Domain .cloud vs .dev: Mana yang Tepat untuk Portofolio Developer?

Setelah menyelesaikan beberapa proyek, developer biasanya mulai membutuhkan domain sendiri untuk menghubungkan portofolio, dokumentasi, repository, dan demo aplikasi. Pada tahap ini, perbandingan domain .cloud vs .dev dapat muncul, terutama jika proyek berkaitan dengan deployment, API, container, atau infrastruktur cloud.

Kedua ekstensi tersebut dapat digunakan untuk menampilkan karya teknis. Namun, pilihan yang tepat perlu mengikuti isi portofolio, struktur proyek, dan cara pengguna akan mengaksesnya.

Domain untuk profil developer yang berisi berbagai eksperimen pemrograman tentu memiliki kebutuhan berbeda dari domain untuk satu proyek cloud yang mempunyai dashboard, dokumentasi, API, dan status page. Karena itu, evaluasi sebaiknya dimulai dari fungsi domain di dalam ekosistem proyek.

Ringkasan Perbandingan Domain .cloud dan .dev

Tabel berikut memberikan gambaran awal untuk membantu kamu membandingkan kedua ekstensi berdasarkan kebutuhan teknis.

Faktor Penilaian	Domain .cloud	Domain .dev
Fokus portofolio	Proyek cloud, DevOps, deployment, storage, dan infrastruktur	Software development, library, framework, aplikasi, dan coding secara umum
Bentuk proyek	Dashboard cloud, homelab, monitoring, atau platform deployment	Portofolio developer, dokumentasi, demo aplikasi, dan playground
Cakupan karya	Satu proyek atau kelompok proyek dengan tema cloud	Berbagai proyek dari beberapa bahasa dan teknologi
Struktur endpoint	Console, API, status, metrics, dan monitoring	Docs, demo, playground, profile, dan repository
Kesiapan HTTPS	Tetap perlu dikonfigurasi untuk seluruh halaman publik	Harus siap menggunakan HTTPS sejak awal
Pengembangan isi	Sesuai untuk proyek yang tetap berfokus pada lingkungan cloud	Lebih fleksibel untuk portofolio lintas bidang development

Perbandingan tersebut bukan aturan mutlak. Developer dapat menggunakan .dev untuk proyek cloud atau .cloud untuk portofolio pribadi. Namun, fungsi domain akan terasa lebih konsisten ketika ekstensi, isi halaman, dan struktur endpoint saling mendukung.

Kamu juga dapat melihat pembahasan mengenai ekstensi domain .cloud untuk memahami konteks penggunaannya sebelum membandingkan struktur proyek secara lebih mendalam.

Cocokkan Domain dengan Isi Portofolio

Langkah pertama adalah memeriksa proyek yang paling dominan di dalam portofolio. Jangan hanya menilai satu proyek terbaru. Lihat keseluruhan karya yang sudah dibuat dan proyek yang masih akan ditambahkan.

Portofolio General Software Development

Portofolio general software development biasanya berisi campuran proyek, seperti:

• Aplikasi front-end
• Back-end service
• Mobile application
• Command-line tool
• Library
• Eksperimen framework
• Kontribusi open-source
• Artikel atau catatan teknis

Untuk struktur seperti ini, domain berfungsi sebagai pusat profil developer. Pengunjung datang untuk melihat berbagai kemampuan, teknologi yang pernah digunakan, repository, dan hasil implementasi.

Struktur domainnya dapat dibuat sederhana:

Pendekatan tersebut membuat seluruh karya berada dalam satu domain. Setiap proyek dapat ditempatkan dalam halaman terpisah tanpa harus memiliki subdomain sendiri.

Portofolio Cloud dan DevOps

Portofolio cloud dan DevOps biasanya memiliki isi yang lebih spesifik, misalnya:

• Infrastructure as Code
• Container orchestration
• CI/CD pipeline
• Monitoring server
• Cloud deployment
• Server automation
• Managed database
• Observability
• Backup dan storage
• Konfigurasi jaringan

