Bedrock a Modern WordPress Boilerplate

Introduction: Why WordPress Needs a Boilerplate

WordPress is famous because allows you to publish content quicklyBut when a site grows, has many plugins, development/staging/production environments, more people working on it and maybe an e-commerce site... this is where the limitations of the "classic" approach emerge: mixed files, updates made manually from the control panel, dependencies managed "by feel", difficulty reproducing the same site on another server.

Bedrock was born to solve exactly this: give WordPress a modern look, inspired by professional software practices, without changing WordPress itself. It is not a new CMS, it is not a fork, it is not a theme: it is a boiler plate, that is, a pre-built project template with a clear structure, sound settings, and current tools for managing dependencies, configurations, and releases.

What is Bedrock in simple words?

If we think of a WordPress site as a house, the “classic” version is a house where the kitchen is also a storage room and the cables run everywhere. It works, but it's chaotic. Bedrock gives you the same house, but with separate rooms, compliant systems and an easily accessible utility meter.

In practice Bedrock:

• Organize folders in a cleaner way (e.g. separate the public “document root” from the rest of the project).

• Deals with WordPress itself as a dependency (not as something to download and copy by hand).

• Manages plugins and themes via Composer, the most popular dependency tool in PHP.

• Defines environment configurations (development, staging, production) using environment variables and files .env.

• Adds some security settings basic and best practices (for example disabling the file editor from the backend).

Translated: your site is more orderly, repeatable and easier to maintain .

The story in brief: from Roots to community

Bedrock is born in the ecosystem Roots, a community that has been working for years to "modernize" WordPress without overturning it. Within this ecosystem you will also find Sage (a starter theme oriented towards modern development) and trellis (provisioning and deployment tools). Bedrock is the piece that fits together how to structure a project.

Over time, more and more developers have adopted Compose to manage plugins and WordPress core as versioned packages. With the arrival of repositories like wpackagist (which replicates the official directory plugins in Composer format), Bedrock has become the de facto standard for those who want to keep control of their WordPress project with professional tools.

Bedrock's goals

The main goals can be summed up in five words: order, repeatability, safety, collaboration, speed.

1. Order: a clear folder structure (e.g. a web/ public and the rest of the project kept safe).

2. Repeatability: with Composer you can rebuild the exact same site anywhere, without any local “magic.”

3. Safety: sensitive code is out of the public folder; the file editor in the backend is disabled; keys/salts are handled correctly.

4. Collaboration: in a team, we understand each other immediately because there's a convention; no more "where did you put that file?"

5. Working speed: Updates, rollbacks, and deployments become “push-button” procedures in pipelines.

The concrete advantages (explained without technicalities)

• WordPress as an addiction: Instead of downloading WordPress manually, Composer does it for you. Outcome: when you update, you update in a tracked and “repeatable” way across all environments.

• Professionally managed plugins and themes: you “declare” them in a file (like a shopping list) and then a command installs them. Outcome: a colleague, a staging machine or a production server will get the same versions.

• Separate environments: development, staging and production can have different configurations, but clear and controlled (for example different credentials or URLs). Outcome: fewer surprises when you post.

• Increased security: The server only exposes publicly what needs to be public. Outcome: Reduce the risk of exposing the wrong files or folders.

• Controlled updates: do an update, testi on staging, then releases in production with the exact same set of files. If something goes wrong, do rollback.

• More sensible backups: the sources (managed by Git) are separated from the dynamic contents (media and database). Outcome: you know what to save and how to restore.

• More order in migrations: Moving a site between servers is no longer “export, cross your fingers, import”. You have versioned dependencies and predictable configurations.

• No lock-in: It's still WordPress. Just more disciplined.

Who is it for (and who perhaps not)

• Agencies and teams: they often have multiple environments, multiple hands on the code, tight deadlines. Bedrock gives discipline and reduces tripping.

• E-commerce and business-critical sites: it serves control on updates and releases, and the ability to quickly rollback.

• Demanding freelancersIf you want to differentiate yourself by offering a more professional and robust WordPress, Bedrock is a great option.

• Who uses CI/CD or containers: Bedrock integrates well with deployment pipeline and containerized environments (Docker, etc.).

• Who wants to learn good practices: it is an excellent “model” from which to copy healthy habits.

For maybe it's not necessary: a very simple personal blog, rarely updated, managed "all from the control panel" and hosted on shared hosting without the need for staging. Bedrock is not complicated, but introduces concepts (Composer, environments, configurations) that make sense if the project deserves a minimum of process.

What a Bedrock project looks like (without looking at the code)

First of all: Bedrock is not changing WordPress, change how it is organized the project. At a glance, instead of a single folder with "a bit of everything", you find distinct areas Designed for security, order, and ease of deployment. Here's what it looks like, without going into the code:

Imagine these well-separated areas:

• A public folder (Usually web/): this is what the server "sees". Inside there will be the public part of WordPress (like wp/wp-admin, wp/wp-includes) and the folder app with themes and plugins that need to be accessible.

• A private part (the rest of the project): configuration files, libraries downloaded from Composer, deployment scripts, and anything that doesn't belong in the public folder.

• Configuration files for the environment: development, staging, production. The "secret" things (passwords, keys) are in environment variables or files. .env not publicly tracked.

• A Manifesto of Addictions (the famous composer.json): there you declare the version of WordPress, plugins and any necessary PHP libraries.

This organization saves you from the classic situation of "I updated a plugin on the fly in production and nobody knows what version it is." With Bedrock, everything is declared.

What difference does it make for safety and maintenance?

First the key concept: Bedrock reduces the attack surface and makes operations traceableIt doesn't add "magic" to security, but it applies good structural practices: it separates what is public from what is not, moves secrets out of the code, prevents impromptu changes in production and introduces a verifiable workflow (staging → testing → release → possible rollback). This translates into less exposure, less human error and more control.

On the maintenance front, Bedrock favors the principle of least privilege (display only what is necessary) and theauditability (Every change goes through Git and a clear pipeline.) Result: predictable updates, quick restores, and a healthier project lifecycle.

• Clean root document: just display the folder web/The rest of the project is invisible from the outside. This is a good practice that reduces risks.

• File editor disabled in backend: No one edits theme or plugin files directly from WordPress. Changes go through the appropriate workflow (Git, review, deployment).

• Keys and salts handled correctly: Bedrock encourages you to set them once and keep them safe, not leave them at default values or forget about them.

• Testable updates: First test on staging, then release. If necessary, go back. Less panic, more control.

How the way of working is changing (simple workflow)

First the basic idea: Bedrock doesn't change WordPress, it changes how you manage it.. Transforms often “artisanal” activities (update, migrate, release) into explicit, repeatable and verifiable stepsThe result is a clear flow that reduces unexpected events: the same versions across all environments, controlled releases, and panic-free rollbacks. This is what daily life with Bedrock looks like in practice.

• Declare dependencies (WordPress, plugin, theme) in the project file.
• Version your code with Git. So every change is tracked.
• On staging you recreate the site exactly the same as the development because Composer installs the same versions.
• Texts: If all goes well, deploy to production.
• A problem? Rollback to the previous version with one click (or a command), because each release is a precise state of the project.

For content (media and database), you use the usual tools: scheduled backups, DB export/import, and upload synchronization (or external storage). Bedrock doesn't change WordPress; it just streamlines code and dependency management.

Compatibility with hosting and tools

First of all, a frame: Bedrock does not require a specific provider, but some minimum requirements to work well — access SSH (or at least a build flow where you can run Compose), possibility to set a dedicated document root (Eg. web/), management of environment variables and a process of deploy predictable. If these conditions are met, Bedrock integrates seamlessly into the most common hosting scenarios and tools you already use every day.

• Shared Hosting: if your provider allows you to set the public folder to web/, you're already on the right track. Alternatively, the deployer can "copy" only what needs to be in the public root.
• Managed WordPress Hosting: Many allow custom web folders or provide guidance for alternative structures. Otherwise, pipelines are used to adapt the final package to the intended root.
• CI/CD: Bedrock is perfect for pipelines like GitHub Actions, GitLab CI, Bitbucket, etc. You run Composer, prepare the package, and release.
• Docker and the like: Bedrock lends itself to separate images/services (PHP, web server, database), simplifying team development.
• WP-CLI: No problem, it continues to work as usual and is often part of the deployment process.

Our WordPress Hosting di MANAGED SERVER SRL are perfectly compliant e support Bedrock: customizable document root (display of only the web/), SSH e Compose available in the build flow, WP-CLI operational, management of environment variables (.env), full integration with CI/CD pipeline and caching/optimization tools (Redis/OPcache/NGINX) where applicable. In practice, you can adopt Bedrock without compromise and with an infrastructure designed to support best practices.

“So is the site faster?”

Not directly. Bedrock is not a caching plugin or a query optimizer. It is a project basis that puts order: by itself it does not speed up WordPress, but makes it much easier apply and maintain all the optimizations that do the difference. The benefits come indirectly: clean structure, tracked dependencies, separate environments and a serious deployment process that allows you to experiment, measure, release and rollback without trauma. In practice, Bedrock create the conditions for a more efficient and stable website; speed is achieved through targeted technical choices.

How Bedrock indirectly helps performance:

• Locked versions and repeatability: Same cores, same plugins, same configurations across development, staging, and production. This eliminates the "side effects" of random updates that often degrade performance.

• Environment (.env) configurations: You can enable/disable caching, CDN, debugging, and logging based on context, avoiding unnecessary overhead in production and enabling accurate diagnostics in development.

• Separate document root (web/): Less exposed surface area and clearer structure to integrate reverse proxy and full page cache.

• MU-plugins and code discipline: Essential loading, shared logic, and more predictable initializations help reduce bloat and conflicts.

• Build and deploy pipeline: facilitates minification/concatenation of theme assets, preloading of critical resources, versioning of statics (cache-busting) and systematic testing of Core Web Vitals before release.

What it really takes to make it fast (with Bedrock as the “enabler”):

• Application Layer: choose lightweight themes and plugins, avoid functional duplications, use Object Cache (e.g. Redis) for transients and repetitive queries, program preloads smart, disable “virtual” cron in favor of one system cron real, monitor slow queries and refactor where necessary.

• Server layer: Modern PHP with OPcache well calibrated, PHP-FPM with pools and process managers suited to the load, Nginx or Apache optimized, Full Page Cache (Eg. Varnish or FastCGI cache), compressions Gzip/Brotli, HTTP/2 and HTTP/3 (QUIC), TLS efficient, CDN for static and media (with images in WebP/AVIF and correct expiration policies), strategies invalidation content consistent with the CMS.

• Database: neat outline and indexes, slow query log Active, MariaDB/MySQL parameters optimized for the workload, optional DB separation and object-side caching; no “old shortcuts” (like the deprecated query cache), but attention to execution plans and cardinality.

• Architecture and contents: Upload to external storage with CDN, sensible lazy-loading, reduction of non-essential JS, critical CSS, efficiently loaded fonts; all tested on staging with performance budgets and automatic alerts.

Bedrock is a well-maintained and organized WordPress. Performance, however, depends on the rigorous application of the best practice development and systems engineering: Object Cache (Redis), Full Page Cache (Varnish or equivalent), NGINX web server properly configured, OPcache, CDN, optimized database and constant attention to Core Web Vitals. Bedrock is not the miracle cure, it is the fertile ground on which to grow a really fast WordPress.

Limits and possible obstacles (to be known beforehand)

First, clarity: Bedrock is not a magic wand. It introduces order and process, and this requires new habits (for people and tools). It's better to know in advance where it can "pull", so plan mitigations (training, tooling, timing) and don't get discouraged in the first few weeks. Those below they are not blocks, but items to be budgeted for a smooth and gradual adoption.

• Learning curve: If no one on the team has ever used Composer, there will be a little initial effort. But it's an investment that pays off.
• Premium Plugins: Not everyone distributes "Composer-ready" packages. There are solutions (private repositories, tools that package plugins), but it's worth considering.
• Non-flexible hosting: If you can't set web/ as a public folder, you'll need a build process to place the files in the intended root. It's not impossible, but it requires organization.
• On-the-fly changes in production: With Bedrock, you don't do that—that's a good thing, but some might initially feel it's a limitation. That's a good thing: it reduces the risk of surprises.

Use case examples

Before going into detail, a premise: Bedrock gives its best when order, repeatability and safety have a real impact on project time, costs, and risks. The scenarios below aren't just "for developers": they're situations concrete Where you need to be able to recreate the same environment everywhere, update without surprises, and rollback quickly. If you recognize yourself in at least one of these contexts, a modern boilerplate like Bedrock will likely save you time and headaches—both today and in the future evolution of your site.

