Klantwerk zelf hosten: waarom een studio de dock bezit

Het is een dinsdag in mei, het soort dinsdag waarop het kantoor stil is omdat twee van de drie collega's bij klanten op locatie zitten. De overgebleven persoon, jij dus, staart naar een factuur van een CI-leverancier die sinds januari stilletjes is verdrievoudigd. De regel heet 'compute minutes'. Het werk dat die minuten deze maand daadwerkelijk deden, was composer install en rsync draaien tegen elf verouderde WordPress- en Magento-sites die je hebt overgenomen van klanten die de originele code niet hebben geschreven en er ook niet aan willen.

Je rekent het uit op een Post-it. Elf sites, vier deploys per week op de drukke, twee op de rustige, zeg 110 deploys per maand. De rekening komt uit op ongeveer twee euro per deploy, voor een klus die 90 seconden CPU vraagt van de Mac mini onder het bureau. Die Mac mini staat aan. Hij staat al drie jaar aan. Hij heeft cycles over.

Dit is het moment waarop veel kleine studio's de oudere vraag stellen: welke schakels in onze keten moeten we echt huren, en welke kunnen we gewoon zelf bezitten? Klantwerk zelf hosten betekent niet teruggaan naar zips door FTP slepen. Het betekent dat je de dock, het stuk dat tussen jou en de legacy site zit, behandelt als infrastructuur die je controleert, niet als infrastructuur die je per minuut huurt.

De vier kamers in de dock van een studio

Voordat je beslist wat je zelf gaat hosten, helpt het om de kamers bij naam te noemen. Een werkende studio-keten heeft er vier, en meestal worden ze alle vier gehuurd:

• De source-kamer: waar de code woont. Meestal GitHub of GitLab.
• De review-kamer: waar een branch een klikbare URL voor een klant wordt. Vercel-previews, Netlify, een staging-slot bij WP-Engine.
• De deploy-kamer: het ding dat de bytes verstuurt. CircleCI, GitHub Actions, een zelfgebouwde runner.
• De secrets-kamer: waar SFTP-inloggegevens, databasewachtwoorden en API-sleutels wonen. 1Password, Bitwarden, een .env waar niemand het over heeft.

Elke kamer heeft een maandelijkse kost en een leveranciersrisico. Je kunt ze alle vier huren. Je kunt ze alle vier bezitten. De meeste studio's die al een tijdje meegaan, bezitten er uiteindelijk twee en huren er twee, en welke twee dat zijn is het interessante deel van het verhaal.

Huur de source. Bezit de deploy.

De goedkoopste kamer om te huren is de source-kamer. Het gratis abonnement van GitHub is prima voor een tent van drie man. Mirroring is één cron-job. Als GitHub een ochtend plat ligt, werk je door vanuit local clones en push je later. Geringe pijn.

De deploy-kamer is waar de som omslaat. CI-leveranciers rekenen per minuut, en een deploy van een legacy site bestaat vooral uit wachten: op composer, op rsync, op een database die een migratie afmaakt. Voor dat wachten betaal je. Een Mac mini, een kleine NUC of een VPS van 4 euro per maand doet hetzelfde werk en stopt met de meter laten lopen zodra het klaar is.

De meest ruwe opzet die je kunt bedenken is een shell-script en een webhook-listener. Hier is een schets van de deploy-helft, het soort bestand dat in /usr/local/bin/deploy-site.sh staat op de bak in eigen huis:

#!/usr/bin/env bash
set -euo pipefail

SITE="$1"
BRANCH="${2:-main}"
CONFIG="/etc/studio-deploys/${SITE}.env"

[[ -r "$CONFIG" ]] || { echo "no config for $SITE"; exit 2; }
source "$CONFIG"

WORK="/var/studio/builds/${SITE}"
mkdir -p "$WORK"
cd "$WORK"

if [[ ! -d .git ]]; then
  git clone --quiet "$REPO" .
fi

git fetch --quiet origin
git checkout --quiet "$BRANCH"
git reset --hard "origin/${BRANCH}"

composer install --no-dev --quiet --no-interaction

rsync -az --delete \
  --exclude='.git' --exclude='wp-content/uploads' \
  ./ "${SFTP_USER}@${SFTP_HOST}:${SFTP_PATH}/"

echo "deployed ${SITE}@${BRANCH} at $(date -Iseconds)"

Daar een webhook-receiver voor zetten, adnanh/webhook is 90 regels YAML, en je hebt de deploy-kamer vervangen voor de prijs van stroom. Het script is auditbaar. Als het om 23:00 uur stuk gaat, lees je het. Je opent geen support-ticket.

Secrets blijven thuis

