Keep the product decision separate from the operating decision. A template can start the software. It does not name the people who approve changes or restore the service.
What is the n8n self hosted AI starter kit?
The official kit is an open Docker Compose template for a local AI and low-code development environment. n8n curates the project and combines its self-hosted workflow platform with compatible components for local AI workflows (GitHub).
The documented inventory is:
- n8n, the self-hosted workflow platform (GitHub)
- Ollama, the local language-model service (GitHub)
- Qdrant, the vector store (GitHub)
- PostgreSQL, the database (GitHub)
The repository includes a Docker Compose file plus preconfigured network and storage settings (GitHub). Its README also documents an environment file, machine profiles, an included workflow, local file access, and profile-specific update commands (GitHub).
The official examples include an appointment-scheduling agent, summaries of company PDFs, Slack bots for company communications and IT operations, and financial-document analysis (GitHub, n8n docs). These are example directions for builders. They are not finished client services, and AI Jungle OS does not claim to ship them.
Do not mix this inventory with other repositories. For example, local-ai-packaged is a separate project that adds components such as Supabase, Open WebUI, Flowise, Neo4j, Langfuse, SearXNG, and Caddy (local-ai-packaged). Those components are not part of the official n8n kit described here.
How is a local experiment different from a maintained private AI service?
A local experiment proves that a workflow can run. A maintained private service also has named decisions for access, change, failure, and recovery. The first half of that distinction comes from the kit's documented scope. The second half is our buyer-side rubric.
| Decision area | What the official kit documents | What this guide asks you to decide |
|---|---|---|
| Purpose | A local AI and low-code development environment for getting started and proofs of concept (GitHub, n8n docs) | Which workflows may remain experiments, and which may become a service |
| Components | n8n, Ollama, Qdrant, and PostgreSQL in a Docker Compose template (GitHub) | Which exact components your service owns and supports |
| Production boundary | The kit is not fully optimized for production and must be secured and hardened before production use (n8n docs) | Who decides that your setup is ready and records that decision |
| Access | The setup tells you to copy the example environment file and change its secrets and passwords (GitHub) | Who holds administrator access and application credentials |
| Updates | The README provides profile-specific update commands (GitHub) | Who reviews, approves, applies, and reverses a change |
| Recovery | The quick start covers startup and first-run log inspection (GitHub) | What gets restored, by whom, and how the result is checked |
This table does not define a universal production standard. It stops a common category error: reading a component list as if it were an operating model.
The missing layer is accountability, not another container. If no one owns an update or a failed workflow, the service boundary is still undefined.
How should you choose between a starter kit and an operated setup?
Choose with written answers, not with the length of the component list. Use the following checks as an editorial decision record. They do not extend n8n's support statement.
Ownership
Name the person responsible for the host and the person responsible for each workflow. State who can stop a workflow. If the same person owns both, write that down. The goal is not a large process. The goal is an answer that remains clear when something fails.
Access
List the administrator accounts and application credentials required by the setup. Record who can grant access and who can remove it. The official quick start instructs users to create .env from .env.example and update the secrets and passwords (GitHub). Our rubric adds the human ownership question.
Updates
Decide who reviews a workflow, model, or component change. Record who approves it and who can reverse it. The repository publishes different update commands for its documented profiles (GitHub). That command-level guidance does not decide your approval rule.
Recovery
Write what must return after a failure. Name the person who restores it and the person who checks the result. Also record what must be exportable if the service changes owner or stops. These are this guide's operating questions. They are not recovery features attributed to the starter kit.
Use a starter kit when the immediate job is to build and inspect a local workflow. Consider an operated setup when the workflow has users beyond the builder and your firm needs durable answers to the checks above. The label matters less than the written ownership.
How do you run the self hosted AI starter kit example?
Follow the repository's clone, profile, browser, and included-workflow path. The official deployment page directs users to the GitHub repository for the kit (n8n docs).
- Clone the official repository and change into its directory (GitHub).
- Copy
.env.exampleto.env, then replace the secrets and passwords (GitHub). - Start the Docker Compose profile documented for your machine:
gpu-nvidia,gpu-amdon Linux, orcpu. The README gives a separate path for Mac (GitHub). - Open
http://localhost:5678/, complete the n8n setup, open the included workflow, and select Chat (GitHub). - On the first workflow run, inspect the Docker console logs if Ollama is still downloading Llama3.2 (GitHub).
The README lists AI Agent, Text Classifier, and Information Extractor among the available n8n AI nodes. It points to the Ollama node for a local language model and Qdrant for the vector store (GitHub). This path gets the example running. It does not change the published production warning (n8n docs).
Can you run the starter kit on Ubuntu or Windows?
The official repository documents hardware-oriented Docker Compose profiles, not separate Ubuntu and Windows editions. It documents an AMD GPU profile on Linux, an Nvidia GPU profile, a CPU profile, and a separate Mac path (GitHub).
For Ubuntu, use the documented profile that matches the available hardware. The repository explicitly associates the AMD GPU profile with Linux (GitHub). It does not publish an Ubuntu-specific production guarantee in the supplied material.
For Windows, the supplied README does not make a Windows-specific compatibility promise. Its general documented path is the CPU profile, while its GPU text names Nvidia and AMD on Linux (GitHub). Check the current README against the exact Windows, Docker, and hardware configuration you intend to use.
In either case, the operating-system choice does not remove n8n's statement that the kit is not fully optimized for production and must be secured and hardened before production use (n8n docs).
What hardware does a self hosted AI starter kit need?
The official kit gives runtime profiles rather than one universal hardware specification. It documents paths for Nvidia GPU, AMD GPU on Linux, CPU, and Apple Silicon Mac (GitHub).
- Use
gpu-nvidiafor the documented Nvidia path. The README points first-time Docker GPU users to Ollama's instructions (GitHub). - Use
gpu-amdfor the documented AMD path on Linux (GitHub). - Use
cpufor the repository's documented path for other machines (GitHub). - On Apple Silicon, the README says the GPU cannot be exposed to the Docker instance. It offers CPU-only operation or host-native Ollama connected to n8n (GitHub).
The supplied official sources do not give a universal RAM, storage, concurrency, latency, or model-size requirement. This guide therefore does not invent one. Match the documented profile first, then evaluate the candidate model for the named workflow.
What is the best model for the starter kit?
The official kit does not rank one model as best for every workflow. Its included workflow refers to Ollama downloading Llama3.2 on the first run, and the README points to the Ollama node when you want to keep the language model local (GitHub).
Use these editorial questions when selecting a model:
- Does the candidate run on the documented hardware profile you chose?
- Must the model remain local under your chosen data boundary?
- Who evaluates the model for the named workflow?
- Who approves and reverses a model change?
Llama3.2 is the model named in the included workflow's first-run note. That fact is not a universal recommendation (GitHub). The final questions above assign responsibility. They make no performance claim.
A model choice is incomplete until someone owns the evaluation and the change decision. A default in an example workflow is still only a default.
Is the self hosted AI starter kit enough for a boutique firm?
It is enough to start a proof of concept, but the supplied official sources do not establish that the default kit is enough for production. n8n says the kit is not fully optimized for production and must be secured and hardened before production use (n8n docs).
Before client-facing use, record:
- the owner of administrator access and application credentials
- the approver for workflow, model, and component changes
- the person who reviews failures and can stop a workflow
- the recovery result that must be restored and checked
- the material that must be exportable during a handoff or exit
- the person who authorizes the move from proof of concept to production
This list is AI Jungle OS's editorial rubric. It does not promise that a specific configuration is ready for production. It also does not imply that AI Jungle OS contains n8n or the public starter kit.
If your answers already name accountable operators, the public kit may be a useful lab base. If the answers are blank, adding more components will not fill them. See the AI Jungle OS cockpit for the operating boundary this publication uses.
FAQ
Does AI Jungle OS ship the n8n starter kit?
No. This article uses the public n8n kit as a comparison point. It does not claim that AI Jungle OS ships n8n or the public starter kit.
Is the SourceForge download a different starter kit?
SourceForge describes its page as an exact mirror of the GitHub project and says that SourceForge is not affiliated with the project (SourceForge). Use the official GitHub repository as the reference for the workflow and files discussed in this guide (GitHub).
Does self-hosting define who can approve changes?
No. The deployment location does not assign a human owner. This guide treats approval and recovery ownership as buyer-side decisions, not as capabilities documented for the n8n kit.
Written by Tileo, who operates a portfolio of internet businesses on this same cockpit.