Membuat aplikasi

Waktu

± 3 menit + durasi build

Butuh

Registry lokal (sumber Git) atau image

Hasil

Container berjalan dari branch pilihanmu

Prasyarat

• Untuk aplikasi dari repo Git: registry lokal sudah diaktifkan — image hasil build di-push ke sana. Tanpa ini deploy pertama gagal.
• Sudah ada project tempat aplikasi ini akan tinggal.
• Untuk repo privat: kredensial Git sudah ditambahkan di Settings.
• Aplikasi listen di port yang tetap dan menerima koneksi dari 0.0.0.0, bukan hanya localhost.

Dua sumber aplikasi

Registry lokal hanya wajib untuk sumber Git (tempat image hasil build disimpan). Aplikasi dari image tidak memerlukannya.

Langkah

1. Di halaman project, klik Aplikasi baru

   Isi form. Sebagian besar bisa diubah lagi nanti di tab Pengaturan.

   Field	Keterangan
   Nama	Jadi slug unik (app_name); nama container = aoox-app-<slug>, ditampilkan (dengan tombol salin) di header aplikasi; aplikasi lain di server yang sama mengaksesnya lewat http://aoox-app-<slug>:<port container>.
   Git repository	URL https repo. Tanpa user:token di URL — pakai select Kredensial Git untuk repo privat.
   Branch	Branch yang di-build. Webhook hanya bereaksi pada push ke branch ini.
   Kredensial Git	Tidak ada (repo publik) atau salah satu kredensial tersimpan.
   Cara build	Dockerfile atau Nixpacks — lihat Cara build.
   Port container	Port yang di-listen aplikasi di dalam container (mis. 3000).
   Port host	Opsional. Isi kalau mau akses lewat IP:port tanpa domain. Kosongkan bila memakai domain — blue/green butuh port host kosong.
   Mendengarkan di	Hanya bila ada port host. Publik (default aplikasi) mempublikasikannya di semua interface; Hanya server ini (127.0.0.1) membuatnya hanya bisa dijangkau dari server itu sendiri atau lewat SSH tunnel. Port yang dipublikasikan Docker melewati ufw, jadi untuk yang publik pakai firewall provider (lihat Mulai dari VPS baru). Mengubahnya membuat ulang aplikasi yang berjalan, seperti port host baru. Tidak tersedia untuk service Swarm.
   Health check path	Opsional tapi disarankan, mis. /health. Menentukan sukses/gagal deploy dan mengaktifkan blue/green.
   Server	Host aoox (default) atau server remote. Hanya tampil bila ada server terdaftar.
   Mode deploy	container (default) atau service dengan replika bila Swarm aktif — beserta penempatan node dan setelan rolling update.
   Update otomatis	Hanya untuk sumber image: cek digest tag secara berkala dan deploy saat berubah.
   Batas CPU / memori	Opsional. Lihat Monitoring.

   Contoh pengisian — aplikasi Next.js di repo publik

   Nama

   shop

   Git repository

   https://github.com/acme/shop

   Branch

   main

   Kredensial Git

   Tidak ada (repo publik)

   Cara build

   Nixpacks

   Port container

   3000

   Port host

   (kosong — pakai domain)

   Health check path

   /health

2. Pilih Akses

   Sebelum menyimpan, form meminta cara aplikasi ini akan bisa diakses — supaya aplikasi baru tidak diam-diam tidak bisa dibuka begitu deploy selesai.

   Opsi	Yang terjadi
   IP + port	Port host diisi otomatis (dicek dulu bentrok dengan port aplikasi/database/stack compose/container lain sebelum disimpan) — langsung bisa diakses di http://<ip-server>:<port>.
   Domain	Host + toggle HTTPS langsung ditambahkan saat ini juga, bukan belakangan lewat tab Domain. Kalau reverse proxy belum pernah diaktifkan, ia dinyalakan otomatis — perilaku yang sama dengan set domain panel, lihat Domain untuk panel → Lewat dashboard.
   Nanti saja	Tanpa port maupun domain. Aplikasi tetap ter-deploy, tapi belum bisa diakses sampai salah satunya ditambahkan lewat tab Pengaturan atau Domain.

3. Simpan, lalu isi Environment variables (bila perlu)

   Tab Environment → editor env, satu KEY=VALUE per baris. Nilai diterapkan saat container dibuat, bukan saat build — lihat Environment variables.

