Bedrock a Modern WordPress Boilerplate

Introduction: Why WordPress Needs a Boilerplate

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

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

What is Bedrock in simple words?

If you think of a WordPress site as a house, the "classic" version is a house where the kitchen doubles as a storage room and cables run everywhere. It works, but it's chaotic. Bedrock gives you the same house, but with separate rooms , up-to-date systems, and an easily accessible utility meter.

In practice Bedrock:

• Organize folders more cleanly (e.g. separate the public “document root” from the rest of the project).

• Treat WordPress itself as a dependency (not something you download and copy by hand).

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

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

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

Translated: your site is more organized, repeatable, and easier to maintain over time.

The story in brief: from Roots to community

Bedrock was born within the Roots ecosystem , a community that has been working for years to modernize WordPress without disrupting it. This ecosystem also includes Sage (a starter theme geared toward modern development) and Trellis (provisioning and deployment tools). Bedrock is the building block for structuring a project.

Over time, more and more developers have adopted Composer to manage plugins and WordPress core as versioned packages. With the arrival of repositories like wpackagist (which replicates the official directory's plugins in Composer format), Bedrock has become the de facto standard for those who want to maintain 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. Security : Sensitive code is out of the public folder; the backend file editor is disabled; keys/salts are handled properly.

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

5. Speed ​​of work : Updates, rollbacks and deployments become “push-button” procedures in pipelines.

The concrete advantages (explained without technicalities)

• WordPress as a dependency : Instead of downloading WordPress manually, Composer does it for you. The result : when you update, you get a tracked and repeatable update across all environments.

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

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

• Increased security : The server only exposes what should be public. Result : You reduce the risk of exposing the wrong files or folders.

• Controlled updates : Perform an update, test on staging, then release to production with the exact same set of files. If anything goes wrong, roll back.

• More sensible backups : Source files (managed by Git) are separated from live content (media and database). The result : you know what to back up and how to restore it.

• More order in migrations : Moving a site between servers is no longer a matter of "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 code, and tight deadlines. Bedrock provides discipline and reduces bottlenecks.

• E-commerce and business-critical sites : you need control over updates and releases, and the ability to quickly rollback.

• Demanding freelancers : If you want to stand out by offering a more professional and robust WordPress, Bedrock is a great calling card.

• CI/CD or container users : Bedrock integrates well with deployment pipelines and containerized environments (Docker, etc.).

• For those who want to learn good practices : it is an excellent “model” from which to copy healthy habits.

For those who may not need it : a very simple personal blog, rarely updated, managed entirely from the dashboard, and hosted on shared hosting with no need for staging. Bedrock isn't complicated, but it introduces concepts (Composer, environments, configurations) that make sense if the project deserves a minimum amount of process.

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

First things first: Bedrock isn't changing WordPress , it's changing how the project is organized . At a glance, instead of a single folder with "a little bit of everything," you'll find distinct areas designed for security, organization, and ease of deployment. Here's what it looks like, without digging 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 “I updated a plugin on the fly in production and no one knows what version it is” situation. 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 traceable . It doesn't add "magic" to security, but it applies good structural practices: it separates the public from the private, 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, fewer human errors, and more control.

On the maintenance front, Bedrock favors the principle of least privilege (exposing only what's needed) and auditability ( every change goes through Git and a clear pipeline). The 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 the backend: No one edits theme or plugin files directly from WordPress. Changes go through the appropriate workflow (Git, review, deploy).

• Properly managed keys and salts: Bedrock encourages you to set them once and keep them safe, not leave them at default values ​​or forget about them.

• Testable updates: test on staging first, then release. If necessary, roll 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 the way you manage it . It transforms often "artisanal" tasks (update, migrate, release) into explicit, repeatable, and verifiable steps . The result is a clear flow that reduces unexpected events: 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 isn't a caching plugin or a query optimization. It's a project foundation that brings order to the site: it won't speed up WordPress on its own, but it makes it much easier to apply and maintain all the optimizations that make a difference. The benefits come indirectly: a clean structure, tracked dependencies, separate environments, and a robust deployment process that allows you to experiment, measure, release, and rollback without disruption. Essentially, Bedrock creates the conditions for a more performing and stable site; then, speed is achieved through targeted technical choices.

How Bedrock indirectly helps performance:

• Version lock 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.

• Per-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, cache-busting of static assets, 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 duplication, use Object Cache (e.g., Redis) for transients and repetitive queries, schedule intelligent preloads , disable “virtual” cron in favor of a real system cron , monitor slow queries, and refactor where necessary.

• Server layer: Modern PHP with well-tuned OPcache , PHP-FPM with load-appropriate pool and process manager, optimized NGINX or Apache, Full Page Cache (e.g. Varnish or FastCGI cache), Gzip/Brotli compression , HTTP/2 and HTTP/3 (QUIC) , efficient TLS , CDN for static and media (with WebP/AVIF images and correct expiration policies), content invalidation strategies consistent with the CMS.

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

• Architecture and content: uploaded 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 development and system best practices : Object Cache (Redis) , Full Page Cache (Varnish or equivalent) , a properly configured NGINX web server , OPcache , CDN , an optimized database, and constant attention to Core Web Vitals . Bedrock isn't a miracle cure, but it's the fertile ground on which to grow a truly fast WordPress.

Limits and possible obstacles (to be known beforehand)

First, let's be clear: Bedrock isn't a magic wand . It introduces order and process, and this requires new habits (for people and tools). It's best to know in advance where it might "pull" so you can plan mitigations (training, tooling, timing) and avoid discouragement in the first few weeks. The following are not roadblocks , but items to budget 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 delving into the details, a preliminary note: Bedrock is at its best when order, repeatability, and security truly impact the project's time, costs, and risks. The scenarios below aren't just "for developers": they're real-world situations 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 scenarios, a modern boilerplate like Bedrock will likely save you time and headaches—both today and as your site evolves.

• 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 same old, down-to-earth questions buzzing around your head? Great: here you'll find quick, jargon-free answers to the most common objections. The goal is to understand what actually changes in your day-to-day life (installations, updates, backups, tools) before even discussing 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, a boilerplate frees you from reinventing the obvious: folder structure, separation of public and private, configuration management. You focus on what the site needs to do, not on how to fit the pieces together every time. If you need something more, you can extend it : Bedrock isn't 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 gets started right away.

• Release control : PMs and devs speak the same language—“let’s release version X” really means that version of core and plugins.

• Error Recovery : 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 chasing bugs born from “different environments”.

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

• Predictable maintenance : Knowing “what’s inside” a site allows for more realistic estimates and clearer support 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 is worth it (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:

• be repeatable on any server;

• have updates and rollbacks under control;

• separate code and content in a healthy way;

• supports multiple environments without surprises;

• grow with good practices from the beginning.

It's not a change of platform, it's a change of mentality : from "it works on my laptop" to "it works because it's 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'd like to evaluate a gradual transition or a pilot on a sample project, we can prepare a technical proposal and an operational plan. We'll get started whenever you like.