IaaS
These are working notes on provisioning infrastructure and running services on it. The focus is practical. Every service page carries a compose file that has actually been run, not a paraphrase of the vendor documentation.
Most of it is exercised on a self-hosted Proxmox home lab rather than a public cloud, so the IaaS layer here is one you own and operate yourself.
The Service Model Stack
IaaS is the layer where you are handed compute, storage, and network, and everything above the hypervisor is yours to manage.
| Model | You manage | Provider manages | Examples |
|---|---|---|---|
| On-premises | Hardware, virtualization, OS, runtime, application, data | Nothing | A server you racked yourself |
| IaaS | OS, runtime, application, data | Hardware, virtualization, network | EC2, Linode, Proxmox VMs and containers |
| PaaS | Application, data | Everything below the runtime | Heroku, Fly.io, App Engine |
| SaaS | Data only | Everything | Gmail, Notion |
Self-hosting complicates that table in a useful way. Proxmox exposes the same abstraction a cloud IaaS does, an API that turns bare metal into VMs and containers on demand, except you are also the provider. You get the interface without outsourcing the hardware, and you inherit the operations work that a cloud provider would otherwise absorb.
Where Containers Fit
Containers are what you run on the IaaS layer, and the single word covers two quite different things. Getting the distinction right is usually what decides which tool a job wants.
| Virtual machine | System container (LXC/LXD) | Application container (Docker) | |
|---|---|---|---|
| Holds | A full guest OS | The userspace of a full distro | One process and its dependencies |
| Kernel | Its own | Shared with the host | Shared with the host |
| Isolation | Hardware level, strongest | Namespaces and cgroups | Namespaces and cgroups |
| Starts in | Tens of seconds | Seconds | Milliseconds |
| Treat it as | A machine | A machine | A process |
| Reach for it when | You need a different OS or a hard isolation boundary | You want a long-lived host to SSH into and configure | You are packaging and shipping a single service |
LXC and LXD covers the system container side. Everything else here is Docker.
Contents
Provisioning the infrastructure
| Page | Covers |
|---|---|
| Terraform | Declarative IaC in HCL: providers, resources, state, and the init/plan/apply workflow, plus what the Proxmox provider does with it |
| Ansible | Agentless configuration management over SSH: inventory, playbooks, roles, variables, idempotency, and where it beats or loses to Terraform |
| Pulumi | Terraform’s model driven from a real programming language, the Output[T] trap that catches everyone, and when the tradeoff is worth it |
Foundations
| Page | Covers |
|---|---|
| Docker Overview | Images, containers, and volumes, plus how a Dockerfile is layered instruction by instruction, with a CUDA PyTorch image as the worked example |
| Install Docker | Adding Docker’s apt repository on Linux, installing the engine, verifying it, and running it as a non-root user |
| LXC and LXD | System containers: how they differ from Docker, lxd init explained option by option, then profiles, storage pools, networks, and the lifecycle commands |
Orchestration
| Page | Covers |
|---|---|
| Kubernetes Overview | The reconcile loop, cluster components, the objects you actually write, probes and resource limits, the three networking layers, and when a single host means you should not use any of it |
Services
| Page | Covers |
|---|---|
| PostgreSQL | A docker run quick start through to a compose file with a persistent volume, plus connecting from another container, tuning, backups, and the usual traps |
| Dockerized PostgreSQL | The same database wrapped in a Makefile for the day-to-day operations |
| Nginx | Nginx on its own, then as a reverse proxy in front of an app container, then serving a static front end beside a proxied API |
| JupyterLab | Compose file, volume permissions, and generating the password hash |
| InfluxDB | Time series database whose entire initial setup is driven from environment variables |
| Portainer | Web UI for managing the containers already running on a host |
| Frigate | NVR with object detection, running inside a Proxmox LXC, including Coral TPU passthrough |
| Kali Linux | A full Kali desktop reached through the browser |
| Firefox | Containerized browser served over VNC, mounted at a subfolder behind a reverse proxy |
The Pattern Every Service Page Follows
The service pages are deliberately uniform: a docker-compose.yml, the command that brings it up, and the URL or port it lands on.
docker compose up --build -dRead the compose file before you run it. These examples carry placeholder values you are expected to change, including bind mounts pointing at /path/to/data, PUID and PGID fixed at 1000, and default credentials such as the InfluxDB admin password and the Firefox VNC password. They are fine on a private LAN and unsafe anywhere else.
Several pages also mount /var/run/docker.sock into the container. That grants the container root on the host, so treat it as a deliberate choice rather than boilerplate to copy.
Where This Runs
The host for most of these notes is a Proxmox home lab, which puts the IaaS layer, the containers, and the services on the same hardware.
- Software Tools covers Proxmox itself, storage, and the surrounding Linux tooling.
- Hardware Tools covers the machines underneath.
- Back End covers the applications that get deployed into these containers.
- The blog has the narrative version of the same home lab build.
Not Covered Yet
Stated plainly, so the gaps are not mistaken for oversights:
- Standing up a Kubernetes cluster. The Kubernetes page covers the model and the manifests, not the install. No k3s or kubeadm walkthrough, and nothing on RBAC, storage classes, or autoscaling.
- The lab’s own IaC. The Terraform and Ansible pages are general. The code that actually provisions this home lab lives in the
infra/directory of the parent Knowledge repo. - Public cloud IaaS. No EC2, GCE, or equivalent.
- Registries and CI. Building, tagging, and pushing images to a registry.
The two PostgreSQL pages also overlap and are worth merging.