DevOps & Automation
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 Services.