PHP deployment strategieën bepalen hoe betrouwbaar, snel en veilig jouw code in productie terechtkomt. Of je nu een kleine WordPress-site beheert of een grote Laravel-applicatie met miljoenen requests per dag, de manier waarop je deployt heeft directe impact op uptime, bugs en de nachtrust van je team.
In deze gids kijken we naar het hele spectrum: van ouderwetse FTP-uploads tot moderne zero-downtime deploys met Docker en Kubernetes. Je leert welke strategie past bij welk project, en hoe je stap voor stap opschaalt naarmate je applicatie groeit.
Waarom deployment strategie ertoe doet
Een slechte deployment strategie is een sluipende kostenpost. Bezoekers zien halve pagina's, foutmeldingen of cached oude code. Ontwikkelaars durven op vrijdagmiddag geen release meer te doen. En als er iets misgaat, is rollback een handmatig drama.
Een goede strategie lost dit op met drie kernprincipes:
- Reproduceerbaarheid: elke deploy levert hetzelfde resultaat, ongeacht wie hem uitvoert
- Atomiciteit: een release is óf volledig live, óf helemaal niet
- Rollback-baarheid: terug naar de vorige versie binnen seconden
Deployment hangt nauw samen met je CI/CD pipeline. Waar CI/CD gaat over het testen en bouwen van je code, gaat deployment over het uitrollen van die gebouwde artefacten.
Strategie 1: FTP en SFTP uploads
De oudste en simpelste vorm van PHP deployment: een FTP-client openen en bestanden overzetten. Je ziet het nog veel bij kleine hostingpakketten en hobbyprojecten.
Wanneer gebruiken
FTP werkt alleen voor hele kleine projecten zonder dependencies of build-stap. Denk aan een statische PHP-landingpagina of een contactformulier. Zodra je Composer, assets-builds of omgevingsspecifieke configuratie hebt, loop je tegen problemen aan.
Waarom het problematisch is
Tijdens een upload is je site minutenlang in een inconsistente staat. Bezoekers kunnen nieuwe PHP-bestanden raken die oude classes aanroepen die nog niet geüpload zijn. Fatal errors zijn dan eerder regel dan uitzondering.
Daarnaast is er geen versiebeheer. Wat als je net 30 bestanden hebt geüpload en iets gaat stuk? Welke versie draaide er eerst? FTP geeft geen antwoord.
Strategie 2: Git-based deployments
Een grote stap vooruit is deployen vanuit je Git-repository. Je logt in op de server, doet git pull en draait eventueel composer install en database migraties.
cd /var/www/mijnsite
git pull origin main
composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan config:cache
Voordelen
Je hebt altijd een exacte kopie van een specifieke commit op productie. Rollback is simpel: git checkout <vorige-commit>. En omdat Composer dependencies gelockt zijn via composer.lock, weet je zeker dat je dezelfde package-versies krijgt.
Nadelen
Ook bij Git-pulls zit je even in een halve staat. Tussen git pull en composer install kunnen requests al nieuwe PHP-code raken die vendors nog niet kent. Voor kleine teams is dat acceptabel, voor productiekritische apps niet.
Strategie 3: rsync en SSH scripts
Rsync synchroniseert alleen de gewijzigde bestanden tussen twee locaties. Je bouwt je applicatie lokaal of in CI, en pusht het resultaat naar de server.
rsync -avz --delete \
--exclude='.env' \
--exclude='storage/logs' \
./build/ user@server:/var/www/mijnsite/
Dit is sneller dan FTP, ondersteunt SSH-encryptie, en je kunt het automatiseren in een shell-script of CI-pipeline. Voor veel MKB-projecten is dit het sweet spot tussen simpel en betrouwbaar.
Het nadeel: tijdens de sync zit je alsnog in een inconsistente staat. En je hebt geen ingebouwde release-historie.
Strategie 4: Deployer en Capistrano-achtige tools
Deployer is de PHP-variant van het Ruby-wereldje's Capistrano. Het introduceert een releases-map-structuur:
/var/www/mijnsite/
├── current -> releases/20260630120000
├── releases/
│ ├── 20260630100000/
│ ├── 20260630110000/
│ └── 20260630120000/
└── shared/
├── .env
└── storage/
Elke deploy maakt een nieuwe map in releases/. Pas als de build volledig klaar is, dependencies geïnstalleerd, caches gebouwd, migraties gedraaid, wordt de current symlink atomair omgezet naar de nieuwe release.
Zero-downtime door symlink switch
De kracht zit in die atomic symlink switch. Het OS wisselt de symlink in één syscall om. Je webserver pikt de nieuwe code op bij de volgende request, zonder dat er ooit een halve staat bestaat.
Rollback? Ook atomair: symlink terugzetten naar de vorige release. Geen herstel-drama's meer.
// deploy.php
namespace Deployer;
require 'recipe/laravel.php';
set('application', 'mijnsite');
set('repository', '[email protected]:team/mijnsite.git');
set('keep_releases', 5);
host('production')
->setHostname('server.example.com')
->set('deploy_path', '/var/www/mijnsite');
after('deploy:failed', 'deploy:unlock');
Voor de meeste Laravel- en Symfony-projecten is Deployer de gouden standaard. Het werkt goed samen met alle PHP 8.x features en moderne framework-workflows.
Strategie 5: Docker en container deployments
Met Docker deploy je geen code meer, maar complete images. Je Dockerfile beschrijft je runtime, dependencies en application code. Het resultaat is een onveranderlijk artefact dat identiek draait op elke omgeving.
FROM php:8.4-fpm-alpine
RUN docker-php-ext-install pdo_mysql opcache
WORKDIR /var/www/html
COPY composer.* ./
RUN composer install --no-dev --optimize-autoloader --no-scripts
COPY . .
RUN php artisan config:cache && php artisan route:cache
CMD ["php-fpm"]
Waarom containers winnen voor grotere teams
Config-drift tussen servers is onmogelijk, de image is de waarheid. Je kunt lokaal exact dezelfde image draaien als in productie. En rollback is een kwestie van een vorige image-tag deployen.
Docker combineert uitstekend met orchestrators zoals Kubernetes, ECS of Nomad. Die regelen rolling updates, health checks en automatic rollback voor je. Ideaal als je applicatie moet schalen naar high-performance niveau.
Valkuilen
Containers vragen meer DevOps-kennis. Je moet nadenken over persistent storage (uploads, sessies), logging naar stdout, en secrets management. Voor kleine teams kan dat overkill zijn.
Strategie 6: Blue-green en canary deployments
Voor mission-critical applicaties waar zelfs een seconde downtime onacceptabel is, bestaan er geavanceerdere patronen.
Blue-green deployment
Je draait twee identieke omgevingen: blue (live) en green (idle). Je deployt de nieuwe versie naar green, test grondig, en zet dan de loadbalancer om. Blue wordt het nieuwe idle, klaar voor de volgende release.
Gaat er iets mis? Loadbalancer terugzetten en je bent binnen seconden weer op de oude versie, mét alle data intact.
Canary deployment
Hier rol je de nieuwe versie geleidelijk uit. Eerst naar 5% van het verkeer, dan 25%, dan 100%. Monitor je error rates en latency tijdens elke stap. Bij problemen stop je direct en rol je terug zonder dat de meeste gebruikers iets gemerkt hebben.
Dit past goed bij een event-driven architectuur met queues, waar je workers gefaseerd kunt vervangen.
Database migraties: het stille risico
Deployment gaat niet alleen over code. Database-schema changes zijn vaak het meest riskante onderdeel. Een paar vuistregels:
- Migreer backwards-compatible: voeg eerst nieuwe kolommen toe, deploy dan code die ze gebruikt, en verwijder oude kolommen pas in een volgende release
- Maak migraties idempotent waar mogelijk, ze moeten veilig opnieuw uitgevoerd kunnen worden
- Run migrations voor de code-switch bij zero-downtime deploys
- Test migraties op een productie-kopie voordat je live gaat, zeker bij grote tabellen
De PDO-gids gaat dieper in op transacties, wat essentieel is om migraties atomair te houden.
Environment variabelen en secrets
Nooit, echt nooit, commit je productie-.env naar Git. Behandel secrets als een apart deployment-aspect:
- Kleine setups:
.envals shared file via Deployer'sshared_files - Container setups: environment variables via Docker secrets of Kubernetes Secrets
- Enterprise: HashiCorp Vault, AWS Secrets Manager of Azure Key Vault
Roteer secrets regelmatig en geef elk environment zijn eigen credentials. Dit sluit aan bij de principes uit validatie en security basics.
Rollback strategie: hopen is geen plan
Elke deployment strategie moet een bewezen rollback-pad hebben. Test het regelmatig, niet pas als productie plat ligt om 3 uur 's nachts.
Minimale eisen:
- Code rollback: binnen 1 minuut terug naar vorige versie
- Database rollback: down-migrations of point-in-time restore beschikbaar
- Cache invalidation: opcache, Redis en CDN worden geleegd na switch
- Queue consistentie: workers draaien geen jobs die afhankelijk zijn van verwijderde code
Welke strategie past bij jouw project?
| Scenario | Aanbevolen strategie |
|---|---|
| Hobbyproject, statische PHP | SFTP of Git pull |
| MKB-website, één server | rsync via CI of Deployer |
| Laravel/Symfony app, meerdere servers | Deployer met atomic symlinks |
| SaaS product, scaling team | Docker + orchestrator (K8s/ECS) |
| Mission-critical, zero tolerance | Blue-green of canary met automatic rollback |
Begin simpel en upgrade wanneer de pijn zich aandient. Premature optimalisatie van je deployment-pipeline is net zo zonde als premature optimalisatie van je code.
Veelgestelde vragen
Wat zijn PHP deployment strategieën?
PHP deployment strategieën zijn methodes om je PHP-code van je lokale machine of repository naar een productieomgeving te krijgen. Ze variëren van simpele FTP-uploads tot geavanceerde zero-downtime deploys met symlinks, containers of blue-green setups.
Waarom is FTP geen goede deployment strategie meer?
FTP is traag, onbetrouwbaar en mist versiebeheer. Tijdens een upload draait je site in een half-gedeployde staat, waardoor bezoekers fouten zien. Modernere tools zoals rsync, Deployer of Git-based deploys zijn sneller, veiliger en reproduceerbaar.
Wat is een zero-downtime deployment in PHP?
Bij een zero-downtime deployment blijft je applicatie beschikbaar tijdens het uitrollen van nieuwe code. Dit gebeurt meestal door een nieuwe release in een aparte map te plaatsen en daarna een symlink atomair om te zetten, zodat bezoekers geen downtime ervaren.
Is Docker een goede keuze voor PHP deployment?
Ja, Docker is uitstekend voor PHP deployment omdat je image immutable is en identiek draait in development, staging en productie. Je voorkomt zo config-drift en kunt eenvoudig rollbacken door een vorige image-tag te deployen.
Hoe kies ik de juiste deployment strategie voor mijn project?
Kies op basis van teamgrootte, complexiteit en uptime-eisen. Een kleine brochure-site kan toe met rsync of een simpele Git pull, terwijl grote webshops baat hebben bij containers, CI/CD pipelines en blue-green deploys met automatische rollback.