CamplaxHow Camplax works
What a project contains, where each piece runs, and why there are two domains.
Camplax replaces the usual two-vendor setup — a Vercel for the frontend and a Supabase for the data — with a single project. This page is the map: what a project contains, where it runs, and which tool reaches which part.
One project, nine parts
A project is the unit everything hangs off. Create one and all of this exists under one slug:
| Part | What it is | Where to read |
|---|---|---|
| Code | Your repo — connected to GitHub, or deployed from the CLI | Hosting and deploys |
| Deploys | A queued build that ends with a running app; production plus a preview deployment per git branch | Hosting and deploys, Preview deployments |
| Postgres database | Postgres 18, one database per environment, always on, reached through DATABASE_URL | Postgres database |
| Authentication | Better Auth running in your app: accounts, sessions, passkeys and OAuth providers, stored in your app's own Postgres | Authentication |
| Object storage | Files on Cloudflare R2, uploaded and downloaded through signed, expiring URLs | Object storage |
| Environment variables | A vault for variables and secrets, with per-environment and per-branch overlays | Environment variables |
| Domains, DNS and SSL | A free *.camplax.app address, plus your own domains with automatic SSL certificates | Domains, DNS and SSL |
| AI | An OpenAI-compatible gateway, paid from prepaid credits | AI gateway |
| Billing | One plan (Indie $25, Pro $50 or Scale $100 a month) plus one prepaid credit balance for every extra | The console's Billing page |
Nothing here is a separate account. A user in your app is a row in your project's Postgres database, a file is under your project's prefix in object storage, and a deploy is your project's code — which is why "is this person subscribed?" is a query, not an integration.
Two stacks
There are two systems and it helps to know which one you are looking at.
The Camplax platform — the marketing site, the console at camplax.dev/app, and the API your CLI and agents call at camplax.dev/v1. This is Camplax's own infrastructure: it stores your project's settings, secrets, deploy queue and domain config, and it orchestrates everything below. You never deploy code into it.
Your app — what your deploys produce. Each running app is its own isolated service: its own compute, its own Postgres database, and its own prefix in object storage (Cloudflare R2), sitting behind Camplax's DNS and SSL certificates. Production never sleeps; a preview suspends when idle and wakes on its first request.
The practical consequence: the console can be down and your app keeps serving; your app can be broken and the console still works to fix it.
Fine print, for the curious: the control plane runs on Cloudflare Workers and D1; your app runs on a Camplax cell — each environment in its own Kubernetes namespace, production with its own Postgres cluster behind a PgBouncer pooler, previews usually sharing one small Postgres server per account, each with its own database and login — with Cloudflare R2 for files. For your app, Cloudflare is DNS, SSL and storage only — your code does not run on Workers.
Two domains, on purpose
The platform lives on camplax.dev. Your apps live on camplax.app — production at https://your-app.camplax.app, previews at https://branch--your-app.camplax.app, and your own custom domains pointed at the same place.
That split is a security boundary, not branding. A registrable domain is where cookies and browser storage stop: code running on camplax.app cannot set a cookie the console will read, cannot reach the platform's storage, and a problem on a customer domain can never touch camplax.dev. You will never be asked to do anything about it — just do not be surprised that the two never mix.
Environments
Every project has two runtime environments, decided by the branch a deploy came from:
- Production — the default branch, serving
https://your-app.camplax.appand any custom domains. - Preview — every other branch, at
https://branch--your-app.camplax.app, with its own compute, its own database, its own storage prefix and its own environment-variable overlay. Preview deployments covers this in full.
Environment variables have a third layer, development, which is what camplax dev pulls to your laptop. The merge order — production, then preview, then a per-branch override — is in Environment variables.
Where each tool fits
| Tool | Where | What it is for |
|---|---|---|
| Console | camplax.dev/app | Creating projects, watching deploys, the database editor, domains, environment variables, users, billing |
| CLI | camplax (not on npm yet — run from the repository) | login, link, dev, env pull/push, deploy, rollback, logs, db, probe — see CLI reference |
| API | camplax.dev/v1 | Everything the console and CLI do, scriptable with a project API key |
| MCP | https://camplax.dev/mcp | The same verbs for AI agents — see AI agents and MCP |
| These docs | camplax.dev/docs | What you are reading; also available as markdown mirrors and llms.txt |
The console and the CLI are two faces of the same system — a deploy started in one shows up in the other, and both sit on the same API the MCP server uses.
Where to go next
- Getting started — the ten-minute path to a live app.
- Hosting and deploys — the deploy lifecycle, hooks and rollback.
- Environment variables — the vault, overlays, and the variables Camplax injects.