Skip to content
cantila

Platform services

Every project deployed on Cantila gets its own dedicated database, object storage, and an email service — provisioned together with the project and wired into the environment before the first build runs. SMS is opt-in: a project gets no number until you activate SMS on it (see SMS, Voice & Numbers).

This page is the overview. Each service has its own page with the API surface and current phase status:

  • Databases & storage — managed Postgres + S3-compatible buckets.
  • Domains — search, register, and attach custom domains.
  • Mail — first-party email provider.
  • SMS, Voice & Numbers — telephony provider and number marketplace.
  • Automations — managed n8n / OpenClaw + native workflow canvas.
  • Connections — account-wide credentials reused across workflows.
  • Agents — the self-healing brain and agent swarm.
  • Templates — one-shot create + deploy marketplace.

What's wired, by phase

ServiceEnv var(s)PhaseDefault state
PostgresDATABASE_URLLiveReal, running on Hetzner
Object storageSTORAGE_ENDPOINT, STORAGE_BUCKET, STORAGE_KEYLiveS3-compatible, per-project
Mailbox + SMTPSMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASSPhase 2Real creds, stub MTA today
SMS numberCANTILA_SMS_NUMBER, CANTILA_SMS_API_KEYOpt-inActivate per project
Cantila API keyCANTILA_API_KEY (scoped to the project)LiveUsed by the runtime SDK

What works today

  • Live: Postgres (DATABASE_URL) and S3-compatible storage are real and running.
  • Phase 2: Mailbox + per-project SMTP credentials are real and auto-wired, but no real bytes leave the MTA yet — the send path is a stub. See Mail.
  • Opt-in: SMS is not auto-wired. Activate it on a project to provision a real number (billed monthly) and inject CANTILA_SMS_NUMBER / CANTILA_SMS_API_KEY. See SMS.

Phase 2 and Phase 3 env vars exist today against the stub adapters — you can write code that targets them and it will work against the API; the live carrier delivery flips on as each phase ships. See the changelog.

How the wiring works

When you create a project:

  1. Project row is created in the control plane.
  2. Database is provisioned in the managed Postgres cluster. A per- project user and database are created; DATABASE_URL is generated.
  3. Mailbox is created at m_<random>@cantila.app (Phase 2 — this becomes <project>@<your-domain> once Mail goes live).
  4. Cantila API key scoped to the project is minted.
  5. Env injection. All of the above are written to the project's secrets, marked cantila-managed: true, and locked from user overwrite.
  6. First build runs with the env in place.

SMS is not provisioned here — it's opt-in. When you activate SMS on the project, a real number is leased and CANTILA_SMS_NUMBER / CANTILA_SMS_API_KEY are injected then.

Sleeping when idle

Auto-wired services follow the same sleep policy as the project itself:

  • Hobby projects sleep when idle (~10 minutes of no traffic). Their database connections close; storage buckets stay live. Wake on next request.
  • Starter / Pro / Agency projects pinned always-on stay live.

A sleeping database doesn't bill on the meter; storage and number leases keep their fixed monthly cost regardless of sleep.

Tearing down

Deleting a project tears down its auto-wired services in lockstep:

project       deleted
db            dropped
storage       bucket emptied + dropped
mailbox       deleted (Phase 2)
sms number    released (only if SMS was activated)
domain        retained (your domain, your call)

The domain stays — it's a registrar product, billed separately from the project. Manage from Console → Domains.

Why bundled

The whole point: a builder ships an app and DATABASE_URL already resolves. No second vendor signup. No glue code. One bill.

Want to bring your own Postgres / S3 / mailbox? Override the Cantila-managed env vars at the project level — Cantila respects user overwrites and stops managing the slot until you delete the override.