Paano I-export at I-self-host ang App na Ginawa ng AI

Para i-self-host ang app na ginawa ng AI, kunin ang code (i-download o i-sync sa GitHub repository na sa iyo), gawing environment variables ang mga secret, ilipat o gumawa muli ng database, at i-deploy ito sa host na bagay sa uri ng app: static host para sa simpleng front end, o platform na nagpapatakbo ng server o containers para sa anumang may back end. Kadalasang madali ang code. Ang data, mga secret, at ang mga serbisyong tahimik na pinatatakbo ng builder para sa iyo ang tunay na trabaho.

Bakit mag-export pa

May magagandang dahilan para dalhin ang code mo, at may ilang hindi gaanong maganda.

Magagandang dahilan:

• Pagmamay-ari at seguro. Ang kopya ng code sa sarili mong repository ay nagpoprotekta sa iyo kung babaguhin ng builder ang presyo, features o terms.
• Pagpasa sa developers. Gugustuhin ng isang engineering team na nasa Git ang code, sa mga tool at proseso ng review na nakasanayan nila.
• Partikular na pangangailangan. Data residency, partikular na cloud provider, patakaran sa seguridad ng kumpanya, o imprastrukturang hindi inaalok ng builder.
• Sukat o gastos kung saan talagang sulit ang sariling imprastraktura.

Hindi gaanong magagandang dahilan: ang paglipat ng maliit na app na may iilang user para makatipid ng maliit na buwanang halaga. Inililipat ng self-hosting ang trabaho sa iyo: updates, backups, monitoring, security patches. Maaaring tamang trade-off iyon; gawin lang ito nang may kamalayan.

Isang makatuwirang gitna: ituloy ang paggawa at pag-host kung nasaan ka, pero i-sync sa sarili mong GitHub repository mula sa simula. Makukuha mo ang seguro nang hindi dinadala ang operational na trabaho. Kung bago pa sa iyo ang Git, basahin ang ano ang GitHub.

Ano ang kasama at hindi kasama sa export

Bago umasa sa export, buksan ito at suriin. Karaniwan:

Sinadyang hindi isinasama ang mga secret: hindi dapat maglaman ng live keys ang archive na maaaring i-email o i-commit. Hindi isinasama ang dependencies dahil muling binubuo ang mga ito mula sa lock file.

Hakbang 1: Kunin ang code

Dalawang karaniwang paraan:

• Mag-download ng archive ng project. Mabilis, at angkop para sa isang beses na paglipat o backup.
• I-sync sa GitHub. Mas mabuti para sa anumang tuloy-tuloy: kumpletong history, madaling i-clone kahit saan, at karamihan ng hosts ay nagde-deploy direkta mula sa GitHub repository sa bawat push.

Alinman, i-clone o i-unpack ito sa computer (o cloud dev environment) at hanapin ang README. Kung wala, humingi sa AI sa builder na sumulat nito bago ka umalis:

Sumulat ng README para sa pagpapatakbo ng project na ito sa labas ng platform na ito: ang stack, kinakailangang bersyon ng runtime, install at build commands, start command at port, bawat environment variable na binabasa ng code (mga pangalan at layunin, walang halaga), at kung paano pinapatakbo ang database migrations.

Isang prompt lang ito pero nakakatipid ng maraming oras, dahil pinipilit nitong isulat ang mga hindi nakasaad na bahagi ng setup.

Hakbang 2: Patakbuhin muna nang lokal

Bago mag-deploy kahit saan, patunayang kaya ng app na tumakbo mag-isa:

1. I-install ang runtime na binabanggit ng README (Node.js, Python, Java, .NET) sa tugmang bersyon.
2. I-install ang dependencies (npm install, pnpm install, pip install -r requirements.txt, o katumbas nito).
3. Gumawa ng lokal na .env file na may environment variables, gamit ang test keys hangga't maaari. Huwag itong isama sa Git. Ipinapaliwanag ng ano ang environment variables at secrets ang ideya.
4. Ituro sa database: lokal na Postgres, o libreng development database mula sa managed provider.
5. Patakbuhin ang migrations, pagkatapos simulan ang app at subukan ang mga pangunahing daloy.

Anumang masisira rito ay masisira rin sa host, at mas madaling i-debug sa sarili mong makina. Mga karaniwang sorpresa: isang naka-hard-code na URL ng preview ng builder, isang nawawalang environment variable na awtomatikong inilagay ng builder, o serbisyong (file storage, image resizing) na umiral lang sa platform.

Hakbang 3: Ilipat ang data

Kung may totoong users ang app, mas mahalaga ang data kaysa code.

• I-export ang database. Para sa Postgres, gumagawa ang pg_dump ng file na maibabalik gamit ang pg_restore o psql sa bagong database. Humingi sa AI ng builder na patakbuhin ito kung wala kang direktang access, at ipaliwanag kung ano ang nagawa nito.
• Ilipat ang na-upload na files. Kung nag-upload ng larawan o dokumento ang users, nasa object storage ang mga ito na hiwalay sa database. Kopyahin sa bagong storage mo (halimbawa isang S3-compatible bucket) at i-update ang mga naka-imbak na URL kung kasama ang lumang host.
• Planuhin ang cut-over. Para sa live na app, ang simpleng paraan ay maikling maintenance window: itigil ang pagsusulat, kumuha ng huling export, ibalik ito sa bagong host, ilipat ang DNS, at buksan muli. Isulat muna ang bawat hakbang.
• Subukan ang restore sa scratch database bago ang totoong paglipat.

