The work clusters around a few recurring technical tracks.

These are not startup-case-study names. They are the engineering domains I keep coming back to because they expose the interesting parts: deployment friction, constrained environments, recovery paths, and the difference between something that demos well and something that holds up.

Track 01

Personal Infrastructure & Self-Hosting

I run and maintain a small personal infrastructure stack across cloud VMs, Raspberry Pis, Docker and Podman hosts, private registries, reverse proxies, Cloudflare Tunnels, and self-hosted services.

What it is

I maintain a personal infrastructure environment that spans cloud VMs, Raspberry Pi hardware, Docker and Podman containers, private registries, reverse proxies, and Cloudflare Tunnels for the services I keep close at hand.

Why it interests me

I keep coming back to this work because it is equal parts learning and control. It gives me room to shape systems around the way I actually want them to behave, instead of stopping at whatever the default path happens to be.

Stack

Cloud VMs
Raspberry Pi hosts
Docker and Podman
Private registries
Reverse proxies
Cloudflare Tunnels

Representative work

Self-hosted services deployed across mixed cloud and local hardware.
Containerized workloads routed through reverse proxies and Cloudflare Tunnels.
Private registry and image distribution patterns for personal services.

Current status

Ongoing. The environment keeps growing, and there is usually another service, workflow, or piece of network behavior worth refining.

Track 02

CI/CD, Image Builds & Private Registry

I build deployment pipelines for personal services using Forgejo runners, Docker buildx, multi-arch images, registry caching, and a private Docker registry I host myself.

What it is

I use Forgejo runners, Docker buildx, and buildx bake workflows to build, tag, cache, and publish container images for personal services through a private Docker registry I host and maintain myself.

Why it interests me

Part of the appeal is the learning, but part of it is also simple operational reality. As the number of services grows, workflow-driven builds, tagging, and deployment habits stop feeling optional and start feeling necessary.

Stack

Forgejo Actions runners
Docker buildx
Buildx bake
Multi-arch image publishing
Registry cache
Private registry auth

Representative work

The `sheldylew.com` image pipeline.
Registry cache and buildx bake workflows.
Forgejo Actions workflow tuning for private image publishing through my own registry.

Current status

Ongoing. I am still adding pieces, tightening the workflow, and customizing the setup as the stack expands.

Track 03

OpenWrt, Router Systems & Network Debugging

I experiment with OpenWrt on Linksys WRT and Velop hardware, focusing on upgrades, package systems, crash debugging, WireGuard and tunnel behavior, and network reliability.

What it is

I work with OpenWrt on real router hardware, including Linksys WRT and Velop devices, where the interesting parts tend to show up in upgrades, packages, tunnels, and recovery.

Why it interests me

This track holds my attention because it is both educational and useful. It is a way to understand the network more deeply while also building practical capabilities, including a personal VPN I can rely on.

Stack

OpenWrt
Consumer router hardware
WireGuard
Bridge and tunnel interfaces
Package and image management
Netconsole and recovery tooling

Representative work

OpenWrt upgrades and package compatibility work on Linksys WRT and Velop devices.
WireGuard and bridge or tunnel behavior under reconnect and failure conditions.
Crash debugging and recovery planning for limited-access router environments.

Current status

Ongoing. The network is stable, which makes it a good base for gradual experimentation rather than constant repair.

Track 04

Home Automation & Local-First Control

I build and tune Home Assistant automations with Docker deployment, Bluetooth presence, smart plugs, weather-based conditions, and schedule-based control.

What it is

I use Home Assistant as a local-first automation platform, with an emphasis on predictable behavior, debuggability, and keeping useful automations close to the network they depend on.

Why it interests me

It started as tinkering, but it stayed interesting once it became genuinely useful. I like the point where small automations stop feeling novel and start quietly improving daily life.

Stack

Home Assistant
Docker deployment
Bluetooth presence
Smart plugs and device integrations
Weather-aware conditions
Schedule-based automation

Representative work

Time-windowed and weather-aware automation flows.
Bluetooth presence experiments and device-triggered control logic.
Docker deployment patterns that preserve hardware access for local integrations.

Current status

Ongoing. I am still refining the system, adding useful automations, and paying attention to what actually earns its place over time.