4. Buka tab Deploy dan klik Deploy

   Yang terjadi, dan terlihat di log realtime:

   queued    deployment dibuat
   building  daemon Docker clone repo → build image
   pushing   image → registry lokal   (dilewati di server remote)
   starting  container baru dibuat, tunggu healthy
   success   container lama diganti · status aplikasi Running

   Deploy berikutnya menolak (409) selama masih ada deployment aktif. Gagal build/push tidak menyentuh container yang sedang berjalan. Detail di Deploy & rollback.

Verifikasi

• Deployment pertama berakhir success dan badge status aplikasi Running.
• Log container (tab Deploy) menampilkan output aplikasi, mis. Listening on :3000.
• Bila memakai port host: curl http://<ip-server>:<port-host>/ menjawab. Bila memakai domain: lanjut ke Proxy & domain.

Tab di halaman aplikasi

Console

Tab Console membuka docker exec -it ke dalam container aplikasi yang sedang berjalan, langsung dari dashboard — berbeda dari halaman Terminal yang membuka shell di host lewat SSH. Cocok untuk memeriksa file, menjalankan perintah debug, atau mengecek environment tanpa perlu akses SSH ke server.

• Akses: role project developer ke atas (termasuk admin/owner platform) — viewer tidak melihat tab ini sama sekali, dan API menolaknya juga bila dicoba langsung. Token APIread-only juga ditolak.
• Tercatat di audit log — setiap pembukaan sesi console adalah baris tersendiri di Settings → Audit log, dengan siapa dan kapan.
• Mode service (Swarm) dengan lebih dari satu replika: pilih task lewat dropdown yang muncul di atas terminal; hanya task yang berjalan di node ini yang bisa dijangkau.
• Shell yang dipakai: bash bila tersedia di image, kalau tidak sh. Image distroless/tanpa shell sama sekali akan menampilkan pesan error dari Docker sendiri lalu sesi langsung berakhir — bukan bug, memang tidak ada shell untuk dibuka.
• Perubahan di dalam shell ini bersifat sementara: file yang diubah lewat Console hilang saat aplikasi di-redeploy, kecuali disimpan di volume yang di-mount.

Deteksi error di log

Tiap menit, API memindai log container aplikasi yang sedang Running untuk pola error umum (traceback, panic, exception, level=error, dan sejenisnya) dan mengirim notifikasi Error aplikasi kalau ditemukan — lihat Notifikasi untuk detail pola, cooldown, dan cara menyalakannya (nonaktif secara default, per channel).

Untuk aplikasi yang output normalnya memang terlihat seperti error (mis. framework yang verbose), nyalakan Abaikan error di log di tab Pengaturan — aplikasi itu dilewati sepenuhnya dari pemindaian, tidak cuma dibisukan.

Mode perawatan

Tampilkan halaman perawatan kepada pengunjung sebagai ganti aplikasi, tanpa menghentikannya. Ini kartu pertama di tab Pengaturan, bernama Mode perawatan.

• Sakelar Aktif berlaku langsung dan tidak me-restart atau membuat ulang container: yang berubah hanya routing Traefik. Selama aktif, strip status menampilkan lencana Maintenance.
• Setiap permintaan ke semua domain aplikasi mendapat halaman itu dengan HTTP 503 dan Retry-After: 300 (5 menit), sehingga mesin pencari dan monitor melihatnya sebagai gangguan sementara. Termasuk domain HTTPS dengan sertifikat kustom, dan middleware Anda tetap berjalan di depannya.
• Pesan halaman: teks biasa, maksimal 280 karakter, dengan tombol Simpan pesan sendiri; kosongkan untuk teks standar. Selalu ditampilkan sebagai teks, bukan HTML. Halamannya sendiri berbahasa Inggris.
• Deploy saat mode ini aktif tidak menghilangkan halamannya. Domain yang ditambah atau dihapus saat aktif otomatis ikut tercakup atau dilepas. Mematikannya langsung mengembalikan aplikasi.
• Developer ke atas bisa menyalakannya; viewer melihat kartu ini tanpa bisa mengubah.

• Aplikasi di server remote belum didukung: kartu memberi tahu hal ini dan API menolaknya (400).
• Aplikasi tidak bisa dipindah ke server lain saat dalam mode perawatan (409); matikan dulu.
• Ekspor/impor project tidak membawa flag ini, jadi aplikasi hasil impor tidak pernah mulai dalam mode perawatan.

Jebakan umum

Langkah berikutnya