Cloud engineering
Architecture, delivery and operation on AWS, Azure and Google Cloud, inside your own account, as code, with the bill and the patch schedule in writing.
We design and run the cloud your platform lives on, in your own account, as code, with monitoring, patching and a monthly cost review in writing. We do not resell hosting, and everything we build is documented so the next engineer can run it.
Request an infrastructure audit- Infrastructure as code from day one
- CI/CD, monitoring and cost reviews
- No hosting resold — we operate inside your account
What cloud engineering is for
A content platform is only as reliable as the account it runs in. Most outages, surprise bills and failed audits trace to infrastructure that was built by hand, never written down, and sized for a launch that happened years ago. Cloud engineering is the discipline of making that infrastructure explicit: every resource declared in code, every change reviewed and deployed the same way, every server patched on a schedule, and every dollar on the bill attributable to something.
What we do with it
We design and build environments on AWS, Azure and Google Cloud in Terraform, so a whole environment can be rebuilt from the repository. We set up CI/CD so code reaches production through a pipeline that tests it first, with rollbacks that work. We run monitoring and alerting that page a person when it matters and stay quiet when it does not, backups that are restored on a schedule to prove they work, and patching of operating systems, PHP and the platform inside the advisory window. We review the bill monthly and turn off what nobody uses. And we do it inside your account, under your identity and access rules, never in a hosting account of ours.
How we work
Every engagement starts with an infrastructure audit: what exists, what it costs, what is unpatched, what is not in code, and what would happen if a region or a database failed. From that we agree the target architecture and migrate to it in steps, each one reversible. Nothing is changed by hand: a change is a pull request, a review and a pipeline run. Runbooks are written as we go, and the on-call rota is a named engineer, not a ticket queue.
Why now
Drupal 11 requires PHP 8.3 or later and Drupal 10 reaches end of life on December 9, 2026, so most platforms have a hosting change ahead of them in any case. Cloud bills have become a leadership question, and the answer is usually an inventory, not a discount. Terraform 1.16 shipped in September 2026; infrastructure as code is now the default expectation of any auditor, insurer or successor team, and a platform that is not in code is a platform one departure away from being unmaintainable.
The rules we run every account by
3
Clouds we build and operate on
AWS, Azure and Google Cloud, chosen for your procurement, your data rules and your team.
1.16
Terraform, current line
Version 1.16.2 released September 9, 2026. Every environment we build is declared in it.
Terraform releases on GitHub0
Hosting resold
Your account, your data, your identity rules. We hold a role, not the keys.
Monthly
Cost review, in writing
What the bill was, what changed, what we turned off, what we recommend next.
I want to …
know what my platform actually costs
A cloud bill is a list of line items, not an answer. An infrastructure audit turns it into what each system costs to run and what would change it.
- Every resource inventoried and attributed to a system and an owner
- Idle, oversized and duplicated resources named, with the saving
- A written report leadership can read without an engineer
move my platform to the cloud, or between clouds
A migration is a chance to arrive in code. We design the target environment, build it in Terraform, rehearse the move and cut over in a window you choose.
- Target architecture agreed before a resource is created
- The environment built in Terraform and rebuilt from scratch to prove it
- A rehearsed cutover with a rollback that has been tried
get my infrastructure into code
Hand-built infrastructure cannot be reviewed, reproduced or handed over. We import what exists into Terraform and put every future change through a pipeline.
- Existing resources imported into code without downtime
- A pipeline that plans, reviews and applies every change
- Runbooks written as the code is, in the same repository
stop being surprised by outages
Monitoring should page a person for the things that matter and stay quiet otherwise. Backups should be restored on a schedule, not trusted.
- Alerts on what users feel: errors, latency, failed jobs, not CPU graphs
- Backups restored on a schedule, with the restore time recorded
- An on-call rota with a named engineer
keep everything patched without a team
Operating systems, PHP, the database and the platform all have advisory windows. We apply patches inside them, on a schedule you can see.
- Security releases applied inside the advisory window
- PHP and database upgrades planned with the Drupal calendar
- A change log you can hand to an auditor
run AI models inside my own account
Bedrock, Azure OpenAI and Vertex put language models inside your tenancy, under your keys and your procurement rules. We set them up and meter them.
- Provider chosen for your cloud, keys and billing under your account
- Prompts and outputs logged in your account
- Cost metered per feature on your own bill
From audit to an account that runs itself
The same sequence for a new environment and for one we inherit. The automated steps run on every change; the human ones decide.
Nothing is changed by hand. A change is a pull request, a review and a pipeline run, and that is what makes the account something another engineer can run.
What is changing in cloud operations
Checked on September 10, 2026: Terraform releases, the Drupal core schedule and PHP requirements.
Infrastructure as code is the baseline
Terraform 1.16 shipped in September 2026. Auditors, insurers and successor teams now expect to read the environment in a repository, not reverse-engineer it from a console.
The bill is a leadership question
Cloud spend is reviewed the way payroll is. The useful answer is an inventory tying every line item to a system and an owner, refreshed monthly, not a one-time discount.
The Drupal calendar forces a hosting decision
Drupal 11 needs PHP 8.3 or later and Drupal 10 reaches end of life on December 9, 2026. Most platforms will touch their hosting within a year; doing it in code is the same work done once.
Private AI endpoints live in your account
Bedrock, Azure OpenAI and Vertex mean AI features no longer require sending content to a public API. Setting them up is cloud engineering.
Services that pair with this one
A cloud account runs a platform, hosts models and needs people. These are the services most often bought alongside.
-
Drupal development
New builds, major-version upgrades, module and theme work, and migrations from Drupal 7 onward. Every site we build is one we can keep patched, accessible and on a supported version for years, because that is the job after launch.
-
AI engineering
We put language models to work inside Drupal on the jobs they do well: alt text, summaries, tagging, and answers from your own pages with citations. They run in your tenancy, your content trains no one else's model, and nothing publishes without a person saying so.
-
Staff augmentation
One more senior engineer inside your stand-ups, your repository and your ticket queue, not an agency. Ours have run platforms for institutions, start in weeks, and write things down so your team is stronger when they leave.
Tell us where it runs.
Which cloud, roughly what it costs, and what worries you. We come back with what an audit would cover and what it would take.
Request an infrastructure audit