Arthur Sommer

Now

Mon, 17 Aug 2026 00:00:00 +0000

A short status file for August 2026.

Building

Publishing this website from the homelab and refining the writing as the projects evolve.
Hardening a three-layer Caddy design for public, tailnet, and local traffic.
Maintaining caddy-tls-file-pair, a custom certificate loader for Caddy.
Improving monitoring for backups, power events, reverse proxies, mail, and the small failures that become large failures if nobody notices.

Learning

How to make self-hosted infrastructure easier to recover, not merely more elaborate.
Where containers clarify system boundaries and where they hide too much.
How far useful documentation can be generated from real configuration without publishing private details.

Site status

Component	State
Hugo source	Ready
Initial writing	In progress
On-prem origin	Online
Public DNS cutover	Complete

This page follows the spirit of a /now page: it changes when my attention changes, without pretending to be a complete activity feed.

One Certificate, Three Caddy Servers

Sat, 15 Aug 2026 00:00:00 +0000

My homelab has three reverse-proxy roles. A public edge accepts internet traffic. An internal proxy serves devices connected through Tailscale. A local proxy keeps LAN services usable without taking a detour through the public internet.

All three answer for names under the same domain, but I did not want all three carrying AWS credentials or independently completing Route 53 DNS challenges.

 ACME DNS-01
 |
 v
internet ----------> caddy-external
 |
 shared certificate storage
 |
 +-------+-------+
 | |
 caddy-internal caddy-local
 tailnet LAN

The awkward middle state

The public edge could renew a wildcard certificate and place it on shared storage. The other proxies could load the PEM files with Caddy’s normal tls directive. The trouble was lifecycle: those consumers did not naturally notice when the files changed. A timer could compare certificate serial numbers and reload Caddy, but that introduced more state and another piece of automation whose only job was compensating for the configuration model.

Start a Homelab Without Overthinking It

Sat, 15 Aug 2026 00:00:00 +0000

You do not need a rack, enterprise servers, or a complicated network to start a homelab. You need a computer you can leave running, a problem you want to solve, and a willingness to document what you change.

Begin with one useful service

Choose something you will actually use: network-wide DNS filtering, a personal dashboard, a media server, or a private Git forge. A used mini PC is usually a better first server than retired enterprise hardware because it is quiet, efficient, and easy to live with.

Why This Site Is Moving Home

Sat, 15 Aug 2026 00:00:00 +0000

For years, arthursommer.com was a small static page sitting behind AWS CloudFront. It worked, in the narrow sense that it continued returning HTML, but it stopped representing me or the work I was doing.

The replacement is deliberately simple. Hugo turns Markdown into static files. Caddy serves them. The source and deployment process live with the rest of my infrastructure documentation. There is no database, application runtime, tracking script, or client-side framework to maintain.

About

Mon, 01 Jan 0001 00:00:00 +0000

I’m Arthur, a computer scientist, infrastructure enthusiast, and longtime builder of things that combine software with the physical world.

My homelab is where I learn in public. It gives me a place to operate real services, test ideas, automate repetitive work, recover from questionable decisions, and understand the systems I depend on. I care about owning my data, documenting what I learn, and making complicated technology approachable.

Outside the server rack, my background includes technical theatre, live sound, lighting, and web development. The common thread is systems: understanding how the pieces connect and making the result dependable for the people using it.

Homelab

Mon, 01 Jan 0001 00:00:00 +0000

The homelab is a hybrid collection of local hardware and carefully selected remote infrastructure. It runs the services I use, provides a realistic environment for experiments, and gives each mistake somewhere educational to happen.

Design principles

Own the important data. Storage, backups, and recovery plans matter more than dashboards.
Private by default. Internal services live behind Tailscale and split DNS unless they genuinely need public access.
Configuration is documentation. Important service configuration is captured in Git alongside operational notes.
Observe before guessing. Metrics, logs, probes, and alerts should explain what a system is doing.
Prefer understandable systems. Clever machinery eventually needs maintenance at an inconvenient hour.

Simplified topology

public internet
 |
 v
caddy-external ---- encrypted tailnet ---- caddy-internal
 |
 +--------------------------+------------------+
 | | |
 services storage monitoring

The lab uses Incus containers for system-level isolation, Docker Compose where application packaging makes sense, Caddy for public and private routing, Tailscale for the encrypted service network, and Prometheus-compatible monitoring for visibility.

Projects

Mon, 01 Jan 0001 00:00:00 +0000

Caddy TLS file-pair module

A custom Caddy module for loading an existing certificate and key pair while preserving useful certificate-selection behavior. I built it to support a homelab design where one public Caddy instance handles ACME DNS challenges and internal instances consume the resulting wildcard certificate from shared storage.

The project grew from a practical constraint: several Caddy instances needed the same certificate, but only the public edge should hold Route 53 credentials or perform renewal.

Uses

Mon, 01 Jan 0001 00:00:00 +0000

This is not a shopping list. It is a snapshot of tools that have earned a place in the system by being useful, understandable, or both.

Infrastructure

Tool	Job
Incus	System containers and virtual-machine management
Docker Compose	Packaging application stacks that already live in containers
Caddy	Public, tailnet, and LAN reverse proxies; automatic HTTPS
Tailscale	Encrypted connectivity between sites, machines, and services
Bind	Split DNS for private names on the tailnet
Ceph and ZFS	Storage experiments with very different operational personalities

Operations

Tool	Job
Forgejo	Git hosting, package publishing, and build automation
Prometheus	Metrics, rules, and the starting point for alerts
Grafana	Dashboards when a graph answers the question better than a log
Promtail	Shipping journal and application logs
NUT	UPS state, power-event handling, and coordinated shutdowns

Working preferences

Plain Markdown for notes and runbooks.
Configuration beside the incident report that explains why it exists.
Small purpose-built exporters instead of pretending every useful signal arrives in a standard integration.
Stable, low-power machines before loud retired enterprise hardware.
A terminal and Git before a management dashboard that cannot be reproduced.