From-Scratch Build · Self-Hosting
A single server running a whole shelf of services — file hosting, ad-blocking DNS, document editing, automation and inventory — each in its own container, all started with one command. Built from scratch to learn how to run your own cloud instead of renting one.
What it is
Most of the software people rely on — file sync, document editing, dashboards — lives on someone else's servers. This build brings that stack home. One machine hosts a curated set of self-hosted services, each running in its own Docker container, so the lab owns its data and controls its own infrastructure.
The services are grouped by what they're for. A work group covers file hosting and collaborative document editing. A network group handles DNS-level ad-blocking, reverse-proxy routing and a container dashboard. A management group adds automation and asset inventory. Each group is its own Compose stack, so you can bring up just the piece you need or the whole server at once.
The core idea I wanted to learn: a server is no longer a hand-tuned pet. With containers and Compose, an entire suite of services becomes a folder of text files — portable, reproducible, and rebuildable from scratch on any host.
The stack
The point of this rebuild was the self-hosting toolchain — how many independent services share one machine cleanly. Here is what each layer does.
Every service runs in its own isolated container, so apps with conflicting dependencies coexist happily on one host.
Each service group is described in a Compose file — images, ports and volumes — so the whole stack starts, stops and rebuilds as a unit.
Self-hosted file sync and collaborative document editing — the everyday cloud apps, kept in-house and under the lab's control.
Network-wide ad-blocking at the DNS layer plus reverse-proxy routing, so every device on the network benefits and services share clean URLs.
A landing dashboard, a container manager and an asset-inventory system — the tools that keep the server itself legible.
A flow-based automation service that ties the other pieces together and runs routine tasks without a human in the loop.
How it comes up
Standing up the whole server is a short, declarative sequence — no hand-configuration, just text files and one command per stack:
Every service group has its own Compose file describing exactly which containers it needs.
Start the DNS ad-blocker and reverse proxy first, so the rest of the services have clean routing and name resolution.
File hosting and document editing come online — the services people actually log into day to day.
Dashboards, the container manager and inventory start, giving a single pane of glass over everything.
The workflow engine ties services together and takes over recurring chores.
A top-level orchestration that launches every group together in the right order. Left as future work; for now stacks start per-group.
What it provides
Running on one box, the server quietly replaces a fistful of paid cloud subscriptions:
Each is just another entry in a docker-compose.yaml — which is what makes the whole server reproducible from text.
Reflection