Skip to main content
All services

Cloud & Infrastructure

Not the room.It is the product.

Cloud architecture, deployment infrastructure, observability, reliability and the operational systems that keep production software available, secure and maintainable.

  • AWS
  • Docker
  • CI/CD
  • Observability
  • CHANGE · PRODUCTION · RECOVERY
  • SIX TIERS
  • THE LOOP CLOSES

Cloud & Infrastructure.

  1. 01ChangeSomeone edits a file
  2. 02BuildIt becomes an artifact
  3. 03DeployResponsibility changes hands
  4. 04RunIt carries real traffic
  5. 05ObserveYou find out what it does
  6. 06RecoverAnd it starts again

A product is not the code in a repository. It is that code running somewhere, reachable over a network, holding data it cannot re-create, and being watched closely enough that someone finds out before your users do. Once you accept that, the infrastructure stops being the room the software sits in and becomes part of the thing you built.

Which means it is engineered, reviewed and owned like the rest of the product rather than assembled by hand and then never touched again. An environment that exists only in one person's console history is not infrastructure; it is a liability with a URL. The version we are interested in is the one written down, rebuildable, and changed the same way any other part of the system is changed.

The work is a closed circuit rather than a checklist. A change is built into an artifact, the artifact is deployed, the deployment runs and carries traffic, the running system emits signals, those signals tell you whether the change was a good idea — and what you learn goes back into the next change. Everything on this page sits somewhere on that loop, and the parts people skip are almost always the second half of it.

Capability overview

What we actually operate.

Engagements are usually a subset of this list, scoped to where the system already is. This is engineering work on your infrastructure — not a migration we have decided you need, and not a platform rebuilt around a tool we happen to like.

06 capabilities · 30 focus areas

01Cloud Architecture
Deciding the shape before anything is provisioned: how many environments there are and how alike they have to be, what compute model the workload actually wants, where the network boundaries sit, where data lives and what that implies, and what the whole arrangement costs to keep running once nobody is paying attention to it.
  • Environment topology
  • Compute model
  • Network boundaries
  • Data placement
  • Cost shape
02Infrastructure as Code
The environment written down, reviewed like any other change and rebuildable from scratch. It is the difference between an outage you recover from and an outage you archaeologically reconstruct — and it is what makes a staging environment worth having, because parity is enforced by the definition rather than by memory.
  • Declarative provisioning
  • Environment parity
  • Change review
  • State management
  • Reproducible rebuilds
03CI/CD & Deployment
A path from commit to production that is boring on purpose. One artifact built once and promoted forward, checks that run before a human is asked to approve anything, a release strategy chosen for the risk of the change, and a rollback that is a normal operation rather than a heroic one.
  • Build pipelines
  • Automated checks
  • Artifact promotion
  • Release strategy
  • Rollback
04Observability
Instrumentation that answers questions rather than filling a screen. Logs shaped for querying, a small set of metrics that genuinely indicate health, traces that follow a request across services, and alerts tuned so that being paged means something — which is mostly the work of deleting the ones that do not.
  • Structured logs
  • Metrics
  • Distributed traces
  • Health checks
  • Alert routing
05Reliability
Designing for the failure you will actually get. Redundancy where a single instance is a single point of failure, restores proven by performing them, degradation that keeps the important paths alive when a dependency does not, headroom left for the day traffic is not what you planned, and drills so the first rehearsal is not the real thing.
  • Redundancy
  • Backup and restore
  • Graceful degradation
  • Capacity headroom
  • Failure drills
06Security & Operations
The running system's standing posture: secrets out of repositories and rotatable, access granted narrowly and taken back when it is no longer needed, patching as a cadence, network surface reduced to what is actually required, and an incident path agreed while everyone is calm.
  • Secrets management
  • Least-privilege access
  • Patching cadence
  • Network hardening
  • Incident response

Where the platform you already pay for would do the job, we will say so. A great deal of infrastructure work is deciding what not to run: every component you operate is one more thing that can wake somebody up, and a smaller system that one person can hold in their head usually beats a sophisticated one that nobody can.

Infrastructure architecture

The loop is the architecture.

Six tiers, one circuit. One of them is where a change can still be reconsidered cheaply; the other five are already carrying traffic. The boundary between those two states is the most consequential line in any system we operate, so the diagram draws it rather than describing it.

