To test the GitHub integration in DirectAdmin, we built something real: a status page for a hosting brand. Static, no build step, with the status in a JSON file. The question: how quickly is a change live after git push?
The setup
- Subdomain created with DNS, SSL and its own folder.
- Repository on GitHub with
index.html,styles.css,app.jsandstatus.json. - Connected through the GitHub tab in Invoker Link: enter the repository, add the deploy key, branch
main, the website itself as the target. - Webhook on GitHub, push event.
Reporting an incident works like this: edit status.json and push. The page reads that file and shows the status per service. The page measures load time and response time live in the visitor's browser.
The measurement
We changed the "updated" timestamp in status.json, pushed, and requested the file from the live website every three seconds.
LIVE after 3s: 2026-09-14T22:22:49+02:00
On GitHub the delivery showed status 204. No deploy button, no FTP, no build server.
What happens in those 3 seconds
- After the push, GitHub sends a webhook to the server.
- DirectAdmin fetches the new commits into its own copy of the repository.
- The branch's files are placed in the subdomain's folder, without a
.gitfolder.
We wrote up how DirectAdmin does that technically in DirectAdmin Git API.
What went wrong along the way
Not everything worked the first time, and that's exactly why we test it ourselves.
The subdomain wasn't listed. DirectAdmin's Git feature only works on main domains. Because of that, the status page first ended up in the domain's main folder instead of on the subdomain. The fix: register the repository under the main domain, with the subdomain as the target folder.
A real homepage was mistaken for a default page. To keep DirectAdmin's placeholder page out of the way, the integration moved every index.html aside. Including a real page that was already there. It was safely kept and back within a few minutes, but it shouldn't have happened. Now only DirectAdmin's own placeholder counts as empty, and files that would be overwritten are saved first.
A deploy key with write access. When adding it on GitHub, "Allow write access" was on. Reading is enough for deploying. The guide now says so more clearly.