Docker — geïsoleerde containers voor stabiele websites
Het hele 4buildsite-platform — de editor, de API, de rendering-engine en de dienst die de gepubliceerde websites uitlevert — draait in Docker-containers: geïsoleerde pakketten die alles bevatten wat de betreffende dienst nodig heeft. Je website wordt statisch gerenderd en uitgeleverd als een volledige versie die bij elke publicatie atomair wordt omgeschakeld. Het resultaat, in gewone taal: publicaties zijn geversioneerd, en als er iets niet klopt ga je in seconden terug naar de vorige versie.
Wat een container is — en waarom die telt voor jouw website
Een container is een gestandaardiseerd pakket dat de applicatie bevat plus alles wat die nodig heeft om te draaien: runtime, bibliotheken, configuratie. De container draait geïsoleerd van de rest van de server, maar gebruikt rechtstreeks de Linux-kernel van de host — zonder een eigen besturingssysteem per applicatie. Docker, uitgebracht in 2013, maakte van deze technologie een toegankelijke standaard; het image-formaat is inmiddels gestandaardiseerd als OCI (Open Container Initiative) en draait identiek op elke Linux-server en in elke cloud.
De klassieke vergelijking is de zeecontainer: wat hij ook vervoert, hij heeft altijd dezelfde genormeerde vorm en past op elk schip, elke trein en elke vrachtwagen. Net zo zitten de diensten van 4buildsite die je website bouwen en uitleveren — de editor, de FastAPI-API, de rendering-engine — verpakt in standaard-images die op de testserver precies zo draaien als in productie. Voor jou als website- of shopeigenaar betekent dat voorspelbaarheid: wat je in de preview zag, is precies wat je bezoekers krijgen.
- Container = de applicatie en haar afhankelijkheden, in één geïsoleerd pakket
- Standaardformaat OCI — hetzelfde image draait op elke server en in elke cloud
- Geen eigen besturingssysteem per dienst — starten in seconden, niet in minuten
- Op 4buildsite neemt het platform de containerisatie op zich — jij publiceert alleen
Isolatie: je website is niet afhankelijk van de buren
Op klassieke shared hosting delen honderden websites dezelfde server, dezelfde processen en vaak dezelfde PHP-installatie. Krijgt een buur een verkeersgolf of vreet een slecht geschreven script de hele processor op, dan wordt jouw website trager — het fenomeen van de „luidruchtige buur”. 4buildsite pakt dat probleem van twee kanten aan. Ten eerste: gepubliceerde websites worden statisch gerenderd — op de uitleverende servers draait geen code per website (PHP, plug-ins, scripts), dus er is geen slecht geschreven buurscript dat de processor belast. Ten tweede: de platformdiensten draaien elk in hun eigen container, met gescheiden processen en bestanden (via namespaces) en met de mogelijkheid van CPU- en geheugenlimieten (via cgroups, de mechanismen van de Linux-kernel).
Isolatie telt net zo goed voor de veiligheid. Op shared hosting kan één gecompromitteerde website de toegangspoort worden tot de buurwebsites op dezelfde server. Op 4buildsite is de gepubliceerde website een set statische bestanden — er draait geen code die via plug-ins of thema's gecompromitteerd kan worden — en de platformdiensten die gegevens verwerken (bestellingen, betalingen, editor) zitten in gescheiden containers: het bestandssysteem is geïsoleerd en een eventueel incident blijft binnen de betreffende container opgesloten.
- Gepubliceerde website = statische bestanden — nul code per website die gecompromitteerd kan worden
- Platformdiensten: gescheiden bestandssysteem en gescheiden processen per container
- Statische uitlevering: geen code per website die op piekmomenten de processor belast
Overal dezelfde versie: geen „bij mij werkt het, live niet”
De meest voorkomende foutbron op het klassieke web is het verschil tussen de omgeving waarin de website is getest en de server waarop hij live draait: een andere taalversie, een ontbrekende extensie, een afwijkende configuratie. Een Docker-image ruimt die hele foutklasse op: het image wordt één keer gebouwd, met alle afhankelijkheden vastgezet, en precies hetzelfde artefact draait in de test en in productie. Er is geen „met de hand op de server geconfigureerd”.
Voor jou vertaalt zich dat direct in stabiliteit. Wanneer je de website aanpast in de visuele editor op panel.4buildsite.net en op publiceren klikt, heeft de versie die bij de bezoekers aankomt elke keer dezelfde stappen en dezelfde gecontaineriseerde diensten doorlopen. Minder verrassingen na de publicatie.
Publiceren met atomaire omschakeling en rollback in seconden
Op 4buildsite betekent publiceren niet „website stilleggen, bestanden kopiëren, hopen”. Elke publicatie maakt een nieuwe, volledige versie van je website — statisch gerenderd, gescheiden van de nu actieve — en het omschakelen daarnaartoe gebeurt atomair: in één enkele handeling begint de uitleverdienst de nieuwe versie te serveren. Bezoekers zien altijd één volledige versie, ook midden in een bestelling in het winkelmandje. Hetzelfde principe geldt voor de platformdiensten: de nieuwe versie van een container start naast de oude en neemt het verkeer pas over na de health checks.
Even belangrijk is de weg terug. Elke gepubliceerde versie van de website blijft ongeschonden bewaard, dus teruggaan naar de vorige versie is simpelweg terugschakelen — een kwestie van seconden, geen urenlang herstel uit de back-up. Introduceert een publicatie een probleem, dan blijft je shop niet vastzitten op de foutieve versie. De enige eerlijke beperking: de gegevens (bestellingen, producten, content) leven in de database, gescheiden van de gepubliceerde versies — daarom worden ze beheerd op persistente volumes, los van de bestanden van de website.
- Elke publicatie = een nieuwe, volledige versie, atomair omgeschakeld
- Rollback = terugschakelen naar de vorige versie, in seconden
- Je publiceert wijzigingen wanneer je wilt, ook midden in het verkoopseizoen; elke eerdere versie blijft bewaard
Efficiëntie en kosten: meer prestaties voor hetzelfde geld
Een klassieke virtuele machine draait voor elke applicatie een compleet besturingssysteem — gigabytes werkgeheugen en minuten opstarttijd die alleen aan de „verpakking” opgaan. Containers delen de kernel van de host, waardoor er veel meer websites op dezelfde server passen, elk met hun eigen isolatie. Die dichtheid is de reden waarom 4buildsite hosting en SSL in het abonnement kan opnemen, zonder aparte infrastructuurkosten per website.
Voor je gepubliceerde website is opschalen bij verkeer nog eenvoudiger: omdat het om statische bestanden gaat, is het uitleveren ervan extreem goedkoop — een piek in bezoekers betekent meer uitgeleverde bestanden, niet extra processen die elkaar in de weg zitten. En de platformdiensten kunnen als containers die in seconden starten er indien nodig extra instanties bij krijgen. Je betaalt een voorspelbaar abonnement in plaats van een infrastructuur die permanent op de drukste dag van het jaar is berekend. Hoe we die containers werkelijk draaien — orkestratie, proxy, CI/CD, monitoring — lees je op de pagina Cloud & DevOps.
Voordelen en beperkingen
Voordelen
- De gepubliceerde website wordt statisch uitgeleverd en het platform draait in geïsoleerde containers — daardoor delen gepubliceerde websites geen processen met de buren.
- Dezelfde platform-images in de test en in productie — geen „bij mij werkt het, live niet”.
- Publiceren met atomaire omschakeling: de nieuwe versie van de website wordt apart aangemaakt en in één handeling omgeschakeld.
- Onmiddellijke rollback naar de eerder gepubliceerde versie, mocht een wijziging niet werken.
- Containers starten in seconden — de platformdiensten kunnen zo nodig extra instanties krijgen.
- Hoge dichtheid per server — hosting inbegrepen in het abonnement, zonder aparte kosten.
Beperkingen
- De isolatie gebruikt de gedeelde kernel van de host — zwakker dan de hardware-isolatie van een dedicated virtuele machine.
- De container is vluchtig: persistente gegevens (database, geüploade bestanden) vragen om apart beheerde volumes en back-ups.
- Images en hun layers nemen schijfruimte in — zonder regelmatig opruimen stapelen ze zich op.
- Voor teams die het zelf beheren heeft Docker een echte leercurve — op 4buildsite neemt het platform dat volledig over.
Kort oordeel
Containerisatie met Docker is de de-facto industriestandaard voor het draaien van webapplicaties: isolatie, overeenkomst tussen test en productie en onmiddellijke rollback. Op 4buildsite draait het platform dat je website bouwt en uitlevert gecontaineriseerd, en de publicaties van je website zijn geversioneerd, worden atomair omgeschakeld en zijn in seconden terug te draaien — hoe de infrastructuur wordt gedraaid (orkestratie, proxy, CI/CD) beschrijft de pagina Cloud & DevOps.
Specificatietabel
| Mogelijkheid | Grens / drempel | Typisch gebruik | |
|---|---|---|---|
| Resource-isolatie | CPU-/RAM-limieten per container (cgroups, namespaces) | Gedeelde kernel — geen hardware-isolatie zoals bij een VM | Websites en shops op gedeelde infrastructuur |
| Start / deployment | De container start in seconden | De eerste download van het image duurt langer | Frequente publicaties en updates, elk als volledige versie |
| Rollback | Terug naar elk eerder image in seconden | De gegevens in de database worden niet met het image teruggerold | Onmiddellijk terug wanneer een update niet werkt |
| Portabiliteit | OCI-image — draait op elke Linux-host en in elke cloud | Images zijn architectuurgebonden (x86/ARM) | Verhuizen tussen servers, zonder de applicatie te herschrijven |
| Dichtheid / kosten | Tientallen geïsoleerde containers op één enkele server | Ze delen allemaal de kernel en de schijf van de host | Lage kosten per website — hosting inbegrepen in het abonnement |
Docker, virtuele machines en shared hosting (cPanel) vergeleken
| Criterium | Docker (containers) | Virtuele machines | Shared hosting (cPanel) |
|---|---|---|---|
| Isolatie | Per container (processen, bestanden, resources) | Volledig (gevirtualiseerde hardware) | Zwak — honderden websites op dezelfde server |
| Start- en deploymentsnelheid | Seconden | Minuten (volledige start van het besturingssysteem) | Wijzigingen rechtstreeks op de live server (FTP) |
| Resourceverbruik | Minimaal — geen eigen besturingssysteem per applicatie | Hoog — een compleet besturingssysteem per machine | Laag, maar ongecontroleerd gedeeld met de buren |
| Rollback | Onmiddellijk — je start het vorige image opnieuw | Vanuit een snapshot — trager | Handmatig, vanuit de back-up |
| Veiligheid | Een incident blijft beperkt tot de container | De sterkste isolatie | Eén gecompromitteerde website kan de buren schaden |
| Kosten per website | Laag — hoge dichtheid op de server | Hoog — je betaalt de hele machine | Zeer laag, maar onvoorspelbare prestaties |
Veelgestelde vragen
Heeft Docker invloed op de snelheid van mijn website?
Nee. Containers draaien native op de Linux-kernel, zonder een laag hardwarevirtualisatie, dus de overhead is verwaarloosbaar. De snelheid van de website komt voort uit code, cache en netwerk — en de resource-isolatie maakt die zelfs voorspelbaarder dan op shared hosting.
Waarom geen klassieke hosting met cPanel, zoals bij WordPress?
Op klassieke shared hosting delen honderden websites dezelfde server zonder strikte grenzen: een overbelaste buur remt je af, een gecompromitteerde buur kan je meesleuren. Op 4buildsite wordt de gepubliceerde website statisch uitgeleverd — er draait geen code per website die gecompromitteerd kan worden — en de platformdiensten draaien geïsoleerd in containers, met publicaties via atomaire omschakeling. Dingen die cPanel niet biedt.
Wat gebeurt er als een publicatie mijn website beschadigt?
De eerder gepubliceerde versie bestaat nog ongeschonden, dus teruggaan duurt seconden: de uitleverdienst schakelt er eenvoudigweg naar terug. De shop blijft niet vastzitten op een foutieve versie en de gegevens in de database blijven onaangeroerd.
Moet ik Docker beheersen om 4buildsite te gebruiken?
Nee. De containerisatie neemt het platform volledig op zich: jij bouwt de website in de visuele editor op panel.4buildsite.net en publiceert. Docker werkt „onder de motorkap” — de voordelen (isolatie, rollback, atomaire omschakeling) krijg je zonder enige configuratie.
Is Docker veilig voor een webshop?
Ja. De isolatie van processen en bestanden beperkt het bereik van een eventueel incident tot de betreffende container in plaats van de hele server. Kaartgegevens lopen sowieso niet door de container — de betalingen worden door Stripe verwerkt op de gecertificeerde infrastructuur van Stripe.
Is Docker hetzelfde als een virtuele machine?
Nee. Een virtuele machine virtualiseert de complete hardware en draait een eigen besturingssysteem — die start in minuten en verbruikt veel. Een container deelt de kernel van de host: hij start in seconden, verbruikt een fractie van de resources en behoudt de isolatie van de applicatie.