Note
Qurio Note #001 - Building My First Local AI Lab
Building a local AI lab with Ollama and n8n, then learning how models, containers, volumes, and self-hosted infrastructure fit together.
Purpose
Explain what building the first local AI lab taught me about the layers underneath self-hosted AI workflows.
Key Idea
The useful lesson was not just that the lab worked, but that each layer had a distinct role: infrastructure, containers, services, models, and workflows.
Explanation
I deployed two services on my Ubuntu home server using Docker Compose:
- Ollama
- n8n
The setup currently looks like:
Server
├── Ubuntu
├── Portainer
├── Ollama
└── n8n
This creates the foundation for running local AI models and building automation workflows.
Containers Are Not Virtual Machines
A more accurate understanding is that a container packages an application and its dependencies into an isolated environment.
Each container behaves like its own small system while sharing the host operating system kernel.
This makes applications easier to deploy and reduces dependency conflicts.
Images and Containers Are Different
An image is a blueprint.
A container is a running instance of that blueprint.
Example:
Image:
ollama/ollama
Container:
qurio-ollama
The image remains unchanged while containers can be started, stopped, and recreated.
Docker Compose Is Infrastructure as Code
Instead of manually starting containers one at a time, Docker Compose allows infrastructure to be described in a single file.
Running:
docker compose up -d
creates the entire environment.
This makes setups reproducible and easier to maintain.
Ports Expose Services
Applications listen on ports.
Examples:
22= SSH80= HTTP443= HTTPS5678= n8n11434= Ollama
Ports act like doors that allow traffic to reach a service.
Without exposing the correct port, the service may be running but inaccessible.
Volumes Protect Data
Containers are temporary.
Deleting a container can remove everything inside it.
Volumes solve this problem by storing important data outside the container.
For this setup:
Ollama volume stores:
- AI models
- Model metadata
n8n volume stores:
- Workflows
- Credentials
- Settings
This allows containers to be recreated without losing data.
Understanding Ollama
One of the biggest lessons was realizing that Ollama is not the AI itself.
Ollama is a runtime.
Its job is to:
- Download models
- Store models
- Load models into memory
- Serve models through an API
Without a model installed, Ollama is simply an engine waiting for something to run.
An analogy:
Docker runs containers.
Ollama runs AI models.
Understanding AI Models
The actual intelligence comes from the model.
Examples:
- Qwen
- Llama
- Gemma
- Mistral
A model contains the learned patterns, relationships, and knowledge that allow it to generate responses.
The model is what performs reasoning, summarization, writing, and question answering.
Why I Chose Qwen 2.5 3B
The first model selected for this lab was:
qwen2.5:3b
Breaking it down:
Qwen = model family developed by Alibaba
2.5 = model generation/version
3B = approximately 3 billion parameters
Parameters can be thought of as learned weights that store patterns acquired during training.
Larger models generally provide stronger reasoning and knowledge but require more memory and compute resources.
Because my server currently has 8 GB of RAM, a 3B model offers a good balance between capability and performance.
The goal of this lab is learning and experimentation rather than running the largest possible model.
What "Pulling a Model" Means
Pulling a model is similar to pulling a Docker image.
Command:
docker exec -it qurio-ollama ollama pull qwen2.5:3b
This downloads the model from the Ollama registry and stores it locally.
Once downloaded, the model can be used without needing to download it again.
The model becomes part of the local infrastructure.
Breaking Down the Command
Command:
docker exec -it qurio-ollama ollama pull qwen2.5:3b
docker
Communicates with Docker.
exec
Runs a command inside a running container.
-it
Interactive terminal mode.
qurio-ollama
The target container.
ollama
The application being executed.
pull
The action being performed.
qwen2.5:3b
The specific model being downloaded.
What Happens Internally
The process looks roughly like this:
Terminal
↓
Docker
↓
qurio-ollama Container
↓
Ollama Runtime
↓
Ollama Registry
↓
Download Model
↓
Store In Docker Volume
The downloaded model is stored in the Ollama volume, which means it survives container restarts and upgrades.
Self-Hosting Changes the Learning Experience
Using cloud services is convenient.
Running services locally forces me to understand:
- Networking
- Containers
- Storage
- Infrastructure
- Security
- Deployment
This creates a deeper understanding of how systems actually work.
First Real Infrastructure Problem
While accessing n8n I encountered a secure cookie warning.
The issue was caused by n8n expecting HTTPS while I was accessing it through HTTP.
This introduced another important concept:
Cookies can be marked as secure, meaning browsers only allow them over encrypted HTTPS connections.
For a local learning environment, secure cookies can be disabled.
For production environments, HTTPS should always be used.
Practical Use
This note gives me a clearer mental model for troubleshooting. When something breaks, I can ask which layer failed first: infrastructure, container, runtime, model, or workflow.
Related Experiments
Takeaways
The most valuable lesson from this experiment is that AI systems are built from layers.
Infrastructure
→ Containers
→ Services
→ Models
→ Workflows
- Understanding each layer makes it easier to troubleshoot problems and design better experiments.
- Self-hosting forces practical understanding of networking, storage, and deployment.
- Today was less about installing software and more about understanding how the pieces fit together.