FAQ

Pertanyaan yang sering diajukan

Panduan singkat praktis untuk pengaturan layanan, akses, dan tindakan umum pelanggan.

> Membuat kunci SSH publik di terminal

Buat kunci SSH publik untuk akses dan bagikan hanya bagian publiknya.
faq/generate-public-ssh-key-id

Gunakan hanya kunci publik

SSH memakai pasangan kunci. Tempelkan hanya kunci publik, biasanya file .pub, ke pengaturan layanan. Kunci privat tetap berada di perangkat Anda.

Langkah di terminal

  1. Buka Terminal, Windows Terminal, atau PowerShell.
  2. Jalankan: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Terima lokasi bawaan atau pilih jalur yang aman.
  4. Tampilkan kunci publik dengan: cat ~/.ssh/id_ed25519.pub.
  5. Di Windows PowerShell gunakan: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Salin seluruh baris ssh-ed25519 ke kolom SSH public key.

Periksa sebelum menempel

Jangan menyalin kunci privat. Jika membuat passphrase, simpan dengan aman untuk penggunaan nanti.

> Membuat kunci SSH lewat GUI Windows

Gunakan PuTTYgen di Windows dan salin hanya kunci publik.
faq/create-ssh-key-windows-gui-id

Cukup bagian publik

PuTTYgen membuat kunci publik dan privat. Tambahkan hanya kunci publik ke Cli>_ dan simpan kunci privat secara lokal.

Langkah di Windows

  1. Buka PuTTYgen.
  2. Pilih EdDSA / Ed25519 jika tersedia.
  3. Gunakan RSA 4096 hanya sebagai cadangan.
  4. Klik Generate dan gerakkan mouse sampai kunci dibuat.
  5. Simpan kunci privat di komputer Anda.
  6. Salin teks kunci publik ke kolom SSH public key.

Jangan bagikan data rahasia

Jangan kirim file .ppk, kunci privat, passphrase, kata sandi, atau token ke dukungan maupun formulir.

> Hubungkan domain sendiri

Periksa DNS otoritatif, hostname persis, tipe record, apex atau subdomain, dan konflik record lama sebelum berpindah.
faq/hubungkan-domain-sendiri

Hostname persis menentukan record

Apex seperti example.com dan subdomain seperti app.example.com dapat membutuhkan record berbeda. Pastikan tempat edit DNS adalah nameserver otoritatif atau registrar yang benar.

Sebelum mengubah DNS

  1. Pilih hostname persis yang akan dipakai.
  2. Hapus atau ubah A/AAAA, CNAME, ALIAS, ANAME, atau redirect yang konflik.
  3. Gunakan tipe record yang direkomendasikan layanan dan didukung penyedia DNS.
  4. Tunggu propagasi DNS sebelum menguji HTTPS final.

Rollback aman

Jangan matikan hosting lama sebelum hostname baru menjawab benar. Untuk diagnosis, kirim domain, target yang diharapkan, dan hasil DNS publik, bukan akses registrar.

> Delegasikan zona DNS

A/AAAA menunjuk alamat, CNAME alias, MX email, TXT verifikasi dan kebijakan mail, CAA otoritas sertifikat.
faq/delegasikan-zona-dns

Setiap tipe punya fungsi

A dan AAAA menunjuk IP, CNAME membuat alias subdomain, MX mengarahkan email, TXT membawa verifikasi serta SPF/DKIM/DMARC, dan CAA membatasi penerbit sertifikat.

Saat menyalin record

  1. Salin name, type, dan value persis seperti instruksi.
  2. Jangan menaruh CNAME pada hostname yang sudah punya record lain jika aturan DNS melarang.
  3. Letakkan DKIM di selector penyedia dan DMARC di _dmarc.
  4. Ubah CAA dengan hati-hati karena nilai salah bisa memblokir sertifikat.

Jika DNS tidak bekerja

Kirim hostname, tipe record, nilai yang diharapkan, dan hasil publik yang terlihat. Jangan kirim login DNS atau screenshot yang menampilkan API token.

> Pendaftaran akun dan login pertama

Gunakan satu akun kerja untuk pesanan, penagihan, layanan, domain, dan komunikasi dukungan.
faq/account-registration-and-login

