selfhost-ai: a one-command Docker Compose stack for n8n, Ollama and 30+ AI tools

The problem selfhost-ai targets: assembling a private AI stack by hand

Running n8n, a local model server, a vector database and a chat front end on one machine is not hard in isolation. It becomes tedious when the pieces have to share a database, sit behind a reverse proxy with certificates, and start in an order that respects health checks. selfhost-ai packages that assembly into a single repository: a `docker-compose.yml`, a `Caddyfile`, an `.env.example`, a `Makefile` and a `scripts/` directory. The README describes it as a Docker Compose template that "deploys 30+ AI and automation tools with a single command" and positions it as a free alternative to Zapier and Make.

The audience is specific. This is for someone with a server, a domain, and a preference for owning the data path. The README's own framing is a "Private AI Homelab" where LLMs run locally through Ollama and Open WebUI provides a chat interface. If you only need a hosted workflow tool, nothing here is aimed at you. The project assumes you are willing to operate a Docker host and read logs when something does not come up.

What the wizard actually deploys, and what is always on

The split between mandatory and optional services is the clearest design decision in the repository. Caddy, Postgres and Redis are always included, and the README calls them "core services for web proxy, database, and caching". Everything else is offered through an interactive wizard during setup, so the final footprint depends on what you tick.

The optional list is long and heterogeneous. It includes n8n for workflow automation, Flowise and Dify for AI application building, Ollama and Open WebUI for local models, Qdrant and Weaviate as vector stores, Langfuse for agent tracing, Grafana and Prometheus for monitoring, plus utilities such as Gotenberg for document-to-PDF conversion, Crawl4ai for crawling, Docling for document conversion, and Gost as an outbound HTTP/HTTPS proxy. Supabase appears in the secret list in `.env.example`, and the compose file declares volumes for services that are not in the excerpted README list, including RAGFlow, Temporal, NocoDB, Portainer and Uptime Kuma.

That breadth is the selling point and the cost. A wizard that offers thirty services will produce a Compose file whose failure modes you have not seen before, and the README does not attempt to document every combination. The monitoring stack is the exception to the thin documentation: the README states that Grafana and Prometheus ship with an n8n dashboard tracking workflow executions, per-workflow volume and time since last success, plus alert rules for failed or stalled workflows.

How the stack is wired: Caddy, Postgres, Redis and queue-mode n8n

The architecture visible in `docker-compose.yml` is conventional and worth understanding before you run the installer. Caddy terminates TLS and issues Let's Encrypt certificates automatically, which is why the README can promise auto HTTPS without further configuration. Postgres is the shared database, and the compose file names a volume `localai_langfuse_postgres_data`, which shows Postgres is shared across services rather than run per application.

n8n is the service with the most explicit configuration. Its environment block sets `DB_TYPE: postgresdb`, points `DB_POSTGRESDB_HOST` at the `postgres` service, and sets `EXECUTIONS_MODE` to `${EXECUTIONS_MODE:-queue}`. Queue mode is the default, not an option you enable later. That means n8n needs Redis for task management, which is why Redis is a core service. The README states that you can specify the number of n8n workers and task runners during installation, so the wizard is where you decide how much parallel execution you want.

Two smaller details in the compose file matter operationally. A shared logging anchor caps container logs at `max-size: "1m"` with `max-file: "1"`, which prevents a chatty service from filling the disk. A proxy anchor injects `HTTP_PROXY`, `HTTPS_PROXY` and `NO_PROXY` from `GOST_PROXY_URL` and `GOST_NO_PROXY` into services, so outbound traffic can be routed through Gost if you deploy it. Both are the kind of detail that is annoying to retrofit.

Installing selfhost-ai and running your first n8n workflow

The repository ships a Makefile that fronts the scripts. The README's installation path starts with the environment file, and `.env.example` opens with the instruction to rename it to `.env` after updating it. The file marks n8n credentials as required and leaves `N8N_ENCRYPTION_KEY`, `N8N_USER_MANAGEMENT_JWT_SECRET` and several runner tokens blank for you to fill.

git clone https://github.com/kossakovsky/selfhost-ai.git
cd selfhost-ai
cp .env.example .env

After editing `.env`, the install target runs the interactive script. According to the Makefile, `install` invokes `sudo bash ./scripts/install.sh`, so the wizard runs with root privileges.

make install

