AI News
商业产业 Hacker News LLM 2026-08-21T16:27 正文 ok 2082 words

🔶 构建一座（几乎）完全自托管、沙箱化的 Agent 软件工厂

英文标题：🔶 Building an (almost) fully self-hosted, sandboxed, agentic software factory

作者在一台独立的家用服务器上搭建了一个近乎完全自托管的 Agent 开发环境，并让 Hermes 通过 Codex 推理自主完成从需求到部署的完整软件生命周期。一次提示后，Agent 创建了 Git 仓库，编写 SvelteKit、Drizzle、Postgres 和 Tailwind 应用及测试，配置 CI，并将应用以 HTTPS 部署到内部域名。该方案以 Coolify、Forgejo、Firecrawl、Tailscale、Pi-hole 和 DNS-01 证书验证为核心，在不开放公网入口的情况下提供内部 HTTPS 服务。作者强调，这种隔离并不意味着安全无风险：Agent 仍可能破坏服务器、泄露凭据或消耗大量推理额度，因此 VLAN 隔离、最小权限、备份和关键操作审批仍是下一步重点。
打开原文相关 3 · 机会 0
media15.0 KB media588.3 KB media1.1 MB media757.6 KB media101.8 KB media1.7 MB media564.4 KB media307.7 KB media159.7 KB media119.2 KB media48.4 KB media250.8 KB media106.5 KB media1.1 MB

中文

简而言之：成功了！只凭一条提示，它就创建了一个仓库，编写应用和测试，让 CI 变绿，配置 Postgres，并在 HTTPS 后部署了完成的应用——期间我没有再发任何消息。如果你只想看最终结果，可以在文末找到演示视频。

LLM 又变得好玩了！也许它们一直都很好玩，只是我此前陷在了幻灭低谷里。最近，只要我需要一个小工具，我就直接自己做一个。

前几天我在健身房，想要一个重量训练记录器。我设想中的应用几乎就是最典型的 CRUD 应用，但应用商店里的版本都要每月 12 英镑，所以我直接用 Claude 一次性生成了一个。很有趣，但让 LLM 在自动模式下拥有我机器的 root 权限，还是让我觉得不太妥。

所以，挑战来了：如何创建一个完全远程的 Agent 开发环境，让我们从结构上约束 LLM，而不只是选择信任它？我希望给它一条指令，并让它自主完成整个 SDLC：

  • 调研合适的技术栈和软件包。
  • 规划并编写代码与测试。
  • 提交到 Git，构建并运行 CI 流水线。
  • 将成果部署到一台带有数据库、o11y 和 SSL 域名的“生产”服务器。

全部运行在我的家庭服务器上，不再增加任何云基础设施账单。这次实验唯一的持续专属成本是一份每月 20 英镑的 Codex 订阅。

服务器

服务器

它们全都在这里了。

底下那台是一台 2014 年的双核 i3，我已经把它作为 homelab 运行了五年。它顽强地托管着这个博客以及大约 45 个其他 Docker 容器，从 Pi-hole 到一整套 Prometheus / Loki / Grafana 栈。它还通过我的路由器转发了 443 端口。如果 LLM 把它搞坏了，我会相当恼火，所以今天我们不用它。

上面那台是一台 2021 年的第 10 代 i7，配备 32GB RAM，从 eBay 买来时是全新空白状态。完美。

技术栈

核心开发栈通过 Coolify 自托管。推理以及 Tailscale、Telegram、DNS 和 ACME 等集成仍会离开这台机器。你也可以托管推理，但我没有相应硬件，而且我更愿意让 OpenAI 补贴我的实验。

