Silverstripe Hosting in Australia: What It Actually Requires

This page explains what Silverstripe CMS actually requires from a hosting environment, why most generic Australian web hosts cannot run it correctly, and how to tell whether your current arrangement is hosting the platform or merely storing it.

Silverstripe is the CMS of choice for a large share of Australian and New Zealand government and enterprise websites. It is also the platform most often placed on hosting that was never designed for it, usually because the site was quoted as "just a PHP site" by someone who had never deployed one. The result is a site that runs, more or less, until the day it needs a build, a flush, a patch or a traffic spike.

Why Silverstripe Is Not a Drop-In on Generic Shared Hosting

A WordPress site can be dragged onto almost any cPanel account and it will work. Silverstripe cannot, and the reasons are structural rather than incidental.

• The application is assembled by Composer at deploy time, not shipped as a folder of files. There is no supported way to install or update it through FTP.
• Since Silverstripe 4, the web root is the public/ directory, not the project root. Hosts that hard-code the document root to public_html and refuse to change it will expose vendor/, .env and your YAML configuration to the internet.
• Schema changes are applied by a build task (dev/build) that must run with the same PHP binary, environment variables and file permissions as the web process.
• A class and configuration manifest is compiled into a cache directory. If that directory is not writable by both the deploy user and the web user, the site fails after deployment rather than during it.
• Several standard modules depend on a background worker process or cron entry. Shared hosting often permits neither.

None of this is exotic. It is simply a modern PHP application, and it needs an environment built for one.

The Server Requirements Silverstripe Actually Has

PHP version, and why it forces the upgrade conversation

Each major line of Silverstripe raises the supported PHP floor, and the platform does not run on unsupported PHP for long. Broadly:

Always confirm the exact constraint against the release notes for the specific minor line you are on. The point for a hosting decision is that the PHP version is not a preference. It is a dependency, and a host that cannot give you a specific patch version of PHP per site, on both the web SAPI and the CLI, will eventually block your upgrade path from Silverstripe 4 to 5 or your move on to 6.

A frequent and maddening failure is a version mismatch between the web PHP and the CLI PHP. The site runs on 8.1 and the cron user runs 8.0, so scheduled tasks and queued jobs die silently while the front end looks perfectly healthy.

Extensions, limits and directories

• Required extensions: intl, mbstring, dom, xml, simplexml, tokenizer, ctype, fileinfo, iconv, curl, zip, session, pdo with the relevant database driver, and gd or imagick for image manipulation.
• memory_limit of at least 512M for Composer operations and dev/build. The default 128M on shared hosting will not complete a build on a site with many DataObjects.
• OPcache enabled, with a cache reset built into the deployment step. Without it, a release can serve a mix of old and new class files.
• A writable temporary cache directory outside the web root, owned consistently. Running dev/build as root and then serving as www-data is one of the most common causes of a post-deploy white screen.

Web server configuration

Apache can use the shipped .htaccess in public/, provided AllowOverride and mod_rewrite are enabled. Nginx has no equivalent, so the rules must be written by hand: route everything not matching a real file to index.php, and explicitly deny requests for /vendor, /.env, /assets/.protected and the cache directory. Nginx configurations copied from a WordPress template are a standing security problem on Silverstripe sites, because they assume nothing sensitive sits beside the index file.

Deployment: Composer, Build Steps and dev/build

A correct Silverstripe deployment is a sequence, not a file copy:

1. composer install --no-dev --optimize-autoloader against the committed lock file, so the build is reproducible.
2. The Composer vendor plugin exposes module assets into public/_resources. If this step is skipped, the CMS loads with no styling and no JavaScript.
3. Front end asset compilation, if the theme uses a build toolchain.
4. sake dev/build from the CLI, with the environment loaded, to apply schema changes.
5. A manifest flush and OPcache reset before the release is switched live.

Two details matter more than they look. First, dev/build is additive: it creates tables and columns but never drops them, so schema drift accumulates quietly across years of development. Second, ?flush=1 on a live site under load is dangerous, because every concurrent request attempts to rebuild the manifest at once. On a properly configured environment the cache is warmed on the new release directory before traffic is switched to it, which is why atomic symlink deployments and a real CI/CD pipeline are not optional extras for this platform.

