Een met AI gebouwde app exporteren en zelf hosten

Om een met AI gebouwde app zelf te hosten, haal je de code eruit (een download of een synchronisatie naar een GitHub-repository die van jou is), maak je de geheimen opnieuw aan als omgevingsvariabelen, verplaats of maak je de database opnieuw, en deploy je naar een host die past bij wat de app is: een statische host voor een eenvoudige frontend, of een platform dat servers of containers draait voor alles met een backend. De code is meestal het makkelijkste deel. De data, de geheimen en de diensten die de bouwer stilletjes voor je draaide, zijn waar het werk zit.

Waarom überhaupt exporteren

Er zijn goede redenen om je code mee te nemen, en een paar minder goede.

Goede redenen:

• Eigendom en zekerheid. Een kopie van de code in je eigen repository beschermt je als de bouwer zijn prijzen, functies of voorwaarden wijzigt.
• Overdracht aan ontwikkelaars. Een engineeringteam wil de code in Git hebben, in hun gebruikelijke tools en reviewproces.
• Specifieke eisen. Dataresidentie, een bepaalde cloudprovider, het beveiligingsbeleid van een bedrijf, of infrastructuur die de bouwer niet biedt.
• Schaal of kosten, op een formaat waarbij het eigen draaien van infrastructuur echt loont.

Minder goede redenen: een kleine app met een handvol gebruikers verhuizen om een klein maandbedrag te besparen. Zelf hosten legt werk bij jou neer: updates, back-ups, monitoring, beveiligingspatches. Dat kan de juiste afweging zijn; maak haar alleen bewust.

Een verstandig middenweg: blijf bouwen en hosten waar je bent, maar synchroniseer vanaf het begin naar je eigen GitHub-repository. Zo heb je de zekerheid zonder het operationele werk. Als Git nieuw voor je is, lees dan wat GitHub is.

Wat een export wel en niet bevat

Controleer een export voordat je erop vertrouwt. Meestal:

Geheimen worden bewust weggelaten: een archief dat je misschien per e-mail verstuurt of in Git commit, mag nooit live sleutels bevatten. Dependencies worden weggelaten omdat ze opnieuw worden opgebouwd uit het lockfile.

Stap 1: haal de code eruit

Twee gangbare routes:

• Een archief downloaden van het project. Snel, en prima voor een eenmalige verhuizing of een back-up.
• Synchroniseren naar GitHub. Beter voor alles wat doorloopt: volledige geschiedenis, makkelijk te klonen op elke plek, en de meeste hosts deployen direct vanuit een GitHub-repository bij elke push.

Pak het in beide gevallen uit of kloon het op een computer (of een cloud-ontwikkelomgeving) en zoek naar een README. Als er geen is, vraag dan aan de AI in de bouwer om er een te schrijven voordat je vertrekt:

Schrijf een README voor het draaien van dit project buiten dit platform: de stack, de vereiste runtime-versies, installatie- en buildcommando’s, het startcommando en de poort, elke omgevingsvariabele die de code leest (namen en doel, zonder waarden), en hoe databasemigraties worden uitgevoerd.

Deze ene prompt bespaart uren, omdat hij de impliciete onderdelen van de opzet dwingt om op papier te komen.

Stap 2: draai het eerst lokaal

Bewijs voordat je ergens deployt dat de app op zichzelf draait:

1. Installeer de runtime die de README noemt: Node.js, Python, Java, .NET, op een passende versie.
2. Installeer de dependencies (npm install, pnpm install, pip install -r requirements.txt, of het equivalent).
3. Maak een lokaal .env-bestand met de omgevingsvariabelen, waar mogelijk met testsleutels. Houd het buiten Git. Wat omgevingsvariabelen en geheimen zijn legt het idee uit.
4. Koppel een database, een lokale Postgres of een gratis ontwikkeldatabase van een beheerde provider.
5. Draai de migraties, start de app en klik de belangrijkste stromen door.

Alles wat hier breekt, breekt ook op een host, en het is veel makkelijker om op je eigen machine te debuggen. Gangbare verrassingen: een hardcoded URL van de preview van de bouwer, een ontbrekende omgevingsvariabele die de bouwer automatisch injecteerde, of een dienst (bestandsopslag, het verkleinen van afbeeldingen) die alleen op het platform bestond.

Stap 3: verplaats de data

Als de app echte gebruikers heeft, is de data belangrijker dan de code.

