What is Spikefrost

Spikefrost is an enterprise platform for building and running production applications, including the AI agents that operate them. Apps are governed by default, audited end to end, and deployed on a global edge network — with a build cycle measured in days rather than quarters.

The compression comes from the platform owning what usually consumes a project: hosting, databases, storage, secrets, domains, environments, version control, observability, and the guardrails around AI. Your team writes application logic; nothing else has to be assembled first.

Built to pass a security review

The things a review asks for are properties of the platform, not features you configure:

Each of those is documented with its mechanism and its limits in Platform & reliability — including where we don't meet a requirement, which is usually the faster conversation.

Enterprise capabilities

Beyond the standard platform, three capabilities are provisioned under an enterprise agreement:

• A dedicated Cloudflare account — your apps become the only apps in the account, so the tenancy answer is "the account is ours" rather than isolate-level separation from other tenants.
• A customer-owned account — the same, on your own Cloudflare contract, if your policy requires the cloud relationship in your name.
• Postgres alongside D1 — for datasets past 10 GB, Postgres-specific features, or data that must sit in a region you choose.

Details, prerequisites, and honest trade-offs in Enterprise capabilities.

What you get with every app

Creating an app provisions a full stack. Nothing here is an add-on you wire up later:

How software gets built here

You describe the outcome; an AI agent designs, writes, and deploys it. What makes that safe to run in an enterprise is where the platform refuses to be flexible:

• The output is a codebase, not a saved configuration. Ordinary TypeScript your engineers can read, review, and reject. There is no proprietary runtime to reverse-engineer during a due-diligence exercise.
• Every AI action is attributed and reversible. Each turn is a commit; each deploy is a record. Rolling back is a one-minute deploy of an earlier commit.
• Business rules live in code, not in prompts. A margin floor or a spend limit enforced in a domain function binds every caller — an agent, an HTTP route, a scheduled job — and still binds after a human approves the action. A rule written into a prompt is guidance a model can be argued out of.
• Agents hold only what they are granted. No ambient filesystem, shell, or database access; no long-lived third-party keys in agent code. A read-only analyst cannot be talked into a write it was never given.
• Claims are verifiable. Every agent turn is traced, so "did it actually check inventory?" is answered by a tool-call edge rather than by the agent's own summary.

Two ways in, operating on exactly the same app:

• The desktop app — a workspace where a team member describes what they need and reviews what the agent built. See The desktop app.
• The sf CLI — the engineering interface. Open the project in your own editor, run your own coding agent, deploy from a terminal or from CI. See The sf CLI.

Neither is a lesser version of the other: same files, same history, same deploys, same review trail.

Apps versus agents

Two words that get conflated everywhere. Here they are distinct:

• An app is the deployed thing: routes, pages, data, storage. A customer portal is an app. An internal tool is an app. A storefront is an app.
• An agent is an actor inside an app. It has instructions, a model, an explicit allowlist of tools, and channels it can be reached on. It can answer an email, watch a queue, run on a schedule, or hold a conversation.

An app with no agents is a conventional web application that happens to have been written quickly. An app with agents is an agentic app: software that both serves requests and takes action on your behalf. Most production systems end up as some of both — a portal with a support agent behind the chat, or an operations tool with an agent that triages the overnight queue.

Who it's for

• Platform and engineering teams that need to ship internal tools, portals, and integrations faster than a normal project cycle allows, without standing up new infrastructure or taking on another thing to operate.
• Operations and back-office teams replacing manual process with agents that have real credentials, real limits, and an audit trail — where permissions and spend are visible to whoever owns the team.
• Developers who want the setup tax gone. The stack is opinionated on purpose: Hono, Workers, D1. A deployed app on day one instead of a terraform plan.
• Smaller teams and founders building the thing they need this week without hiring for it. The platform doesn't change shape for them — the same governance applies, it just isn't in the way.

What Spikefrost is not

Being clear about the edges is faster than discovering them in a proof of concept:

• Not a general VPS or container host. Apps run on Workers at the edge, which is what makes them fast and global — and means long-running processes, arbitrary binaries, and native daemons are the wrong shape. Heavy or long work belongs in a queue consumer, a scheduled job, or an agent turn.
• Not a lift-and-shift target. Existing applications aren't migrated onto this; new ones are built on it, and can integrate with what you already run.
• Not a place to store bulk files. The project tree is source. Media goes to assets, data goes in the database — see Files and assets.
• Not able to guarantee where compute runs. Code executes in the location nearest each user on every tier. Stored-data residency is addressable; processing residency is not — see Isolation and tenancy.

Where to go next

• Architecture overview — what runs your app, and what you don't have to operate.
• SLAs, limits and quotas — the commitments, the limits, and the compliance posture in one place.
• Enterprise capabilities — dedicated accounts and Postgres.
• Core concepts — the vocabulary: apps, environments, agents, connectors, jobs, commits.
• Getting started — install, sign in, and deploy a first app.