• Digital Agency: Multiple projects per year, mixed teams (dev, content, PM). Bedrock standardizes the way we work: new members quickly understand where to put their hands.
• E-commerce: Frequent security updates, mandatory staging testing, and the need for quick rollbacks. With Bedrock, updating WooCommerce or a payment gateway is a seamless process.
• Multilingual portal: Many plugins, external integrations, and scheduled deployments. Having a declared and versioned list of dependencies avoids divergences between environments and reduces the risk of "ghost" bugs.

Frequently Asked Questions (FAQ)

Are you evaluating Bedrock and have the usual down-to-earth questions buzzing around in your head? Great: here you'll find quick, jargon-free answers to the most common objections. The goal is to understand what really changes in everyday life (installations, updates, backups, tools) before even talking about code or pipelines.

• Is Bedrock another WordPress?
  No. It's still WordPress, but with a more streamlined project structure and modern tools.
• Can I use it on an existing site?
  Yes, you can migrate. It requires some method: you move the project to the Bedrock structure, declare the dependencies in Composer, and adjust the public folder and configurations. It's not a "click," but it's doable.
• Should I learn to program?
  No, but it's a good idea to familiarize yourself with Composer and the idea of "environments" (development/staging/production). There's no need to write complex code.
• Does it work with the themes and plugins I already use?
  In almost all cases, yes. The difference is how you manage them (with Composer and versioning) rather than what you use.
• What if a premium plugin isn't on Composer?
  You can use a private repository or tools that "package" the plugin so it can be integrated into your workflow. This is a common practice.
• What changes in backup?
  The code is in Git (easy to restore), the dynamic content (database and uploads) is backed up as usual. The separation makes everything clearer.
• Can I still use the WordPress dashboard?
  Of course. Bedrock isn't removing features from the backend. It simply discourages direct file changes from there.

Why “boilerplate” doesn't mean “rigid”

The word can be scary: it seems to "lock you" in a box. In reality, it's a boilerplate. it frees you from reinventing the obvious: folder structure, separation between public and private, configuration management. You focus on thing must make the site, not on including fit the pieces together every time. If you need something more, you can extend it: Bedrock is not a fence, it's a solid foundation.

How collaboration between people and departments helps

• Transparency: everyone sees the same dependencies, the same versions, the same configurations per environment.

• Rapid onboarding: a new colleague clones the project, runs Composer and he's leaving right away.

• Release Control: PM and dev speak the same language—“let's release version X” really means that core and plugin version.

• Recovery from errors: if something goes wrong in production, a rollback is a procedure, not a propitiatory rite.

What impact does it have on costs and time?

• Less time wasted to chase bugs born from “different environments”.

• Scheduleable updates: you do them on staging, then you replicate them in production without redoing the work.

• Predictable maintenance: knowing "what's inside" a site allows more realistic estimates and clearer service contracts.

Over the course of a medium to long term project, Bedrock tends to save money—not because it's magical, but because it reduces waste.

An honest comparison with the “classical” approach

• Traditional installation: you download WordPress, upload via FTP, add plugins from the dashboard, edit some files, update when necessary.
  Pro: immediate departure.
  Cons: difficult to maintain order, difficult to work in a team, risky to update “live”.

• Installation with Bedrock: WordPress, plugin and theme are declared; there are separate environments; the deployment is repeatable.
  Pro: order, security, collaboration, rollback.
  Cons: you need to adopt a minimum process (Composer, Git, pipeline).

If the site vale (revenue, reputation, traffic volume), the Bedrock approach is generally a net upgrade.

Conclusions: when to choose Bedrock

Choose Bedrock if you want your WordPress to:

• is repeatable on any server;

• has updates e rollback under control;

• separate code e content in a healthy way;

• supports multiple environments no surprises;

• grow with good practice from the beginning.

It's not a platform change, it's a change of mentality: from “it works on my laptop” to “it works because it is defined, tested and released methodically”.

Bedrock is WordPress on autopilot. Based on modern practices: it takes you further, with fewer bumps. If you manage sites that need to last, evolve, and remain secure, it's a foundation worth adopting today.

I our WordPress Hosting are perfectly compatible with Bedrock: customizable document root (display of only the web/), SSH, Compose e WP-CLI available, environment variables supported, pipeline integration GitHub Actions/GitLab CI/Bitbucket, Redis, and server configurations designed for maximum efficiency.

If you want to evaluate a gradual transition or a Based on a sample project, we can prepare a technical proposal and an operational plan. We'll get started whenever you like.