Assets, File Storage and the Public Directory

Silverstripe 4 and later split file storage in two. Published files live under public/assets and are served directly by the web server. Draft, restricted and unpublished files live under assets/.protected with hashed paths and are streamed through PHP after a permission check.

This breaks in predictable ways. A CDN or nginx rule that serves /assets straight from disk will either bypass the permission check or return 404s for draft files that editors can see in the CMS. A load balanced pair of web servers with local disks will drift apart within a day of editors uploading files, so assets need shared storage: NFS or EFS, or an S3 backed Flysystem adapter with the CDN in front of it. Migrating an existing site into S3 storage is a task in its own right, not a configuration toggle, because the legacy file paths must be rewritten as they move.

Database Behaviour Under Load

Silverstripe runs on MySQL 5.7 or later and MariaDB, with PostgreSQL available through a community maintained module that does not have full feature parity. For anything with a compliance obligation, MySQL 8 or a supported MariaDB release is the safer choice.

The behaviour that surprises people is the ORM under content weight:

• Versioned tables grow without bound. Every publish writes to _Versions, and on a site using Elemental content blocks each page publish can write dozens of version rows across multiple block tables. Sites that have been edited daily for five years routinely carry version tables an order of magnitude larger than the live tables.
• Lazy loading produces N+1 queries. A template loop that touches a relation on each item issues a query per iteration. Recent Silverstripe 5 releases added explicit eager loading on DataLists, which resolves it, but only if someone reads the slow query log and applies it.
• Partial match filters are full table scans. A search page built on PartialMatchFilter generates LIKE '%term%', which no index will help. At scale that needs a real search index rather than a bigger database server.
• Custom indexes must be declared. Silverstripe indexes relation fields, but filters on your own fields need private static $indexes in the model and a rebuild to take effect.

Tuning the InnoDB buffer pool to hold the working set, enabling the slow query log with a low threshold, and reviewing it monthly will find more performance than any amount of extra CPU.

Background Jobs, Scheduled Tasks and Search

Most enterprise Silverstripe sites run the queued jobs module. It requires either a cron entry executing the queue processor every minute, or a supervisor managed long running worker. If neither exists, scheduled publishing, bulk imports, sitemap regeneration, notification emails and static cache rebuilds all queue up and never run, with no visible error on the front end. Monitoring should alert on queue depth and on the age of the oldest unprocessed job, not just on whether the site returns a 200.

Full text search through the fulltextsearch module typically means running Solr, which is a JVM service with its own memory profile, its own patching schedule and its own reindexing tasks. No shared host will run it for you.

Caching Layers That Actually Work on Silverstripe

• Partial caching in templates, with cache keys that include every piece of state the block depends on, including member status. Getting a key wrong shows one visitor another visitor's content.
• Static publishing via the static publish queue module, which writes rendered HTML on publish. Effective for content sites, and dependent on the queue worker described above.
• HTTP cache control. Silverstripe's cache control middleware deliberately sends no-cache headers for authenticated sessions and CMS requests. Any edge configuration must respect that and bypass the cache when a session cookie is present.
• Edge caching and WAF. Putting Cloudflare in front of the origin absorbs traffic spikes and bot load, but the cache rules have to be written against Silverstripe's actual behaviour, including form submissions carrying a SecurityID token that must never be cached.

Security Patching and the Silverstripe Release Process

Silverstripe publishes security advisories with their own identifiers and, where applicable, CVE numbers, and pre-notifies partners under embargo before public disclosure. Patches are issued only for supported minor lines. This has a consequence that catches many organisations: staying secure is not just applying patches, it is staying current enough on minor releases to be eligible for them.

Because the CMS is installed as a recipe, a patch typically updates a set of modules together. That makes a staging environment mandatory, along with regression checks over the CMS interface, forms, file handling and any custom modules, before the change reaches production. Applying a Silverstripe security release blind on a Friday afternoon is how a working site becomes an incident. This is ongoing Silverstripe website management work, and it is exactly the work that pure infrastructure providers exclude from scope.

