Start
Deploy on every push
Connecting a repository lets DeployMate download your code. It does not make your git host tell DeployMate when you push. For that you add a webhook to the repository: one entry, pointing at your dashboard, once per repository. After that, every push to the app's branch builds and deploys by itself.
Without a webhook nothing is broken — you just deploy by pressing Deploy.
1. Get the two values
On the app, open Settings → Source & build. Under the connected repository you'll find:
| Webhook URL | Shown as https://your-host/hooks/<id>. Replace your-host with the address you use for the dashboard, for example https://dash.example.com/hooks/<id>. The dashboard must be reachable from the internet at that address. |
|---|---|
| Webhook secret | A random string. It proves a delivery really came from your git host, so keep it private. Rotate secret makes a new one. |
2. GitHub
- In the repository open Settings → Webhooks → Add webhook.
- Payload URL: the webhook URL from step 1.
- Content type:
application/json. - Secret: the webhook secret.
- Which events: choose Let me select individual events and tick only Pushes. For a prebuilt app tick Workflow runs instead (a push is ignored for those, because the deploy waits for the build to finish).
- Press Add webhook. GitHub immediately sends a test; the entry should get a green tick.
GitLab and Gitea
GitLab: Settings → Webhooks. Put the URL in URL and the secret in Secret token, and tick Push events. Gitea: Settings → Webhooks → Add → Gitea, the same fields as GitHub with the content type JSON and push events.
What happens on a push
- Only pushes to the app's tracked branch deploy; pushes to other branches are ignored.
- Each delivery is checked against the secret first. A wrong or missing signature is rejected before anything runs.
- A delivery GitHub sends twice is recognised and deployed once.
- The deployment appears in the app's history, triggered by webhook, with the usual build log.
- Each app has its own webhook. If several apps are built from one repository, a push deploys only the apps whose build folder it changed (set under Settings → Source & build). A skipped push shows in the app's activity as “Push skipped”. Apps built from the repository root deploy on every push, and so does a push whose file list GitHub or GitLab didn't send (very large pushes).
Dashboard behind a login or a tunnel
Your git host has to be able to reach /hooks/… without signing in. If you've put the dashboard behind Cloudflare Access (a good idea), add a second Access application for the same hostname with the path hooks/* and a Bypass policy for everyone. Only that path is opened; the rest of the dashboard stays locked, and each webhook is still verified by its secret. The same applies to any proxy or VPN that asks visitors to authenticate.
If a push doesn't deploy
In GitHub, the webhook's Recent Deliveries tab shows what DeployMate answered for every delivery:
| Answer | Meaning |
|---|---|
queued (200) | It worked: a deployment was queued. Look in the app's Deployments tab. |
pong | The test ping arrived. The address and secret are right. |
ignored: not the deploy branch | You pushed another branch. Check the branch on the app matches. |
ignored: not a push event | The webhook sends events DeployMate doesn't use; for a normal app, tick only Pushes. |
ignored: this app deploys from CI runs, not pushes | The app is in prebuilt mode: tick Workflow runs on the webhook. |
bad signature (401) | The secret in GitHub doesn't match. Copy it again from the app, or rotate it and paste the new one. |
| A login page, 302, 403 or a Cloudflare page | Something in front of the dashboard is blocking the request. See the section above. |
| 404, or no response at all | Wrong address or id, or the dashboard isn't reachable from the internet. Open the URL's host in a browser to check. |
You can press Redeliver on any delivery to replay it after fixing the cause.