The Deployer documentation
After you're live: the Dashboard

Pull & Restart and auto-deploy

There are two ways your live app picks up new code: you can update it yourself with one click, or, on the Pro and Team plans, you can let The Deployer update it automatically every time you push. This page explains both, and why neither one takes your app offline.

Pull & Restart (the manual way)

At the top of the Dashboard is a Pull & Restart button. It does exactly what it says:

  1. Pulls the latest code from your connected branch (the version of your code The Deployer is tracking, usually main).
  2. Restarts your app with that fresh code.

When you click it, you're taken to a live log screen and the update streams in front of you, exactly like a full deployment — just faster, because nothing about your servers or setup changes. Use it whenever you've pushed a change and want it live right now.

If something goes wrong, an error message appears at the top of the Dashboard explaining what happened, and the attempt is recorded in the Activity feed so you can reopen its logs.

Auto-deploy (the automatic way)

Auto-deploy is included with the Pro and Team plans. On the Free plan, new commits wait until you click Pull & Restart, and your app keeps running the code it already has. If you move to a paid plan later, the very next push deploys.

You usually don't even need the button. When you push new code to your tracked branch, The Deployer notices and redeploys on its own. It does this in one of two ways, and it picks the right one for you automatically:

  • Push webhook — if your setup has a public web address, GitHub sends The Deployer an instant "you just pushed" message (a webhook is a small automatic notification one service sends another). Your app redeploys within moments of the push.
  • Polling — if there's no public address for GitHub to reach, The Deployer instead checks your branch regularly for new commits and redeploys when it spots one. It's a little less instant, but it works from anywhere, behind any firewall.

You don't choose between them — whichever fits your setup just works.

Every trigger is labelled

However an update starts, it's recorded in the Activity card with a TYPE chip so you always know what kicked it off:

ChipWhat triggered the deployment
ManualYou clicked deploy or Pull & Restart
PushA code push, delivered by the GitHub webhook
AutoThe Deployer spotted a new commit while polling
EnvYou changed an environment variable
DomainYou added or changed a domain

You can search and filter these — see searching & filtering your activity.

How your app stays up during an update

For apps running on your own servers, a redeploy (manual or automatic) is a health-gated rolling update: The Deployer starts the new version of each service beside the old one and only switches visitors over once the new version passes its health check. If the new version fails that check, the old one keeps serving. There's nothing for you to configure.

This applies to redeploys of an app that's already running. On managed hosting (such as App Platform, Cloud Run or a static-site CDN) the provider's own rollout applies instead. Some changes, such as database or infrastructure changes and resizing a single server, can still cause a short outage.