Deployment history
Every build of this server, with its result and duration.
The server asks the repository once a minute and acts only after it has been still for two minutes, so a burst of pushes becomes one build. Nothing is configured on GitHub for this.
0 builds recorded
No builds recorded yet.
Pick a deployment on the left to read its log.
Why the history lives in the database
A failed build stops being a moment. Every press of Deploy is recorded in your project's database, not in a file the next restart forgets. The log is still there tomorrow, after a reload, after a restart of the panel — you do not have to reproduce a failure to read its cause again. And because it lives in the same storage as the rest of your data, an agent can query “what happened on the last five deploys” instead of investigating.
What the three modes cost. Manual — nothing happens without your button. Pull only — the server fast-forwards to the repository; content and pages apply at once, code waits for your Deploy. Pull and deploy — the server pulls and builds, the way a hosting platform does. The difference matters because this server builds on the same machine that serves your visitors: a build competes with the site for the processor.
It refuses rather than improvises. If this server holds uncommitted changes, if the histories have diverged, or if a build is already running, the turn is skipped and the reason appears above. Only a clean fast-forward is taken automatically — your work is never buried to make room.
Why it is off by default. On a project serving real customers, letting a build start by itself is a decision to make deliberately rather than inherit. So the default is Manual, and turning it on is one press with the cost stated.