OpenClaw op Kubernetes: een AI coding agent die je codebase echt kent

AI coding assistants zijn inmiddels overal. Maar de meeste tools zijn gebouwd voor gebruik in je editor of draaien volledig in de cloud van een ander. Ze helpen goed bij losse codevragen, maar zijn minder geschikt als je een platform beheert met vaste conventies, meerdere klanten en terugkerende onboardings- of wijzigingsflows.

Daar werd het voor mij interessant.

In plaats van AI alleen te gebruiken als hulpje tijdens het programmeren, ben ik gaan kijken hoe een coding agent onderdeel kan worden van mijn eigen platform. Niet als vervanging van development, maar als extra laag voor repeterend werk: boilerplates genereren, klantstructuren aanmaken, wijzigingen voorbereiden en PR's klaarzetten.

In dit artikel beschrijf ik hoe ik OpenClaw in Kubernetes heb ingezet, waar het in mijn setup wél waarde toevoegt, en waarom dat iets anders is dan alleen GitHub Copilot gebruiken in VS Code.

Wat is OpenClaw?

OpenClaw is een self-hosted AI coding agent. In plaats van alleen suggesties te geven in je editor, draait zo'n agent als een service binnen je eigen omgeving en werkt hij op basis van jouw repository, jouw conventies en jouw workflows.

Dat maakt het een ander type tool dan een traditionele coding assistant.

De kracht zit niet alleen in het genereren van code, maar vooral in het kunnen uitvoeren van taken binnen een afgebakende context. Denk aan:

• een nieuwe klantwebsite opzetten op basis van een bestaande structuur
• bestanden of configuratie aanpassen in een monorepo
• wijzigingen voorbereiden als pull request
• standaard platformlogica consequent toepassen

De agent gebruikt daarbij een taalmodel zoals Claude of GPT voor de redeneerlaag, maar de meerwaarde zit in de orkestratie eromheen: toegang tot repositorycontext, bestandssysteem, conventies en deploymentflow.

Waarom dit voor Webforged relevant is

Voor Webforged bouw ik websites en platformoplossingen voor klanten, met een vrij vaste technische basis. Nieuwe projecten lijken vaak niet functioneel identiek, maar hebben wél veel terugkerende onderdelen:

• een app-structuur
• Docker-configuratie
• deployment-configuratie
• namespace- of omgevingsspecifieke instellingen
• content- of componentaanpassingen op bestaande sites

Dat soort werk is niet moeilijk, maar wel tijdrovend en foutgevoelig als je het telkens handmatig doet.

Precies daar zie ik de waarde van een coding agent: niet als vervanging van engineering, maar als versneller van terugkerende platformtaken.

Mijn Kubernetes-setup

Mijn workloads draaien op Kubernetes, met nodes op Hetzner. Daaromheen gebruik ik tooling om deployments, routing en beheer werkbaar te houden. Cloudflare Tunnels gebruik ik om services en klantomgevingen veilig extern bereikbaar te maken zonder overal direct publieke endpoints voor open te zetten.

Belangrijk daarbij is om die onderdelen niet door elkaar te halen: Hetzner levert de compute, Kubernetes draait de workloads, en Cloudflare verzorgt in mijn architectuur de externe toegang voor geselecteerde services. Dat zijn losse bouwstenen binnen dezelfde setup, geen één-op-één geïntegreerd platform.

Per klant hanteer ik een afgescheiden structuur, vaak met een eigen namespace en eigen configuratie. Daardoor blijven websites en ondersteunende services logisch gescheiden en kun je resources, routing en beheer per klant beter organiseren.

Juist in zo'n opzet is standaardisatie veel waard. Hoe consistenter je platform is ingericht, hoe bruikbaarder een AI-agent wordt.

OpenClaw deployen in Kubernetes

OpenClaw draait in mijn cluster als een aparte service, los van de klantworkloads. Ik heb daar een eigen deploymentstructuur voor gebruikt via Helm, zodat de configuratie herhaalbaar blijft en goed past binnen de rest van mijn platformbeheer.

Dat is een belangrijk detail: het ging hier niet om 'even een AI-tool installeren', maar om het inbedden van zo'n agent in een bestaande Kubernetes-omgeving met eigen secrets, netwerktoegang en repositorykoppelingen.

