Infrastructure as Code & DevOps

Infrastructure as Code

NixOS Setup & Management

I specialize in NixOS because it turns your entire OS into version-controlled code. Every service, every config, every package — declared, not imperatively installed. The same approach carries to Ansible and Terraform where the existing stack has to be met halfway.

On a host that means:

• The machine declared in one repository, with config shared across hosts instead of copy-pasted between them
• Web servers, databases and monitoring described as code, not configured in place
• A reviewed change built into a new generation before anything is switched to
• Atomic upgrades, and a rollback that takes seconds rather than a restore

I would rather not quote you an uptime figure I cannot back. What I can show you is the rollback: the new generation is probed, and a failed probe puts the host back on the one that worked.

CI/CD, Containers & Orchestration

Infrastructure That Ships Itself

I administer servers by writing down what they should be. The desired state lives in code, the path from a pull request to production is automated, and a failure shows up before a user notices it.

That covers:

• Pipelines with review gates, reproducible builds and promotion between environments
• Configuration management for NixOS, Ansible, Terraform, or the stack you are already on
• Container images and manifests built to be rebuilt and rolled back rather than patched in place
• Kubernetes or something simpler, whichever earns its operating cost
• Automated backups with restore tests, and deploys that check themselves before they count

You end up with one repeatable path from a reviewed change to a running service: small reversible changes instead of edits made on the production box, the same configuration in development, staging and production, and a deployment that rolls itself back when the new generation breaks a service it was supposed to keep up.

One Path to Production

A deployment is a chain of decisions, not one action. I make each transition explicit and test the transition rather than assuming the previous stage was successful.

1. Review — changes are evaluated as source, with the scope of each affected host or service visible.
2. Build — artifacts are built from locked inputs and the candidate generation is evaluated before activation.
3. Deploy — only the affected targets change, and hand-edited production state is not part of the path.
4. Settle — the system gets a bounded window to start services and reconnect dependencies.
5. Verify — critical services and externally visible endpoints are probed.
6. Roll back — a failed health gate returns the target to the previous known-good generation.

Automation With Guardrails

Automation should make a narrow, repeatable change without hiding its scope. Every production path gets a deployment record, explicit event gates, and a dry-run or preview where the tooling supports one.

The important property is not automation for its own sake. It is that the same reviewed input produces the same result, and a failed deployment stops rather than continuing through later stages.

Choosing the Smallest Useful System

Not every workload needs Kubernetes. A single NixOS host, a systemd service, or a static binary may be easier to operate than a cluster. I choose the smallest design that preserves the guarantees you need: versioned configuration, tested builds, safe release, and a tested restore.

What Comes With the Delivery

I document the path, the trust boundaries, the rollback point, and the failure modes. If another engineer has to take over, the system should be legible from its source and its runbooks.

For the live signals that tell you whether the delivered path is healthy, see Monitoring & Observability. For the security controls and review layers around a deployment, see Security Engineering.