Kung bago pa sa iyo ang Postgres, sakop ng ano ang Postgres ang mga batayan.

Hakbang 4: Piliin kung saan i-host

Ipares ang host sa uri ng app. Ang mga pangalan sa ibaba ay mga halimbawa ng kilalang provider sa bawat kategorya noong Setyembre 2026, hindi ranggo; i-check ang kasalukuyang features at presyo sa kanilang mga site.

Kakailanganin mo rin ang:

• Managed database: maraming app host ang nag-aalok ng Postgres, at may mga dedicated na serbisyo gaya ng Neon o Supabase na nagbibigay nito nang mag-isa. Sulit ang managed: backups at updates ay trabaho ng iba.
• Object storage para sa uploads, kung may uploads ang app.
• Pagpapadala ng email, payments at AI providers: kadalasan kailangan lang ang parehong API keys na nakatakda sa bagong host.

Patas na trade-offs: ang platform hosts (unang apat na hanay) ay mas mabilis i-setup at i-maintain, pero mas kaunti ang kontrol mo at maaaring tumaas ang gastos kapag dumami ang traffic. Kadalasang mas mura ang virtual server sa tuloy-tuloy na load at buo ang kontrol mo, pero ikaw ang may-ari ng patching, TLS, backups, monitoring at recovery. Kung walang gustong gumawa ng trabahong iyon sa team, pumili ng platform. Para sa mga batayan ng hosting, tingnan ang ano ang web hosting.

Hakbang 5: Mag-deploy at lumipat

1. Ikonekta ang repository sa host, o mag-push ng container image.
2. Itakda ang environment variables sa dashboard ng host. Lahat ng nasa README mo, na may live na halaga.
3. Itakda ang build at start commands at ang port. Maraming host ang nagpapasa ng port sa PORT environment variable; dapat makinig ang app dito at sa lahat ng interface (0.0.0.0), hindi lang sa localhost.
4. Patakbuhin ang migrations laban sa bagong database.
5. Subukan sa pansamantalang URL ng host bago galawin ang DNS.
6. I-update ang mga external service na tumuturo sa lumang URL mo: payment webhooks, OAuth redirect URLs para sa login, email links, allowed origins.
7. Ilipat ang domain sa pamamagitan ng pag-update ng DNS records papunta sa bagong host. Ipinapaliwanag ng paano ikonekta ang custom domain ang mga record.
8. Panatilihing tumatakbo ang lumang deployment nang sandali hanggang sigurado ka, saka ito patayin.

Ang Hakbang 6 ang madalas makalimutan: ang login at payments na tahimik na pumapalya pagkatapos ng paglipat ay kadalasang nagmumula sa callback URL na nakaturo pa rin sa lumang host.

Hakbang 6: Akuin ang operasyon

Kapag na-self-host mo na, ikaw na ang hahawak ng mga bagay na dati ay inaasikaso ng builder. Hindi bababa sa: awtomatikong database backups na may nasubukang restore, error tracking, uptime alerts, dependency updates, at talaan ng sino ang may access sa bawat account. Sinasaklaw ng paano dalhin sa production ang AI prototype ang listahang ito nang mas detalyado.

Checklist ng export

• Code sa repository na sa iyo, may README na sumasaklaw sa run, build at env vars
• Tumatakbo ang app nang lokal mula sa malinis na clone
• Na-export ang database at nasubukan ang restore; nakopya ang mga na-upload na file
• Napili ang host para sa uri ng app, kasama ang managed database at storage
• Nakatakda ang lahat ng environment variables na may live na halaga sa bagong host
• Na-update ang webhooks, OAuth redirects at email links
• Nailipat ang DNS, nanatili nang sandali ang lumang deployment, saka inalis
• Nakalagay ang backups, monitoring at listahan ng access

Pag-export mula sa Mythex

Sa Mythex, pagmamay-ari mo ang code na binubuo mo. Sa Pro plan, maaari mong i-download ang project bilang archive mula sa Project settings → Export, o ikonekta ang GitHub at mag-push at mag-pull sa sarili mong repository. Sa Free plans, makikita ang code nang read-only pero hindi ito maaaring i-export o i-sync. Hindi kasama sa export ang secrets at node_modules, kaya ilagay muli ang secrets sa bagong host. Sakop ng docs ang mga hakbang sa export at pagpapatakbo sa iba at GitHub, export at import. Maaari ka ring manatili sa pag-host sa Mythex at gamitin ang GitHub sync bilang sarili mong kopya at ruta ng pagpasa; kung lilipat ka, i-unpublish ang Mythex app kapag live na ang bagong host.

Mga tanong