Så exporterar och self-hostar du en AI-byggd app

För att self-hosta en AI-byggd app ska du få ut koden (en nedladdning eller en synk till ett GitHub-repo som du äger), återskapa hemligheterna som miljövariabler, flytta eller återskapa databasen och deploya den till en värd som passar appen: en statisk värd för en ren frontend, eller en plattform som kör servrar eller containrar för allt med en backend. Koden är oftast den enkla delen. Data, hemligheter och tjänsterna som byggaren i det tysta körde åt dig är där arbetet finns.

Varför exportera alls

Det finns goda skäl att ta med sig koden, och några mindre goda.

Goda skäl:

• Ägande och försäkring. En kopia av koden i ditt eget repo skyddar dig om byggaren ändrar priser, funktioner eller villkor.
• Överlämning till utvecklare. Ett utvecklingsteam vill ha koden i Git, i sina vanliga verktyg och granskningsprocesser.
• Specifika krav. Datalagring i en viss region, en viss molnleverantör, företagets säkerhetspolicyer eller infrastruktur som byggaren inte erbjuder.
• Skala eller kostnad i en storlek där egen infrastruktur faktiskt lönar sig.

Mindre goda skäl: att flytta en liten app med några användare för att spara ett litet månadsbelopp. Self-hosting flyttar arbete till dig: uppdateringar, säkerhetskopior, övervakning, säkerhetsuppdateringar. Det kan vara rätt avvägning; gör den bara medvetet.

En klok mellanväg: fortsätt bygga och hosta där du är, men synka till ditt eget GitHub-repo från början. Du får försäkringen utan det operativa arbetet. Om Git är nytt för dig, läs vad GitHub är.

Vad en export innehåller och inte innehåller

Innan du förlitar dig på en export, öppna den och kontrollera. Typiskt:

Hemligheter utelämnas med avsikt. Ett arkiv som du kan mejla eller råka checka in i Git ska aldrig innehålla skarpa nycklar. Beroenden utelämnas eftersom de byggs om från lock-filen.

Steg 1: Få ut koden

Två vanliga vägar:

• Ladda ner ett arkiv av projektet. Snabbt och bra för en engångsflytt eller en säkerhetskopia.
• Synka till GitHub. Bättre för allt löpande: full historik, enkelt att klona var som helst, och de flesta värdar deployar direkt från ett GitHub-repo vid varje push.

Oavsett väg: klona eller packa upp den på en dator (eller en molnutvecklingsmiljö) och leta efter en README. Om det inte finns någon, be AI:n i byggaren skriva en innan du går:

Skriv en README för att köra det här projektet utanför den här plattformen: stacken, nödvändiga runtime-versioner, install- och byggkommandon, startkommandot och porten, varje miljövariabel som koden läser (namn och syfte, inga värden) och hur databasmigreringar körs.

Den här prompten sparar timmar, eftersom den tvingar de underförstådda delarna av installationen att bli skrivna.

Steg 2: Kör den lokalt först

Innan du deployar någonstans, bevisa att appen går att köra på egen hand:

1. Installera runtime som README:n anger: Node.js, Python, Java, .NET, i en matchande version.
2. Installera beroenden (npm install, pnpm install, pip install -r requirements.txt eller motsvarande).
3. Skapa en lokal .env-fil med miljövariablerna, helst med testnycklar. Håll den utanför Git. Vad miljövariabler och hemligheter är förklarar idén.
4. Koppla den till en databas, en lokal Postgres eller en gratis utvecklingsdatabas hos en hanterad leverantör.
5. Kör migreringar, starta sedan appen och klicka igenom de viktigaste flödena.

Allt som går sönder här går också sönder på en värd, och det är mycket enklare att felsöka på din egen maskin. Vanliga överraskningar: en hårdkodad URL till byggarens förhandsvisning, en saknad miljövariabel som byggaren injicerade automatiskt, eller en tjänst (fillagring, bildförminskning) som bara fanns på plattformen.

Steg 3: Flytta datan

Om appen har riktiga användare är datan viktigare än koden.

• Exportera databasen. För Postgres ger pg_dump en fil som du kan återställa med pg_restore eller psql i den nya databasen. Be byggarens AI köra det om du inte har direkt åtkomst, och förklara vad det producerade.
• Flytta uppladdade filer. Om användare laddat upp bilder eller dokument ligger de i objektlagring, separat från databasen. Kopiera dem till din nya lagring (till exempel en S3-kompatibel bucket) och uppdatera de lagrade URL:erna om de innehåller den gamla värden.
• Planera övergången. För en levande app är det enklaste ett kort underhållsfönster: stoppa skrivningar, ta en sista export, återställ den på den nya värden, byt DNS och öppna sedan igen. Skriv ner varje steg i förväg.
• Testa en återställning i en tillfällig databas innan den riktiga flytten.

Om Postgres är nytt för dig ger vad Postgres är grunderna.

Steg 4: Välj var den ska hostas

Anpassa värden efter vad appen är. Namnen nedan är exempel på välkända leverantörer i varje kategori per september 2026, inte en rankning. Kontrollera aktuella funktioner och priser på deras webbplatser.

Du behöver också:

• En hanterad databas. Många apphostar erbjuder Postgres, och dedikerade tjänster som Neon eller Supabase tillhandahåller det fristående. Hanterad är värt det: säkerhetskopior och uppdateringar är någon annans jobb.
• Objektlagring för uppladdningar, om appen har dem.
• Utskick av e-post, betalningar och AI-leverantörer. Dessa behöver oftast bara samma API-nycklar satta på den nya värden.

För att vara rättvis mot avvägningarna: plattformsvärdar (de fyra första raderna) är snabbare att sätta upp och underhålla, men du har mindre kontroll och kostnaderna kan växa med trafiken. En virtuell server är ofta billigare vid jämn last och helt under din kontroll, men du ansvarar för patchning, TLS, säkerhetskopior, övervakning och återställning. Om ingen i teamet vill ha det jobbet, välj en plattform. För grunderna i vad webbhosting innebär, se vad webbhosting är.

Steg 5: Deploya och byt över

1. Koppla repot till värden, eller pusha en containeravbild.
2. Sätt miljövariabler i värdens instrumentpanel: alla från din README, med skarpa värden.
3. Sätt bygg- och startkommandona samt porten. Många värdar skickar porten i miljövariabeln PORT; appen ska lyssna på den och på alla gränssnitt (0.0.0.0), inte bara på localhost.
4. Kör migreringar mot den nya databasen.
5. Testa på värdens tillfälliga URL innan du rör DNS.
6. Uppdatera externa tjänster som pekar på din gamla URL: betalningswebhooks, OAuth-redirect-URL:er för inloggning, länkar i e-post, tillåtna origins.
7. Flytta domänen genom att uppdatera DNS-posterna till den nya värden. Så kopplar du en egen domän förklarar posterna.
8. Håll den gamla driftsättningen igång en stund tills du är säker, och ta sedan ner den.

Steg 6 är det som oftast glöms bort: inloggningar och betalningar som tyst slutar fungera efter en flytt beror oftast på en callback-URL som fortfarande pekar på den gamla värden.

Steg 6: Ta över driften

När du self-hostar blir sådant som byggaren skötte ditt ansvar. Minst: automatiska säkerhetskopior av databasen med en testad återställning, felövervakning, uptime-larm, uppdatering av beroenden och en anteckning om vem som har åtkomst till varje konto. Så tar du en AI-prototyp till produktion går igenom listan mer i detalj.

Checklista för export

• Koden i ett repo du äger, med en README som täcker körning, bygg och miljövariabler
• Appen körs lokalt från en ren klon
• Databasen exporterad och återställning testad; uppladdade filer kopierade
• Värd vald utifrån appens form, plus hanterad databas och lagring
• Alla miljövariabler satta med skarpa värden på den nya värden
• Webhooks, OAuth-redirects och länkar i e-post uppdaterade
• DNS bytt, gammal driftsättning kvar en kort stund och sedan borttagen
• Säkerhetskopior, övervakning och åtkomstlista på plats

Exportera från Mythex

I Mythex äger du koden du bygger. På Pro-planen kan du ladda ner projektet som ett arkiv under Project settings → Export, eller koppla GitHub och pusha och hämta mot ditt eget repo. Free-planer kan visa koden i skrivskyddat läge men inte exportera eller synka den. Hemligheter och node_modules utelämnas i exporter, så återskapa dina hemligheter på den nya värden. Dokumentationen beskriver stegen i exportera och kör någon annanstans och GitHub, export och import. Du kan också fortsätta hosta på Mythex och använda GitHub-synken bara som din egen kopia och överlämningsväg; om du flyttar, avpublicera Mythex-appen när den nya värden är igång.

Frågor