01 delivery · 05 production

06 tiers · 30 controls

  1. 01

    Deployment

    How a change becomes an artifact

    Build · DeployInfrastructure04

    The path from a merged commit to something running. A build that produces one artifact rather than a different result on each machine, checks that run before anyone is asked to trust it, promotion through environments that resemble each other, and a release that can be undone — because the ability to go back is worth more than the confidence that you will not need to.

    • Build pipeline
    • Automated checks
    • Artifact registry
    • Environment promotion
    • Rollback
    Responsibility changes here
  2. 02

    Compute

    Where the artifact actually executes

    RunCloud04

    Containers with declared resource limits, a runtime configured from the environment rather than from the image, scaling rules that respond to load instead of to a calendar, and placement that keeps one noisy workload from taking its neighbours with it. The unit here is disposable on purpose: anything that cannot be replaced without ceremony will eventually have to be.

    • Containers
    • Runtime configuration
    • Scaling policy
    • Scheduling and placement
    • Resource isolation
  3. 03

    Network

    How a request reaches it, and what it can reach back

    RunCloud04

    DNS, certificates and termination, routing and health-aware load balancing, an edge that answers what it can without waking the origin, and service boundaries that decide what is allowed to talk to what. This tier is also where most of the blast radius is decided: a system that can reach everything internally fails in a much larger way than one that cannot.

    • DNS
    • TLS termination
    • Routing and load balancing
    • Edge and caching
    • Service boundaries
  4. 04

    Data

    The one tier you cannot re-create from a repository

    RunDatabase04

    Every other tier on this list can be rebuilt from code. This one cannot, which is why it gets the disproportionate share of the attention: migrations that run forward under load, replication that is understood rather than assumed, backups that exist, and — the part almost everyone skips — a restore that has actually been performed rather than a backup job that has merely been green.

    • Primary store
    • Schema migrations
    • Replication
    • Backups
    • Restore drills
  5. 05

    Observability

    How anyone knows what it is doing

    ObserveInfrastructure04

    Structured logs you can query rather than scroll, metrics on the handful of things that actually indicate health, traces that survive a hop between services, health checks the platform is allowed to act on, and alerts routed to a person with the context to do something. An alert nobody can act on is not monitoring; it is noise with a pager attached.

    • Structured logs
    • Metrics
    • Distributed traces
    • Health checks
    • Alert routing
  6. 06

    Operations

    What happens when it goes wrong, decided in advance

    Recover

    Secrets held somewhere other than a repository, access granted narrowly and revocably, a patching cadence that is a routine rather than an emergency, an incident path that says who does what before anyone needs it, and a recovery plan that has been rehearsed. This tier closes the circuit: what it learns is what the next change is for.

    • Secrets management
    • Access control
    • Patching and maintenance
    • Incident response
    • Disaster recovery
Stage 01
Change00:01
Stage 02
Deploy00:03
Stage 03
Recover00:08
Source
1920 × 108030fps · 1.41MB

Still frame

Deployment · Compute · Network · Data · Observability · Operations

Infrastructure lifecycle

How the work is sequenced.

The order is shaped by one rule: nothing is changed before it is understood, and nothing is understood until it is written down. Two of these stages exist purely so the environment stops being knowledge held by whoever set it up.

  1. 01

    Assess

    Find out what is actually running.

    What exists, what it costs, what depends on it, what nobody has touched in a year, and which parts are undocumented because they were done by hand. Also the questions that decide everything after: what has to stay available, what happens if it does not, and how much data you can afford to lose.

  2. 02

    Design

    Decide the topology, before provisioning anything.

    Environments and how alike they have to be, the compute model, the network boundaries, where data sits and how it is protected. Written up while it is still cheap to disagree — a topology argued over in a document is far less expensive than one argued over in a console.

  3. 03

    Codify

    Put the environment in code.

    Provisioning becomes a definition that is reviewed, versioned and re-runnable, so the environment can be rebuilt rather than remembered. This is also where staging stops being an approximation, because both environments now come from the same source.

  4. 04

    Deliver

    Build the path from commit to production.

    Pipelines, checks, one artifact promoted forward, and a rollback exercised before it is needed rather than discovered during an incident. The goal is a deployment that is unremarkable enough to do on a Friday, which is the only honest test of a release path.

  5. 05

    Operate

    Instrument it, then rehearse losing it.

    Logs, metrics, traces and alerts that route to someone who can act, followed by the part that is usually skipped: restoring a backup, failing over deliberately, and walking the incident path while nothing is on fire. What that produces goes back into the next change, which is where the loop closes.

