Infrastructure on Artur Rios Lab

Deploying With Yggdrasil

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

Yggdrasil is the deploy manager I built for my server. It does one job: take an application from a GitHub repository to a healthy container in the right environment, and back to the previous version if the new one does not come up. This part follows a change from a pull request to production.

One catalog

Everything yggdrasil knows comes from one file, catalog.yaml, in three layers:

Documentation Sites

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

Every project with users gets a documentation site: what it is, how to install and use it, and its reference. Heimdall’s documentation is one, and so is the documentation of my .NET libraries. They are all built the same way.

Concern	Choice
Generator	Hugo, extended edition
Theme	Docsy, as a Hugo module
Hosting	GitHub Pages
Deploys	GitHub Actions
DNS	Cloudflare, optional

Why Hugo

Hugo is a single binary that builds thousands of pages in about a second, and documentation is Markdown in a folder, next to the code it describes, reviewed in the same pull requests. Docsy is a documentation theme from Google with navigation, search and versioned sections built in.

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.

Landing Pages

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

A landing page sells something: a hero section, a grid of features, pricing, a contact or waiting-list form. It has to look polished, load fast everywhere, and occasionally do something dynamic, such as accept a form. That last part is why landing pages are not plain static sites.

Concern	Choice
Framework	Next.js, with the App Router
UI	shadcn/ui and Tailwind CSS
Hosting	Vercel, on the free tier
DNS	Cloudflare
Deploys	Vercel’s Git integration

Building one

bash

npx create-next-app@latest my-landing --ts --tailwind --app --eslint
cd my-landing
npx shadcn@latest init
npx shadcn@latest add button card input navigation-menu

shadcn/ui is not a component library installed as a dependency: it copies each component’s source into the project, built on Radix and Tailwind, so every component can be changed like my own code.

Libraries

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

Code that more than one project needs becomes a package. Mine are .NET libraries, published as NuGet packages to two places: nuget.org, where anyone finds them, and GitHub Packages, next to their source.

Concern	Choice
Package format	NuGet, or the language’s own format elsewhere
Primary feed	nuget.org
Secondary feed	GitHub Packages
Publishing	GitHub Actions, on a version tag
Versioning	Semantic versioning

Package metadata

The project file describes the package, so dotnet pack produces a complete .nupkg with its symbols alongside:

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.

Static Sites

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

A static site is rendered to HTML, CSS and JavaScript when it is built, and served as files from then on: portfolios, brochure sites, event pages and small blogs. With no code running on a server, it can be hosted for free on a CDN and will never go down for want of a patch.

Concern	Choice
Generator	Astro for content-first sites, or Next.js with a static export
Styling	Tailwind CSS
Hosting	Cloudflare Pages, or GitHub Pages
Deploys	The host’s Git integration, or GitHub Actions

Its neighbours in this series draw the line: a page that needs a form or a server function is a landing page, on Vercel, and reference documentation is a documentation site, in Hugo.

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: