Platform

What it actually runs on.All of it, named.

Most platforms will not tell you this. We would rather you knew, because every choice below is one you could have made yourself, and because a platform you cannot inspect is a platform you have to take on faith.

Your code

Where it runs, and what it is wrapped in.

  • gVisor A user-space kernel between your container and the machine. Your syscalls are answered by it, not by the host.
  • Kata Containers The stronger option: a real virtual machine with its own kernel, for workloads that need the boundary drawn by hardware.
  • BuildKit, rootless Builds run without root, on machines set aside for building. A build that eats a node cannot take a running service with it.

Orchestration

The part that decides what runs where.

  • Kubernetes One cluster per region. You never see it, never configure it, and are never asked to understand it.
  • A purpose-built operator Drumlin's own controller turns a service into pods, policies and routes. Not Helm charts you have to maintain.
  • Talos Linux An immutable, API-driven operating system on every node. There is no SSH into these machines, because there is no shell on them.

Network

How a request reaches your application, and what it cannot reach.

  • Cilium eBPF networking. Policies are enforced in the kernel's datapath, where a workload has no route around them.
  • Envoy Gateway The shared ingress, configured through the Kubernetes Gateway API. One address, many hostnames, TLS terminated per name.
  • cert-manager, Let’s Encrypt Certificates issued and renewed without anybody remembering to.
  • Network policies, per environment Production cannot reach staging. Another tenant cannot reach either. That rule sits in the datapath, so nothing has to remember to obey it.

Data

Where your state lives.

  • PostgreSQL 17, CloudNativePG Managed databases, sized when you create them, with continuous write-ahead-log archiving.
  • Point-in-time recovery Restore to a moment, not to last night's dump.
  • Off-site archives Encrypted, in a second data centre, so one site failing does not take the backups with it. We have carried that restore out and timed it.
  • Persistent volumes, copied off the machine Disk that outlives a deployment, copied to the same second data centre and dated. You can put one back yourself from any copy, without asking us.
  • Hourly metering What every account holds, read at the top of each hour and written down. One invoice a month is built from those readings, and the readings stay so the invoice can be checked against them.

Secrets

How the things that must not leak are held.

  • OpenBao Transit A sealed master key that never leaves the service. Data keys are wrapped by it; the control plane can ask for a key to be unwrapped and cannot read the master.
  • Argon2id Passwords, hashed with parameters that are upgraded transparently when they are raised.
  • Sealed at rest Environment variables, connection strings and provider credentials are encrypted with keys the database alone cannot decrypt.

Observability

How you find out what happened.

  • VictoriaLogs Every line your service writes, live and historical, queryable by service and by build.
  • VictoriaMetrics Processor and memory per instance, at the resolution that makes a spike visible.
  • Vector The agent that ships both, on every node.
  • An append-only activity log Who changed what, enforced by the database itself, with staff actions in the same log.

The control plane

The part you talk to.

  • Go One modular monolith, four binaries out of one build. No service mesh of our own to debug at three in the morning.
  • PostgreSQL, replicated The platform's own database runs as a cluster, archived like a customer's.
  • River Background work such as builds, certificates and notifications, kept as durable jobs in the same database, so a restart loses nothing.
  • An OpenAPI document generated from the router The CLI, the dashboard and your scripts talk to the same API, described by the same file, and it cannot drift because nobody writes it by hand.

Region

One region, and we say where it is.

RegionNL01, Netherlands 1
ServersThe Netherlands
Operated fromGermany
Operated byUs, not resold
SandboxgVisor by default, Kata on request
BackupsContinuous, archived off-site

It runs on a single site today. A failure of that site is a failure of the platform, and we would rather write that here than explain it later. Further regions will appear on this page when they exist, not before.

You could build all of this.That is rather the point.