Sådan eksporterer og selv-hoster du en AI-bygget app

For at selv-hoste en AI-bygget app skal du få koden ud (en download eller en synkronisering til et GitHub-repository, du ejer), genskabe dens hemmeligheder som miljøvariabler, flytte eller genskabe databasen og deploye den til en host, der passer til appen: en statisk host til et simpelt front end, eller en platform der kører servere eller containere til alt med en back end. Koden er normalt den nemme del. Data, hemmeligheder og de tjenester, som builderen stille og roligt kørte for dig, er der arbejdet ligger.

Hvorfor eksportere overhovedet

Der er gode grunde til at tage din kode med, og nogle mindre gode.

Gode grunde:

• Ejerskab og forsikring. En kopi af koden i dit eget repository beskytter dig, hvis builderen ændrer priser, funktioner eller vilkår.
• Overlevering til udviklere. Et udviklingsteam vil have koden i Git, i deres sædvanlige værktøjer og review-proces.
• Specifikke krav. Datalokation, en bestemt cloududbyder, virksomhedens sikkerhedspolitikker eller infrastruktur, builderen ikke tilbyder.
• Skala eller omkostninger på et niveau, hvor det virkelig kan betale sig at køre din egen infrastruktur.

Mindre gode grunde: at flytte en lille app med en håndfuld brugere for at spare et lille månedligt beløb. Selv-hosting flytter arbejde over på dig — opdateringer, backups, overvågning, sikkerhedsrettelser. Det kan være den rigtige afvejning; tag den bare bevidst.

Et fornuftigt mellemvej: fortsæt med at bygge og hoste, hvor du er, men synkroniser til dit eget GitHub-repository fra start. Så får du forsikringen uden det driftsmæssige arbejde. Hvis Git er nyt for dig, læs hvad GitHub er.

Hvad en eksport indeholder og ikke indeholder

Før du stoler på en eksport, så åbn den og tjek. Typisk:

Hemmeligheder udelades med vilje — et arkiv, du måske sender på e-mail eller committer, bør aldrig indeholde aktive nøgler. Afhængigheder udelades, fordi de genskabes ud fra lock-filen.

Trin 1: Få koden ud

To almindelige veje:

• Download et arkiv af projektet. Hurtigt, og fint til en engangsflytning eller en backup.
• Synkroniser til GitHub. Bedre til alt løbende: fuld historik, nem at klone hvor som helst, og de fleste hosts deployer direkte fra et GitHub-repository ved hvert push.

Uanset hvilken vej, så klon eller pak den ud på en computer (eller et cloud-udviklingsmiljø) og led efter en README. Hvis der ikke er en, så bed AI'en i builderen om at skrive en, før du forlader den:

Skriv en README til at køre dette projekt uden for denne platform: stacken, nødvendige runtime-versioner, install- og build-kommandoer, start-kommandoen og porten, hver miljøvariabel koden læser (navne og formål, ingen værdier), og hvordan databasemigrationer køres.

Denne ene prompt sparer timer, fordi den tvinger de implicitte dele af opsætningen ned på skrift.

Trin 2: Kør den lokalt først

Før du deployer nogen steder, skal du bevise, at appen kan køre på egen hånd:

1. Installer runtime'en README'en nævner — Node.js, Python, Java, .NET — i en passende version.
2. Installer afhængigheder (npm install, pnpm install, pip install -r requirements.txt eller tilsvarende).
3. Opret en lokal .env-fil med miljøvariablerne, helst med testnøgler. Hold den ude af Git. Hvad miljøvariabler og hemmeligheder er forklarer ideen.
4. Peg den på en database — en lokal Postgres eller en gratis udviklingsdatabase fra en administreret udbyder.
5. Kør migrationer, start derefter appen, og klik dig igennem de vigtigste flows.

Alt, der går i stykker her, vil også gå i stykker på en host, og det er meget nemmere at fejlsøge på din egen maskine. Almindelige overraskelser: en hårdkodet URL til builderens preview, en manglende miljøvariabel, som builderen indsatte automatisk, eller en tjeneste (filopbevaring, billedskalering), der kun fandtes på platformen.

Trin 3: Flyt data

Hvis appen har rigtige brugere, betyder data mere end koden.

