Slik eksporterer og self-hoster du en AI-bygd app

For å self-hoste en AI-bygd app må du hente ut koden (en nedlasting eller en synk til et GitHub-repo du eier), lage hemmelighetene på nytt som miljøvariabler, flytte eller gjenskape databasen, og deploye den til en host som passer til det appen er. En statisk host for en enkel frontend, eller en plattform som kjører servere eller containere for alt med en backend. Koden er vanligvis den enkle delen. Data, hemmeligheter og tjenestene byggeren stille kjørte for deg, er der arbeidet ligger.

Hvorfor eksportere i det hele tatt

Det finnes gode grunner til å ta koden med seg, og noen mindre gode.

Gode grunner:

• Eierskap og sikkerhet. En kopi av koden i ditt eget repo beskytter deg hvis byggeren endrer priser, funksjoner eller vilkår.
• Overlevering til utviklere. Et utviklingsteam vil ha koden i Git, i sine vanlige verktøy og sin vanlige review-prosess.
• Spesifikke krav. Datalagring i et bestemt land, en bestemt skyleverandør, selskapets sikkerhetspolicyer eller infrastruktur byggeren ikke tilbyr.
• Skala eller kostnad på et nivå der det virkelig lønner seg å kjøre egen infrastruktur.

Mindre gode grunner: å flytte en liten app med en håndfull brukere for å spare et lite beløp i måneden. Selvhosting legger arbeid på deg — oppdateringer, sikkerhetskopier, overvåking, sikkerhetsrettinger. Det kan være riktig avveining; ta den bevisst.

En fornuftig mellomvei: bli der du bygger og hoster, men synk til ditt eget GitHub-repo fra tidlig av. Da får du sikkerheten uten det operative arbeidet. Hvis Git er nytt for deg, les hva GitHub er.

Hva en eksport inneholder og ikke inneholder

Før du stoler på en eksport, åpne den og sjekk. Typisk:

Hemmelighetene utelates med vilje — et arkiv du kan sende på e-post eller committe, skal aldri inneholde aktive nøkler. Avhengigheter utelates fordi de bygges på nytt fra lock-filen.

Steg 1: Få koden ut

To vanlige veier:

• Last ned et arkiv av prosjektet. Raskt, og greit for en engangsflytting eller en sikkerhetskopi.
• Synk til GitHub. Bedre for alt som er løpende: full historikk, enkelt å klone hvor som helst, og de fleste hosts deployer direkte fra et GitHub-repo ved hver push.

Uansett, klon eller pakk ut det på en maskin (eller et skybasert utviklingsmiljø), og se etter en README. Hvis det ikke finnes en, be AI-en i byggeren skrive en før du drar:

Skriv en README for å kjøre dette prosjektet utenfor denne plattformen: stacken, nødvendige runtime-versjoner, installasjons- og byggekommandoer, startkommandoen og porten, hver miljøvariabel koden leser (navn og formål, uten verdier), og hvordan databasemigreringer kjøres.

Denne ene prompten sparer timer, fordi den tvinger de underforståtte delene av oppsettet ned på papiret.

Steg 2: Kjør den lokalt først

Før du deployer noe sted, bekreft at appen kjører på egen hånd:

1. Installer runtime README nevner — Node.js, Python, Java, .NET — i en passende versjon.
2. Installer avhengigheter (npm install, pnpm install, pip install -r requirements.txt, eller tilsvarende).
3. Lag en lokal .env-fil med miljøvariablene, helst med testnøkler. Hold den utenfor Git. Hva miljøvariabler og hemmeligheter er forklarer ideen.
4. Koble til en database — en lokal Postgres, eller en gratis utviklingsdatabase fra en administrert leverandør.
5. Kjør migreringer, start appen og klikk deg gjennom hovedflytene.

Alt som bryter her, bryter også på en host, og det er mye lettere å feilsøke på egen maskin. Vanlige overraskelser: en hardkodet URL til byggerens forhåndsvisning, en manglende miljøvariabel byggeren satte automatisk, eller en tjeneste (fillagring, bildebehandling) som bare fantes på plattformen.

Steg 3: Flytt dataene

Hvis appen har ekte brukere, betyr dataene mer enn koden.

• Eksporter databasen. For Postgres lager pg_dump en fil du kan gjenopprette med pg_restore eller psql i den nye databasen. Be byggerens AI kjøre den hvis du ikke har direkte tilgang, og forklare hva den produserte.
• Flytt opplastede filer. Hvis brukere lastet opp bilder eller dokumenter, ligger de i objektlagring atskilt fra databasen. Kopier dem til ny lagring (for eksempel en S3-kompatibel bøtte) og oppdater lagrede URL-er hvis de inneholder den gamle hosten.
• Planlegg overgangen. For en levende app er den enkle løsningen et kort vedlikeholdsvindu: stopp skriving, ta en siste eksport, gjenopprett den på den nye hosten, bytt DNS, og åpne igjen. Skriv ned hvert steg først.
• Test en gjenoppretting i en tom database før den ekte flyttingen.

