Staging, blue/green en zero-downtime deploys WordPress

Een WordPress-site in productie updaten zonder downtime klinkt als luxe, maar is voor serieuze sites een harde eis. Bezoekers verwachten 24/7 beschikbaarheid, en elke seconde dat je site "even onderhoud" toont kost conversie, vertrouwen en SEO-waarde. In deze gids leer je hoe staging, blue/green en zero-downtime deploys voor WordPress werken, en hoe je ze praktisch inzet.

Of je nu een content-site, een WooCommerce-shop of een multisite beheert: de technieken die je hier leert zijn direct toepasbaar. We beginnen bij de basis (wat is staging?) en werken door naar geavanceerdere deploystrategieën.

Waarom deployment een vak apart is bij WordPress

WordPress is van origine niet ontworpen met moderne deployment in gedachten. Je wijzigt code, uploads én database op dezelfde server, en plugins activeren zichzelf soms met bijeffecten op de wp_options-tabel. Dat maakt een "gewone" git pull riskant.

Daarnaast zijn er runtime-afhankelijkheden die lastig te synchroniseren zijn. Denk aan OPcache, Redis-sleutels en caching-plugins die halverwege een deploy verouderde data teruggeven. Wil je hier meer achtergrond bij, lees dan ook wat er gebeurt tijdens een WordPress request.

Een goed deployproces lost drie problemen tegelijk op:

• Consistentie: staging en productie draaien identieke code en configuratie
• Reversibility: je kunt binnen seconden terugrollen
• Beschikbaarheid: bezoekers merken niets van de release

Wat is een staging-omgeving?

Een staging-omgeving is een kopie van je productieomgeving die niet publiek toegankelijk is. Daar test je plugin-updates, themewijzigingen en nieuwe features voordat ze live gaan. Staging is geen luxe, het is je verzekering tegen onverwachte fouten.

Kenmerken van een goede staging

Een staging-setup die écht waarde toevoegt, voldoet aan een paar eisen:

• Dezelfde PHP-, MySQL- en webserver-versies als productie
• Gelijke plugin- en themestack (identieke versies)
• Realistische dataset (liefst een recente database-kopie met gepseudonimiseerde klantgegevens)
• Afgeschermd via IP-whitelisting, basic auth of een aparte subdomein met noindex

Veel hosting-providers bieden een one-click staging aan. Handig voor eenvoudige sites, maar voor complexere setups met custom infrastructuur of multi-server setups wil je zelf de controle houden.

Staging-workflow in de praktijk

Een gezonde workflow ziet er ongeveer zo uit:

1. Ontwikkelen lokaal (bijvoorbeeld met LocalWP of Docker)
2. Pushen naar een develop-branch
3. Automatisch deployen naar staging
4. Handmatig én geautomatiseerd testen
5. Merge naar main → deploy naar productie

Vergeet niet om e-mail uit te schakelen op staging (of alle mail naar een mailcatcher te sturen). Niets pijnlijker dan per ongeluk 5.000 "welkom"-mails vanuit de stagingdatabase versturen.

Blue/green deployment uitgelegd

Bij blue/green deployment draai je twee identieke productieomgevingen naast elkaar. De "blue"-omgeving handelt het live verkeer af, terwijl je nieuwe code deployt naar "green". Zodra green klaar is en gevalideerd, schakel je het verkeer om via een load balancer of DNS.

Hoe dat er technisch uitziet

In een typische blue/green setup heb je:

• Twee (of meer) applicatieservers met identieke WordPress-installaties
• Een gedeelde database (of een gerepliceerde setup)
• Gedeelde uploads via NFS, S3 of een object store
• Een load balancer (bijvoorbeeld NGINX, HAProxy of een managed LB)

De load balancer wijst al het verkeer naar blue. Je deployt naar green, draait smoke tests, en update daarna de upstream-configuratie zodat green het verkeer krijgt. Blue blijft stand-by, zodat je binnen seconden kunt terugrollen als er iets misgaat.

