selfhost-ai: a Docker Compose installer that wires n8n, Ollama and 30+ services behind Caddy
🚀 Self-hosted AI automation platform. Deploy n8n, Ollama, Flowise, RAG, Supabase & 30+ tools with one command. Auto HTTPS. Free Zapier/Make alternative.
At a glance
- What is it?
- The repository ships a Shell-based interactive wizard that selects services, generates secrets and writes a Docker Compose stack with automatic HTTPS. It is aimed at homelab and small-team operators who want n8n and local LLMs without assembling the plumbing themselves.
- Who is it for?
- Adopt selfhost-ai if you want n8n in queue mode with Redis and Postgres plus a local Ollama endpoint, and you accept that Caddy, Postgres and Redis are always installed. Skip it if you need a Kubernetes deployment or want to run exactly one container.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What selfhost-ai actually installs, and for whom
The project is a Shell installer plus a Docker Compose template. It does not implement workflow automation, LLM inference or vector search itself. It selects, configures and connects other people's containers. The README describes the result as a complete self-hosted environment with n8n, Flowise, Ollama, vector databases (Qdrant, Weaviate), RAG engines, Supabase and a monitoring stack, all behind Caddy with automatic HTTPS.
The target user is an operator who would otherwise spend a weekend writing compose files and reverse proxy rules. The README frames the audience as people who want a private AI homelab and a ChatGPT alternative through Open WebUI, or who want a free Zapier or Make alternative through n8n. There is an explicit homelab topic on the repository, and the install path is documented for Ubuntu 24.04 LTS. That is a narrower audience than the feature list suggests. If you run Debian, Fedora or a NAS appliance, the README does not describe a supported path for you.
The value proposition is curation and wiring, not code. The installer decides which images to pull, which environment variables to generate, and how services find each other on the Docker network. That is the whole product.
The one-command wizard and what it writes to disk
Installation is an interactive wizard. The README states that secrets are generated automatically and that configuration is zero-manual. During setup you choose which optional tools to deploy, and for n8n you specify the number of workers and task runners. InvokeAI asks for a hardware target: NVIDIA, AMD or CPU, with models and outputs stored in ./invokeai on the host.
The always-on core is Caddy, Postgres and Redis. Caddy terminates TLS and obtains Let's Encrypt certificates, which is why the README can promise automatic HTTPS. Postgres is the data store for n8n and other services. Redis backs n8n's queue mode, which the README says is the default rather than an option you enable later.
Two details in the README are worth reading twice. First, Gotenberg is described as available only within the Docker network, for internal use by n8n workflows and other services. That is a deliberate exposure decision, and it means you cannot hit the PDF conversion API from your laptop without adding your own route. Second, the n8n Assistant sandbox uses Docker-in-Docker isolated with Sysbox and is marked internal only. Running Docker inside a container has a larger host-level blast radius than a normal service, and the README does not walk through the kernel or privilege requirements for Sysbox. Treat that component as the one to research before enabling.
n8n in queue mode: the part that decides your hardware bill
The README is specific here. n8n runs in queue mode by default, using Redis for task management and Postgres for data storage. The installer asks how many n8n workers and task runners you want, and the README connects that choice to parallel processing of workflows under demanding loads.
This is the main architectural decision the project makes for you. Queue mode means the editor process and execution processes are separate, so a heavy workflow does not block the UI. It also means every worker is another container competing for the same CPU and RAM, and the same Postgres connection pool. The wizard will happily accept a worker count your machine cannot feed. Nothing in the supplied material describes autoscaling, resource limits per worker, or a recommended worker-to-core ratio, so the number you type is a guess until you watch the monitoring stack.
That monitoring stack is included rather than bolted on. The README mentions Grafana and Prometheus with an n8n dashboard tracking workflow executions: outcomes, per-workflow volume, and time since last success, plus ready-made alert rules for failed or stalled workflows. For a queue-mode deployment this is the feedback loop that tells you whether the worker count is right. It is also the part most likely to be skipped, because it is not the reason anyone installs the project.
Optional services and the integration seams between them
The optional list is long and heterogeneous. Workflow and agent tooling: n8n, Flowise, Dify, Letta. Local inference and generation: Ollama, Open WebUI, ComfyUI, InvokeAI. Retrieval: Qdrant, Weaviate, Crawl4ai, Docling. Platform and operations: Supabase, Appsmith, Langfuse, Grafana, Prometheus, Gost, Gotenberg, n8n-MCP, and the n8n Assistant sandbox.
The seams matter more than the count. Docling converts PDF, DOCX, PPTX, XLSX, HTML and images into Markdown or JSON and exposes a REST API, which the README positions for document processing inside n8n workflows. Gotenberg converts HTML, Markdown and Office documents to PDF, PNG or JPEG, but only inside the Docker network. Crawl4ai fetches web pages for extraction. Those three are the ingestion path for a RAG pipeline, and the wizard is what puts them on the same network as Qdrant or Weaviate and n8n.
n8n-MCP is a different kind of addition. The README describes it as a Model Context Protocol server that gives AI coding assistants indexed access to n8n node documentation, property schemas and workflow templates, and, once you supply an n8n API key, the ability to create and update workflows in your instance from the IDE. That is a write path into your automation platform from a developer tool. If you enable it, the API key is the thing to scope and rotate.
The README also mentions an optional import of 300+ community workflows during setup. Imported workflows are third-party content. The supplied material does not say whether they arrive disabled, what credentials they expect, or how they are reviewed. Assume you are importing untrusted automation and check what got created before activating anything.
Where this approach breaks down
The installer is opinionated about the core. Caddy, Postgres and Redis are always included. If you already run Postgres with tuned backups, or you terminate TLS at an existing load balancer, you are adding a second copy of infrastructure you did not ask for. There is no documented path in the supplied material to point the stack at an external database or to disable Caddy in favour of your own proxy.
Caddy's automatic HTTPS assumes public DNS resolution for the host and reachable ports 80 and 443. On a home connection behind CGNAT, or on a host where another service already owns those ports, certificate issuance fails. The README's troubleshooting section exists, but the supplied excerpt does not enumerate these failures, so budget time for them.
Resource sizing is the other sharp edge. Ollama models, a vector database, ComfyUI or InvokeAI, Supabase, and a Grafana and Prometheus pair all want memory and disk. Selecting everything in the wizard on a small VPS is a plausible way to end up with an unusable machine. The README offers no minimum specification table in the material provided, which is a real gap for anyone sizing a purchase.
Finally, the project is Shell. The installer's correctness depends on the host distribution and on Docker being present and recent. This is not a Kubernetes operator, a Helm chart, or a managed control plane, and it does not claim to be.
How it differs from Coolify
Coolify is the closest comparison for the deployment layer, and the difference is philosophical. Coolify is a general-purpose, web-UI-driven platform for deploying arbitrary applications and databases from Git repositories or Docker images, with its own proxy management and per-application configuration. selfhost-ai is a curated bundle: a fixed catalogue of AI and automation services, chosen and wired by a Shell wizard, with the integration between them pre-decided.
If your goal is to run your own software, Coolify is the broader tool. If your goal is to reach a working n8n plus Ollama plus a vector database without making those decisions, selfhost-ai removes more work. The trade is flexibility. With Coolify you assemble the stack and own every connection. With selfhost-ai the stack arrives assembled, and your leverage is the wizard's choices plus the generated compose files, which you can edit afterwards, though the README does not describe how upgrades treat local edits.
Upgrades, licence and what to verify before you commit
The repository shows a steady release cadence through v1.11.0, with v1.10.0 and v1.10.1 landing a week earlier. The README has an Upgrading section and a Makefile with quick commands, so there is an intended upgrade path rather than a reinstall. What the supplied material does not state is whether upgrades preserve your compose edits, your Postgres data, or your selected service set. That is the first thing to test on a throwaway host, not on the machine running your workflows.
The licence is Apache-2.0. That permits commercial use and modification, and it includes a patent grant. It also means the bundled third-party services keep their own licences, which vary: some are permissively licensed, others are not. Reviewing the licence of each service you enable is your responsibility, and this is not legal advice.
Maintenance cost is mostly the cost of the underlying services. Each image you enable needs updates, and a stack of thirty containers multiplies that. The monitoring stack is the mitigation the project provides, but it monitors workflow outcomes, not image freshness. Decide up front which services you truly need, because every one you skip is a container you never have to patch.
Editorial conclusion
Adopt selfhost-ai if you want n8n in queue mode with Redis and Postgres plus a local Ollama endpoint, and you accept that Caddy, Postgres and Redis are always installed. Skip it if you need a Kubernetes deployment or want to run exactly one container. Before running the wizard, confirm that ports 80 and 443 are free, that your DNS A records point at the host, and that your disk and RAM can hold the Ollama models and the vector databases you select.
Community notes