Services · Cloud engineering

Infrastructure, and the run-book that comes after it

Getting a service onto AWS is a day's work. Making it something a small team can operate at 2am — deploy, roll back, find the failing job, restore the database — is the part that decides whether the platform is an asset or a liability.

What we build

Concrete deliverables, not adjectives

Containerised deployment
Services packaged as images and run on managed compute, so the artefact that passed CI is the artefact in production, and scaling is a number rather than a migration.
Delivery pipelines
Build, test, migrate, deploy, and a rollback that is one action. If shipping requires a person to remember a sequence, the sequence is the bug.
Environment separation
Development, staging and production with separate data, separate credentials and separate blast radius — including for the third-party services that charge real money when a test loop misfires.
Backup and restore
Automated backups, and — the part usually skipped — a restore that has actually been performed. A backup nobody has restored is a hypothesis.
What's included

The parts a demo doesn't show

Four stacked capability cards — secrets kept out of the repository, monitoring aimed at questions, cost visibility, documented operations — beside a cloud tile and an infrastructure diagram
Secrets that are not in the repository
Configuration through the platform's secret store, injected at runtime, rotated without a redeploy. No credential ever lands in version control.
Monitoring aimed at questions
Dashboards built around the questions you will actually ask — is the queue draining, are deliveries failing, which tenant is affected — rather than a wall of default metrics.
Cost visibility
Tagged resources and a clear picture of what each part of the platform costs, so architectural decisions can be made with the bill in view.
Documented operations
A written run-book: how to deploy, how to roll back, how to rotate a key, who to call at the provider. Handed over, not held.
How we work

The order things actually happen in

  1. Audit what exists

    Inventory of services, data stores, credentials, scheduled work and third-party dependencies. Undocumented infrastructure is the norm, not the exception.

  2. Containerise and reproduce

    Get the application running identically on a laptop and in a pipeline. Everything after this is much cheaper once it is true.

  3. Automate the path to production

    Pipeline, migrations, health checks, rollback. Then deploy through it repeatedly until it is boring.

  4. Hand over the keys

    Run-book, dashboards, alerts and a walkthrough with the people who will be on call. An engagement that ends without this has not ended.

Technology

The stack, and why each piece is in it

Compute
AWS ECS · Fargate · LambdaLong-running services on ECS with Fargate so there is no fleet to patch; Lambda for event-driven work that is idle most of the day.
Data and storage
Amazon RDS · DynamoDB · S3 · RedisManaged Postgres or MySQL for relational data with backups handled by the platform; S3 for media and exports; Redis for queues and short-lived state.
Messaging and mail
Amazon SNS · SES · queue workersFan-out and transactional mail through managed services rather than a server nobody wants to own, with the sending reputation treated as production infrastructure.
Pipeline and packaging
Docker · CI/CD · infrastructure as codeEnvironments defined in files under review, so rebuilding one is a run rather than an archaeology project.

Tell us what you want built

A short brief is enough to start — what you're trying to do, and roughly for whom. We'll tell you honestly whether it's a fit.