Rails Thruster: Vervang Nginx door de Ingebouwde HTTP/2-proxy van Rails 8 in Productie

Elk nieuw Rails 8-project dat ik in 2025 opzette, leidde tot hetzelfde gesprek met het infrastructuurteam van de klant: “Wacht, er is geen Nginx-configuratie? Waar is de reverse proxy?” Het antwoord is dat Rails 8 er standaard een meelevert.

Rails Thruster is een lichtgewicht HTTP/2-proxy geschreven in Go, die voor Puma staat, TLS-terminatie via ACME afhandelt, responses comprimeert en statische bestanden cachet — allemaal zonder een apart proces dat je zelf moet configureren, deployen of onderhouden. Het is geen vervanging voor elk Nginx-gebruik. Maar voor een standaard Rails 8-applicatie die met Kamal 2 op één server of een kleine cluster wordt gedeployed, elimineert Thruster een volledige infrastructuurlaag die de meeste teams alleen uit gewoonte in stand hielden.

Na negentien jaar Rails heb ik veel Nginx geconfigureerd. Die proxy_pass, gzip on, location /assets en keepalive_timeout-blokken die in elke Rails Nginx-config staan, zien er anders uit als je beseft dat ze problemen oplossen die Thruster al afhandelt.

Wat Rails Thruster Eigenlijk Doet

Thruster is een Go-binary die jouw Puma-proces omhult. Het start Puma als een subproces, bindt extern aan poort 80 en 443, en routeert requests door naar Puma op een interne poort. Als een response terugkomt, regelt Thruster het volgende:

• HTTP/2-ondersteuning — Thruster spreekt HTTP/2 met clients. Puma darachter gebruikt intern nog steeds HTTP/1.1. Je krijgt gemultiplexte verbindingen en headercompressie naar de browser zonder enige aanpassing aan je Rails-applicatie.
• TLS-terminatie via ACME — wijs Thruster een domein toe, en het haalt automatisch een Let’s Encrypt-certificaat op en vernieuwt dit. Geen Certbot, geen cronjob, geen handmatige verlenging.
• Responsecompressie — Brotli voor clients die dit ondersteunen, gzip als terugval. Comprimeert tekstresponses boven een instelbare minimale grootte voordat ze de server verlaten.
• Caching van statische bestanden — responses met Cache-Control: public worden opgeslagen in het in-process geheugen van Thruster en direct bij cache-hits geserveerd, zonder Puma te hoeven aanroepen. Je stylesheets en JavaScript-bundles worden bij herhaalde requests vanuit de proxy geserveerd.
• Beheer van X-Forwarded-For-headers — correcte injectie van het vertrouwde client-IP, zonder set_real_ip_from-configuratie in Nginx.

De totale geheugenvoetafdruk van het Thruster-proxyproces is doorgaans minder dan 30 MB. Voor de klasse applicaties die voorheen Nginx als Docker-sidecar of als apart systemd-service draaiden, is dit een zinvolle operationele vereenvoudiging.

De Standaard Rails 8-setup

Bij rails new met Rails 8 eindigt de gegenereerde Dockerfile met:

# Zet de HTTP-poort van Thruster open
EXPOSE 80

# Gebruik Thruster als HTTP-proxy voor Puma
CMD ["./bin/thrust", "bundle", "exec", "puma", "-C", "config/puma.rb"]

Het uitvoerbare bestand bin/thrust wordt geïnstalleerd door de thruster-gem. Voeg het toe aan je Gemfile als het er nog niet in staat:

# Gemfile
gem "thruster", require: false

Voer daarna de generator uit om de binstub aan te maken:

bundle install
bundle binstubs thruster

Dat is de volledige Rails-kant van de setup. Wanneer je container start, start Thruster op, bindt aan poort 80, start Puma als childproces op poort 3000 en routeert verkeer daartussen.

In development gebruik je Thruster niet — bin/dev start Puma nog steeds direct op localhost:3000. Thruster is uitsluitend een productiezorg.

Thruster Configureren via Omgevingsvariabelen

Thruster wordt volledig geconfigureerd via omgevingsvariabelen. De relevante voor een standaard productiedeployment:

# Poort waarop Thruster luistert voor HTTP (standaard: 80)
HTTP_PORT=80

# Poort waarop Thruster luistert voor HTTPS (standaard: 443)
HTTPS_PORT=443

# Interne poort waarop Puma luistert (standaard: 3000)
TARGET_PORT=3000

# Domein voor ACME/Let's Encrypt TLS-certificaatverkrijging
SSL_DOMAIN=mijnapp.example.com

# Maximale grootte van een gecachte response in bytes (standaard: 1MB)
MAX_CACHE_ITEM_SIZE=1048576

# Requesttimeout in seconden (standaard: 60)
REQUEST_TIMEOUT=60

Voor een Kamal 2-deployment stel je deze in in het env-blok van deploy.yml of in een .env-bestand dat Kamal leest bij deployment:

# config/deploy.yml
env:
  clear:
    HTTP_PORT: "80"
    HTTPS_PORT: "443"
    TARGET_PORT: "3000"
  secret:
    - SSL_DOMAIN
    - RAILS_MASTER_KEY

SSL_DOMAIN hoort bij secrets, omdat je anders je productiedomein via versiebeheersgeschiedenis lekt als je het in plaintext commit. RAILS_MASTER_KEY is vereist voor het ontsleutelen van Rails credentials tijdens de uitvoering.

TLS met ACME: Zero-config HTTPS

Stel SSL_DOMAIN in en Thruster regelt de rest. Bij de eerste opstart neemt het contact op met het ACME-endpoint van Let’s Encrypt, voltooit de HTTP-01-challenge op poort 80, haalt een certificaat op en accepteert daarna HTTPS-verkeer op poort 443. Bij volgende opstartopdrachten laadt het het gecachte certificaat en vernieuwt dit automatisch vóór vervaldatum.

Certificaten worden standaard opgeslagen binnen de container. Dat werkt als je container een persistent volume heeft of bij single-node-deployments waar container-herstarts zeldzaam zijn. Voor multi-node of ephemere containeromgevingen wil je persistente certificaatopslag:

# In je Docker Compose of Kubernetes volume-configuratie:
volumes:
  - thruster_certs:/rails/storage/thruster

# Of met Kamal 2:
volumes:
  - /data/mijnapp/thruster:/rails/storage/thruster

Het pad storage/thruster is waar Thruster standaard zijn certificaatcache schrijft. Koppel daar een hostdirectory aan en certificaten overleven container-rebuilds.

Eén kanttekening: ACME HTTP-01-challenges vereisen dat poort 80 op je server bereikbaar is vanaf het openbare internet, met het juiste DNS A-record dat naar het server-IP verwijst. Als je setup een load balancer heeft die TLS eerder beëindigt — AWS ALB, Cloudflare in proxy-modus, een Kamal Proxy ervoor — wil je TLS in Thruster uitschakelen en dit overlaten aan de upstream. Laat SSL_DOMAIN leeg en Thruster draait alleen HTTP, zonder ACME te proberen.

Thruster met Kamal 2: Twee Deploymentpatronen

Kamal 2 levert zijn eigen proxy — Kamal Proxy — die container-routing, zero-downtime-deploys en optioneel TLS afhandelt. Er zijn twee verstandige configuraties bij gebruik van Kamal 2:

Patroon 1: Kamal Proxy handelt TLS af, Thruster handelt HTTP/2 en compressie af

# config/deploy.yml
proxy:
  ssl: true
  host: mijnapp.example.com
  # Kamal Proxy haalt het certificaat op en beëindigt TLS
  # Het stuurt HTTP/1.1 door naar elke container op de interne poort

In dit patroon staat Kamal Proxy op poort 443 en regelt het Let’s Encrypt-certificaten, load balancing tussen containers en health-checked rolling deploys. Binnen elke container luistert Thruster op HTTP (poort 80, geen TLS) en geeft het nog steeds compressie, statische bestandscaching en HTTP/2 voor het traject browser → Kamal Proxy.

Stel hier geen SSL_DOMAIN in de containeromgeving — Thruster mag geen ACME-challenges proberen als een upstream proxy al TLS afhandelt.

Patroon 2: Thruster handelt TLS direct af (single server, geen Kamal Proxy)

# config/deploy.yml
proxy:
  ssl: false  # of laat het proxy-blok helemaal weg

