Enterprise Drupal Hosting in Australia: What It Requires

This page explains what enterprise Drupal hosting in Australia actually requires at the infrastructure and application layer, and how to tell whether a prospective host can run Drupal or merely store it. It is written for IT managers, digital leads and agency owners responsible for a Drupal 10 or Drupal 11 site that matters to the organisation.

Why generic Australian hosting underserves Drupal

Most Australian hosting offers are built around a filesystem and a database. You get a control panel, a PHP version selector, a nightly backup and a support desk that will restart services. That model works adequately for a brochure site. It fails for Drupal, because Drupal is not a set of files you upload. It is a Composer-managed application with a build step, a configuration system that lives in version control, a cron contract, a layered cache that must be invalidated correctly, and a published security advisory stream that requires someone to read it every Wednesday and act.

The gap shows up the first time something goes wrong. A core security advisory lands, the host says patching the application is the client's responsibility, and the agency that built the site three years ago no longer has a retainer. Nobody owns the problem. The server is up, the SLA is technically met, and the site is running a version of Drupal with a known remote code execution path. For government and regulated clients that is also an Essential Eight failure, since the ACSC expects internet-facing applications with a known exploit to be patched within 48 hours.

Hosting a Drupal site properly means owning the application layer, not just the box it sits on. Below is what that involves.

Composer is the build system, so the deploy has to be a build

Since Drupal 8, core and contributed modules are managed by Composer. The canonical production install is not what sits in your Git repository. The repository holds composer.json, composer.lock, custom modules and themes, and configuration YAML. The deployable artefact is produced by running composer install --no-dev --optimize-autoloader, which resolves drupal/core-recommended, pulls contributed modules into web/modules/contrib, writes vendor/, and runs drupal/core-composer-scaffold to place index.php, .htaccess and the default settings files.

This is why FTP deploys break Drupal. Dragging files over an existing release leaves the autoloader describing classes that are no longer there, produces a composer.lock that does not match vendor/, and puts the site into a partially-updated state for however long the transfer takes. Worse, it skips the two steps that actually complete a Drupal release: drush updatedb to run database update hooks, and drush config:import to bring configuration into line with the code.

A production-grade Drupal deploy looks like this, in order:

1. Build the release on a build agent, not on the web server, so a failed dependency resolution never touches production.
2. Ship the built artefact to a new, timestamped release directory.
3. Symlink the shared sites/default/files directory and settings.local.php into the release.
4. Put the site into maintenance mode only if the update hooks require it.
5. Run drush updatedb, then drush config:import, then drush cache:rebuild.
6. Atomically switch the document root symlink and reset OPcache.
7. Keep the previous release on disk so rollback is a symlink switch, not a restore.

If a host cannot describe something close to this, they are not deploying Drupal. They are copying files and hoping.

The docroot, settings.php and file permissions

A Composer-managed Drupal project has a nested docroot, usually web/ or docroot/. Everything above it, including vendor/, composer.json and the configuration sync directory, must sit outside the web-accessible path. Hosts that insist on serving the repository root are forcing you to expose dependency source and configuration exports to the internet.

Three permission details cause most of the real-world incidents we see:

• sites/default/settings.php should be read-only to the web user after install, with credentials and environment-specific overrides in a separate settings.local.php that is never committed. If PHP can write to settings.php, any file-write vulnerability becomes a persistent backdoor.
• sites/default/files must be writable by the PHP-FPM user and must never execute PHP. On nginx that means an explicit location block denying \.php$ under the files path, because the .htaccess protections Drupal ships only apply to Apache.
• Private files belong in a directory outside the docroot entirely, with delivery routed through Drupal's file access system. Uploaded documents in government sites routinely contain material that should never be reachable by guessing a URL.

PHP settings that actually matter under Drupal

Drupal 10 requires PHP 8.1 or newer and performs best on 8.3; Drupal 11 requires PHP 8.3 or newer. Version alone is not the issue. The settings below separate a Drupal host from a generic LAMP host:

• memory_limit of 256M as a working minimum, with higher ceilings for CLI so Composer and migration batches do not die mid-run.
• opcache.max_accelerated_files raised well above the default. A Drupal install with a normal contributed module set easily exceeds 20,000 PHP files, and a default OPcache will silently stop caching the remainder.
• opcache.validate_timestamps=0 in production, paired with an explicit OPcache reset in the deploy pipeline. If the reset is missing, you will serve a half-old codebase after every release.
• realpath_cache_size increased, because Drupal's file resolution is path-heavy.
• APCu enabled for the class loader and Drupal's fast chained bootstrap cache.
• On the database side, MySQL 8.0 or MariaDB 10.6+ with utf8mb4, InnoDB and READ COMMITTED transaction isolation. PostgreSQL is fully supported if that suits your environment better.

Cron, queues and the tasks that fail silently

Drupal's default automated cron fires on inbound page requests. On a production site that is the wrong mechanism: it adds latency to a real user's request, it does not run at all when traffic is low, and it is usually the first thing disabled when someone tunes performance. Production Drupal should run drush core:cron from system cron or a scheduler, on a defined interval, with the output logged.

When cron stops, nothing visibly breaks. That is the danger. Search indexes stop updating, XML sitemaps go stale, temporary files are never purged, scheduled content never publishes, and, critically, the Update Status module stops checking drupal.org, so the site stops telling anyone that a security release exists. Sites have sat unpatched for months because a cron entry was lost during a server migration.

Queue workers deserve the same treatment. If you use Search API with a Solr or Elasticsearch backend, a message queue, or any contributed module relying on advancedqueue, those workers need supervised processes with restart policies and alerting on queue depth, not a hope that cron drains them in time.

The caching stack, and the invalidation problem

Drupal's cache system is unusually good, provided the infrastructure respects it. Cache tags and contexts let Drupal tell an upstream cache exactly what to purge when a node changes. Most hosts ignore this and set a blunt time-to-live, which is why editors complain that their changes take 15 minutes to appear.

Getting cache tags flowing from Drupal through to the edge is a configuration exercise that takes a day and saves you from both stale content and origin overload. The same edge also carries your WAF rules and rate limiting, which is why we treat Cloudflare as part of the hosting stack rather than an optional extra.

Security advisories and a real patch window

The Drupal Security Team publishes advisories on a predictable schedule, with core releases on the third Wednesday of the month and contributed project advisories weekly. Each advisory carries a risk score out of 25 and an identifier: SA-CORE- for core, SA-CONTRIB- for contributed projects, PSA- for a pre-announcement warning you to have staff available. History makes the stakes obvious. SA-CORE-2014-005 and SA-CORE-2018-7600 were both exploited in the wild within hours of release.

Core versus contributed

Core advisories are the ones people watch. Contributed modules are where sites actually get compromised, because the average Drupal site carries 40 to 80 contributed projects and only stable releases that have opted into the security advisory policy receive coverage at all. A module pinned to an alpha or a dev branch has no coverage, regardless of how well it works.

A managed arrangement should define, in writing, how fast a highly critical advisory gets to production, who reviews the patch, who regression-tests it, and what happens at 2am on a Saturday. That is a function of your support SLA, not your server specification. Running composer audit against the Packagist advisory database in CI and tracking PHP library CVEs through continuous vulnerability monitoring closes the gap between an advisory being published and someone noticing.

Drupal 10 to 11, and what blocks it

Drupal's release cadence means a major version arrives roughly every two years and the previous major loses security coverage soon after. Drupal 7 reached end of life in January 2025, and organisations that left it until the final quarter found the contributed module ecosystem had already moved on.

The Drupal 10 to 11 move is a dependency and deprecation exercise rather than a rebuild. The work is:

• Install the Upgrade Status module to produce an inventory of incompatible projects and deprecated API calls.
• Run PHPStan with mglaman/phpstan-drupal across custom modules and themes, then apply Drupal Rector for the mechanical fixes.
• Resolve the Symfony major version jump, which breaks custom event subscribers, service definitions and anything touching the HTTP kernel.
• Check every contributed project for a Drupal 11 compatible release, and decide whether to patch, sponsor, replace or remove the ones without.
• Verify the database and PHP versions meet Drupal 11 minimums before the code change, not after.

Most of the elapsed time goes into contributed module readiness, which is exactly the work a host who only owns the server will not do.

Environments, configuration sync and sanitised databases

Drupal's configuration management system exports site configuration to YAML so it can move through environments in version control. It only works if the pipeline respects it. The sync directory belongs outside the docroot, environment-specific differences belong in Config Split, and anything genuinely owned by production editors belongs in Config Ignore. A deploy that does not run drush config:import is not deploying the site you tested.

