Pertanyaan Umum

Pertanyaan yang Sering Diajukan

Panduan singkat praktis untuk pengaturan layanan, akses, dan langkah-langkah umum yang dilakukan oleh pelanggan.

> Bagaimana sistem kredit Cli>_ bekerja?

Satu saldo prabayar bersama membiayai semua layanan yang memenuhi syarat dan hanya terpakai saat layanan aktif.
faq/prepaid-credit-how-it-works

Akun Cli>_ memiliki satu saldo kredit prabayar bersama. Pelanggan baru yang memenuhi syarat hanya dapat mengklaim Starter Credit setelah menyelesaikan verifikasi akun dan pencegahan penyalahgunaan yang diwajibkan. Layanan aktif yang memenuhi syarat menggunakan saldo ini seiring waktu. Estimasi bulanan memakai 31 hari, dan layanan baru hanya dapat dimulai jika saldo mencakup setidaknya 7 hari. Peringatan merah muncul saat estimasi waktu turun di bawah 7 hari; jika tidak, peringatan oranye muncul saat turun di bawah 14 hari.

Setelah saldo habis, layanan ditangguhkan setelah 7 hari, berhenti memakai kredit, dan hitung mundur retensi serta penghapusan selama 7 hari dimulai. Sebelum tenggat yang ditampilkan, layanan dapat dimulai kembali dengan kredit cukup. Pembatalan layanan yang sudah diprovisikan juga menangguhkannya dan memulai hitung mundur yang sama. Layanan tertunda yang belum diprovisikan dapat langsung dinonaktifkan. Setelah tenggat, penonaktifan dan penghapusan layanan yang sudah diprovisikan dimulai. Force delete langsung menonaktifkan layanan, melewati retensi, dan memulai penghapusan dari runtime aktif; penyelesaian mengikuti pemrosesan deployment dan GitOps. Backup dan Offsite Archive memiliki kebijakan retensi terpisah.

Contoh OpenCode seharga EUR 9,90: 9,90 / 31 ≈ EUR 0,319 per hari. Setelah 10 hari penuh, sekitar EUR 3,19 terpakai. Jika saldo awal tepat EUR 9,90 dan tidak ada layanan lain, tersisa sekitar EUR 6,71. Pemakaian berhenti setelah layanan dinonaktifkan.

Contoh ini hanya ilustrasi. Harga terkini yang ditampilkan di Cli>_ selalu berlaku.

> Bagaimana cara menghasilkan kunci SSH publik melalui baris perintah

Buat kunci SSH publik untuk akses aman ke VPS Anda. Bagikan hanya kunci publik dengan Cli>_; simpan kunci pribadi di perangkat Anda.
faq/generate-public-ssh-key-id

Kunci publik dibagikan, kunci privat tetap aman pada Anda

Masukkan hanya kunci publik ke dalam proses pemesanan atau konfigurasi layanan. Kunci privat akan tetap berada di komputer Anda dan tidak akan dikirimkan ke tim dukungan atau dimasukkan ke dalam formulir web.

Prosedur

  1. Buka terminal di komputer Anda.
  2. Jalankan perintah: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Konfirmasi lokasi penyimpanan file atau pilih jalur khusus. Jangan pernah mengirimkan kunci pribadi Anda.
  4. Tampilkan kunci publik menggunakan perintah: cat ~/.ssh/id_ed25519.pub.
  5. Salin seluruh baris yang dimulai dengan ssh-ed25519 dan tempelkan ke kolom "SSH Public Key" saat melakukan pemesanan atau mengatur layanan.
  6. Salin seluruh baris yang diawali dengan ssh-ed25519 dan tempelkan ke kolom "SSH Public Key".

PowerShell Windows 10/11

  1. Buka PowerShell atau Windows Terminal.
  2. Jalankan perintah: ssh-keygen -t ed25519 -C "email-anda@example.com".
  3. Tekan Enter untuk menyimpan kunci ke C:\Users\nama-pengguna-anda\.ssh\id_ed25519, atau masukkan jalur khusus.
  4. Jika Windows meminta passphrase, gunakan passphrase yang dapat Anda simpan dengan aman, atau tekan Enter untuk melewatkannya saat pengaturan sederhana.
  5. Tampilkan kunci publik menggunakan perintah: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Salin hanya baris lengkap yang dimulai dengan ssh-ed25519. Jangan menyalin atau mengunggah file kunci pribadi.
> Bagaimana cara membuat kunci SSH secara visual di Windows

Panduan visual di Windows untuk membuat pasangan kunci SSH tanpa menggunakan baris perintah.
faq/create-ssh-key-windows-gui-id

Gunakan alat Windows dan tempelkan hanya kunci publik

Anda dapat membuat pasangan kunci SSH secara visual menggunakan klien SSH Windows seperti PuTTYgen. Cli>_ hanya memerlukan kunci publik. Simpan file kunci privat di komputer Anda dan jangan pernah mengunggahnya melalui formulir web.

Langkah-langkah

  1. Instal PuTTY atau buka PuTTYgen jika sudah terinstal sebelumnya.
  2. Pilih EdDSA/Ed25519 jika tersedia, atau RSA 4096 jika opsi Ed25519 tidak ditawarkan.
  3. Klik Generate dan gerakkan mouse Anda di area kosong sampai kunci dihasilkan.
  4. Tambahkan passphrase jika Anda ingin perlindungan lokal tambahan untuk kunci privat.
  5. Simpan kunci privat di perangkat Anda dan jagalah kerahasiaannya.
  6. Salin teks kunci publik dan tempelkan ke kolom SSH public key di Cli>_.

Jangan Bagikan Data Sensitif

Jangan mengirimkan file .ppk, kunci pribadi, frasa sandi, kata sandi, atau token ke dukungan atau formulir.

> Bawa Domain Anda Sendiri

Pelajari cara mengarahkan domain atau subdomain Anda ke layanan CLIopen sebelum mengaktifkan fitur 'Bawa Domain Anda Sendiri'.
faq/hubungkan-domain-sendiri

Apa fungsi dari pengaturan ini

Fitur 'Gunakan domain sendiri' memungkinkan layanan Anda merespons melalui nama host pribadi Anda, misalnya app.example.com, alih-alih menggunakan nama host yang dihasilkan secara default *.co.cliopen.cloud. DNS Anda harus mengarah ke CLIopen terlebih dahulu sebelum nama host dapat digunakan dengan aman oleh layanan.

Sebelum memulai

  1. Pilih nama host (hostname) yang tepat yang ingin Anda gunakan, misalnya app.example.com. Menggunakan subdomain adalah pilihan yang paling mudah.
  2. Buka pengaturan DNS pada registrar domain atau penyedia layanan DNS Anda.
  3. Hapus semua catatan A, AAAA, CNAME, ALIAS, atau pengalihan yang bertentangan untuk nama host tersebut.
  4. Biarkan nama host CLIopen yang dihasilkan tetap aktif sampai nama host khusus Anda diverifikasi dan berfungsi penuh.

Konfigurasi DNS yang Direkomendasikan untuk Subdomain

Buat catatan DNS untuk nama host yang tepat yang akan Anda masukkan di CLIopen. Untuk app.example.com, label DNS-nya adalah app. Arahkan ke alamat ingress CLIopen yang diberikan oleh dukungan CLIopen atau dalam dokumentasi layanan Anda. Jika penyedia Anda meminta jenis catatan, gunakan catatan A untuk IPv4 dan catatan AAAA untuk IPv6 jika alamat tersebut disediakan.

Contoh:

app.example.com.  A     <Alamat IPv4 CLIopen>
app.example.com.  AAAA  <Alamat IPv6 CLIopen, jika tersedia>

Ketika CLIopen Memberikan Target CNAME

Beberapa layanan mungkin memberikan nama host yang dihasilkan, misalnya service.customer.co.cliopen.cloud. Jika instruksi layanan Anda secara eksplisit memerlukan CNAME, buat catatan seperti app.example.com CNAME service.customer.co.cliopen.cloud. Gunakan CNAME hanya untuk subdomain, bukan untuk domain apex/root, kecuali penyedia DNS Anda mendukung flattening ALIAS atau ANAME.

Penggunaan Domain Root

Untuk domain tanpa subdomain seperti example.com, sebagian besar penyedia DNS tidak mengizinkan penggunaan CNAME standar. Gunakan rekaman A/AAAA yang menunjuk ke alamat ingress CLIopen, atau gunakan fitur ALIAS/ANAME dari penyedia Anda jika CLIopen menyediakan target hostname.

Mendelegasikan seluruh subzona

Jika Anda ingin CLIopen mengelola rekaman di bawah subdomain seperti apps.example.com, buat rekaman NS untuk subdomain tersebut yang menunjuk ke server nameserver CLIopen yang Anda terima. Jangan mengubah server nameserver untuk seluruh domain kecuali Anda secara sengaja ingin CLIopen (atau layanan DNS lainnya) mengelola semua rekaman.

Daftar Periksa

  1. Tunggu hingga propagasi DNS selesai. Perubahan kecil seringkali terlihat dalam beberapa menit, tetapi beberapa penyedia layanan mungkin memerlukan waktu lebih lama untuk melakukan caching.
  2. Pastikan hostname mengarah ke target CLIopen, bukan ke penyedia sebelumnya.
  3. Masukkan hostname yang tepat ke kolom "Bring your own domain", tanpa menyertakan `https://` dan path apapun.
  4. Setelah pembaruan, uji coba `https://app.example.com` di browser Anda.
  5. Simpan catatan DNS lama hanya jika tidak bertentangan dengan nama host baru.
> Cara Memindahkan Zona DNS ke CLIopen

Delegasikan domain ke ns1.cliopen.com dan ns2.cliopen.com, sehingga CLIopen dapat menerbitkan rekaman untuk seluruh zona.
faq/delegasikan-zona-dns

Apa arti transfer zona di sini?

Untuk layanan DNS pelanggan, transfer berarti mengubah server nama otoritatif pada registrar domain Anda. Setelah delegasi diarahkan ke CLIopen, rekaman yang ditambahkan dalam DNS CLIopen akan dipublikasikan oleh server nama otoritatif kami.

Sebelum mengubah nameserver

  1. Salin catatan DNS yang sudah ada dan masih Anda perlukan, seperti situs web, email, verifikasi, SPF, DKIM, DMARC, dan catatan layanan.
  2. Tambahkan zona di CLIopen DNS. Jika delegasi belum siap, CLIopen akan menyimpannya tetapi tidak mengaktifkannya untuk pelanggan sampai validasi berhasil.
  3. Buat catatan yang diperlukan di CLIopen DNS sebelum mengganti server nama jika memungkinkan.
  4. Perhatikan pengaturan CAA dengan benar, karena nilai yang salah dapat mencegah penerbitan sertifikat.

Delegasikan zona

  1. Buka pengaturan domain Anda di registrar, misalnya example.com.
  2. Cari bagian Nameserver, Delegasi DNS, atau Pengaturan DNS Otoritatif.
  3. Ganti nameserver yang ada dengan ns1.cliopen.com dan ns2.cliopen.com.
  4. Simpan perubahan dan tunggu hingga propagasi selesai di registri dan resolver.

Validasi

Kembali ke CLIopen DNS dan klik Periksa delegasi ulang. Ketika catatan NS publik menunjukkan ns1.cliopen.com dan ns2.cliopen.com, zona akan dimasukkan dalam antrean sinkronisasi, dan catatan akan aktif dari CLIopen.

> Pendaftaran Akun dan Login Awal

Buat satu akun kerja untuk pesanan, detail penagihan, DNS, dan pengelolaan layanan. Gunakan alamat email yang dapat diakses oleh tim Anda.
faq/account-registration-and-login

Satu akun untuk pemesanan dan pengelolaan

Gunakan akun sebagai wadah jangka panjang untuk pesanan, informasi penagihan, layanan, domain, dan komunikasi dengan tim dukungan. Alamat email kerja adalah pilihan terbaik karena dapat diakses oleh tim bahkan setelah ada perubahan personel.

Sebelum melakukan pemesanan pertama

  1. Daftar menggunakan alamat email kantor Anda.
  2. Selesaikan verifikasi email jika diminta.
  3. Lengkapi detail penagihan sebelum melakukan pemesanan layanan berbayar.
  4. Aktifkan autentikasi dua faktor segera setelah tersedia saat Anda masuk untuk pertama kalinya.

Akses untuk Tim

Jangan kirim kata sandi kepada rekan kerja melalui obrolan atau email. Jika beberapa orang memerlukan akses, gunakan pengelola kata sandi internal atau minta prosedur tim yang direkomendasikan; dukungan tidak memerlukan kata sandi atau token login Anda.

> Perkiraan Bulanan, Tahunan, dan Penggunaan Harian Aktual

Harga bulanan dan tahunan digunakan untuk perbandingan; untuk layanan berlangganan, konsumsi harian menentukan biaya setelah perubahan dikonfirmasi.
faq/billing-periods-and-credit-burn

Perbandingan ini bukan kalender penagihan

Gunakan perkiraan bulanan sebagai perbandingan untuk 31 hari, dan perkiraan tahunan sebagai perbandingan untuk 372 hari. Penggunaan kredit yang sebenarnya pada layanan prabayar terjadi sesuai dengan waktu aktif layanan dan konfigurasi yang telah dikonfirmasi.

Hal yang Perlu Diperiksa Saat Harga Berubah

  1. Bandingkan penggunaan harian sebelum dan sesudah perubahan dilakukan.
  2. Perlu diingat bahwa peningkatan CPU, RAM, disk, atau fitur berbayar dapat meningkatkan konsumsi harian.
  3. Perubahan akan berlaku setelah dikonfirmasi, pembayaran (jika diperlukan), dan diterapkan.
  4. Simpan bukti pemesanan dan riwayat kredit untuk keperluan akuntansi.

Fokus pada periode tertentu saat melakukan analisis.

Untuk membantu tim dukungan, berikan nomor pesanan, nama layanan, dan tanggal yang ingin Anda periksa. Jangan mengirimkan informasi rekening bank, seluruh laporan pembayaran, atau tangkapan layar yang berisi data pribadi yang tidak diinginkan.

> Status pesanan setelah pembayaran

Pesanan mungkin memerlukan waktu untuk dikonfirmasi oleh penyedia pembayaran; jangan membuat duplikat pesanan kecuali pesanan pertama telah jelas dibatalkan atau kedaluwarsa.
faq/order-status-and-payment-confirmation

Status "Tertunda" Tidak Selalu Berarti Gagal

Setelah kembali dari halaman pembayaran, pesanan mungkin masih menunggu konfirmasi dari penyedia layanan pembayaran. Sampai statusnya tidak menunjukkan kegagalan atau kedaluwarsa, pemesanan duplikat dapat menyulitkan proses pencocokan.

Bagaimana cara melanjutkan setelah pembayaran

  1. Setelah pembayaran selesai, kembali ke Cli>_.
  2. Periksa status pesanan dan pesan terkait pembayaran di akun Anda.
  3. Jika pesanan masih dalam keadaan menunggu, berikan waktu bagi penyedia untuk melakukan konfirmasi.
  4. Jika ada masalah, hubungi tim dukungan dengan menyertakan nomor pesanan dan referensi pembayaran (jika tersedia).

Apa yang Tidak Boleh Dikirim

Tim dukungan tidak memerlukan informasi kartu pembayaran, kata sandi login, atau salinan lengkap bukti transfer bank. Cukup berikan nomor pesanan, waktu pembayaran, status yang terlihat, dan tangkapan layar yang disamarkan jika terjadi kesalahan.

> Informasi yang Mempercepat Pengaturan Layanan

Siapkan nama layanan, domain, ukuran penyimpanan, alamat email akses, dan kunci SSH publik; jangan masukkan informasi rahasia ke dalam formulir.
faq/service-setup-information-needed

Informasi yang akurat menghemat waktu

Gunakan formulir pemesanan untuk informasi publik atau yang tidak bersifat rahasia: nama layanan, domain, rencana DNS, ukuran penyimpanan, CPU, RAM, alamat email administrator, atau kunci SSH publik. Kata sandi, kunci pribadi, dan token tidak boleh dimasukkan ke dalam formulir.

Persiapkan sebelum melakukan pemesanan

  1. Pilih nama layanan yang mudah diingat oleh tim Anda.
  2. Tentukan apakah Anda akan menggunakan domain sendiri atau hostname sementara.
  3. Siapkan kunci SSH publik jika layanan membutuhkannya.
  4. Periksa ukuran penyimpanan dan sumber daya yang dibutuhkan sesuai dengan aplikasi yang akan Anda jalankan.

Jangan Kirim Informasi Rahasia

Jika Anda tidak yakin apakah suatu informasi bersifat rahasia, sebaiknya tanyakan tanpa mengirimkannya. Jangan kirim kunci pribadi, kata sandi, token, dump database, atau file konfigurasi lengkap melalui obrolan atau pesanan.

> Mengubah CPU, RAM, disk, atau durasi setelah pemesanan

Ubah konfigurasi layanan yang sudah ada melalui detail layanannya, bukan dengan membuat pesanan baru; perubahan sumber daya dapat memengaruhi harga, biaya layanan, penggunaan kredit harian, waktu restart, dan risiko downtime.
faq/change-service-resources-after-order

Anda sedang mengubah layanan yang sudah ada, bukan membuat yang baru

Jika layanan sudah berjalan, ubah sumber daya dari detail layanannya. Pesanan baru akan membuat layanan lain alih-alih memodifikasi yang sudah ada, dan dapat mengubah harga, penggunaan kredit harian, serta perilaku operasional setelah konfirmasi, pembayaran (jika diperlukan), dan penerapan perubahan.

Sebelum mengonfirmasi perubahan

  1. Lihat penggunaan CPU, RAM, disk, informasi pencadangan, dan retensi Offsite Archive saat ini.
  2. Periksa harga terbaru dan dampaknya pada kredit harian Anda.
  3. Baca pemberitahuan tentang pembaruan sistem, perawatan, atau gangguan layanan.
  4. Lakukan ekspor data penting sebelum melakukan perubahan yang berpotensi menimbulkan risiko.

Bagaimana jika perubahan tidak berjalan sesuai harapan

Sampaikan nama layanan, waktu perubahan, status tampilan, dan pesan kesalahan. Jangan mengirimkan kunci pribadi (private key), kata sandi, token, atau file konfigurasi rahasia; untuk diagnosis, cukup informasi konteks publik dan tangkapan layar yang disamarkan.

> Pembatalan Layanan dan Batas Waktu Penghapusan Data

Layanan yang telah diaktifkan akan ditangguhkan terlebih dahulu, kemudian ditampilkan batas waktu penghapusan data yang dapat dikonfigurasi, setelah itu data dapat dihapus secara permanen.
faq/cancel-service-and-data-retention

Pembatalan tidak langsung menghapus semua layanan

Untuk layanan yang sudah diaktifkan, layanan tersebut akan ditangguhkan sementara dan menampilkan jangka waktu penghapusan yang dapat dikonfigurasi, selama periode ini pemulihan atau ekspor masih memungkinkan. Pesanan yang tertunda dan belum dibayar tanpa data aktif mungkin memiliki perilaku berbeda, dan penghapusan permanen baru terjadi setelah masa berlaku habis.

Periksa sebelum pembatalan

  1. Buat ekspor data sendiri untuk menyimpan data yang Anda butuhkan dalam jangka panjang.
  2. Perhatikan tanggal dan waktu penghapusan yang dijadwalkan saat layanan ditangguhkan.
  3. Jangan keliru antara pencadangan (backup) dan Arsip Eksternal (Offsite Archive) dengan penghapusan data otomatis (lifecycle deletion).
  4. Jika Anda tidak yakin, hubungi dukungan sebelum tanggal penghapusan.