Hosting Models Compared

What Breaks When Hosting and Development Are Separate Vendors

The most expensive Silverstripe failures are rarely technical mysteries. They are boundary disputes. The hosting provider confirms the server is up, CPU is normal and disk is fine, which is true. The development agency says nothing has been deployed for six weeks, which is also true. Meanwhile the queue worker stopped after a kernel update, no one owns the queue worker, and the site has not published a page in nine days.

Other common versions of the same problem: a PHP minor upgrade rolled out by the host breaks a module and nobody had a staging environment to catch it; a security release lands and the host says patching is the developer's job while the developer says they are no longer on retainer; disk fills with version table growth and log files and the fix requires a database change nobody is authorised to make. Every one of these needs someone who can read a stack trace and change infrastructure in the same afternoon. That is why the useful contract is one that covers both layers with a single response time, which is what a properly written website support SLA for enterprise and government is for.

Frequently Asked Questions

Can Silverstripe run on standard shared hosting in Australia?

Technically yes, in the sense that PHP will execute. In practice most shared hosting cannot set the web root to the public/ directory, cannot give you SSH and Composer, cannot run a queued jobs worker, and cannot guarantee that the CLI PHP version matches the web PHP version. Sites on shared hosting usually work until the first upgrade or the first traffic spike, then need to be moved.

What PHP version does Silverstripe need?

It depends on the major line. Silverstripe 4 supported PHP 7.x and, in later patch releases, PHP 8.0 and 8.1, but it is now end of life. Silverstripe 5 requires PHP 8.1 or later and Silverstripe 6 requires a current PHP release. Confirm the exact constraint in the release notes for your specific minor version before planning a server upgrade.

Does Silverstripe hosting need to be in Australia?

For commercial sites the main argument is latency to Australian visitors and to any locally hosted integrations. For government agencies and organisations handling personal information, data residency policies and procurement requirements often make onshore hosting non-negotiable, which means an Australian region for both the application servers and the database, including backups.

Why does my Silverstripe site break after a deployment?

The three usual causes are a missing dev/build, a manifest cache directory with the wrong ownership after the build was run as a different user, and Composer's vendor expose step not running, which leaves the CMS without its CSS and JavaScript. All three are eliminated by a scripted deployment pipeline that performs the steps in a fixed order and warms the cache before switching traffic.

How often should Silverstripe security patches be applied?

Security releases should be assessed as soon as they are published and applied on a timeframe matched to their severity, with critical advisories treated as an out-of-cycle change rather than waiting for the next maintenance window. Patches are only issued for supported minor lines, so an ongoing programme of minor upgrades is part of staying patchable at all.

Can you take over hosting for a Silverstripe site built by another agency?

Yes, and it is a routine engagement. It starts with an audit of the codebase, the Composer lock file, the current server configuration, the asset store and the database, followed by a staged migration with DNS cut over last. Sites are commonly found to be several minor versions behind, running unsupported PHP, or missing a queue worker entirely.

Silverstripe Hosting and Management with UnDigital

UnDigital is an official Silverstripe Partner and has been building and running Silverstripe sites for Australian government and enterprise organisations for over a decade, including pioneering the platform's use within NSW Government. We host on dedicated Australian infrastructure with 24/7 monitoring, 6-hourly backups, WAF and DDoS protection, and uptime SLAs from 99.9 to 99.99 per cent.

The distinction that matters is that we do not stop at the server. Composer deployments, dev/build execution, queue worker supervision, asset store configuration, slow query review, security release testing and minor version upgrades are all inside scope, because they are what running this platform actually involves. If you already have AWS or Azure infrastructure you want to keep, we can take the management layer only. Everything begins with an infrastructure audit and is scoped individually.

See Silverstripe hosting for the hosting side, or our Silverstripe hosting and maintenance partner agency page if you are an agency looking to hand fulfilment to a specialist.