De secrets-kamer is de kamer die studio's het vaakst verkeerd inrichten, omdat de verleiding bestaat hem te laten staan op dezelfde plek waar de deploys draaien. Doe het niet. Houd secrets in iets wat daarvoor gebouwd is, een zelfgehoste Bitwarden-server bijvoorbeeld, of zelfs een platte met age versleutelde file in een private repo, en laat de deploy-bak de credentials ophalen op het moment van deployen, in plaats van ze in rust op te slaan.

Een .env-bestand op een machine die ook webhooks accepteert is veruit de meest voorkomende manier waarop kleine studio's de SFTP-gegevens van een klant kwijtraken. De OWASP-richtlijnen voor secrets management zijn één keer per jaar het lezen waard, ook als je denkt dat je ze kent. De korte samenvatting: de credential komt aan op het moment dat hij gebruikt wordt, en vertrekt zodra het proces afsluit.

De review-kamer is de lastige

Previews zijn de plek waar de huren-versus-bezitten-som echt troebel wordt. Een Vercel-preview-URL op elke PR is een serieuze feature. Diezelfde feature nabouwen voor een legacy PHP-site betekent een server die op afroep een verse kopie van de site kan optrekken, met een verse database-snapshot erbij, en die alles weer afbreekt zodra de branch sluit.

Voor een Next.js-marketingsite: huren. De prijs is redelijk en het engineering-werk is niet aan jou. Voor een WordPress-site met 14 GB aan wp_postmeta en drie custom plugins uit 2014: bezitten. Geen enkel SaaS-preview-product gaat daar goed mee om, en de partijen die het proberen rekenen enterprise-tarieven. Een nachtelijke snapshot, een subdomein per branch en één regel wp search-replace volstaan:

wp search-replace 'https://client.example' \
  "https://${BRANCH}.preview.studio.internal" \
  --all-tables --skip-columns=guid

Dat levert klikbare previews op voor dezelfde maandelijkse kost als de Mac mini die al de deploys draait. De interessante vraag is steeds minder of je zelf host, en steeds vaker welk stuk je als eerste in eigen beheer neemt. Het stuk dat vrijwel altijd het bezitten waard is, is het stuk dat het dichtst tegen de productieserver van de klant aan zit, want daar moeten de bytes uiteindelijk landen.

De eerlijke kost van bezitten

Self-hosting is niet gratis. Het kost aandacht. Je deploy-bak in eigen huis heeft OS-updates nodig, schijfmonitoring, en een back-up van zijn eigen configuratie. De juiste manier om die kost te bekijken is in uren per maand, niet in euro's.

Een grove begroting voor een studio van drie man:

• 15 minuten per week aan routine: de deploy-log nakijken, security-updates uitrollen, de externe back-up roteren.
• 1 uur per kwartaal aan onderhoud: het deploy-script bijwerken, oude preview-omgevingen opruimen, langlevende credentials roteren.
• 4 uur per jaar aan rebuild-oefening: de volledige dock op een nieuwe machine vanuit documentatie opnieuw opzetten, om te bewijzen dat die documentatie nog steeds klopt.

Dat laatste is de discipline die de meeste studio's overslaan, en het is precies de stap die self-hosting veilig maakt. Als je de dock niet vanuit notities in één middag opnieuw kunt opbouwen, bezit je hem niet, dan huur je hem van jezelf, en slecht ook. De rebuild-oefening vangt ook de langzame drift op, die ene waarbij een teamlid achttien maanden geleden iets installeerde 'voor even'.

Waar de grens ligt in 2026

De grens die we hebben zien neerdalen, in ons eigen studio-werk en bij de kleine bureaus waar we mee praten, ziet er ongeveer zo uit. Source: huren. Issue tracking: huren. Deploys, secrets, review-omgevingen voor legacy stacks, en de database-tooling die daarbij hoort: bezitten. De redenering is steeds dezelfde. Alles wat per minuut of per omgeving wordt afgerekend, waar je gebruik in pieken komt en je werk vooral uit wachten bestaat, beloont bezitten. Alles wat per seat wordt afgerekend, waar de leverancier echte engineering doet die je anders zelf had moeten nabouwen, beloont huren.

Toen wij Pier bouwden liepen we steeds opnieuw tegen de database-helft van de review-kamer aan, het stuk waar je voor een klikbare preview een echte klant-snapshot moet kunnen optrekken met een MySQL-editor die je vertrouwt en een schone version history voor als de migratie misloopt. Wat we er uiteindelijk van gemaakt hebben, is allebei in dezelfde Mac-native app stoppen, zodat de dock op de machine van de studio blijft en niets van de database van de klant ooit langs een derde partij passeert.

Het kleinste wat je vandaag kunt doen: open de facturen van afgelopen maand van je CI-leverancier en je preview-omgeving, tel ze op, en deel de som door het aantal deploys dat je daadwerkelijk hebt uitgerold. Als dat getal boven de euro uitkomt, is de rest van deze post een tweede lezing waard.