组件 说明
Pi-hole 本地 DNS 规则，顺便还能让我少看到些糟糕广告。
Tailscale 让我的家庭网络跟着我到处走。
Coolify 基于 Docker 构建的、自托管的 Heroku 风格 PaaS。
Forgejo（含 runners） 自托管 Git 与 CI。
Hermes（含 WebUI） 一款 OpenClaw 风格虚拟助手，使用 Codex 进行推理。
Telegram 无论是在厕所还是其他地方，都可以和 Agent 对话。
Firecrawl（自托管） Agent 与 Web 之间的抓取 / 翻译层。
Porkbun（注册商）和 Let’s Encrypt 域名及按需签发的 SSL 证书。
其他任何东西 Postgres、Redis，以及你的应用所需的任何组件。底层不就是 Docker 吗？

资源

这不是一篇完整的操作指南。我大概可以写一个 Ansible 一键脚本来完成全部设置；如果你希望有一个，请在上方链接的 GitHub 仓库中提交 issue。不过，如果你已经读到这里，应该也能自己摸索出来。

网络

第一道护栏显而易见：它运行在独立的物理机器上。Hermes 可以执行 rm -rf /，最坏的结果也只是我花几个小时重建它。

下一层防护是网络。我的旧服务器在路由器上转发了 443 端口；这台新服务器没有。它不存在外部入站流量，由此砍掉了巨大的攻击面，也避开了互联网背景噪声——那些人总会对我设置的每条 DNS A 记录投机性地探测 /wp-admin。

但是，如果没有入站访问，我要如何：

  • 在手机上访问所有酷炫的新应用？
  • 在一个自定义 URL 上生成 SSL 证书，以便访问 https://cool-new-app.internal.jakeshomelab.me？

我设置了 Tailscale，并将旧服务器作为出口节点。离开家后，选中它会让我的流量经过那台服务器和 Pi-hole；我正用 Pi-hole 配置自定义 DNS。Pi-hole 允许你添加如下 dnsmasq 规则：

address=/internal.jakeshomelab.me/192.168.1.201

现在，任何请求 *.internal.jakeshomelab.me 的流量都会解析到我的新服务器，Coolify 的反向代理会接收该流量并提供我闪亮的新服务。

SSL 证书

借助 Caddy 或 Traefik 以及 Docker labels，你可以将容器 X 上的 3000 端口服务通过 https://my-service.internal.jakeshomelab.me 提供出去。只要把一条 A 记录指向服务器，它就会联系 Let’s Encrypt，完成 ACME 挑战并获取 SSL 证书。我三年前学到这件事时觉得像魔法，现在依然如此。

问题在于 A 记录。我不想让 my-service.internal.jakeshomelab.me 与我的 IP 公开关联——无论人们能否访问它。我想为一个幽灵服务获得 SSL 证书。

为了解决这个问题，我转向了 DNS-01。坦白说，这对我来说也是新东西，但它的工作方式如下：

  • 购买一个域名（本例中来自 Porkbun）。

  • 生成 Porkbun API 密钥，并将其添加到 Coolify 的环境中，使其拥有该域名的写入权限。

  • 修改 Coolify 的 Docker Compose 文件，使用 lego 和 Porkbun API：

      - '--certificatesresolvers.letsencrypt.acme.dnschallenge=true'
  - '--certificatesresolvers.letsencrypt.acme.dnschallenge.provider=porkbun'
  - '--log.level=INFO'

然后，当我注册一个新 URL 时，Traefik / Coolify 会：

  • 使用 Porkbun API 在 _acme-challenge.my-service.internal.jakeshomelab.me 创建新的 TXT 记录。
  • Let’s Encrypt 验证挑战并签发有效的 SSL 证书。
  • Traefik 删除该记录。

就是这样！现在你拥有一个有效的 HTTPS URL，可在你的 tailnet 内访问，并且没有任何公开的 A 或 AAAA 记录指向该服务。主机名仍可能出现在公开的证书透明度日志中，但该服务只能从 tailnet 访问。

最棒的是，Coolify 会动态完成这些操作。我们的 Agent 可以在任意子域名创建服务，它都会✨神奇地✨自行处理。

因此，把所有这些拼在一起，你会得到下面这个架构：

网络图（抱歉，有点 AI 味）

相同的设置也覆盖工具本身，因此 Coolify、Hermes、Forgejo 和 Firecrawl 都运行在各自的本地域名上。

开发栈与 MCP

现在我们有了一台相对隔离的机器，接下来看看工具。工具本身众所周知；把它们组合起来才是有趣的部分。

Forgejo

我们需要一个持久化存储代码并运行 CI 的地方。我决定不使用 GitHub，因为：

  • 把 GitHub token 交给这台机器，基本上削弱了隔离效果。而且，它也不是自托管。
  • 它的 API 和 CI 分钟数限制无法满足我们这座新软件工厂的规模。
  • 反正如今它大部分时间都处于宕机状态。

Forgejo 是一个很棒的自托管替代方案。上方链接的 Docker Compose 文件会设置 Forgejo 及其 runners；注册账户和 runner 还需要一点额外操作，但文档写得很完善。

我还附上了一个用于将项目同步回 GitHub 的 Compose 文件。这样会把你的 GH token 放入环境变量，但是否接受这一权衡由你决定。

上方链接的 Forgejo Hermes skill 让 Agent 能完全控制该实例。

Hermes

Hermes 是一款具备 Agent 能力的 OpenClaw 风格个人助手。我没有赶上 OpenClaw 的热潮，因此无法比较两者，但 Hermes 有几个我觉得很实用的功能：

  • Web UI：一个标准的、类似 ChatGPT 的界面，用于从笔记本电脑工作和管理 skills。
  • 共享文件系统：我从 Docker 主机挂载了它的工作区，并通过 Samba 共享。Agent 和我可以使用同一批文件，而不必在各处复制粘贴 Markdown 和代码。
  • Telegram 集成：我可以通过手机与 Agent 交谈。设置只花了两分钟，也不需要登录信息，这很符合沙箱方案的思路。
  • 自建 skills：Hermes 可以创建并注册自己的 skills。我找不到一个好用的 Coolify skill，所以它阅读了文档，查看 MCP，并自己构建了一个。
  • Firecrawl：自托管 Firecrawl 能让 Agent 更方便地访问 SERP 数据，并大规模抓取网页。

让 Hermes 和 Firecrawl 在正确的位置配置正确的密钥，简直麻烦透顶。我已将适用于 Coolify 的 Docker Compose 文件加入上方链接的仓库。

Hermes 正在努力为这篇博客文章构建演示 Web 应用。

Coolify

Coolify 是将这些东西粘合在一起的核心：这是一个基于 Docker 和 Compose 的自托管 PaaS，每次更新都进步飞快。如果你想在自己的硬件上拥有 Heroku 或 DigitalOcean App Platform 的便利功能，我强烈推荐它。

我最喜欢的一些功能包括：

  • 底层就是 Docker。现有部署大多能直接运行；如果 Coolify 无法处理某些奇怪需求，你可以从笔记本电脑执行 docker exec <whatever>。只有在你希望时，东西才会被抽象隐藏起来。
  • 我在上文深入介绍过的 SSL / 路由栈。
  • Coolify 附带了一系列最常见应用的预制 recipes。Postgres、Redis、Hermes、Forgejo，以及几乎所有其他东西，都可以一键部署。
  • 将 Postgres 备份至 S3 只需三次点击，环境变量和用户管理也都内置。
  • GitHub webhooks 可在推送至 main 分支时自动部署。

下面是我的 Coolify 设置实际运行时的几张截图：

Coolify 中的工具页面

Firecrawl 服务与 Docker Compose

它实际上做了什么

下面的演示已经很好地说明了这一点，不过发令枪是下面这条提示：

Please build me an app for tracking my calorie intake. It should be similar to MyFitnessPal but with a form to
add specific food and meals for quick selection later.

Your task is to build it, commit it to a new repo with tests, test it with CI, and deploy it to
http://calories.internal.jakeshomelab.me.

I’d like it to be a full stack svelte kit app with Drizzle and Postgres for the database layer.
I’d like tailwind for the CSS. It should be mobile first.

For deployment, please use docker and docker compose and deploy your own Postgres instance.

从那以后，它就自己开始干活了：

  • 创建一个新的 Git 仓库，并初始化 SvelteKit、Drizzle、Postgres 和 Tailwind。
  • 编写应用及其测试，并分阶段合理地提交工作。
  • 创建 CI 流水线。
  • 持续处理测试失败，直到 CI 变绿。
  • 使用 Docker Compose 将应用及其独立的 Postgres 实例容器化。
  • 将所有内容部署至 Coolify 上的独立 URL。

整个过程没有一条额外提示。没有在测试失败时引导它，也没有把错误信息复制回聊天框。它只是持续推进，直到应用运行起来。

那时我试用了一下，在提交数据时遇到 CSRF 问题。我又发了一条提示；它诊断了问题、修复了问题、添加了回归测试，并重新部署。

而且，成功了！

这就是我想要的闭环：提示、仓库、代码、测试、CI、部署、修复 bug。显然，这不是一个复杂应用，但它从一段文字变成了经过测试、已经部署的软件，并处理了中间所有枯燥的工作。这仍然让我感觉有点像巫术。

别说这些了，给我看看成果！

我不是 YouTuber，不过请看：

关于隔离和下一步的想法

完全 Agent 化开发与安全之间始终存在权衡。这是一个相当刻意构造的例子：该应用可以完全隔离地运行。但大多数有用的软件都需要与其他软件通信，这意味着要交出 API 密钥，而每一把密钥都会在沙箱上再开一个小洞。

即使在这一设置中，Hermes 仍然可以：

  • 摧毁新服务器及其中运行的一切。
  • 删除仓库、数据库和部署。
  • 泄露或滥用我交给它的任何凭据。
  • 像其年终考核取决于此一样疯狂消耗推理 token。
  • 发起随机的出站请求，并下载互联网塞给它的任何垃圾。
  • 探测防火墙允许它访问的、网络中的任何其他资源。

所以，不，这并非无害。我所做的是让这台机器成为可牺牲的机器，并严格限制它可触及的、我真正关心的东西。现在的故障模式是“重建这台 eBay 买来的机器，并轮换少量密钥”，而不再是“发现 LLM 兴致勃勃地重新整理了我的真实笔记本电脑”。我认为这更好，但这不是魔法。

显而易见的下一步包括：

  • 将这台机器放入独立 VLAN，并明确阻止其访问家庭网络的其他部分。
  • 将每项凭据的权限限定到服务提供商允许的最小范围，并定期轮换。
  • 自动化备份，并让重建整台机器成为一键操作。
    • Coolify 的数据库备份以及我共享的 Docker Compose 挂载，应能使这件事相对容易。
  • 在它执行任何真正公开或难以撤销的操作前，要求获得批准。

不过在某个时刻，足够多的审批门槛会把神奇的自主软件工厂重新变成一堆需要你填写的表单。在“每五分钟都需要我介入”和“它掌握发射密码”之间找到有用的平衡点，将是下一个实验。

English / 原文

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)

The servers

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.

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:

Networking diagram (A bit AI slop sorry!)

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-building skills : Hermes can create and register its own skills. I couldn’t find a good Coolify one, so it read the docs, looked at the MCP and built one.
  • Firecrawl : Self-hosted Firecrawl gives the agent much nicer access to SERP data and web scraping at scale.

Getting Hermes and Firecrawl set up with the right keys in the right places is a massive pain in the arse. I’ve added Coolify-friendly Docker Compose files to the repo linked above.

Hermes chugging through building a demo web app for this blog post.

Coolify

Coolify is the glue holding this together: a self-hosted PaaS built on Docker and Compose that comes on in leaps and bounds with every update. If you want Heroku or DigitalOcean App Platform niceties on your own hardware, I’d highly recommend it.

Some of my favourite features are:

  • It’s just Docker under the hood. Existing deployments mostly work, and if Coolify won’t do something weird you can docker exec <whatever> from your laptop. Things are only abstracted away if you want them to be.
  • The SSL / routing stack which I’ve gone into in depth above.
  • Coolify ships with a bunch of pre-made recipes for all the most common apps. Postgres, Redis, Hermes, Forgejo and almost anything else is available to deploy with a single click.
  • Postgres backups to S3 are a three-click job, and env vars and user management are built in.
  • GitHub webhooks give you automatic deploys on push to main.

Here are a couple of screenshots of my Coolify setup in action:

Tooling screen on Coolify

Firecrawl service and Docker Compose

What it actually did

The demo below shows this pretty well, but the starting gun was the following prompt:

Please build me an app for tracking my calorie intake. It should be similar to MyFitnessPal but with a form to
add specific food and meals for quick selection later.

Your task is to build it, commit it to a new repo with tests, test it with CI, and deploy it to
http://calories.internal.jakeshomelab.me.

I’d like it to be a full stack svelte kit app with Drizzle and Postgres for the database layer.
I’d like tailwind for the CSS. It should be mobile first.

For deployment, please use docker and docker compose and deploy your own Postgres instance.

From there, it just got on with it:

  • Created a new Git repo and bootstrapped SvelteKit, Drizzle, Postgres and Tailwind.
  • Wrote the app and its tests, committing the work in sensible stages.
  • Created a CI pipeline.
  • Worked through test failures until CI turned green.
  • Containerised the app and its own Postgres instance with Docker Compose.
  • Deployed the lot to Coolify at its own URL.

All without a single further prompt. No nudging it through failed tests or copying error messages back into the chat. It just kept going until the app was running.

At that point I gave it a whirl and hit a CSRF issue when submitting data. I sent one more prompt; it diagnosed the problem, fixed it, added regression tests and redeployed.

And it worked!

That’s the loop I wanted: prompt, repo, code, tests, CI, deployment, bug fix. It’s not a complicated app, obviously, but it went from a paragraph to tested, deployed software and handled all the boring bits in between. That still feels a bit like witchcraft.

Enough of all that, show me the goods!

I’m no YouTuber, but here you go:

Thoughts on isolation and next steps

There is always a trade-off between fully agentic development and security. This was a fairly contrived example: the app works completely in isolation. Most useful software talks to other software, which means handing over API keys, and every key adds another little hole in the sandbox.

Even in this setup, Hermes can still:

  • Nuke the new server and everything running on it.
  • Delete repos, databases and deployments.
  • Leak or abuse any credentials I’ve given it.
  • Burn through inference tokens like its end-of-year review depends on it.
  • Make rando outbound requests and download whatever rubbish the internet hands it.
  • Poke anything else on my network that the firewall allows it to reach.

So no, it isn’t harmless. What I’ve done is make the machine sacrificial and sharply limit how much stuff I care about is within reach. The failure mode is now “rebuild the eBay box and rotate a handful of keys”, rather than “discover an LLM has enthusiastically reorganised my actual laptop”. That’s better I think, but it isn’t magic.

The obvious next steps are:

  • Put the box on its own VLAN and explicitly block access to the rest of my home network.
  • Scope every credential as narrowly as the provider allows, and rotate them regularly.
  • Automate backups and make rebuilding the whole box a one-shot job.
    • Coolify’s DB backup and my shared Docker compose mounts should make this relatively easy.
  • Require approval before it does anything genuinely public or difficult to undo.

At some point, though, enough approval gates turn your magical autonomous software factory back into a collection of forms you have to fill in. Finding the useful point between “needs me every five minutes” and “has the launch codes” is the next experiment.