The wizard asks which optional services to deploy and, for n8n, how many workers and task runners you want. Once it finishes, the Makefile gives you the operational commands you will use daily. `make status` shows container status, `make logs` tails everything or a single service, and `make doctor` runs system diagnostics.

make status
make logs s=n8n
make doctor

Once n8n is reachable through your Caddy domain, the README notes an optional step: importing 300+ community workflows during setup. The Makefile exposes this as `make import`, and it accepts a count, so `make import n=10` imports only the first ten workflows. That is the safer first run, because it lets you confirm the import path works before pulling the full set.

make import n=10

Where selfhost-ai gets in your way

The update path is the sharpest edge. The Makefile help text describes `make update` as "Update system and services (resets to origin)". A reset to origin discards local changes in the checkout, and the README does not document rollback. If you plan to edit the Compose file or the Caddyfile directly, that command will take those edits with it. The Makefile offers `make update-preview` as a dry run and `make git-pull` for forks, which merges from upstream, but the distinction between a reset and a merge is exactly the kind of thing you want to understand before, not after, running the command.

Resource requirements are the second constraint. Ollama runs models locally, and the README's own pitch is a private homelab. Local model inference is memory-hungry, and the compose file declares a separate `docker-compose.ollama-gpu-devices.yml` for GPU device passthrough and another for InvokeAI, which tells you the default path is CPU unless you opt in. The README does not publish minimum hardware figures, so sizing is on you.

Third, this is a broad stack with narrow documentation. The README documents what each service is and links to upstream projects. It does not document per-service configuration, secret rotation, or what happens when a shared Postgres instance is used by many applications at once. The `paddlex/`, `searxng/`, `python-runner/` and `caddy-addon/` directories in the repository root indicate the installer carries its own configuration for several services, and those files are the real reference when the README runs out.

How it differs from running n8n or Ollama on their own

The honest alternative is not another bundle. It is the official installation path for each component: n8n's own Docker image with a Postgres container, Ollama installed directly on the host, and a reverse proxy you configure yourself. That approach gives you one service to reason about at a time, and when it breaks you are debugging software whose documentation you can read end to end.

selfhost-ai's difference is the integration work it does up front. Queue mode with Redis, a shared Postgres, Caddy with automatic certificates, log rotation, proxy environment variables, health checks and service dependencies are all pre-wired. The README also points at n8n-MCP, a Model Context Protocol server that gives AI coding assistants indexed access to n8n node documentation and, with an API key, the ability to create and update workflows from an IDE. That is a convenience you would otherwise assemble yourself.

The trade-off is coupling. A single Compose file means a single upgrade surface, a shared database, and a wizard that decides start order. If you want to run n8n at the latest version while pinning Flowise to an older one, this template is not built for that. If your goal is one tool, install that tool.

Licence, maintenance and what upgrading costs you

The repository is Apache-2.0, and the README lists "Free & Open Source" with "No vendor lock-in" as a feature. Apache-2.0 covers the installer, the Compose files and the scripts in this repository. It does not relicense the services the wizard deploys. n8n, Flowise, Dify, Ollama and the rest carry their own licences, and several of them have open-core models where some features sit behind a commercial tier. The README does not enumerate those licences per service, so check each one you enable. That is a licensing question, not a legal opinion, and it is worth a look before this stack ends up in front of paying customers.

On maintenance, the last push to `main` was on 2026-09-09, and the most recent release is v1.11.0 from the same day, following v1.10.1 and v1.10.0 on 2026-09-02. The repository is not archived. Release cadence in early September was three releases in eight days, which suggests active work at that time, but the available facts do not establish a longer-term pattern.

The upgrade cost is mostly the reset behaviour described above plus the usual Compose image pulls. `make update` resets the checkout to origin, `make update-preview` shows what would change, and `make clean` removes unused Docker resources while preserving data. `make clean-all` is flagged as DANGEROUS in the Makefile help because it removes data volumes. Read that help text before running either.

Editorial conclusion

Adopt selfhost-ai if you already run a Docker host, want n8n in queue mode with Redis and Postgres, and would rather choose services from a wizard than assemble a Compose file yourself. Skip it if you need a single small application, or if you cannot give the stack a real domain and a machine with enough memory for local LLMs. Before you commit, verify three things: that the services you want are actually selectable in the wizard, that you understand what `make update` does to your checkout, and that your `.env` secrets are generated rather than left blank.

Frequently asked questions

Official sources

1. kossakovsky/selfhost-ai on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases