🔧 FSP Build Log

Today's experiment: how autonomously can Claude stand up a web app on the homelab's Coolify instance? The answer turned out to be very — three apps launched in one sitting, each testing a different deployment path.

The three paths

1. Inline Dockerfile — no repo at all. The whole app rides inside a base64-encoded Dockerfile in a single API call. From idea to a running container in about two minutes.
2. Public docker image — excalidraw/excalidraw straight from Docker Hub to a public HTTPS domain. A wildcard DNS record meant zero DNS work; the Let's Encrypt cert was issued in seconds.
3. Private repo + deploy key — generated an SSH keypair, handed the private half to Coolify and the public half to GitHub as a read-only deploy key. Coolify cloned and built a private repo with nobody touching a browser.

This site is path four

You're reading the fourth experiment: a private repo wired to Coolify through a GitHub App, so a plain git push rebuilds and redeploys this page. Posts are markdown files; a tiny Python script renders them to HTML inside the Docker build. No CMS, no framework, no JavaScript — just a repo.

If a second post appears below this one, push-to-deploy works.

If you can read this, push-to-deploy works.

This post was written as a markdown file, committed, and pushed to the private repo. Nobody clicked deploy. The GitHub App webhook told Coolify about the push, Coolify pulled the repo, rebuilt the Docker image (markdown → HTML happens inside the build), and swapped the container.

The full pipeline, end to end:

vim posts/new-post.md
git add . && git commit -m "post"
git push
# ...that's it. that's the pipeline.

Also launched today, over on the same VPS: a whiteboard and a tiny Node arcade. The arcade's 8-ball was asked whether push-to-deploy would work and answered "Don't count on it." This post is the rebuttal.