Satu identitas kerja untuk tim

Daftarkan akun dengan alamat email kerja yang tetap dapat diakses tim. Akun ini menjadi tempat untuk melihat pesanan, data penagihan, layanan aktif, domain, dan percakapan dukungan.

Sebelum membuat pesanan pertama

  1. Selesaikan verifikasi email jika diminta.
  2. Isi data penagihan sebelum memesan layanan berbayar.
  3. Pilih email yang tidak bergantung pada satu orang saja.
  4. Aktifkan autentikasi dua faktor saat tersedia.

Akses tim tanpa membocorkan login

Jangan mengirim kata sandi melalui chat atau email. Jika beberapa orang perlu akses, gunakan password manager internal atau minta prosedur tim yang aman; dukungan tidak memerlukan kata sandi atau token login.

> Cara kerja kredit prabayar

Kredit menunjukkan saldo, perkiraan masa pakai, biaya harian layanan aktif, dan risiko suspensi atau batas waktu penghapusan.
faq/prepaid-credit-how-it-works

Saldo berkurang saat layanan berjalan

Layanan yang memenuhi syarat memakai kredit prabayar selama aktif. Saldo, estimasi runway, dan biaya harian membantu memperkirakan kapan perlu top up agar layanan tidak tersuspensi.

Menghindari kehabisan kredit

  1. Pantau saldo dan estimasi hari tersisa setelah login.
  2. Periksa biaya harian sebelum mengonfirmasi pesanan atau perubahan.
  3. Top up sebelum saldo mendekati nol.
  4. Jika layanan tersuspensi, baca batas waktu penghapusan yang ditampilkan.

Pertanyaan tentang saldo

Kirim nomor pesanan, nama layanan, dan periode yang ingin diperiksa. Jangan kirim data kartu, kata sandi, kunci privat, atau mutasi pembayaran lengkap yang berisi informasi sensitif.

> Estimasi bulanan, tahunan, dan pemakaian kredit harian

Harga bulanan dan tahunan adalah pembanding; layanan prabayar memakai kredit harian setelah perubahan dikonfirmasi dan diterapkan.
faq/billing-periods-and-credit-burn

Angka perbandingan bukan kalender tagihan

Estimasi bulanan memakai 31 hari dan estimasi tahunan memakai 372 hari. Kredit prabayar benar-benar berkurang sesuai waktu aktif, CPU, RAM, storage, dan opsi berbayar yang sudah diterapkan.

Saat harga berubah

  1. Bandingkan biaya harian sebelum dan sesudah perubahan.
  2. Ingat bahwa CPU, RAM, disk, backup, dan Offsite Archive dapat mengubah biaya.
  3. Anggap perubahan berlaku setelah dikonfirmasi, dibayar bila perlu, dan diterapkan.
  4. Simpan konfirmasi pesanan dan riwayat kredit untuk pembukuan.

Memeriksa periode tertentu

Untuk sengketa atau pertanyaan, sebutkan nomor pesanan, nama layanan, dan tanggal yang ingin dihitung. Jangan mengirim detail bank lengkap atau screenshot yang belum disamarkan.

> Status pesanan setelah pembayaran

Pesanan bisa menunggu konfirmasi penyedia pembayaran; jangan membuat duplikat sebelum pesanan pertama jelas gagal atau kedaluwarsa.
faq/order-status-and-payment-confirmation

Pending belum tentu gagal

Setelah pembayaran selesai, pesanan mungkin masih menunggu notifikasi dari penyedia pembayaran. Pesanan duplikat dapat menyulitkan pencocokan jika pembayaran pertama akhirnya terkonfirmasi.

Setelah menyelesaikan pembayaran

  1. Kembali ke Cli>_ dari halaman penyedia pembayaran.
  2. Periksa status pesanan di akun.
  3. Tunggu konfirmasi jika status masih pending.
  4. Hubungi dukungan dengan nomor pesanan dan referensi pembayaran bila tersedia.

Bukti yang aman

Dukungan cukup membutuhkan nomor pesanan, waktu pembayaran, status yang terlihat, dan screenshot tersamarkan jika ada error. Jangan kirim nomor kartu, kata sandi, atau bukti bank lengkap.

> Informasi yang mempercepat penyiapan layanan