De basis bestaat uit:

• een eigen namespace voor de agent
• secrets voor modeltoegang en Git-authenticatie
• een deployment/service voor de agent
• externe toegang via mijn bestaande routing-aanpak, bijvoorbeeld met Cloudflare Tunnel

Daardoor blijft de agent gewoon een beheerde workload in het cluster, net als andere interne services.

Niet hetzelfde als Copilot

Hier zit ook meteen het belangrijkste onderscheid met GitHub Copilot.

Copilot gebruik ik nog steeds dagelijks in VS Code. Voor code schrijven, refactors, uitleg en snelle suggesties is dat heel sterk. Maar Copilot blijft in de kern een editor-assistent: interactief, lokaal in je ontwikkelworkflow, en gericht op het ondersteunen van jou als developer.

Een tool als OpenClaw is interessanter voor een ander probleem: taken die minder gaan over 'help me code schrijven' en meer over 'voer deze wijziging uit binnen mijn platformstructuur'.

Dus niet:

• schrijf deze functie voor me

maar eerder:

• maak voor klant X een nieuwe basisapp op basis van onze standaardopzet
• pas de contactpagina aan en zet de wijziging klaar als PR
• maak de benodigde configuratiebestanden aan volgens onze conventies

Dat maakt OpenClaw niet automatisch beter dan Copilot. Het maakt het anders inzetbaar.

De echte fundering: context en conventies

Of je nou Copilot, Claude, OpenClaw of iets anders gebruikt: zonder goede context krijg je generieke output.

Voor mij zat een groot deel van de winst juist in het expliciet maken van de platformregels. Denk aan:

• hoe de repository is opgebouwd
• welke tooling de standaard is
• welke patronen verboden zijn
• hoe deployments en configuratiebestanden zijn georganiseerd
• welke naming conventions gelden

Daarom is een bestand als .github/copilot-instructions.md waardevol, maar dat principe gaat breder dan Copilot alleen. Elke agent wordt beter zodra je architectuur, standaarden en grenzen goed vastlegt.

De les was vrij simpel: AI werkt het best in een codebase die al discipline heeft.

Toepassing binnen Webforged

In de praktijk zie ik de grootste waarde in twee soorten taken.

1. Nieuwe klanten sneller onboarden

Waar je normaal handmatig directories aanmaakt, configuratie kopieert, deploymentwaarden invult en de basisstructuur neerzet, kan een agent daar een groot deel van voorbereiden.

Niet blind autonoom, maar wel snel en consistent.

2. Kleine klantwijzigingen sneller verwerken

Veel klantverzoeken zijn geen complete rebuilds, maar gerichte aanpassingen:

• tekst wijzigen
• sectie toevoegen
• afbeelding vervangen
• component net anders opbouwen

Dat soort wijzigingen lenen zich goed voor een flow waarbij de agent een voorstel doet, jij de diff controleert en daarna pas laat deployen.

Die human-in-the-loop stap is voor mij geen nadeel, maar juist de reden dat dit werkbaar blijft.

Wat ik ervan geleerd heb

De grootste les: AI wordt pas echt nuttig als je het koppelt aan structuur.

Niet omdat de modellen slecht zijn, maar omdat een agent alleen betrouwbaar kan werken als jouw platform voldoende duidelijkheid geeft. Hoe beter je conventies, hoe minder ruis. Hoe beter je repository is ingericht, hoe bruikbaarder de output.

De tweede les: autonomie is niet het doel.

Voor een productieplatform met echte klantprojecten wil ik geen agent die zelfstandig alles live zet. Wat ik wél wil, is een agent die voorbereidt, standaardiseert en versnelt — terwijl ik het goedkeuringsmoment houd.

En misschien de belangrijkste nuance: OpenClaw vervangt GitHub Copilot voor mij niet.

Copilot blijft top voor dagelijkse development in de editor. Een self-hosted agent wordt pas interessant zodra je AI niet alleen wilt laten meedenken, maar ook wilt laten meedraaien in je platformworkflow.

Daar zit voor mij de echte meerwaarde.