Deployments
Deploy a Git application by hand, read the deploy history and build logs, edit the deploy script, and deploy automatically on push.
Deployments only exists for applications created from a Git repository. It is the screen that pulls new code onto the server, runs the build, and records what happened.
Deploy now
The card at the top is the whole manual flow: press Deploy now, and the panel checks out the branch, runs the deploy script, and checks that the application still answers.
The strip underneath is the current state — repository, branch, Live commit (with a link out to it), and when the last successful deploy was.
A deploy is a reset, not a merge
The panel says it on the card: "Deploying resets the application to the main branch; changes made directly on the server are discarded." Anything you edited in Files inside the repository is gone on the next deploy.
When a deploy fails
A failed deploy leaves the application in a half-updated state, and the panel says which half:
Last deploy failed at "Checking the application responds". The last deploy failed after the new code was put in place, so the site is running commit
b659733, which is not fully deployed. Fix the problem and deploy again.
View the error log opens the build log for that attempt, and the
Live commit gets a Not fully deployed badge until a deploy succeeds.
The commonest cause of that particular failure is a web root that does not
point at what the build produced — a dist/ or public/ directory rather
than the repository root. Change it from … → Change web root on the
dashboard.
History
Every deploy is listed newest first, with its commit, branch, trigger (First deploy, Manual, or the webhook), who started it, and how long it took. Open one to read its build log. Deploy again on a row redeploys.
Settings
Branch is the branch each deploy checks out.
Deploy script is the commands that run after checkout. Until you edit it,
the panel shows the default it would run for this application's rendering type
— for a Node build, npm ci then npm run build --if-present. Editing it
makes it yours; Reset to default gives it back.
The script can use placeholders, listed under the editor with their values for this application:
| Placeholder | Example value |
|---|---|
{path} | /home/demo-app/demo-app/public_html |
{branch} | main |
{domain} | demo-app.example.com |
{php} | /usr/bin/php8.4 |
{PHP84} | /usr/bin/php8.4 |
Deploy on push
Turning Deploy on push on makes a push to the deploy branch trigger a deploy. How it is wired depends on where the repository came from.
With a connected Git account, the panel adds the webhook to the repository for you.
With a public repository URL it cannot — it has no credentials for your repository — so it gives you the two values to paste in yourself:
Copy the Webhook URL — it is an /api/webhooks/deploy/<id> address on your
server's API host.
Copy the Secret. It is masked on screen; use the copy button rather than reading it.
In the repository, open Settings → Webhooks → Add webhook. Paste the URL,
set Content type to application/json, paste the secret into Secret,
and select Just the push event.
Last delivery then tells you whether the hook is actually arriving, and Rotate secret issues a new one if it leaks.
Signature-verified, not secret-URL
The Verified by signature badge means the panel checks the signature GitHub sends with each delivery. A request to the URL without a valid signature is refused, so the URL alone cannot trigger a deploy.
One deploy per burst
Pushes arrive in bursts — a branch merge can fire several webhook deliveries within seconds — and the panel deliberately does not run a deploy per delivery. At most one deploy waits behind the one that is running; every further trigger, whether a webhook or a Deploy now you press yourself, joins that waiting deploy instead of queueing its own.
Nothing is lost by that. The waiting deploy fetches the tip of the branch at the moment it starts, so it deploys the newest commit, not the one that happened to trigger it. Ten pushes make one deploy, of the tenth.