How it works

How a deploy works

Plan, apply, and the state file: why re-running a deploy is safe and never duplicates anything.

Every deploy is the same two moves: work out what's missing, then make it so. Understanding that explains why re-running a deploy is safe, and why nothing is ever created twice.

Plan, then apply

Plan compares what your launchpad.json describes with what already exists, and lists the difference: what would be created, what would be changed, and which credentials are missing. It changes nothing. The console shows it beside the switches as you edit; the CLI prints it with launchpad plan.

Apply carries that list out, in order.

The order of steps

database → redis → email → sign-in → storage → payments → bot protection → processes → hosting → domain

The order matters: every key exists before anything that needs it is deployed, and the web app can be given its background API's URL because processes come first.

State: how it knows what exists

As each step finishes, Launchpad records the id of what it created, and nothing else. On the next run it reads those ids back, so it updates the same database and the same Vercel project instead of making new ones.

  • With the CLI, state is a .launchpad/state.json file next to your launchpad.json.
  • In the console, it's a row in its database.

Because progress is saved as each step finishes, not at the end, a deploy that dies halfway through, or times out while a database starts, resumes from where it stopped.

Why re-running is safe

  • A step that already did its work checks and moves on.
  • A step that was interrupted finds its half-finished resource by id and continues.
  • Values that can't be read back, such as a database password, are asked of the provider each run rather than stored.

So "press Deploy again" is a real answer to most problems, and the usual next step after fixing a permission or turning a service on.

Things Launchpad leaves to you

Some steps can't be done through an API. They're listed under Still to do at the end of a deploy, and keep appearing until they're done:

  • DNS records, when your DNS isn't on Cloudflare.
  • A Razorpay webhook, because only partner accounts may create one through the API.
  • An OAuth app for GitHub or Google sign-in.

Changing things later

Edit launchpad.json, or the switches in the console, and deploy again. Added services are created, removed secrets are deleted from the providers, and buckets or products you took out are kept rather than deleted, because they may hold data or past payments.

Tearing down

A teardown deletes what Launchpad created, newest first, and keeps:

  • anything you linked from an existing setup;
  • storage buckets that still hold files;
  • Stripe products and prices, because past payments refer to them;
  • your own secrets.

In the console, deleting a project asks you to type its name first.

Something missing or wrong? Edit this page on GitHub or email hello@axonscape.com.