Een staging-omgeving voor je app opzetten

Om een staging-omgeving op te zetten, deploy je een tweede kopie van je app naar een eigen privé-URL, geef je die een eigen database en testsleutels van API's, en laat je hem zo veel mogelijk lijken op de opzet van productie. Daarna release je elke belangrijke wijziging eerst naar staging, doorloop je de belangrijke stromen, en publiceer je pas naar productie als staging er goed uitziet.

Als je het idee nieuw vindt, legt wat een staging-omgeving is het concept uit. Deze gids is de praktische opzet, geschreven voor mensen die met AI-tools bouwen en niet voor een DevOps-team.

Dev, staging en productie

De meeste kleine apps hebben drie omgevingen nodig, ook al is de eerste gewoon de preview van je bouwtool:

Het doel van staging is dat het zich gedraagt als productie — dezelfde code, dezelfde stack, dezelfde soort instellingen — maar een fout daar schaadt niemand.

Stap 1: bepaal wat staging moet evenaren

Staging is alleen nuttig als problemen daar opduiken voordat ze in productie opduiken. Zorg dat deze dingen overeenkomen:

• Dezelfde code, op dezelfde manier vrijgegeven.
• Dezelfde stack en versies — framework, runtime, databasetype.
• Dezelfde soort configuratie — dezelfde namen van omgevingsvariabelen, met testwaarden.
• Dezelfde services — als productie een webapp en een API heeft, heeft staging beide.

Het mag verschillen in grootte (een kleinere machine is prima) en in data.

Stap 2: maak de kopie

De eenvoudigste aanpak: een tweede deployment van hetzelfde project, op een andere URL zoals staging.jouwapp.com of jouwapp-staging.example.com.

Hoe je dat doet hangt af van je host:

• Hosts met ingebouwde preview- of stagingdeployments kunnen er automatisch een maken voor een Git-branch.
• Hosts zonder die functie: maak een tweede app of project van dezelfde code en deploy die apart.
• Code in Git: houd een staging- of main-branch aan die naar staging deployt, en deploy naar productie vanuit een release. Zie hoe je Git gebruikt met een met AI gebouwde app.

Stap 3: geef staging een eigen database

Dit is de stap die je beschermt. Als staging en productie een database delen, verwijdert een test die records verwijdert ook echte records.

• Maak een aparte database voor staging.
• Vul die met seed-data — realistische nepgegevens die de AI voor je kan genereren.
• Heb je een kopie van productiedata nodig, verwijder of versleutel dan eerst namen, e-mailadressen en alles wat persoonlijk is.

Schrijf een seed-script dat een lege database vult met realistische testdata: 20 klanten, 50 bestellingen in verschillende statussen, en twee beheerdersgebruikers. Gebruik duidelijk nepnamen en e-mailadressen op example.com.

Voordat je de opzet vertrouwt, bevestig je welke database elke kopie gebruikt. Vraag het direct:

Met welke database verbindt deze app, en waar komt die instelling vandaan? Laat me de naam van de variabele zien, niet het wachtwoord.

Stap 4: gebruik testsleutels en gescheiden instellingen

Alles wat met een externe dienst communiceert, moet in staging test-gegevens gebruiken:

• Betalingen in testmodus (bijvoorbeeld Stripe-testsleutels), zodat er geen echte kaart wordt belast.
• E-mail verstuurd naar een sandbox of alleen naar je eigen adres, zodat klanten nooit een testbericht krijgen.
• AI en andere betaalde API's met een aparte sleutel en een laag uitgavenplafond.
• Webhooks die naar de staging-URL wijzen, niet naar productie.

Houd de namen van de variabelen in beide omgevingen gelijk en wijzig alleen de waarden. Dan hoeft de code niet te weten waar hij draait. Zie voor meer hierover hoe je API-sleutels veilig houdt.

Stap 5: houd staging privé

Staging hoort niet publiek te zijn:

• Zet het achter een login, een wachtwoord, of een lijst met toegestane teamadressen.
• Voorkom dat zoekmachines het indexeren met een noindex-metatag of de X-Robots-Tag-header.
• Link er niet naar vanaf je publieke site.
• Laat het er anders uitzien — een gekleurde "STAGING"-banner voorkomt dat je in het verkeerde tabblad test.