Pemulihan mungkin tidak tersedia setelah tenggat waktu

Setelah batas waktu yang terlihat berakhir, jangan anggap data masih tersedia. Saat mengajukan pertanyaan, berikan nomor pesanan dan nama layanan, bukan ekspor database atau kredensial rahasia.

> Cadangan dan permintaan pemulihan

Cadangan berfungsi untuk pemulihan operasional, bukan sebagai pengganti fitur ekspor; proses pemulihan dapat menimpa data yang lebih baru.
faq/backups-and-restore-requests

Cadangan bukanlah arsip atau ekspor

Periode penyimpanan cadangan bergantung pada produk dan opsi yang dipilih. Cadangan membantu dalam pemulihan operasional setelah terjadi kesalahan, tetapi tidak menggantikan ekspor mandiri, arsip audit, atau Offsite Archive. Proses pemulihan dapat menimpa perubahan terbaru.

Cara menyiapkan permintaan pemulihan

  1. Sebutkan nama layanan dan nomor pesanan.
  2. Jelaskan perkiraan waktu yang ingin Anda kembalikan.
  3. Tulis apakah seluruh layanan atau hanya bagian tertentu yang perlu dipulihkan, jika memungkinkan.
  4. Sertakan pesan kesalahan atau konteks yang jelas tanpa kata sandi, token, atau kunci pribadi.

Pertimbangkan dampaknya sebelum melakukan pemulihan

Jika layanan telah menerima data baru, proses pemulihan dapat mengganti data tersebut dengan versi sebelumnya. Beri tahu tim dan lakukan ekspor data penting sebelum menyetujui pemulihan.

> Untuk Apa Offsite Archive?

Offsite Archive menyimpan salinan arsip yang disimpan di lokasi terpencil, terpisah dari pencadangan operasional jangka pendek dan siklus hidup layanan.
faq/offsite-archive-purpose

Arsip di Luar Lingkungan Operasi Normal

Offsite Archive dirancang untuk membuat salinan arsip jarak jauh dan menyimpan data dalam jangka waktu yang lebih lama. Ini bukan disk aktif untuk aplikasi, pengganti ekspor lokal, atau sama dengan pencadangan operasional singkat.

Kapan mengaktifkannya

  1. Gunakan fitur ini untuk menyimpan data yang perlu diarsipkan, diekspor, atau disimpan dalam jangka waktu yang lebih lama, bukan hanya untuk penyimpanan aplikasi aktif.
  2. Pilih jumlah hari retensi sesuai dengan kebutuhan kepatuhan (compliance) atau tujuan pemulihan data Anda.
  3. Perhatikan bahwa biaya akan meningkat seiring dengan volume data yang disimpan dan lamanya waktu penyimpanan.
  4. Untuk volume data yang besar, rencanakan arsip bersamaan dengan proses ekspor Anda sendiri.

Bagaimana Cara Mempertimbangkan Biaya

Dasarnya adalah MB-hari: berapa banyak data yang disimpan dan berapa hari data tersebut disimpan. Tarif ditampilkan kepada pelanggan sebagai EUR/GB/bulan, dan hasilnya dibulatkan ke sen terdekat.

> Pilih CPU, RAM, dan disk untuk VPS

Pilih ukuran VPS berdasarkan aplikasi, database, cache, log, dan potensi pertumbuhan; Jika terjadi kesalahan kehabisan memori (OOM) atau penggunaan swap yang berlebihan, itu bisa menjadi indikasi bahwa Anda memerlukan lebih banyak RAM.
faq/vps-cpu-ram-and-disk-sizing

Mulai berdasarkan beban kerja yang sebenarnya, bukan perkiraan

Situs web statis kecil memiliki kebutuhan yang berbeda dari basis data, aplikasi Java, pencarian, atau kontainer build. Saat merencanakan, pertimbangkan memori aplikasi, cache, database, log, unggahan, dan ruang untuk pertumbuhan.

Tanda-tanda bahwa paket terlalu kecil

  1. Tingkatkan RAM jika terjadi OOM (Out Of Memory), proses dihentikan, atau swap yang terus-menerus.
  2. Tingkatkan CPU saat terjadi beban komputasi tinggi berkelanjutan, kompresi, proses build, atau aktivitas worker yang sibuk.
  3. Perbesar kapasitas disk sebelum sistem file, log, atau database penuh.
  4. Setelah setiap perubahan, perhatikan apakah aplikasi benar-benar tidak lagi mencapai batas awal.

Informasi yang Perlu Disertakan Saat Bertanya Tentang Ukuran Server

Informasi yang berguna meliputi nama layanan, jenis aplikasi, pesan kesalahan yang terlihat, perkiraan waktu kejadian, serta penggunaan CPU, RAM, dan disk saat ini. Jangan mengirimkan kata sandi, kunci pribadi, atau file konfigurasi internal.

> Kapan Alamat IP Publik Berguna untuk VPS

Alamat IP publik khusus berguna untuk daftar putih (allowlist), akses masuk (inbound), sumber keluar (outbound) yang stabil, atau layanan yang terikat pada alamat tersebut.
faq/vps-public-ip-options

Pertama, tentukan arah komunikasi

Alamat IP publik tidak selalu diperlukan untuk setiap layanan. Biasanya digunakan untuk memenuhi kebutuhan mitra eksternal, penyedia, atau firewall yang memerlukan daftar putih (allowlist), sumber outbound yang stabil, atau akses masuk ke port tertentu.

Pertanyaan Sebelum Memesan IP

  1. Tanyakan kepada mitra apakah mereka memerlukan daftar putih untuk lalu lintas masuk, keluar, atau keduanya.
  2. Gunakan nama DNS alih-alih alamat IP numerik jika memungkinkan.
  3. Buka hanya port yang benar-benar dibutuhkan oleh aplikasi.
  4. Kirimkan permintaan daftar putih (allowlist) ke tim dukungan sebelum mengubah konfigurasi akses produksi.

Apa yang Sebaiknya Dibiarkan Tertutup

Alamat IP publik khusus tidak berarti membuka semua port. Konfigurasikan akses hanya untuk layanan yang benar-benar dibutuhkan, dan jangan kirim kata sandi, kunci privat, atau aturan firewall internal sebagai tangkapan layar yang berisi informasi sensitif.

> Akses SSH Bersama untuk VPS

Tanpa membeli alamat IP publik, VPS terhubung melalui endpoint SSH bersama dengan port tinggi; jika Anda memiliki alamat IP publik, Anda juga akan mendapatkan akses SSH langsung ke alamat tersebut.
faq/shared-ssh-access-for-vps

Mengapa SSH Bersama Menggunakan Port Tinggi

Beberapa layanan VPS dapat berbagi endpoint SSH publik yang sama, oleh karena itu setiap layanan akan mendapatkan port tinggi sendiri. Port merupakan bagian dari pengarahan ke layanan Anda; tanpa port tersebut, koneksi tidak dapat secara unik dikirimkan ke VPS yang benar.

Cara Menghubungkan Berdasarkan Jenis Akses

  1. Untuk SSH bersama, salin nama pengguna (username) SSH, host publik, dan port dari halaman layanan.
  2. Gunakan format `ssh -p <port> <username>@<public-host>`.
  3. Jika layanan memiliki alamat IP publik khusus, Anda mungkin menemukan titik akhir SSH kedua langsung pada alamat IP tersebut atau nama domainnya, tergantung pada konfigurasi layanan.
  4. Gunakan kunci privat hanya secara lokal melalui klien atau agen SSH Anda; tim dukungan hanya memerlukan host publik, port, nama pengguna, dan pesan kesalahan yang terlihat.

Saat Anda Memiliki Alamat IP Publik Tambahan

Alamat IP publik tidak mengubah endpoint SSH bersama; ini menambahkan cara akses terpisah yang cocok untuk daftar putih, pemantauan, atau koneksi langsung. Dalam praktiknya, Anda mungkin melihat dua jenis akses SSH: host bersama dengan port tinggi dan host atau IP langsung untuk layanan dengan alamat IP publik.

> Periksa Sebelum Menghubungkan Domain Anda Sendiri

Sebelum mengganti domain, pastikan untuk memeriksa DNS yang berwenang, nama host yang tepat, jenis catatan, apakah itu domain utama atau subdomain, dan adanya catatan lama yang bertentangan.
faq/custom-domain-readiness-checklist

Nama host yang tepat sangat penting

Pertama, pastikan apakah Anda menghubungkan domain utama (seperti example.com) atau subdomain (seperti app.example.com). Setiap variasi mungkin memerlukan jenis catatan DNS yang berbeda, batasan DNS penyedia yang berbeda, dan verifikasi dengan registrar.

Sebelum Mengubah DNS

  1. Periksa lokasi di mana rekaman DNS otoritatif untuk domain dimodifikasi.
  2. Hapus atau ubah rekaman A/AAAA, CNAME, ALIAS, ANAME, atau pengalihan yang saling bertentangan.
  3. Gunakan tipe rekaman yang direkomendasikan untuk layanan dan nama host tertentu.
  4. Setelah perubahan, tunggu hingga propagasi DNS selesai dan kemudian uji HTTPS secara final.

Kembalikan dengan Aman

Jangan menonaktifkan hosting lama sebelum hostname baru berfungsi dengan benar. Saat melaporkan masalah, berikan informasi tentang domain, tujuan yang diharapkan, dan hasil DNS publik, bukan akses ke registrar.

> Jenis Rekaman DNS untuk Layanan

Rekaman A/AAAA mengarahkan ke alamat IP, CNAME digunakan untuk alias, MX untuk layanan email, dan TXT untuk verifikasi, termasuk SPF, DKIM, atau DMARC.
faq/dns-record-types-for-services

Jangan menggabungkan catatan secara sembarangan

