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.
What I deliver:
- Complete NixOS setup for services I deploy
- Modular config system shared across all hosts
- Declarative service configurations (web servers, databases, monitoring)
- CI/CD deployment pipelines running where you want
- Atomic upgrades with instant rollback capability
You get:
- 99.98%-99.99% uptime
- Reproducible environments (dev = staging = prod)
- Full audit trail of every system change
- One config file to rule them all
CI/CD, Containers & Orchestration
Infrastructure That Ships Itself
I don’t just administer servers — I encode the desired state, automate the path from pull request to production, and make failure visible before it becomes user-visible.
What I deliver:
- CI/CD pipelines with review gates, reproducible builds, and environment promotion
- Configuration management for NixOS, Ansible, Terraform, or the stack you already run
- Container images and deployment manifests designed for rebuilds and rollback
- Kubernetes or simpler service orchestration where it earns its operating cost
- Automated backups, restoration tests, and health-gated deployment
You get:
- A repeatable path from a reviewed change to a running service
- Small, reversible changes instead of manual production edits
- The same configuration and behavior in development, staging, and production
- Deployments that verify themselves and roll back when the new generation breaks a critical service
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.
- Review — changes are evaluated as source, with the scope of each affected host or service visible.
- Build — artifacts are built from locked inputs and the candidate generation is evaluated before activation.
- Deploy — only the affected targets change, and hand-edited production state is not part of the path.
- Settle — the system gets a bounded window to start services and reconnect dependencies.
- Verify — critical services and externally visible endpoints are probed.
- 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.
| Need | Useful default |
|---|---|
| Reproducible Linux hosts | NixOS flakes and shared modules |
| Configuration across existing servers | Ansible roles or a declarative provider |
| Application delivery | CI pipeline plus immutable container image |
| Multi-service scheduling | systemd, Nomad, or Kubernetes by operational scale |
| Recovery | Encrypted backups with scheduled restore tests |
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.