Render

Render takes a repository, builds it, runs it, and gives you managed Postgres and Key Value next to it. Four capabilities answer that surface: /v1/platform (37 operations) for the app, /v1/provisioning (28) for the data, /v1/projects (27) for a static site, and /v1/tasks (5) for cron.

The structural difference that shows up in every call is ownerId — Render makes the tenant a field you send, on every create and as a query parameter on every list. Here the org is read off the validated key and the cluster namespace tenant-<org> is derived from it, so there is no field to write another tenant into and nothing to keep in step between calls.

Start here

An image you already have becomes a running URL in one call, and the database beside it in a second.

# 1. mint a key — sk- belongs on a server, pk- is safe in a browser
curl -sS -X POST https://api.hanzo.ai/v1/account/keys \
  -H "Authorization: Bearer $HANZO_SESSION" \
  -H 'Content-Type: application/json' \
  -d '{"type":"secret"}'

# 2. run the image — no owner lookup, no service id. 202 with the live URL
curl -sS -X POST https://api.hanzo.ai/v1/platform/run \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"name":"api","image":"oci.hanzo.ai/acme/api:1.4.2","port":8080,"minScale":1}'

# 3. a Postgres of your own beside it — instance binds SQL_URL into the app
curl -sS -X POST https://api.hanzo.ai/v1/provisioning/sql \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"name":"orders","instance":"api"}'

Two calls, and neither holds an identifier the other minted: the org is read off the key, the app is addressed by the name you chose, and instance places the DSN in the app's environment at create. Render's equivalent is five — list owners for ownerId, create the service, poll the deploy, fetch connection-info, then PUT the whole env-var array back. Re-running step 2 with the same name updates that app in place, so a pipeline stores nothing between runs.

Core capabilities

Nouns

Render's type field picks between five service kinds. Two of them are separate capabilities here, and the rest are one app.

Services and deploys

Data, edge and the rest

The call

Render, standing up a service. Three requests, because the create needs an owner you have to go and find, and the deploy it starts has to be polled:

curl -sS https://api.render.com/v1/owners \
  -H "Authorization: Bearer $RENDER_API_KEY"

curl -sS -X POST https://api.render.com/v1/services \
  -H "Authorization: Bearer $RENDER_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "web_service",
    "name": "api",
    "ownerId": "own-cq1e8h5f2p",
    "repo": "https://github.com/acme/api",
    "branch": "main",
    "serviceDetails": {"env": "docker"}
  }'

curl -sS "https://api.render.com/v1/services/srv-cq1e8j/deploys/dep-cq1e8k" \
  -H "Authorization: Bearer $RENDER_API_KEY"

Hanzo, from an image that already exists. One request:

curl -sS -X POST https://api.hanzo.ai/v1/platform/run \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "api",
    "image": "oci.hanzo.ai/acme/api:1.4.2",
    "port": 8080,
    "minScale": 1,
    "maxScale": 4
  }'

From a repo, where there is something to build, it is create then deploy:

curl -sS -X POST https://api.hanzo.ai/v1/platform/projects/acme/apps \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "api",
    "source": "git",
    "repo": {"url": "https://github.com/acme/api", "branch": "main"},
    "buildType": "pack",
    "port": 8080,
    "storageGb": 10
  }'

curl -sS -X POST \
  https://api.hanzo.ai/v1/platform/projects/acme/apps/api/deploy \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"commit":"main"}'

The database, and its wiring, is one call:

curl -sS -X POST https://api.hanzo.ai/v1/provisioning/sql \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"name":"orders","instance":"api"}'

And a rollback takes an empty body:

curl -sS -X POST \
  https://api.hanzo.ai/v1/platform/projects/acme/apps/api/rollback \
  -H "Authorization: Bearer $HANZO_API_KEY" \
  -H 'Content-Type: application/json' -d '{}'

Count what each side has to remember. Render's flow carries own-, then srv-, then dep-, and a pipeline has to store the service id between runs to know whether to POST or PATCH. Here an app is addressed by project and slug, a provisioned resource by the org-unique name you chose, and POST /v1/platform/run is idempotent by name — re-running it updates that app in place, so a pipeline holds no identifier at all. The 201 from /v1/provisioning/sql carries connectionString in the body, and instance binds the resource to an app whose <instance>-addons Secret receives the SQL_URL; Render answers its create without the DSN and makes you fetch connection-info, then PUT the whole env-var array back. The rollback is the same shape: Render wants a deployId you looked up first, and here an empty body resolves to the newest earlier deployment that carries a real built image and did not error, skipping the release currently live.

What does not carry

render.yaml has no equivalent. Render's Blueprint is a file in the repo that declares services, databases and env groups, and syncing it creates them. hanzo.yml in a repo declares how that repo builds — the images and binaries — and committing it is how a repo opts into push-to-deploy, rather than owning a webhook of its own. The service's shape is API state: replicas, disk, domains and env are calls, not lines in a file. /v1/blueprint (3) is a catalog of ready-made stacks, which is a different thing to your repo declaring itself.

There is no private service. Every app is seeded with its canonical host, <slug>.<org>.<sites host>, at create, and that host cannot be removed — re-adding it is a 409. So an app is always reachable by name. Restrict who may call it with /v1/gateway (3), which is edge policy rather than absence from DNS, and have the app authenticate its callers.

Backups and point-in-time recovery are not in the provisioning API. Render gives Postgres GET /v1/postgres/{id}/backups, POST .../recovery and a managed export. /v1/provisioning (28) is create, read and drop across seven kinds — sql, kv, vector, search, s3, docdb and datastore. The instance runs in your own namespace and no other tenant shares the process, which also means its backup schedule is yours to run.

The credential is returned once. The 201 carries connectionString and password, and no read beside it does: GET /v1/provisioning/sql/{name} answers the status, the instance address and the admin user Postgres booted with, never the password. Render's connection-info can be fetched whenever you like. Bind the resource with instance at create, or put the DSN into /v1/kms (5) yourself.

Env groups do not fan out, and a write does not restart anything. Render's env group is one object many services inherit, and editing it redeploys them all. PUT .../apps/{app}/env replaces one app's whole set — a variable absent from the body is gone — and running pods keep the environment they started with until their next deploy. A value two apps share is written into both, or held in /v1/kms and placed by whatever runs your deploy.

A refused deploy leaves no record at all. Deploys are capped per org: over the concurrent limit is 429 and nothing is written, so there is no phantom in the history to reconcile. An unreachable cluster is 503 but does record an error deployment, because an attempt that failed must not be indistinguishable from one never made. Render queues instead of refusing, so port a retry rather than assuming the deploy is somewhere in a backlog.