Cloud infrastructure and DevOps
A deploy should be the least interesting thing that happens all week. If releasing makes people nervous, the problem is not the release process — it is that nobody trusts the environment they are releasing into.
What good infrastructure looks like
It is describable. Every piece of it exists in a repository as code, which means staging can be rebuilt from scratch and is genuinely identical to production. Configuration drift — where someone connected to a server eighteen months ago and changed something — is the root cause of a remarkable share of production incidents, and infrastructure as code is the only reliable cure.
It is also boring. Managed database, managed queue, managed object storage, containers on a service that handles orchestration for you. We reach for Kubernetes when there is a specific reason, not as a default, because an eight-person company running its own cluster has quietly bought itself a second full-time job.
And it is legible on the invoice. Cloud bills grow quietly. We tag resources by environment and service from day one, so when the bill jumps you can see which thing did it rather than guessing.
Pipelines and environments
Every merge to the main branch runs the test suite, builds an image and deploys to staging automatically. Production is one approval away, not one heroic evening away. Rollback is a button, and it has been tested — because a rollback path that has never been exercised is a hypothesis, not a safety net.
Secrets live in a secret manager, not in environment files passed around on chat. Database migrations run as part of the deploy with a strategy that tolerates the brief window where old and new code are both live. That last detail is what most often turns an ordinary deploy into an outage.
Knowing when something is wrong
Monitoring that pages someone at 3am for a CPU spike that resolves itself trains people to ignore alerts, which means the real one gets ignored too. We alert on symptoms a user would actually notice — error rate, latency at the ninety-fifth percentile, queue depth, failed jobs — and we write the runbook entry at the same time as the alert, so whoever is woken knows what to do about it.
Backups are tested by restoring them. An untested backup is a belief rather than a backup, and the first restore should not be happening during an incident.
What this actually covers
Cloud architecture
AWS-first design sized to your actual load, with a written rationale for each managed service chosen over a self-run one.
Infrastructure as code
Terraform for everything, so environments are reproducible and drift is visible in a diff rather than discovered in an incident.
CI/CD pipelines
Test, build and deploy to staging on merge; production one approval away. Rollback tested rather than assumed.
Observability
Metrics, logs and traces wired to alerts on symptoms users notice — with the runbook written at the same time as the alert.
Security hardening
Least-privilege IAM, secrets in a manager, network segmentation, and dependency scanning that blocks a release.
Cost optimisation
Resources tagged by service and environment, right-sizing, and a bill you can read line by line and attribute.
The sequence
Same shape on every engagement, so you always know what week you are in and what happens next.
Assess what exists
A written review of the current setup: what is running, what it costs, what would happen if the primary database were lost, and who can deploy. The gaps usually rank themselves.
Codify before changing
We bring the existing infrastructure under Terraform before improving it. Changing an environment nobody can reproduce is how a maintenance window becomes an outage.
Pipeline and environments
Staging that genuinely matches production, automated deploys to it on merge, and a production path with an approval gate and a tested rollback.
Observe, harden, hand over
Alerts on real symptoms, runbooks written, a restore rehearsed, and your team walked through operating all of it without us.
Handed over, in your accounts
Not a demo and a login. These are the artefacts you keep, and they are what makes leaving us possible.
- Terraform describing every environment, in your repository
- A CI/CD pipeline with a tested rollback path
- Secrets managed properly, with no credentials in the repository or in chat
- Dashboards and alerts tied to user-visible symptoms, each with a runbook entry
- A tested restore — we restore a backup in front of you rather than promising one exists
- A cost breakdown by service and environment, with the three largest line items explained
Typically built with
- AWS
- Terraform
- Docker
- GitHub Actions
- PostgreSQL
- Redis
- CloudWatch
- Grafana
- Cloudflare
The selection principle is deliberately dull: largest hiring pool, longest support window. See why we choose these.
Cloud & DevOps, answered
The things people ask on the first call, written down so you do not have to.
Do we need Kubernetes?
Probably not. Kubernetes solves real problems at real scale, and below that scale it mostly adds a platform that needs its own maintenance, its own expertise and its own on-call rotation. For most companies we build on managed container services, a managed database and a managed queue, which covers the requirement with a fraction of the operational surface. If you genuinely need Kubernetes we will build it properly — but we will ask you to say out loud what problem it is solving first.
Can you reduce our cloud bill?
Usually, and the first move is visibility rather than cuts. Untagged resources make it impossible to attribute cost, so we tag by service and environment first and then look at what the data says. The common wins are unglamorous: over-provisioned instances, storage nobody deleted, non-production environments running twenty-four hours a day, and cross-zone data transfer nobody realised was chargeable. You get a written list ranked by saving against risk.
How do you handle security?
Least-privilege IAM roles rather than shared credentials, secrets in a secret manager with rotation, network segmentation so the database is not reachable from the internet, and dependency scanning that fails a build on a known critical vulnerability. We also test the restore path, because a ransomware event and a hardware failure have the same recovery requirement — and an untested backup is a belief rather than a backup.
What if our team has to run this after you leave?
That is the intended outcome, and it shapes the choices. Everything is Terraform in your repository, everything managed rather than bespoke, and the runbooks are written for someone who was not present when it was built. Handover is a working session in which your team performs a deploy, a rollback and a restore themselves while we watch. If they can do all three unaided, the handover is complete.
What usually comes with this
- BuildCustom Software DevelopmentCustom platforms, marketplaces and SaaS. We write the parts that are specific to your business and buy the parts that aren’t.Read more
- RunMaintenance & SupportTaking over a system someone else wrote — including the archaeology needed before anyone can safely change it.Read more
- RunQA & Software TestingAutomated regression suites where they pay for themselves, and exploratory testing where they don’t. We tell you which is which.Read more
- BuildWeb Application DevelopmentDashboards, portals and internal tools that hold up under real data volumes — not a prototype that falls over at ten thousand rows.Read more
Thinking about cloud & devops?
Start with a call rather than a brief. Thirty minutes, no deck, and an honest answer about whether we are the right people for it.