# coleam00/local-ai-packaged: a Docker Compose stack for n8n, Ollama and Supabase

> The repository bundles n8n, Ollama, Open WebUI, Supabase, Qdrant, Neo4j, Flowise, SearXNG, Langfuse and Caddy behind one start_services.py script. It is a convenience wrapper with a real upgrade tax, not a managed platform.

**coleam00/local-ai-packaged** — Run all your local AI together in one package - Ollama, Supabase, n8n, Open WebUI, and more!

- Repository: https://github.com/coleam00/local-ai-packaged
- Stars: 3,778 · Forks: 1,352
- Language: Python
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/coleam00-local-ai-packaged

## What coleam00/local-ai-packaged actually bundles

The README describes the project as an open docker compose template that bootstraps a local AI and low-code environment. The components listed are n8n for workflow automation, Ollama for local models, Open WebUI as the chat front end, Supabase for database, vector store and authentication, plus Flowise, Qdrant, Neo4j, SearXNG, Langfuse and Caddy. That is eleven services in one repository.

The intended user is someone building agent workflows who does not want to assemble the plumbing. n8n is the center of gravity: the README points to pre-built RAG AI Agent workflows stored in n8n/backup/workflows/, and the top-level directory listing confirms an n8n/ folder alongside n8n-tool-workflows/ and a single n8n_pipe.py file. If your goal is a private chat window over a local model, this is more machinery than you need. If your goal is an automation pipeline that queries your own documents, the bundled pieces line up.

The project is a fork of the n8n team's self-hosted-ai-starter-kit, which the README credits as the original. Cole's version adds Supabase, Open WebUI, Flowise, Neo4j, Langfuse, SearXNG and Caddy on top. The last push to the repository was on 2026-05-25, so it is not archived, but four months have passed since then and there have been no retrieved releases, which matters for the upgrade story below.

## How start_services.py wires the stack together

The root docker-compose.yml opens with an include directive that pulls in ./supabase/docker/docker-compose.yml. That single line explains most of the project's behaviour: the Supabase self-hosting compose file is a dependency, not a copy. When Supabase changes its own compose file or its containers, this repository inherits the change on the next pull.

The compose file defines named volumes for n8n_storage, ollama_storage, qdrant_storage, open-webui, flowise, caddy-data, caddy-config, valkey-data and four langfuse volumes. Persistence is therefore per-service and survives container recreation, which is the behaviour you want when Ollama has already downloaded several gigabytes of model weights.

Two YAML anchors configure Ollama. The service anchor sets OLLAMA_CONTEXT_LENGTH=8192, OLLAMA_FLASH_ATTENTION=1, OLLAMA_KV_CACHE_TYPE=q8_0 and OLLAMA_MAX_LOADED_MODELS=2. A second anchor, ollama-pull-llama, runs as a one-shot init container that sleeps three seconds and then pulls qwen2.5:7b-instruct-q4_K_M and nomic-embed-text into the shared volume. So a first start downloads a quantized 7B chat model and an embedding model without you issuing an ollama pull. The n8n service anchor points DB_TYPE at postgresdb with host db, meaning n8n stores its workflows in the Supabase Postgres instance rather than in SQLite.

start_services.py is the entry point and takes a --profile flag choosing the GPU configuration. The README shows gpu-nvidia, gpu-amd and cpu as the documented values.

## Installing it and starting the stack for the first time

The README's prerequisites are Python, Git or GitHub Desktop, and Docker or Docker Desktop. The clone command targets the stable branch rather than main, which is worth noting because the repository's default branch is main.

```bash
git clone -b stable https://github.com/coleam00/local-ai-packaged.git
cd local-ai-packaged
```

Next, copy .env.example to .env in the repository root. The example file carries a comment telling you to generate n8n secrets with openssl rand -hex 32, or on Windows with python -c "import secrets; print(secrets.token_hex(32))". The required block includes N8N_ENCRYPTION_KEY, N8N_USER_MANAGEMENT_JWT_SECRET, POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY, DASHBOARD_USERNAME, DASHBOARD_PASSWORD, POOLER_TENANT_ID, NEO4J_AUTH, CLICKHOUSE_PASSWORD, MINIO_ROOT_PASSWORD, LANGFUSE_SALT, NEXTAUTH_SECRET and ENCRYPTION_KEY. The .env.example ships placeholder values and the README states plainly that you must never use the example values in production.

With .env filled in, start the stack with the profile matching your hardware. Nvidia users run:

```bash
python start_services.py --profile gpu-nvidia
```

AMD users on Linux use --profile gpu-amd, and Mac users on M1 or newer cannot expose the GPU to Docker at all, so the README offers --profile cpu. Expect the ollama-pull-llama container to spend its first minutes downloading qwen2.5:7b-instruct-q4_K_M and nomic-embed-text. n8n listens on port 5678 by default, as the WEBHOOK_URL fallback in the compose file shows. The README also links a separate n8n_pipe.py integration published on the Open WebUI site for talking to n8n agents from the chat interface.

## The .env upgrade tax and the storage container failure

The most concrete limitation in this repository is not performance, it is configuration drift from the included Supabase compose file. The README carries two separate notices about variables that existing installations must add by hand.

The first concerns POOLER_DB_POOL_SIZE=5, required if the package has been running since before June 14th. The second is sharper. The Supabase storage container at storage-api v1.37.8 requires GLOBAL_S3_BUCKET, REGION, STORAGE_TENANT_ID, S3_PROTOCOL_ACCESS_KEY_ID and S3_PROTOCOL_ACCESS_KEY_SECRET. The README states that without these the storage container crashes on startup with a Region is missing error, and that the stub values work for local file-based storage. New setups get them from .env.example; anyone who pulled changes into an existing .env has to merge them manually.