Siapkan nama layanan, domain, DNS, ukuran storage, resource, email admin, dan public SSH key tanpa mengirim rahasia.
faq/service-setup-information-needed

Nilai yang presisi mengurangi penundaan

Formulir pesanan biasanya meminta nama layanan, domain, rencana DNS, storage, CPU, RAM, email admin, atau public SSH key. Masukkan hanya nilai publik atau non-rahasia.

Checklist sebelum checkout

  1. Pilih nama layanan yang mudah dikenali tim.
  2. Tentukan domain sendiri atau hostname sementara.
  3. Siapkan public SSH key jika layanan memerlukannya.
  4. Periksa kebutuhan storage dan resource aplikasi.

Data rahasia tidak masuk formulir

Private key, kata sandi, token, dump database, dan file konfigurasi penuh tidak boleh dikirim lewat pesanan atau chat. Jika ragu, tanyakan tanpa melampirkan nilainya.

> Mengubah CPU, RAM, disk, atau retensi setelah pesanan

Ubah layanan yang sudah ada dari detail layanan; periksa harga baru, biaya harian, waktu penerapan, restart, downtime, dan kebutuhan ekspor.
faq/change-service-resources-after-order

Jangan membuat layanan duplikat

Jika layanan sudah berjalan, lakukan perubahan dari halaman layanan tersebut. Pesanan baru dapat membuat layanan lain, bukan memperbarui yang sudah ada.

Sebelum mengonfirmasi perubahan

  1. Catat CPU, RAM, disk, backup retention, dan Offsite Archive retention saat ini.
  2. Periksa harga baru dan biaya kredit harian.
  3. Baca peringatan restart, maintenance, atau downtime.
  4. Ekspor data penting sebelum perubahan berisiko.

Jika perubahan bermasalah

Kirim nama layanan, waktu perubahan, status yang terlihat, dan pesan error. Jangan kirim private key, kata sandi, token, atau file konfigurasi rahasia.

> Membatalkan layanan dan retensi data

Layanan yang sudah aktif biasanya disuspensi dulu, menampilkan batas waktu penghapusan, lalu dapat dihapus permanen.
faq/cancel-service-and-data-retention

Pembatalan tidak selalu langsung menghapus semua data

Layanan yang sudah berjalan biasanya disuspensi terlebih dahulu dan menampilkan batas waktu penghapusan. Setelah batas waktu itu lewat, data dapat dihapus permanen.

Sebelum membatalkan layanan

  1. Buat ekspor sendiri untuk data yang perlu disimpan.
  2. Baca tanggal dan waktu penghapusan yang terlihat.
  3. Jangan menyamakan backup dan Offsite Archive dengan masa retensi layanan yang dibatalkan.
  4. Hubungi dukungan sebelum batas waktu jika masih ragu.

Setelah batas waktu

Setelah deadline terlihat berlalu, jangan menganggap data masih dapat dipulihkan. Untuk pertanyaan, berikan nomor pesanan dan nama layanan, bukan dump database atau kredensial.

> Backup dan permintaan restore

Backup untuk pemulihan operasional, bukan pengganti ekspor; restore dapat menimpa data yang lebih baru.
faq/backups-and-restore-requests

Backup bukan arsip bisnis

Retensi backup tergantung produk dan opsi. Backup membantu pemulihan operasional, tetapi tidak menggantikan ekspor mandiri atau Offsite Archive.

Menyusun permintaan restore

  1. Sebutkan nama layanan dan nomor pesanan.
  2. Berikan perkiraan waktu kondisi yang ingin dipulihkan.
  3. Jelaskan apakah perlu seluruh layanan atau bagian tertentu bila didukung.
  4. Lampirkan error yang terlihat tanpa kata sandi, token, atau private key.

Dampak restore

Restore dapat mengganti data baru dengan keadaan lama. Beri tahu tim dan ekspor data penting sebelum menyetujui pemulihan.

> Fungsi Offsite Archive

Offsite Archive menyimpan salinan arsip jarak jauh, terpisah dari backup operasional singkat dan lifecycle penghapusan layanan.
faq/offsite-archive-purpose

Arsip terpisah dari aplikasi aktif

