Dev-, staging- en prod-omgevingen voorkomen dat testen echte gebruikers schaden. Leer hoe je databases, inloggegevens en integraties scheidt met eenvoudige regels en controles.
Als mensen het hebben over dev, staging en prod omgevingen, bedoelen ze één belofte: je kunt dingen veilig uitproberen zonder echte klanten, echte data of echt geld in gevaar te brengen.
Die belofte gaat kapot zodra dev en productie iets belangrijks delen, vooral de database of API-sleutels. Een “kleine test” wordt een echt incident omdat de app niet kan onderscheiden wat oefening is en wat echt is.
In eenvoudige woorden:
Scheiden zorgt dat je sneller kunt bewegen omdat je niet elke wijziging als een hoog-risico operatie hoeft te behandelen.
Een kort reëel falen ziet er zo uit: iemand test een nieuw checkout-flow, maar de app gebruikt productie Stripe-sleutels. De “test” maakt echte kosten, triggert echte bonnetjes, en support besteedt de middag aan terugbetalingen. Of iemand draait een data-cleanup script in dev, maar het is verbonden met de gedeelde productie-database, en klantgegevens verdwijnen. Nog een veelvoorkomend voorbeeld: een e-mailfunctie wordt getest met de live provider en stuurt “Welkom!” naar duizenden echte gebruikers.
De meeste fouten komen uit drie bronnen: gedeelde databases (testen wijzigen echte records), gedeelde referenties (testen bellen echte services), en gedeelde integraties (webhooks, e-mails, SMS en betalingen worden echt uitgevoerd).
Platformen zoals AppMaster maken snel bouwen makkelijk, maar veiligheid hangt nog steeds af van hoe je data, geheimen en integraties vanaf dag één scheidt.
De meeste teams doen het beste met drie omgevingen: dev, staging en prod. Dat houdt werk georganiseerd zonder dat de setup een bijproject wordt.
Behandel ze als drie aparte “werelden” voor dezelfde app. Elke wereld moet zijn eigen database, eigen inloggegevens en eigen integratie-instellingen hebben. Zo kan een test-signup, een buggy automatisering of een verkeerd geconfigureerde API-aanroep de productiegegevens niet aanraken.
Twee omgevingen kunnen acceptabel zijn voor hele vroege prototypes: “dev” en “prod”. Je wint snelheid en bespaart kosten, maar je verliest een veilige repetitieruimte. Als de app door iemand buiten je directe team wordt gebruikt, neemt het risico snel toe.
Je hebt mogelijk meer dan drie nodig wanneer mensen, naleving of integraties ernstiger worden. Veelvoorkomende aanvullingen zijn UAT (user acceptance testing), een dedicated sandbox voor integratietests, of een tijdelijke hotfix-omgeving voor urgente patches. Als je er meer toevoegt, houd namen saai en voorspelbaar: dev, staging, uat, prod. Vermijd “staging2”, “final-final” of teamspecifieke labels die niemand anders begrijpt.
Kosten en tijd nemen toe met elke extra omgeving, maar niet zo erg als de kosten van één productie-incident. Verwacht extra hosting, extra databases en wat setup-tijd voor geheimen en integraties. In een no-code platform zoals AppMaster is het voordeel dat je app-logica consistent blijft terwijl je omgevingsinstellingen wisselt.
Dit zijn de regels die voorkomen dat “snelle tests” in uitval resulteren en releases rustig houden, zelfs als ze vaak voorkomen.
Deel nooit een database tussen omgevingen. Dev en staging mogen niet naar productietabellen wijzen, zelfs niet “read-only”. Gebruik aparte database-instanties of, op z’n minst, aparte schema’s met strikte rechten.
Gebruik overal verschillende geheimen. Database-gebruikers, API-sleutels, webhook signing secrets, OAuth client secrets en encryptiesleutels moeten per omgeving uniek zijn. Als een dev-sleutel uitlekt in een screenshot of chat, mag alleen dev risico lopen.
Behandel integraties als twee systemen: test en live. Gebruik sandbox-accounts of test-modi. Als een provider die niet aanbiedt, bouw een veiligheidschakelaar (schakel uitgaande calls in dev uit, stuur naar een dummy-ontvanger, of zet calls achter een feature-flag). Dit is vooral belangrijk voor betalingen, messaging en automatiseringen.
Maak productie-wijzigingen strakker af. Productie moet minder mensen met edit-rechten hebben en sterkere goedkeuring. In een no-code tool kunnen “kleine” UI-wijzigingen nog steeds logica beïnvloeden, dus productie heeft extra zorg nodig.
Promoveer slechts in één richting. Wijzigingen moeten van dev -> staging -> prod bewegen. Vermijd direct hot-fixen in prod, want het is makkelijk om te vergeten de fix terug te zetten en de volgende deployment overschrijft het.
Voorbeeld: je bouwt een supportportal in AppMaster. In dev verbind je met een dev PostgreSQL-database en een test Stripe-account. In staging gebruik je een verse kopie van het schema en staging-only API-sleutels, en draai je een volledige realistische test. Pas nadat staging slaagt deploy je naar prod met productie-sleutels en de productiedatabase.
Als dev, staging en prod dezelfde database delen, heb je eigenlijk geen gescheiden omgevingen. Een onschuldige test kan echte data overschrijven, e-mails triggeren of reporting breken. Behandel database en bestandsopslag als omgevingsgebonden resources, niet als gedeelde tools.
Er zijn een paar nette manieren om data te scheiden. De beste keuze is degene die je team elke keer écht zal volgen:
app_dev, app_staging, app_prod op dezelfde PostgreSQL-host.dev, staging, prod schema’s. Dit is het makkelijkst door elkaar te halen, dus voeg safeguards toe.Wat je ook kiest, maak het duidelijk in namen en connectie-instellingen. Maak de productiedatabase-naam en host moeilijk te verwarren met staging.
Staging moet zich als productie gedragen, maar zonder echte persoonlijke data. Veelgebruikte benaderingen zijn een kleine seed-dataset die je beheerst, een geanonimiseerde snapshot van productie, of synthetische data die dezelfde vormen en randgevallen heeft.
Voor een supportportal zijn synthetische tickets zoals “Terugbetalingsverzoek” en “Loginprobleem” genoeg om zoeken, filteren en rollen te testen zonder klantberichten te tonen.
Schema-wijzigingen veroorzaken veel incidenten. Een veilig patroon is:
In AppMaster worden Data Designer-wijzigingen uiteindelijk database-wijzigingen in PostgreSQL, dus behandel elke publicatie als een migratie.
Voorkom per ongeluk schrijven naar prod vanuit non-prod: gebruik aparte credentials per omgeving, beperk netwerktoegang zodat dev-machines prod niet kunnen bereiken, en gebruik read-only accounts voor analytics.
Vergeet bestanden en attachments niet. Houd aparte buckets of duidelijk gescheiden mappen per omgeving, want test-uploads kunnen net zo makkelijk in echte gebruikersrecords lekken als databaseregels.
Geheimen zijn alles wat je pijn doet als iemand het kopieert. In dev, staging en prod zijn de gebruikelijke verdachten database-wachtwoorden, OAuth client secrets, Stripe-sleutels, e-mail- of SMS-provider sleutels en Telegram-bot tokens.
Behandel geheimen als elektriciteit: beschikbaar waar nodig, nooit blootgesteld. Dat betekent geen hard-coderen in je no-code project, niet plakken in tickets en geen “tijdelijke” deling in chat.
Een praktische regel is: één omgeving, één set geheimen. Gebruik environment variables (of de secret store van je platform) en een duidelijke naamgevingspatroon.
In AppMaster bewaar je deze waarden in omgevingsspecifieke instellingen voor elk deployment-target. Je app-logica moet alleen naar de variabelenaam verwijzen, nooit de werkelijke waarde.
Toegang is net zo belangrijk als opslag. Beperk wie geheimen kan bekijken of bewerken tot de kleinst mogelijke groep en houd een lichte wijzigingslog bij (wie heeft wat veranderd, wanneer en waarom). Zelfs een simpel notitieveld in je release-checklist is beter dan op geheugen vertrouwen.
Rotatie hoeft niet eng te zijn, maar moet normaal zijn. Roteer sleutels als een teamlid vertrekt, als een waarde te breed gedeeld is, na verdachte activiteit en regelmatig voor productie.
Test na rotatie de flows die van dat geheim afhangen: aanmelding (OAuth of wachtwoordstroom), betalingen (test-modus flow), e-mail/SMS-bezorging (naar een testadres/-nummer) en achtergrondjobs of webhooks die derde partij API’s aanroepen.
Voorkom per ongeluk lekken. Zet geen geheimen in screenshots, docs of “snelle voorbeelden”. Als je een config moet laten zien, gebruik placeholders (zoals PROD_STRIPE_SECRET_KEY=xxxx).
Integraties zijn waar dev, staging en prod meestal breken, omdat één verkeerde sleutel echte kosten, echte e-mails of echte dataveranderingen kan triggeren. In non-prod moet je app zich als productie gedragen, maar met vangrails die schade onmogelijk maken.
Voor betalingen: één duidelijke regel — alleen productie mag live-modus gebruiken. In dev en staging gebruik je test-modus en aparte testproducten, prijzen en webhooks. Zo kun je de volledige checkout-flow draaien zonder echt geld te riskeren.
Voor e-mail en SMS: ga ervan uit dat elke non-prod boodschap een vergissing is tenzij je het hebt bewezen. Route uitgaande berichten naar een veilige bestemming (zoals een interne inbox of een gecontroleerd telefoonnummer), of zet verzenden standaard uit en schakel het alleen in voor specifieke testers. Als je AppMaster-modules voor e-mail/SMS of Telegram gebruikt, geldt dezelfde regel: non-prod mag nooit echte klanten bereiken.
Webhooks hebben hun eigen scheiding nodig. Maak aparte endpoints per omgeving en verifieer handtekeningen overal, niet alleen in productie. Dit voorkomt dat staging-verkeer productiehandlers raakt en helpt spoofingproblemen vroeger te vinden.
Als een derde partij API een sandbox biedt, gebruik die. Als dat niet zo is, voeg strikte rate limits en read-only permissies toe waar mogelijk, en maak non-prod calls makkelijk te herkennen (bijvoorbeeld via een duidelijke header of tag).
Een veiligheids-checklist die de meeste incidenten opvangt:
Voorbeeld: je staging supportportal kan nep-betalingen aanmaken en notificaties sturen, maar elk bericht gaat naar het team-inbox en nachtelijke jobs draaien alleen op staging-data.
Toegangscontrole is het vangnet voor dev, staging en prod. Veel incidenten in no-code apps gebeuren wanneer iemand iets in prod wijzigt met goede bedoelingen.
Begin met een paar rollen en houd ze duidelijk. Zelfs een klein team heeft baat bij simpele permissies: iemand die kan bekijken, iemand die kan testen, mensen die in dev/staging kunnen bewerken, en een kleine groep die kan deployen of omgevingen en geheimen beheren.
Houd productie-toegang kleiner dan je denkt. Als iemand niet wekelijks prod nodig heeft, geef geen permanente toegang. Als iemand het nodig heeft (bijvoorbeeld om een live-issue te onderzoeken), geef tijdelijk verhoogde toegang en verwijder die daarna.
Voeg één lichte goedkeuringsstap toe voordat iets productie raakt, vooral releases en database-wijzigingen. In de praktijk kan dat zijn: één persoon bereidt de release voor, een tweede persoon keurt goed. Als je AppMaster gebruikt, behandel “publish to prod” en “apply schema changes” als acties die expliciete permissie vereisen, niet alleen “iedereen die kan bewerken”.
Houd een basis-audit-trail zodat je snel drie vragen kunt beantwoorden: wie heeft wat veranderd, wanneer en in welke omgeving.
Schrijf een rollback-plan in klare taal voordat je het nodig hebt. Wees specifiek over wat snel teruggedraaid kan worden (redeploy vorige versie, feature-flag uitschakelen) en wat niet (dataverwijderingen, onomkeerbare migraties), plus wie rollback mag triggeren en hoe je herstel bevestigt.
Begin met opschrijven wat nooit gedeeld mag worden tussen omgevingen: de database, geheimen (API-sleutels, tokens) en elke integratie die echte e-mails kan sturen, kaarten kan belasten of klanten kan berichten. Als je maar één ding scheidt, scheid de database.
Een setup die je herhaalt zonder dat het een rommeltje wordt:
Noem omgevingen en zet grenzen. Gebruik consistente namen (Dev, Staging, Prod). Besluit dat elke omgeving zijn eigen database, eigen geheimen en eigen integratie-accounts of test-modi heeft.
Clone de app met aparte configuratie. In een no-code platform zoals AppMaster maak je Dev- en Staging-versies van dezelfde app. Houd de logica gelijk, maar houd omgevingsinstellingen gescheiden (database connection strings, API-sleutels, webhook-URL's).
Maak en seed databases, en bewijs de scheiding. Maak drie databases (of drie geïsoleerde schema’s als het moet). Seed Dev en Staging met nep-data die realistisch genoeg is om te testen. Doe een boundary-check: maak een record in Staging en bevestig dat het niet in Prod verschijnt, en probeer het omgekeerde.
Zet integraties in veilige modus en valideer webhooks. Betalingen gebruiken test-modus, e-mail gaat naar een sandbox-inbox, messaging post naar een testkanaal. Trigger de volledige flow (gebruiker registreert zich, wachtwoord reset, betaling poging) en bevestig dat webhooks alleen in de overeenkomende omgeving landen.
Draai een staging-checklist en promoot dan dezelfde wijziging. Test belangrijke journeys, permissies en foutpaden in Staging. Als het schoon is, pas je exact dezelfde wijzigingen toe in Prod (vermijd quick fixes die alleen in Prod worden gemaakt).
Na release monitor je een kort venster: kijk logs, mislukte verzoeken en integratie-dashboards. Houd een rollback-optie klaar (vorige build, vorige configuratie of een feature-toggle) totdat het verkeer normaal lijkt.
Een klein ops-team bouwt een interne supportportal: agents loggen in, zoeken klanten op, belasten voor add-ons in Stripe en sturen e-mailupdates wanneer een ticket van status verandert. Ze draaien het over drie omgevingen zodat testen nooit echt geld of echte inboxen raakt.
In dev is alles standaard nep. De database is gescheiden en gevuld met seed-data (voorbeeldklanten, voorbeeldtickets en probleemgevallen zoals ontbrekende e-mails). Authenticatie wijst naar een test user directory of een kleine set testaccounts. Stripe gebruikt test-modus en testkaarten, en e-mail gaat naar een sandbox-mailbox (of is uitgeschakeld en gelogd).
In staging is het doel bijna-echt zonder risico. De database is gescheiden maar ververst uit productie op een veilige manier (bijv. geanonimiseerde namen en e-mails). Authenticatie komt overeen met productie-instellingen, maar toegang is beperkt tot een kleine groep. Stripe blijft in test-modus, maar het team voert realistische checkout- en refund-flows uit. E-mail is alleen toegestaan naar goedgekeurde interne adressen.
In prod is de portal dichtgetimmerd. Alleen goedgekeurde admins kunnen integraties veranderen of deployen. Echte Stripe-sleutels en echte e-mailzendingen zijn ingeschakeld en auditlogs staan aan.
Nu een nieuwe feature: een one-click refund workflow. Een builder maakt het in AppMaster met de Business Process Editor en test het in dev met testkaarten en controleert UI-tekst en statusupdates.
In staging verschijnt een veilige fout: de refund-logica triggert de "ticket gesloten" e-mail twee keer omdat twee stappen op dezelfde statusverandering afgaan. In productie zou dat klanten gespamd en agents verward hebben. In staging raakt het alleen interne inboxen, dus het team repareert de voorwaarde en test opnieuw.
Ze documenteren een paar basics zodat niemand later hoeft te gokken: omgevingsnamen en eigenaren, waar sleutels leven en wie ze roteert, welke databases bij welke omgeving horen, de release-checklist en de regel “geen echte data in dev”.
De meeste incidenten hier zijn geen mysteriebugs. Het zijn vergissingen: de verkeerde database, de verkeerde sleutel of de verkeerde endpoint.
De grootste valkuil is een gedeelde database over omgevingen. Het voelt handig in het begin, vooral als je realistische data wilt. Later wordt het een stille aansprakelijkheid: een testscript verwijdert records, een migratie draait te vroeg, of een nieuw veld wordt geschreven in een formaat dat productiecode niet leest.
Een andere veelvoorkomende oorzaak is het gebruik van productie-API-sleutels in staging. Betalingen en e-mail zijn de grootste boosdoeners. Eén staging-checkout kan echte kosten maken en één staging-e-mailtest kan echte klanten bereiken. Als je tool environment variables of aparte config per deployment ondersteunt (veel no-code platforms doen dat, inclusief AppMaster), behandel sleutels als onderdeel van de omgeving, niet als onderdeel van de app.
Webhook-confusie is een naaste verwant. Teams hergebruiken webhook-endpoints, zodat zowel staging als productie dezelfde events ontvangen. Dat creëert dubbele bestellingen, herhaalde “account aangemaakt” flows en rommelige supporttickets die moeilijk terug te draaien zijn.
Achtergrondjobs verdienen extra aandacht omdat ze stil draaien. Een nachtelijke sync, "stuur herinnering" workflow of auto-close proces kan vanuit staging vuren en echte services raken als je vergeten bent het uit te schakelen.
Net voordat je shipped, wil je snelle checks die de veelvoorkomende vergissingen vangen: staging wijst naar de productiedatabase, de verkeerde API-sleutel is geplakt of een gevaarlijke webhook staat aan.
Een korte checklist die je in 10 minuten kunt doorlopen:
Doe dan een people-check: bekijk de productie-toegangslijst en verwijder iedereen die het niet nodig heeft. Als je tool rollen ondersteunt, eis een goedkeuringsstap voor productie-wijzigingen, ook al is het team klein.
Om dit beheersbaar te houden, standaardiseer namen en variabelen (DEV, STAGING, PROD) en plan een maandelijkse review van geheimen en toegang. Dat is makkelijker regelmatig te doen dan tijdens een incident.
Als je met AppMaster bouwt, kun je aparte PostgreSQL-configs per omgeving houden, modules zoals auth, Stripe en e-mail/SMS op de juiste sleutels per deployment richten en deployen naar verschillende targets (inclusief AppMaster Cloud of grote cloudproviders) zonder de app-logica te veranderen. Voor meer details over het platform zelf is AppMaster’s home appmaster.io.
Wat is het praktische verschil tussen dev, staging en prod?Gebruik dev om snel te bouwen, staging om de volledige release end-to-end te testen in een productie-achtige omgeving, en prod voor echte gebruikers. Het belangrijkste is dat elke omgeving eigen data, geheimen en integratie-instellingen heeft zodat een test geen echte klanten kan raken.
Heb ik echt drie omgevingen nodig, of volstaat dev + prod?Begin met dev, staging, prod omdat dat simpel is en de meeste risico's dekt. Voeg UAT of een dedicated sandbox alleen toe als je een duidelijke reden hebt, en houd namen consistent zodat niemand hoeft te raden welke omgeving de ‘echte’ is.
Wat is de veiligste manier om databases tussen omgevingen te scheiden?Deel productie niet met non-prod, zelfs niet als “read-only”. De veiligste standaard is aparte PostgreSQL-databases per omgeving, met namen en hosts die niet makkelijk te verwarren zijn zodat een verkeerde connection string meteen opvalt.
Hoe krijg ik realistische staging-data zonder echte klantdata te kopiëren?Gebruik data die realistisch is maar niet gevoelig. Een kleine gecontroleerde seed-dataset werkt meestal, en als je uit productie kopieert, anonimiseer persoonlijke velden en verwijder alles wat je niet nodig hebt zodat staging echt aanvoelt zonder klantdata te lekken.
Hoe voer ik database-migraties uit zonder productie te breken?Maak migraties voorspelbaar door ze eerst op staging toe te passen en een korte smoketest uit te voeren voordat je naar productie gaat. Maak in productie eerst een backup-punt en vermijd éénstaps brekende wijzigingen zodat je kunt terugdraaien of corrigeren zonder te panikeren.
Wat is de eenvoudigste regel voor API-sleutels en geheimen per omgeving?Gebruik verschillende geheimen in elke omgeving en bewaar ze in omgevingsspecifieke instellingen in plaats van in de app-logica. Als een dev-sleutel uitlekt, mag dat alleen dev raken; productie-sleutels mogen door een zeer kleine groep bekeken en gewijzigd worden.
Hoe voorkom ik dat staging echte e-mails verstuurt of echte kaarten belast?Behandel elke integratie als twee modi: test/sandbox voor dev en staging, en live alleen voor productie. Voor alles wat geld kan kosten of gebruikers kan berichten, zet een harde veiligheidschakelaar zodat non-prod nooit naar echte ontvangers kan sturen, zelfs niet bij een misconfiguratie.
Wat is de beste manier om webhook-mixups tussen staging en prod te vermijden?Geef elke omgeving eigen webhook-URL's en signing secrets, en verifieer handtekeningen overal, niet alleen in productie. Dit voorkomt dat staging-events productie-workflows activeren en helpt misroutes vroeg te detecteren door verkeer duidelijk te scheiden.
Wie mag productie wijzigen in een no-code app?Beperk productie-toegang strikter dan je denkt: minder mensen mogen deployen, minder mensen mogen geheimen aanpassen, en releases vereisen een tweede blik. Zelfs in no-code kan een “kleine” wijziging gedrag veranderen, dus productie heeft duidelijke permissies en een audit-trail nodig.
Wat is de veiligste release-flow en hoe rol ik snel terug als er iets misgaat?Laat wijzigingen in één richting bewegen: dev → staging → prod, en vermijd directe bewerkingen in prod. Als je moet herstellen, redeploy de laatst bekende goede versie en schakel risicovolle workflows uit, repareer het probleem in dev en promoot dezelfde fix via staging terug naar prod.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