Hvis Postgres er ukjent for deg, dekker hva Postgres er det grunnleggende.

Steg 4: Velg hvor du skal hoste

Tilpass hosten til hva appen er. Navnene under er eksempler på velkjente leverandører i hver kategori fra september 2026, ikke en rangering. Sjekk oppdaterte funksjoner og priser på nettstedene deres.

Du trenger også:

• En administrert database — mange apphoster tilbyr Postgres, og dedikerte tjenester som Neon eller Supabase leverer det alene. Administrert er verdt det: sikkerhetskopiering og oppdateringer er noen andres jobb.
• Objektlagring for opplastinger, hvis appen har dem.
• E-postutsending, betalinger og AI-leverandører — disse trenger vanligvis bare de samme API-nøklene satt på den nye hosten.

For å være rettferdig med avveiningene: plattformhostene (de fire første radene) er raskere å sette opp og vedlikeholde, men du har mindre kontroll, og kostnadene kan øke med trafikken. En virtuell server er ofte billigere ved jevn belastning og helt under din kontroll, men du eier oppdateringer, TLS, sikkerhetskopier, overvåking og gjenoppretting. Hvis ingen på teamet vil ha den jobben, velg en plattform. For det grunnleggende om hva hosting innebærer, se hva webhosting er.

Steg 5: Deploy og bytt over

1. Koble repoet til hosten, eller push et containerbilde.
2. Sett miljøvariabler i hostens dashbord — alle fra README-en, med de ekte verdiene.
3. Sett bygge- og startkommandoer og porten. Mange hoster sender porten i en PORT-miljøvariabel; appen bør lytte på den og på alle grensesnitt (0.0.0.0), ikke bare localhost.
4. Kjør migreringer mot den nye databasen.
5. Test på hostens midlertidige URL før du rører DNS.
6. Oppdater eksterne tjenester som peker på den gamle URL-en: betalings-webhooks, OAuth-omdirigerings-URL-er for innlogging, lenker i e-post, tillatte opprinnelser.
7. Flytt domenet ved å oppdatere DNS-postene til den nye hosten. Hvordan du kobler til et eget domene forklarer postene.
8. Behold den gamle deployen en kort stund til du er sikker, og ta den deretter ned.

Steg 6 er det som oftest glemmes: innlogginger og betalinger som stille slutter å virke etter en flytting, skyldes nesten alltid en callback-URL som fortsatt peker på den gamle hosten.

Steg 6: Ta over driften

Når du selvhoster, blir det byggeren gjorde for deg ditt ansvar. Minst: automatiske databasesikkerhetskopier med en testet gjenoppretting, feilsporing, oppetidsvarsler, oppdatering av avhengigheter, og en oversikt over hvem som har tilgang til hver konto. Hvordan du tar en AI-prototype til produksjon går gjennom denne listen mer i detalj.

Sjekkliste for eksport

• Kode i et repo du eier, med en README som dekker kjøring, bygging og miljøvariabler
• Appen kjører lokalt fra en ren klone
• Database eksportert og gjenoppretting testet; opplastede filer kopiert
• Host valgt etter appens form, pluss administrert database og lagring
• Alle miljøvariabler satt med ekte verdier på den nye hosten
• Webhooks, OAuth-omdirigeringer og lenker i e-post oppdatert
• DNS byttet, gammel deploy beholdt en stund og deretter fjernet
• Sikkerhetskopiering, overvåking og tilgangsliste på plass

Eksportere fra Mythex

I Mythex eier du koden du bygger. På Pro-abonnementet kan du laste ned prosjektet som et arkiv fra Prosjektinnstillinger → Eksporter, eller koble til GitHub og push og pull mot ditt eget repo. Gratisabonnement kan se koden skrivebeskyttet, men ikke eksportere eller synke den. Hemmeligheter og node_modules utelates fra eksporter, så lag hemmelighetene på nytt på den nye hosten. Dokumentasjonen dekker stegene i eksporter og kjør andre steder og GitHub, eksport og import. Du kan også fortsette å hoste på Mythex og bruke GitHub-synk bare som din egen kopi og overleveringsvei. Hvis du flytter, avpubliser Mythex-appen når den nye hosten er oppe.

Spørsmål