--- title: "How We Run WordPress in 2026: Bedrock, GitLab, and CI/CD" date: 2026-05-18 author: "Tobias Rast" featured_image: "https://static.pegotec.net/uploads/2026/05/Modern-WordPress-Workflow-in-2026-Bedrock-GitLab-CI_CD.webp" categories: - name: "Pegotec News" url: "/category/news.md" --- # How We Run WordPress in 2026: Bedrock, GitLab, and CI/CD Most WordPress sites in 2026 are still deployed the way they were in 2012. Someone logs into the WP admin, clicks “Update plugins,” and crosses their fingers. Someone else SFTPs a file edit at 11 pm to fix a typo. Nobody can say, with certainty, what code is on production right now. That used to be acceptable. In 2026, with growing security pressure, more complex stacks, and clients who expect real audit trails, it has quietly become unacceptable. At Pegotec, we manage a fleet of WordPress sites across humanitarian, commercial, and SME clients — and we replaced the 2012-era workflow with something far closer to how the rest of our stack is operated. This article is the practical guide to that workflow, written for decision-makers who need to understand the shape of the change before approving it. ## What “Modern WordPress Workflow” Actually Means in 2026 A modern WordPress workflow rests on three pillars. Specifically, Bedrock gives the codebase a proper structure that Composer can manage. GitLab provides version control, code review, and audit trails. Meanwhile, CI/CD automates deploying code changes to a live site. Importantly, none of these changes what WordPress is. Editors still log in to the familiar admin, content still lives in MySQL, and the same plugins still run. What changes is the entire layer beneath — how code reaches the server, who approved it, and how it is rolled back when something breaks. Furthermore, none of this is theoretical. Indeed, every site we maintain runs this stack, and every monthly maintenance cycle relies on it. ## Pillar 1 — Bedrock: WordPress That Respects Modern Dependency Management Bedrock is a WordPress boilerplate maintained by Roots. It does one thing of strategic importance: it makes `composer.json` the single source of truth for the entire site. Every plugin, every theme, and the WordPress core itself become Composer-managed dependencies with pinned versions. As a result, a site is reproducible — you can spin up an identical copy locally, on staging, or on a new production server with one command. The “it worked on the old server” problem disappears entirely. Bedrock also reorganizes the file layout in a small but consequential way. Instead of putting WordPress core files at the project root, it nests them inside a web/ directory and renames wp-content/to app/. Consequently, only the web/ directory is exposed to the public, which immediately reduces the attack surface. Configuration moves `wp-config.php` to environment variables, which means database credentials and API keys never sit in the codebase. ![Side-by-side comparison of classic WordPress directory layout versus Bedrock structure with composer.json](https://static.pegotec.net/uploads/2026/05/bedrock-vs-classic-wordpress-directory-layout-1024x576.webp)For decision-makers, the upshot is simple. A typical Pegotec WordPress site has 22 to 40 Composer-managed dependencies, each pinned to a specific version, each upgradable through a controlled process. The manifest itself becomes the audit trail. When auditors ask which plugins are installed on a client site and at what versions, the answer is a single committed file, not a screenshot of the WP admin. ## Pillar 2 — GitLab: Code Reviews, Audit Trails, and the End of Cowboy Edits Once the codebase lives in Composer, the next question is where the canonical copy lives. For Pegotec’s WordPress fleet, the answer is GitLab. Every site has a private repository; every change goes through a merge request; every merge request requires at least one review; and every deploy ties back to a specific commit. As a consequence, “who changed this and why” stops being a mystery six months after the fact. We chose GitLab over GitHub for client work for three pragmatic reasons. First, the issue, merge request, and CI workflow are tightly integrated, reducing context switching for the engineering team. Second, the self-hosting option matters for clients with data-residency requirements — particularly NGO and public-sector clients in regions where storing source code outside the country is not an option. Third, the built-in CI runner means we do not need to wire up a separate pipeline service for every site. Furthermore, the cost framing matters here. Running a shared GitLab instance for a fleet of WordPress sites has approximately zero marginal cost per additional site. The real cost is process discipline — getting engineers, project managers, and occasionally clients accustomed to the idea that production changes go through a merge request, not through a screen-share session with the lead developer. That cultural cost is meaningful but pays back within months. In fact, we have not had a “what happened on the server last night?” outage on a Bedrock-and-GitLab site since the workflow stabilized. ## Pillar 3 — CI/CD: Staging, Lint, Deploy, Drift Detection The third pillar is what binds the first two together. A continuous integration and deployment pipeline takes a merge into the `main` branch and automatically moves it through a series of safety stages before it touches production. Specifically, our standard WordPress pipeline runs four stages. 1. **Composer install and lint.** The pipeline installs all pinned dependencies, runs PHP syntax checks, and validates the lockfile. If a developer accidentally commits a broken composer.json, the pipeline fails before any deploy starts. 2. **Staging deploy.** The pipeline syncs the build artifact to a staging environment that mirrors production. Smoke tests run automatically. The team can click around and verify the change manually if it is non-trivial. 3. **Manual approval gate.** For production deploys, we require a human to click “approve” in GitLab. This is deliberately a friction point — it forces someone to confirm the change is safe to ship, especially outside business hours. 4. **Production deploy.** An rsync-driven, atomic switch moves the build to production. The previous version remains on disk for instant rollback. Cache layers (Redis, Autoptimize) are flushed at the end of the run. Typical pipeline run time for a 22-plugin site is 90 to 180 seconds from merge to production. Crucially, this is not just about speed — it is about repeatability. The same pipeline runs whether it is a routine plugin update, an emergency security patch, or a major theme refactor. ![Monthly WordPress maintenance cycle visual showing composer-outdated pull, CVE cross-reference, MR review, and deploy stages ](https://static.pegotec.net/uploads/2026/05/wordpress-maintenance-monthly-cadence-1024x576.webp)Alongside the deploy pipeline, a scheduled drift-detection job runs nightly across the fleet. It compares the deployed code on each server against the latest commit on `main`. If anything differs — a hot-patched plugin, a manually edited file, an unauthorized theme upload through the WP admin — the job opens a P3 ticket on the affected site’s dashboard. Therefore, drift never lives undiscovered on a server for more than a day. ## What a Real Client Maintenance Month Looks Like Abstract pipelines are easy to describe and hard to feel. The clearest way to show the value of this workflow is to walk through what happens during a single maintenance month for a client site. At the start of the month, an engineer runs `composer outdated` against the site’s lockfile. The result is a list of every plugin and theme that has a newer version available. Each entry is then cross-referenced against the Patchstack CVE feed for WordPress plugins and against our internal record of past updates for that plugin. From there, every update gets one of three labels — auto-merge for low-risk patches with no breaking changes, hold-for-review for plugins that have caused regressions in the past, and skip for major-version bumps that need a scheduled migration. For each accepted update, a draft merge request is opened. The pipeline automatically deploys the change to staging, runs smoke tests, and reports back. A human reviewer then approves or rejects the MR. Approved MRs flow into the production pipeline. By the end of a typical month, a single site might receive five to fifteen plugin updates, all individually reviewed, deployed, and rolled back if needed. Compare that to the legacy alternative. In the old workflow, an engineer logs into the WP admin, clicks “update all,” and watches the page reload. If a plugin breaks the site, there is no per-plugin rollback — only a frantic restore from backup. Furthermore, nothing is recorded about what changed, no review occurs, and no smoke tests are run on staging. For decision-makers, this is the single chapter in which the value of the modern workflow becomes clear. Predictable, auditable, calm — and far cheaper to operate when something does go wrong. ## Migration: What It Takes to Move a Legacy WordPress Site to This Stack The question we hear most often from CTOs is how much it costs to move an existing WordPress site onto this workflow. The honest answer is that it depends on the site, but the process itself is well-defined and predictable. The migration runs in two phases. **Phase A** is an audit. We capture the live state of the site — the active plugins and their versions, the active theme, the WordPress core version, the PHP version, the database version, and any must-use plugins. The audit is entirely read-only. Nothing on the live site changes during this phase, which means clients can approve it with zero risk to ongoing operations. Phase B is the cutover. From the audit output, we generate a composer.json that pins every active plugin to its current version, scaffold a Bedrock repository, deploy it to staging, and validate that the staging site is behaviorally equivalent to production. Once the client signs off on the staging environment, we cut DNS over, and the new infrastructure takes over. The legacy server stays live for a configurable rollback window, typically 14 days. The typical engineering cost for a single-site WordPress installation is 8 to 16 hours. Multisite networks take longer because each subsite needs individual triage. The highest-risk component is always custom plugin code that is not available on Packagist or the official WordPress plugin repository. Those plugins need either a private Composer repository wrapper or a one-time install recipe. We have done this dozens of times now, so the path is straight even when the underlying code is messy. ## What We Learned — Three Operational Realities That Surprised Us Rolling this workflow out across an entire fleet of WordPress sites taught us a few things that we did not anticipate when we started. Lesson one — drift detection catches more than you expect. We initially built the drift checker as a quarterly compliance tool. In practice, it fires roughly once per month per fleet, almost always for well-meaning reasons. For instance, a developer hot-fixed a one-line PHP issue on the live server during an incident and forgot to backport it. In another case, a client uploaded a small CSS tweak through the admin theme editor. Sometimes, a managed hosting provider automatically applies a WordPress core patch without telling anyone. None of those are malicious. All of them would have caused mysterious behavior six months later when someone redeployed from `main` and quietly overwrote the live change. **Lesson two — Composer is the audit trail.** When a CVE drops for a popular plugin at a specific version, the standard agency response is to start grepping admin dashboards across client sites. With Composer, the response is a single command across the entire fleet, returning the affected sites in seconds. That speed difference becomes a competitive advantage during real security incidents, not just during quarterly audits. **Lesson three — CI/CD makes WordPress boring, which is the goal.** The first six months of running this workflow felt like overkill. Pipelines for minor copy edits? Code review for a plugin patch? After the sixth or seventh month, however, the absence of late-night incidents started to feel like a permanent property of the platform rather than a lucky streak. Boring is exactly what clients pay for, and the modern WordPress workflow is the cheapest way we know to make WordPress boring. ## When This Workflow Is Not Worth It The honest counterweight to all of this is that the modern WordPress workflow is not the right choice for every site. There are three cases where the overhead exceeds the benefit. First, hobby sites and one-page brochures with no real business risk attached. If the site is read-only marketing copy that nobody depends on, classic WordPress hosting is fine. Second, sites built heavily around page builders that store presentational state directly in the database. The code-first model fights you when the canonical source of layout is a serialized blob in, not a file—third, single-developer operations with no rotation. The audit trail and review process exist to support handover; if there will never be a handover, the discipline cost can outweigh the benefit. We say this openly because clients deserve a clear answer, not a sales pitch. ## The Pegotec Angle At Pegotec, the Bedrock-plus-GitLab-plus-CI/CD workflow is the default stance for any client site we maintain long-term. We maintain internal templates for both the Bedrock layout and a more conservative variant for sites that cannot adopt Bedrock immediately. Furthermore, we run drift detection, automated security update review, and monthly maintenance reports across the entire fleet. Clients see the same dashboard for every site, regardless of who originally built it. If you are wondering whether your existing WordPress estate is a candidate for this workflow, the audit phase is the cheapest way to find out. It is read-only, does not interfere with the live site, and produces a concrete answer about the migration effort and risk. [Contact Pegotec](https://pegotec.net/contact-us/) to scope an audit of your current WordPress setup. ## Conclusion WordPress in 2026 is still a fine platform. It runs roughly 43% of the web, the editor experience remains familiar to content teams, and the plugin ecosystem still solves real business problems. What has changed is the standard for operating WordPress. The rest of your engineering stack already runs on version control, code review, and continuous deployment. Bedrock, GitLab, and CI/CD bring WordPress up to that same operational standard without changing what it is. The transition is concrete, the cost is bounded, and the result is a WordPress estate that behaves like the rest of your software — predictable, auditable, and quietly reliable. ### Read next If this guide was useful, the following companion pieces go deeper into adjacent territory: - [Managing Technical Debt: A Practical Guide for CTOs](https://pegotec.net/managing-technical-debt-a-practical-guide-for-ctos/) — sister CTO-facing piece on operational debt and how to repay it. - [The First 90 Days After Launch: What Really Happens](https://pegotec.net/the-first-90-days-after-launch-what-really-happens/) — operational reality of maintenance after a launch, the chapter where this workflow earns its keep. - [The Evolution of DevSecOps](https://pegotec.net/the-evolution-of-devsecops-integrating-security-into-every-development-stage/) — security overlap: Bedrock plus an audit trail is, in practice, DevSecOps for WordPress. ## Frequently Asked Questions about the Modern WordPress Workflow **Will moving to Bedrock break my existing WordPress plugins?**No, plugins continue to work the same way. Bedrock changes where plugins live on disk and how they are installed, but the plugin code itself is unchanged. The only friction comes from plugins that are not distributed through Packagist or the WordPress.org plugin repository. Those need a one-time wrapper to make Composer aware of them, which is a routine part of the migration. **Do my content editors notice any difference after the cutover?**No, editors see the same WordPress admin they used before. Bedrock and CI/CD affect the deployment and dependency layer underneath WordPress. The editorial experience, the Gutenberg block editor, and the media library remain unchanged. The only visible change for editors is that direct theme-file edits through the WP admin are disabled, which is intentional. **How long does a typical Bedrock migration take?**For a single-site WordPress install with a standard set of 20 to 40 plugins, expect 8 to 16 hours of engineering effort across the audit and cutover phases. Multisite networks take longer because each subsite needs individual triage. Sites with significant custom plugin code that lives outside Packagist need additional time to wrap each plugin for Composer. **Why GitLab instead of GitHub?**Both work for this workflow. We chose GitLab for client work because the issue, merge request, and CI/CD features are tightly integrated, the self-hosting option matters for clients with data residency requirements, and the built-in CI runner avoids wiring up a separate pipeline service per site. Teams already standardized on GitHub can run the same workflow with GitHub Actions. **What does this cost compared to traditional WordPress hosting?**Hosting costs are typically similar or slightly higher because the stack expects a staging environment alongside production. The main cost shift is the one-time migration effort plus the recurring discipline of running every change through merge requests. In return, you avoid the costs of plugin-update outages, security incidents from unaudited live edits, and emergency restorations from backup.