Skip to main content
Build an application with an agent, deploy it from Git, and operate it through one contract. Korve gives each project a managed your-app.korve.app URL and optional databases, storage, queues, crons, caches, observability, recovery, custom domains, and spend controls — plus a deployment agent that investigates failures and proposes approval-gated actions. The shortest path from repository to live application is korve init: it detects the Git source, writes a reviewable manifest, shows the plan, applies it, links the directory, deploys, and verifies the terminal deployment state. It is built agents-first. Public operator capabilities are declared once and projected onto four surfaces with the same permissions and behavior:
  1. API — https://api.korve.dev, described by a public spec at GET /v1/spec. See the API reference.
  2. CLI — the korve binary. Every public API operation a key can call maps to exactly one command (a tested parity guarantee). See the CLI reference.
  3. MCP — https://mcp.korve.dev/mcp, two tools: search the API and execute code against it. See MCP setup.
  4. Dashboard — the convenience layer at korve.dev for the things humans prefer to click.
Agents can call the complete public operator surface; identity, billing, and membership work that requires a dashboard session stays intentionally human-gated. Start with agent onboarding.

​
How Korve is built

  • Paid-only, usage-based. No free tier, no seats. You pay for what you run, metered against a public rate card to the cent, with a $5/month platform minimum credited against usage.
  • One spec, one enforcement point. Auth, roles, and billing gates are declared per operation and enforced once in the API layer. The dashboard, CLI, and MCP inherit identical behavior — there is no surface with secret extra powers.
  • Declarative when you want it. Describe projects, environment, and domains in a manifest and apply it. The platform reconciles and never deletes anything you didn’t ask it to.
  • Assisted operations. Failed deploys can be diagnosed by the deployment agent, which persists the conversation and requires approval before any mutation.

​
Runtime classes

Every project picks one of two runtime classes at creation: See Deploys for what each class expects from your code.

​
Next steps