Dalam kasus ini, periksa apakah seluruh proyek memang memiliki satu tema yang konsisten. Jika sebagian besar karya berkaitan dengan infrastruktur dan layanan cloud, domain .cloud dapat dimasukkan sebagai kandidat utama.

Strukturnya dapat berupa:

Namun, jika domain digunakan untuk satu proyek saja, nama proyek dapat ditempatkan langsung sebelum ekstensi:

Portofolio Berbasis Studi Kasus

Sebagian developer tidak hanya menampilkan screenshot atau tautan repository. Mereka menyusun proyek sebagai studi kasus lengkap yang mencakup:

• Permasalahan yang diselesaikan
• Diagram arsitektur
• Pemilihan teknologi
• Alur deployment
• Repository
• Live demo
• Dokumentasi
• Hasil pengujian
• Catatan pengembangan

Pada struktur seperti ini, domain berfungsi sebagai pusat dokumentasi. Ekstensi yang dipilih perlu mendukung banyak halaman sekaligus tetap nyaman digunakan sebagai alamat demo dan endpoint.

Developer yang sebelumnya menggunakan GitHub Pages, Netlify, atau Vercel juga dapat mempelajari beberapa opsi domain untuk portofolio developer sebelum menghubungkan proyek ke domain khusus.

Nilai Jenis Proyek yang Akan Dipublikasikan

Setelah memeriksa isi portofolio secara keseluruhan, lanjutkan dengan mengevaluasi bentuk proyek yang akan dipublikasikan. Proyek sederhana tidak membutuhkan struktur domain yang sama dengan platform yang memiliki beberapa layanan.

Demo Aplikasi

Demo aplikasi biasanya menjadi bukti bahwa proyek benar-benar dapat dijalankan. Beberapa struktur yang bisa digunakan antara lain:

Jika demo hanya menjadi salah satu bagian portofolio, menempatkannya di bawah domain utama dapat mempermudah pengelolaan.

Sebaliknya, proyek dengan dashboard, sistem autentikasi, dan layanan yang berdiri sendiri mungkin memerlukan domain tersendiri.

Sebelum membuat subdomain, pastikan platform deployment mendukung custom domain dan penerbitan sertifikat SSL untuk setiap alamat yang digunakan.

Dokumentasi API dan SDK

Proyek API memerlukan struktur yang mudah dibaca, baik di browser maupun ketika dimasukkan ke dalam kode.

Contohnya:

Dokumentasi API juga dapat mencakup beberapa komponen:

• API reference
• Authentication guide
• SDK
• Changelog
• Versioning
• Playground
• Error reference
• Contoh request dan response

Jika API memiliki beberapa versi, kamu dapat menggunakan path seperti:

Pemisahan tersebut lebih mudah dikelola daripada membuat subdomain baru untuk setiap versi.

Apabila proyek mempunyai banyak endpoint, pembagian domain dapat mengikuti strategi arsitektur API agar dokumentasi, autentikasi, versioning, dan akses layanan tidak tercampur.

Proyek Open-Source

Domain untuk proyek open-source tidak harus menggantikan repository. Domain dapat menjadi pusat informasi yang menghubungkan beberapa komponen berikut:

• Dokumentasi penggunaan
• Repository
• Issue tracker
• Release notes
• Package registry
• Contributor guide
• Live demo
• Roadmap

Sebagai contoh, repository tetap berada di GitHub atau GitLab, sedangkan dokumentasinya menggunakan custom domain.

Untuk proyek open-source yang berfokus pada deployment atau pengelolaan infrastruktur, strukturnya dapat dibuat seperti:

Pertimbangkan juga bagaimana URL akan terlihat ketika ditempatkan di README, package metadata, dan contoh konfigurasi.

Homelab dan Personal Cloud

Homelab dapat berisi server, media storage, monitoring, container management, VPN, dan berbagai eksperimen jaringan.

Domain publik dapat digunakan untuk dokumentasi atau status page:

Akan tetapi, dashboard administratif tidak sebaiknya dibuka ke internet tanpa autentikasi dan pembatasan akses yang tepat.

Pisahkan halaman publik dengan interface internal. Jangan menggunakan domain sebagai alasan untuk membuka seluruh layanan homelab secara langsung.

