Acorn runs Laravel inside a WordPress install

What Acorn actually gives you

Acorn brings Laravel's ecosystem to WordPress, and the README lists what that means in practice. You can use Blade templates for WordPress views, blocks and more. You get access to Laravel's powerful features within WordPress. You can use Laravel packages in your WordPress projects. And you write better WordPress code with Laravel's patterns and utilities. The claim is that Acorn gives you access to most Laravel components out of the box, including routing, caching, events, validation and more. There is also a growing ecosystem of community packages built specifically for Acorn that add features like WooCommerce support and ACF integration. The position is that the tools and packages you already know from Laravel now work in a WordPress project, rather than you learning a second framework's idioms.

The supported component list is the real documentation

The README enumerates the Illuminate components that Acorn supports, and the list is long: auth, bus, cache, collections, conditionable, config, console, container, contracts, cookie, database, encryption, events, filesystem, hashing, http, log, macroable, pagination, pipeline, queue, routing, session, support, validation and view. That is most of the framework, and it is presented as a plain list rather than a claim. Then there is a details block for the unsupported components, and it is short: broadcasting, mail, notifications, redis and translation. Five exclusions out of thirty. Each of those is a component that would fight with what WordPress already provides or that assumes a Laravel application context, and the honesty of listing them is more useful than a vague statement that some things are not available. If your design depends on the translation component, for instance, that is a blocker you can discover from the README rather than from a runtime error.

The package is a Composer library with a WordPress plugin surface

The repository layout shows how the integration is packaged. There is a `src/` directory, a `config/` directory and a `config-stubs/` directory, which together suggest that Laravel configuration is bootstrapped from stubs so a WordPress install can supply its own values. There is a `bin/` directory for the command line entry point and a `scripts/` directory, plus `tests/` with a phpunit configuration. The build tooling is modern PHP: a `composer.json`, a `mago.toml` for the Mago tool, a `phpunit.xml.dist` for the test configuration, an `.editorconfig`, and a `.devcontainer/` for a reproducible development environment. The `config-stubs` directory is the interesting one, because it is where the line between Laravel's expectations and WordPress's runtime has to be reconciled.

The version line tracks Laravel major versions

The README carries a badge for Laravel v13, which tells you which generation of the framework the current line targets, and the topic tags confirm the shape of the project with acorn, blade, laravel, wordpress, wordpress-framework, wordpress-laravel and wordpress-plugin-library. The release history is regular: v6.3.0 from 2026-09-22, v6.2.0 from 2026-06-01 and v6.1.0 from 2026-04-26, so three releases across a six month window, with a major version bump whenever the Laravel generation changes. The homepage is roots.io/acorn and the installation documentation is linked from the README, which is the document to read before you commit, since how Acorn is installed into a WordPress project is the part that determines whether it fits your build.

The project is funded by sponsorship, not by a company product

The support section explains the economics. Roots is described as an independent open source organisation, supported only by developers like you, and the sponsorship funds WP Packages and the entire Roots ecosystem and keeps them independent. The sponsorship routes are purchasing Radicle or sponsoring on GitHub, and sponsors get access to the private Discord. The visible sponsors are a mix of hosting and development tool companies, which is the usual pattern for a foundation-style project that sells no licences. The relevant part for an adopting developer is that the ecosystem of community packages depends on that funding continuing, and the community channels are a Discord, the Roots Discourse forum, the Twitter account, the blog and a newsletter.

Where the two frameworks collide

The structural challenge is that WordPress and Laravel both want to own the request lifecycle. WordPress has its own plugin loading order, its own hook system, its own database abstraction and its own output buffering, and Laravel has a container, a service provider model, a lifecycle with boot and register phases, and a configuration system. Acorn's job is to run the Laravel side inside the WordPress side without either one corrupting the other, and the `config/` and `config-stubs/` directories are where that negotiation is visible in the repository. The practical consequence for a project is that the pieces of Laravel that assume they are in charge, such as the full HTTP kernel, the exception handler and the route middleware stack, are the parts most likely to need adaptation, which is a plausible reason why the routing component is supported while several others are not.

Editorial conclusion

Adopt Acorn if you are building a WordPress site or plugin that needs Blade templates, a service container or Laravel packages, and you would rather not run a separate Laravel application alongside WordPress. Do not adopt it if you need the five unsupported components, since broadcasting, mail, notifications, redis and translation are explicitly excluded. Verify first which Laravel version your project can live with, that the community package you need exists, and that WordPress and Laravel do not fight over the same global state, since you are running two frameworks' bootstrapping in one process.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. roots/acorn on GitHub