Offsite Archive ditujukan untuk salinan arsip jarak jauh. Ini bukan disk live aplikasi, bukan pengganti ekspor lokal, dan bukan backup operasional jangka pendek.

Kapan mengaktifkannya

  1. Gunakan untuk data yang perlu disimpan di luar operasi harian.
  2. Pilih hari retensi sesuai kebutuhan recovery atau compliance.
  3. Perkirakan biaya dari volume data dan lama penyimpanan.
  4. Rencanakan arsip besar bersama proses ekspor sendiri.

Memperkirakan biaya arsip

Biaya dipengaruhi oleh volume data yang disimpan dan lamanya retensi. Periksa estimasi yang ditampilkan sebelum mengaktifkan atau memperpanjang arsip.

> Memilih CPU, RAM, dan disk untuk VPS

Ukuran VPS ditentukan oleh aplikasi, database, cache, log, upload, dan pertumbuhan; OOM atau swap berat menandakan RAM kurang.
faq/vps-cpu-ram-and-disk-sizing

Mulai dari profil beban nyata

Website statis kecil berbeda dari database, aplikasi Java, pencarian, atau container build. Hitung memori aplikasi, cache, database, log, upload, dan ruang pertumbuhan.

Tanda paket terlalu kecil

  1. Tambah RAM jika ada OOM, out of memory, process killed, atau swap terus-menerus.
  2. Tambah CPU untuk kompresi, build, worker sibuk, atau beban komputasi stabil.
  3. Tambah disk sebelum filesystem, log, atau database penuh.
  4. Pantau aplikasi setelah perubahan untuk memastikan batas lama tidak terulang.

Data untuk pertanyaan sizing

Kirim nama layanan, jenis aplikasi, error yang terlihat, waktu kejadian, serta CPU, RAM, dan disk yang dipilih. Jangan kirim kata sandi, private key, atau file konfigurasi internal.

> Kapan VPS membutuhkan public IP

Dedicated public IP berguna untuk allowlist, akses inbound, sumber outbound stabil, atau layanan yang terikat alamat.
faq/vps-public-ip-options

Tentukan arah koneksi

Public IP tidak wajib untuk semua layanan. Biasanya dibutuhkan saat partner, penyedia, atau firewall eksternal meminta alamat stabil untuk inbound, outbound source, atau keduanya.

Sebelum memesan IP

  1. Tanyakan apakah allowlist berlaku inbound, outbound, atau dua arah.
  2. Gunakan nama DNS jika sistem eksternal mengizinkan.
  3. Buka hanya port aplikasi yang benar-benar perlu.
  4. Kirim kebutuhan allowlist sebelum mengubah akses produksi.

IP publik bukan semua port terbuka

Dedicated public IP tetap harus dipakai dengan aturan minimal. Jangan mengirim kata sandi, private key, atau screenshot firewall yang berisi nilai rahasia.

> Akses SSH bersama untuk VPS

Tanpa public IP tambahan, VPS memakai endpoint SSH bersama dengan port tinggi; dengan dedicated public IP, gunakan endpoint langsung hanya jika layanan menampilkannya.
faq/shared-ssh-access-for-vps

Alasan port tinggi pada SSH bersama

Beberapa VPS dapat berbagi endpoint SSH publik yang sama. Setiap layanan mendapatkan port tinggi sendiri agar koneksi dapat diarahkan ke VPS yang benar.

Pilih endpoint SSH yang ditampilkan

  1. Untuk SSH bersama, salin SSH username, public host, dan port tinggi dari halaman layanan.
  2. Gunakan format ssh -p <port> <username>@<public-host>.
  3. Jika layanan memiliki dedicated public IP, gunakan host atau IP langsung serta port SSH yang ditampilkan untuk layanan itu.
  4. Private key tetap dipakai lokal di SSH client atau agent; dukungan cukup menerima host publik, port, username, dan error yang terlihat.

Public IP tidak otomatis membuka SSH

Dedicated public IP dapat menambahkan jalur langsung yang berguna untuk allowlist, monitoring, atau integrasi alamat tetap, tetapi akses SSH tetap mengikuti endpoint, port, firewall, dan autentikasi yang ditampilkan pada layanan.

> Checklist sebelum menghubungkan domain sendiri

Periksa DNS otoritatif, hostname persis, tipe record, apex atau subdomain, dan konflik record lama sebelum berpindah.
faq/custom-domain-readiness-checklist

Hostname persis menentukan record

Apex seperti example.com dan subdomain seperti app.example.com dapat membutuhkan record berbeda. Pastikan tempat edit DNS adalah nameserver otoritatif atau registrar yang benar.

Sebelum mengubah DNS

  1. Pilih hostname persis yang akan dipakai.
  2. Hapus atau ubah A/AAAA, CNAME, ALIAS, ANAME, atau redirect yang konflik.
  3. Gunakan tipe record yang direkomendasikan layanan dan didukung penyedia DNS.
  4. Tunggu propagasi DNS sebelum menguji HTTPS final.

Rollback aman

Jangan matikan hosting lama sebelum hostname baru menjawab benar. Untuk diagnosis, kirim domain, target yang diharapkan, dan hasil DNS publik, bukan akses registrar.

> Jenis record DNS untuk layanan

A/AAAA menunjuk alamat, CNAME alias, MX email, TXT verifikasi dan kebijakan mail, CAA otoritas sertifikat.
faq/dns-record-types-for-services

Setiap tipe punya fungsi

A dan AAAA menunjuk IP, CNAME membuat alias subdomain, MX mengarahkan email, TXT membawa verifikasi serta SPF/DKIM/DMARC, dan CAA membatasi penerbit sertifikat.

Saat menyalin record

  1. Salin name, type, dan value persis seperti instruksi.
  2. Jangan menaruh CNAME pada hostname yang sudah punya record lain jika aturan DNS melarang.
  3. Letakkan DKIM di selector penyedia dan DMARC di _dmarc.
  4. Ubah CAA dengan hati-hati karena nilai salah bisa memblokir sertifikat.

Jika DNS tidak bekerja

Kirim hostname, tipe record, nilai yang diharapkan, dan hasil publik yang terlihat. Jangan kirim login DNS atau screenshot yang menampilkan API token.

> Propagasi DNS dan TTL tanpa janji menit pasti

TTL menentukan berapa lama resolver dapat menyimpan jawaban lama; jawaban lama dan baru bisa muncul bersamaan sementara waktu.
faq/dns-propagation-and-ttl

Propagasi adalah cache resolver

DNS tidak memiliki janji waktu pasti per menit. Setelah record otoritatif berubah, resolver berbeda dapat masih menampilkan jawaban lama sampai cache TTL kedaluwarsa.

Untuk perubahan terencana

  1. Turunkan TTL sebelumnya jika penyedia mengizinkan.
  2. Ubah DNS sekali dan hindari edit berulang selama cache berjalan.
  3. Tes dari beberapa resolver bila hasil berbeda.
  4. Catat waktu perubahan, nilai lama, nilai baru, dan TTL.

Bahan diagnosis DNS

Sebutkan hostname, target yang diharapkan, jawaban lama, jawaban baru, TTL, dan waktu perubahan. Jangan kirim akses akun DNS atau catatan internal penyedia.

> Merencanakan storage Nextcloud

Hitung file pengguna, folder bersama, versi, trash, previews, thumbnails, overhead sinkronisasi, dan pertumbuhan tim.
faq/nextcloud-storage-planning

Nextcloud memakai ruang di luar file utama

Kapasitas dipakai oleh file pengguna, folder bersama, file terhapus, versi, previews, thumbnails, klien sinkronisasi, dan import besar. Mendekati batas dapat membuat upload atau sync gagal.

Sebelum menambah kapasitas

  1. Hitung data pengguna dan folder bersama saat ini.
  2. Tambahkan ruang untuk trash, version history, previews, dan sync overhead.
  3. Masukkan rencana import, tim baru, dan pertumbuhan.
  4. Tambah storage sebelum pengguna menabrak limit.

Masalah sinkronisasi

Kirim ukuran layanan, perkiraan pemakaian, waktu masalah, dan error klien yang terlihat. Jangan kirim file pribadi atau ekspor data pengguna kecuali diminta lewat cara aman.

> Migrasi repository ke Gitea

Rencanakan migrasi Git bersama Git LFS, submodules, protected branches, deploy keys, webhook, dan CI/CD.
faq/gitea-repository-migration

