The Roots.io Stack in 2026: Bedrock, Sage, Trellis, Acorn, and Radicle Explained

Emnes April 17, 2026

Network diagram showing the five Roots.io tools — Bedrock, Sage, Trellis, Acorn, Radicle — connected around a central Roots hub

Most WordPress sites in 2026 still look like they did in 2011: a directory of PHP files committed to Git, credentials in wp-config.php, plugins installed via drag-and-drop, and a deploy process that is some combination of SFTP and prayer. That approach still works for simple blogs. It falls apart the moment you hire a second developer, need a staging environment, or want a production deploy that doesn’t take the site down for 30 seconds.

The Roots.io stack is the most established answer to that problem. For over a decade, an independent team led by Ben Word and Scott Walkinshaw has been building open-source tools that borrow the best ideas from Laravel, modern PHP, and DevOps culture — and applying them to WordPress. In 2026, the stack is more mature, more integrated, and more widely adopted than ever, powering tens of thousands of production WordPress sites from solo freelance projects to enterprise media properties.

This guide is a complete, practical introduction to the five Roots.io tools — Bedrock, Sage, Trellis, Acorn, and Radicle. We’ll cover what each one is, what problem it solves, how they fit together, and — critically — when they’re the right choice and when they aren’t. By the end, you’ll have a clear mental model of the stack and enough context to decide whether to adopt all of it, some of it, or none of it for your next WordPress project.

What Is Roots.io?

Roots.io is an independent, community-funded open-source organization founded in 2011. Its stated mission is to “make WordPress development less painful and more in line with industry best practices.” In practice, that means taking conventions that are standard in other PHP ecosystems — Composer-managed dependencies, dotenv configuration, Blade templating, Ansible provisioning, Vite-based asset pipelines — and making them work with WordPress without fighting the platform.

Roots doesn’t replace WordPress. Every site built on the Roots stack runs the same WordPress core, the same plugins from the WordPress.org directory, the same themes. What changes is the developer experience — how the code is organized, how dependencies are declared, how environments are configured, and how deploys happen.

The project is funded through GitHub Sponsors (with tiers ranging from $10/month for Discord access to $320/month for full sponsor placement) and a single paid product, Radicle. Its core tools — Bedrock, Sage, Trellis, and Acorn — are all free and MIT-licensed. Over 100 sponsors support the project, including hosting companies like WordPress.com, Kinsta, and independent agencies.

The Five Tools in the Roots.io Stack

Each Roots tool solves one specific problem. You can use any of them independently — Bedrock without Sage, Sage without Trellis, Trellis to deploy a non-Roots site — and the tools compose cleanly when you use them together.

Bedrock — the WordPress boilerplate. Solves: code structure, dependency management, environment configuration.
Sage — the starter theme. Solves: modern frontend tooling, Blade templating, design-system integration with the block editor.
Trellis — the provisioning and deployment tool. Solves: setting up a production-grade server, zero-downtime deploys, environment parity.
Acorn — the Laravel bridge. Solves: bringing Laravel’s service container, Blade, Eloquent, and console commands into WordPress without replacing it.
Radicle — the opinionated starter. Solves: “I want all of the above, already wired up, without gluing them together myself.”

Bedrock — A Composer-Based WordPress Boilerplate

Bedrock is where most teams start with Roots. It’s a boilerplate that restructures a WordPress project so it behaves like a modern PHP application: dependencies are declared in composer.json, secrets live in a .env file that’s never committed, and per-environment configuration lives in clean PHP files rather than a tangle of if-statements inside wp-config.php.

The current stable version as of April 2026 is Bedrock 1.30.1, shipping with WordPress 6.9.x and requiring PHP 8.3 or higher. A typical Bedrock project looks like this:

├── composer.json
├── .env # git-ignored, per-environment secrets
├── config/
│ ├── application.php
│ └── environments/ # dev / staging / production overrides
└── web/ # public document root
    ├── app/ # custom wp-content
    │ ├── plugins/
    │ ├── themes/
    │ └── uploads/
    ├── wp-config.php
    └── wp/ # WordPress core, managed via Composer

The big wins Bedrock gives you:

WordPress core is a Composer dependency. Updating core is composer update roots/wordpress. Your Git repo never contains core files, so diffs stay clean and conflicts disappear.
Plugins are declared, not uploaded. Every plugin — free ones from WordPress.org via WP Packages or WPackagist, paid ones via private Composer repositories — is listed in composer.json at a specific version. Deploys are deterministic.
Secrets never touch Git. Database credentials, auth keys, and API tokens live in a .env file loaded by vlucas/phpdotenv. Leaked-credential incidents drop to zero.
Sensible production defaults. File editing via the WordPress admin is disabled outside development, auto-updates are turned off (you’ll update through Composer instead), and debug output is suppressed in production.