This is the shape of the whole project. Because docker-compose.yml includes Supabase's own compose file, upstream container changes arrive without a version bump in this repository, and the failure mode is a container that will not boot rather than a warning. There is no documented rollback procedure in the README for a bad pull, and no retrieved releases to pin against. Treat .env as a file you diff on every update, not one you set once.

## Qdrant and Supabase both do vectors, and the README says why

Running two vector stores in one stack looks redundant until you read the README's own justification. It notes that even though you can use Supabase for RAG, Qdrant was kept because it is faster than Supabase, so sometimes it is the better option. That is an honest framing of a trade-off rather than a claim that one replaces the other.

The practical consequence is that you choose per workflow. Supabase gives you Postgres, authentication and a vector store in one place, which is convenient when your n8n workflow already writes relational rows and you want embeddings next to them. Qdrant gives you a dedicated vector engine with its own API and its own qdrant_storage volume, which suits retrieval-heavy pipelines where the embedding query is the bottleneck. Neo4j adds a third retrieval style for graph-based approaches; the README names GraphRAG, LightRAG and Graphiti as the tools it powers.

The cost is operational. Three storage systems mean three sets of credentials in .env (POSTGRES_PASSWORD, NEO4J_AUTH, plus whatever you configure for Qdrant) and three volumes to back up. If you only need document Q&A over a folder of PDFs, picking one store and deleting the others from the compose file is a reasonable edit, though nothing in the README documents that path.

## Alternatives: the n8n starter kit and Open WebUI alone

The README itself points to two alternatives, which makes the comparison easy. The first is the n8n team's self-hosted-ai-starter-kit, the upstream project this one forks. The difference in approach is scope: the upstream kit pairs n8n with Ollama and a small set of AI components, while coleam00/local-ai-packaged keeps those and adds Supabase, Open WebUI, Flowise, Neo4j, Langfuse, SearXNG and Caddy. If you want the smallest surface that still runs n8n against a local model, upstream is the narrower choice. If you want authentication and a Postgres-backed vector store without wiring them yourself, this fork has already done it.

The second alternative is Open WebUI by itself. It is the chat interface bundled here, and it can run as a standalone container pointed at any Ollama endpoint. Choosing it alone means no Supabase, no n8n, no Caddy and no Langfuse, which removes the entire .env upgrade problem described above. You lose the workflow automation and the RAG agent pipelines in n8n/backup/workflows/, and you lose Langfuse's tracing. For a single user who wants a private ChatGPT substitute, that trade is usually correct. For a team building scheduled or event-driven agent workflows, it is not.

## Licence and the cost of keeping this stack current

The repository is licensed Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files. That covers the template itself. It does not cover the bundled services, which are separate projects with their own licences, and the compose file pulls images from n8nio/n8n, ollama/ollama, flowiseai/flowise and the Supabase compose file rather than vendoring code. Anyone redistributing a modified version should check each upstream licence separately. This is a description of the repository's licence field, not legal advice.

Upgrade cost is the real ongoing expense. There are no retrieved releases, so there is no version to pin and no changelog to read before pulling. The include directive means Supabase container updates arrive with the pull. The README's own two migration notices, one for POOLER_DB_POOL_SIZE and one for the storage variables, are evidence that this has already happened at least twice. Budget for reading the README diff and merging .env keys on every update, and keep a copy of a working .env before you pull. The last push was on 2026-05-25, so the project is not archived, but the gap since then means you should check the repository state before assuming a fix has landed.

## Conclusion

Adopt coleam00/local-ai-packaged if you want n8n and Ollama running together tonight and you accept that the Supabase layer underneath will occasionally demand new .env keys before containers start. Skip it if you need a supported, versioned release train, or if you only want a chat UI, since Open WebUI alone is far less surface area. Before committing, check your GPU profile against start_services.py, confirm the .env.example values are replaced with generated secrets, and read the Supabase storage variables in the README, because a missing Region value stops the storage container from starting.

## FAQ

### What is an AI package like coleam00/local-ai-packaged?

In this project's terms it is a docker compose template that starts several AI services together: n8n, Ollama, Open WebUI, Supabase, Flowise, Qdrant, Neo4j, SearXNG, Langfuse and Caddy. The README describes it as an open template that bootstraps a fully featured local AI and low code development environment.

### Can coleam00/local-ai-packaged run AI locally?

Yes. Ollama runs the models inside Docker, and the compose file includes an init container that pulls qwen2.5:7b-instruct-q4_K_M and nomic-embed-text on first start. Mac users on M1 or newer cannot expose the GPU to Docker, so the README offers a CPU profile instead.

### What does local AI cost to run with coleam00/local-ai-packaged?

The repository does not state any pricing, and the README describes no paid tier. The software is Apache-2.0 licensed and the images are pulled from public registries, so the costs it implies are your own hardware and the electricity to run the containers.

## Sources

- [coleam00/local-ai-packaged on GitHub](https://github.com/coleam00/local-ai-packaged)
- [Issues](https://github.com/coleam00/local-ai-packaged/issues)
- [License: Apache-2.0](https://github.com/coleam00/local-ai-packaged/blob/main/LICENSE)
- [README](https://github.com/coleam00/local-ai-packaged/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/coleam00-local-ai-packaged