DevOps and infrastructure consulting

There are teams where deploying is a ritual: it happens on Tuesday mornings, the same person always does it, and nobody breathes until it's over. Where production secrets live in a shared spreadsheet. Where backups happen —but nobody has ever restored one—. And where the cloud bill goes up every month without anyone being able to explain why.

If any of these sound familiar, the problem is not your team: it's that the infrastructure grew by patches and nobody has treated it as what it is, part of the product.

My take after years of building this: good DevOps is the kind you don't notice. PRs that spin up their own environment, secrets that don't live in a spreadsheet, backups proven by restoring them. That's what I offer as consulting, and what I operate myself every day.

What “not noticing it” means

You notice it in what stops happening:

• You open a pull request and a complete environment appears — with its database, its secrets, and its domain — without anyone touching anything. Reviewing code stops being reading blind.
• A secret rotates without an emergency meeting: it's changed in a single place and reaches only where it has to reach.
• The day something breaks, restoring is following a runbook, not a leap into the void.

All of this is boring engineering, done with care and kept in Git.

What I build

• CI/CD that actually speeds you up. Pipelines people aren't afraid to touch: parallel tests, well-placed caching, strict manifest validation, and secret scanning. A slow or fragile pipeline is not a nuisance: it's a tax on every change.
• GitOps. All infrastructure declared in Git: push to main and it's in production, with ArgoCD watching that the cluster doesn't drift from what's declared. Rolling back is reverting a commit.
• Preview environments per PR. Every pull request spins up its namespace, its database, and its domain, and deletes itself when closed. At Konect, previews boot with a copy of the real data, so migrations are tested against the real schema.
• Secrets management. Infisical as the source and External Secrets to inject them where they belong. Goodbye to the spreadsheet: every secret has a place, an owner, and a history.
• Backups that get restored. Continuous backup and staggered retention, yes, but above all tested restores and a written runbook. A backup you've never restored is a hope, not a backup.
• Self-hosting with numbers. Sometimes it pays to leave the cloud and sometimes it doesn't. I settle it with numbers, not ideology: hardware, power, and hours against your bill, and you decide with data.
• Self-hosted CI runners. Self-hosted runners that scale from zero to several depending on the workload, with a custom image. No billed minutes and no waiting queues.

How I work

1. Audit. I measure what's there: how long a deploy takes, who can do it, where the secrets live, when the last backup was restored. Without data there's no plan, just opinions.
2. Plan ordered by risk. First whatever is on fire: almost always secrets and backups; then the pipeline.
3. Build in Git. Everything ends up declared in your repository, with its runbooks. The infrastructure stays with the team: I don't create dependencies.
4. Handover. I train whoever will operate it and stay available, but the goal is that you don't need me.

Where the experience comes from

I don't sell anything I don't operate myself. At Konect we built the full platform: Kubernetes with GitOps, our own Harbor registry, secrets in Infisical, devcontainers for the whole team, and a preview environment for every pull request that replicates staging by copying its data.

On my own infrastructure — the one serving this website, with clients on top — I apply the same: ArgoCD in app-of-apps mode, ApplicationSets that generate environments from a JSON file, and self-hosted runners that scale to zero when there's no work; even the runner image builds itself. I tell the whole story in the homelab Kubernetes and GitOps post.

And the topic that worries me most when I walk into a new place: backups. All of mine converge on the MinIO store running on spinoza, the TrueNAS box — restic and k8up keep the copies there, on the other side of the Tailscale gateway, cervantes —. PostgreSQL has continuous WAL archiving and a daily backup with point-in-time recovery to any moment in the last 30 days, and restores are tested by restoring. The details, including the remaining debt, are in the backups and restore post.

When it makes sense (and when it doesn't)

It fits if you have a product team without anyone full-time on platform, if deploying feels daunting, if nobody has ever restored a backup, or if the cloud bill grows without explanation. Also if you want to self-host but lack someone who has done it before in production.

It doesn't fit if your deploy is already boring and your restores are tested — congratulations, you don't need me. Nor if you want to outsource operations forever: I build the system so your team runs it, not so you depend on me.

Related consulting

IT governance: who gets in, who can deploy, and how you prove it

Jun 24, 2026ConsultingGovernance

Building a homelab from scratch: Kubernetes and GitOps - Homelab (03/06)

May 9, 2026Case studyHomelab

Setting up a homelab from scratch: backups and restore - Homelab (06/06)

Jun 18, 2026Case studyHomelab

One deployment per customer or one space per customer

Aug 4, 2026ConsultingMulti-tenancy

From standard to graph to project

Jun 22, 2026Case studySingular Solving

Platform architecture consulting

Jun 8, 2026ConsultingArchitecture