Skip to content
Samuel Higgins
Projects
Personal ProjectInfrastructure

Home Infrastructure Lab

A personal lab for Linux, containers, remote access, local AI and GPU compute — used to understand infrastructure by running it.

Overview

This is a technical lab, not enterprise production infrastructure. It exists to keep infrastructure skills current: servers, containers, remote access, networking and local model serving.

The Problem

You cannot learn operational infrastructure only from cloud consoles. Hosts still need updates, containers still need volumes, and remote access still needs a model that is not 'port 22 on the internet'.

Requirements

  • A Linux server that can be administered remotely
  • Container workflows with a manageable UI (Portainer) and a host UI (Cockpit)
  • Private remote access (Tailscale) rather than exposing services casually
  • Room for local AI models and GPU compute
  • Self-hosted services used enough to break and be fixed

My Role

Personal environment: design, install, network, operate and break/fix. No private IPs, hostnames or network diagrams that would help an attacker are published here.

Approach

  • Prefer a small number of well-understood services over a large homelab trophy cabinet
  • Use Tailscale for access; keep inbound exposure minimal
  • Run workloads in Docker so the host stays boring
  • Treat local AI as another workload with resource limits, not as a magic box

System / Architecture

Ubuntu Server as the host. Docker for workloads, Portainer for container operations, Cockpit for host management, Tailscale for remote access. GPU compute used where models need it. Exact topology, addressing and credentials stay off this site.

Ubuntu Server
Docker / Portainer
Tailscale / Cockpit
Workloads / local AI
Lab topology, sanitised. Addressing, hostnames and credentials are not published.

Implementation

  • Ubuntu Server as the base
  • Docker and Portainer for containers
  • Cockpit for host-level administration
  • Tailscale for remote access
  • Local AI models and GPU compute
  • Routine server, network and self-hosting work

Challenges

  • Keeping the lab maintained without turning it into a second job
  • GPU resource contention between experiments
  • Backup and restore for self-hosted state
  • Resisting the urge to publish a network map

Outcome

A working lab that supports Linux, containers, remote management and local models. Useful as evidence of infrastructure fluency; explicitly not a claim of enterprise-scale operations.

  • Hands-on Linux and container operations
  • Remote access patterned on least-surprise networking
  • A place to run local models without sending everything to a hosted API

Technologies

Ubuntu ServerDockerPortainerCockpitTailscaleLinuxNetworkingLocal AIGPU computeSelf-hostingRemote managementContainer platform

What I Learned

  • Access patterns matter more than the number of containers
  • Host simplicity pays off when workloads change
  • Local AI is an operations problem as much as a model problem

Future Improvements

  • Clearer backup/restore drills
  • Tighter resource accounting for GPU jobs
  • More infrastructure-as-documented-config, still without publishing internals