Built to operate

What makes it survivable.

Infrastructure is not judged on the day it is built. These are the properties that decide whether a system is an asset or an ongoing risk, and they are the ones we would ask about if we were taking over somebody else's platform.

01Every environment rebuildable from code
The definition is the source of truth and the running system is a consequence of it. An environment that can only be reproduced by a person who remembers doing it is a single point of failure with a salary.
02A deployment that can be undone
Rollback is a routine operation with a known duration, not an improvisation. The ability to reverse a change quickly is what makes it safe to ship changes often, which is what keeps them small.
03Backups that have actually been restored
A backup job reporting success proves that a file was written. Only a restore proves you can get the data back, and it is the only tier on this system that cannot be reconstructed from a repository if you are wrong.
04Alerts that mean something
Every alert names a condition a person can act on and routes to someone who can act on it. A channel nobody reads is not monitoring, and a team that has learned to ignore its alerts is worse off than one with none.
05Secrets out of the repository, access out of the group chat
Credentials held somewhere they can be rotated and revoked, access granted narrowly and reviewed. The test is simple: someone leaves the project on Friday, and by Monday nothing they held still opens anything.
06A system somebody else can run
Documented, conventional and legible enough that the next engineer can operate it without a briefing. Infrastructure that depends on one person's context has not been finished — it has been deferred onto them.

What we build

Shapes of engagement this work suits.

These are situations rather than case studies — the points at which infrastructure stops being background and becomes the thing blocking everything else. Our published project work lives under Selected Work; nothing below is presented as a delivered engagement.

01A first production environment
Something that works on a laptop and now has to run somewhere real. Environments, a deployment path, data with backups, and enough instrumentation to know it is alive — set up once, properly, rather than three times under pressure.
02A deployment nobody wants to perform
Where releases are manual, rare and frightening, so changes accumulate until each one is large enough to be genuinely dangerous. The work is the path itself: reproducible builds, automated checks, and a rollback that has been tried.
03A system with no visibility
Where the first indication of a problem is a customer message, and diagnosis means reading a server log by hand. Structured logging, the few metrics that matter, health checks and alerting that reaches somebody.
04Infrastructure that exists only in a console
Configured by hand over years, undocumented, and impossible to reproduce. Codifying what is there — usually incrementally, without a big-bang migration — so the environment can be rebuilt rather than excavated.
05A move between platforms
Consolidating providers, leaving a managed host that has been outgrown, or splitting a system that has become one indivisible deployment. Planned around the data tier, because that is the part that cannot simply be recreated.
06A platform only one person understands
Where the infrastructure is fine as long as a particular engineer is available. Documentation, codification and simplification until it is operable by the team rather than by an individual.

Systems layer

What it is built on.

Read from the same engineering stack the rest of the site publishes. It is deliberately short: these are the platforms and tools we are prepared to operate and support in production, not a list of everything we have read about.

01Infrastructure04The delivery path and the telemetry — and the code the environment itself is written in
  • Docker
  • CI/CD
  • Observability
  • Infrastructure as Code
02Cloud04Where it runs, and what sits at the edge in front of it
  • AWS
  • Vercel
  • Cloudflare
  • Object Storage
03Database04The one tier that cannot be rebuilt from a repository
  • PostgreSQL
  • Redis
  • Supabase
  • Vector Databases
04Backend05What is actually being operated — the services traffic arrives at
  • Node.js
  • Python
  • REST APIs
  • GraphQL
  • WebSockets
05Integrations07Everything it depends on, each one a failure mode you do not own
  • Stripe
  • Paystack
  • Flutterwave
  • Third-party APIs
  • Webhooks
  • OAuth
  • Message Queues

Could your environmentbe rebuilt from scratch?

The most useful first conversation is about two things: what happens if the production database is lost, and how long a change currently takes to reach users. The answers tend to describe the whole system.

Start a ProjectAll services