Migrasi bukan hanya git clone

Selain riwayat Git, pindahkan atau atur ulang owner, tim, protected branches, protected tags, Git LFS, submodules, deploy keys, webhook, dan integrasi CI/CD.

Sebelum cutover

  1. Daftar repository, owner, grup akses, dan akun otomasi.
  2. Periksa Git LFS, submodules, branch protection, dan tag protection.
  3. Setelah migrasi, uji clone, push, Git LFS, submodules, dan CI.
  4. Rotate atau cabut token lama tanpa membagikan nilainya.

Rahasia migrasi

Jangan kirim token, private key, private part deploy key, atau CI secrets. Cukup kirim nama repository, tipe integrasi, error yang terlihat, dan perilaku yang sebelumnya berjalan.

> Domain pengirim untuk Listmonk

Siapkan domain atau subdomain pengirim, identitas From, SPF, DKIM, DMARC, bounce, dan unsubscribe sebelum kampanye.
faq/listmonk-sender-domain-basics

Deliverability dimulai dari domain

Listmonk membutuhkan identitas From yang jelas dan DNS yang dapat diverifikasi oleh sistem email. SPF, DKIM, dan DMARC harus selaras dengan domain atau subdomain pengirim.

Sebelum kampanye pertama

  1. Pilih domain atau subdomain pengirim dan nama From.
  2. Tambahkan record verifikasi, SPF, DKIM selector, dan DMARC.
  3. Uji pengiriman, bounce atau Return-Path, dan tautan pesan.
  4. Periksa unsubscribe dan List-Unsubscribe sebelum kirim massal.

Rahasia email

Untuk diagnosis, kirim domain, tipe record, nilai DNS publik, dan pesan error. Jangan kirim kata sandi SMTP, API token, private DKIM key, atau ekspor penerima berisi data pribadi.

> Pengaturan Runtime Classic Hosting

Classic Hosting dapat memakai Runtime otomatis atau manual; CPU, RAM, storage, backup, Offsite Archive, upload, cache, dan log memengaruhi biaya serta stabilitas.
faq/classic-hosting-runtime-settings

Auto bukan satu-satunya pilihan

Auto Runtime membantu proyek yang dikenali. Manual Runtime cocok bila Anda ingin memilih Nginx, Apache, FrankenPHP, atau runtime bahasa tertentu. PHP selector hanya dipakai pada skenario yang mendukungnya.

Pengaturan sebelum deploy

  1. Pilih auto atau manual Runtime sesuai framework dan proses build.
  2. Pilih PHP 8.2, 8.3, atau 8.4 hanya untuk skenario PHP yang didukung.
  3. Atur CPU, RAM, disk, backup retention, dan Offsite Archive sesuai data serta trafik.
  4. Setelah deploy, uji upload, cache, log, dan error aplikasi yang terlihat.

Saat aplikasi tidak start

Kirim mode runtime, bahasa atau versi PHP, error terlihat, perubahan terakhir, dan waktu deploy. Jangan kirim file .env, kata sandi, token, atau log lengkap yang berisi rahasia.

> Informasi yang aman dibagikan ke dukungan

Nomor pesanan, nama layanan, domain, waktu, host publik, port, pengaturan hosting, screenshot tersamarkan, dan error terlihat membantu tanpa membuka rahasia.
faq/support-safe-information-to-share

Ticket yang baik berisi konteks

Dukungan dapat merespons lebih cepat dengan nomor pesanan, nama layanan, domain, public host atau port, waktu masalah, perubahan terakhir, dan pesan error yang terlihat.

Isi pesan yang aman

  1. Sebutkan pesanan, layanan, domain, waktu, dan langkah yang gagal.
  2. Untuk hosting, tambahkan runtime, PHP atau bahasa, CPU, RAM, disk, backup retention, Offsite Archive retention, upload, cache, dan log tanpa nilai rahasia.
  3. Samarkan screenshot sebelum dikirim.
  4. Jika ragu apakah data aman, tanyakan dulu tanpa mengirim nilainya.

Yang tidak boleh dikirim

Jangan kirim kata sandi, private keys, recovery seed, API token, session cookies, dump database, file .env penuh, log penuh berisi rahasia, atau detail infrastruktur internal.