Thruster luistert op poort 443, handelt ACME zelf af en er is geen Kamal Proxy. Dit werkt goed voor single-server-deployments — een VPS, een dedicated machine — waarbij zero-downtime-deploys worden afgehandeld door de Kamal-containerwissel in plaats van een proxylaag. Je stelt SSL_DOMAIN in in de containeromgeving en Thruster beheert de volledige HTTPS-stack.

Voor de overgrote meerderheid van mijn single-VPS-klantdeployments die voorheen draaiden op Nginx + Let’s Encrypt + Certbot is patroon 2 een directe vervanging met minder onderhoud. De twee bestanden die verdwijnen zijn nginx.conf en de systemd-timer van Certbot.

Compressie: Brotli en Gzip

Thruster comprimeert tekstresponses automatisch. De algoritmekeuze is gebaseerd op de Accept-Encoding-header: Brotli (br) als de client dit ondersteunt, anders gzip. Binaire responses — afbeeldingen, lettertypen, video — worden ongecomprimeerd doorgegeven, ongeacht het inhoudstype, omdat ze al gecomprimeerd zijn op formatniveau.

De compressiedrempel is standaard ingesteld op responses boven 1 KB. Responses kleiner dan dat kosten meer aan CPU-overhead dan ze besparen aan overdrachtstijd. Je kunt dit afstemmen als je applicatie veel kleine JSON-responses rondom de drempel serveert:

# Comprimeer alleen responses boven 4KB
MIN_COMPRESS_RESPONSE_SIZE=4096

Voor een typische Rails-applicatie die Turbo Drive-paginanavigaties (HTML-responses van 10–100 KB) en JSON API-responses serveert, reduceert Brotli-compressie de overdrachtsgrootte met 60–80% ten opzichte van ongecomprimeerd, en 15–25% ten opzichte van gzip. De compressie vindt plaats in het Go-proces, wat hierin sneller is dan Ruby, zonder Puma-threads te blokkeren.

Praktisch effect: voor een Rails-app met een gemiddelde responstijd van 400 ms voegt Thruster’s Brotli ongeveer 2–5 ms compressielatentie toe voor een HTML-response van 50 KB. De tijdsbesparing bij overdracht op een mobiele verbinding compenseert dit ruimschoots.

Caching van Statische Bestanden

Wanneer Puma een response teruggeeft met Cache-Control: public, max-age=..., slaat Thruster deze op in zijn in-process cache. Het volgende request voor dezelfde URL wordt vanuit geheugen geserveerd zonder Puma aan te raken. Dit is met name nuttig voor vingerafdruk-assets — je application-abc123.js-bestand heeft een oneindige max-age, dus na het eerste request bereikt het Puma nooit meer voor de levensduur van die container.

De standaard maximale cache-itemgrootte is 1 MB. Pas dit aan op basis van je grootste bestanden:

# Cache items tot 5MB (nuttig bij grote lettertypebundels)
MAX_CACHE_ITEM_SIZE=5242880

De cache wordt niet gedeeld tussen containers. Elke containerinstantie cachet onafhankelijk. Dat is geen probleem voor onveranderlijke vingerafdruk-assets — elke container cachet dezelfde inhoud — maar dynamische responses met Cache-Control: public hebben bij elke deploy een koude cache. Ontwerp je Cache-Control-headers dienovereenkomstig.

Voor de Propshaft asset pipeline dragen alle vingerafdruk-assets al Cache-Control: public, max-age=31536000. Thruster cachet ze bij de eerste hit. Gecombineerd met CloudFront ervoor betekent dit dat vingerafdruk-assets bij volgende hits vanuit het CDN worden geserveerd en de container nooit bereiken. De cache van Thruster is het meest relevant voor de eerste request die CDN mist na een cache-invalidatie.

Wat Thruster Niet Vervangt

Thruster is geen Nginx. Als je een van het volgende nodig hebt, wil je Nginx of een speciaal reverse proxy:

WebSocket-upgrades voor Action Cable. Thruster proxyet standaard HTTP/2-verbindingen. Als je Action Cable gebruikt met WebSockets direct (in plaats van via Solid Cable over SSE), verifieer dan dat jouw Thruster-versie de upgrade correct afhandelt. In de meeste gevallen werkt dit, maar test het expliciet vóór go-live.

