Customize your deploy

Every deploy runs the same ordered sequence — pull your code, install dependencies, run migrations, switch traffic over. Most of the time that's exactly what you want, and you never need to touch it. But when your application needs something extra — clear a cache, warm a search index, send a release notification — you can add it to the sequence yourself.

Each environment has its own deploy plan: the list of steps that runs every time you deploy. You edit it under your environment's Deployment settings, and your changes apply from the next deploy onward.

See what runs

Open Deployment settings for an environment to see the full sequence laid out in order. Each step shows the context it runs with — the branch, your PHP and Node versions, the database engine, the number of background workers — so you can see at a glance what strackt detected and what each step will do.

The steps strackt manages for you (checking out your code, building the release, switching traffic) are always present. Some steps are optional and can be turned off; the essential ones can't, so you can never accidentally remove the parts that keep a deploy safe.

Add your own command

Hover between any two steps to reveal an add command gap, and drop in a command that runs at exactly that point in the sequence. Each command shows which step it runs after, so the order is always clear.

Your commands run in sequence with the rest of the deploy, and the deploy stops if one of them fails. That's deliberate: if your "warm the cache" command errors out, you usually don't want the deploy to continue and call itself done. The flip side is the one thing to watch for — a command that always fails will block every deploy for that environment until you fix or remove it. There's no dry-run, so test your command before you rely on it.

Use commands for work that's part of the release itself and must succeed: building extra assets, priming a cache, running a one-off data fix.

Add a hook

Hooks are for the opposite case — work that should run around a deploy but should never be able to break it. A hook is attached to a moment in the deploy's life rather than a position in the sequence, and a failing hook is logged but never fails the deploy.

There are four moments you can hook into:

• On start — just before the first step runs.
• On success — after a clean deploy, before it's marked done.
• On failure — when any step fails.
• On rollback — reserved for a future release; you can write it now, but it won't run yet.

Use hooks for notifications and bookkeeping: ping your team channel on success, post to an error tracker on failure, record the release somewhere. Because hooks can't fail a deploy, they're the safe place for "nice to have" side effects.

Turn optional steps on or off

Some steps only make sense for some applications. If a step is optional, you can switch it off and it drops out of the sequence — for example, skipping migrations on an environment that doesn't own its database. The essential steps stay on no matter what.

If strackt later adds a new optional step to the platform, it stays off for your existing environments. A platform update never silently changes a deploy pipeline you've already set up.

Deploy once with different options

Sometimes you want to change a deploy just for a single run without changing your saved plan — skip migrations on one deploy, add a one-off command to test something. Choose Deploy with options instead of the one-click Deploy, and your changes apply to that run only. Your standing plan is untouched, and the next plain deploy uses it as normal.

See what actually ran

After a deploy, open the environment's Activity and expand the deployment to see the plan as it executed — every step, how long it took, and which step failed if one did. The plan you edit and the record of what ran share the same shape, so what you set up is exactly what you can audit afterward.

A note on safety

Your commands and hooks run as your application's own user, within the deploy's time limit. They're powerful — they can do anything your application can — so treat them like the rest of your code: keep them in mind when something changes, and remove ones you no longer need.

Related

• How deploys work — the standard sequence every deploy follows.
• When a deploy fails — what to check when a deploy stops partway.