Voordelen en valkuilen

De grote winst: geen downtime en directe rollback. Maar er zijn valkuilen:

• Database-wijzigingen gelden voor beide omgevingen tegelijk, migraties moeten backwards-compatible zijn
• Sessies en caches moeten gedeeld zijn (bijvoorbeeld via Redis object cache)
• Uploads mogen niet op lokale disk staan, gebruik een gedeelde storage

Voor WordPress is dit laatste vaak de grootste hobbel. Als je theme of plugins naar wp-content/uploads schrijven, moet die map op beide servers identiek zijn.

Zero-downtime deploys met atomic releases

Voor single-server setups is volledige blue/green overkill. Een elegantere oplossing is de atomic release-pattern, populair gemaakt door tools als Capistrano en Deployer.

Het principe:

1. Elke release krijgt een eigen map (bijvoorbeeld /var/www/releases/2026-04-29-143022)
2. De huidige live-versie is een symlink: /var/www/current → /var/www/releases/2026-04-22-101530
3. Bij een deploy bouw je de nieuwe release volledig op in een nieuwe map
4. Pas als alles klaar is, wissel je de symlink atomic om

Omdat het omschakelen van een symlink een atomic operation is, ziet PHP-FPM de wisseling instant. Geen half-geladen files, geen corrupte staat.

Gedeelde mappen

wp-content/uploads, wp-content/cache en bepaalde logs wil je niet per release opnieuw deployen. Die symlink je naar een gedeelde shared-map:

/var/www/
├── current -> releases/2026-04-29-143022
├── releases/
│   ├── 2026-04-22-101530/
│   └── 2026-04-29-143022/
│       └── wp-content/
│           └── uploads -> ../../../shared/uploads
└── shared/
    └── uploads/

Zo blijven uploads en andere persistente data intact tussen releases.

OPcache en PHP-FPM reload

Eén ding om op te letten: OPcache cachet bestandspaden, niet alleen inhoud. Na een symlink-swap moet je OPcache invalideren of PHP-FPM gracefully reloaden. Een systemctl reload php8.3-fpm doet dat zonder bestaande requests te breken.

Draai je met preloading? Dan moet ook het preload-script opnieuw ingelezen worden. Plan dit in je deployscript in.

Database-migraties zonder downtime

De database is de lastigste factor bij zero-downtime deploys. Code is eenvoudig te wisselen; een schema-wijziging niet. De gouden regel: maak migraties backwards-compatible.

Expand / contract pattern

Deze aanpak verdeelt een schema-wijziging in drie fases:

1. Expand: voeg nieuwe kolommen/tabellen toe, zonder oude te verwijderen
2. Migrate: deploy code die naar de nieuwe structuur schrijft en zowel oud als nieuw leest
3. Contract: verwijder oude kolommen pas nadat alle code de nieuwe structuur gebruikt

Dit voorkomt dat de oude code ineens een kolom niet meer vindt omdat je die in dezelfde deploy al hebt weggegooid.

WordPress-specifieke valkuilen

WordPress heeft een paar eigenaardigheden:

• Plugin-activatiehooks draaien bij activate_plugin(), bij een atomic deploy wil je die in een aparte stap draaien
• wp_options en autoloaded options kunnen groeien bij plugin-switches (zie autoloaded options: stille performance killer)
• Transients kun je beter legen na een deploy; dat voorkomt rare cache-situaties

Gebruik WP-CLI voor migraties en plugin-activaties. wp plugin activate, wp db query en wp cache flush zijn je vrienden in deployscripts.

Tools die het werk doen

Je hoeft dit niet zelf from scratch te bouwen. Enkele populaire keuzes:

• Deployer, PHP-based deployment tool met WordPress-recipe
• Bedrock van Roots, moderne WordPress boilerplate met Composer, .env-configuratie en een mapstructuur die zich leent voor atomic deploys
• GitHub Actions of GitLab CI, voor pipelines die testen, bouwen en deployen automatiseren
• Ansible of Terraform, voor infrastructure-as-code

Bedrock in combinatie met Deployer is een fijne setup: je beheert WordPress, plugins en themes via Composer, en je deployt met één commando.

Cache-invalidatie en warming

Na een deploy heb je te maken met meerdere cachelagen die je moet invalideren:

• OPcache (PHP bytecode)
• Object cache (Redis/Memcached)
• Full page cache (NGINX of plugin, zie full page caching: NGINX vs plugins)
• CDN (bijvoorbeeld Cloudflare)

Een typische post-deploy sequence:

wp cache flush
wp transient delete --all
systemctl reload php8.3-fpm
nginx -s reload
# Optioneel: CDN purge via API

Overweeg ook cache warming: laat een scriptje direct na de deploy de belangrijkste pagina's opvragen. Zo komen echte bezoekers niet als eerste op een koude cache terecht.

Monitoring tijdens en na de deploy

Een deploy is pas geslaagd als je het kunt meten. Zet minimaal het volgende op:

• Smoke tests direct na deploy (HTTP 200 op homepage, login, checkout)
• Error-rate monitoring (Sentry, Bugsnag of je APM)
• Response time tracking (bijvoorbeeld met New Relic of Datadog)
• Logs in de gaten houden, lees WordPress logs analyseren als een pro voor technieken

Bij een verdubbeling van de error rate of een plotselinge TTFB-stijging wil je automatisch kunnen rollbacken. Dat voorkomt lange incidenten buiten kantooruren.

Praktische deploystrategie: stap voor stap

Een werkbare workflow voor een middelgrote WordPress-site:

1. Developers werken in feature-branches, gemergd via PR's
2. CI bouwt en test elke push (linting, unit tests, Composer install)
3. Merge naar develop triggert een deploy naar staging
4. QA/review op staging, inclusief visuele regressietests
5. Merge naar main triggert een atomic deploy naar productie
6. Post-deploy hooks draaien migraties, cache flush en smoke tests
7. Monitoring checkt de eerste 10 minuten intensief

Voor kritieke wijzigingen (bijvoorbeeld een grote WooCommerce-migratie) kies je een blue/green-aanpak met canary: 5% van het verkeer krijgt de nieuwe versie, en als alles goed gaat rol je breder uit.

Veelgestelde vragen

Wat is een zero-downtime deploy?

Een zero-downtime deploy is een releaseproces waarbij je nieuwe code live zet zonder dat bezoekers downtime, foutmeldingen of onderbrekingen ervaren. De oude versie blijft beschikbaar tot de nieuwe versie volledig klaar is om verkeer af te handelen.

Wat is het verschil tussen staging en blue/green?

Staging is een aparte, niet-publieke omgeving waar je wijzigingen test vóór productie. Blue/green is een deploystrategie waarbij twee identieke productieomgevingen naast elkaar draaien en je het verkeer schakelt tussen de oude (blue) en de nieuwe (green) versie.

Kan ik zero-downtime deployen met WordPress?

Ja, maar het vraagt wel om planning. Je moet rekening houden met de database (die gedeeld wordt), uploads, plugin-activaties en wp_options. Tools zoals Deployer, Bedrock en atomic symlinks maken het haalbaar.

Wat doe ik met database-wijzigingen tijdens een deploy?

Database-migraties moeten backwards-compatible zijn: eerst deploy je code die zowel het oude als nieuwe schema ondersteunt, dan voer je de migratie uit, en pas daarna verwijder je oude code. Zo voorkom je fouten tijdens de overgangsperiode.

Heb ik staging nodig als ik een kleine site beheer?

Ja, zelfs voor kleine sites loont een staging-omgeving. Een plugin-update of themewijziging kan onverwachte fouten veroorzaken. Met staging test je zonder risico voor bezoekers en voorkom je downtime bij productie-releases.