Panduan

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:

TermasukBiasanya 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 memakainyaData database yang sebenarnya
Aset statis dalam proyekFile 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:

  1. Pasang runtime yang disebut README — Node.js, Python, Java, atau .NET — dengan versi yang sesuai.
  2. Pasang dependensi (npm install, pnpm install, pip install -r requirements.txt, atau yang setara).
  3. Buat file .env lokal dengan environment variable, sebaiknya memakai kunci uji. Jangan masukkan file ini ke Git. Apa itu environment variable dan secret menjelaskan idenya.
  4. Arahkan ke database — Postgres lokal, atau database pengembangan gratis dari penyedia terkelola.
  5. 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_dump menghasilkan file yang bisa dipulihkan dengan pg_restore atau psql ke 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 aplikasiYang dibutuhkanContoh host
Situs statis atau SPA (hanya HTML, CSS, JS)Hosting file dengan CDNNetlify, Vercel, Cloudflare Pages, GitHub Pages
Framework full-stack (Next.js dan sejenisnya)Server atau fungsi serverlessVercel, Netlify, Render, Railway
API atau back end (Node, Python, Java, C#)Server yang selalu aktif atau skala-ke-nolRender, Railway, Fly.io, layanan container cloud
Apa pun dengan DockerfileRuntime containerFly.io, Render, Railway, AWS, Google Cloud, Azure
Kendali penuhServer virtual yang kamu kelolaDigitalOcean, 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

  1. Hubungkan repositori ke host, atau dorong image container.
  2. Atur environment variable di dashboard host — semua yang ada di README dengan nilai yang sebenarnya.
  3. 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 hanya localhost.
  4. Jalankan migrasi ke database baru.
  5. Uji di URL sementara host sebelum menyentuh DNS.
  6. Perbarui layanan eksternal yang mengarah ke URL lama: webhook pembayaran, URL redirect OAuth untuk login, tautan di email, origin yang diizinkan.
  7. Pindahkan domain dengan memperbarui record DNS ke host baru. Cara menghubungkan domain kustom menjelaskan record-recordnya.
  8. 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.

Mythex · Pricing · Bangun apa pun dengan AI · Template website dan aplikasi · Mythex dibandingkan · Glosarium membuat aplikasi dengan AI · Alat gratis untuk membuat aplikasi dengan AI · English

English አማርኛ العربية Български বাংলা Bosanski Català Čeština Dansk Deutsch Ελληνικά Español Español (España) Eesti فارسی Suomi Français Français (Canada) ગુજરાતી हिन्दी Hrvatski Magyar Հայերեն Íslenska Italiano 日本語 ქართული Қазақ тілі ಕನ್ನಡ 한국어 Lietuvių Latviešu Македонски മലയാളം Монгол मराठी Bahasa Melayu မြန်မာ Norsk bokmål Nederlands ਪੰਜਾਬੀ Polski Português (Brasil) Português (Portugal) Română Русский Slovenčina Slovenščina Soomaali Shqip Srpski Svenska Kiswahili தமிழ் తెలుగు ไทย Tagalog Türkçe Українська اردو Tiếng Việt 简体中文 繁體中文(香港) 繁體中文(台灣)