Your Local Server: The Architect’s Lab

A local server (or a server at home, or a cheap VPS you use as a “lab”) isn’t only for production. It’s the place where you can experiment with infrastructure, self-host dev tools, and decide where your data lives. For an architect or developer who wants to understand how systems really work, having your own environment —without depending only on closed SaaS— is an investment that pays off in learning and data sovereignty.

In this article I explain why a local server can be your lab, what kind of things you can run on it, and what it implies for data sovereignty and learning.

Why your own server

Learn without fear: You can break things, reinstall, try distros, configure networks, firewalls, containers, databases. If something fails, it doesn’t affect production or a customer.
Tools under your control: Git, CI, wikis, password managers, notes, backups. If you self-host them, you choose where the data lives and how it’s accessed.
Data sovereignty: Your notes, repos, builds, and secrets can live on your machine or on a server you manage, not only in a third party’s cloud.
Real experience: Managing a server (updates, logs, monitoring, backups) gives you the same experience you need to design and operate systems in production.

A “local server” can be: an old PC with Linux, a Raspberry Pi, a NUC, or a cheap VPS (Hetzner, DigitalOcean, etc.) you use only as a lab. It doesn’t have to be expensive or complex at first.

What you need

To set up your own lab you don’t need an endless list of things. The minimum:

Hardware: A machine that can run an OS and several services. It can be a desktop PC (new or reused), a mini-PC (NUC, Mini-ITX), a Raspberry Pi for a very light start, or a cloud VPS if you prefer not to have hardware at home.
Operating system: Linux (Ubuntu Server, Debian, Proxmox as hypervisor, etc.) is the usual choice for servers; you get used to the same kind of environment you’ll see in production.
Network: Stable connection and, if you want access from outside, a router that allows VPN (WireGuard, Tailscale) or controlled port forwarding. You don’t have to expose anything to the internet at first.
Storage: Enough disk for the OS, containers or VMs, databases, and backups. SSD makes a big difference; size depends on how many services and how much data you want.
Time and willingness: Some time to install, configure, and maintain (updates, backups, basic monitoring). You can start with one service and grow from there.

You don’t need the most powerful machine to learn. A modest setup is enough to run Proxmox, several containers, databases, and monitoring tools. If you later want more performance or more services, you scale up.

My homelab: a real example

I have a homelab at home. That’s where I do all my testing, run all my programs, and keep all my tools under my control. It’s the lab where I experiment with infrastructure, databases, and microservices without depending on a shared environment.

Stack I run:

Virtualization: Proxmox — multiple VMs and containers to isolate services and try different configurations.
Monitoring and observability: Uptime Kuma (check that services are up), Prometheus (metrics), Grafana (dashboards), Grafana Loki (logs). The full observability stack at home.
Errors and tracing: Sentry — to capture application errors and see traces when I develop or test microservices.
Databases: Postgres (relational), Dragonfly (Redis-compatible, very fast), TimescaleDB (time series for metrics and telemetry). Different engines for different workloads.
Own services: My own S3 for microservices (objects, blobs) written in Go, and my password manager self-hosted. Critical tools —storage and secrets— live on my infrastructure.
Other tools: Everything I use daily for development, testing, and operations: Git, CI, wikis, backups, etc.

Homelab hardware:

Case: Model Dryft Mini-BK-v1 (compact gamer chassis).
CPU: Intel Core i7-13700.
Motherboard: Gigabyte Z790 Eagle AX.
RAM: 2×32 GB DDR5 Corsair Vengeance at 6000 MHz (64 GB total).
Storage: 2× XPG Gammix 570 Blade 1 TB (2 TB NVMe).
Cooling: Nautilus 360RS ARGB — liquid cooling for the CPU.
Power supply: Corsair RM850e (850 W).

With this I run Proxmox, multiple VMs and LXC, all the databases, Prometheus, Grafana, Loki, Sentry, Kuma, my Go S3, the password manager, and the rest of the services without issue. It’s a “serious” homelab but in a compact form factor; the i7-13700 and 64 GB of RAM give plenty of headroom to experiment with real workloads and many services at once.

What you can run (ideas)

Self-hosted Git: Gitea, Forgejo, or GitLab. Private repos, basic CI, without depending only on GitHub/GitLab.com.
Wiki / docs: BookStack, Wiki.js, MkDocs, or similar. Internal docs, runbooks, architecture notes.
CI/CD: Jenkins, Drone, Gitea Actions, or GitLab CI on your instance. Pipelines that run on your infrastructure.
Containers: Docker (and optionally Docker Compose or light Kubernetes). Learn to package services, networks, volumes.
Databases: Postgres, Redis, etc., in containers or installed on the host. Performance tests, replicas, backups.
Monitoring and logs: Prometheus, Grafana, Loki, or lighter stacks. Centralized metrics and logs to understand system behavior.
VPN / remote access: WireGuard or Tailscale. Secure access to your lab from outside without opening ports to the world.
Productivity tools: Notes (Outline, Trilium), password manager (Vaultwarden), task lists. Your data on your server.

You don’t need to run everything at once. You can start with one service (e.g. Gitea or a wiki) and add more as needed.

Data sovereignty

“Data sovereignty” here means: deciding where your data lives and who can access it. If everything is on GitHub, Notion, Google Drive, and Dropbox, you depend on their policies, outages, and pricing. With your own server (local or VPS):

Backups: You define what gets copied, where, and how often.
Privacy: Sensitive data (notes, internal docs, builds) can stay on your network or on a server you control.
Availability: If the SaaS has an outage, your wiki or Git are still available if they run on your server (and if your network/server are set up correctly).

It’s not “all or nothing”: you can have public repos on GitHub and private repos or CI on your server; notes in your wiki and others in Notion. The idea is to have the option to self-host what you want to control.

Minimal operations

A lab also implies some operations:

Updates: Security patches for the OS and for services you expose (web, SSH, etc.).
Backups: Copies of important data (repos, wikis, configs) to another disk or location.
Basic security: SSH with keys, firewall (only needed ports), optionally fail2ban or similar. If you expose something to the internet, harden it.
Light monitoring: Knowing if the server is up and if services respond (even with a simple script or healthcheck).

You don’t need a DevOps team; with some discipline and automation (scripts, cron, Docker) you can keep a lab stable.

My personal perspective

A local server (or a VPS used as a lab) is one of the best “gyms” for an architect or developer: you learn how services really work, how they’re configured, how they fail, and how to recover. It also gives you sovereignty over part of your data and tools, without having to put everything in a third party’s cloud.

My homelab is exactly that: the place where I do all my testing, where I run Proxmox, Kuma, Sentry, Prometheus, Grafana, Loki, Postgres, Dragonfly, TimescaleDB, my Go S3, and my password manager. All my tools in one place, under my control. It doesn’t replace the cloud or SaaS when they make sense (collaboration, scale, zero maintenance). It complements: you have a place to experiment, self-host what you want to control, and make conscious decisions about where your code and information live. If you’ve never had your own server, starting small —a Git, a wiki, a container— already opens the door to that lab.