Rate limiting. Thruster heeft geen rate limiting-primitieven. Voor requestrate limiting op proxyniveau heb je Nginx met limit_req_zone of een CDN-level WAF-regel nodig. Rails-level rate limiting met Rack::Attack handelt dit af op de applicatielaag, wat prima is voor de meeste applicaties maar pas vuurt nadat de request Puma bereikt heeft.

Complexe routing tussen meerdere backends. Als je infrastructuur /api/ naar één service en / naar een andere routeert, zijn Nginx’s location-blokken de juiste keuze. Thruster proxyet alles naar één Puma-proces.

IP-allowlisting en geo-blocking. Nginx kan requests afwijzen voordat ze je applicatie bereiken. Thruster geeft alles door aan Puma. Als je requestfiltering op proxyniveau nodig hebt, houd Nginx dan in de stack.

Bestanden van schijf serveren buiten Rails. Thruster cachet Puma-responses. Het serveert geen bestanden direct vanuit het bestandssysteem zoals nginx root /srv/mijnapp/public dat doet. Voor Kamal 2-deployments waarbij alle bestandsservices via Rails en Propshaft verlopen, is dit geen beperking. Als je grote binaire bestanden direct van schijf serveert, zal Nginx met sendfile on dit scenario nog steeds overtreffen.

Tuning voor Productie

De twee Thruster-instellingen die het meeste uitmaken in productie zijn de requesttimeout en de doelpoort.

# Thruster wacht dit aantal seconden op een response van Puma
# Standaard: 60 seconden — te lang voor de meeste request-SLO's
# Als achtergrondtaken in ActiveJob worden gezet, is 15s doorgaans royaal
REQUEST_TIMEOUT=15

# De poort waarop je Puma-proces luistert
# Moet overeenkomen met config/puma.rb of de PORT-omgevingsvariabele die Puma gebruikt
TARGET_PORT=3000

Als je langlopende requests hebt — PDF-generatie, grote CSV-exports, batchverwerking — verhoog dan de timeout, of beter: verplaats deze operaties naar achtergrondtaken met Solid Queue en serveer de export via een polling-patroon of Action Cable-notificatie. Een Puma-thread 60 seconden vasthouden voor een bestandsexport blokkeert alle andere gelijktijdige requests op die worker.

Voor Puma-tuning — workers, threads, geheugenlimieten — is dat een afzonderlijke zorg van Thruster. Ik behandelde dit in de Puma-tuninggids. Thruster en Puma zijn onafhankelijk afstgelbaar. De Thruster-timeout moet iets boven je p99 Puma-responstijd liggen. Als je p99 3 seconden is, geeft een Thruster-timeout van 10 seconden je een ruime buffer zonder verbindingen onbepaald open te houden voor echt vastgelopen requests.

Health Checks met Thruster

Rails 8 voegt een ingebouwd health check-endpoint toe op /up. Thruster geeft dit door aan Puma. Kamal 2 bevraagt dit tijdens deploys om te verifiëren dat de nieuwe container gezond is voordat verkeer wordt omgezet.

Als je Thruster gebruikt zonder Kamal 2 en health checks nodig hebt voor een externe monitor:

# config/routes.rb
# Rails 8 voegt dit automatisch toe, maar je kunt het aanpassen:
get "/up", to: lambda { |_env|
  [200, { "Content-Type" => "text/plain" }, ["OK"]]
}

Thruster voegt zelf geen health check-logica toe — het geeft /up door aan Puma. Als Puma niet draait, geeft Thruster een 502 terug. Je monitor behandelt een 502 als ongezond. Dit is het juiste gedrag: als Puma down is, is de container down.

Migreren van Nginx naar Thruster

De migratie is eenvoudig als je Nginx-configuratie standaard Rails-proxywerk doet. Een typische minimale Rails Nginx-configuratie:

upstream puma {
  server unix:///tmp/mijnapp.sock;
}

server {
  listen 443 ssl http2;
  server_name mijnapp.example.com;

  ssl_certificate     /etc/letsencrypt/live/mijnapp.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/mijnapp.example.com/privkey.pem;

  gzip on;
  gzip_types text/html application/javascript text/css application/json;

  location /assets {
    expires max;
    add_header Cache-Control public;
  }

  location / {
    proxy_pass http://puma;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 60;
  }
}

