// the find
coleam00/local-ai-packaged
Run all your local AI together in one package - Ollama, Supabase, n8n, Open WebUI, and more!
A Docker Compose stack that bundles Ollama, n8n, Open WebUI, Supabase, Qdrant, Neo4j, SearXNG, Langfuse, and Caddy into a single local AI development environment. It's a personal fork of the n8n self-hosted AI starter kit with Supabase and several extras bolted on. Target audience is developers who want to experiment with local LLMs and workflow automation without managing each service independently.
The GPU profile system (cpu/gpu-nvidia/gpu-amd/none) with a Python wrapper script is a practical solution to a genuinely annoying Docker Compose problem — most similar projects just hand you a single compose file and wish you luck. Including both Qdrant and Supabase pgvector gives you a real choice between a dedicated vector store and a general-purpose DB, which matters at different scales. The private/public environment split at startup is a sensible security boundary for the cloud deployment case, closing ports automatically rather than leaving it as a footnote. Pre-built n8n workflows in the repo mean you can actually run something end-to-end on day one instead of staring at an empty canvas.
The README is littered with migration notices and manual .env patches for breaking Supabase upstream changes — three separate urgent update blocks in the top section alone. That's a sign the dependency pinning strategy is 'latest everything', which means any Supabase or storage-api release can silently break your setup. The ufw/Docker iptables conflict is documented as out of scope, but it's a real security hole in cloud deployments that the repo's own users will hit and won't know how to fix. Running a full Supabase stack (Kong, Pooler, Analytics, Storage, Auth, Studio) locally just to get a Postgres vector store and auth is significant overhead — it adds about 8 containers that most n8n RAG workflows don't actually need. No health checks or restart policies are visible in the compose structure, so when one of the 15+ services fails silently, you're left reading docker logs to figure out what happened.