Fleet Deploy Handbook

One screen that answers two questions: what is running right now, and what do I press next.

01 —

What it is

Deploy is the screen where a change stops being code and starts being something people can use.

Every workspace has one. It tracks two environments - beta (where you try things) and production (where your users are) - and it shows you one button at a time: the next sensible thing to do.

Behind that button, Fleet does the parts nobody wants to do by hand: find the right build, pin the exact image, write the config, roll the pods, and watch whether they came back healthy.

02 —

Why we use it

Three questions used to have no single answer.

Is the build done?

You had to open GitHub Actions and read a run list. Now the screen says so, and “Check now” asks GitHub on demand.

What is actually live?

You had to trust that the last merge went out. Now each environment shows the image digest it is really running.

Where did it get to?

A deploy was a black box between “triggered” and “seems fine”. Now you watch pods come up, one by one.

03 —

Where to find it

Open fleetcontrol.build, pick your workspace, click Deploy.

URL shape: fleetcontrol.build/orgs/qode/users/<you>/workspaces/<your-workspace>/deploy

Overview
What is running, and the next action. This is the tab you want 90% of the time.
History
Every past revision, and the button to roll back to one.
Env
Environment variables and CI variables, for beta and production separately.
Checklist
The review items a release has to clear before it can ship to production.

04 —

The journey a release takes

A release moves through five stages, always in this order. The screen tells you which one you are in.

  1. 1

    Draft — You prepared a release from the top of your branch. Fleet finds the build for that exact commit, or starts one.

  2. 2

    Pending — You promoted it. Beta already has it. Production is waiting for a person to approve.

  3. 3

    Approved — Someone approved it. Production is rolling - old pods out, new pods in.

  4. 4

    Verifying — The pods are up. Fleet watches health and the public address before calling it done.

  5. 5

    Shipped — It is live, and the release is closed. The next change starts a new one.

Beta does not wait for anyone. Promoting sends the build to beta straight away. Approval is only ever about production.

05 —

What you see on Overview

Four things, and nothing else.

A banner
Appears only when there is something to say: a build running, a deploy that failed. It goes away on its own. If there is no banner, nothing is wrong.
One row per environment
What image is running, which version, when it went out, and who moved it last. Click a row to open it.
One button
The next step, and only that step. If it is greyed out, the hint beside it says what is missing.
A DoD score
How many quality checks your project passes, like 16/16. Click through for the detail.

Clicking an environment row opens a panel with the checklist first, then the tickets and pull requests in this release, what changed in its config, and the deeper facts - running digest, Helm revision, last deploy. The app's settings for that environment live at the bottom: replicas, port, resources, service and public address.

06 —

How to do the usual things

Ship a change to production

  1. Merge your change to the main branch as usual.
  2. On Deploy, press Prepare a release. Fleet finds the build for that commit, or starts one, and shows you the progress.
  3. When the build is ready, press Promote. Beta gets it immediately.
  4. Check beta actually works. Then clear anything the checklist is still blocking on.
  5. Press Approve. Production rolls, and the screen shows the pods coming up.

Merging alone deploys nothing. The press is the deploy.

Find out whether the build is finished

  1. The environment row shows the run and how long it has been going.
  2. Press View log to watch the build output as it happens.
  3. If you started a build yourself on GitHub, press Check now - that asks GitHub about your exact commit instead of waiting for the next sweep.

The screen refreshes itself while something is in flight, then stops. You do not need to reload.

Change the app's settings - port, replicas, domain

  1. Click the environment row to open its panel.
  2. Scroll to the app settings and edit the field you need.
  3. Press Save. The change is written to that environment only.

Beta and production keep separate settings on purpose - changing one never touches the other.

Put production back the way it was

  1. On the production row, press Rollback, or pick an older revision under History.
  2. Confirm. The cluster changes immediately - this does not wait for an approval.

Rollback moves the running app back. It does not undo the release record, so the history stays honest about what happened.

Set up an environment you do not have yet

  1. If a row says the environment is not declared, press Set up.
  2. Fleet creates it empty. Nothing is deployed to it yet.
  3. Prepare and promote a release to put something there.

Most workspaces start with production only. Beta is worth adding before your first risky change, not after.

07 —

Worth knowing before you press anything

  • Merged is not deployed. Code on the main branch is not live until someone prepares, promotes and approves a release. There is no automatic path to production, by design.
  • Settings lock once you promote. From the moment you promote until the release finishes, the app settings are read-only. That is what makes an approval mean something: what the approver read is what deploys. Withdraw the release if you need to change it.
  • The port lives in three places. The container port, the service port and the health checks all have to agree, or the app runs and nobody can reach it. Fleet moves all three together when you change one - so change it here, not by hand.
  • A custom domain needs DNS first. Adding a domain asks for a certificate right away, and that request waits until the domain actually points at our cluster. Point the DNS first, then add it.
  • Re-pull on beta does not fetch a new version. It re-applies the current settings and restarts the pods so they pull the image tag again. Use it when a build was pushed under the same tag - not to move a new release forward.
  • Secrets are never stored by Fleet. Secret values are written straight to the cluster and shown masked everywhere else. If a field shows dots, that is the real value being protected, not an empty field.