Elke instructie hier heeft een equivalent in Thruster:

• http2 → ingebouwd, altijd aan
• SSL-certificaat via Certbot → vervangen door SSL_DOMAIN ACME-automatisering
• gzip → ingebouwd, standaard Brotli
• Langdurige /assets-caching → afgehandeld door Propshaft-headers + Thruster-cache
• proxy_set_header X-Forwarded-For → ingebouwd
• proxy_read_timeout 60 → REQUEST_TIMEOUT=60

Wat je verliest: de doorstuur van proxy_set_header X-Forwarded-Proto moet worden geverifieerd. Rails leest config.force_ssl en X-Forwarded-Proto om te bepalen of HTTP naar HTTPS omgeleid moet worden. Met Thruster die TLS afhandelt, zijn requests die Puma bereiken intern HTTP. Stel dit in je Rails-config in:

# config/environments/production.rb
config.force_ssl = true

# Vertel Rails het X-Forwarded-Proto-header van Thruster te vertrouwen
config.action_dispatch.trusted_proxies = [
  "127.0.0.1",
  "::1",
  IPAddr.new("10.0.0.0/8"),
  IPAddr.new("172.16.0.0/12"),
  IPAddr.new("192.168.0.0/16")
]

Thruster stelt X-Forwarded-Proto: https in op requests die via HTTPS binnenkwamen. Rails leest dit en behandelt die requests als veilig, zodat request.ssl? true teruggeeft en url_for correcte https://-URL’s genereert.

Veelvoorkomende Problemen Oplossen

Container start, maar HTTPS geeft 502. De ACME-challenge is mislukt. Controleer of je DNS A-record verwijst naar het publieke IP van de server en poort 80 open staat in je firewall. De ACME HTTP-01-challenge gaat eerst naar poort 80, zelfs voor HTTPS-certificaatuitgifte. Controleer containerlogboeken op acme:-voorvoegde regels van Thruster.

Statische bestanden geven 304 terug wanneer ze 200 zouden moeten zijn. De bestandsvingerafdrukken komen overeen met een bestaand browsercache-item. Dit is correct gedrag — je browser heeft de vorige asset-URL gecached en stuurt If-None-Match. Thruster serveert de 304 zonder Puma te hoeven aanraken. Als de bestandsinhoud is veranderd maar de vingerafdruk niet (dit gebeurt als je Propshaft omzeilt met handmatig bewerkte bestanden), maak dan de browsercache leeg.

X-Forwarded-For toont het verkeerde IP. Je server staat achter een upstream proxy (Kamal Proxy, CloudFront, een load balancer) die al X-Forwarded-For instelt. Thruster voegt het verbindende IP toe, wat resulteert in een header met meerdere IP’s. Configureer je trusted_proxies in Rails om het IP-bereik van de upstream proxy te omvatten, en request.remote_ip zal het oorspronkelijke client-IP correct extraheren uit de meest linkse niet-vertrouwde invoer.

Thruster stopt onmiddellijk bij opstarten. De meest voorkomende oorzaak is een poortconflict — iets anders luistert op poort 80 of 443. Op een verse VPS is dit gewoonlijk een standaard Apache of Nginx-installatie. Schakel deze uit met systemctl stop nginx && systemctl disable nginx voordat je je Thruster-container start.

Grote bestandsuploads time-outen. De REQUEST_TIMEOUT van Thruster omvat uploadtijd. Een upload van 200 MB CSV via een trage verbinding kan gemakkelijk de standaard 60 seconden overschrijden. Verhoog ofwel de timeout voor upload-endpoints, of — beter — schakel over naar directe S3-uploads. Ik behandelde de setup in de Active Storage S3 direct upload post, die uploadtimeouts volledig elimineert door de server voor de upload zelf te omzeilen.

Is Thruster Geschikt voor Jouw Setup?

Na het draaien van Rails Thruster in productie op zes klantapplicaties sinds Rails 8 werd uitgebracht, is mijn vuistregel eenvoudig:

• Single VPS-deployment met Kamal 2 → Thruster met ACME. Verwijder Nginx, verwijder Certbot. Twee minder dingen om te onderhouden.
• Multi-server met Kamal Proxy → Thruster binnen elke container voor HTTP/2 en compressie, Kamal Proxy voor TLS en routing. Beide in de stack.
• AWS ALB of CloudFront ervoor → Thruster zonder SSL_DOMAIN (alleen HTTP). ALB handelt TLS af, CloudFront handelt caching af. Thruster geeft je nog steeds HTTP/2 tussen ALB en de container als je ALB-doelgroep HTTP/2 gebruikt.
• Complexe routeringsvereisten (meerdere backends, geo-fencing, IP-allowlisting) → Houd Nginx. Thruster heeft deze primitieven niet en probeert ze ook niet te hebben.

De productiviteitswinst is reëel voor het eenvoudige geval. De Nginx-config die ik verwijderde van de eerste klantdeployment in begin 2025 had vier jaar aan # TODO: begrijp waarom dit hier staat-commentaren verzameld. De Thruster-vervanging heeft tien omgevingsvariabelen en vereist geen commentaar.

Veelgestelde Vragen

Wat is Rails Thruster en waarom is het geïntroduceerd in Rails 8?

Rails Thruster is een lichtgewichte Go-based HTTP/2-proxy die als onderdeel van het Rails 8-ecosysteem wordt meegeleverd. Het omhult Puma, handelt TLS-certificaatverkrijging af via ACME (Let’s Encrypt), comprimeert responses met Brotli en gzip, en cachet statische bestanden in het geheugen. Rails 8 introduceerde het om de deploymentcomplexiteit te verminderen — voorheen vereiste een standaard Rails-productiedeployment Nginx of Apache als reverse proxy, Certbot voor TLS-certificaatbeheer, en afzonderlijke configuratie voor compressie en caching. Thruster consolideert dit alles in de bin/thrust-binstub die je Puma-commando omhult in de standaard Rails 8 Dockerfile.

Vervangt Rails Thruster Nginx volledig?

Voor een standaard single-applicatiedeployment vervangt Rails Thruster de reverse proxy, TLS-terminator, gzip-laag en statische bestandscache die Nginx leverde. Het vervangt niet Nginx’s rate limiting-instructies, multi-backend routing, IP-filtering of sendfile-gebaseerde directe bestandsservering. Als je Nginx-configuratie alleen proxy_pass, ssl_certificate en gzip on bevatte, is Thruster een complete vervanging. Als het limit_req_zone, meerdere location-blokken die naar verschillende backends routeren, of alias-instructies bevatte die bestanden direct van schijf serveert, houd Nginx dan.

Hoe gaat Rails Thruster om met TLS-certificaatverlenging?

Thruster gebruikt ACME (hetzelfde protocol als Certbot) om certificaten op te halen bij Let’s Encrypt. Het handelt de HTTP-01-challenge af op poort 80, slaat het certificaat lokaal op en vernieuwt het automatisch vóór vervaldatum — geen cronjob, geen certbot renew, geen certificaatvervaldatumwaarschuwingen. Certificaten worden opgeslagen in storage/thruster/ binnen de container. Koppel een hostvolume aan dat pad om certificaten te bewaren over container-rebuilds heen. Stel SSL_DOMAIN in op je productiedomein en Thruster doet de rest bij de eerste opstart.

Kan ik Rails Thruster gebruiken met Kamal 2?

Ja. Er zijn twee patronen. Als je Kamal Proxy gebruikt voor TLS-terminatie en load balancing (de standaard voor multi-server Kamal 2-setups), voer Thruster dan binnen elke container uit zonder SSL_DOMAIN — het zal HTTP-verkeer proxyen en compressie toevoegen zonder ACME te proberen. Als je op een enkele server bent zonder Kamal Proxy, stel SSL_DOMAIN dan in je containeromgeving in en Thruster handelt TLS direct af. In beide gevallen is de CMD in je Dockerfile ./bin/thrust bundle exec puma -C config/puma.rb — het verschil zit alleen in welke omgevingsvariabelen zijn ingesteld.

Na negentien jaar Nginx-configs onderhouden met commentaren die de engineers die ze schreven overleefd hebben, is Rails Thruster een echte verbetering voor de standaard single-applicatiedeployment. TTB Software helpt Rails-teams hun productie-infrastructuur te vereenvoudigen en met vertrouwen te deployen. Als je deployment-pipeline lagen van configuratie heeft die niemand meer volledig begrijpt, kunnen wij helpen.