Developer Buying Guide
Drupal hosting plans — If you cannot run Composer, you cannot run Drupal
Drupal is operated from a shell. A plan without one does not make maintenance awkward, it removes it.
The short answer
Buy the toolchain first and the specification second. Business-tier hosting with the complete toolchain suits most Drupal sites, and a VPS handles the heavyweight builds — Composer-native on either route, because on Drupal the command line is not a convenience, it is how the site is maintained at all.
What follows: how this usually goes wrong, the instrumentation that catches it, the platform requirements those findings imply, and the plan we would build on with a way to verify it.
By the HostingFast team · Reviewed 24 August 2026
NVMe
Storage on every plan
Free
Domain, first year
99.9%
Uptime target, monitored
Flat
Renewal pricing
Most writing on this subject is a league table bankrolled by referral fees. This one starts from the failure mode, because on Drupal the expensive mistakes are structural rather than incremental.
The two primary interfaces for operating a current Drupal site are Composer and Drush, not optional conveniences layered on top. A plan with no terminal access does not merely make maintenance awkward; it removes the mechanism by which maintenance happens.
How this goes wrong, concretely
A site is installed by uploading a tarball. Six months later a security release lands, there is no Composer to apply it, and the choice is a manual file diff or staying vulnerable. Neither is a plan.
Or cron never fires. Drupal collects search indexing, queue processing and cleanup behind one cron endpoint, and when that stops running the symptoms are diffuse: search results go stale, queued mail never sends, the cache tables grow without bound. Nothing errors. It just quietly stops working.
Or PHP memory is set to a WordPress-shaped default. Bulk admin operations, a views preview with several relationships, or a configuration import then die halfway through with a white screen and no log entry that names the cause.
Each of those is a hosting decision made months earlier, arriving late.
Instrument it before you commit
Run drush status and drush cron on the plan you are evaluating, over SSH, before any money moves. If either command cannot run, the evaluation is finished and you have saved yourself a year.
Then read two numbers. Drupal's own performance page and the database log will tell you when cron last completed; anything older than a few hours on a content site means the schedule is not real. And check the PHP memory limit against what a configuration import actually needs, not against the default.
Finally, look at page cache behaviour for anonymous visitors. Drupal's cache tags are precise and effective, and a correctly configured site serves anonymous traffic without touching most of the render pipeline. If it is not doing that, no plan upgrade will disguise it.
The requirements those findings imply
SSH with Composer and Drush available, because that is how a modern Drupal site is actually run.
Generous PHP memory and execution limits, since the framework spends both without hesitation during administrative work.
A database that copes with the query volume entities and views produce, on storage where latency is measured in microseconds rather than milliseconds.
System cron firing on a schedule you control. Visitor-triggered cron is not a substitute; it makes your slowest request slower and still misses quiet periods entirely.
Our pick, and the receipts
Overdrive is where this lands: SSH from signup, Composer and Git on the path, PostgreSQL and MySQL both available, 3.5 cores and 2.5 GB of RAM, staging copies included and 100 addon domains if the build is a multisite.
Verify it with the same three commands you used to disqualify the alternatives — drush status, a real cron run, and the memory limit — then time an anonymous page load cold and warm.
Put us through the identical checks: message support before paying and see who actually replies, compare the renewal rate with the order rate, read the refund terms in full, and look the company up — ours is Vitalcare at Home Ltd, registered in England and Wales, on the public record.
Our interest here, declared up front
Most 'best hosting' content is ranking-for-hire. We sell what this page recommends and say so early, which is what lets the rest of it be about commands and limits rather than a leaderboard.
NVMe storage and LiteSpeed caching sit under every tier from the entry plan upward, so the fast components are the baseline rather than an upsell.
- Commands you can run before you pay
- Renewal price stated on the page
- No charge to bring a site across
- Exit terms stated in full
Why HostingFast
Standard on every plan
Composer and Drush on the path
The two interfaces a current Drupal site is actually operated through, present from the first login rather than on request.
Memory sized for admin work
Configuration imports and views previews spend PHP memory freely, and the Business tier's allocations were chosen with that in mind.
Real system cron
A scheduled run rather than a visitor-triggered one, so indexing and queues keep working through quiet hours.
What Overdrive actually is
500 GB of disk, 3.5 cores, 2.5 GB of RAM and 100 addon domains at a single published monthly rate.
Staging copies included
Clone the site, run the update, exercise it, then promote — which turns a security release into a routine rather than an evening.
The legal entity, named
Vitalcare at Home Ltd, registered in England and Wales, with the paperwork public before you commit.
Prices Side by Side
Our numbers next to the big names
Typical intro and renewal pricing across the market, lined up against ours — including the renewal figure most comparison charts skip.
| Feature | HostingFastMost popular | Typical household-name host | Typical bargain host | Typical loss-leader deal |
|---|---|---|---|---|
| Starting price / mo* | $2.42/mo | $4–$6 | $2–$4 | $1–$3 |
| Renewal price / mo | $2.42/mo | $10–$15 | $8–$12 | $4–$6 |
| Cheapest plan renews at its sign-up price | ||||
| SSL as standard | ||||
| Migration done for you | ||||
| NVMe drives on the cheapest tier | ||||
| Daily backups from the first tier | ||||
| Real humans on support, 24/7 |
*Our number is the lowest-priced plan we sell on an annual term, pulled live from the same catalogue that powers our pricing page — it physically cannot fall out of date. The other three columns show the ranges shared hosts in each bracket typically advertise: introductory offers that mostly demand a one-to-four-year commitment, then jump once it expires. We no longer name rivals or print their prices, because a figure we cannot verify on the day you read it has no business on this page. Line us up against whichever host you are really weighing — and give the renewal row the hardest look.
Quick Start
From order to online
- 1
Try to run drush before you buy
drush status over SSH on the plan you are considering. If it will not run, the rest of the comparison is academic.
- 2
Check when cron last completed
Anything older than a few hours on a content site means the schedule is theoretical. Diffuse symptoms all trace back to this one value.
- 3
Total it over the full term
Renewal rate times the term, plus every extra you would genuinely enable. The lowest headline figure rarely survives it.
- 4
Time an anonymous load, cold and warm
The gap between the two is your cache tags doing their work. If there is no gap, fix that before you buy anything larger.
Built In
Loaded onto every plan
- SSH from signup, with Composer and Drush usable immediately
- PHP memory and execution limits sized for configuration imports
- System cron on a schedule rather than triggered by visitors
- PostgreSQL and MySQL both available on the Business tier
- NVMe SSD under the database, not spinning disk
- Staging copies for testing a security release before it ships
- Per-site PHP version switching from the control panel
- DDoS filtering absorbed out at the network edge
- Renewal charged at the rate you ordered at
- Zero setup charges — there is no joining fee, ever
Frequently Asked
What people ask us most often
What actually happens if Drupal cron stops running?
Nothing visible, for a while. Then search results go stale, queued mail stops sending, cached entries are never invalidated and the cache tables grow. There is no error page and no alert, which is why the last-run timestamp is worth putting on a monitor rather than checking when somebody complains.
How much PHP memory does a Drupal site actually want?
More than a typical WordPress default, and the reason is administrative rather than public. A page view is cheap; a configuration import, a views preview with several relationships, or a bulk operation across thousands of nodes is not. Size the limit for the heaviest admin operation you perform, because that is the one that fails silently.
Are cache tags enough, or do I still need a page cache in front?
Drupal's internal caching is unusually precise — it can invalidate exactly the pages an edit affected. A server-level cache in front adds the ability to answer an anonymous request without waking PHP at all. Use both: the internal layer for correctness, the outer layer for the requests that never need to reach the application.
Can a Composer-managed site be migrated without breaking the lock file?
Yes, and it should be. We move files, database and configuration free of charge, vendor directory included, so the lock file and the installed tree stay in agreement. Rebuilding dependencies during a migration is how a routine move turns into a debugging session, and there is no reason to do it.
Keep reading
Let's Encrypt vs Paid SSL
What a paid certificate buys that a free one does not, decided on the actual differences.
Ecommerce Hosting for First Stores
A first storefront costed properly, including what the checkout path needs.
Uptime (Glossary)
What uptime figures mean in practice, and what they quietly exclude.
Drupal Hosting
Drupal with Composer, Drush and per-site PHP control on tap.
AI Website Builder
Describe the site you need and the AI drafts it on real hosting.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Run it the way it was designed to be run.
SSH, Composer, Drush and real cron from the first login, on NVMe hardware at a flat renewal rate.
View Drupal Hosting plans