DevOps & Platform Engineering
We run the rails every release rides on — the build pipeline, the canary rollout, the secret store, the SLO dashboards and the rollback lever an on-call engineer can pull at 3am without waking anyone else. We do not ship features; we ship the confidence that lets other teams ship features. A good week is one nobody noticed, because nothing broke.
Deploys per day, progressive
Mean Time To Restore
Platform availability floor
Secrets in git, ever
Why DevOps
The platform is the contract between engineering and reality
A feature that cannot deploy safely is not a feature — it is a liability we have not yet paid for. We treat the platform as the contract between what engineering writes and what reality accepts: every commit builds reproducibly, every artifact carries an SLSA provenance attestation, every deploy is progressive, every secret lives in a manager that never sees git, every SLO has an alert wired to a runbook an on-call can execute at 3am. We are the team that says "yes, ship it" — and we earn that by being the team that can also say "and here is the revert lever if it breaks". The platform is the evidence that trust is engineered, not promised.
We refuse the superstition that DevOps is "the people who restart things". Our work starts in the IDE — a developer pulls a template that already has CI, IaC, secrets management and observability wired in — and ends in the runbook the on-call reads at 3am. We treat infrastructure as code, review it like application code, and test it like product code: a Terraform change runs through plan, policy and cost gates before it applies, and a Kubernetes manifest is linted, scored against best practices, and drifted-detected in production. The boring tools — Postgres, Kafka, Kubernetes, Terraform, OpenTelemetry — are boring on purpose. Exciting infrastructure is a liability we cannot afford on a critical path.
What we build
The rails every release rides on. Here is what we own end-to-end.
CI/CD Pipelines
Every commit builds reproducibly, runs the full test suite, signs the artifact, and ships behind a progressive rollout. A failed build never reaches production; a broken release reverts itself.
Infrastructure as Code
Terraform modules reviewed, policy-checked and cost-scored before apply. A cloud resource that is not in version control does not exist in production, full stop.
Secrets & Key Management
Secrets live in a manager that never sees git; keys are rotated, audited and access-listed. A leaked secret is detected and revoked within minutes, not discovered in a postmortem.
Progressive Delivery
Canary rollout to 1% then 10% then 100%, with automated rollback on SLO breach. The deploy that fails a critical-flow test reverts before a human reads the alert.
Observability Platform
Metrics, logs and traces linked by trace id, shipped to a single pane. Any incident can be replayed event-by-event; the dashboard is a convenience, the log is the contract.
SRE & On-Call
SLOs, error budgets, runbooks and an on-call rotation that pages a human only when a job cannot. We do not wake people for things automation can fix.
How we work
Our loop is platform-first: the rails ship before the feature. Here is one orbit, from template to canary.
Pull a reviewed template
Developers pull a service template that already has CI, IaC, secrets management and observability wired in — the boring choices are made once, by the platform team.
Build reproducibly
Reproducible builds, signed artifacts, SLSA provenance attestation. The artifact that runs in production is the same artifact that ran in CI, byte-for-byte.
Plan, policy, cost
IaC changes run through terraform plan, OPA policy, and cost estimation before apply. A resource that breaks policy or triples the bill does not apply.
Deploy progressively
1% then 10% then 100%, with automated rollback on SLO breach. The critical-flow test suite runs against every stage before promotion.
Observe and alert
SLO dashboards, error budgets, and alerts wired to runbooks. An alert that fires more than twice triggers a runbook-fix backlog item automatically.
Postmortem & improve
Every incident gets a blameless postmortem with a root-cause and a preventive action that lands as code — a new alert, a new test, a new policy gate.
Definition of done
A platform change ships only when all of this is true
Reproducible
Builds reproducible, artifacts signed, SLSA provenance attested. The artifact in production is byte-for-byte the artifact in CI.
Revertible
Every change has an automated rollback path tested before the forward path ships. A revert takes minutes, not a maintenance window.
Observable
Metrics, logs and traces linked by trace id; the SLO dashboard and the alert are wired before the change ships, not after.
Policy-checked
IaC changes pass terraform plan, OPA policy and cost estimation gates. A resource that breaks policy or triples the bill does not apply.
Documented in runbook
The on-call runbook is updated by the engineer who shipped the change, not reverse-engineered later. An alert without a runbook does not ship.
Tools & why we use them
Boring on purpose. Each tool was chosen for its failure mode, not its demo.
The boring orchestrator. We run a managed control plane; the cost of running our own would be paid in 3am pages we do not want.
IaC reviewed, planned, policy-checked and cost-scored before apply. A cloud resource not in version control does not exist in production.
GitOps progressive delivery; canary to 1% then 10% then 100% with automated rollback on SLO breach.
Metrics, logs and traces in one standard, linked by trace id; any incident replays event-by-event.
Secrets manager that rotates, audits and access-lists. A leaked secret is detected and revoked within minutes.
Signed artifacts and provenance attestation; the artifact in production is the artifact in CI, byte-for-byte.
Policy-as-code gates IaC before apply; a resource that breaks policy does not apply, regardless of who merged it.
Single pane for metrics, logs and traces. The dashboard is a convenience; the underlying data is the contract.
How we interface
Where DevOps meets the rest of the company
Backend
Backend owns the SLO; we own the canary, the rollback lever and the runbook. Neither of us ships a critical path without the other's sign-off.
Frontend
We ship the Lighthouse gate together; frontend owns the perf budget, we own the build pipeline. A perf regression does not merge, regardless of who introduced it.
QA
The critical-flow test suite runs against every canary stage before promotion. QA owns the scenario matrix; we own the progressive delivery that runs it.
Data
Data exports are events off the audit log; we own the Kafka topic that feeds the analytics warehouse without pinning the write buffer.
Questions we get asked
How often do you actually deploy to production?
Thirty-plus times a day on a normal day. We can ship that often because each deploy is small, observable, and instantly revertible — not because we are brave.
What happens when a deploy breaks production?
Automated rollback fires on SLO breach before a human reads the alert. The critical-flow test suite runs against every canary stage; a failure at 1% reverts within minutes. Most rollbacks are over before the on-call is fully awake.
How do you keep secrets out of git?
Secrets live in Vault; CI injects them at runtime. A pre-commit hook scans for high-entropy strings, a CI scanner blocks merges that contain secret-shaped content, and a leaked secret is detected and revoked within minutes by rotation.
What is on-call like?
One week primary, one week secondary, then four weeks off. Runbooks are written by the engineer who shipped the system. We do not page humans for things a job can catch; an alert without a runbook does not ship.
Do you really use error budgets to gate features?
Yes. Spend the budget on features, run out, and deploys freeze until reliability pays it back. It is the only objective rule we have found that makes product and engineering argue about reliability instead of feelings.
Our mission
Build the rails every release rides on — reproducible, observable, revertible. We do not ship features; we ship the confidence that lets other teams ship features. A good week is one nobody noticed, because nothing broke — and the evidence of that is on the dashboard, not in the absence of complaints.