• Eksportér databasen. For Postgres laver pg_dump en fil, du kan gendanne med pg_restore eller psql i den nye database. Bed builderens AI om at køre den, hvis du ikke har direkte adgang, og forklare, hvad den producerede.
• Flyt uploadede filer. Hvis brugere har uploadet billeder eller dokumenter, ligger de i objektlager, adskilt fra databasen. Kopiér dem til dit nye lager (for eksempel en S3-kompatibel bucket) og opdater de gemte URL'er, hvis de indeholder den gamle host.
• Planlæg overgangen. For en live app er den enkle tilgang et kort vedligeholdelsesvindue: stop skrivninger, tag en endelig eksport, gendan den på den nye host, skift DNS og åbn igen. Skriv hvert trin ned først.
• Test en gendannelse i en midlertidig database, før den rigtige flytning.

Hvis Postgres er ukendt, dækker hvad Postgres er det grundlæggende.

Trin 4: Vælg hvor den skal hostes

Tilpas hosten til, hvad appen er. Navnene nedenfor er eksempler på velkendte udbydere i hver kategori pr. september 2026, ikke en rangering; tjek aktuelle funktioner og priser på deres sider.

Du får også brug for:

• En administreret database — mange app-hosts tilbyder Postgres, og dedikerede tjenester som Neon eller Supabase leverer det alene. Administreret er det værd: backups og opdateringer er andres ansvar.
• Objektlager til uploads, hvis appen har dem.
• Afsendelse af e-mail, betalinger og AI-udbydere — de kræver normalt bare de samme API-nøgler sat på den nye host.

Vær ærlig om afvejningerne: platformshosts (de første fire rækker) er hurtigere at opsætte og vedligeholde, men du har mindre kontrol, og omkostningerne kan stige med trafikken. En virtuel server er ofte billigere ved stabil belastning og fuldt under din kontrol, men du ejer patching, TLS, backups, overvågning og genopretning. Hvis ingen på holdet har lyst til det job, så vælg en platform. For det grundlæggende i, hvad hosting indebærer, se hvad webhosting er.

Trin 5: Deploy og skift over

1. Forbind repositoryet til hosten, eller push et containerbillede.
2. Sæt miljøvariabler i hostens dashboard — hver enkelt fra din README, med live-værdier.
3. Sæt build- og start-kommandoer og porten. Mange hosts sender porten i en PORT-miljøvariabel; appen bør lytte på den og på alle interfaces (0.0.0.0), ikke kun på localhost.
4. Kør migrationer mod den nye database.
5. Test på hostens midlertidige URL, før du rører DNS.
6. Opdater eksterne tjenester, der peger på din gamle URL: betalings-webhooks, OAuth-redirect-URL'er til login, e-mail-links, tilladte origins.
7. Flyt domænet ved at opdatere DNS-posterne til den nye host. Sådan forbinder du et eget domæne forklarer posterne.
8. Behold den gamle deployment kørende en kort stund, til du er sikker, og tag den derefter ned.

Trin 6 er det, der oftest glemmes: login og betalinger, der stille og roligt fejler efter en flytning, kan normalt spores til en callback-URL, der stadig peger på den gamle host.

Trin 6: Overtag driften

Når du selv-hoster, bliver de ting, builderen håndterede, dit ansvar. Som minimum: automatiske databasebackups med en testet gendannelse, fejlsporing, oppetidsalarmer, opdatering af afhængigheder og en fortegnelse over, hvem der har adgang til hver konto. Sådan tager du en AI-prototype til produktion gennemgår denne liste mere detaljeret.

Eksport-tjekliste

• Kode i et repository, du ejer, med en README, der dækker kørsel, build og miljøvariabler
• Appen kører lokalt fra en ren klon
• Database eksporteret og gendannelse testet; uploadede filer kopieret
• Host valgt efter appens type, plus administreret database og lager
• Alle miljøvariabler sat med live-værdier på den nye host
• Webhooks, OAuth-redirects og e-mail-links opdateret
• DNS skiftet, gammel deployment beholdt kort tid og derefter fjernet
• Backups, overvågning og adgangsliste på plads

Eksport fra Mythex

I Mythex ejer du den kode, du bygger. På Pro-planen kan du downloade projektet som et arkiv fra Projektindstillinger → Eksport, eller forbinde GitHub og push og pull mod dit eget repository; gratis planer kan se koden i skrivebeskyttet tilstand, men ikke eksportere eller synkronisere. Hemmeligheder og node_modules udelades fra eksporter, så genskab dine hemmeligheder på den nye host. Dokumentationen dækker trinene i eksportér og kør et andet sted og GitHub, eksport og import. Du kan også blive på Mythex som hosting og bruge GitHub-synkronisering blot som din egen kopi og overleveringsvej; hvis du flytter, så afpublicer Mythex-appen, når den nye host er live.

Spørgsmål