Deployment Architecture

The Dry Dock Stack.

"Most WordPress installations are archaeological sites. This is the alternative."

Every WordPress installation, by default, accumulates. Core files update in place. Plugins overwrite themselves. A cache file from 2021 sits next to a theme you stopped using in 2023. A malicious script embedded in a compromised plugin last April is still there - surviving every security scan, every update, every migration.

The industry calls this maintenance. I call it drift. And drift, over time, becomes invisible risk.

Most managed hosts perform updates on a live, accumulating file system. They patch. They scan. They alert. But the foundation never changes. The vessel never gets a proper refit. It just keeps sailing - collecting barnacles.

The Standard Model

A compromised file in a traditional WordPress installation can survive for years. It survives updates because updates patch, not replace. It survives migrations because migrations copy, not rebuild. Security scanners miss it because it was designed to be missed.

Every Layer. Separated. Versioned. Fresh.

"The SmartBirb deployment model."

Instead of a single monolithic WordPress directory that accumulates over time, the stack is decomposed into discrete, independently-managed layers. Each one is a sealed artifact - built fresh, deployed clean, and replaced in full on every refit.

Server Root - Deployment Layout

/ (Server Root)
├── __wp__/          ← WordPress Core
├── wp-config.php    ← Environment Config
└── wp-content/
    ├── plugins/     ← Plugin Bundle
    ├── themes/      ← Theme Code
    └── uploads/     ← Media Files (persists)

__wp__/

WordPress Core

Repackaged directly from the official WordPress source on every deploy. No in-place updates. No accumulated core modifications. The exact version you are running is always known and verifiable.

wp-content/plugins/

Plugin Bundle

Assembled from a locked, audited manifest. Every plugin, at a pinned version, repackaged as a fresh bundle. Nothing carries over from the previous deploy unless it is explicitly in the manifest.

wp-content/themes/

Theme Code

Taken from source and deployed as a versioned artifact. Theme files are never edited directly on the server. All changes go through source control, then into the next refit.

wp-content/uploads/

Media Files

The one layer that persists. Your images, PDFs, and attachments are your content - not your code. PHP execution is disabled at the server level for this directory. It cannot be weaponised as an entry point the way code files can.

Every change is version-controlled.

Every component version bump - WP core, a plugin update, a theme change - is committed to a git repository before it ships. There is a complete, timestamped audit trail of what changed, when, and why. If something breaks, the answer is never "we don't know what changed." Rollbacks are precise: not just "restore a backup," but revert to any specific versions in under a minute (within seconds).

The Refit Cycle.

"What happens on every deploy."

1

Manifest Review

Plugin versions, theme version, and WP core version are reviewed and locked. No unvetted updates proceed.

2

Artifact Assembly

Each layer - core, plugins, themes - is repackaged independently from clean sources. No copying from the live environment.

3

Staging Validation

The new stack is deployed to staging and verified before anything touches the live environment.

4

The Refit

The live server is refitted. Every layer except uploads is replaced in full. No file from the previous deploy survives unless it is explicitly in the new artifact.

5

Rollback Snapshot Retained

The previous stack is preserved as a rollback point. A revert to the last known-good state takes seconds, not hours.

Refit Cadence

Standard refit: weekly.
Accelerated refit: within 24–48 hours when a critical security patch is issued for WordPress core, a plugin, or the server stack - regardless of where we are in the standard schedule.

The Sealed Deck.

"The architecture is only as strong as what touches it."

The refit cycle works because the deployment pipeline is the single authorised point of entry for all software changes. If the wp-admin interface is left open for manual installs or updates, that guarantee is broken. A well-meaning plugin install at 11pm - or a compromised admin account used to inject a backdoor - bypasses the entire architecture and places an unreviewed artifact directly into the live environment, outside the manifest, outside the refit window.

To protect the integrity of the stack, a custom mu-plugin is deployed on every managed site that enforces the following at the server level:

wp-admin Restrictions - All Users, Including Administrators

WordPress background auto-updates (plugins & themes)

Blocked

Manual "Update" button in Plugins / Themes list

Blocked

Add New Plugin (upload or wp.org search & install)

Blocked

Add New Theme

Blocked

WordPress Core updates

Unaffected

A Note on Cooperation

This is not about distrust. A surgeon insists on a sterile field - not because she doubts the team, but because the sterile field is what makes the surgery work. The Sealed Deck is the same principle applied to your WordPress environment.

If you need a new plugin, a theme change, or any extension installed: raise it with me. I evaluate it, add it to the manifest, and it ships in the next scheduled refit - or in an accelerated deploy if the urgency warrants it. Nothing enters the stack unreviewed.

This is a standing default across all engagements. Edge cases can be discussed during onboarding.

The Security Consequence

Maximum intrusion lifespan:
7 days.

In a traditional WordPress installation, a compromised file can persist for years. Updates do not remove it. Migrations carry it forward. Scanners that were not built to find it will not find it.

In the Dry Dock Stack, the math is different. Even if a plugin is compromised today - even if it goes undetected - the next refit replaces every file from a clean artifact. The intrusion has an expiry date baked into the architecture itself.

Prevention is not a scanner you run after something goes wrong. Prevention is a deployment model that makes "going wrong" a recoverable, time-limited event.

"The question is not whether an attack will be attempted. The question is how long it can last."

This architecture runs on the SmartBirb Cloud.

The Dry Dock Stack is the deployment model. The SmartBirb Cloud is the infrastructure it runs on - chosen after twenty years of testing every alternative, from shared hosting to DIY VPS to managed hosts.

Read the infrastructure story →

The Architecture Is Part of the Charter

Ready to move your site off the archaeological pile?

Request Your Charter