The tradeoff is that clients can no longer install plugins through the WordPress admin UI — doing so puts the plugin on the server’s filesystem but not in composer.json, so the next deploy wipes it. This is a feature for disciplined teams and a footgun for hand-off-to-non-technical-client scenarios. Bedrock is for teams that treat WordPress like a real application; it’s overkill for a brochure site that will never change.

Sage — A Starter Theme with Blade, Vite, and Tailwind

Sage is Roots’ WordPress starter theme and the most popular Roots project, with over 13,000 GitHub stars. It’s a blank theme designed for developers who want to build custom designs with the same tools they’d use on any modern PHP or JavaScript project — Blade templating, Vite for asset bundling and hot module replacement, and Tailwind CSS as the default utility framework.

Sage 11, released in March 2024 and now on version 11.2.0, was a major rewrite. Previous versions used Bud.js for asset bundling; Sage 11 moved to Vite, which is faster, better supported by the broader JavaScript ecosystem, and — critically — supports hot module replacement inside the iframed WordPress block editor. Sage 11 also ships with Tailwind CSS v4 and Acorn v5 (now v6), and requires PHP 8.3.

A Sage theme looks quite different from a traditional WordPress theme:

Blade templates, not PHP spaghetti. Instead of header.php and footer.php with <?php echo ... ?> scattered through the markup, you get .blade.php files with template inheritance, components (<x-button />), slots, and compile-time optimization.
Vite-powered assets with HMR. Save a CSS file, and the block editor refreshes the style without a full reload. JavaScript changes ship to the browser in milliseconds.
Tailwind-first theme.json. The block editor’s design tokens — colors, font sizes, spacing — are generated from your Tailwind config at build time, so frontend styles and block editor styles stay in sync.
First-class block editor support. editor.css and editor.js are dedicated entry points for the block editor, separate from the frontend.

Sage is the right choice when you’re building a custom design that won’t be assembled from off-the-shelf blocks. It’s the wrong choice if you want a Customizer-driven, client-theme-options experience — that’s not what Sage optimizes for. It’s also PHP 8.3 minimum and requires a Node.js build step, which rules it out of the cheapest shared hosting.

Trellis — Provisioning and Zero-Downtime Deploys

Trellis is Ansible-based infrastructure-as-code for WordPress. One command provisions a production-grade LEMP server; another command deploys your WordPress site to it with zero downtime. The current version is Trellis 1.31.1 paired with the trellis-cli at 1.17.x.

Out of the box, Trellis provisions:

Ubuntu 24.04 with hardened defaults, fail2ban, and UFW firewall
Nginx with HTTP/2, HTTP/3, OCSP stapling, HSTS, strong TLS, and FastCGI micro-caching
PHP 8.3 with OPcache tuned for WordPress
MariaDB with sensible InnoDB settings
Redis for object caching and PHP session storage
Memcached as an optional secondary cache
Let’s Encrypt SSL with automatic renewal
msmtp for outbound mail (replaced ssmtp in v1.31)

Deploys are where Trellis really shines. Every deploy creates a new timestamped directory (releases/20260418142032/), clones fresh code into it, runs composer install, links shared files (uploads, .env), and then atomically flips a current/ symlink to point at the new release. There’s no moment where half the files are new and half are old. If something’s wrong, trellis rollback flips the symlink back in seconds. Trellis keeps the last five releases, giving you instant multi-step rollback.

The 2025–2026 releases brought major changes worth knowing:

Vagrant support was dropped in favor of Lima VMs in October 2025. Local development is now faster, uses native macOS virtualization, and has far less filesystem friction.
Pluggable server providers landed in trellis-cli 1.17: Hetzner Cloud and DigitalOcean are first-class options for one-command server provisioning.
HTTP/3 support, Redis session storage, and Composer custom-header authentication for premium plugin repositories.

Trellis is the right choice when you control your own server — a VPS on DigitalOcean, Hetzner, Linode, AWS, or similar — and want the same deploy workflow across every site your team manages. It’s the wrong choice on managed hosts like Kinsta or WP Engine, which block Ansible and manage the stack themselves (Kinsta supports Bedrock and Sage on their infrastructure; you just don’t use Trellis for provisioning there).

Acorn — Laravel Features Inside WordPress

Acorn is the newest of the core Roots tools and the hardest to explain in a single sentence. The closest: Acorn is a Composer package that loads a Laravel application inside WordPress, giving you access to Laravel’s service container, Blade templating, Eloquent ORM, Artisan-style console commands, queues, validation, events, mail, and cache — all while WordPress continues to run normally on the same request.

Acorn 6.0.0, released in March 2025 and announced in the March 2026 Roots blog post “Acorn v6 Released”, supports Laravel v13, requires PHP 8.3, and pulls in roughly 26 Laravel packages by default. Sage 11 ships with Acorn as a dependency — it’s the engine that powers Sage’s Blade rendering, view composers, and theme.json generation.

