How Camplax works

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:

Nothing here is a separate account. A user in your app is a row in your project's database, a file is in your project's bucket, 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: a small always-available compute instance, its own Postgres database, and its own slice of object storage, sitting behind Camplax's DNS and certificates. An idle app suspends and resumes in a few hundred milliseconds, so a quiet project costs nothing to keep warm.

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 Fly.io Machines with a Prisma Postgres database and 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.app and any custom domains.
• Preview — every other branch, at https://branch--your-app.camplax.app, with its own compute, its own database branch, its own storage and its own secrets overlay. Previews covers this in full.

Secrets 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 Secrets.

Where each tool fits

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.
• Secrets — the vault, overlays, and the variables Camplax injects.