Infrastruktur dan Observability

Proyek observability sering memiliki beberapa interface, seperti metrics, logs, traces, dan status.

Struktur sederhananya dapat berupa:

Tidak semua endpoint perlu tersedia untuk publik. Status page dan dokumentasi dapat diakses secara terbuka, sedangkan dashboard operasional tetap berada di balik autentikasi.

Tentukan Fungsi Domain dalam Ekosistem Proyek

Domain dapat berfungsi sebagai profil utama, alamat proyek, pusat dokumentasi, atau endpoint teknis. Menentukan fungsi tersebut sejak awal akan mengurangi perubahan konfigurasi setelah proyek dipublikasikan.

Domain Utama untuk Profil Developer

Jika domain digunakan sebagai profil utama, seluruh karya dapat diletakkan dalam satu alamat:

Halaman utamanya dapat memuat:

• Profil singkat
• Daftar proyek
• Teknologi yang digunakan
• Tautan repository
• Artikel teknis
• Kontak
• Catatan eksperimen

Setiap proyek dapat menggunakan path agar strukturnya tetap ringkas:

Domain Utama untuk Satu Proyek Cloud

Proyek yang memiliki beberapa layanan dapat menggunakan domain utama beserta subdomain:

Struktur ini memisahkan fungsi setiap layanan tanpa membuatnya terlihat seperti proyek yang tidak berkaitan.

Sebelum membuat banyak alamat, pahami cara mengatur domain dan subdomain agar aplikasi, dokumentasi, API, dan status page tidak saling bercampur.

Domain untuk Dokumentasi

Dokumentasi dapat ditempatkan pada subdomain khusus:

Pemisahan ini sesuai untuk proyek dengan dokumentasi panjang, versioning, navigasi sendiri, dan proses deployment yang berbeda dari website utama.

Namun, proyek kecil dapat menggunakan path:

Tidak perlu membuat subdomain jika dokumentasi hanya memiliki beberapa halaman.

Domain untuk Endpoint Teknis

Beberapa proyek memerlukan alamat yang akan dimasukkan ke file konfigurasi atau digunakan oleh aplikasi lain.

Contohnya:

Gunakan nama yang singkat dan mudah dibedakan. Hindari endpoint yang terlalu panjang karena alamat tersebut akan sering muncul di dokumentasi, environment variable, dan contoh kode.

Evaluasi Workflow Repository hingga Deployment

Pilihan domain juga perlu mengikuti workflow publikasi proyek. Periksa bagaimana source code diproses hingga akhirnya dapat diakses melalui custom domain.

Alur yang umum digunakan adalah:

1. Source code disimpan di repository.
2. Branch tertentu dipilih sebagai sumber production.
3. Build dijalankan secara otomatis.
4. Hasil build dikirim ke platform deployment.
5. Custom domain diarahkan ke deployment.
6. Sertifikat SSL diaktifkan.
7. HTTP dialihkan ke HTTPS.
8. Domain bawaan platform diarahkan ke domain utama.

Jika portofolio dibuat dengan static site generator, kamu dapat menerapkan workflow tersebut melalui GitHub Actions, GitLab CI/CD, atau sistem build dari platform deployment.

Custom Domain di GitHub Pages

GitHub Pages dapat digunakan untuk menampilkan portofolio, dokumentasi, dan halaman proyek statis. Setelah website dipublikasikan, domain khusus dapat diarahkan melalui pengaturan repository dan DNS.

Kamu dapat mengikuti panduan menghubungkan custom domain ke GitHub Pages untuk mengatur domain, DNS, dan repository yang digunakan.

Setelah domain terhubung, periksa kembali:

• Domain utama sudah tersimpan di pengaturan repository
• Record DNS mengarah ke tujuan yang benar
• Domain bawaan dialihkan ke domain utama
• HTTPS sudah aktif
• Tidak ada file konfigurasi yang tertimpa saat build
• Tautan internal tidak lagi menggunakan alamat lama

Deployment Multi-Environment

Proyek aktif biasanya memiliki production, staging, atau preview.

Contoh dengan domain .dev:

Contoh dengan domain .cloud:

Pastikan staging tidak terindeks atau terbuka jika masih berisi data pengujian. Gunakan autentikasi jika environment tersebut hanya ditujukan untuk pengembangan internal.

Periksa Kesiapan HTTPS

Website publik sebaiknya sudah menggunakan HTTPS. Untuk .dev, kesiapan tersebut menjadi bagian penting sejak awal karena seluruh koneksi ke domain .dev dipaksa menggunakan HTTPS melalui HSTS preload.

Sebelum memilih nama, periksa beberapa hal berikut:

• Platform deployment menyediakan SSL
• Sertifikat dapat diterbitkan untuk domain utama
• Subdomain juga tercakup sertifikat
• HTTP dapat dialihkan ke HTTPS
• Tidak ada mixed content
• Asset tidak lagi dipanggil melalui HTTP
• Callback URL sudah menggunakan HTTPS
• Endpoint API menggunakan sertifikat valid
• Sertifikat diperbarui secara otomatis

Jika menggunakan GitHub Pages, custom domain yang dikonfigurasi dengan benar mendukung HTTPS dan HTTPS enforcement.

Untuk proyek dengan banyak subdomain, periksa apakah platform menerbitkan sertifikat satu per satu atau mendukung wildcard certificate.

Bandingkan Ketersediaan dan Kualitas Nama

Setelah struktur proyek dan deployment siap, bandingkan nama yang tersedia dalam versi .cloud dan .dev.

Jangan hanya memeriksa apakah domain bisa didaftarkan. Nilai juga bagaimana nama tersebut akan digunakan dalam terminal, dokumentasi, endpoint API, dan file konfigurasi.

Gunakan pertanyaan berikut:

• Apakah nama proyek tersedia secara utuh?
• Apakah harus menambahkan kata yang tidak berkaitan?
• Apakah domain mudah diketik di terminal?
• Apakah namanya terlalu mirip dengan package lain?
• Apakah mudah terjadi salah ketik?
• Apakah tetap jelas ketika digunakan sebagai subdomain?
• Apakah nyaman dimasukkan ke contoh kode?
• Apakah nama dapat digunakan untuk alamat email?
• Apakah domain sesuai jika proyek memiliki modul tambahan?
• Apakah nama yang sama tersedia di repository dan package registry?

Misalnya, nama proyek utuh mungkin sudah tidak tersedia dalam versi .dev, tetapi masih tersedia dalam versi .cloud.

Kondisi	Kandidat .cloud	Kandidat .dev
Nama proyek tersedia utuh	orion.cloud	orionproject.dev
Domain untuk profil developer	namadeveloper.cloud	namadeveloper.dev
Fokus pada dokumentasi	docs.orion.cloud	orion.dev
Fokus pada platform cloud	orion.cloud	orionplatform.dev
Berisi banyak proyek coding	projects.nama.cloud	nama.dev

Nama pendek yang tersedia secara utuh sering kali lebih praktis daripada nama panjang dengan beberapa kata tambahan.

Cek Nama Sebelum Menentukan Struktur Final

Setelah menemukan susunan yang sesuai, bandingkan ketersediaan domain .CLOUD untuk versi .cloud dan .dev. Pengecekan ini membantu memastikan struktur yang sudah dirancang dapat digunakan tanpa harus mengganti nama proyek atau menambahkan kata yang tidak diperlukan.

Sudah memiliki beberapa kandidat nama?
Periksa ketersediaannya sebelum memperbarui repository, dokumentasi, dan konfigurasi deployment.

Cek Ketersediaan Domain .CLOUD!

Susun Struktur Domain Sebelum Registrasi

Setelah mengecek nama, buat rancangan struktur domain secara tertulis. Langkah ini membantu menentukan apakah kamu membutuhkan satu domain, beberapa subdomain, atau dua domain dengan fungsi berbeda.

Satu Domain untuk Seluruh Portofolio

Struktur ini sesuai jika seluruh proyek masih menjadi bagian dari profil developer.

Domain utama menjadi pusat navigasi. Demo aplikasi dapat ditempatkan pada subdomain hanya jika memang memerlukan deployment terpisah.

