Cara Mengekspor dan Self-Host Aplikasi Buatan AI
Untuk self-host aplikasi buatan AI, ambil kodenya (unduh atau sinkronkan ke repositori GitHub milikmu), buat ulang secret-nya sebagai environment variable, pindahkan atau buat ulang databasenya, lalu deploy ke host yang sesuai dengan jenis aplikasinya: host statis untuk front end sederhana, atau platform yang menjalankan server atau container untuk apa pun yang punya back end. Kodenya biasanya bagian yang paling mudah. Data, secret, dan layanan yang diam-diam dijalankan pembuat aplikasi untukmu adalah tempat pekerjaan yang sebenarnya.
Mengapa perlu mengekspor
Ada alasan bagus untuk membawa kodemu sendiri, dan ada juga alasan yang kurang bagus.
Alasan yang baik:
- Kepemilikan dan perlindungan. Salinan kode di repositori milikmu melindungi kamu jika pembuat aplikasi mengubah harga, fitur, atau syaratnya.
- Serah terima ke developer. Tim engineering akan ingin kode berada di Git, di alat dan proses review yang mereka pakai.
- Kebutuhan khusus. Lokasi penyimpanan data, penyedia cloud tertentu, kebijakan keamanan perusahaan, atau infrastruktur yang tidak ditawarkan pembuat aplikasi.
- Skala atau biaya pada ukuran di mana menjalankan infrastruktur sendiri benar-benar menguntungkan.
Alasan yang kurang baik: memindahkan aplikasi kecil dengan beberapa pengguna hanya untuk menghemat sedikit biaya bulanan. Self-hosting memindahkan pekerjaan kepadamu: pembaruan, cadangan, pemantauan, dan patch keamanan. Itu bisa menjadi pilihan yang tepat; buatlah keputusan itu dengan sadar.
Jalan tengah yang masuk akal: tetap membangun dan meng-host di tempat yang sekarang, tetapi sinkronkan ke repositori GitHub milikmu sejak awal. Kamu mendapat perlindungan tanpa beban operasional. Jika Git masih baru bagimu, baca apa itu GitHub.
Apa yang termasuk dan tidak termasuk dalam ekspor
Sebelum mengandalkan ekspor, buka dan periksa. Biasanya:
| Termasuk | Biasanya tidak termasuk |
|---|---|
| Kode sumber (front end, back end) | Nilai secret (kunci API, kata sandi) |
File konfigurasi (package.json, Dockerfile, konfigurasi build) | Dependensi yang terpasang (node_modules dan sejenisnya) — ini dipasang ulang |
| Skema database dan file migrasi, jika aplikasi memakainya | Data database yang sebenarnya |
| Aset statis dalam proyek | File yang diunggah pengguna di penyimpanan terpisah |
| Layanan yang dikelola pembuat aplikasi: hosting, domain, server database, penyimpanan file |
Secret sengaja tidak disertakan — arsip yang mungkin kamu kirim lewat email atau commit tidak boleh berisi kunci aktif. Dependensi tidak disertakan karena dibangun ulang dari lock file.
Langkah 1: Ambil kodenya
Dua cara yang umum:
- Unduh arsip proyek. Cepat, dan cocok untuk satu kali pindah atau cadangan.
- Sinkronkan ke GitHub. Lebih baik untuk sesuatu yang berkelanjutan: riwayat lengkap, mudah di-clone ke mana saja, dan kebanyakan host men-deploy langsung dari repositori GitHub pada setiap push.
Apa pun caranya, clone atau ekstrak di komputer (atau lingkungan pengembangan cloud) dan cari README. Jika tidak ada, minta AI di pembuat aplikasi untuk menulisnya sebelum kamu pergi:
Tulis README untuk menjalankan proyek ini di luar platform ini: stack, versi runtime yang dibutuhkan, perintah install dan build, perintah start dan port, setiap environment variable yang dibaca kode (nama dan fungsinya, tanpa nilai), dan cara menjalankan migrasi database.
Satu prompt ini menghemat berjam-jam, karena memaksa bagian yang tersirat dalam pengaturan menjadi tertulis.
Langkah 2: Jalankan dulu secara lokal
Sebelum men-deploy ke mana pun, buktikan bahwa aplikasi berjalan sendiri:
- Pasang runtime yang disebut README — Node.js, Python, Java, atau .NET — dengan versi yang sesuai.
- Pasang dependensi (
npm install,pnpm install,pip install -r requirements.txt, atau yang setara). - Buat file
.envlokal dengan environment variable, sebaiknya memakai kunci uji. Jangan masukkan file ini ke Git. Apa itu environment variable dan secret menjelaskan idenya. - Arahkan ke database — Postgres lokal, atau database pengembangan gratis dari penyedia terkelola.
- Jalankan migrasi, lalu jalankan aplikasi dan coba alur utamanya.
Apa pun yang rusak di sini akan rusak juga di host, dan jauh lebih mudah di-debug di mesin sendiri. Kejutan yang umum: URL pratinjau pembuat aplikasi yang tertanam langsung di kode, environment variable yang disuntikkan otomatis oleh pembuat aplikasi dan terlewat, atau layanan (penyimpanan file, pengubahan ukuran gambar) yang hanya ada di platform.
Langkah 3: Pindahkan datanya
Jika aplikasi punya pengguna sungguhan, data lebih penting daripada kode.
- Ekspor database. Untuk Postgres,
pg_dumpmenghasilkan file yang bisa dipulihkan denganpg_restoreataupsqlke database baru. Minta AI di pembuat aplikasi untuk menjalankannya jika kamu tidak punya akses langsung, dan minta penjelasan tentang apa yang dihasilkannya. - Pindahkan file yang diunggah. Jika pengguna mengunggah gambar atau dokumen, file itu tersimpan di penyimpanan objek yang terpisah dari database. Salin ke penyimpanan barumu (misalnya bucket yang kompatibel dengan S3) dan perbarui URL tersimpan jika menyertakan host lama.
- Rencanakan peralihan. Untuk aplikasi yang sedang aktif, pendekatannya sederhana: jeda penulisan data, ambil ekspor terakhir, pulihkan di host baru, ganti DNS, lalu buka kembali. Tuliskan setiap langkah terlebih dulu.
- Uji pemulihan ke database sementara sebelum pemindahan sungguhan.
Jika Postgres masih asing bagimu, apa itu Postgres membahas dasarnya.
Langkah 4: Pilih tempat hosting
Sesuaikan host dengan jenis aplikasinya. Nama-nama di bawah ini hanyalah contoh penyedia terkenal di setiap kategori per September 2026, bukan peringkat; periksa fitur dan harga terbaru di situs mereka.
| Bentuk aplikasi | Yang dibutuhkan | Contoh host |
|---|---|---|
| Situs statis atau SPA (hanya HTML, CSS, JS) | Hosting file dengan CDN | Netlify, Vercel, Cloudflare Pages, GitHub Pages |
| Framework full-stack (Next.js dan sejenisnya) | Server atau fungsi serverless | Vercel, Netlify, Render, Railway |
| API atau back end (Node, Python, Java, C#) | Server yang selalu aktif atau skala-ke-nol | Render, Railway, Fly.io, layanan container cloud |
| Apa pun dengan Dockerfile | Runtime container | Fly.io, Render, Railway, AWS, Google Cloud, Azure |
| Kendali penuh | Server virtual yang kamu kelola | DigitalOcean, Hetzner, Linode, atau VM cloud apa pun |
Kamu juga akan membutuhkan:
- Database terkelola — banyak host aplikasi menawarkan Postgres, dan layanan khusus seperti Neon atau Supabase menyediakannya secara mandiri. Terkelola sepadan: cadangan dan pembaruan menjadi tanggung jawab penyedia.
- Penyimpanan objek untuk unggahan, jika aplikasi punya fitur itu.
- Pengiriman email, pembayaran, dan penyedia AI — biasanya hanya perlu kunci API yang sama diatur di host baru.
Adil terhadap trade-off: host platform (empat baris pertama) lebih cepat disiapkan dan dipelihara, tetapi kendali kamu lebih sedikit dan biaya bisa naik seiring trafik. Server virtual sering lebih murah pada beban yang stabil dan sepenuhnya di bawah kendalimu, tetapi kamu yang bertanggung jawab atas patch, TLS, cadangan, pemantauan, dan pemulihan. Jika tidak ada orang di tim yang mau mengerjakan itu, pilih platform. Untuk dasar-dasar hosting web, lihat apa itu web hosting.
Langkah 5: Deploy dan pindah
- Hubungkan repositori ke host, atau dorong image container.
- Atur environment variable di dashboard host — semua yang ada di README dengan nilai yang sebenarnya.
- Atur perintah build dan start serta port. Banyak host mengirim port lewat environment variable
PORT; aplikasi harus mendengarkan di sana dan di semua antarmuka (0.0.0.0), bukan hanyalocalhost. - Jalankan migrasi ke database baru.
- Uji di URL sementara host sebelum menyentuh DNS.
- Perbarui layanan eksternal yang mengarah ke URL lama: webhook pembayaran, URL redirect OAuth untuk login, tautan di email, origin yang diizinkan.
- Pindahkan domain dengan memperbarui record DNS ke host baru. Cara menghubungkan domain kustom menjelaskan record-recordnya.
- Biarkan deployment lama berjalan sebentar sampai kamu yakin, lalu matikan.
Langkah 6 adalah yang paling sering terlupakan: login dan pembayaran yang diam-diam gagal setelah pindah biasanya disebabkan oleh URL callback yang masih mengarah ke host lama.
Langkah 6: Ambil alih operasionalnya
Setelah self-hosting, hal-hal yang dulu ditangani pembuat aplikasi menjadi tanggung jawabmu. Minimal: cadangan database otomatis dengan pemulihan yang sudah diuji, pelacakan error, peringatan uptime, pembaruan dependensi, dan catatan siapa saja yang punya akses ke setiap akun. Cara membawa prototipe AI ke produksi membahas daftar ini lebih rinci.
Checklist ekspor
- Kode ada di repositori milikmu, dengan README yang mencakup cara menjalankan, build, dan env var
- Aplikasi berjalan secara lokal dari clone yang bersih
- Database sudah diekspor dan pemulihannya sudah diuji; file yang diunggah sudah disalin
- Host dipilih sesuai bentuk aplikasi, ditambah database terkelola dan penyimpanan
- Semua environment variable diatur dengan nilai asli di host baru
- Webhook, redirect OAuth, dan tautan email sudah diperbarui
- DNS sudah dipindahkan, deployment lama dibiarkan sebentar, lalu dihapus
- Cadangan, pemantauan, dan daftar akses sudah tersedia
Mengekspor dari Mythex
Di Mythex, kamu memiliki kode yang kamu bangun. Di paket Pro, kamu bisa mengunduh proyek sebagai arsip dari Pengaturan proyek → Ekspor, atau menghubungkan GitHub dan mendorong serta menarik perubahan dari repositorimu sendiri. Paket Free dapat melihat kode secara read-only, tetapi tidak bisa mengekspor atau menyinkronkan. Secret dan node_modules tidak disertakan dalam ekspor, jadi buat ulang secret-mu di host baru. Dokumentasi membahas langkahnya di ekspor dan jalankan di tempat lain dan GitHub, ekspor, dan impor. Kamu juga bisa tetap meng-host di Mythex dan memakai sinkronisasi GitHub sebagai salinan milikmu sendiri serta jalur serah terima; jika kamu benar-benar pindah, hapus publikasi aplikasi Mythex setelah host baru berjalan.
Pertanyaan
Bisakah saya mengekspor kode dari pembuat aplikasi AI?
Itu tergantung alat dan paket langganannya. Beberapa pembuat aplikasi memungkinkan kamu mengunduh seluruh proyek atau menyinkronkannya ke repositori GitHub milikmu; yang lain menyimpan aplikasi di dalam platform mereka. Periksa dulu sebelum menghabiskan berbulan-bulan, dan baca apa saja yang termasuk dan tidak termasuk dalam ekspor.
Apakah ekspor menyertakan database dan kunci API saya?
Biasanya kode diekspor tetapi data dan secret tidak. Kunci rahasia umumnya sengaja tidak disertakan, dan isi database perlu diekspor secara terpisah, misalnya dengan pg_dump untuk Postgres. Rencanakan keduanya sebelum berpindah hosting.
Di mana sebaiknya saya meng-host aplikasi yang diekspor?
Front end statis cocok di host statis seperti Netlify, Vercel, atau Cloudflare Pages. Aplikasi yang punya server sendiri membutuhkan platform yang menjalankan kode atau container, seperti Render, Railway, atau Fly.io, atau server virtual yang kamu kelola sendiri. Kamu juga akan membutuhkan database terkelola jika aplikasinya memakai database.
Apakah self-hosting lebih murah daripada tetap di pembuat aplikasi?
Kadang-kadang, pada skala besar. Untuk aplikasi kecil, selisihnya sering kecil setelah kamu menghitung database, email, pemantauan, dan waktumu sendiri untuk pemeliharaan. Pindah demi kendali atau kebutuhan tertentu, bukan hanya untuk menghemat beberapa dolar per bulan.