SupportConsole
llms.txtSign in

Deploy automatically on every push

llms.txt

With push to deploy on, you stop pressing Deploy now. You push to the configured branch, your git host tells SrvYard, and SrvYard deploys the new commit. The connection is a webhook that SrvYard registers on your repository for you, signed with a secret only the two sides know, so strangers cannot trigger deployments.

This article shows where the switch is, what exactly happens behind it, which pushes are ignored on purpose, how a burst of pushes is handled, and how to check that deliveries arrive. If your repository is not on a connected provider, or you deploy from CI, the deploy hook is the alternative.

Before you begin

  • A repository on a connected provider. Push to deploy works for repositories you chose through a Git provider connection (GitHub, GitLab or Bitbucket). A Custom Git URL has no connection through which SrvYard could create a webhook. See Connect a repository and pick a branch.
  • A token that may manage webhooks. For GitHub the connection needs the repo and admin:repo_hook scopes. A token without them makes the switch fail with the provider's message in a toast.
  • A working deployment first. Run Deploy now once and check the log before you automate. See Write and test a deploy script.
  • Permission to manage deployments. Owners and admins have it.

1. Switch push to deploy on

The switch appears in two places, and both are the same setting. The quickest is on the Deployments tab.

The Source card with the Push to deploy switch
The switch is on the Deployments tab and in the settings.
  1. Push to deploy. Turn it on. The text under it names the branch: "Deploy automatically when main receives a push." The switch is disabled with "Connect a repository first." when the site has no repository.
  2. Branch. The branch that triggers deployments. Pushes to any other branch are ignored. Change the branch in the repository settings.

The same switch is in Settings > Deployments, above the deploy hook address.

The Push to deploy and Deploy hook URL cards
In Settings the switch sits above the deploy hook address.
  1. Push to deploy. "Turning it off removes the webhook." The toast says "Push to deploy is on." or "Push to deploy is off."
  2. Deploy hook URL. Not part of the webhook. It is the other trigger, for scripts and CI.

When you switch it on, SrvYard registers a webhook at your git host that points to a SrvYard address of the form /hooks/push/<site>, listens for push events only, and stores a per-site secret. If a webhook from an earlier registration exists it is replaced, so there is never more than one. Switching it off deletes the webhook at the git host; if that fails you get a warning toast and the switch still turns off.

2. See how the site is connected

Settings > Integrations summarises the connection.

The Integrations section
The Integrations section shows how the site is connected to the git host.
  1. Push to deploy. On or Off.
  2. Push webhook. Whether SrvYard holds a registered webhook for the site: Registered or Not registered. After you switch push to deploy on with a working connection it should read Registered. The demo organisation uses fictional tokens, so it shows Not registered even though the switch is on.

The card also lists the source control connection, the repository and the GitHub deployments setting. "Change these under Deployments."

3. What happens on a push

  1. You push to the branch. Your git host sends a request to SrvYard.
  2. SrvYard checks the signature. GitHub signs the body (X-Hub-Signature-256), GitLab sends the secret in a header and Bitbucket in the webhook address. A request that fails the check is rejected with 401 before anything else is read.
  3. The test pings your git host sends when a webhook is created are answered without deploying.
  4. SrvYard ignores the request, with a short explanation, when push to deploy is off, when the push is not to the site's branch, or when the push deletes a branch.
  5. Otherwise it queues a deployment with the trigger Push. The deployment appears in the history at once.
A deployment started by a push
A push deployment names the commit and says it was triggered by Push to deploy.
  1. Triggered by. Push to deploy. The history table shows the same as Push in the Trigger column.
  2. Hash. The commit that was deployed. Together with the commit message and author, this is what your git host sent and what SrvYard fetched.

Filter the history to see only automatic deployments:

The Trigger filter
Filter the history by what started each deployment.
  1. Trigger. Choose one or more of Manual, Push, Hook, Api and Rollback. Hook is the deploy hook and Api is a deployment queued through the API.

4. Bursts of pushes and a busy site

A site never runs two deployments at the same time. If one is running when a push arrives, the new deployment waits as Queued and starts when the first ends. If a push arrives while an earlier push, hook or API deployment is already waiting, SrvYard does not queue another: the waiting one will fetch the branch tip when it starts, so it already includes the new commit. Ten quick pushes therefore cost at most two deployments, not ten.

SrvYard always deploys the latest commit of the branch at the moment the deployment starts, not the commit that triggered it. If someone pushes a fix while a deployment is queued, the fix goes out too.

A push is refused with a 409 when the site cannot deploy at all: it is not ready, its server is not ready, it has no repository or its deploy script is empty. The message is in the response; the deployment history shows nothing.

Tip

If you do not want every merge to go live, push to a branch that is not the site's branch, for example staging, and create a second site on that branch.

5. Confirm that deliveries arrive

  1. Make a small commit on the branch and push it.
  2. Open the site's Deployments tab. A row with the trigger Push should appear within a few seconds.
  3. If nothing appears, open the webhook list at your git host (for GitHub: the repository's Settings > Webhooks). It shows each delivery and the response SrvYard gave: 202 is accepted, 401 is a wrong secret and 404 means the site no longer exists.
Note

The push endpoint accepts at most 60 requests per minute per address. A git host that delivers thousands of events at once (a mass import) can hit that limit; the deliveries show a 429 response and can be redelivered from the git host.

Troubleshooting

  • The switch fails with a toast. The message comes from the git host: usually "Not Found" or "Resource not accessible", meaning the token lacks admin:repo_hook. Reconnect with a token that has it. Push to deploy "needs a repository on a connected GitHub, GitLab or Bitbucket account".
  • I push and nothing happens. Check the branch (the push must be to the site's branch), that the switch is on, and the delivery list at your git host.
  • Deliveries show 401. The secret no longer matches, for example after the webhook was re-created at the git host by hand. Turn push to deploy off and on again to register a fresh one.
  • Deliveries show 202 with "ignored". The response says why: push to deploy is off, or it was not a push to the site's branch.
  • A deployment appears but fails straight away. It is a normal deployment failure. Read the log: Read a deployment log and find the failing step.
  • Two pushes made one deployment. That is the queue rule in step 4: the waiting deployment covers both commits.
  • I switched push to deploy off but the webhook is still at GitHub. SrvYard could not delete it and showed a warning. Delete it by hand in the repository's webhook settings.
Last updated 2026-10-247 min readNeed help? Contact support
PreviousWrite and test a deploy scriptNextDeploy without downtime and roll back to an earlier release