Satu Domain untuk Satu Proyek Cloud

Gunakan struktur ini jika proyek memiliki beberapa komponen yang saling terhubung:

Pastikan setiap subdomain memiliki fungsi yang jelas. Jangan membuat app, dashboard, dan console jika ketiganya mengarah ke interface yang sama.

Domain Terpisah untuk Profil dan Proyek

Developer dapat menggunakan dua domain jika profil pribadi dan proyek cloud memiliki kebutuhan berbeda.

Pembagian fungsinya dapat dibuat seperti berikut:

• .dev untuk profil, artikel, dan daftar karya
• .cloud untuk aplikasi, dokumentasi, API, dan status proyek cloud

Tautkan keduanya secara jelas agar pengunjung dapat berpindah dari portofolio menuju proyek dan sebaliknya.

Domain Utama dengan Path

Jika proyek belum membutuhkan domain tersendiri, gunakan path:

Pendekatan ini lebih sederhana untuk proyek awal dan mengurangi jumlah konfigurasi DNS serta sertifikat yang harus dikelola.

Decision Helper Domain .cloud vs .dev

Gunakan tabel berikut untuk menilai pilihan berdasarkan kondisi proyekmu.

Pertanyaan	Arah .cloud	Arah .dev
Apa isi dominan portofolio?	Infrastruktur, cloud, DevOps, deployment, atau monitoring	Aplikasi, library, coding, eksperimen, dan dokumentasi
Domain mewakili apa?	Satu proyek atau platform cloud	Developer atau kumpulan proyek
Bagaimana struktur aksesnya?	Memiliki console, API, status, dan beberapa endpoint	Memiliki profil, demo, docs, dan playground
Apakah proyek berdiri sendiri?	Ya, proyek memiliki layanan dan dokumentasi sendiri	Tidak, proyek masih menjadi bagian dari portofolio
Bagaimana nama tampil di endpoint?	api.proyek.cloud sesuai dengan kelompok layanan cloud	docs.proyek.dev sesuai untuk dokumentasi development
Apakah HTTPS sudah siap?	Tetap harus dikonfigurasi dengan benar	Harus siap sejak domain mulai diakses
Apakah isi akan berkembang?	Tetap berfokus pada ekosistem cloud	Dapat mencakup berbagai disiplin development

Berikan satu poin untuk setiap kolom yang paling sesuai.

Jika skor .cloud lebih tinggi, domain tersebut lebih selaras dengan satu proyek atau ekosistem cloud. Jika skor .dev lebih tinggi, domain tersebut lebih sesuai untuk profil developer dan kumpulan proyek lintas teknologi.

Jika hasilnya seimbang, gunakan .dev sebagai portofolio utama dan .cloud untuk proyek cloud yang berdiri sendiri.

Validasi Teknis Sebelum Menggunakan Domain

Sebelum mengubah alamat di seluruh repository, lakukan validasi terakhir.

Checklist Nama

• Nama proyek tersedia secara utuh
• Nama tidak terlalu panjang
• Tidak menggunakan tanda hubung berlebihan
• Mudah diketik di terminal
• Tidak menyerupai proyek atau package populer
• Tetap terbaca ketika menjadi subdomain
• Sesuai digunakan sebagai endpoint API
• Tidak membingungkan dalam bentuk tunggal dan jamak

Checklist DNS dan Deployment

• Platform mendukung custom domain
• Record DNS dapat diarahkan ke platform
• Domain utama sudah ditentukan
• Redirect dari www atau non-www sudah direncanakan
• Subdomain yang diperlukan sudah dipetakan
• SSL tersedia
• HTTPS redirect dapat diaktifkan
• Preview dan staging dipisahkan
• Domain bawaan platform dialihkan ke domain utama

Checklist Dokumentasi

• Domain dapat dicantumkan di README
• URL tetap ringkas dalam contoh kode
• Dokumentasi mempunyai struktur versi
• Tautan repository mudah ditemukan
• Changelog tersedia
• API reference dipisahkan dari halaman umum
• Domain lama sudah diperbarui di seluruh dokumentasi

