Wat deployment écht is voor een vibecoder
Deployment is niet hetzelfde als de "publish" knop in Lovable of de preview-link van Bolt. Die hosten je app op een gedeelde, beperkte omgeving die prima is voor demo's maar niet voor echte gebruikers. Je mist een eigen domein, je zit vast aan hun pricing, je hebt geen controle over de stack, en als je app ineens viraal gaat is er geen knop om op te schalen.
Echte deployment betekent vier dingen tegelijk regelen: een server (of containerised infrastructure) waar je app op draait, een eigen domein met SSL, omgevingsvariabelen voor je secrets, en monitoring zodat je het weet als er iets stuk gaat.
De vijf paden van AI-builder naar productie
Vibecoders kiezen meestal uit één van vijf paden. Geen ervan is automatisch goed of fout. Wat past hangt af van technische comfort, budget en hoe serieus de app is.
- Builder-native hosting. Je blijft in Lovable Cloud of Bolt's hosting. Snelste pad, geen technische kennis nodig, maar je betaalt premium voor weinig flexibiliteit en je zit vast aan hun stack.
- Vercel of Netlify. Free tier, één-klik koppeling met GitHub. Werkt prima voor frontend-only apps. Hits de muur bij persistent backend processes, queues, of zware database operaties.
- Railway, Render of Fly.io. Full-stack vriendelijker, runnen ook backend processes. Iets meer DevOps kennis nodig, maar nog steeds doable. Verborgen kosten kunnen oplopen bij egress traffic.
- Eigen VPS of cloud. Hetzij een Hetzner server of GKE/EKS. Maximale controle, laagste kosten op schaal, maar je tekent voor de hele DevOps stack: CI/CD, monitoring, backups, security patches.
- Managed deployment service. Iemand anders neemt de DevOps over. Bijvoorbeeld Ployed: een engineer reviewt elke deploy, je krijgt een canvas editor om door te bouwen, en je houdt je tijd voor de app zelf.
Welke past bij jou? Als je app maximaal vijf gebruikers heeft en je betaalt al voor Lovable Pro, blijf op builder-native. Heb je een echte launch met betalende klanten of investeerders die meekijken? Pad 4 of 5. Pad 2 en 3 zijn de tussenstap voor wie technisch wat aandurft.
Wat er stuk gaat als je het zelf doet
Drie dingen die structureel misgaan bij vibecoders die het deployment-pad zelf bewandelen, op basis van wat we bij Ployed binnen krijgen:
1. Secrets in de code
Lovable en Bolt zetten je API keys vaak in de frontend code. Dat is in development geen probleem, in productie wel. Iedereen die je site bezoekt kan je OpenAI, Stripe of Supabase keys uit de bundle plukken. De fix is environment variables, maar dat vraagt herwerk in elke file.
2. Geen Row Level Security
Apps die met Supabase of Firebase werken vergeten vaak RLS aan te zetten. Het gevolg: elke ingelogde gebruiker kan alle data van alle andere gebruikers lezen of muteren. Dit haalt de pers wel eens. Tools als Lovable proberen je te waarschuwen, maar in de praktijk klikken mensen door.
3. Geen rollback pad
Als de live deployment crasht, hoe ga je terug naar de versie die wel werkte? Vercel en Railway geven je dat. Builder-native hosting niet altijd. Een eigen Hetzner zonder CI/CD setup ook niet. Dit ontdek je pas als je het nodig hebt.
Wat je écht nodig hebt voor een productie launch
Een minimale productie checklist die geldt voor elk pad:
- Eigen domein met geldig SSL certificaat (geen
app.lovable.dev/jouw-naam) - Alle secrets in environment variables, niet in code
- Database met backups, automatisch, niet één keer per maand handmatig
- Error monitoring (Sentry of vergelijkbaar) zodat je het weet voor je gebruikers het melden
- Een rollback pad: terug naar de vorige werkende versie binnen vijf minuten
- Security check op de OWASP Top 10, of in elk geval iemand die er kritisch naar kijkt
- Privacy policy en cookies banner als je in de EU werkt (verplicht)
Als je hier op blijft hangen, lees onze stappenplan voor productie launch of kijk naar de beveiligingsrisicos van vibe-coded apps.
Human in the loop: waarom mensen er nog steeds bij moeten
De afgelopen twee jaar is vibe coding enorm volwassen geworden. Lovable, Bolt en Cursor produceren code die op het oog werkt. Maar "werkt op het oog" is niet hetzelfde als "ready voor productie". Een mens die de codebase doorleest vangt dingen die geen enkele AI vangt: subtiele auth gaten, foutieve aannames over de data, dependencies met bekende CVE's, code die alleen in development werkt door toeval.
Daarom werkt Ployed met human-in-the-loop deployment: je bouwt zoveel als je wil met AI, en als je live wil gaan reviewt een engineer de code en draait de deploy. Geen weekje wachten, geen agency facturen van duizenden euro's, gewoon een vangnet voor het moment dat het echt moet werken.
Wanneer je een managed service moet overwegen
Drie signalen dat je over self-serve hosting heen aan het groeien bent:
- Je verliest een dag per week aan deployment, infra issues, of debugging waarom iets in productie anders werkt dan lokaal.
- Je hebt betalende klanten en kan je een uur downtime niet veroorloven.
- Je wil features toevoegen maar bent bang om iets stuk te maken dat al draait.
Op dat punt heeft een managed deployment service zin. Lees verder over DevOps uitbesteden als startup of plan direct een gesprek.