The deployment workflow
Before anything is built, The Deployer shows you everything your chosen hosting plan will set up, in the order a new version of your app goes through it. This is the Workflow step. It comes right after you choose a hosting plan, for every kind of plan and every kind of app, in both the deploy guide and Step by step. It's a preview: nothing is created until you press Launch.
What you're looking at
The step has two views of the same thing:
- A diagram of connected boxes. Each box is one piece of your deployment. The line down (or across, on a wide screen) is what happens every time you release a new version, from your code to your live app. The pieces beside your app are where it keeps its data and what keeps watch over it. Tap a box to jump to its explanation.
- Each piece explained in plain words, numbered in order: what it is, what it's for, which tool or cloud service does it, and what you could use instead.
At the top, a short summary says in one or two sentences how your app gets from your code to its address on this plan, and roughly what the plan costs each month in your own cloud account.
What the labels mean
| Label | Meaning |
|---|---|
| Required | Part of the plan. Your app couldn't deploy or stay reachable without it. |
| Comes with your cloud | Your cloud provides it with the service (for example its own logs and charts). Nothing extra is installed for it. |
| Optional, on / Optional, off | A piece you can switch, on a plan that runs on your own server. You choose these in the Extras step that follows. |
Nothing optional is added without you seeing it here first.
Alternatives
Where a piece has alternatives, they're listed under it with what each one is like:
- Another tool for the same job (for example a different front door or uptime checker on a server plan). You can swap it in the full workflow editor before you launch.
- Another hosting plan. Your app's own piece lists the other plans you were offered, with their monthly cost. To run your app a different way (on a server of your own instead of managed hosting, for example), go back and choose that plan; the workflow is rebuilt for it.
What the pieces usually are
| Piece | What it does |
|---|---|
| Repository | Where your code lives. A new version starts from here. |
| Build | Turns your code into something that can run: a container image, or your website's finished files. |
| Registry | Keeps each packaged version, so a release can go back to an earlier one. |
| Deploy | Puts the new version live (on your server plans). |
| Your app | Your running application, on a server you own or on your cloud's managed hosting. |
| Front door | Sends visitors to your app and gives your address HTTPS (on your server plans; managed hosting does this itself). |
| Database / Cache | Where your app keeps its data, if it needs them. |
| Logs, charts, alerts, uptime, crash reports | Keep an eye on your app and tell you when something's wrong. |
| Backups | Nightly copies of your data. |
Changing things
Most people glance over the workflow and continue. If you want to change how the pieces fit together, open the full workflow editor: click a piece to read about it, swap its tool, or remove and restore an optional piece. Pieces with a small lock can't be removed.
Next
When you're happy with it, continue. On a plan that runs on your own server you'll choose the optional Extras next; otherwise you go straight to the web address. The workflow then becomes the exact plan that Launch carries out, step by step.