Setiap jenis DNS memiliki fungsi yang berbeda. Catatan A dan AAAA menunjuk ke alamat IP, CNAME membuat alias untuk subdomain, MX mengarahkan email, TXT berisi verifikasi dan kebijakan email, serta CAA membatasi otoritas sertifikat.

Saat menyalin catatan

  1. Salin nama, jenis, dan nilai sesuai dengan instruksi layanan secara persis.
  2. Gunakan A/AAAA untuk alamat, CNAME untuk alias subdomain yang diizinkan, MX untuk email, dan TXT untuk SPF, DKIM, DMARC, atau verifikasi.
  3. Letakkan DKIM pada bagian selector dari penyedia dan DMARC biasanya pada _dmarc.
  4. Konfigurasi CAA harus dilakukan dengan hati-hati, karena nilai yang salah dapat menghalangi proses penerbitan sertifikat.

Ketika DNS Tidak Berfungsi

Kirimkan hostname, jenis catatan, nilai yang diharapkan, dan hasil yang terlihat kepada tim dukungan. Jangan kirimkan kredensial login ke administrasi DNS atau tangkapan layar yang menampilkan token API.

> Propagasi DNS dan TTL: Panduan

TTL (Time To Live) menentukan berapa lama resolver dapat menyimpan respons lama. Selama proses propagasi, resolusi yang berbeda mungkin menampilkan hasil lama dan baru secara bersamaan hingga cache kedaluwarsa, bahkan setelah rekaman otoritatif diubah.
faq/dns-propagation-and-ttl

Propagasi adalah mekanisme caching, bukan sekadar menunggu

Pada DNS, tidak ada jaminan waktu yang pasti. Setelah perubahan pada server DNS utama, berbagai resolver mungkin masih menampilkan jawaban lama dan baru sampai cache mereka kedaluwarsa sesuai dengan TTL (Time To Live). Oleh karena itu, hasilnya dapat bervariasi antar jaringan, negara, atau resolver DNS.

Saat melakukan perubahan yang direncanakan

  1. Jika penyedia layanan mengizinkan, turunkan TTL sebelum perubahan yang direncanakan.
  2. Lakukan perubahan DNS sekali saja dan hindari pengeditan berulang sampai cache kedaluwarsa.
  3. Uji dari beberapa resolver jika hasilnya berbeda.
  4. Catat waktu perubahan, nilai sebelumnya, nilai baru, dan TTL.

Apa yang Dikirim Selama Diagnostik

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

> Perencanaan Kapasitas Penyimpanan untuk Workspace Suite

Saat merencanakan kapasitas penyimpanan, pertimbangkan faktor-faktor seperti file pengguna, folder bersama, versi file, tempat sampah, pratinjau, overhead sinkronisasi, dan perkiraan pertumbuhan tim.
faq/nextcloud-storage-planning

Workspace Suite menggunakan ruang penyimpanan lebih dari sekadar file utama

Ruang penyimpanan digunakan oleh file pengguna, folder bersama, file yang dihapus, riwayat versi, pratinjau, thumbnail, klien sinkronisasi, dan impor data. Jika penyimpanan hampir mencapai batasnya, unggahan atau sinkronisasi dapat gagal.

Sebelum memesan kapasitas

  1. Hitung data pengguna dan folder bersama saat ini.
  2. Tambahkan ruang untuk file yang dihapus, riwayat versi, pratinjau, dan aktivitas sinkronisasi.
  3. Pertimbangkan impor besar, tim baru, dan pertumbuhan yang diharapkan.
  4. Tingkatkan kapasitas sebelum pengguna mencapai batasnya.

Jika Anda Mengalami Masalah Sinkronisasi

Kirimkan ukuran layanan, perkiraan penggunaan, waktu masalah, dan pesan kesalahan yang terlihat dari sisi klien. Jangan mengirimkan file pribadi, kata sandi, atau ekspor data pengguna kecuali diminta secara khusus oleh tim dukungan melalui cara yang aman.

> Migrasi Repositori ke Gitea

Pindahkan repositori Git dengan mempertimbangkan Git LFS, submodule, izin, kunci penerapan, webhook, dan CI/CD.
faq/gitea-repository-migration

Migrasi lebih dari sekadar `git clone`

Selain riwayat repositori, Anda perlu memindahkan atau mengatur ulang pemilik, tim, cabang yang dilindungi, tag yang dilindungi, Git LFS, submodule, kunci penerapan, webhook, dan koneksi CI/CD.

Pemeriksaan Sebelum Migrasi

  1. Daftar repositori, pemilik, grup akses, dan akun otomatisasi.
  2. Periksa objek Git LFS, submodule, perlindungan cabang, dan perlindungan tag.
  3. Setelah migrasi, lakukan pengujian kloning, push, Git LFS, submodule, dan eksekusi CI.
  4. Hapus atau ganti token lama setelah migrasi selesai tanpa membagikan nilainya.

Informasi Penting Selama Migrasi

