Sejarah & Evolusi

Sejarah & Evolusi Caddy #

Caddy bukan proyek yang lahir dari keinginan membuat web server baru demi kebaruan semata. Ia adalah respons langsung terhadap frustrasi nyata yang dirasakan developer dan operator selama bertahun-tahun: mengapa mendapatkan HTTPS untuk sebuah website masih harus melalui proses yang panjang, rawan kesalahan, dan membutuhkan intervensi manual berkala? Memahami sejarah Caddy — dari motivasi awal hingga keputusan desain yang paling kontroversial — membantu kita mengerti mengapa setiap bagian dari Caddy dirancang seperti sekarang.

Konteks: Keadaan Web Sebelum Caddy (2015) #

Untuk memahami mengapa Caddy relevan, kita perlu memahami kondisi web server landscape di sekitar tahun 2014–2015.

Nginx sudah sangat matang dan digunakan secara masif, tapi konfigurasinya verbose dan HTTPS masih sepenuhnya manual. Untuk mendapatkan sertifikat TLS, kamu harus membeli dari CA komersial (Comodo, DigiCert, dll.) dengan harga $50–200 per tahun, atau menggunakan self-signed certificate yang akan selalu menampilkan warning di browser.

Apache mendominasi shared hosting karena .htaccess dan mod_php, tapi arsitekturnya sudah menunjukkan usia — MPM prefork yang boros memori dan konfigurasi yang bisa membengkak ratusan baris untuk use case sederhana.

Let’s Encrypt mulai diumumkan di akhir 2014 dan masuk beta publik di November 2015 — tepat bersamaan dengan kemunculan Caddy. Ini bukan kebetulan. Matt Holt, pembuat Caddy, melihat peluang: jika ada protokol standar untuk mendapatkan sertifikat gratis secara otomatis, mengapa web server tidak langsung mengimplementasikannya sebagai fitur inti?

Kelahiran Caddy (April 2015) #

Caddy pertama kali diperkenalkan ke publik oleh Matt Holt pada April 2015. Matt adalah seorang software engineer yang frustrasi dengan kerumitan setup HTTPS dan kompleksitas konfigurasi web server yang ada. Dalam posting blog awalnya, ia memperkenalkan konsep yang saat itu terasa radikal: web server yang mengurus HTTPS sendiri, dengan konfigurasi yang bisa dibaca sekilas.

Rilis pertama Caddy sudah menunjukkan dua DNA yang bertahan hingga sekarang:

  1. HTTPS otomatis — meski implementasi awalnya masih kasar karena Let’s Encrypt sendiri belum GA
  2. Sintaks konfigurasi yang ringkas — Caddyfile yang bisa ditulis dalam satu atau dua baris untuk use case umum

Respons komunitas awal sangat positif. Di Hacker News, thread peluncurannya mendapat ratusan komentar. Banyak developer yang sudah lama merasa kesel dengan kerumitan Nginx merespons dengan antusias. Tapi juga ada skeptisisme yang wajar: “Apakah ini production-ready? Apakah performa-nya sebanding?”

Caddy v1 (2015–2020): Membuktikan Konsep #

Selama lima tahun pertama, Caddy v1 berkembang dari proof-of-concept menjadi tool yang benar-benar digunakan di production oleh ribuan situs.

Pencapaian v1 #

Adopsi Let’s Encrypt yang cepat — ketika Let’s Encrypt GA di April 2016, Caddy sudah siap. Caddy menjadi cara tercepat dan termudah untuk mendapatkan HTTPS gratis, menarik banyak pengguna baru yang sebelumnya menghindari HTTPS karena kerumitannya.

Pertumbuhan ekosistem plugin — komunitas mulai berkontribusi plugin untuk berbagai use case: autentikasi, caching, monitoring, dan sebagainya. Sistem plugin v1 memungkinkan ini meski dengan keterbatasan.

HTTP/2 support — Caddy menjadi salah satu web server pertama yang mengaktifkan HTTP/2 secara default, bahkan sebelum Nginx melakukannya secara default.

Adopsi komersial — berbagai perusahaan mulai menggunakan Caddy di production untuk use case yang sebelumnya membutuhkan setup yang jauh lebih kompleks.

Keterbatasan v1 yang Semakin Terasa #

Seiring bertambahnya pengguna dan semakin kompleksnya use case, keterbatasan arsitektural v1 mulai menjadi masalah nyata:

Konfigurasi statis tanpa API — Caddyfile adalah file teks yang di-parse saat startup. Untuk mengubah konfigurasi, kamu harus mengedit file lalu mengirim signal SIGUSR1 untuk reload. Tidak ada cara untuk melakukan perubahan secara programatik. Ini menjadi bottleneck untuk use case multi-tenant di mana domain perlu ditambah dan dihapus secara dinamis.

# v1: Workflow perubahan konfigurasi
Edit /etc/caddy/Caddyfile
    │
    ▼
kill -SIGUSR1 $(pidof caddy)
    │
    ▼
Caddy reload (semua konfigurasi di-parse ulang)
    │
    ▼
