n8n Self-hosted AI Starter Kit: What the Docker Compose Template Actually Ships

The problem is the wiring, not the components

Running a local LLM is easy now. Running a local LLM that a workflow tool can call, with a vector store next to it and a database underneath, is a configuration exercise spread across four projects. Ollama has its own container conventions, Qdrant has its own ports and volumes, PostgreSQL needs credentials, and n8n needs to reach all three from inside its own container. The starter kit's contribution is a single Compose file with the network and storage settings already aligned, so the four services start as one unit. The README describes it as a template that "quickly sets up a local AI environment," and the operative word is template: you are meant to read the Compose file, not treat it as an appliance. The audience is engineers who want to evaluate n8n's AI nodes against a local model without sending prompts to a hosted API, and who would rather start from a working stack than from four separate quickstart pages.

Four services, one Compose network

The kit bundles n8n as the orchestration layer, Ollama as the model runtime, Qdrant as the vector store, and PostgreSQL as the database. n8n is the low-code platform with the AI nodes: the README names the AI Agent, Text classifier and Information Extractor nodes specifically, and notes that over 400 integrations are available once the instance is up. Ollama handles model download and inference locally. Qdrant holds embeddings. PostgreSQL is described in the README as the data engineering workhorse that "handles large amounts of data safely." The data flow implied by the README is straightforward: a workflow in n8n calls the Ollama node for generation, writes and queries embeddings in Qdrant, and persists workflow and execution state in PostgreSQL. The README's guidance for keeping everything local is explicit: use the Ollama node as your language model and Qdrant as your vector store. Swap either for a hosted service and the privacy argument for the stack disappears, which is the whole point of the kit's existence.

Profiles decide how Ollama gets compute

The Compose file uses profiles rather than separate files, so the same repository serves Nvidia, AMD and CPU-only machines. Nvidia users run docker compose --profile gpu-nvidia up. AMD users on Linux run docker compose --profile gpu-amd up. Everyone else runs docker compose --profile cpu up. The README points Nvidia users who have not passed a GPU into Docker before at the Ollama Docker instructions, which is a fair signal that the GPU path assumes prior setup outside this repository. The Mac case is handled differently and is the most interesting detail in the README. Apple Silicon cannot expose the GPU to the Docker instance, so the README offers two options: run the whole kit on CPU, or run Ollama natively on the Mac and point n8n at it. The second option requires two changes, not one. You set OLLAMA_HOST to host.docker.internal:11434 in .env, and after n8n reports that the editor is accessible, you open the credentials page at localhost:5678/home/credentials, select the Local Ollama service credential, and change its base URL to http://host.docker.internal:11434/. Miss the second step and the workflow keeps pointing at the containerized Ollama that is not running.

Getting it up: clone, .env, one compose command

Every installation path in the README starts the same way: git clone https://github.com/n8n-io/self-hosted-ai-starter-kit.git, cd self-hosted-ai-starter-kit, then cp .env.example .env. The README's inline comment on that copy step is a direct instruction: you should update secrets and passwords inside. That is the one manual task the kit does not do for you, and it is the step most likely to be skipped. From there the command depends on the profile: docker compose --profile gpu-nvidia up, docker compose --profile gpu-amd up, or docker compose --profile cpu up. Once n8n is reachable at http://localhost:5678/, you complete its one-time setup in the browser, open the bundled workflow at http://localhost:5678/workflow/srOnR8PAY3u4RSwb, and click the Chat button at the bottom of the canvas to run it. The README warns that the first run may block while Ollama downloads Llama3.2, and suggests watching the Docker console logs for progress. Upgrades follow the same profile logic: pull, then create, then up, for example docker compose --profile gpu-nvidia pull followed by docker compose create && docker compose --profile gpu-nvidia up.

The README calls it a proof-of-concept, and that matters

The kit's own note is unusually blunt for a vendor-published template: it is designed to help you get started, it is "not fully optimized for production environments," and it works well for proof-of-concept projects. Read that as a scope statement rather than modesty. A Compose file with default credentials, a single host, and no described backup, TLS termination or resource limits is an evaluation environment. The Mac path adds a second constraint: Apple Silicon users cannot use the GPU through Docker, so inference either runs on CPU or runs outside the container entirely, which splits the stack across two runtimes and makes the setup less reproducible than the Linux GPU paths. The model download is a third friction point. Until Llama3.2 finishes pulling, the bundled chat workflow has nothing to call, and a first-time user watching an empty canvas may read that as a broken install rather than a slow download. None of these are defects in a starter kit. They are reasons not to promote it to production without doing the work the README leaves to you.

Where a plain Docker Compose file fits against managed platforms

The obvious alternative is a managed workflow platform with hosted models, where you sign up and get an editor without touching a Compose file. The difference is not convenience, it is where the model runs and who holds the data. With this kit, the prompts and embeddings stay on your hardware, which is what makes the README's example use cases coherent: summarizing company PDFs without data leaks, private financial document analysis, internal Slack bots. A hosted platform can do all of those too, but the data leaves your network. The second alternative is assembling the same four services yourself from their individual quickstarts. That gets you the same components with full control over versions, volumes and networking, at the cost of writing the Compose file, the health checks and the inter-service addressing that this repository already contains. The kit's value is the middle position: more control than a hosted platform, less setup than a hand-rolled stack. If your requirement is a specific Ollama or Qdrant version pinned for compliance reasons, the hand-rolled route is the honest answer, because you will be editing this Compose file anyway.

Licence, upgrade cost and what to check before you commit

The repository is Apache-2.0, which permits commercial use and modification with the usual attribution and notice requirements. That licence covers the template itself. The components it pulls have their own terms, and the README does not enumerate them, so if you plan to redistribute the resulting stack or run it as a service, check n8n's licensing separately, since n8n's own distribution terms are the ones most likely to affect a commercial deployment. This is not legal advice. On maintenance: there are no releases retrieved for this repository, so upgrades follow the Compose pull-and-recreate pattern the README documents rather than tagged versions. That means the upgrade path tracks whatever image tags the Compose file references, and you should read the diff of that file between pulls before recreating containers, because a changed tag can move you across a major version of any of the four services at once. The README also links a video walkthrough and a set of n8n documentation pages on LangChain concepts, agents versus chains, and vector databases, which is where the actual learning curve lives once the stack is running.

Editorial conclusion

Adopt it if you want a local n8n instance talking to Ollama and Qdrant on one machine for evaluation work, and you are comfortable editing .env before the first start. Skip it if you need a production topology: the README states the kit is not fully optimized for production environments. Verify first that your hardware fits a profile (gpu-nvidia, gpu-amd or cpu), that you have replaced the default secrets in .env, and that the Llama3.2 pull completes before you judge workflow latency, since the first run waits on that download.

Official sources

1. Issues
2. License: Apache-2.0
3. n8n-io/self-hosted-ai-starter-kit on GitHub
4. Project website
5. README