Cloud

Hosting & Managed Infrastructure

Somebody responsible for the platform on a Sunday

How this is usually engaged

A rolling monthly agreement with a notice period and no lock-in beyond it. The support boundary, cover hours, response commitments and escalation contacts are agreed per engagement and set out in the agreement itself. Everything runs in accounts you own, so ending the arrangement is a handover of access rather than a migration.

Practice
Cloud & Infrastructure
Sectors
4 served
Process
5 stages
Standard
Built and tested to WCAG 2.2 AA

Summary

Managed hosting for applications we build and applications we inherit, covering patching, backups with tested restores, scaling and a defined route to a human when something breaks.

01What this solves

The problem this addresses

Hosting is usually fine until it is not, and the gap becomes visible at the worst possible moment. Certificates expire on a bank holiday, the operating system has not been patched since it was provisioned, the backup job has been failing silently for five weeks, and when the site goes down at the weekend the only escalation path is an email address that is read on Monday. None of this is exotic; it is the ordinary consequence of nobody being clearly accountable for the platform.

02Capabilities

What is included

01

Patching and maintenance windows

Operating system, runtime and dependency updates applied on an agreed schedule, tested in staging first, with an expedited path for serious vulnerabilities and a record of what was applied when.

02

Backups and tested restores

Automated backups with agreed retention, encrypted and stored separately from the production account, and restored on a regular cadence into a scratch environment. You receive the results, including the time the restore actually took.

03

Certificate, domain and DNS management

Automated certificate renewal with expiry monitoring as a backstop, DNS held under change control, and domain renewal dates tracked. Most of the outages in this category are calendar failures rather than technical ones.

04

Capacity and scaling

Autoscaling where the workload suits it, scheduled capacity where traffic is predictable, and periodic right-sizing against measured usage rather than the size someone guessed at provisioning.

05

Incident response and escalation

Defined severity levels, a documented escalation path and an agreed route that reaches a person rather than a queue. Cover hours and response times are set in your agreement, and we do not publish a figure we have not agreed with you.

06

Cost review

A periodic look at what you are spending and on what, including reserved capacity where your usage is stable and honest advice about resources that are running because nobody switched them off.

03Use cases

Where this work usually starts

01

No internal operations capability

A team of developers with no one whose job is the platform. Patching and backups compete with feature work and lose, quietly, until an incident makes the trade-off visible.

Professional Services

02

Inheriting a system whose builder has gone

An application still doing useful work with no one left who knows how it is deployed. We document it, bring it under monitoring and backup, and stabilise it before deciding whether it should be rebuilt.

Property & Real Estate

03

Seasonal or timetable-driven load

Enrolment weeks, sale periods or reporting deadlines where traffic multiplies for a few days. Capacity planned and rehearsed ahead of the date rather than adjusted during it.

Education

04Approach

How we approach it

We take defined responsibility for the running platform and write down exactly where that responsibility ends, because ambiguity in a support boundary is what leaves an incident unowned. Patching, certificate renewal and dependency updates run on a schedule with the results visible to you. Backups run automatically and are restored on a regular cadence into a scratch environment, so the restore is evidence rather than an assumption. Capacity is reviewed against real traffic, and we tell you when your workload would be cheaper and better served on a managed platform than on anything we would run for you.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

  1. 01

    Platform assessment

    What is running, how it was built, what is out of date and what would happen today if it stopped. We produce findings before quoting an arrangement.

  2. 02

    Stabilisation

    The urgent gaps first — missing backups, unpatched systems, expiring certificates, credentials in the wrong place — before any ongoing cover begins.

  3. 03

    Onboarding to managed cover

    Monitoring, alert routing, access control and documentation brought to the standard the agreement assumes, in accounts you own.

  4. 04

    Operate and review

    Scheduled maintenance, restore tests and incident handling, with a regular review covering what happened, what it cost and what should change.

  5. 05

    Exit readiness

    Documentation kept current enough that another supplier or your own team could take over. We would rather earn renewal than rely on the difficulty of leaving.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

  • Support agreement with a written responsibility boundaryWhat we cover, what remains yours, and how each is escalated.
  • Environment documentation and runbook
  • Backup schedule and restore test records
  • Patch and maintenance log
  • Periodic service and cost review
07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Data & Storage

  • PostgreSQL
  • Redis

Cloud Platforms

  • Amazon Web Services
  • Cloudflare
  • Vercel

DevOps & Operations

  • Docker
  • Terraform
The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Systems are patched on an agreed schedule with an out-of-band path for serious vulnerabilities. Administrative access is individually attributed with multi-factor authentication and no shared accounts, and production access is logged. Backups are encrypted and held in a separate account or project from the systems they protect, so a compromise of the environment does not take the recovery path with it. Certificates and domains are monitored for expiry rather than remembered.

09Questions

Asked before we start

Would we be better off on a managed platform instead?

For a good number of workloads, yes, and we will say so. A standard application on a managed application platform or a managed database usually costs less in total than the same thing assembled from components and looked after by us, because you are paying a platform for work we would otherwise do by hand. We recommend managed hosting from us when the workload has requirements those platforms do not meet, or when there are enough moving parts that someone needs to hold the whole picture.

What uptime do you commit to?

Whatever we have agreed with you in writing for the architecture you have funded, which is why we do not publish a number here. A figure quoted on a website before anyone has looked at your dependencies, your database topology or your cover hours is decoration. During onboarding we agree availability targets, recovery objectives and response commitments, and they go into the support agreement.

Will you host systems you did not build?

Often, after an assessment. Some inherited systems are ordinary applications that simply lack an owner, and those are straightforward to take on. Others depend on unsupported runtimes or undocumented manual steps, and taking responsibility for them without changes would be dishonest — in that case we quote the remediation separately and let you decide whether it is worth it against a rebuild.

Do you provide overnight cover?

Cover hours are agreed per engagement and written into the agreement, and out-of-hours cover costs meaningfully more because it requires people on a rota. It is worth being honest about whether you need it: for a good number of internal systems, a documented failure mode and a response the next working morning is the proportionate answer, and we would rather you spend the difference on making failures less likely.

START HERE

Talk to us about Hosting & Managed Infrastructure

The project brief takes about five minutes and gives us enough to have a useful first conversation about Hosting & Managed Infrastructure rather than a generic one. If you would rather just ask a question, the short form is there for that.

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.