你的自托管 AI 栈可能只需要一个进程，而不是六个

Open the compose file for almost any self-hosted AI assistant. You will find an app container, Redis for the queue, Postgres for state, a worker, usually a vector database, often a reverse proxy. Six services. For a household of five. Then ask what that architecture is actually buying you at that scale. The queue exists so work survives a restart and so you can scale workers horizontally. You are not scaling workers horizontally. You have one box under a desk. The queue is solving a problem you do not have A broker earns its place when producers and consumers scale independently, when work must survive the process that accepted it, or when several services need the same event. Those are real problems at real scale. At five users, none of them apply, and you have paid for all of them anyway. Six services is six things that can fail, six sets of logs, six version upgrades, and a debugging experience where a symptom in the UI has its cause three hops away in a container you were not looking at. TencentCloud's Octop takes the other branch. One process serves the web dashboard, the CLI backend, every chat channel and the cron scheduler. No broker. Every surface routes through one in-process handler, and the entire runtime state is rebuilt from a SQLite control-plane database on boot. That last clause is the part doing the work. Restart-safety usually comes from durable queues plus careful shutdown handling. Here it comes from the process holding no authoritative state at all. Kill it however you like. On boot it reads the database and reconstructs itself. There is nothing in memory worth preserving, which is a much stronger property than preserving it well. SQLite in WAL mode is not the compromise here The reflex is that SQLite is the starter option you outgrow. For a concurrent-reader, low-concurrent-writer workload on one machine, it is simply the correct choice. No connection pool, no second daemon, no tuning, and your backup is a file copy. Octop offers Postgres as an option rather than an assumption. That ordering is the tell that someone thought about the actual workload instead of copying a reference architecture. Where this breaks Say the limits out loud, because they are real. One process is one failure domain. You cannot put the chat gateway on one box and the agent runtime on another. There is a user count past which this stops being clever and starts being a bottleneck. For a household or a team of five, that ceiling is theoretical and the operational simplicity is banked every single day. For fifty concurrent users it is the wrong shape. The practical version: before you self-host anything with remote access, your upload bandwidth decides whether it is usable at all, and a speed test answers that faster than finding out later. Fuller write-up, including two caveats worth knowing before you run the installer: Octop.