← All expertise

06

Infrastructure and security

Where your data lives, who can see it, and what happens when something breaks

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

From code to production
  1. Versioned recipesA host is born from a file in the repository, not from a terminal session
  2. Separate networksOne customer never sees another's network, and ingress goes through a tunnel
  3. Vaulted credentialsGenerated on the spot, short-lived, never copied into a file
  4. ReleaseDetached from the remote session and verified right after
  5. MonitoringThe light automatic remedy first, then the heavy one, then a person
  6. Restore drillPeriodic, onto a throwaway database, with the protections re-checked

Machines that rebuild identically

Every server is born from versioned recipes, not from a lucky terminal session. Procedures live in the repository next to the code they govern, and every structural choice leaves its reasoning on record.

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

The boundary is the network, not good faith

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 networks per customer and ingress through a tunnel instead of ports open to the internet.

Credentials live in a vault with short-lived certificates: the application receives keys generated on the spot, not strings copied into a config file.

Noticing before the customer does

Metrics, checks that tell "powered on" from "working", alerts that fire on useful symptoms instead of every flicker. An alarm that always rings is an alarm switched off.

Where it makes sense the reaction is automatic and graded: the light remedy first, then the heavy one, and if the problem repeats it stops insisting and calls a person. Every attempt stays on the record.

Backups we can restore, evidence that holds

An unverified backup is just a file. The restore drill must be automated onto a throwaway database and must also check that the protections really come back — not that they exist, that they work.

Recovery objectives (how much time, how much data) are declared per service and measured with periodic drills: a number never verified is a wish, a number that came out of a drill is a commitment.

The same things that keep the system up produce the evidence for an audit: append-only event log, incident history, periodic report. If producing evidence needs a person exporting by hand, that evidence will arrive late.

Portfolio

What we did on this, project by project.

Orbitas

Multi-customer private cloud on dedicated hardware

  • Three-node Proxmox cluster with separate networks per customer and tunnel ingress: no management port open to the internet.
  • Credential vault with internal certificates, service discovery and internal DNS; Ansible recipes for compute nodes, egress, vault and monthly coordinated patching.
  • Security agent on every virtual machine with per-customer isolation, vulnerability detection and file integrity monitoring.
  • Three-level automatic repair with a circuit breaker, high-availability PostgreSQL, network inventory as the source of truth.
  • ISO 27001 controls and NIS2 measures mapped onto real components, recovery objective matrix, scheduled drills and a customer dashboard with score, uptime and incident history.
  • Proxmox
  • Ansible
  • PostgreSQL
  • Vault
  • Consul
  • Wazuh
  • Grafana

CocoonServer

Multi-instance Odoo on Kubernetes

  • Isolated instances on Kubernetes with a dedicated release package and managed routing.
  • Separate volumes for modules and templates, so a container upgrade doesn't take the work with it.
  • Periodic metric collection and dashboards for instance consumption and health.
  • Kubernetes
  • Helm
  • Traefik
  • PostgreSQL
  • Grafana

SOS Bollette

Continuity of a multi-company CRM

  • Automated weekly restore drill: it rebuilds the latest backup onto a temporary database, verifies its fingerprint before touching anything, then drops it.
  • The drill does not count protections: it connects the way the application would and checks that no row comes back — the only test that exposes a restore gone silently wrong.
  • No command can overwrite the live database: a restore creates a new one.
  • PostgreSQL
  • cron
  • fingerprint verification
  • restore drills

BigFishIta

This site, in production on a dedicated server

  • Containers for application, database, proxy with automatic certificates and automations on the same machine.
  • Release detached from the remote session and verified right after; nightly database and attachment backups with retention.
  • Docker
  • Caddy
  • PostgreSQL
  • cron

Need this?

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

Let's talk