Deploy

Every edit to a ZXCV project is a deploy. Deploys are atomic, content-addressed, and versioned — v43 becomes v44, each one a complete, immutable snapshot of your app, schema, and authorization rules. There is no half-shipped state: a version is either live or it isn’t.

Because each version is previewable, you can look at exactly what a change does before it reaches your users — then promote it, roll it back, or canary it.

Publishing

There are two ways to ship, and they land on the same version line.

zxcv deploy            # build a new version + preview URL
zxcv deploy --prod     # promote it to your production domain

Whichever way you work, both surfaces write to one project and one version line, so a build from the console and a zxcv deploy are interchangeable.

Previews

Every deploy gets its own preview URL — a live copy of that exact version. Share it, review it, and only promote when it looks right. A preview runs the same gateway, policies, and edge as production, so what you see is what ships.

The global edge

Promoted versions serve from a global edge/CDN spanning 300+ points of presence, so your app loads close to every user without any configuration.

Domains

Every project gets a default domain the moment it exists:

{slug}.zxcv.app

Wildcard DNS and TLS are provisioned automatically — there’s nothing to set up.

To ship on your own domain, add a custom domain. You can bring a domain you already own, or register one through the in-console registrar:

zxcv domains add app.acme.com

Instant rollback

Because every version is immutable and content-addressed, rolling back is instant: pick a previous version and it’s live again — one click in the console. Nothing rebuilds, because that version already exists exactly as it shipped.

Canary deploys

Ship a candidate to a slice of traffic before it goes everywhere:

zxcv deploy --canary 10

This routes 10% of traffic to the new version and watches its metrics. On clean metrics it auto-promotes to 100%. If something looks wrong, rolling back discards the candidate and returns all traffic to the current version — no manual cleanup.

Schema changes are safe deploys

Deploys carry your schema too. Changes ship as expand/contract migrations, and ZXCV takes a restore point before publish — so a bad deploy never strands your data.

The expand migration applies first, in one transaction; the destructive contract steps are deferred until the new version is promoted. Combined with a canary, you can validate a schema change under load before the old shape is removed. See Database → Migrations for how to author them.

CI with GitHub

For continuous deployment, ZXCV ships a GitHub Action so a push to your repo builds and deploys a new version automatically — the same atomic, versioned deploy as the CLI, wired into your pipeline.

Next steps

• CLI reference — deploy, --prod, --canary, domains add
• Database — author expand/contract schema migrations
• Auth · SDK reference