Jangan kirim token, kunci pribadi, bagian privat dari kunci deployment, atau rahasia CI ke tim dukungan. Cukup berikan nama repositori, jenis integrasi, pesan kesalahan yang terlihat, dan informasi tentang apa yang berfungsi sebelum migrasi.

> Domain Pengirim untuk Listmonk

Untuk kampanye, siapkan domain atau subdomain pengirim, identitas 'Dari', SPF, DKIM, DMARC, penanganan email yang tidak diterima (bounce), dan opsi berhenti berlangganan (unsubscribe).
faq/listmonk-sender-domain-basics

Keandalan Pengiriman Dimulai dari Domain

Listmonk memerlukan identitas "From" yang jelas dan catatan DNS yang dapat diverifikasi oleh sistem email. SPF, DKIM, dan DMARC harus sesuai dengan domain atau subdomain tempat Anda ingin mengirimkan kampanye.

Sebelum kampanye pertama

  1. Pilih domain atau subdomain pengirim, serta nama yang akan ditampilkan di bagian 'Dari'.
  2. Tambahkan catatan DNS verifikasi, termasuk SPF, DKIM selector, dan DMARC.
  3. Lakukan uji coba pengiriman untuk memeriksa apakah pesan masuk ke folder spam, bagaimana penanganan email yang tidak terkirim (bounce), alamat Return-Path, dan tautan.
  4. Periksa fitur berhenti berlangganan (unsubscribe) dan List-Unsubscribe sebelum pengiriman massal.

Informasi sensitif terkait email tidak boleh dimasukkan ke dalam tiket.

Saat melakukan diagnosis, kirimkan domain, jenis catatan (record), nilai DNS yang terlihat publik, dan pesan kesalahan. Jangan mengirimkan kata sandi SMTP, token API, kunci DKIM pribadi, atau ekspor penerima yang berisi data pribadi.

> Pengaturan Runtime untuk Classic Hosting

Classic Hosting dapat berjalan dalam mode Runtime otomatis atau manual. Sumber daya seperti CPU, RAM, penyimpanan, cadangan, retensi Arsip Eksternal, unggahan, cache, dan log memengaruhi biaya dan stabilitas.
faq/classic-hosting-runtime-settings

Mode otomatis bukanlah satu-satunya pilihan terbaik

Auto Runtime membantu dalam proyek yang terdeteksi secara otomatis, tetapi mode manual lebih cocok jika Anda ingin memilih Nginx, Apache, FrankenPHP, atau runtime bahasa tertentu. Gunakan PHP selector hanya pada skenario yang didukung oleh runtime yang dipilih.

Pengaturan sebelum penerapan

  1. Pilih mode otomatis untuk build yang terdeteksi atau mode manual untuk kontrol runtime Nginx, Apache, atau FrankenPHP.
  2. Pilih PHP 8.2/8.3/8.4 hanya jika runtime yang dipilih mendukung opsi tersebut.
  3. Tentukan ukuran CPU, RAM, memori, penyimpanan, retensi backup, dan retensi Arsip Eksternal sesuai dengan lalu lintas dan data.
  4. Setelah penerapan, lakukan pengujian unggahan, cache, log, dan kesalahan aplikasi yang terlihat.

Saat aplikasi tidak berjalan

Kirimkan informasi tentang mode runtime, bahasa atau versi PHP, kesalahan yang terlihat, perubahan terbaru, dan perkiraan waktu penerapan. Jangan kirim file .env, kata sandi, token, atau log lengkap yang berisi informasi sensitif.

> Informasi apa saja yang aman untuk dikirimkan ke tim dukungan?

Informasi berikut sangat membantu: nomor pesanan, nama layanan, domain, waktu, host publik, port, periode penyimpanan cadangan, periode penyimpanan Arsip Eksternal, unggahan, cache, log, tangkapan layar, dan kesalahan yang terlihat (tanpa informasi rahasia).
faq/support-safe-information-to-share

Permintaan berkualitas berisi informasi yang relevan, bukan data rahasia.

Tim dukungan dapat merespons lebih cepat jika menerima nomor pesanan, nama layanan, domain, host atau port publik, waktu masalah terjadi, perubahan terbaru, dan pesan kesalahan yang jelas.

Isi pesan dengan aman

  1. Sebutkan nomor pesanan, layanan yang terlihat, domain, perkiraan waktu, dan host atau port publik jika relevan.
  2. Untuk masalah hosting, sertakan mode runtime, bahasa atau versi PHP, CPU, RAM, penyimpanan, retensi cadangan, retensi Arsip Eksternal, unggahan, cache, dan log tanpa informasi rahasia.
  3. Potong atau samarkan bagian sensitif pada tangkapan layar sebelum mengirimkannya.
  4. Jika Anda tidak yakin apakah suatu informasi cocok untuk tiket, tanyakan terlebih dahulu tanpa mengirimkannya.

Hal-hal yang Tidak Boleh Dikirimkan

Jangan kirim kata sandi, kunci pribadi, seed pemulihan, token API, cookie sesi, ekspor database, file .env lengkap, log lengkap yang berisi data sensitif, atau detail infrastruktur internal.