A few months ago I picked up a LincStation N2 - a small box that looks like an overgrown Raspberry Pi case. The box itself is reasonably affordable; by the time you add drives the budget expands considerably. Nonetheless, the pitch was simple: a low-power, always-on machine that could sit quietly on a shelf and do homelab things.

The Foundation: Unraid

The Lincstation came with Unraid, which is not something I had heard of prior to this project. It’s not a traditional Linux distro and but it’s not NAS-only-ware in the FreeNAS sense either. It’s a middle ground: a reasonably friendly UI, strong Docker support, and a flexible storage model that doesn’t force you into RAID arrays for every drive.

Under Unraid I’m running a ZFS mirror pool — two 4TB drives (one NVMe, one SATA, which is a slightly nonstandard pairing) in a redundant mirror, and a fast 2TB NVMe drive for cache before things move to that long-term pool. ZFS presumably (I haven’t needed to use it yet) gives me checksumming, snapshot capability, and the kind of storage integrity story that lets me sleep without worrying about bit rot. Everything that matters lives on this pool.

Making Things Reachable

One of the first real problems in a homelab is the question of how do you actually reach this stuff from outside? Residential ISPs are not friendly to this - no static IP, no inbound port 80, and a firewall that assumes you’re a consumer, not a server operator.

My answer is a two-proxy chain:

NGINX Proxy Manager (NPM) sits at the edge, handles all public HTTPS traffic on port 443, terminates TLS, and routes requests to internal services by hostname. Many of my internal services are exposed this way. NPM also handles wildcard subdomains for my development environment, which it chains to the second proxy.

Caddy sits behind NPM and handles all the *.dev... wildcard traffic. It’s a purpose-built dev-farm proxy: any folder I drop into the devsites share on the NAS automatically becomes a live HTTPS URL at on my public domain. No configuration, no restart. Just drop a build artifact and it’s live.

Both proxies handle TLS certificate issuance and renewal via Cloudflare’s DNS API - even the wildcard certs. Since my ISP blocks inbound port 80, the traditional HTTP ACME challenge is not an option, so DNS-01 lets the certificate authority verify domain ownership by checking DNS records instead of making an HTTP request. This works fine with a dynamic residential IP, which I have my UDR updating automatically through Cloudflare.

The Dev Farm

The Caddy wildcard proxy isn’t just for manually deployed sites. I’ve wired it into a full CI/CD pipeline:

Gitea is my self-hosted git server, running as a container on the NAS. It’s a lightweight GitHub alternative that handles repos, issues, and the feature I care most about, Actions, a GitHub Actions-compatible CI system.

Gitea Actions Runner is a companion container that picks up CI jobs and executes them. When I push to a repo, the runner can check out the code, build it, and deploy the output directly into the dev-farm directory, which Caddy is already watching.

The result: push code → CI builds it → it’s live at a URL. The whole loop runs on hardware sitting on my shelf.

I keep a shared actions repository with reusable CI workflow templates, so new projects can opt into the full push-to-deploy flow in a few lines of YAML.

Media and Downloads

The more traditional homelab stuff is there too.

Jellyfin is my media server - open-source, self-hosted, and genuinely good for streaming movies and TV around the house (and, via NPM, away from it). This is particularly handy for sharing ripped DVDs of Community and Veronica Mars with Abby now that she’s moved into her apartment.

Sonarr handles TV show tracking — monitoring RSS feeds from Usenet indexers, noticing when a new episode of something I care about drops, and automating the download. It talks to NZBGet, a Usenet download client, which does the actual fetching. I have two Usenet providers configured for redundancy, so if one doesn’t have a release the other usually does.

The Automatic Ripping Machine (ARM) container will rip a DVD or Blu-ray if I insert one. I’ve actually been hitting up eBay pretty hard for used DVDs so that I can grow my library and cancel all of my streaming services.

Home Automation

Home Assistant is the home automation brain, running in host networking mode so it can discover devices on the local network via mDNS and Bonjour. It integrates with UniFi for presence detection (knowing who’s home), Philips Hue and Matter/Thread for lighting, and an Apple TV.

The automations I’ve built aren’t complex, but they’re genuinely useful: bedroom lights that alert when something specific is happening, arrival announcements, that kind of thing. I’ve set up a new Ulanzi TC001 LED matrix clock under the TV in the family room that visualizes everything. It shows the currently playing TV show, alerts when people get home (by detencting when their phones join the network), and even tells the time!

Mosquitto is an MQTT broker that sits between Home Assistant and the clock (an AWTRIX device). Home Assistant can push messages and data to the clock over MQTT without either party needing to know the other’s address.

The Dashboard

Homepage ties all of this together into a single internal dashboard. There are tiles for each service, live status from the Docker API, widget readouts from Sonarr and NZBGet showing what’s downloading, Jellyfin showing recent media, and links to everything else. It’s a good starting place for accessing all of the services.

Operational Discipline

The part I’m most satisfied with isn’t any single service - it’s the operational discipline I’ve built into the setup.

Everything is defined in tracked files in Gitea. Container definitions, network configurations, CI workflows, the Caddyfile, Home Assistant automations - all of it iscommitted. If this box died tomorrow, I could restore from the ZFS pool backup and the git repos and have everything running again without relying on memory.

The networking is persistent by design. Docker networks and container attachments are wired into Unraid’s startup sequence so they survive reboots and power loss, not justdocker run commands that evaporate on next boot.

The result is something that behaves more like a small production environment than a collection of experiments - reproducible, documented, and operable by future-me who doesn’t remember why anything is configured the way it is.

What’s Next

A few things are still on the roadmap:

  • Monitoring. I want host and container metrics somewhere I can actually look at them, not just hope everything is fine.
  • An AI inference endpoint. Running a shared internal endpoint that my NAS apps can use for local AI inference, so I stop sending every AI request to a cloud service, and offer generalized AI APIs for others in the household.

The LincStation is a surprisingly capable platform for something this quiet and low-power. In spite of the stack of old Linux-based systems I have on the shelf already, this is the most capable and simplest piece of hardware I’ve used for this purpose. It’s enabling functionality on my home network that I’ve had to pay external providers for, and at a quality that rivals or surpasses what they provide. I’m really happy with what it has been able to unlock.

Comments

To comment on this post, search for this URL in your ActivityPub client (such as Mastodon): https://asymptomatic.net/posts/2026-06-28-my-lincstation-home-lab

No comments yet. Be the first to reply via ActivityPub!