Drupal hosting problems are rarely about capacity. They come from process: no environment anyone can rebuild, no rollback that has been tried, a backup nobody has restored, and an alert that lands in an inbox. We run Drupal for you on standard containers and open-source infrastructure, in your cloud account or in ours, and we operate it month by month: deployments, backups with a tested restore, monitoring, and the caching, cron and queue setup that Drupal needs.
- Who this is for
- An organisation deploying Drupal by hand to a single server. A team that is not sure its backups would restore. A site paying platform rates for more than it uses. A public body whose procurement rules require the servers to sit in its own cloud account.
What managed hosting includes
- Environments that match. Local, staging and production built from the same container definition, so a release tested on staging behaves the same on production.
- A deployment path with a tested rollback. Releases go out the same way every time, and going back to the previous release has been tried before anyone needs it.
- Backups with a restore that has been run. The restore is tested rather than assumed, and each test is recorded.
- Monitoring that reaches a person. Uptime, error rates and the things that fail quietly: a queue backing up, cron that stopped, a certificate about to expire.
- Drupal-aware configuration. Page and dynamic page cache, Redis or Memcache where it earns its place, CSS and JS aggregation, image derivatives, cron and queue workers, and a CDN that honours Drupal's cache tags.
- TLS, security headers and hardening. Administrative and update paths are kept off the public internet.
- A runbook. Written for somebody who was not there when the environment was built.
Sample Restore test record example.org · signed off each quarter
Backups
- Database dump taken nightly Kept off the production server
- Files directory synced
- Retention period checked against the agreement
Restore
- Latest backup restored to a clean environment
- Home page and a search result load
- Editor can log in and save a draft
Record
- Time the restore took Compared with the last test
- Who performed it
- Anything that failed, and the fix
How the work runs
Moving an existing site is staged so that the current site stays live until the new environment has proved itself.
How a Drupal site moves onto managed hosting
- Audit How the site is deployed today, the real backup position, the versions it needs, and what runs on the server undocumented. You keep the environment audit
- Build Staging and production built from one container definition, in your account or ours. You keep the configuration
- Rehearse The move is run on staging until it goes through cleanly, with the old site still live. You keep the move plan
- Cut over DNS switched last, with a rollback that has been rehearsed. You keep the rollback steps
- Run Deployments, backups, restore tests and monitoring, reported every month. You keep the runbook
Where the audit finds something hosting cannot fix, such as an unsupported Drupal version or a module with an open security advisory, we say so and price it as the separate piece of work it is.
Your cloud account, ours, or a platform
Where the site runs is a commercial choice, and it can be reversed, because the configuration lives in a repository you own in every case.
| Question | Your account | Our account | A platform |
|---|---|---|---|
| Who holds the cloud bill | You, directly with the provider | We do, passed through at cost | You, on the platform's plan |
| Who holds root access | You, with accounts issued to us | We do | The platform |
| The stack | Standard containers and open-source components | Standard containers and open-source components | The platform's own stack and rules |
| Leaving | Nothing moves; you keep a running system | A redeployment from your repository | A move onto another stack |
| Suits | Data residency and procurement rules | One supplier and one invoice | Teams that want the platform's tooling |
For some teams a platform service is the better answer, and we will say so. If what you need is the pipeline and the environments built for your own team to run, that is Drupal DevOps and CI/CD rather than hosting.
Hosting, maintenance and upgrades are different things
A site can be perfectly hosted and still be running a module with a published security advisory against it. Hosting keeps the environment healthy; it does not change the code.
Managed Drupal hosting stack What we run and watch, from the edge to the database
CDN Static files and cached pages at the edge
Cache miss
Web server and PHP The same container image on staging and production
Queries and cache
Database Backed up, with a tested restore
Redis or Memcache Object and page cache
Monitoring Alerts that reach a person
- Hosting: This page. The environment, the deployment path, the backups and the monitoring.
- Maintenance and support: Security releases of core and contributed modules applied and tested, bugs fixed, small changes made. It applies whatever server the site runs on, and to every contributed module, including the modules we publish on Drupal.org. It is how we look after the systems we built, such as CreAct.
- Version upgrades: Moving between major Drupal versions. Neither hosting nor maintenance replaces it, and Drupal 10 security support ends on 9 December 2026.
- Performance work: The hosting layer gets caching and a CDN right; tuning the pages themselves is separate work, covered in Drupal performance optimisation.
Hosting and maintenance can be bought together, and then one team is called when something breaks. They are still scoped and priced separately, so you can see what each one covers.
What it costs
Managed hosting sits in the Maintenance and support band on our pricing page, billed per month and sized to the system, with no lock-in period. What moves it within the band: traffic and uptime expectations, the number of environments, how much of the stack we operate, and whether cover outside business hours is needed.
Cloud costs are separate from our fee. In your own account you pay the provider directly; in ours the infrastructure is passed through at cost and shown on its own line.
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
What uptime do you commit to?
Uptime targets are set in the agreement against the architecture you buy: a single server and a setup with failover cannot carry the same number. We agree a figure we can meet rather than publish one we cannot.
Do we need a CDN?
Not always. A CDN earns its place when visitors are spread across regions or traffic arrives in spikes; for a regional site with steady traffic, Drupal's own page caches may be enough. We set one up where it pays, and configure it to respect Drupal's cache tags so editors see their changes go live.
Can our own developers still deploy?
Yes. Deployments go through the same pipeline whoever starts them: your developers merge, the pipeline deploys, and the same rollback applies. What changes is that nobody edits files on the production server by hand.
How often are backups taken, and how often is a restore tested?
Backup frequency and retention are set per site in the agreement, according to how much content changes and how much of it you can afford to lose. The restore test runs on the schedule agreed with you, and each one is recorded: when it ran, how long it took and what, if anything, failed.
Can you take over hosting for a site you did not build?
Yes. The environment audit covers the server side. If the application also needs looking after, the takeover audit for maintenance and support covers the code, and the two run together.
Not covered here? Ask us directly.
Discuss hostingAn engineer reads it and replies within one business day.
Run
Related services
Tell us where the site runs today
The environment audit tells both of us what the move involves before anybody quotes a monthly figure.
An engineer reads it and replies within one business day.