Checklist Konfigurasi Aplikasi

• Environment variable menggunakan domain baru
• OAuth callback telah diperbarui
• Webhook mengarah ke endpoint yang benar
• CORS mencantumkan origin baru
• API base URL sudah diperbarui
• Cookie domain sudah diperiksa
• Redirect URI tidak lagi memakai alamat lama
• Package metadata mencantumkan domain baru

Checklist Keamanan

• Dashboard administratif tidak terbuka tanpa autentikasi
• Endpoint internal tidak diekspos secara tidak sengaja
• Secret tidak disimpan di repository
• HTTPS aktif pada semua halaman
• Sertifikat dapat diperbarui otomatis
• Staging tidak dapat diakses tanpa pembatasan jika berisi data pengujian
• Status page tidak menampilkan informasi sensitif

Kesalahan yang Perlu Dihindari

1. Memilih Ekstensi Tanpa Memetakan Isi Portofolio

Domain dapat terasa tidak konsisten jika sebagian besar proyek tidak berkaitan dengan konteks ekstensi yang dipilih.

Periksa minimal lima proyek utama. Jika seluruhnya berada dalam bidang yang berbeda, domain untuk profil umum kemungkinan lebih mudah dipertahankan.

2. Membuat Terlalu Banyak Subdomain

Tidak semua halaman memerlukan subdomain sendiri. Proyek sederhana dapat menggunakan path agar deployment dan sertifikat lebih mudah dikelola.

Gunakan subdomain jika bagian tersebut memiliki aplikasi, sistem deployment, atau fungsi yang benar-benar terpisah.

3. Membuka Dashboard Homelab ke Internet

Dokumentasi homelab dapat dipublikasikan, tetapi dashboard server, storage, dan container perlu dilindungi.

Gunakan autentikasi, VPN, access proxy, atau pembatasan jaringan sesuai kebutuhan.

4. Mengabaikan HTTPS pada Domain .dev

Domain .dev memerlukan kesiapan HTTPS sejak awal. Jangan mengarahkan DNS ke server yang belum memiliki sertifikat valid karena browser akan mencoba menggunakan koneksi HTTPS.

Periksa juga subdomain, callback, webhook, dan asset eksternal.

5. Mengganti Domain tanpa Memperbarui Konfigurasi

Perubahan domain dapat memengaruhi banyak bagian proyek, antara lain:

• Environment variable
• OAuth callback
• Webhook
• CORS
• API endpoint
• Repository
• Dokumentasi
• Package metadata
• Status page
• File konfigurasi deployment

Buat daftar komponen tersebut sebelum melakukan perpindahan.

6. Menggunakan Dua Domain dengan Isi Identik

Jika .cloud dan .dev sama-sama didaftarkan, tentukan satu domain utama.

Domain lainnya dapat diarahkan ke domain utama atau digunakan untuk fungsi berbeda. Hindari menerbitkan dua website identik tanpa pembagian yang jelas.

Jadi, Domain .cloud atau .dev?

Pilihan antara .cloud dan .dev sebaiknya mengikuti bentuk proyek yang ingin kamu publikasikan.

Jika domain menjadi pusat profil dan berbagai hasil coding, .dev dapat masuk dalam daftar pilihan. Ekstensi tersebut sesuai untuk struktur yang memuat aplikasi, library, dokumentasi, eksperimen framework, dan kontribusi open-source.

Jika domain menaungi satu proyek dengan dashboard, API, dokumentasi, monitoring, serta layanan cloud, .cloud dapat memberikan struktur yang lebih kontekstual. Domain utama dapat digunakan sebagai halaman proyek, sedangkan subdomain dipakai untuk memisahkan aplikasi dan endpoint.

Keduanya juga dapat digunakan bersama. .dev dapat menjadi alamat portofolio utama, sedangkan .cloud dipakai untuk proyek cloud yang sudah memiliki ekosistem tersendiri.

Keputusan akhirnya tidak hanya ditentukan oleh ekstensi. Pertimbangkan isi portofolio, jenis proyek, struktur endpoint, kesiapan HTTPS, workflow deployment, dan ketersediaan nama secara keseluruhan.