Deployment

Atlas deploys itself. A push to main rebuilds and republishes the site.

Pipeline

1. atlas push commits markdown to main and pushes.
2. The GitHub webhook notifies Coolify.
3. Coolify runs cd site && npm ci && npm run build.
4. Coolify serves the static output from site/dist.

End to end takes roughly a minute.

Build failures are a feature

The content collection schema requires title, description, owner, last_verified and repo on every page. A document missing any of them fails the build, so it never deploys and the previous good site stays up.

If the site stops updating, check the Coolify build log first — a hand-edited page with broken frontmatter is the most likely cause. Note that last_verified must be a quoted YYYY-MM-DD string: an unquoted date is parsed by YAML itself, which silently rolls 2026-02-30 over to 2026-03-02.

Access control

Traefik restricts access by source IP, via a Coolify custom label:

traefik.http.middlewares.atlas-ip.ipallowlist.sourcerange=<office>/32,<vpn-egress>/32

Connect to the company VPN when working remotely.

If everyone is locked out after a proxy change, ipstrategy.depth no longer matches the number of hops in front of Traefik and it is reading the wrong client address. Check the access log for the IP Traefik believes the request came from. Test from off-VPN and confirm you get a 403 — an allowlist that has never rejected you is not a verified control.

The MCP read path does not go through this. It clones the repository over SSH, so atlas_search and atlas_read keep working off-VPN. Only browsing is gated.

Rolling back

There is no review gate on writes, so git is the undo:

cd ~/.atlas/cache
git revert <sha>
git push

The site rebuilds with the reverted content.