What Acorn makes possible:

Blade templating with full component and slot support, used by Sage for every template.
Eloquent ORM — querying the wp_posts and wp_postmeta tables with Laravel-style fluent syntax instead of WP_Query.
Service container and dependency injection — wire up custom classes with auto-resolved dependencies, just like in a Laravel project.
Laravel migrations — versioned database schema changes managed alongside your code, rather than hand-rolled SQL.
Console commands — wp acorn make:block BlockName scaffolds a new block with server-side rendering and editor UI.
Ecosystem packages like Acorn Post Types (declarative CPTs), Acorn User Roles (config-driven user roles), and Acorn AI (Laravel’s AI framework wired to WordPress’s new Abilities API).

Acorn is the right choice when your team includes Laravel developers or when you need features that WordPress doesn’t have clean primitives for — versioned DB migrations, a proper queue, a service container. It’s overkill for simple content sites that only need the block editor and a theme.

Radicle — The Whole Stack, Pre-Wired

Radicle is the one paid Roots product. It’s a starter template that combines Bedrock, Sage, and Acorn into a single Laravel-style project structure, with a curated set of mu-plugins and conventions already wired up. The current version is v2.6.0 (April 2026).

The Radicle directory layout looks more like a Laravel app than a WordPress project:

app/ # PHP classes, controllers, providers
bootstrap/
config/ # app + WordPress + Acorn config
public/ # web root
└── content/ # wp-content replacement
resources/
└── views/ # Blade templates — NOT inside a theme folder
storage/
vendor/

Notice that Blade views live at the project root, not inside a theme. This is the key Radicle idea: your custom code is a first-class application that happens to use WordPress as a CMS, rather than a theme and a pile of plugins sitting inside WordPress.

Radicle ships with:

Curated mu-plugins — Extended CPTs, Allow SVG, Query Monitor, Acorn Prettify, Acorn Mail, Blade Icons — already installed and configured.
Acorn at the project level, not just inside the theme, so controllers and Laravel services are top-level concerns.
Laravel-style REST APIs — define routes that return Eloquent-queried JSON, without fighting WordPress’s REST API patterns.
Laravel migrations as a first-class feature (Kinsta has a good tutorial on this: “Running Laravel-style database migrations in WordPress with Radicle“).
Testing scaffolding with Pest and PHPUnit.

The tradeoff is price (Radicle is a one-time purchase per customer, though pricing is reasonable for an agency) and opinionation (if you want Bedrock + Sage but not Acorn, you’re better off composing them yourself). Radicle is for shops that have bought into the entire Roots philosophy and want to skip the glue-code step on every new project.

How the Tools Fit Together

The most common production setup combines three or four of the Roots tools:

Bedrock as the root-level project structure
Sage as the theme inside web/app/themes/
Acorn pulled in as a Composer dependency of Sage (or at the project root, if you’re doing advanced Laravel-style work)
Trellis as a sibling directory that provisions the server and runs deploys

The full layout of a real-world Roots project often looks like:

my-project/
├── site/ # Bedrock
│ ├── composer.json
│ ├── .env
│ ├── config/
│ └── web/
│ └── app/themes/sage/ # Sage theme, using Acorn
└── trellis/ # Ansible + deploy scripts

A developer works on the Sage theme with pnpm run dev, commits changes, and pushes to Git. A CI pipeline or a direct trellis deploy production my-project.com runs Composer on the server, compiles assets, rsyncs built files, and flips the release symlink. Zero downtime, fully repeatable, no mystery state.

If you start a new project with Radicle instead, you get all of this pre-wired — Acorn at the root, Sage-style Blade templates in resources/views/, Bedrock-style Composer management, and Trellis still as an optional deploy layer.

The Broader Roots Ecosystem in 2026

Beyond the five core tools, Roots maintains or sponsors several ecosystem projects worth knowing about:

WP Packages — an independent, open-source Composer repository at wp-packages.org that mirrors the WordPress.org plugin and theme directory. Announced in March 2026 as an alternative to WPackagist, with better reliability and features like SVN revision pinning for dev-trunk versions.
WP Sec Adv — a Composer repository that feeds Wordfence security advisories into composer audit, so vulnerable plugins and themes are caught at dependency-resolution time rather than during an attack.
Acorn ecosystem packages — Acorn AI, Acorn User Roles, Acorn Post Types, Acorn Mail, and Blade Icons, each a focused package that composes cleanly with the rest of the stack.
Roots Radio — a long-running podcast covering Roots projects, WordPress development, and interviews with community figures.
Discourse forum at discourse.roots.io with active categories for each project.