• Exporteer de database. Voor Postgres maakt pg_dump een bestand dat je met pg_restore of psql in de nieuwe database terugzet. Vraag de AI van de bouwer dit te draaien als je geen directe toegang hebt, en om uit te leggen wat het heeft opgeleverd.
• Verplaats geüploade bestanden. Als gebruikers afbeeldingen of documenten hebben geüpload, staan die in objectopslag los van de database. Kopieer ze naar je nieuwe opslag (bijvoorbeeld een S3-compatibele bucket) en werk de opgeslagen URL’s bij als ze het oude domein bevatten.
• Plan de overstap. Voor een live app is de eenvoudige aanpak een korte onderhoudsperiode: stop met schrijven, maak een laatste export, zet die terug op de nieuwe host, wijzig de DNS en open weer. Schrijf elke stap eerst uit.
• Test een herstel in een scratch-database voordat je de echte verhuizing doet.

Als Postgres onbekend voor je is, legt wat Postgres is de basis uit.

Stap 4: kies waar je hem host

Kies een host die past bij wat de app is. De namen hieronder zijn voorbeelden van bekende aanbieders per categorie, op het moment van schrijven, september 2026. Het is geen ranglijst; controleer functies en prijzen op hun sites.

Je hebt ook nodig:

• Een beheerde database. Veel app-hosts bieden Postgres, en gespecialiseerde diensten zoals Neon of Supabase leveren het los. Beheerd is de moeite waard: back-ups en updates zijn het werk van iemand anders.
• Objectopslag voor uploads, als de app die heeft.
• E-mailverzending, betalingen en AI-providers. Die hebben meestal gewoon dezelfde API-sleutels nodig op de nieuwe host.

Eerlijk over de afwegingen: platformhosts (de eerste vier rijen) zijn sneller op te zetten en te onderhouden, maar je hebt minder controle en de kosten kunnen met het verkeer stijgen. Een virtuele server is bij een constante belasting vaak goedkoper en volledig van jou, maar jij beheert dan patches, TLS, back-ups, monitoring en herstel. Wil niemand in het team die taak, kies dan een platform. Voor de basis van wat hosting inhoudt, zie wat webhosting is.

Stap 5: deployen en overschakelen

1. Koppel de repository aan de host, of push een containerimage.
2. Stel omgevingsvariabelen in in het dashboard van de host: elke variabele uit je README, met live waarden.
3. Stel het build- en startcommando in, evenals de poort. Veel hosts geven de poort door via een PORT-omgevingsvariabele; de app moet daarop luisteren en op alle interfaces (0.0.0.0), niet alleen op localhost.
4. Draai de migraties tegen de nieuwe database.
5. Test op de tijdelijke URL van de host voordat je de DNS aanraakt.
6. Werk externe diensten bij die naar je oude URL wijzen: betaal-webhooks, OAuth-redirect-URL’s voor inloggen, links in e-mails, toegestane origins.
7. Verplaats het domein door de DNS-records naar de nieuwe host te wijzen. Hoe je een eigen domein koppelt legt de records uit.
8. Houd de oude deployment even draaiende tot je zeker bent, en haal die daarna weg.

Stap 6 wordt het vaakst vergeten: inloggen en betalingen die na een verhuizing stilletjes mislukken, komen meestal door een callback-URL die nog naar de oude host wijst.

Stap 6: neem de operatie over

Zodra je zelf hosts, worden de taken die de bouwer voor je deed de jouwe. Minimaal: automatische database-back-ups met een getest herstel, foutregistratie, uptime-meldingen, updates van dependencies, en een lijst van wie toegang heeft tot elk account. Hoe je een AI-prototype naar productie brengt loopt deze lijst gedetailleerder door.

Exportchecklist

• Code in een repository die van jou is, met een README over draaien, bouwen en omgevingsvariabelen
• App draait lokaal vanuit een schone kloon
• Database geëxporteerd en herstel getest; geüploade bestanden gekopieerd
• Host gekozen die past bij de vorm van de app, plus beheerde database en opslag
• Alle omgevingsvariabelen ingesteld met live waarden op de nieuwe host
• Webhooks, OAuth-redirects en links in e-mails bijgewerkt
• DNS overgeschakeld, oude deployment even bewaard en daarna verwijderd
• Back-ups, monitoring en toegangslijst op orde

Exporteren vanuit Mythex

Op Mythex ben je eigenaar van de code die je bouwt. Op het Pro-abonnement kun je het project als archief downloaden via Projectinstellingen → Exporteren, of GitHub koppelen en pushen en pullen naar je eigen repository. Gratis abonnementen kunnen de code alleen-lezen bekijken maar niet exporteren of synchroniseren. Geheimen en node_modules worden uit exports weggelaten, dus maak je geheimen opnieuw aan op de nieuwe host. De documentatie behandelt de stappen in exporteren en elders draaien en GitHub, export en import. Je kunt ook op Mythex blijven hosten en GitHub-synchronisatie gebruiken als je eigen kopie en overdrachtsroute; verhuis je wel, haal de Mythex-app dan offline zodra de nieuwe host live is.

Veelgestelde vragen