Production data flowing the other way needs the same discipline. Pulling a live database into staging without running drush sql:sanitize copies real user email addresses, hashed passwords and session data into a lower environment with weaker access controls. For Australian organisations handling personal information under the Privacy Act, that is a notifiable incident waiting to happen. Pair sanitisation with Stage File Proxy so lower environments pull files on demand instead of cloning a 60GB files directory.

Backups, restore testing and recovery targets

A Drupal site is three things that must be restored together: the database, the public and private files directories, and the code artefact with its exported configuration. A database-only backup gets you a site where every image is a broken link. A filesystem snapshot taken mid-write gets you a database that will not import.

Ask for the numbers, not the adjective. What is the recovery point objective, in hours? What is the recovery time objective, in minutes, for a full restore to a working site? When was a restore last performed end to end, and to what environment? Hosts that have never tested a restore invariably discover on the day that the files directory was excluded from the job two years ago. Our standard enterprise arrangement runs six-hourly backups with retention and periodic restore verification, which is also the baseline we apply to managed website hosting generally.

What to ask a Drupal host before you sign

If you are comparing providers formally, our guide to evaluating a managed web services provider sets out the questions that separate the two columns on the right.

Frequently Asked Questions

What does enterprise Drupal hosting in Australia need that standard hosting does not?

It needs a Composer-driven build and deploy pipeline, CLI access for Drush, system cron running drush core:cron, a Redis or Memcached cache backend, tuned OPcache settings for a large PHP file count, and a named party responsible for applying Drupal security advisories. Standard hosting supplies the server and stops at the application boundary. The distinguishing factor is who owns the Drupal codebase after go-live, not the specification of the virtual machine.

Does Drupal hosting have to be in an Australian data centre?

Not always, but for government and most regulated sectors it is a requirement rather than a preference, and procurement will usually ask where data is stored and processed. Hosting in the Sydney region also removes 150 to 250 milliseconds of round-trip latency for Australian users on uncached, authenticated requests, which is where Drupal admin performance is felt. Static assets can still be served globally from a CDN edge regardless of where the origin sits.

How quickly should a Drupal security advisory be patched?

For a highly critical advisory on an internet-facing site, the ACSC Essential Eight expects patching within 48 hours where a working exploit exists, and within two weeks otherwise. In practice, core advisories released on a Wednesday should be assessed the same day, tested in a staging environment, and deployed to production within one business day. Contributed module advisories follow the same process but often require more regression testing because the module is interacting with custom code.

Can we keep our existing cloud account and still get managed Drupal hosting?

Yes. A management-only arrangement is common where an organisation has an existing AWS or Azure commitment, enterprise agreement or internal security tooling it must keep using. The provider takes operational responsibility for the Drupal application, the deploy pipeline, patching, monitoring and backups while infrastructure continues to be billed to your account. The commercial model changes; the technical responsibilities do not.

How long does a Drupal 10 to Drupal 11 upgrade take?

For a site with a moderate contributed module set and well-written custom code, the mechanical work is measured in weeks rather than months, with most of the effort going into contributed project compatibility and Symfony-related fixes in custom modules. Sites with heavily customised entities, abandoned contributed modules or a theme built against older frontend libraries take considerably longer. An Upgrade Status audit on the current codebase gives a defensible estimate before any work is committed.

What happens to our Drupal site if the agency that built it disappears?

Provided the codebase is in Git with a working composer.lock and exported configuration, a competent Drupal team can take over without a rebuild. The risky cases are sites deployed by FTP with no repository, modules patched directly in web/modules/contrib without a patch file, and configuration changes made only in the production database. Those need a discovery and remediation phase before any normal maintenance cadence can begin.

Talk to UnDigital about Drupal hosting and management

UnDigital runs Drupal on Australian infrastructure and takes responsibility for the application as well as the server, which means the same team that keeps the uptime also applies the security advisories, runs the deploys, tunes the cache layers and plans the version upgrades. There is no gap between the hosting provider and the web team to fall into, because they are the same people.

Every engagement starts with an infrastructure and codebase audit so the scope reflects the site you actually have. You can read more about Drupal hosting and ongoing Drupal website management, or get in touch to arrange the audit.