Dora NodaThirty tools, one command, zero configuration files touched by hand. That is the promise of selfhost-ai, a Docker Compose installer that turns a fresh Ubuntu VPS into a private AI homelab: n8n workflows, local LLMs via Ollama, a ChatGPT-style chat, vector databases, RAG engines, Supabase, and Grafana monitoring, all behind Caddy with automatic HTTPS.
Here is the verdict up front, because the rest of this post is the evidence for it: selfhost-ai is the best demonstration yet that compose-first distribution won the homelab — one install command beats thirty README files every time. But the same design that makes it unbeatable for one person on one box is exactly what breaks it for teams: no second machine, no multi-user tenancy, and no per-tool upgrade story. The interesting question is not whether the stack is good. It is which pieces a real PaaS should absorb as one-click templates, and which it should leave to the compose file.
The numbers that frame everything below: 30+ optional services behind a single ./scripts/install.sh, a minimum of 4 GB RAM for n8n plus monitoring versus 20 GB RAM for the full stack, and exactly one supported machine — a public-IP Ubuntu 24.04 VPS with a wildcard DNS record.
What the stack actually is
selfhost-ai (by kossakovsky, Apache 2.0, formerly n8n-install) sits at the end of a clear lineage. The n8n team shipped the Self-hosted AI Starter Kit, a minimal compose file wiring n8n to Ollama, Qdrant, and Postgres. Cole Medin's local-ai-packaged expanded that template with Supabase, Open WebUI, Flowise, and Caddy. selfhost-ai takes the third step: it stops being a template you adapt and becomes an installer you run, with an interactive wizard, generated secrets, profiles per service, and make commands for day-2 operations.
Three services are always installed — Caddy (reverse proxy and HTTPS), PostgreSQL, and Valkey — and everything else is optional, chosen in the wizard:
| Group | Services |
|---|---|
| Chat and agents | Open WebUI, OpenClaw, Flowise / Keelflow, Dify, Letta, Ollama, ComfyUI, InvokeAI |
| RAG and data | Qdrant, Weaviate, Supabase, Neo4j, LightRAG, RAGFlow, RAGApp |
| Documents and search | Docling, PaddleOCR, Gotenberg, Crawl4AI, SearXNG, LibreTranslate |
| Low-code and data apps | Appsmith, NocoDB |
| Monitoring and ops | Grafana + Prometheus, Langfuse, Uptime Kuma, Portainer, Databasus |
Each service gets its own subdomain (n8n.yourdomain.com, webui.yourdomain.com) off the wildcard record, and the installer prints a Welcome page with every URL and credential at the end. Prerequisites are deliberately narrow: one VPS, one domain, one wildcard A record configured before you start. Home servers, shared hosting, and localhost setups are explicitly unsupported — a scope decision that eliminates half the support burden before it exists.
The anchors of the stack are the two projects that made self-hosted AI legible to normal teams. n8n passed 180,000 GitHub stars, topped the 2025 JavaScript Rising Stars ranking, and after a $180M Series C at a $2.5B valuation in October 2025 took a strategic SAP investment in May 2026 that roughly doubled that valuation.
Ollama raised a $65M Series B in July 2026 on 8.9 million developers and nearly a million new installs a week, while ISG reports 65% of organizations now piloting open-weight models with nearly 20% already running a local LLM in deployment. selfhost-ai did not create this demand. It packaged it.
What compose-first distribution gets right
Strip the marketing and selfhost-ai is four mechanisms, each removing one category of toil that has historically made self-hosting AI tools a weekend project instead of a Tuesday afternoon.
The wizard plus generated secrets removes .env archaeology. A 30-service compose stack naively means thirty password fields, thirty port assignments, and thirty chances to misconfigure auth. The installer asks for a domain, an email, a service checklist, and an optional OpenAI key, then generates every secret itself. Compare that to the starter-kit era, where step one was always "copy .env.example and fill in secrets" — a step the official Supabase self-hosting docs still make you do by hand across eleven containers.
Caddy plus Let's Encrypt removes per-service TLS. Every service is reachable only through Caddy; nothing listens on a public port directly. TLS termination, certificate issuance, and renewal happen once, in one place, for every subdomain. Anyone who has ever debugged a mixed-content error in one of six reverse-proxied apps knows how much operational surface this deletes.
Subdomain-per-service removes port bookkeeping. The wildcard DNS record plus Caddy routing means no port-allocation spreadsheet, no collisions when two tools both default to port 3000, and URLs humans can remember. It is the same convention every PaaS converged on, implemented with two primitives (DNS wildcard, reverse proxy) instead of a control plane.
Profiles, make doctor, and make update remove day-2 guesswork. Services are compose profiles you opt into rather than YAML blocks you uncomment. make doctor checks DNS, certificates, containers, disk, and memory in one command, and make update pulls the installer and images and restarts.
The troubleshooting guide's first entry — "sites don't load, the server is usually out of RAM" — is honest about the failure mode and points at make monitor to confirm it. This is distribution as a product, not a README.
Together these mechanisms explain the project's traction: roughly 940 stars and active releases (v1.16.0 landed September 28, 2026) for what is, at bottom, a compose file with opinions. The opinions are the product.
Where it hits the second-machine wall
Every strength above assumes one administrator and one machine. The moment a second person or a second box enters the picture, three structural ceilings appear — and none of them is fixable with a better wizard.
No second machine. Docker Compose is a single-host orchestrator: it schedules onto one Docker daemon, on one box, full stop. Multi-host means Swarm or Kubernetes, and compose semantics do not map 1:1 onto either.
So the full selfhost-ai stack shares one machine's RAM and CPU forever. The README's own sizing tells the story: 4 GB for the minimal install, 20 GB for everything. When Ollama wants a GPU box and Supabase wants memory and n8n workers want CPU, there is nowhere to put them except a bigger single VPS — vertical scaling as the only scaling. The installer even documents the failure mode: out of RAM means sites stop loading, and the fix is to enable fewer services.
No multi-user tenancy. Each tool has its own login, and the Welcome page holds every credential in one place — for one admin. There is no shared identity, no per-teammate accounts provisioned across the stack, no RBAC layer, no audit trail of who changed what.
n8n has users; Open WebUI has users; Supabase has auth; but nothing above the individual tools knows that "alice the n8n editor" and "alice the chat user" are the same person. For a homelab that is fine. For a team, it means every onboarding and offboarding is a manual tour of a dozen admin panels, and every shared password is a credential that outlives its need.
No per-tool upgrade story. This is the subtlest ceiling and the one that bites hardest over time. make update pulls the installer and updates all images at once — and it resets tracked files like Caddyfile and docker-compose.yml, so customizations must live in override files or be lost. There is no supported "upgrade just Qdrant" or "hold n8n at this version while everything else moves." One tool's lifecycle drags the whole stack with it.
The Flowise saga is the concrete exhibit. Flowise was archived upstream on August 13, 2026 and reached end of life on August 31, receiving no more security fixes. selfhost-ai's response — pin Flowise to 3.1.3 and ship the Keelflow continuation (forked from Flowise 3.1.4, first release September 24) as a parallel profile with its own data volume and a migration guide — was exemplary incident handling.
But notice what it required: a whole new stack profile, a docs page, and every operator deciding when to move their data. In a compose monolith, one dependency's end-of-life is a stack event. In a template catalog, it is one template's changelog entry.
The absorption map: what a PaaS should take
If compose won distribution for the homelab, the team-grade answer is the same catalog with tenancy and scheduling underneath — which is precisely what one-click template libraries on self-hosted PaaS platforms already are. Coolify ships 280+ one-click services across multiple SSH-managed servers; the model is proven. The question for any Cluster-API PaaS is which selfhost-ai pieces to absorb as templates and which to leave to the compose file. Here is the map:
| Stack group | Verdict | Why |
|---|---|---|
| n8n | Absorb with a license caveat | The anchor workload: queue mode, workers, and 400+ integrations map cleanly to per-tenant deploys. But n8n's fair-code license bars reselling it as a competing hosted service — a PaaS can template it for self-hosted tenants, not meter it as its own SaaS. |
| Ollama | Absorb | The GPU story is the whole game: per-tenant model pulls, VRAM quotas, and multi-GPU placement are scheduler problems Compose cannot express. ISG's 20%-deployed-local-LLM figure says demand is here. |
| Qdrant / Weaviate / Neo4j | Absorb | Single-container stateful services with clear resource profiles — ideal template citizens, and per-tenant instances fix the shared-credential problem for free. |
| Supabase | Absorb selectively | Eleven containers idling at ~2 GB RAM is a heavy template, but Postgres + Auth + Storage is exactly what tenant apps need. Ship the subset (Auth, PostgREST, Postgres) before the full Studio bundle. |
| Open WebUI | Absorb | Thin stateless frontend over Ollama; trivially multi-tenant behind per-workspace routing. The SQLite-vs-Postgres choice the stack documents becomes a template default. |
| Dify / Letta / RAGFlow / LightRAG | Leave to compose (for now) | Fast-moving, overlapping agent/RAG frameworks with unstable APIs. Templating all four means owning four churn firehoses; let the compose stack be the evaluation sandbox and template the winner later. |
| Docling / PaddleOCR / Crawl4AI / SearXNG | Leave to compose | Internal or single-purpose utilities that ride along inside n8n/RAG workflows. Absorb them as sidecars of the n8n template, not as standalone entries. |
| Grafana / Prometheus / Uptime Kuma | Skip (platform already owns this) | A PaaS has its own observability plane. Re-templating monitoring per tenant duplicates what the platform must provide globally. |
Portainer / make doctor | Skip (replace with platform UX) | Container UIs and diagnostic CLIs are symptoms of missing platform UX. The PaaS equivalent is tenant dashboards and health checks, not a Portainer template. |
Two principles fall out of the table. First, absorb the stateful anchors and the GPU workloads — the pieces where per-tenant isolation and scheduler placement are the value a PaaS adds over a compose file. Second, leave the fast-churn application layer to compose — the stack's real service to a PaaS operator is as a curated evaluation sandbox where frameworks compete before any of them earns a template slot. Flowise's end-of-life is the cautionary tale for templating too eagerly: every template is a lifecycle commitment, and a catalog that absorbs four overlapping agent frameworks inherits four deprecation timelines.
The wall is the product spec
selfhost-ai proves that distribution — not orchestration — was the missing piece for self-hosted AI: one command, generated secrets, automatic HTTPS, and honest sizing guidance got 30 tools onto boxes that would otherwise run two. The second-machine wall is not a criticism of that achievement. It is the spec for the next layer: the same catalog, per-tenant, scheduled across machines a team owns, with each tool on its own upgrade track.
Compose got the homelab from zero to thirty tools. Getting a team from thirty tools to a platform is a different job — and it starts by absorbing the anchors, not the whole stack.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
