[ 10 — DEVOPS & SECURITY ]
Pipelines, monitoring and hardening so releases are boring and outages are rare.
[ 01 — THE PROBLEM ]
What this usually looks like
Before
- Releases happen on Friday evenings because they are frightening and nobody wants an audience.
- It works on one machine and not on another, and the difference is undocumented.
- There is no way to tell whether the last deploy made things worse.
- Secrets are in the repository, and have been for years.
After
- One pipeline: tests, build, deploy. Releases become dull enough to do on a Tuesday morning.
- The application and its dependencies in a container, so every environment is the same one.
- Error rates and response times visible per release, so a bad deploy is obvious in minutes.
- Secrets out of the repository, rotated, and injected at runtime from somewhere accountable.
[ 02 — WHAT YOU GET ]
Deliverables, not deliverable-sounding words
A build and deploy pipeline
Tests, linting, image build, deploy and rollback, triggered by a push and visible to everyone.
Containerised application
Reproducible builds, a non-root runtime user and a slim image that is quick to pull.
Environments
Staging that genuinely resembles production, so a test there means something.
Monitoring and alerting
Uptime, errors, latency, resource usage and certificate expiry, with alerts routed to a person.
A security pass
Exposed services, access control, dependency vulnerabilities, secret handling and backups — with a written report and the fixes applied.
[ 03 — HOW IT WORKS ]
The steps, and how long each one takes
- 01
Review
2–4 daysHow you build, deploy and run today, and where it hurts most.
- 02
Containerise
3–5 daysThe application and its dependencies, with a reproducible build.
- 03
Build the pipeline
1 weekTests, build, deploy, rollback. Staging first, then production behind an approval.
- 04
Instrument
3–5 daysMetrics, logs and alerts, with dashboards that answer the questions you actually ask during an incident.
- 05
Harden
1 weekFirewall, access control, dependency updates, secret rotation, and a tested restore.
[ 04 — EXAMPLES ]
What people use this for
From manual deploys to a pipeline
Replacing SSH-and-hope with a push-button release and a one-minute rollback.
Pre-launch hardening
A security and reliability pass before a system goes public, with a written report you can show a client.
Incident readiness
Monitoring, runbooks and an on-call rotation, so the first outage is not also the first time anyone has thought about it.
Releases should be dull.
One pipeline
Tests, build, deploy, rollback — triggered by a push, visible to everyone, and the same every time. When a release takes four minutes and can be undone in one, teams ship small changes often, and small changes are the ones that are easy to debug.
Hardening the parts that matter
We look at what attackers actually use: services exposed that should not be, weak or shared access, unpatched dependencies, secrets sitting in repositories, and backups nobody has restored. You get a written report and the fixes, not a PDF of generic advice.
[ 05 — STACK ]
What we build it with
Chosen because they are boring, well supported and easy to hire for. Nothing here will be abandoned next year.
- Docker
- GitHub Actions
- Kubernetes
- Terraform
- nginx
- Grafana
- Cloudflare
[ 08 — FAQ ]
DevOps & Security: questions people ask
[ 09 — ALSO IN THIS PILLAR ]
Related services
Let's talk about devops & security.
Tell us the problem. We will tell you what we would build, what it costs and how long it takes — before you commit to anything.