Bedrock and Roots: Modern WordPress Stack Hosting Requirements

Bedrock does not ask much of a server, but the few things it does ask rule out a large share of budget hosting plans. The modern WordPress stack from Roots expects SSH access, Composer 2.x, PHP 8.0 or newer, and a document root you can repoint at a web/ subdirectory. Miss any one of those and the deploy fails long before WordPress prints a single line of HTML.

Most write-ups explain what Bedrock, Sage and Trellis are. Fewer explain the boring infrastructure questions that decide whether your host can actually run the thing. That is what this post covers.

How Bedrock Rearranges the Server

The Bedrock WordPress boilerplate moves WordPress core into web/wp, moves wp-content to web/app, and pushes wp-config.php and your dependency files above the public directory. Credentials live in a .env file that never gets served. That layout is the whole point: nothing outside web/ should be reachable over HTTP.

Which means the first hosting question is simple. Can you set the document root to a subfolder of the repository? Plenty of shared plans hard-wire the vhost to public_html and offer no way to change it, and a symlink workaround is fragile at best.

The Baseline Requirements Checklist

• PHP 8.0 minimum, 8.2 or 8.3 in practice, with memory_limit at 256 MB or higher for Composer runs and WP-CLI tasks.
• MySQL 8.0 or MariaDB 10.6+, matching what WordPress.org recommends for core.
• SSH access with a real shell, not a restricted file manager terminal.
• Composer 2.x installed globally or installable to the user account.
• Git on the server, or a CI runner that can push build artifacts to it.
• A configurable document root pointing at web/.
• Environment variable support, either through a readable .env file or server-level vars.
• A writable uploads path that survives deploys, usually web/app/uploads symlinked to shared storage.
• Real system cron, so you can disable WP-Cron and run wp cron event run on a schedule.

Nine items, and the last four are where cheap plans quietly fall over. We see teams get Bedrock installed fine and then discover uploads vanish on the next release because nothing was symlinked.

Why Shared Hosting Usually Breaks the Roots Stack

Running composer install on a shared box often trips a process memory cap or a CPU limit mid-dependency-resolution. The install dies halfway, leaves a partial vendor/ directory, and the site returns a fatal error. Build on a local machine or a CI runner instead, then ship the finished tree.

There are two other recurring problems worth naming. Some hosts run their own mu-plugins that assume the standard wp-content path, which Bedrock has renamed. Others block outbound connections to Packagist, so dependency resolution never completes at all. Check both before you commit to a plan, and read our notes on running Composer for WordPress on the server if you plan to build remotely.

Sage, Acorn and the Node Build Step

If you are pairing Bedrock with Sage, the theme adds a second toolchain: Node 18 or newer, plus Yarn or npm, plus a Vite build that compiles Blade templates, Tailwind and JavaScript into a manifest. Acorn brings Laravel components into the theme layer and wants PHP 8.1+ at minimum.

Almost nobody runs that build on production. The standard pattern is to compile assets in CI, commit nothing but the built output, and deploy the artifact. Our walkthrough on CI/CD pipelines for WordPress theme deployment covers the mechanics.

For a closer look at this topic, see our guide: Optimizing the WordPress REST API for Headless Applications.

We cover this topic in more depth in The Role of IPv6 in Modern WordPress Hosting.

Related reading: WordPress as an App Backend: Hosting Requirements for React/Vue Frontends.

We cover this topic in more depth in Hosting Requirements for Web3 and Blockchain Integrations in WordPress.

Related reading: How to Restrict WordPress Access by IP Address in .htaccess or Nginx.

Trellis or Managed Hosting: Where the Stack Lives

Trellis provisions Ubuntu servers with Ansible and gives you Nginx, PHP-FPM, MariaDB and Let’s Encrypt configured for Bedrock out of the box. It is excellent and it is also a server you now own, with kernel patches, monitoring and backup verification as your problem.

The alternative is managed hosting that happens to be flexible enough for a Roots project. The criteria are narrow but firm:

• Document root configurable per site, per environment.
• SSH keys, not password auth, with a per-site user.
• Staging that clones the environment rather than just the database.
• Deploy hooks you can call from GitHub Actions or GitLab CI.
• PHP version pinning, so a platform-wide upgrade does not break a composer constraint overnight.

Teams running client work on a business WordPress hosting plan usually land here, because the ops overhead of a fleet of Trellis servers stops being worth it past five or six sites. Version control over the PHP runtime your host provides matters more than raw benchmark numbers once your codebase has real dependency constraints.

Deployment Patterns That Actually Hold Up

Atomic deploys are the expected model for a Bedrock project. Each release lands in a timestamped directory, shared paths are symlinked in, and the live symlink flips only after the build succeeds. Rollback becomes a symlink change rather than a restore.

Three details cause most of the failures we get asked about. Uploads must be symlinked to shared storage or they disappear between releases. The .env file belongs on the server, generated at provision time, never in Git. And database credentials differ per environment, so WP_ENV has to be set correctly or Bedrock will load the wrong config branch.

Migration is its own exercise. Converting a legacy install to Bedrock means moving core, rewriting content paths, and often transferring the domain and hosting at the same time, which is worth sequencing on paper before you touch DNS.

When the Roots Stack Is Overkill

Bedrock pays off when multiple developers touch the same codebase, when plugin versions need to be pinned and reviewed, and when deploys have to be repeatable. A single-author site with eight plugins and no build step gets very little from it, and the maintenance tax is real.

Threads on Reddit and issues on the Roots GitHub repo circle the same conclusion: adopt it for team projects and client retainers, skip it for a personal site. Straightforward WordPress blog hosting with automatic updates will serve that reader better than a Composer workflow nobody maintains.

Frequently Asked Questions

Is WordPress Outdated in 2026?

No. WordPress still powers roughly 43% of all websites and around 60% of the CMS market, and the gap to the next platform remains enormous. The Roots stack exists precisely because the core application is worth modernising rather than replacing, layering Composer, Blade and environment config onto software that is still under active development.

What Are the Minimum Hosting Requirements for WordPress?

WordPress core recommends PHP 7.4 or greater, MySQL 8.0 or MariaDB 10.5 or greater, HTTPS support, and either Nginx or Apache with mod_rewrite. Bedrock raises that floor: recent releases require PHP 8.0 or newer, plus SSH, Composer and a configurable document root that core itself never needs.

Is NASA Using WordPress?

Yes. NASA runs several public properties on WordPress, including nasa.gov and science.nasa.gov, which moved to the platform as part of a consolidation of its web estate. Government and university use is common because WordPress handles high-traffic editorial publishing well on standard LAMP or LEMP infrastructure.

Is PHP 8.3 Stable for WordPress?

Yes, PHP 8.3 has been stable since its November 2023 release, and WordPress core is compatible with it. Active support ended in December 2025 with security fixes continuing to December 2027 per the official PHP support schedule, so 8.3 or 8.4 is the sensible target for a new Bedrock project today.

Get Your Bedrock Project on Hosting That Fits It

If you need SSH, Composer, per-environment PHP pinning and a document root you control, tell us what your deploy pipeline looks like and we will confirm the setup before you migrate. Free migration is included on every plan.