Tidak ada cara tahu apakah reload berhasil selain lihat log

Plugin system yang terbatas — Plugin di v1 harus dikompilasi langsung ke dalam binary Caddy saat build. Tidak ada hot-loading, tidak ada dynamic loading. Pengguna yang butuh plugin harus mencari binary pre-built dengan plugin tersebut atau compile sendiri, yang proses-nya tidak semudah sekarang.

Format konfigurasi tunggal — Hanya ada Caddyfile. Tidak ada representasi data yang bisa di-serialize dan di-deserialize, yang berarti tidak bisa ada API yang bermakna untuk memanipulasi konfigurasi secara programatik.

Tidak ada observability built-in — Tidak ada cara standar untuk query status Caddy yang sedang berjalan: sertifikat apa yang dikelola, upstream mana yang sehat, berapa banyak request yang sedang diproses. Semua informasi ini harus didapat dari log dan tool eksternal.

Penanganan error yang tidak konsisten — Berbagai plugin v1 menangani error dengan cara yang berbeda-beda karena tidak ada interface yang standar.

Keputusan Besar: Penulisan Ulang Total #

Pada tahun 2018–2019, tim Caddy memulai diskusi publik yang panjang tentang masa depan Caddy. Pertanyaan utamanya adalah: haruskah kita memperbaiki masalah v1 secara incremental, atau melakukan penulisan ulang total dengan arsitektur yang benar?

Keputusan yang diambil sangat berani: penulisan ulang total dengan tidak ada backward compatibility dengan v1.

Ini adalah keputusan yang kontroversial. Banyak pengguna v1 merasa tidak nyaman dengan potensi migration pain. Beberapa direktif utama berubah nama (proxy menjadi reverse_proxy, gzip menjadi encode, dll.). Sintaks beberapa bagian berubah cukup signifikan.

Tapi tim Caddy berargumen — dengan benar, seperti terbukti kemudian — bahwa masalah arsitektural v1 tidak bisa diperbaiki dengan patch kecil. Mereka perlu membangun dari fondasi yang berbeda.

Caddy v2 (Mei 2020): API-First Architecture #

Caddy v2 dirilis dalam versi stabil pada Mei 2020, hampir dua tahun setelah diskusi penulisan ulang dimulai. Ini adalah produk yang sangat berbeda dari v1, dengan perubahan fundamental di setiap lapisan.

Perubahan 1: JSON sebagai Format Konfigurasi Native #

Perubahan paling fundamental di v2 adalah menjadikan JSON sebagai representasi internal dari semua konfigurasi. Ini bukan sekadar perubahan format — ini adalah perubahan cara berpikir tentang konfigurasi.

// Konfigurasi Caddy v2 dalam format JSON native
// Ini adalah yang sebenarnya dieksekusi oleh Caddy
{
  "apps": {
    "http": {
      "servers": {
        "main": {
          "listen": [":443"],
          "routes": [
            {
              "match": [{"host": ["example.com"]}],
              "handle": [
                {
                  "handler": "reverse_proxy",
                  "upstreams": [{"dial": "localhost:3000"}]
                }
              ]
            }
          ]
        }
      }
    },
    "tls": {
      "automation": {
        "policies": [{"subjects": ["example.com"]}]
      }
    }
  }
}

Caddyfile masih ada, tapi sekarang ia adalah “adapter” — sebuah layer yang mengkonversi sintaks Caddyfile yang mudah dibaca manusia ke JSON internal. Kamu bisa melihat JSON yang dihasilkan:

caddy adapt --config /etc/caddy/Caddyfile --adapter caddyfile

Implikasi dari ini sangat luas: konfigurasi sekarang adalah data yang bisa di-serialize, di-deserialize, di-compare, dan dimanipulasi oleh program. Ini yang memungkinkan Admin API.

Perubahan 2: Admin API #

Caddy v2 dilengkapi dengan REST API bawaan di localhost:2019. API ini memberikan akses ke seluruh konfigurasi yang sedang berjalan, dan memungkinkan manipulasi parsial tanpa perlu reload seluruh konfigurasi.

# Tambah route baru tanpa restart, tanpa menyentuh Caddyfile
curl -X POST "http://localhost:2019/config/apps/http/servers/main/routes/" \
  -H "Content-Type: application/json" \
  -d '{...}'

# Query status upstream
curl http://localhost:2019/reverse_proxy/upstreams/

# Load konfigurasi baru dari Caddyfile
curl -X POST "http://localhost:2019/load" \
  -H "Content-Type: text/caddyfile" \
  --data-binary @/etc/caddy/Caddyfile

Ini adalah fitur yang tidak ada padanannya di Nginx atau Apache standard.

Perubahan 3: Sistem Modul yang Sesungguhnya #

Di v2, setiap komponen adalah modul Go dengan:

  • Namespace yang unik dan konsisten (http.handlers.reverse_proxy)
  • Interface yang well-defined dan terdokumentasi
  • Registrasi otomatis ke registry global saat init
// Contoh: modul mendaftarkan diri ke Caddy
func init() {
    caddy.RegisterModule(ReverseProxy{})
}

