Docker on Artur Rios Lab

How I Host My Projects

Wed, 21 Oct 2026 17:55:00 +0000

Every project eventually has to run somewhere, and deciding where for each one separately is how a hobby turns into a pile of accounts, bills and half- remembered setups. So I decided once, by kind of project, and every new project inherits the answer. This series describes that setup, as it runs today.

The decision table

I’m building	Stack	Hosting
A marketing or product page	Next.js with shadcn/ui	Vercel, behind Cloudflare
A static portfolio or brochure site	Astro, or a Next.js static export	Cloudflare Pages or GitHub Pages
Technical documentation	Hugo with the Docsy theme	GitHub Pages
An interactive web app	Flutter, built for the web	My server: Docker, Traefik, yggdrasil
A backend API	ASP.NET Core	My server: Docker, Traefik, yggdrasil
A reusable package	NuGet, or the language’s own format	nuget.org and GitHub Packages

The rule behind it

Anything with a running backend is self-hosted; everything else is not.

Sizing the Server

Wed, 21 Oct 2026 17:55:00 +0000

Before an application goes on the server, it should be clear that it fits. This is the model I size the server with: one figure per service for what it needs, a formula that adds headroom, and the signals that say the model has stopped being true.

The figures are starting estimates for a small production load, a few requests a second on each API, not measurements. After a week of real traffic, Grafana’s numbers replace them.

The Platform: Traefik, Monitoring and the Console

Wed, 21 Oct 2026 17:55:00 +0000

On top of the server runs one Compose project, yggdrasil, that every application shares: the reverse proxy, the monitoring, and a status API with its console. It is started once per host, and serves every environment on that host.

bash

scripts/platform.sh up

Component	Version	Job
Traefik	v3.6	Routes every request, terminates TLS
Docker socket proxies	1.13.1	Give Traefik, Alloy and the status API read-only access to Docker
Status API	.NET 10	Health, version and deploy time of every application
Console	Flutter	Shows the status API, on the web, Windows and Android
Prometheus	v3.5	Metrics, kept 30 days
Loki	3.5	Logs, kept 31 days
Alloy	v1.10	Ships every container’s logs to Loki
Grafana	12.1	Dashboards over Prometheus and Loki
Jenkins	LTS	Deploys, covered in Deploying With Yggdrasil

Traefik and one wildcard certificate

Traefik is the only container that publishes ports, 80 and 443, and port 80 does nothing but redirect to 443. It watches Docker for containers that opt in with labels, so a new application is routed the moment it starts, without touching Traefik’s configuration.

The Server

Wed, 21 Oct 2026 17:55:00 +0000

Everything self-hosted runs on one machine: the platform, the deploy server, and every application in three environments. This part covers the machine itself and what is installed on it directly, outside any container.

The machine

Resource	Spec
Provider	Hostinger VPS
vCPU	4 cores
RAM	16 GB
Disk	200 GB NVMe
Bandwidth	16 TB a month
OS	Ubuntu LTS

One machine is a single point of failure, and I accept that knowingly: these are my own projects, an outage costs me an evening, and one well-understood server is easier to keep healthy than three. Whether everything fits on it is the subject of Sizing the Server.

Web APIs

Wed, 21 Oct 2026 17:55:00 +0000

My backends are ASP.NET Core APIs, and every one of them meets the platform the same way. Heimdall’s API is the example throughout; Fortuna’s follows the same shape.

Concern	Choice
Framework	ASP.NET Core on .NET 10
Image	Multi-stage: the SDK to build, the ASP.NET runtime to run
Database	The host’s PostgreSQL, one database per environment
Configuration	Environment variables, from yggdrasil
Health	`/healthcheck`, probed by Docker, yggdrasil and the status API
Metrics	OpenTelemetry’s Prometheus exporter, on port 9464
Logs	Standard output, shipped to Loki
Checks	Tests and a Docker build in GitHub Actions

The image

The Dockerfile has two stages. The first restores and publishes with the .NET 10 SDK, copying the project files before the sources so a source-only change reuses the cached restore. The second copies the output onto the much smaller ASP.NET runtime image, and runs it as the image’s own non-root user:

Web Apps

Wed, 21 Oct 2026 17:55:00 +0000

My interactive front ends are Flutter apps, and on the web they are a set of static files: HTML, JavaScript and WebAssembly. So the container that runs one is just a web server, small and stateless. Heimdall’s web app is the example.

Concern	Choice
Framework	Flutter, built for the web
Build stage	Debian with a Flutter SDK pinned by version and checksum
Runtime	nginx, unprivileged, with a read-only file system
Settings	Compiled in at build time, once per environment
API	Its own origin’s `/api/`, routed to the API by Traefik
Health	`/healthz`
Checks	Analysis and tests, and generated code checked in GitHub Actions

The image

The build stage installs Flutter itself, rather than starting from a community Flutter image, so the exact SDK version is pinned and its download is checked against a SHA-256 checksum. It builds as a non-root user, and fetches packages with --enforce-lockfile, so the build uses exactly the versions the repository was tested with: