거의 완전한 자체 호스팅 샌드박스형 AI 소프트웨어 공장 구축기

Building an (almost) fully self-hosted, sandboxed, agentic software factory I built an (almost) fully self-hosted, sandboxed, agentic software factory. tl;dr: It worked! From one prompt it created a repo, wrote the application and tests, got CI green, provisioned Postgres and deployed the finished app behind HTTPS without another message from me.If you just wanna see the outcome you can find a demo video at the bottom LLMs got fun again! Maybe they always were and I was just stuck in the trough of disillusionment. Lately, whenever I need a little tool, I just build it. I was in the gym the other day and wanted a weights tracker. The app I had in mind was about as CRUD-y as it gets, but all the app store versions wanted £12 per month, so I just one-shotted one with Claude. Great fun, but giving an LLM root access to my machine in auto mode still doesn’t sit right with me. So, the challenge: how can I create a fully remote agentic development environment where we structurally contain the LLM rather than just trusting it? I want to give it an instruction and have it autonomously move through the whole SDLC: Researching the right stack and packages to use. Planning and writing the code and tests. Committing to Git, building and running a CI pipeline. Deploying the work to a ‘production’ server with databases, o11y, and a domain with SSL. All on my home server, without another cloud infrastructure bill. The only ongoing cost specific to this experiment is a £20 Codex sub. The Server(s) Here they are in all their glory. The one at the bottom is a 2014 dual-core i3 I’ve been running as a homelab for five years. It’s valiantly hosting this blog and about 45 other Docker containers, from Pi-hole to a full Prometheus / Loki / Grafana stack. It also has port 443 forwarded from my router. I’d be miffed if an LLM broke it, so that’s not what we’re using today. The top one is a 2021 10th-gen i7 with 32GB RAM, bought fresh from eBay with nothing on it. Perfect. The Stack The core development stack is self-hosted through Coolify. Inference and integrations like Tailscale, Telegram, DNS and ACME still leave the box. You could host inference too, but I don’t have the hardware and I’d rather OpenAI subsidise my experiments. Component Notes Pi-hole Local DNS rules, with the side benefit of seeing less shitty advertising. Tailscale Makes my home network follow me around. Coolify A self-hosted, Heroku-style PaaS built on Docker. Forgejo (with runners) Self-hosted Git and CI. Hermes (with WebUI) An OpenClaw-style virtual assistant, using Codex for inference. Telegram Talk to the agent from the toilet or wherever. Firecrawl (self-hosted) A scraping / translation layer between the agent and the web. Porkbun (Registrar) & Let’s Encrypt A domain and on-the-fly SSL certificates. Whatever else Postgres, Redis, whatever your apps need. It’s just Docker under the hood, innit? Sources This isn’t a full how-to guide. I could probably write an Ansible one-shot script to set it all up; leave an issue on the GitHub repo below if you’d like one. If you’ve read this far, though, you can probably figure it out. Source Notes Coolify Setup Blog My Coolify-on-Hetzner setup guide. Coolify Dockerfiles Production Dockerfiles that actually work on Coolify. Just add env vars. Forgejo Hermes Skill A Hermes skill for the Forgejo CLI; just provide a key. Networking The first guardrail is obvious: it’s on its own metal. Hermes could rm -rf / and at worst it would cost me a couple of hours rebuilding it. The next layer of bombproofing is the network. My older server has port 443 forwarded from the router; this one doesn’t. There’s no external ingress, cutting out a huge attack surface and all the internet background radiation from people speculatively probing /wp-admin on every DNS A record I set up. But, if there’s no ingress, how do I: Get access to all our cool new apps on my phone? Generate an SSL cert at a vanity URL so I can access https://cool-new-app.internal.jakeshomelab.me ? I have Tailscale set up with my older server as an exit node. When I’m away from home, selecting it routes my traffic through that server and Pi-hole, which I’m using for custom DNS. Pi-hole lets you add dnsmasq rules like this: address=/internal.jakeshomelab.me/192.168.1.201 Anything requesting *.internal.jakeshomelab.me now resolves to my new server, where Coolify’s reverse proxy picks it up and serves my shiny new services. SSL Certs With Caddy or Traefik and Docker labels, you can serve port 3000 on container X from https://my-service.internal.jakeshomelab.me . Point an A record at the server and it’ll contact Let’s Encrypt, complete an ACME challenge and get an SSL cert. I learned this three years ago and it still seems like magic. The problem is the A record. I don’t want to publicly associate my-service.internal.jakeshomelab.me with my IP, whether people can access it or not. I want an SSL cert for a ghost service. To solve this problem, I turned to DNS-01. I’ll be honest this is new to me, but here’s how it works: Buy a domain (in this case from Porkbun). Generate Porkbun API keys and add them to Coolify’s environment with write access to the domain. Modify Coolify’s Docker Compose file to use lego and the Porkbun API: - '--certificatesresolvers.letsencrypt.acme.dnschallenge=true' - '--certificatesresolvers.letsencrypt.acme.dnschallenge.provider=porkbun' - '--log.level=INFO' Then, when I register a new URL, Traefik / Coolify: Uses the Porkbun API to create a new TXT record at _acme-challenge.my-service.internal.jakeshomelab.me . Let’s Encrypt validates the challenge and issues a valid SSL cert. Traefik deletes it. That’s it! You now have a valid HTTPS URL, reachable within your tailnet, with no public A or AAAA record pointing to the service. The hostname may still appear in public certificate-transparency logs, but the service is only reachable from the tailnet. The best bit is that Coolify does this on the fly. Our agent can create a service at any subdomain and it’ll ✨magically✨ sort itself out. So, glue all this together and you get the following: The same setup covers the tooling, so Coolify, Hermes, Forgejo and Firecrawl all live on their own local subdomains. Development Stack & MCPs Now we have an isolated(ish) box, let’s move on to the tooling. The tools are well known; gluing them together is the fun part. Forgejo We need somewhere durable to store code and run CI. I decided not to use GitHub because: Giving the box my GitHub token rather undermines the isolation. Also, it’s not self-hosted. Its API and CI minute limits won’t work at the scale of our new software factory. It’s down most of the time these days anyway. Forgejo is a great self-hosted alternative. The Docker Compose file linked above sets up Forgejo and its runners; registering yourself and the runner takes a little extra work, but it’s well documented. I’ve also included a Compose file for syncing projects back to GitHub. That puts your GH token in the environment, but the trade-off is yours to make. The Forgejo Hermes skill linked above gives the agent full control of the instance. Hermes Hermes is an OpenClaw-style personal assistant with agentic capabilities. I never got in on the OpenClaw hype, so I can’t compare the two, but Hermes has a few features I’ve found handy: Web UI : A standard ChatGPT-esque interface for working from my laptop and managing skills. Shared filesystem : I’ve mounted its workspace from the Docker host and shared it over Samba. The agent and I can use the same files instead of copy-pasting Markdown and code around. Telegram integration : I can chat to the agent from my phone. Setup took two minutes and required no login details, which suited the sandbox approach. Self-