Voeg een felgele banner toe bovenaan elke pagina met de tekst "STAGING — alleen testdata" wanneer de omgevingsvariabele APP_ENV de waarde "staging" heeft. Voeg in dat geval ook een noindex-metatag toe.

Stap 6: maak een releaseroutine

Staging helpt alleen als je het elke keer gebruikt. Een eenvoudige routine:

1. Maak de wijziging in development en controleer die in de preview.
2. Release die naar staging.
3. Doorloop je belangrijkste stromen: aanmelden, inloggen, de belangrijkste functie, betalingen, alles wat de wijziging raakte.
4. Als er iets breekt, los je het op en release je opnieuw naar staging.
5. Publiceer dezelfde versie naar productie.
6. Controleer productie snel — dezelfde stromen, kort.

Schrijf de belangrijkste stromen op als een korte testscript. Zie hoe je je app test voor de lancering voor wat erin hoort.

Stap 7: wees zorgvuldig met databasewijzigingen

Wijzigingen aan de databasestructuur — een kolom toevoegen, een tabel hernoemen — zijn waar staging zijn waarde bewijst.

• Voer elke structurele wijziging eerst op staging uit.
• Controleer of de bestaande data intact is, niet alleen of nieuwe functies werken.
• Maak een back-up van productie voordat je dezelfde wijziging daar uitvoert. Zie hoe je de database van je app back-upt.
• Geef de voorkeur aan wijzigingen die toevoegen in plaats van hernoemen of verwijderen, zodat de oude versie nog werkt als je terugrolt.

Voorbeeldprompts

Leg uit wat er met bestaande data zou gebeuren als we deze databasewijziging op productie uitvoeren. Wordt er iets verwijderd of hernoemd?

Laat alle omgevingsspecifieke instellingen — API-URL's, sleutels, het afzenderadres van e-mail, de eigen URL van de site — uit omgevingsvariabelen komen, met dezelfde namen in staging en productie. Geef een lijst ervan.

Schrijf een korte checklist van de stromen die ik op staging moet testen vóór elke release, op basis van wat deze app doet.

Veelgemaakte fouten

• Gedeelde database. De meest schadelijke fout. Staging krijgt altijd een eigen database.
• Live-sleutels in staging. Echte betalingen, echte e-mails naar echte klanten.
• Staging loopt uit de pas met productie. Verschillende versies of instellingen betekenen dat staging problemen niet meer vangt.
• Een publieke, geïndexeerde staging-site die naast je echte site in zoekresultaten verschijnt.
• Staging overslaan voor "kleine" wijzigingen. Kleine wijzigingen breken ook dingen.
• In het verkeerde tabblad testen. Een zichtbare banner lost dat op.

Checklist

• Staging draait dezelfde code, stack en services als productie.
• Staging heeft een eigen database met test- of geschoonde data.
• Betalingen, e-mail en betaalde API's gebruiken testsleutels in staging.
• Variabelenamen komen overeen tussen omgevingen; alleen de waarden verschillen.
• Staging staat achter een login of wachtwoord en wordt niet geïndexeerd.
• Er verschijnt een banner wanneer je op staging bent.
• Elke release gaat eerst naar staging, met een geschreven lijst van te controleren stromen.
• Databasewijzigingen worden eerst op staging uitgevoerd, met een back-up van productie vóór de release.

Staging op Mythex

Publish van Mythex geeft je één live-URL per app; er is geen aparte staging-schakelaar. In de praktijk heb je twee opties:

• Preview als je controle vóór de release. Elk project draait in een privé-cloudwerkruimte met een live Preview. Met /test klikt de agent er als een gebruiker doorheen, en een Share-link laat een klant of teamlid de preview bekijken zonder te publiceren. Zie Preview en Code. Voor veel solo-projecten is dit genoeg.
• Een tweede project als staging. Op Pro exporteer je het project en importeer je het in een nieuw project, geef je dat project een eigen database en testsleutels als geheimen, en publiceer je het op een eigen slug. Release daarnaar voordat je het productieproject publiceert.

Vraag in beide gevallen de agent welke database de preview en de gepubliceerde app gebruiken voordat je iets destructiefs test, en gebruik checkpoints om een slechte wijziging terug te draaien. Voor het breder live zetten van een app, zie hoe je een AI-prototype naar productie brengt.

Veelgestelde vragen