func (ReverseProxy) CaddyModule() caddy.ModuleInfo {
    return caddy.ModuleInfo{
        ID:  "http.handlers.reverse_proxy",
        New: func() caddy.Module { return new(ReverseProxy) },
    }
}

Karena semua komponen mengikuti pattern yang sama, dokumentasi otomatis bisa digenerate, dan developer bisa memahami cara kerja satu modul lalu apply pengetahuan itu ke modul lain.

Perubahan 4: xcaddy #

Bersamaan dengan v2, diperkenalkan juga xcaddy — tool resmi untuk compile Caddy dengan plugin tambahan. xcaddy menyederhanakan proses yang sebelumnya membingungkan menjadi satu perintah:

xcaddy build \
    --with github.com/caddy-dns/cloudflare \
    --with github.com/mholt/caddy-ratelimit

Timeline Lengkap #

2014  │ Let's Encrypt diumumkan
      │
Apr   │ Caddy v1.0 dirilis — "web server dengan HTTPS otomatis"
2015  │ Komunitas merespons antusias
      │
Nov   │ Let's Encrypt masuk beta publik
2015  │ Caddy langsung mengintegrasikan dukungannya
      │
Apr   │ Let's Encrypt GA
2016  │ Caddy menjadi cara termudah untuk HTTPS gratis
      │
2017  │ Caddy menambahkan HTTP/2 push, WebSocket proxy
      │ Kontroversi model lisensi komersial
      │
2018  │ Matt Holt mulai diskusi publik tentang v2
      │ RFC untuk arsitektur baru
      │
2019  │ Caddy v2 beta dirilis
      │ Breaking changes dari v1 — komunitas mulai migrasi
      │
Mei   │ Caddy v2.0 stable dirilis
2020  │ JSON native, Admin API, sistem modul baru
      │
2021  │ xcaddy menjadi standar de facto
      │ Ekosistem DNS modules berkembang pesat
      │
2022  │ caddy-security dirilis (OAuth2, OIDC, LDAP)
      │
2023  │ Caddy 2.7+ — perbaikan performa dan stabilitas
      │
2024  │ Caddy 2.8+ — HTTP/3 improvements, on-demand TLS

Pelajaran dari Evolusi Caddy #

Sejarah Caddy mengandung beberapa pelajaran yang berguna:

Kesederhanaan memiliki harga yang layak dibayar. Keputusan untuk menjadikan HTTPS otomatis sebagai fitur inti — bukan plugin atau addon — membuat banyak hal lain menjadi lebih kompleks di dalam. Tapi harga ini tidak terlihat oleh pengguna akhir, yang hanya merasakan manfaatnya.

Backward compatibility bukan segalanya. Caddy v2 sengaja merusak backward compatibility dengan v1 untuk mendapatkan arsitektur yang lebih baik. Jangka pendek menyakitkan bagi pengguna yang harus migrasi; jangka panjang menghasilkan platform yang jauh lebih kuat.

API-first design membuka kemungkinan yang tidak terduga. Admin API Caddy bukan fitur yang diminta komunitas secara eksplisit di awal — tapi begitu ada, ternyata membuka use case yang sangat berharga seperti platform multi-tenant dan dynamic routing.

Caddy Hari Ini #

Di 2024, Caddy adalah proyek yang sangat matang dengan:

  • Ribuan bintang GitHub dan ratusan kontributor
  • Komunitas aktif di forum Caddy dan Discord
  • Ekosistem plugin yang terus berkembang
  • Adopsi enterprise yang meningkat
Caddy v1 sudah end-of-life dan tidak lagi menerima update keamanan. Jika kamu masih menggunakan v1, sangat disarankan untuk segera migrasi ke v2. Panduan migrasi tersedia di dokumentasi resmi di caddyserver.com/v2-upgrade.

Ringkasan #

  • Caddy lahir April 2015 sebagai respons terhadap frustrasi dengan kerumitan setup HTTPS — bersamaan momentum dengan kemunculan Let’s Encrypt.
  • v1 (2015–2020) berhasil membuktikan konsep HTTPS otomatis dan mendapat adopsi luas, tapi dibatasi oleh arsitektur yang tidak mendukung konfigurasi dinamis atau observability.
  • Keputusan penulisan ulang total di 2018 adalah keputusan berani yang akhirnya terbukti tepat — v2 memiliki arsitektur yang jauh lebih kuat meski ada migration pain jangka pendek.
  • v2 (Mei 2020) membawa perubahan fundamental: JSON native, Admin API, sistem modul yang konsisten, dan xcaddy.
  • Caddyfile tetap ada di v2 sebagai adapter yang mengkonversi ke JSON internal — lebih ekspresif dari v1 dengan sintaks yang sedikit berubah.
  • Caddy v1 sudah EOL — gunakan v2 untuk semua deployment baru.
  • Ekosistem terus berkembang dengan xcaddy, DNS modules, caddy-security, dan plugin komunitas yang aktif.

← Sebelumnya: Apa itu Caddy?   Berikutnya: Caddy vs Nginx →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact