Gebruik deze productieklare handoff-checklist om omgevingen, geheimen, monitoring, backups en runbooks te verpakken zodat ops je app kan deployen en beheren.
Een productieklaar handoff betekent dat ops de app kan draaien zonder te moeten raden. Ze kunnen een bekende versie deployen, bevestigen dat die gezond is, op alerts reageren en herstellen van een slechte release of storing. Als dat allemaal afhangt van het geheugen van één ontwikkelaar, is de handoff niet klaar.
Behandel de handoff als een pakket dat één vraag beantwoordt: als de originele bouwers een week weg zouden zijn, kan ops het systeem nog steeds veilig en beschikbaar houden?
Een solide pakket omvat meestal wat de app doet, hoe “gezond” eruitziet, hoe releases werken (deploy, verifiëren, terugdraaien), waar configuratie staat, hoe geheimen worden behandeld en hoe te monitoren, back-uppen en reageren op incidenten.
Even belangrijk is wat het niet dekt. Een handoff is geen belofte om features toe te voegen, te refactoren, schermen te ontwerpen of “later op te schonen.” Dat zijn aparte projecten met hun eigen scope.
Voordat je het voltooid noemt, stem ownership en responstijden af. Bijvoorbeeld: ops is verantwoordelijk voor uptime en deploys; het productteam is verantwoordelijk voor roadmap-wijzigingen; het dev-team biedt een afgebakend venster post-handoff support voor fixes en vragen.
Ops kan alleen ownership hebben over wat ze kunnen zien. Een eenvoudige éénpagina-inventaris voorkomt giswerk tijdens deploys, incidenten en audits. Houd het in gewoon Nederlands en specifiek.
Noem elk draaiend onderdeel van het systeem en waar het woont: de backend-API, webapp, achtergrond-workers, geplande jobs en hoe mobiele apps verbinden. Zelfs als iOS/Android via stores worden verspreid, zijn ze nog steeds afhankelijk van dezelfde backend.
Noem externe services die de app nodig heeft. Gebruik je PostgreSQL, een queue, objectopslag of derde-partij API's (betalingen zoals Stripe, messaging, e-mail/SMS, Telegram), noteer dan de exacte servicenaam en waar het voor gebruikt wordt.
Leg netwerkvereisten vast zodat hosting geen proef en fout wordt: vereiste domeinen (app, api, admin), poorten en protocollen, wie TLS-certificaten vernieuwt, waar DNS wordt beheerd en eventuele inbound/outbound allowlists.
Schrijf tenslotte de verwachte load in echte cijfers: piek-aanvragen per minuut, actieve gebruikers, typische payloadgroottes, huidige databasesize en verwachte groei. Zelfs ruwe reeksen helpen ops met het instellen van limieten en alerts.
Als je bouwde met AppMaster, inventariseer de gegenereerde backend, webapp en integraties zodat ops weet wat samen gedeployed moet worden.
Productie-setup faalt meestal op het saaie deel: config die alleen in iemands hoofd leeft. Behandel configuratie als een oplevering. Ops moet kunnen zien welke instellingen bestaan, wat per omgeving verschilt en hoe ze veilig gewijzigd kunnen worden.
Begin met het benoemen van elke omgeving die er nu is, ook als je denkt dat het tijdelijk is. De meeste teams hebben dev, staging en production, plus kopieën zoals “production-eu” of “staging-us.” Noteer welke omgeving gebruikt wordt voor release-testing, datamigraties en incidentoefeningen.
Lever één configuratiereferentie die variabelnamen en veilige voorbeeldwaarden lijst (nooit echte credentials). Maak placeholders duidelijk.
Je handoff-pakket moet bevatten:
Voeg een eenvoudig wijzigingsproces toe. Bijvoorbeeld: aanvraag via een ticket, review door service-eigenaar, eerst toepassen in staging, daarna promoten naar productie in een gepland window met een rollback-plan als het foutpercentage stijgt.
Als je een AppMaster-app exporteert en self-host, blijf bij dezelfde regel: lever een schoon, gedocumenteerd set config keys mee naast de gegenereerde bron zodat ops het consistent kan draaien in verschillende omgevingen.
Geheimen zijn de snelste weg waarop een schone handoff verandert in een security-incident. Het doel is eenvoudig: ops moet elk geheim dat de app nodig heeft kennen, waar het ligt, wie het kan lezen en hoe het te veranderen zonder downtime.
Begin met een korte geheimenlijst die ops in één minuut kan scannen. Noteer voor elk item wat het ontsluit (database, SMTP, Stripe, JWT-signing key), waar het bewaard wordt (vault, cloud secret store, Kubernetes Secret, versleuteld bestand) en wie rotatie beheert.
Schrijf rotatiestappen als een recept, niet als beleid. Inclusief de exacte volgorde, hoe lang het oude geheim geldig moet blijven en de ene controle die aantoont dat het gelukt is.
Gebruik dit patroon voor elk geheim:
Wees expliciet over encryptieverwachtingen. Geheimen moeten in rust versleuteld zijn in de secret store en beschermd in transit (TLS) tussen de app en zijn afhankelijkheden. Nooit geheimen in source control, build-artifacts of gedeelde docs zetten.
Definieer break-glass toegang. Als een storing normale toegang blokkeert, specificeer wie noodtoegang kan goedkeuren, hoe lang die duurt en wat daarna geaudit moet worden.
Ops kan alleen ownership hebben over wat ze kunnen reproduceren. Een goed deployment-pakket maakt drie vragen makkelijk te beantwoorden: wat draaien we precies, hoe deployen we het opnieuw en hoe herstellen we snel als iets breekt?
Voeg een duidelijke "bill of materials" voor de build toe. Noem het artifact-type en hoe je het verifieert, niet alleen waar het staat:
Voeg één klein, concreet voorbeeld toe. Bijvoorbeeld: “Deploy v1.8.2 door de image-tag bij te werken, migraties te draaien en dan webworkers te herstarten. Als health checks binnen 10 minuten falen, revert naar v1.8.1 en stop de migratiejob.”
Een rollback-plan moet lezen als instructies die je om 02:00 kunt volgen. Het moet vermelden:
Als de app met AppMaster is gebouwd en als broncode is geëxporteerd voor self-hosting, voeg dan de gegenereerde codeversie, buildinstructies en runtimeverwachtingen toe zodat ops dezelfde release later kan herbouwen.
Een handoff is niet compleet totdat ops kan zien wat de app doet en gewaarschuwd wordt voordat gebruikers klagen.
Stem af welke logs moeten bestaan en waar ze terechtkomen (bestand, syslog, logplatform). Zorg dat logs tijdgesynchroniseerd zijn en een request- of correlatie-ID bevatten zodat incidenten end-to-end traceerbaar zijn.
Je wilt doorgaans application logs (belangrijke events en failures), error logs (stacktraces en gefaalde jobs), access logs (requests en statuscodes), audit logs (admin-acties en exports) en infrastructuurlogs (restarts, node-pressure, diskproblemen).
Definieer vervolgens een kleine set metrics die gebruikersimpact en systeemgezondheid reflecteren. Als je er maar vijf kiest: latency (p95/p99), error rate, saturatie (CPU/memory/disk), queue-diepte en beschikbaarheidschecks van buiten je netwerk.
Alertregels moeten eenduidig zijn: wat triggert, ernst (page vs ticket), wie on-call is en wanneer escaleren. Voeg een “known good” dashboard-snapshot en een korte notitie toe die beschrijft wat normaal is (typische latency-range, verwachte error rate, gebruikelijke queue-diepte). Die context voorkomt lawaaierige alerts en helpt nieuwe responders snel te handelen.
Backups zijn niet iets wat je "hebt." Het is iets waar je van kunt herstellen, op aanvraag.
Schrijf het exacte bereik op: database, file storage (uploads, reports, facturen) en de onderdelen die mensen vergeten, zoals config die niet in code staat en de encryptiesleutels die nodig zijn om beschermde data te lezen.
Houd doelen in eenvoudige termen. RPO is hoeveel data je kunt verliezen (bijv. 15 minuten). RTO is hoe lang je down kunt zijn (bijv. 1 uur). Kies cijfers die het bedrijf goedkeurt, want die sturen kosten en inspanning.
Neem op:
Als je een AppMaster-geproduceerde app exporteert en self-host, voeg PostgreSQL-restore-stappen toe plus eventuele externe storage buckets en de sleutels die gebruikt worden voor versleutelde velden.
Plan een restore-oefening. Noteer tijd, wat misging en wat je veranderde zodat de volgende restore sneller en minder stressvol is.
Een handoff is pas echt als iemand om 02:00 gepaged kan worden en het probleem kan oplossen zonder te moeten raden. Runbooks zetten tribale kennis om in stappen die on-call kan volgen.
Begin met de incidenten die je het eerst verwacht: totale uitval, trage requests en een deploy die iets kapotmaakt. Houd elk runbook kort. Zet de snelste checks bovenaan zodat responders binnen enkele minuten signaal krijgen.
Houd de structuur consistent zodat het onder druk scanbaar is:
Als de app geëxporteerd of self-hosted is vanuit AppMaster, vermeld waar de gegenereerde services draaien, hoe ze veilig herstart worden en welke configwaarden per omgeving verwacht worden.
Houd een korte post-incident checklist bij. Leg de timeline vast, wat laatst veranderd is, exacte foutmeldingen, getroffen gebruikers en welke actie het probleem oploste. Werk daarna het runbook bij terwijl details nog vers zijn.
Ops kan alleen ownership hebben als duidelijk is wie wat kan doen en hoe toegang wordt vastgelegd.
Schrijf de rollen op die je daadwerkelijk gebruikt. Voor veel teams zijn dit voldoende:
Documenteer het "deurbeleid" in eenvoudige stappen: wie verleent toegang, waar het verleend wordt (SSO, cloud IAM, databasegebruikers, CI/CD, admin panels), wie het kan intrekken en hoe je bevestigt dat het verwijderd is tijdens offboarding.
Vergeet niet niet-menselijke toegang. Licht elk service-account en token toe dat door jobs, integraties en monitoring gebruikt wordt, met een least-privilege-notitie voor elk (bijv. “kan alleen lezen uit bucket X”). Als je AppMaster-broncode exporteert voor self-hosting, vermeld welke env vars of configbestanden deze identiteiten definiëren, maar plak nooit geheime waarden in het handoff-doc.
Stel ook auditlog-verwachtingen in: wat gelogd moet worden (login, deploy, configwijziging, DB-admin-acties), wie logs kan lezen, retentie, waar logs bewaard worden en hoe logs opgevraagd worden tijdens een incident of review.
Securitynotities moeten leesbaar zijn voor niet-specialisten, maar specifiek genoeg zodat ops kan handelen. Voeg een éénpagina-samenvatting toe die antwoordt op: welke data bewaren we, waar staat het en wie kan erbij?
Begin met datatypes: klantprofielen, supporttickets, payment-metadata, bestanden. Benoem gevoelige categorieën zoals PII (namen, e-mails, telefoonnummers), credentials en gereguleerde data die je organisatie relevant vindt. Als je broncode exporteert voor self-hosting (inclusief uit AppMaster), vermeld waar die data in de database belandt en welke services het kunnen lezen.
Schrijf retentie- en verwijderregels in praktische termen. Zeg wat je bewaart, hoelang en hoe verwijdering werkt (soft delete vs hard delete, vertraagde purge, backups). Als er juridische houdingen of auditbehoeften zijn, noteer wie uitzonderingen goedkeurt.
Logs lekken vaak meer dan databases. Wees duidelijk waar PII kan verschijnen (access logs, error logs, analytics events) en hoe je het reduceert of maskert. Als een veld nooit gelogd mag worden, benoem die regel.
Houd goedkeuringen expliciet:
Als je één ding extra kunt toevoegen, voeg dan een bewijsnotitie toe: waar auditlogs worden bewaard en hoe ze geëxporteerd kunnen worden als iemand om bewijs vraagt.
Ops neemt een klantportaal over dat door een klein productteam gebouwd is en migreert het naar nieuw self-hosted infra. Het doel is niet alleen “het draait”, maar “ops kan het draaien zonder de bouwers te bellen.”
Dag 1: Ops doet een schone eerste deploy in een nieuwe omgeving met alleen het handoff-pakket. De app komt op, maar inloggen faalt omdat een env-var voor de e-mailprovider mist. Die wordt toegevoegd aan de env-template en de deploy wordt herhaald totdat het vanaf nul werkt.
Dag 2: De eerste alert wordt opzettelijk veroorzaakt. Ops triggert een gecontroleerde fout (stop een service of blokkeer uitgaande e-mail) en bevestigt: metrics tonen het probleem, alerts bereiken het juiste kanaal en het bericht zegt wat te doen.
Dag 3: Een token verloopt in de payment-sandbox. Omdat de locatie van credentials en rotatiestappen gedocumenteerd zijn, vervangt ops het zonder te raden of geheimen bloot te geven.
Dag 4: DNS-cutover. Een verkeerde record wijst naar het oude IP en het portaal lijkt voor sommige gebruikers down. Ops gebruikt het runbook om DNS, TLS en health checks in de juiste volgorde te verifiëren.
Dag 5: Eerste backup-restore test. Ops herstelt naar een verse database en bewijst dat het portaal echte data kan laden.
De app heeft 7 dagen gedraaid zonder mysterieuze fixes, één succesvolle restore, duidelijke alerts en een reproduceerbare deploy die ops alleen kan uitvoeren.
De snelste manier om een rustige handoff in een 02:00-brand te veranderen is aannemen dat “we ops alles hebben verteld” hetzelfde is als “ops kan het draaien zonder ons.”
Veelvoorkomende faalpatronen na een self-hosting handoff zijn: geheimen gedeeld in spreadsheets of chat, rollbacks die een ontwikkelaar nodig hebben, backups die bestaan maar nooit hersteld zijn, alerts die de hele dag afgaan omdat drempels niet zijn afgestemd en omgevingsdetails die alleen in iemands hoofd leven (poorten, DNS-namen, cron-schedules, cloud-permissions).
Voorbeeld: je exporteert broncode uit AppMaster voor self-hosting en de eerste deploy werkt. Twee weken later breekt een configwijziging inloggen. Als geheimen in chat gedeeld zijn en rollback de oorspronkelijke bouwer nodig heeft, verliest ops uren om weer terug te komen op “werkte gisteren.”
Voordat je het ticket sluit, voer een korte fresh-start drill uit. Geef het handoff-pakket aan één ops-engineer en een schone omgeving (nieuwe VM, nieuwe Kubernetes-namespace of een blanco cloudproject). Als die engineer binnen een ingestelde tijd (bijv. 2 uur) kan deployen, observeren en herstellen, ben je dichtbij.
Gebruik deze checks:
Als je gegenereerde broncode voor self-hosting exporteert, bevestig dan ook dat ops weet waar build-inputs, versies en release-tags zijn vastgelegd zodat toekomstige releases reproduceerbaar blijven.
Doe één laatste walkthrough met de mensen die de pager dragen. Behandel het als een repetitie. Bewijs dat deploy, rollback, restore en alerting werken met precies het pakket dat je overdraagt.
Een finale walkthrough omvat meestal: deploy naar een testomgeving en daarna naar productie met dezelfde stappen, terugrollen naar de vorige versie en verifiëren dat de app nog werkt, herstellen uit backup in een schone omgeving en valideren van een eenvoudige check (inloggen, record aanmaken, bericht verzenden), één veilige test-alert triggeren en bevestigen waar logs en dashboards te vinden zijn tijdens een incident.
Maak ownership expliciet. Wijs een benoemde eigenaar toe voor elk runbook (deploy, incident, restore) en voor elke alertroute (primaire on-call, backup, gedrag buiten kantooruren). Als niemand eigenaar is van een alert, wordt deze genegeerd of wordt de verkeerde persoon wakker gemaakt.
Schrijf een kort Day-2-plan zodat ops weet wat te verbeteren na de eerste week: drempels afstemmen, kosten controleren, oude artifacts opruimen en toegang herzien. Houd het klein en time-boxed.
Als je met AppMaster bouwde (appmaster.io), voeg de geëxporteerde broncode of de exacte deployment-targetdetails toe (cloud, regio's, build-instellingen, vereiste services) zodat ops de app kan reproduceren zonder afhankelijk te zijn van de originele projectworkspace. Stel een eenvoudige cadans in om het pakket bij te werken wanneer eisen veranderen, zodat runbooks niet vervreemden van de werkelijkheid.
What does “production-ready handoff” actually mean?Een productieklare overdracht betekent dat ops een bekende versie kan deployen, bevestigen dat die gezond is, op alerts kan reageren en kan herstellen van storingen zonder afhankelijk te zijn van het geheugen van één specifieke ontwikkelaar. Als een week zonder de bouwers de uptime in gevaar zou brengen, is de handoff niet klaar.
What should be included in a basic system inventory?Begin met een éénpagina-inventaris die elk actief onderdeel en waar het draait vermeldt: API, webapp, workers, geplande jobs, database, opslag en benodigde derde partijen. Voeg domeinen, poorten, wie TLS/DNS beheert en een ruwe verwachting van de load toe zodat ops niet hoeft te raden.
How do we hand off environment configuration without leaking secrets?Lever één configuratiereferentie die elke configkey, het type en een veilig voorbeeldwaarde vermeldt, plus wat er verschilt tussen dev/staging/prod. Houd echte credentials eruit en documenteer waar config staat en hoe het tijdens deploys toegepast wordt, zodat wijzigingen reproduceerbaar zijn.
What’s the minimum we should document for secrets and credential rotation?Maak een korte geheimenlijst die zegt waar elk geheim voor is, waar het opgeslagen is, wie het kan lezen en wie verantwoordelijk is voor rotatie. Schrijf rotatiestappen als een checklist met één duidelijke verificatiestap, en voeg een break-glass-proces voor noodgevallen toe met auditverwachtingen.
What makes a deployment package “reproducible” for ops?Ops moet precies weten wat draait en hoe het opnieuw te maken is: artifact-naam/tag, versie, builddatum, checksum en de bronreferentie die gebruikt is om het te bouwen. Voeg het aanbevolen deploy-target, de deployvolgorde, verwachte deploytijd en hoe migraties gecontroleerd worden toe.
What should a rollback plan include so it’s usable at 2 a.m.?Definieer de signaaltriggers (zoals falende health checks of verhoogde error rate), de laatst bekende goede versie en de exacte stappen om snel terug te keren. Geef aan of databasewijzigingen omkeerbaar zijn en wat de veilige fallback is als dat niet zo is, zodat rollback geen improvisatie wordt.
Which monitoring signals should we prioritize during handoff?Kies een kleine set metrics die gebruikersimpact reflecteren: latency, foutpercentage, resource-saturatie, queue-diepte en een externe uptime-check. Maak alerts duidelijk over ernst, wie gepaged wordt en wat “normaal” is, en zorg dat logs tijdgesynchroniseerd en traceerbaar zijn met een correlatie-ID.
How do we make backups and restores genuinely reliable?Documenteer wat geback-upt wordt, waar het opgeslagen is, retentie en wie restores kan uitvoeren. Voeg een stap-voor-stap restore-procedure met verificatie toe en plan een restore-oefening; backups zijn pas waardevol als een restore op aanvraag in een schone omgeving mogelijk is.
What should an on-call runbook look like for common incidents?Houd runbooks kort en consistent: symptomen, eerste checks, volgende checks, beslismomenten en escalatie. Focus op de waarschijnlijke eerste incidenten (totale uitval, traagheid, kapotte deploy) en werk het runbook bij direct na incidenten zodat kennis niet vervaagt.
How should we document access control and permissions for ops ownership?Schrijf de rollen op die je echt gebruikt (deployer, DB-admin, read-only, incident commander), hoe toegang wordt verleend en ingetrokken, en wat gelogd moet worden voor audit. Vergeet service-accounts en tokens niet; vermeld wat ze mogen en waar hun identiteit geconfigureerd is zonder geheime waarden te plakken.
27 jan 2026
7 min
26 jan 20268 min
21 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
