IRON LAKE

Iron Lake Memo No. 002 · 2026-04-22

The vision, annotated.

The prelaunch page tells you what we believe. This page shows you what we're building. Three things, in order: the API an agent will see, the formula behind every line on its bill, and the calendar between here and v1.

on this page how an agent uses Kingdom · what we charge for · where we're going · what we are not

How an agent uses Kingdom

Four verbs. Every other API surface is built from these. They were designed for a thing that reads documentation by parsing it, holds the whole conversation in working memory, and never clicks a button.

POST /v1/jobs deploy
$ curl -X POST https://api.kingdom.sh/v1/jobs \
    -H "Authorization: Bearer $KINGDOM_KEY" \
    -H "Idempotency-Key: 7f3e9c2b-..." \
    -d '{
      "image":        "ghcr.io/you/yourapp:latest",
      "ingress_port": 8080,
      "service":      "api",
      "resources":    {"cpu": 1, "memory_mb": 512}
    }'

{
  "id":         "kj_01HW8Z3N5K...",
  "state":      "BOOTING",
  "public_url": "https://api-a4b9.kingdom.sh",
  "cost": {
    "this_request_usd":    0.00,
    "period_total_usd":    0.00,
    "budget_remaining_usd": null
  }
}
GET /v1/jobs/{id} status
$ curl https://api.kingdom.sh/v1/jobs/kj_01HW8Z3N5K... \
    -H "Authorization: Bearer $KINGDOM_KEY"

{
  "id":         "kj_01HW8Z3N5K...",
  "state":      "READY",
  "public_url": "https://api-a4b9.kingdom.sh",
  "timings": {
    "submitted_at": "2026-04-22T14:33:01Z",
    "booted_at":    "2026-04-22T14:33:14Z",
    "ready_at":     "2026-04-22T14:33:18Z"
  },
  "error":      null,
  "cost": { ... }
}
GET /v1/jobs/{id}/logs logs
$ curl -N https://api.kingdom.sh/v1/jobs/kj_01HW8Z3N5K.../logs \
    -H "Authorization: Bearer $KINGDOM_KEY" \
    --header "Accept: text/event-stream"

data: {"ts":"2026-04-22T14:33:14.012Z","stream":"stdout","line":"axum listening :8080"}
data: {"ts":"2026-04-22T14:33:18.441Z","stream":"stdout","line":"GET / 200 — 1.4ms"}
...
DELETE /v1/jobs/{id} cancel
$ curl -X DELETE https://api.kingdom.sh/v1/jobs/kj_01HW8Z3N5K... \
    -H "Authorization: Bearer $KINGDOM_KEY"

{
  "id":    "kj_01HW8Z3N5K...",
  "state": "CANCELLED",
  "cost": { ... }
}

Phase 1a adds POST /v1/storage (Garage buckets), POST /v1/databases (SQLite-on-NVMe), POST /v1/networks (per-tenant VXLAN), and the account surface (GET /v1/account, GET /v1/usage, GET /v1/audit). Each one is the same shape: ULID, structured error envelope, cost metadata, idempotency key.

What we charge for

Three lines on your bill: compute, storage, bandwidth. Nothing else. Not API calls. Not load balancers. Not DNS records. Not "premium support." The formula is below; the numbers ship with the metering pipeline in Q3.

price_per_unit  =  ((capex_amortized + opex) / utilization)  ×  (1 + margin)

  where
    capex_amortized  =  hardware_cost / (months_in_service × hours_per_month)
    opex             =  power + transit_share + compliance + ops_overhead
    utilization      =  realistic_average_utilization  (we publish ours quarterly)
    margin           ∈  [0.30, 0.40]  (strategic ceiling, not a target)

What "transparent" actually means here

The formula is versioned
Each pricing change is a Git commit on a public file. kingdom-pricing@v1.4.2 is the unit, not "we'll let you know in an email."
Inputs are itemized
Hardware cost: the actual invoice we paid. Power: the watt-hour rate from our utility, multiplied by measured draw. Transit: the contracted IP-transit rate divided across the rack. You can do the multiplication yourself.
Utilization is published
Most clouds price as if their hardware ran at 100% — they don't, and the spread becomes pure margin. We publish the actual quarterly utilization number we used in the denominator. When utilization rises, prices fall. Mechanically.
Margin is capped
30–40% gross margin. Floor is 30 because below that we can't fund safety circuits and DR. Ceiling is 40 because above that someone will notice and undercut us, and we'd deserve it.
Egress is not a profit center
Industry standard is ~$0.09/GB. The actual underlying transit cost is closer to $0.001/GB at small scale and $0.0005/GB at any reasonable scale. We charge near cost. The math does not change because it's egress.
The free tier is permanent
Not a trial. Not credits. Not a 12-month rug-pull. A floor — small enough to be cheap to provide, big enough that an agent can try things without a credit card. Funded by paid usage; not subsidized by VC.

A worked example with real Q3 numbers — vCPU-hour, GB-month of NVMe, GB of egress — ships with Phase 1b's metering pipeline. Until then, every cost field in the API returns null for budget_remaining_usd rather than a misleading zero.

Where we're going

Calendar-honest. v1 is Phase 0 plus Phase 1. Anything later is real work, not hand-waving.

  1. Phase 0 Q2 2026 in progress

    The Demo

    Single-node Slurm + Firecracker + axum API + Caddy ingress on owned metal. Agent reads kingdom-skill.md, calls four endpoints, hello-world boots in a microVM and is reachable on the public internet within ~30 seconds. Filmed at the end of the phase. Public announcement held to Phase 1b so the launch lands paired with a signup funnel.

  2. Phase 1a Q3 2026 planned

    Platform Core

    Multi-node cluster (2–3 boxes). kingdom-controller as a separate reconciler daemon. VXLAN tenant isolation under Open vSwitch with default-deny flows, gated on every commit by a multi-tenant integration test. Garage for object storage, CoreDNS+Valkey for service discovery, real auth with API-key-per-tenant.

  3. Phase 1b Q3 2026 planned

    Safety, Metering, Hardening — and Launch

    Metering pipeline producing the cost numbers the API has been shipping null for. Four-layer cost-spiral defense (submit-rate limiter, job_submit budget breaker, soft cost ceilings, kill switch). Observability moves to a fate-separated node so the alerting cannot die with the cluster it watches. DR plan exercised. The kingdom.sh landing page ships and the first wave of accounts opens.

  4. Phase 1c Q4 2026 planned

    Dog-food Migration

    Our two production SaaS workloads — Riley (medspa marketing) and Form Relay (fan-in form builder) — migrate onto Kingdom in parallel-run mode, then cut over. v1 ships when both are 100% on Kingdom with their published SLOs intact. We are the first paying customer of our own platform; if it can't run our own revenue, it isn't ready.

  5. Phase 2 2027 future

    Billing & Colocation

    Stripe wired in (we want first homelab users before money flows). Colocation deployment when homelab capacity is the bottleneck — not before. The hardware story stays "owned metal" even at colo; this is just rented rack space and transit, not rented compute.

  6. Phase 3 2027+ future

    Public Beta & PMF

    MCP adapter. OpenAPI spec made authoritative. Workload classification and an intelligence layer that learns the shape of agent traffic. A possible fast tier: unikernels on the same Firecracker substrate, sub-10ms cold start, an order of magnitude faster than the Linux guest path. Decided when the metering data tells us agents would actually use it.

What we are not

Some of these are restatements of the manifesto. The full pitch is in Why Iron Lake. This list is here so that if any of these are dealbreakers for you, you know now.

  • Not 200 services. Compute, storage, bandwidth, databases, networking. That's the whole shape. We don't have a queue product. We don't have a managed Kafka. We don't have an AI Studio. If the answer to "where do I run my code" is "in a Kingdom job," we're done.
  • No web console. A read-only dashboard, eventually. Never a place where the official path to deploy something is to click. The agent is the user; the console is for humans who want to see what their agent did.
  • No enterprise sales. No negotiated SKUs. No "talk to us about pricing." No hidden enterprise tier with the actually-good features. Self-serve only, forever.
  • No usage-based opaque billing. If a charge appears on your invoice, the formula that produced it is in our public Git repo at the version we used.
  • No egress gouging. Bandwidth is priced near transit cost. Moving data out is not a punishment for leaving.
  • No paid SaaS dependencies for core infra. Self-hosted OSS only. If a vendor we depend on changes their terms and we can't absorb the hit, we have to pass it on. We've removed the option.
  • No raising VC unless we have to. VC math forces maximum extraction. Maximum extraction kills the wedge. Bootstrap-first; revenue-funded; cap-table-clean.

None of this is a posture. Each is a structural commitment baked into the architecture, the legal entity, or the funding shape. Walking any of them back later is more expensive than honoring them now.

If this resonates

The waitlist is a mailto: link. We send one email when Kingdom opens the first wave of accounts and never another, unless you reply.

Or read Why Iron Lake, the long version of the manifesto.