Selfhost AI — Self-Hosted AI Automation Platform

Deploy 30+ AI and automation tools with a single command. This open-source Docker Compose template creates a complete self-hosted environment with n8n (workflow automation), Flowise (AI agents), Ollama (local LLMs), vector databases (Qdrant, Weaviate), RAG engines, Supabase, monitoring stack, and more — all pre-configured behind Caddy reverse proxy with automatic HTTPS. Plus, optionally import 300+ community workflows during setup!

Table of Contents

• Key Features
• Why This Setup?
• What's Included
• Installation
• Quick Start and Usage
• Upgrading
• Quick Commands
• Troubleshooting
• License

Key Features

• Private AI Homelab — Run LLMs locally with Ollama, keep your data on your own servers
• ChatGPT Alternative — Open WebUI provides a familiar chat interface for local AI models
• Workflow Automation — n8n with 400+ integrations, scalable queue-based architecture
• AI Agents & RAG — Flowise, Dify, LangChain, vector databases (Qdrant, Weaviate)
• One Command Install — Interactive wizard, automatic secrets, zero manual configuration
• Auto HTTPS — Caddy reverse proxy with automatic Let's Encrypt certificates
• Built-in Monitoring — Grafana + Prometheus stack included, with an n8n dashboard that tracks workflow executions (outcomes, per-workflow volume, time since last success) and ready-made alert rules for failed or stalled workflows
• Production Ready — Scalable workers, health checks, proper service dependencies
• Free & Open Source — No vendor lock-in, Apache 2.0 license

Why This Setup?

This installer helps you create your own powerful, private AI workshop. Imagine having a suite of tools at your fingertips to:

• Automate repetitive tasks.
• Build smart assistants tailored to your needs.
• Analyze information and gain insights.
• Generate creative content.

This setup provides a comprehensive suite of cutting-edge services, all pre-configured to work together. Key advantages include:

• Rich Toolset: Get a curated collection of powerful open-source tools for AI development, automation, and monitoring, all in one place.
• Scalable n8n Performance: n8n runs in queue mode by default, leveraging Redis for task management and Postgres for data storage. You can dynamically specify the number of n8n workers and task runners during installation, allowing for robust parallel processing of your workflows to handle demanding loads.
• Full Control: All of this is hosted by you, giving you full control over your data, operations, and how resources are allocated.

What's Included

✅ Caddy, Postgres, and Redis - Core services for web proxy, database, and caching, which are always included.

The installer also makes the following powerful open-source tools available for you to select and deploy via an interactive wizard during setup:

✅ Appsmith - An open-source low-code platform for building internal tools, dashboards, and admin panels with a drag-and-drop UI builder.

✅ n8n - A low-code platform with over 400 integrations and advanced AI components to automate workflows.

✅ n8n-MCP - A Model Context Protocol server that gives AI coding assistants (Claude Code, Cursor, Windsurf, VS Code Copilot) indexed access to every n8n node's documentation, property schemas and thousands of workflow templates - and, once you add an n8n API key, the ability to create and update workflows in your n8n instance straight from your IDE.

✅ n8n Assistant sandbox - Code-execution sandbox for n8n's built-in AI Assistant and the Agents preview (n8n's own sandbox service, Docker-in-Docker isolated with Sysbox; internal only, see below).

✅ ComfyUI - A powerful, node-based UI for Stable Diffusion workflows. Build and run image-generation pipelines visually, with support for custom nodes and extensions.

✅ Crawl4ai - A flexible web crawler designed for AI, enabling you to extract data from websites for your projects.

✅ Docling - Universal document converter that transforms PDF, DOCX, PPTX, XLSX, HTML, and images into clean Markdown or JSON. Features advanced PDF parsing, OCR support, and a REST API with optional web UI. Perfect for document processing in n8n workflows.

✅ Dify - An open-source AI application development platform that provides comprehensive LLMOps capabilities, including workflow management, prompt engineering, RAG pipelines, and AI agent orchestration. Perfect for building production-ready AI applications.

✅ Flowise - A no-code/low-code AI agent builder that complements n8n perfectly, allowing you to create sophisticated AI applications with ease.

✅ Gost - Versatile HTTP/HTTPS proxy for routing AI service outbound traffic through a central proxy point

✅ Gotenberg - A stateless API for converting HTML, Markdown, Word, Excel, and other documents to PDF, PNG, or JPEG. Available only within the Docker network for internal use by n8n workflows and other services.

✅ Grafana - An open-source platform for visualizing monitoring data, helping you understand system performance at a glance.

✅ InvokeAI - A professional creative engine for Stable Diffusion with a polished web UI, node-based workflow editor, inpainting/outpainting, and a REST API. Choose NVIDIA, AMD, or CPU hardware during install; models and outputs are stored in ./invokeai on the host.

✅ Langfuse - An open-source platform to help you observe and understand how your AI agents are performing, making it easier to debug and improve them.

✅ Letta - An open-source agent server and SDK that can be connected to various LLM API backends (OpenAI, Anthropic, Ollama, etc.), enabling you to build and manage AI agents.

✅ LightRAG - A simple and fast graph-based Retrieval-Augmented Generation system with automatic knowledge graph extraction, dual-level retrieval mechanisms, and incremental updates. Supports multiple storage backends (PostgreSQL, Neo4j, JSON) and embedding models.

✅ LibreTranslate - Self-hosted translation API (50+ languages).

✅ Neo4j - A graph database management system that allows you to model, store, and query data as a network of nodes and relationships.

✅ NocoDB - An open source Airtable alternative that turns any database into a smart spreadsheet with a no-code interface for building collaborative apps.

✅ Ollama - Run Llama 3, Mistral, Gemma, and other large language models locally. Optionally expose its API externally through Caddy under OLLAMA_HOSTNAME, protected by a generated Bearer token. On multi-GPU hosts you can run several instances (OLLAMA_INSTANCE_COUNT) to dedicate a GPU per model.

✅ Open WebUI - A user-friendly, ChatGPT-like interface to interact privately with your AI models and n8n agents.

✅ Open Terminal - Execution sandbox for Open WebUI agents: a real Linux shell with a filesystem, package installs, local services and Jupyter, a separate Linux account per user (internal only, see below).

✅ PaddleOCR - A CPU-ready OCR API powered by PaddleX Basic Serving.

✅ Portainer - A lightweight, secure web UI to manage your Docker environment (containers, images, volumes, networks) with ease.

✅ Databasus - Database backups & monitoring with a self-hosted UI.

✅ Postiz - An open-source social media scheduling and publishing platform.

✅ Prometheus - An open-source monitoring and alerting toolkit to keep an eye on system health.

✅ Qdrant - A high-performance open-source vector store, specialized for AI. While Supabase also offers vector capabilities, Qdrant is included for its speed, making it ideal for demanding AI tasks.

✅ RAGApp - Open-source application to build Retrieval-Augmented Generation (RAG) assistants over your data. Provides a web UI for chat and an HTTP API for integration with your workflows.

✅ RAGFlow - An open-source RAG engine based on deep document understanding with Elasticsearch backend, providing truthful question-answering capabilities with well-founded citations from complex formatted data.

✅ SearXNG - A free, open-source internet metasearch engine. It aggregates results from numerous search services without tracking or profiling you, ensuring your privacy.

✅ Supabase - An open-source alternative to Firebase, providing database storage, user authentication, and more. It's a popular choice for AI applications.

✅ Uptime Kuma - Self-hosted uptime monitoring tool with notifications

✅ WAHA - WhatsApp HTTP API (REST API) that you can configure in a click! 3 engines: WEBJS (browser based), NOWEB (websocket nodejs), GOWS (websocket go).

✅ Weaviate - An open-source AI-native vector database with a focus on scalability and ease of use. It can be used for RAG, hybrid search, and more.

Included Community Workflows

Get started quickly with a vast library of pre-built automations (optional import during setup)! This collection includes over 300 workflows covering a wide range of use cases:

🚦 What's inside?

• AI Agents & Chatbots: RAG, LLM, LangChain, Ollama, OpenAI, Claude, Gemini, and more
• Gmail & Outlook: Smart labeling, auto-replies, PDF handling, and email-to-Notion
• HR, E-commerce, IT, Security, Research, and more!
• Notion, Airtable, Google Sheets: Data sync, AI summaries, knowledge bases
• PDF, Image, Audio, Video: Extraction, summarization, captioning, speech-to-text
• Slack, Mattermost: Ticketing, feedback analysis, notifications
• Social Media: LinkedIn, Pinterest, Instagram, Twitter/X, YouTube, TikTok automations
• Telegram, WhatsApp, Discord: Bots, notifications, voice, and image workflows
• WordPress, WooCommerce: AI content, chatbots, auto-tagging

Installation

Prerequisites before Installation

1. Domain Name: You need a registered domain name (e.g., yourdomain.com).
2. DNS Configuration: Before running the installation script, you must configure DNS A-record for your domain, pointing to the public IP address of the server where you'll install this system. Replace yourdomain.com with your actual domain:
   • Wildcard Record: A *.yourdomain.com -> YOUR_SERVER_IP
3. VPS (Virtual Private Server): A dedicated VPS with a public IP address is required. Home servers, shared hosting, or localhost setups are not supported.
   • Operating System: Ubuntu 24.04 LTS, 64-bit
   • For a minimal setup with n8n, Monitoring, Databasus and Portainer: 4 GB Memory / 2 CPU Cores / 40 GB Disk Space
   • For running all available services: at least 20 GB Memory / 4 CPU Cores / 60 GB Disk Space

Running the Install

The recommended way to install is using the provided main installation script.

1. Connect to your server via SSH.

2. Run the following command:

   git clone https://github.com/kossakovsky/selfhost-ai && cd selfhost-ai && sudo bash ./scripts/install.sh
   

This single command automates the entire setup process, including:

• Preparing your system (updates, firewall configuration, and basic security enhancements like brute-force protection).
• Installing Docker and Docker Compose (tools for running applications in isolated environments).
• Generating a configuration file (.env) with necessary secrets and your domain settings.
• Launching all the services.

During the installation, the script will prompt you for:

1. Your primary domain name (Required, e.g., yourdomain.com). This is the domain for which you've configured the wildcard DNS record.
2. Your email address (Required, used for service logins like Flowise, Supabase dashboard, Grafana, and for SSL certificate registration with Let's Encrypt).
3. An optional OpenAI API key (Not required. If provided, it can be used by Supabase AI features and Crawl4ai. Press Enter to skip).
4. Whether you want to import ~300 ready-made n8n community workflows (y/n, Optional. This can take 20-30 minutes, depending on your server and network speed).
5. The number of n8n workers you want to run (Required, e.g., 1, 2, 3, 4. This determines how many workflows can be processed in parallel. Each worker automatically gets its own dedicated task runner sidecar for executing Code nodes. Defaults to 1 if not specified).
6. A Service Selection Wizard will then appear, allowing you to choose which of the available services (like Flowise, Supabase, Qdrant, Open WebUI, etc.) you want to deploy. Core services (Caddy, Postgres, Redis) will be set up to support your selections.

Upon successful completion, the script will display a summary report. This report contains the access URLs and credentials for the deployed services. Save this information in a safe place!

Quick Start and Usage

After successful installation, your services are up and running! Here's how to get started:

1. Access Your Services: The installation script provided a summary report with all access URLs and credentials. Please refer to that report. The main services will be available at the following addresses (replace yourdomain.com with your actual domain):

   • n8n: n8n.yourdomain.com (Log in with the email address you provided during installation and the initial password from the summary report. You may be prompted to change this password on first login.)
   • n8n-MCP: n8n-mcp.yourdomain.com (MCP endpoint at /mcp. Every request must send Authorization: Bearer - the token is on the Welcome Page - so a browser visit returns 401 by design. Connect with npx -y mcp-remote https://n8n-mcp.yourdomain.com/mcp --header "Authorization: Bearer ", or keep the token out of your shell history and process list with --header-file pointing at a file containing Authorization: Bearer . Starts in documentation-only mode; to also manage workflows, create an API key in n8n under Settings -> n8n API, set N8N_API_KEY in .env and run make restart. Note that outside n8n Enterprise an API key has full account access.)
   • Appsmith: appsmith.yourdomain.com (Low-code app builder)
   • ComfyUI: comfyui.yourdomain.com (Node-based Stable Diffusion UI)
   • Databasus: databasus.yourdomain.com
   • Dify: dify.yourdomain.com (AI application development platform with comprehensive LLMOps capabilities)
   • Docling: docling.yourdomain.com (Universal document converter with REST API; web UI available at /ui)
   • Flowise: flowise.yourdomain.com (Log in with the email address you provided during installation and the initial password from the summary report.)
   • Grafana: grafana.yourdomain.com
   • InvokeAI: invokeai.yourdomain.com (Stable Diffusion studio; download a model via the Model Manager on first visit)
   • Langfuse: langfuse.yourdomain.com
   • Letta: letta.yourdomain.com
   • LibreTranslate: translate.yourdomain.com
   • LightRAG: lightrag.yourdomain.com
   • Neo4j: neo4j.yourdomain.com
   • NocoDB: nocodb.yourdomain.com
   • Ollama: ollama.yourdomain.com (Optional local-LLM API; every request must send Authorization: Bearer . A leaked token grants full control — including pulling/deleting models — not just inference.)
   • Open WebUI: webui.yourdomain.com
   • PaddleOCR: paddleocr.yourdomain.com
   • Portainer: portainer.yourdomain.com (Protected by Caddy basic auth; on first login, complete Portainer admin setup)
   • Postiz: postiz.yourdomain.com
   • Prometheus: prometheus.yourdomain.com (Typically used as a data source for Grafana)
   • Qdrant: qdrant.yourdomain.com
   • RAGApp: ragapp.yourdomain.com
   • RAGFlow: ragflow.yourdomain.com
   • SearXNG: searxng.yourdomain.com
   • Supabase (Dashboard): supabase.yourdomain.com
   • Uptime Kuma: uptime-kuma.yourdomain.com (Uptime monitoring dashboard)
   • WAHA: waha.yourdomain.com (WhatsApp HTTP API; engines: WEBJS, NOWEB, GOWS)
   • Weaviate: weaviate.yourdomain.com

Optional Internal Utility: Python Runner

• What it is: An internal-only service to run your custom Python code inside the same Docker network as your other services (n8n, Postgres, Qdrant, etc.). No external ports are exposed, and it is not proxied by Caddy.
• How to enable: Select “Python Runner” in the Service Selection Wizard during install/update, or add the profile manually: COMPOSE_PROFILES=...,python-runner.
• Where to put code: Place your Python files in python-runner/. The default entry point is python-runner/main.py.
• Dependencies: Add them to python-runner/requirements.txt; they will be installed automatically on container start.

Open Terminal: execution sandbox for Open WebUI agents

Open WebUI can search, read and reason, and its built-in code interpreter runs a snippet of Python, but out of the box it cannot keep files around, install a dependency or start a local service. Open Terminal closes that loop: a Linux environment the chat drives, with a shell, a persistent home directory, apt/pip/npm installs at runtime, port proxying for local services and Jupyter kernels. Select Open Terminal in the wizard (open-terminal profile, requires open-webui). Nothing is published and there is no URL; Open WebUI talks to open-terminal:8000 over the internal network.

• Connect it once: in Open WebUI open Admin Settings → Integrations → Open Terminal and add http://open-terminal:8000 with the API key from the Welcome Page (OPEN_TERMINAL_API_KEY in .env). Add it there, not as a tool server, and not in your personal settings: the admin connection keeps the key on the server, a personal one sends it to the browser.
• Access is deliberate: a new connection is visible to admins only. Grant it to users or groups in the same dialog. Everyone you grant gets a shell inside the container (an unprivileged Linux account in multi-user mode, a sudo-capable one with OPEN_TERMINAL_MULTI_USER=false), which sits on the same Docker network as Postgres, Ollama, n8n and the rest, so treat it like giving out SSH access.
• Multi-user by default: OPEN_TERMINAL_MULTI_USER=true creates a Linux account per Open WebUI user with its own home under the localai_open_terminal_home volume. Files and processes are isolated, the network namespace is not: a local service one user starts on a port is reachable through another user's proxy URL. Set it to false for a single shared shell.
• Size and limits: the full image (latest, or a release tag such as 0.12.5 via OPEN_TERMINAL_VERSION) is about 4 GB and is the only variant that supports multi-user and runtime installs; the installer refuses a slim/alpine/openshift variant while multi-user is on. The container is capped at OPEN_TERMINAL_CPU_LIMIT=2.0 CPUs and OPEN_TERMINAL_MEMORY_LIMIT=2G; raise them in .env if the agent needs more.
• Preinstalled packages: OPEN_TERMINAL_PACKAGES, OPEN_TERMINAL_PIP_PACKAGES and OPEN_TERMINAL_NPM_PACKAGES are reinstalled on every container start, so long lists slow startup. In multi-user mode they are the only way to add apt packages, because per-user accounts have no sudo; the agent can still pip install --user and use project-local npm. With multi-user off the shell has sudo and installs anything itself.
• Egress filtering (OPEN_TERMINAL_ALLOWED_DOMAINS) is not wired into the stack: the image treats an empty value as "block all outbound traffic" and needs NET_ADMIN. If you want it, add the variable together with cap_add: [NET_ADMIN] to the open-terminal service in docker-compose.override.yml.

2. Explore n8n:

   • Log in to your n8n instance. This is your central hub for workflow automation.
   • If you chose to import the community workflows during installation, you'll find over 300 examples in your "Workflows" section. These are a great way to learn and get ideas.
   • Start building your first workflow! You have access to over 400 integrations and powerful AI tools.

3. Utilize Integrated AI Tools:

   • Connect n8n with Vector Stores: Use n8n to connect to Qdrant (accessible via its own endpoint if needed, typically qdrant.yourdomain.com), Supabase, or Weaviate (weaviate.yourdomain.com) to store and retrieve information for your AI tasks like Retrieval Augmented Generation (RAG).
   • Build with Flowise: Access Flowise at flowise.yourdomain.com to create AI agents and applications. You can trigger Flowise agents from n8n or vice-versa.
   • Interact with Open WebUI: Use Open WebUI at webui.yourdomain.com as a chat interface for your local AI models or n8n agents (e.g., using the n8n_pipe integration if configured).
   • Configure LLMs: If you wish to use large language models (LLMs) from providers like OpenAI, Anthropic, or locally via Ollama (if installed), you can easily configure credentials and connections within n8n nodes or in services like Flowise and Open WebUI.

4. Check Monitoring (Optional):

   • Visit Grafana (grafana.yourdomain.com) to see dashboards monitoring your system's performance (data sourced from Prometheus).
   • The n8n Monitoring dashboard includes a Workflow Executions section, and four alert rules are pre-provisioned: n8n workflow failed (non-manual executions only, so testing in the editor does not page), n8n workflow stalled (an active workflow with no success for 24 hours), n8n workflow has no recorded success (active for 24 hours without ever succeeding since monitoring started) and n8n metrics target down. The 24-hour thresholds are global, so workflows that run less than daily will alert; tune them in grafana/provisioning/alerting/n8n-workflows.yml. Alerts follow Grafana's default notification policy, whose built-in email contact point delivers nothing without SMTP: create a contact point (Telegram, Slack, Email with GF_SMTP_*, ...) under Alerting → Contact points and select it in Alerting → Notification policies.

Secure Access with Cloudflare Tunnel (Optional)

Cloudflare Tunnel provides zero-trust access to your services without exposing any ports on your server. All traffic is routed through Cloudflare's secure network, providing DDoS protection and hiding your server's IP address.

Benefits

• No exposed ports - Ports 80/443 can be completely closed
• DDoS protection - Built-in Cloudflare protection
• IP hiding - Your server's real IP is never exposed
• Zero-trust security - Optional Cloudflare Access integration
• No public IP required - Works on private networks

Setup Instructions

See the Cloudflare Tunnel guide: cloudflare-instructions.md

Using Libraries in n8n Code Nodes (v2.0+)

n8n v2.0 uses external task runners to execute JavaScript and Python code in Code nodes. This setup pre-configures the following libraries via n8n/Dockerfile.runner and n8n/n8n-task-runners.json:

JavaScript libraries:

• cheerio: For parsing and manipulating HTML/XML (e.g., web scraping).
• axios: A promise-based HTTP client for making requests to external APIs.
• moment: For parsing, validating, manipulating, and displaying dates/times.
• lodash: A utility library for common programming tasks (arrays, objects, strings, etc.).

Pre-installed System Tools in n8n

The custom n8n Docker image (n8n/Dockerfile.n8n) includes the following system-level tools:

• ffmpeg: A powerful multimedia framework for converting, recording, and streaming audio and video. Use it via the Execute Command node in n8n workflows for tasks like:
  • Converting video/audio formats (e.g., MP4 to MP3)
  • Extracting audio from video files
  • Resizing or compressing media files
  • Generating thumbnails from videos

n8n Assistant sandbox (AI Assistant / Agents)

n8n's built-in AI Assistant and the Agents preview build, edit and debug workflows through conversation, and on a self-hosted instance they need a code-execution sandbox before they do anything (the Instance AI settings page shows Code sandbox: Not set until one exists). Select n8n Assistant sandbox in the wizard (n8n-sandbox profile, requires n8n) and the installer adds n8n's own sandbox stack next to n8n: a one-shot certificate job, the sandbox-api service and a Docker-in-Docker sandbox-runner-1. Nothing is published; n8n talks to sandbox-api over the internal network. Budget about 4 GB of extra RAM for it.

After installation, open n8n → Settings → Instance AI and add a model API key (Anthropic, OpenAI, OpenRouter or any OpenAI-compatible endpoint). The sandbox and, when the searxng profile is active, web search through the bundled SearXNG are already wired in. n8n's docs position this bundled sandbox as the self-hosted option and Daytona as the hosted one; the Agents knowledge base is the only feature that needs Daytona.

How the runner is isolated. Docker-in-Docker normally requires a privileged container, which is root-equivalent on the host. The installer avoids that by installing Sysbox (scripts/setup_sysbox.sh) and running the runner with runtime: sysbox-runc. This installer supports Sysbox on Ubuntu 20.04/22.04/24.04 or Debian 11 (amd64/arm64) and, following n8n's sandbox service, requires a kernel newer than 5.19, Docker installed natively (Sysbox does not support the snap), /var/lib and Docker's data root on ext4 or btrfs, and a VM or bare-metal host (not an LXC or other system container). The installer also loads the br_netfilter module (the sandbox network policy needs it in both isolation modes) and, before installing Sysbox, adds bip and default-address-pools entries to /etc/docker/daemon.json that mirror Docker's current values: the Sysbox package needs them present to install without rewriting Docker's networking or restarting Docker, so running services are not interrupted. If a prerequisite is missing, or your Docker network setup is custom (-b/--bridge, --bip, --fixed-cidr or --default-address-pool flags; bridge, fixed-cidr, fixed-cidr-v6 or ipv6: true in daemon.json; no docker0 bridge), the installer asks whether to run the runner privileged instead; say No and the profile is dropped. The choice is recorded in .env as N8N_SANDBOX_RUNNER_RUNTIME / N8N_SANDBOX_RUNNER_PRIVILEGED, make doctor warns while the runner is privileged, and make update retries Sysbox. On a host you configured yourself, install the sysbox-ce package by hand (release 0.7.1; its installer registers the runtime, but refuses to run while containers exist unless daemon.json already has bip and default-address-pools, so do it with the stack stopped) and run make update.

Notes:

• Agents preview: set N8N_ENABLED_MODULES=instance-ai,agents in .env and make restart. Leave it empty otherwise; an unknown module name stops n8n from booting. The Agents knowledge base additionally needs a Daytona sandbox, which this stack does not provide.
• Versions: the three sandbox images are released together and follow :latest; set N8N_SANDBOX_VERSION in .env to pin one release for all of them. The runner downloads the sandbox image (about 330 MB) on first use after each make update or make restart, so the first assistant request after that takes a little longer.
• Certificates between sandbox-api and the runner are generated once into the localai_n8n_sandbox_tls volume and do not renew themselves. To regenerate: docker compose -p localai rm -sf sandbox-certs sandbox-api sandbox-runner-1, then docker volume rm localai_n8n_sandbox_tls, then make restart.
• Removing Sysbox: sudo apt-get purge sysbox-ce && sudo userdel sysbox; the two daemon.json entries and /etc/modules-load.d/n8n-sandbox.conf (br_netfilter autoload) are harmless and can stay.

Upgrading

To update all components (n8n, Open WebUI, etc.) to their latest versions and incorporate the newest changes from this installer project:

make update

For forks: If you maintain a fork with custom changes and want to merge updates from upstream instead of resetting:

make git-pull

This script will:

1. Fetch the latest updates for the installer from the Git repository.
2. Temporarily stop the currently running services.
3. Download the latest versions of the Docker images for all services.
4. Ask if you want to re-run the n8n workflow import (useful if you skipped this during the initial installation or want to refresh the community workflows).
5. Restart all services with the new updates.

Custom Configuration That Survives Updates

make update resets tracked files (like Caddyfile and docker-compose.yml) to the latest version, so never edit them directly. Instead, use the dedicated extension points — the files you create there are gitignored, so they are preserved across updates:

• Custom Caddy entries (e.g. reverse proxy for a service running outside this stack): drop a site-*.conf file into caddy-addon/. It is imported automatically by the main Caddyfile. See caddy-addon/README.md for examples.
• Docker Compose overrides (change any service property): create a docker-compose.override.yml in the project root. It is picked up automatically with the highest precedence.
• Settings: values you set in .env are preserved by the updater (except GOST_NO_PROXY, which is regenerated so it always covers newly added services).

Ollama on multi-GPU hosts

By default the stack runs a single Ollama container. On a machine with several GPUs you can run more, so a large model can stay resident on its own GPU instead of being swapped out whenever another model is used.

Set OLLAMA_INSTANCE_COUNT in .env (1-8) and run make update (or bash scripts/generate_ollama_instances.sh followed by make restart). Instance 1 stays the familiar ollama container; extras are ollama2, ollama3, and so on.

OLLAMA_INSTANCE_COUNT=3
OLLAMA_GPU_DEVICES=0,1     # instance 1 -> GPUs 0 and 1
OLLAMA2_GPU_DEVICES=2      # instance 2 -> GPU 2
OLLAMA3_GPU_DEVICES=3      # instance 3 -> GPU 3

OLLAMA2_KEEP_ALIVE=-1      # keep this instance's model resident forever
OLLAMA3_MAX_LOADED_MODELS=1

The runtime tuning variables — KEEP_ALIVE, NUM_PARALLEL, MAX_LOADED_MODELS, CONTEXT_LENGTH, KV_CACHE_TYPE, GPU_OVERHEAD, SCHED_SPREAD — can be set per instance with an OLLAMA_ prefix, and an unset one falls back to the global value. These take effect on the next make restart, with no regeneration needed. (OLLAMA_GPU_COUNT has no per-instance form, and OLLAMA_GPU_DEVICES does not fall back to the global OLLAMA_GPU_DEVICES — it defaults to GPU N-1.)

Notes:

• On NVIDIA, set OLLAMA_GPU_DEVICES too. Extra instances are pinned to explicit GPU IDs, but instance 1 falls back to a count-based reservation and may otherwise land on a GPU already assigned to ollama2. make doctor warns about this. On AMD, OLLAMA_GPU_DEVICES is ignored: extra instances are pinned with HIP_VISIBLE_DEVICES, while instance 1 still sees every GPU — pin it yourself in docker-compose.override.yml if that matters.
• All instances share one model store, so each model is downloaded only once.
• Extra instances are internal only, reachable at http://ollama2:11434 from other containers — for example, add it as a second connection in Open WebUI. There are no published ports; if you need external access to a specific instance, add a caddy-addon/site-*.conf file.
• Lowering the count stops and removes the surplus containers on the next make update.

Open WebUI: SQLite or PostgreSQL

Open WebUI stores chats, users and settings in either SQLite (a single file in the open-webui volume) or the stack's shared PostgreSQL. SQLite allows only one writer at a time, so with several tabs or devices open you may see:

sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) database is locked

PostgreSQL handles concurrent writes and puts the data in the same backup as the rest of the stack. Which one you get is controlled by OPEN_WEBUI_DATABASE in .env:

• New installations default to postgres.
• Existing installations stay on sqlite, deliberately. Open WebUI does not migrate data between databases — switching would give you an empty Open WebUI while your chats, users and tags stayed in webui.db.

To switch an existing installation:

1. Back up the volume first (check the exact name with docker volume ls | grep open-webui):

   docker run --rm -v localai_open-webui:/data -v "$PWD":/backup alpine \
     tar czf /backup/open-webui-backup.tar.gz -C /data .
   

2. Set OPEN_WEBUI_DATABASE=postgres in .env.
3. Run make update (not just make restart) — the openwebui database is created by make install/make update, and pointing Open WebUI at a database that does not exist gives you a container that starts and then fails every request.
4. Open WebUI comes up empty. If you want your old data, migrate it now, before registering an account — importing users into a schema that already has an admin can collide on the primary key or the unique email. Use a purpose-built tool: open-webui-postgres-migration or Open-WebUI-SQLite-migration. Prefer these over generic pgloader, which does not understand Open WebUI's JSON and blob columns.
5. Log in with your migrated account. Only register a fresh admin if you deliberately want to start empty.

To revert, set OPEN_WEBUI_DATABASE=sqlite and run make restart — the original SQLite file is left untouched.

Note that uploaded files and the vector store live in the open-webui volume in either mode, so moving the database does not make Open WebUI stateless and does not put all of its data into your PostgreSQL backup.

Security Notes

Published host ports bypass the firewall

The installer configures ufw with default deny incoming, but that does not cover Docker. Docker publishes container ports in the nat table, which is evaluated before the INPUT chain ufw uses — so any port a container publishes on 0.0.0.0 is reachable from the internet regardless of your firewall rules. See Docker: packet filtering and firewalls.

By design this stack publishes almost nothing: every service is reached through Caddy on ports 80/443 only. To audit what is actually exposed on your server:

docker ps --format '{{.Names}}\t{{.Ports}}'   # the reliable check
ss -ltnp                                      # host listeners

Trust docker ps here: with "userland-proxy": false the listener is owned by dockerd rather than a docker-proxy process, so ss output is easy to misread even though the port is published.

Anything showing 0.0.0.0:-> is internet-reachable if your server has a public IP.

• Supabase API gateway — bound to 127.0.0.1:8000 by default. Caddy still reaches it over the Docker network, and host-local tooling (curl http://localhost:8000) keeps working. To expose it deliberately, set API_GW_HTTP_PORT in .env (e.g. API_GW_HTTP_PORT=8000 for all interfaces, or API_GW_HTTP_PORT=192.168.1.10:8000 for one LAN address) and run make restart. make doctor warns if the gateway is bound to all interfaces.
• Supabase database and pooler — Supabase's upstream compose still publishes 0.0.0.0:5432 and 0.0.0.0:6543 from its supavisor service (container supabase-pooler). If you run the supabase profile on a public-IP server, restrict these at your cloud provider's firewall or security group, which is enforced outside the host and therefore not bypassed by Docker. You can close the pooler port yourself by setting POOLER_PROXY_PORT_TRANSACTION=127.0.0.1:6543 in supabase/docker/.env — that is the file Compose interpolates for the Supabase stack, and the variable is only used for the port mapping. Editing the root .env has no effect here: the installer copies it to supabase/docker/.env once and afterwards only appends keys that are missing there, and only API_GW_HTTP_PORT/KONG_HTTP_PORT/KONG_HTTPS_PORT are force-synced. Re-apply your edit after any upstream change that recreates that file. The 5432 mapping cannot be handled the same way: POSTGRES_PORT is reused as a bare numeric port throughout Supabase's own connection strings, so it cannot take an address prefix.

Cleaning up Docker

If you need to free up disk space, you can run the Docker cleanup command. This removes all unused Docker containers, images, and volumes.

make clean

This can be useful for removing old images and freeing up space, but be aware that it will remove all unused data.

Quick Commands (Makefile)

The project includes a Makefile for simplified command execution:

Installation & Updates

Monitoring & Logs

Diagnostics & Configuration

Run make help for the full list of available commands.

Community Ports

• n8n-installer-arch by @ndrewpj - Adapted for Arch-based Linux distributions (Arch Linux, CachyOS, Manjaro)

Important Links

• Based on a project by coleam00
• Original Starter Kit by the n8n team

Troubleshooting

Here are solutions to common issues you might encounter:

Sites not loading even after following the instructions

• Symptom: Your domains/sites do not open or return errors even though you completed all installation steps.
• Likely cause: Your VPS does not have enough resources for the set of services you selected.
• What to try:
  1. Check current CPU and RAM usage (e.g., with top/htop, free -h, and docker stats). If resources are saturated, upgrade the server or reduce the number of running services.
  2. Try a minimal configuration — start only n8n and verify it comes up. If it works in this minimal setup, enable other services gradually while monitoring the load.

Temporary "Dangerous Site" Warning in Browser

• Symptom: Immediately after deploying the services, your browser (e.g., Chrome) might display a "Dangerous Site" or similar security warning when you try to access your services. This warning typically disappears after some time (e.g., within a few hours or by the next day).
• Cause: This can happen for a couple of reasons:
  1. Brief use of a self-signed certificate: When Caddy (the web server managing your SSL certificates) starts up for a new domain, it might briefly use a temporary, self-signed certificate while it's in the process of requesting and obtaining a valid SSL certificate from Let's Encrypt.
  2. Delay in applying the new certificate: There might also be a short delay before the newly obtained certificate from Let's Encrypt is fully applied and recognized by all systems.
• Solution: This is usually a temporary issue and resolves itself. Give it some time. If the warning persists for more than 24 hours, check your Caddy logs for any errors related to certificate acquisition and ensure your DNS settings are correctly pointing your domain to the server's IP address. You can also try clearing your browser's cache or using an incognito/private window to re-check.

General Issues

• VPN Conflicts: Using a VPN might interfere with downloading Docker images. If you encounter issues pulling images, try temporarily disabling your VPN.
• Server Requirements: If you experience unexpected issues, ensure your server meets the minimum hardware and operating system requirements (including version) as specified in the "Prerequisites before Installation" section.

Update Script Not Working

• Symptom: The make update command fails, shows errors, or doesn't apply the latest changes.

• Cause: This can happen if your local repository has diverged from the upstream, has uncommitted changes, or is in an inconsistent state.

• Solution: Run the following command to force-sync your local installation with the latest version:

  git config pull.rebase true && git fetch origin && git checkout main && git reset --hard "origin/main" && make update
  

  Warning: This will discard any local changes you've made to the installer files. If you've customized any scripts or configurations, back them up first.

Recommended Reading

n8n offers excellent resources for getting started with its AI capabilities:

• AI agents for developers: from theory to practice with n8n
• Tutorial: Build an AI workflow in n8n
• Langchain Concepts in n8n (Langchain is a framework n8n uses for some AI features)
• Demonstration of key differences between agents and chains
• What are vector databases? (Explains tools like Supabase and Qdrant in more detail)

More AI Templates

For more AI workflow ideas, visit the official n8n AI template gallery. From each workflow, select the Use workflow button to automatically import it into your n8n instance.

AI Templates (Examples from n8n.io)

• AI Agent Chat
• AI chat with any data source (using the n8n workflow tool)
• Chat with OpenAI Assistant (by adding a memory)
• Use an open-source LLM (via HuggingFace)
• Chat with PDF docs using AI (quoting sources)
• AI agent that can scrape webpages
• Tax Code Assistant
• Breakdown Documents into Study Notes with MistralAI and Qdrant
• Financial Documents Assistant using Qdrant and MistralAI
• Recipe Recommendations with Qdrant and Mistral

Tips & Tricks

Accessing Files on the Server

The installer creates a shared folder (by default, located in the same directory where you ran the installation script). This folder is accessible by the n8n application. When you build automations in n8n that need to read or write files on your server, use the path /data/shared inside your n8n workflows. This path in n8n points to the shared folder on your server.

n8n components that interact with the server's filesystem:

• Read/Write Files from Disk
• Local File Trigger (To start workflows when files change)
• Execute Command (To run command-line tools)

Contributors

Want to see who has contributed to this project? Check out the GitHub Contributors Page!

Telemetry

This installer collects anonymous usage statistics via Scarf to help improve the project. No personal data is collected.

Data collected:

• Event type (install/update start/complete)
• Installer version
• Selected services
• OS type (e.g., ubuntu-24.04)
• Random installation ID (to correlate start/complete events)
• Country (determined by Scarf from IP, not stored by us)

To opt out, add to your .env file after installation:

SCARF_ANALYTICS=false

License

This project (originally created by the n8n team, with further development by contributors - see "Important Links") is licensed under the Apache License 2.0. See the LICENSE file for details.