The ecosystem has a clear philosophical center: treat WordPress like a real PHP application, borrow good ideas from Laravel and modern DevOps, don’t fight the platform but don’t accept its worst defaults either.

When the Roots Stack Is the Right Choice

After running the Roots stack across many production sites (including this one), here’s where it pays off:

You have a team, not just yourself. Multiple developers working on the same site without stepping on each other requires real version control, deterministic dependencies, and per-environment config. All of that comes free with Bedrock + Trellis.
You run multiple sites. Trellis lets you provision and deploy dozens of sites from one Ansible repo with consistent configuration, instead of maintaining each server by hand.
You ship frequently. Zero-downtime deploys matter when you deploy ten times a week, not once a quarter.
You have developers with Laravel experience. Acorn and Sage let them bring their existing skills to WordPress with minimal adjustment.
You care about security posture. Composer-managed dependencies + .env secrets + WP Sec Adv audit + read-only deploys from Git are a dramatically stronger supply chain than the typical WordPress drag-and-drop workflow.

When to Skip Roots

You’re building a single-page brochure site that will never change. The overhead of Composer, .env, and deploy scripts isn’t worth it for five static pages.
Your client installs plugins themselves. The Bedrock workflow fights non-technical clients who expect to click “Add New Plugin.” Some agencies solve this with training; others simply don’t use Bedrock on those projects.
You’re on $3/month shared hosting. Roots needs SSH, Composer, and ideally a VPS you control. Cheap shared hosts often don’t offer any of that.
Your team has no Composer, CLI, or Git experience. The learning curve is real. Before adopting Roots, someone on the team needs to be comfortable with all three.
You’re committed to full-site-editing (FSE) block themes. Sage supports FSE partially, but if your whole workflow is Gutenberg-first, the Sage advantage shrinks.

Frequently Asked Questions

Is Roots.io free to use?

Yes — Bedrock, Sage, Trellis, and Acorn are all MIT-licensed and free. Only Radicle, the all-in-one starter, is a paid product. Roots is funded through GitHub Sponsors and Radicle sales, not through locking features behind paywalls.

Do I need to use all the Roots tools together?

No. Each tool is standalone. You can run Bedrock without Sage, Sage without Trellis, and so on. The tools are designed to compose well when used together, but there’s no requirement to adopt all of them at once.

Does Roots work with managed hosts like Kinsta or WP Engine?

Partially. Kinsta officially supports Bedrock, Sage, and Radicle deployments via DevKinsta and their Git push workflow. WP Engine supports Bedrock and Sage with some configuration. In both cases, you don’t use Trellis for provisioning (the host manages the stack), but you get the Bedrock and Sage benefits. Self-hosted VPS users get to use the full Trellis workflow.

What’s the difference between Bedrock and Radicle?

Bedrock is an unopinionated boilerplate that restructures WordPress for Composer. Radicle is an opinionated starter that combines Bedrock + Sage + Acorn + curated mu-plugins in a Laravel-style layout. If you want to choose every piece yourself, use Bedrock. If you want “all of Roots, already wired up,” buy Radicle.

How steep is the learning curve?

Honestly, it’s real. You’ll need working knowledge of Composer, dotenv, Git, Blade (if using Sage), Vite, Tailwind (if not swapping it out), Ansible (if using Trellis), and possibly Laravel concepts (if going deep on Acorn). A developer comfortable with modern PHP can get productive on Bedrock in a day and Sage in a week. Trellis takes longer — plan a week or two to be comfortable provisioning and debugging servers.

Is Sage compatible with block themes and full-site editing?

Partially. Acorn 4.1+ added FSE support — Blade files take precedence over block templates when both exist. There’s also a community fork, strarsis/sage10-fse, that goes fully FSE. Roots’ stance is to support both paradigms rather than force one. If your design is block-first and you don’t need Blade, a native block theme may be a simpler choice.

Start Small, Grow Into the Stack

The most common onboarding path we see with teams new to Roots is: adopt Bedrock first on a new project, get comfortable with Composer-managed WordPress, then introduce Sage on the next project, then Trellis on the project after that. By the time you’re running Trellis in production you’ve absorbed the Roots mental model gradually rather than all at once. Radicle, when you’re ready, collapses that onboarding into a single paid starter.

At Emnes, the entire monorepo of 18 WordPress sites — including this one — runs on Bedrock + Sage + Trellis. We’ve been running the stack in production for years, and every plugin we release is tested against it. If you’re thinking about adopting Roots for your next WordPress project, get in touch — we’re happy to share what we’ve learned and help you make the right call for your team.

This is the first post in a series covering the Roots.io ecosystem in depth. Over the next few weeks we’ll publish detailed guides on each component: Bedrock, Sage, Trellis, Acorn, and Radicle. Subscribe to the newsletter or bookmark the blog to follow along.