Most Drupal hosting problems are not capacity problems. They are process problems wearing a capacity costume: no reproducible environment, no tested rollback, a backup nobody has ever restored, and an alert that goes to an inbox instead of a person. We run Drupal on standard containers and open-source infrastructure so that the setup is portable and you are not locked to one provider, including us. If you would rather keep your own cloud account, that is the normal arrangement rather than the exception.
- Who this is for
- Organisations deploying Drupal by hand, running a single environment, unsure whether their backups would restore, or paying platform-as-a-service rates for a site that does not need them.
What managed hosting includes
- Containerised environments that match. Local, staging and production built from the same definition, so "it works on staging" stops being an argument.
- A deployment pipeline with a tested rollback. Releases become routine rather than events, which is the only durable way to make them frequent.
- Backups with a restore that has actually been run. A backup nobody has restored is a hope, not a plan, so the restore is part of the deliverable rather than a line in a contract.
- Monitoring that reaches a person. Uptime, error rates and the things that fail quietly: queue backlogs, cron that stopped, a certificate about to expire.
- Drupal-aware tuning. Page and dynamic page cache, internal page cache, Redis or Memcache where it earns its place, CSS and JS aggregation, image derivatives, cron and queue workers, and a CDN in front with cache tags honoured.
- TLS, security headers and hardening, with administrative and update paths not reachable from the public internet.
- Runbook documentation written for somebody who was not there when it was built.
Your infrastructure or ours
This is a commercial choice, not a technical constraint, and we are content either way.
Your cloud account. We build and operate the environment inside your own AWS, Google Cloud or other provider account. You hold the billing relationship and the ultimate access, and if the arrangement ends you keep a running system rather than a migration project. Public-sector and enterprise clients usually need this for data residency or procurement reasons anyway.
Our infrastructure. One supplier, one invoice, and nothing for your team to hold. Because it is standard containers and open-source components, leaving is a redeployment rather than a rescue. We do not build in a reason for you to stay.
Either way the configuration lives in version control in a repository you own, which is what makes the choice reversible.
Hosting, maintenance and upgrades are different things
Buying the wrong one of these is common and expensive.
- Hosting: this page. The environment, the pipeline, the backups, the monitoring.
- Maintenance and support: security advisories applied, bugs fixed, small changes made. A site can be perfectly hosted and still be running a module with a published advisory against it.
- Version upgrades: moving between major Drupal versions. Neither hosting nor maintenance can substitute for it, and Drupal 10 reaches end of life on 9 December 2026.
- DevOps engineering: the wider work of making environments reproducible and deployment boring, including for systems that are not Drupal.
Most clients take hosting and maintenance together, because the two overlap in who gets woken up. They are still priced and scoped separately so you can see what you are buying.
Moving an existing site
Migration onto managed hosting starts with a short audit of the current environment: how it is deployed today, what the backup position really is, which versions it needs, and what is running on the server that nobody has documented.
The move itself is staged with the existing site kept available until the new one is proven, DNS cut over last, and a rollback that has been rehearsed rather than described. Where the audit finds something that hosting cannot fix (an unsupported Drupal version, a module with an open advisory), we say so and price it as the separate piece of work it is.
Pricing sits in the maintenance and support band, $100 to $5K and above per month depending on the system, published at pricing. There is no lock-in period.
Questions we get asked
Do we have to host with you?
No. We build and operate inside your own cloud account just as readily, and public-sector and enterprise clients often require it. The configuration is in a repository you own either way, which is what makes the decision reversible.
How is this different from a Drupal platform-as-a-service?
A platform product gives you a managed environment on its own terms and its own stack. We build on standard containers and open-source components, so the environment is portable and the exit is a redeployment rather than a rebuild. For some teams the platform product is the better answer, and we will say so.
What does it cost?
It sits in our published maintenance and support band, $100 to $5K and above per month, sized to the system. Traffic, environment count, uptime expectations and how much of the stack we operate are what move it within that band.
Do you handle security updates too?
That is maintenance rather than hosting, and most clients buy both. We keep them separate in the quote so you can see what each one costs and what each one covers.
Can you take over hosting for a site you did not build?
Yes. It starts with an audit of the current environment and deployment path, because inheriting a server nobody has documented is how a migration window gets doubled.
What uptime do you commit to?
Uptime targets are set in the agreement against the architecture you actually buy, since a single-server setup and a multi-environment one with failover cannot honestly carry the same number. We would rather agree a figure we can meet than publish one we cannot.
Tell us what you are running
The environment audit tells both of us what the move actually involves before anybody quotes a monthly figure.