← All expertise

03

Infrastructure and DevOps

I always use the same yardstick: if this machine disappeared tonight, how long would it take to rebuild it identically? If the answer is "depends what I remember", the infrastructure isn't finished.

Repeatable provisioning, not documented from memory

Every host is born from versioned roles and scripts, not from a lucky SSH session. Operating procedures live in the repository next to the code they govern, and every structural choice leaves a decision record explaining why — so whoever comes next doesn't reverse it by accident.

Destructive operations have explicit semantics and are repeatable: re-running must do no harm, and that has to be tested rather than hoped for.

The network is the first boundary

Separating customers at the network layer costs more effort than filtering them in code, but it is the only layer that holds when the code is wrong: dedicated overlays, per-tenant routing, and ingress through a tunnel instead of ports exposed to the internet.

Secrets live in a vault with an internal PKI and short-lived certificates; the application receives credentials generated on the spot, not strings copied into a config file.

Releases you can redo (and undo)

Reproducible container builds, a release detached from the SSH session that launches it (a dropped connection must not leave a half-finished deploy), a state check right after, and a rollback path designed beforehand rather than during the incident.

Portfolio

What I did on this, project by project.

Orbitas

Multi-tenant private cloud on bare metal

  • Three-node Proxmox cluster in a German datacentre, with an EVPN/VXLAN overlay and VRFs isolating customer networks.
  • Service discovery and internal DNS with Consul, secrets and PKI with Vault, credentials handed to applications by agents that renew them autonomously.
  • Ingress through a Cloudflare Zero Trust tunnel: no management port exposed to the internet.
  • High-availability PostgreSQL, Ansible roles for compute nodes, egress nodes, vault and coordinated patching; a shared library of operational scripts installed on targets with make.
  • NetBox as CMDB with a documented IP allocation plan: the network has a source of truth, not a spreadsheet.
  • Proxmox VE
  • EVPN/VXLAN
  • Consul
  • Vault
  • Ansible
  • PostgreSQL HA
  • Cloudflare Zero Trust
  • NetBox

CocoonServer

Multi-instance Odoo on Kubernetes

  • Isolated Odoo instances on K3s with a dedicated Helm chart, Traefik ingress and middleware for authentication and routing.
  • Separate persistent volumes for custom modules and database templates, so a container upgrade doesn't take the module work with it.
  • A metrics CronJob and Grafana dashboards to keep instance consumption and health in view.
  • Kubernetes (K3s)
  • Helm
  • Traefik
  • PostgreSQL
  • Prometheus
  • Grafana

Manora

Layer 2 chain infrastructure

  • Docker Compose stack with the Nitro sequencer, a public RPC node, the batch poster towards L1, PostgreSQL, Redis, Prometheus and Grafana.
  • Separate networks for development, testnet and mainnet with distinct chain ids for replay protection, plus a hardening document dedicated to the mainnet move.
  • Docker Compose
  • Arbitrum Nitro
  • PostgreSQL
  • Redis
  • Prometheus
  • Grafana
  • Terraform

BigFishIta

This site, in production on a VPS

  • Docker Compose with the application, PostgreSQL, a Caddy reverse proxy (automatic TLS) and n8n on the same machine.
  • Release detached from the SSH session and verified right after; nightly database and attachment backups with retention and a restore script.
  • Docker Compose
  • Caddy
  • PostgreSQL
  • n8n
  • cron
  • rsync

Need this?

Tell me the problem and I'll tell you how I would tackle it — and if it isn't worth doing, I'll tell you that too.

Let's talk