Caddy vs Apache

Caddy vs Apache #

Apache HTTP Server adalah salah satu perangkat lunak open source paling berpengaruh dalam sejarah internet. Didirikan pada 1995 dan mendominasi web server market selama lebih dari satu dekade, Apache membangun fondasi dari banyak praktik web hosting modern. Ekosistemnya yang sangat matang — dari module system yang luas hingga dukungan .htaccess yang menjadi standar de facto di shared hosting — membuatnya masih sangat relevan dan masih digunakan oleh jutaan website hari ini.

Caddy hadir dengan pendekatan yang berbeda secara fundamental: modern, cloud-native, dan berorientasi pada kemudahan operasional. Memahami perbedaan di antara keduanya penting agar kamu bisa memilih tool yang tepat, bukan sekadar yang paling populer.

Perbedaan Filosofi #

Apache lahir di era di mana fleksibilitas maksimum adalah prioritas utama. Modulnya bisa di-load dan di-unload secara dinamis, konfigurasinya bisa di-override per direktori via .htaccess, dan hampir setiap aspek perilakunya bisa dikontrol oleh operator bahkan oleh end-user aplikasi. Apache adalah “Swiss Army Knife” dari web server — bisa melakukan hampir apa saja, tapi membutuhkan pengetahuan yang dalam untuk dikonfigurasi dengan baik.

Caddy lahir dengan pertanyaan yang berbeda: “Apa konfigurasi default yang paling baik untuk web server modern?” Ini menghasilkan tool yang memiliki opini kuat tentang apa yang seharusnya dilakukan secara otomatis (HTTPS, security headers, log JSON) dan mengekspos konfigurasi yang benar-benar perlu dikontrol user.

Arsitektur Concurrency — Goroutine vs MPM #

Perbedaan teknis yang paling fundamental antara Caddy dan Apache adalah bagaimana mereka menangani koneksi simultan.

Apache: Multi-Processing Modules (MPM) #

Apache memiliki tiga model concurrency yang disebut MPM:

MPM Prefork — Model paling lama dan paling aman. Setiap request ditangani oleh satu proses Unix terpisah. Proses-proses ini di-fork di awal (pre-fork) dan menunggu request.

Apache MPM Prefork:

Master Process
    │
    ├─ Worker Process 1  ← Request A
    ├─ Worker Process 2  ← Request B
    ├─ Worker Process 3  ← Request C
    └─ Worker Process 4  ← (menunggu)

Karakteristik:
  + Sangat stabil — crash di satu proses tidak mempengaruhi yang lain
  + Kompatibel dengan mod_php (non-thread-safe)
  - Sangat boros memori — setiap proses ~30–50MB
  - Tidak bisa menangani banyak concurrent connections

MPM Worker — Menggunakan kombinasi proses dan thread. Setiap proses memiliki beberapa thread yang masing-masing bisa menangani satu request.

Apache MPM Worker:

Master Process
    │
    ├─ Worker Process 1
    │   ├─ Thread 1  ← Request A
    │   ├─ Thread 2  ← Request B
    │   └─ Thread 3  ← Request C
    │
    └─ Worker Process 2
        ├─ Thread 1  ← Request D
        └─ Thread 2  ← (menunggu)

Karakteristik:
  + Lebih efisien dari prefork
  + Bisa menangani lebih banyak concurrent connections
  - Tidak kompatibel dengan mod_php non-thread-safe
  - Thread overhead masih cukup signifikan

MPM Event — Paling modern. Menggunakan model event-driven untuk koneksi keep-alive, hanya menggunakan thread untuk request yang aktif memproses.

Apache MPM Event:

Master Process
    │
    └─ Event Manager (mengelola semua koneksi keep-alive)
        │
        └─ Thread Pool (hanya aktif saat request diproses)
            ├─ Thread 1  ← Request A (sedang diproses)
            └─ Thread 2  ← Request B (sedang diproses)
            # Ribuan koneksi keep-alive dikelola tanpa thread

Karakteristik:
  + Sangat efisien untuk keep-alive
  + Bisa menangani banyak concurrent connections
  - Lebih kompleks dikonfigurasi

Caddy: Goroutine Go #

Caddy menggunakan model concurrency Go yang berbeda secara fundamental dari thread model Apache:

Caddy (Go Goroutines):

Runtime Go
    │
    └─ Goroutine Pool (dikelola oleh Go runtime scheduler)
        ├─ Goroutine 1  ← Request A
        ├─ Goroutine 2  ← Request B
        ├─ Goroutine 3  ← Request C
        ...
        └─ Goroutine N  ← Request N

Karakteristik:
  + Goroutine sangat ringan — ~2KB stack memory awal
    (vs ~2MB untuk thread OS)
  + Go runtime otomatis menjadwalkan goroutine ke CPU core
  + Bisa menangani ratusan ribu concurrent connections
  + Tidak ada perbedaan performa antara goroutine pertama dan ke-100.000

Implikasi praktis: untuk workload dengan banyak concurrent connections (long-polling, WebSocket, API dengan banyak user simultan), Caddy menggunakan jauh lebih sedikit memori dibanding Apache MPM Worker/Prefork. Apache MPM Event lebih kompetitif, tapi masih memiliki overhead thread yang lebih tinggi dari goroutine.

.htaccess — Fitur yang Tidak Ada Padanannya #

.htaccess adalah fitur yang paling sering disebutkan saat membandingkan Apache dengan web server lain — dan dengan alasan yang bagus. Tidak ada padanan langsung .htaccess di Caddy atau Nginx.

Apa itu .htaccess? #

.htaccess adalah file konfigurasi per-direktori yang bisa ditempatkan di mana saja dalam direktori web server. Ketika Apache memproses request untuk file di /var/www/html/blog/, ia akan membaca dan mengeksekusi semua .htaccess di sepanjang path: /var/www/.htaccess, /var/www/html/.htaccess, dan /var/www/html/blog/.htaccess.

/var/www/
  ├── .htaccess              ← Dibaca untuk semua request
  └── html/
        ├── .htaccess        ← Dibaca untuk request ke /html/
        ├── index.html
        └── blog/
              ├── .htaccess  ← Dibaca untuk request ke /html/blog/
              └── index.html

Ini memungkinkan konfigurasi per-direktori yang sangat granular — setiap subdirektori bisa memiliki konfigurasi sendiri.

Kenapa .htaccess Sangat Penting untuk Shared Hosting? #

Di shared hosting, puluhan atau ratusan website berbagi satu instance Apache. Server admin tidak bisa memberikan akses ke file konfigurasi Apache utama ke setiap customer. .htaccess menjadi solusi: setiap customer bisa mengkonfigurasi web server untuk direktori mereka sendiri tanpa mempengaruhi customer lain.

# .htaccess untuk WordPress
# Customer bisa menaruh ini tanpa perlu akses ke server
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /

    # Jangan redirect untuk file yang ada
    RewriteRule ^index\.php$ - [L]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d

    # Semua request lain ke index.php
    RewriteRule . /index.php [L]
</IfModule>

# Custom error pages
ErrorDocument 404 /404.html
ErrorDocument 500 /500.html

# Cache control untuk asset statis
<IfModule mod_expires.c>
    ExpiresActive on
    ExpiresByType text/css "access plus 1 year"
    ExpiresByType application/javascript "access plus 1 year"
</IfModule>

Implikasi untuk Caddy #

Caddy tidak mendukung .htaccess. Semua konfigurasi harus ada di Caddyfile utama. Ini memiliki konsekuensi yang sangat signifikan:

# ANTI-PATTERN: Tidak ada cara melakukan ini di Caddy
# (tidak ada equivalen .htaccess per-direktori)

# BENAR: Semua konfigurasi harus di Caddyfile utama
example.com {
    root * /var/www/html
    
    # WordPress URL rewriting — harus di Caddyfile, bukan per-direktori
    @notFile {
        not file
        not path /wp-admin/* /wp-includes/*
    }
    rewrite @notFile /index.php
    
    php_fastcgi unix//run/php/php8.2-fpm.sock
    
    encode gzip
    
    file_server
}

Caddy tidak mendukung .htaccess. Ini adalah perbedaan yang tidak bisa disiasati. Jika kamu:

  • Mengoperasikan shared hosting platform
  • Memiliki banyak aplikasi yang menggunakan .htaccess untuk URL rewriting atau konfigurasi lainnya
  • Butuh kemampuan konfigurasi per-direktori oleh pengguna non-admin

…maka Apache adalah pilihan yang lebih tepat, dan migrasi ke Caddy akan membutuhkan usaha yang signifikan.

PHP — Dua Pendekatan yang Berbeda #

Apache dan Caddy mengambil pendekatan yang berbeda untuk menjalankan PHP.

Apache: mod_php (PHP sebagai modul Apache) #

# Apache dengan mod_php
# PHP berjalan di dalam proses Apache — terintegrasi langsung

<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/html

    <FilesMatch \.php$>
        SetHandler application/x-httpd-php
    </FilesMatch>

    # PHP interpreter langsung tersedia di proses Apache
    # Konfigurasi PHP via php.ini atau .htaccess
</VirtualHost>

Keuntungan mod_php:

  • Setup sederhana — install libapache2-mod-php dan PHP langsung bekerja
  • Tidak perlu process manager terpisah
  • PHP bisa dikonfigurasi via .htaccess per-direktori

Kelemahan mod_php:

  • PHP berjalan dengan user dan permission yang sama dengan Apache
  • Restart Apache = restart PHP engine
  • Hanya kompatibel dengan MPM Prefork (non-thread-safe)
  • PHP dan Apache menjadi tightly coupled

Caddy: PHP-FPM via FastCGI #

# Caddy dengan PHP-FPM
# PHP berjalan sebagai proses terpisah, berkomunikasi via socket/TCP

example.com {
    root * /var/www/html
    
    # php_fastcgi adalah shorthand untuk konfigurasi FastCGI ke PHP-FPM
    php_fastcgi unix//run/php/php8.2-fpm.sock
    
    file_server
}

PHP-FPM (FastCGI Process Manager) menjalankan PHP sebagai proses yang terpisah dari web server. Keuntungannya:

  • Isolasi — crash di PHP tidak mempengaruhi Caddy
  • User berbeda — PHP bisa berjalan sebagai user yang berbeda dari web server (lebih aman)
  • Process management — FPM punya mekanisme restart, spawning, dan throttling yang canggih
  • Performa lebih baik untuk high concurrency karena Caddy dan PHP masing-masing bisa dioptimalkan sendiri
  • Kompatibel dengan semua MPM karena tidak ada direct coupling dengan Apache
Arsitektur dengan mod_php (Apache):        Arsitektura dengan PHP-FPM (Caddy):
──────────────────────────────             ─────────────────────────────────

Apache Process                             Caddy Process
  │                                          │
  ├─ Worker (Apache + PHP)                   ├─ Handler (Caddy saja)
  ├─ Worker (Apache + PHP)                   └─ FastCGI proxy ──→ PHP-FPM Process
  └─ Worker (Apache + PHP)                                          ├─ PHP Worker
                                                                    ├─ PHP Worker
                                                                    └─ PHP Worker

Menariknya, PHP-FPM sebenarnya adalah pendekatan yang lebih modern dan lebih baik dari mod_php — bahkan banyak deployment Apache modern sudah beralih dari mod_php ke PHP-FPM. Jadi untuk use case PHP, Caddy menggunakan pendekatan yang “lebih benar” secara arsitektural.

Perbandingan Konfigurasi PHP #

# Apache + mod_php untuk aplikasi Laravel
<VirtualHost *:443>
    ServerName laravel.example.com
    DocumentRoot /var/www/laravel/public

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/laravel.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/laravel.example.com/privkey.pem

    <Directory /var/www/laravel/public>
        AllowOverride All
        Require all granted

        <IfModule mod_rewrite.c>
            Options -MultiViews -Indexes
            RewriteEngine On

            # Handle Authorization Header
            RewriteCond %{HTTP:Authorization} .
            RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

            # Redirect Trailing Slashes If Not A Folder...
            RewriteCond %{REQUEST_FILENAME} !-d
            RewriteCond %{REQUEST_URI} (.+)/$
            RewriteRule ^ %1 [L,R=301]

            # Send Requests To Front Controller...
            RewriteCond %{REQUEST_FILENAME} !-d
            RewriteCond %{REQUEST_FILENAME} !-f
            RewriteRule ^ index.php [L]
        </IfModule>
    </Directory>
</VirtualHost>

# Caddy + PHP-FPM untuk aplikasi Laravel
laravel.example.com {
    root * /var/www/laravel/public
    
    php_fastcgi unix//run/php/php8.2-fpm.sock
    
    encode gzip
    file_server
}

Caddy secara otomatis menangani URL rewriting yang umum untuk PHP apps — php_fastcgi directive sudah menyertakan try_files logic yang diperlukan.

Performa #

Benchmark perbandingan (data umum):

Static file serving:
  Apache MPM Event  ████████████████████  Sangat baik
  Caddy             ████████████████████  Sebanding
  
PHP dengan PHP-FPM (keduanya menggunakan PHP-FPM):
  Apache            ████████████████████  Sebanding
  Caddy             ████████████████████  Sebanding
  Bottleneck ada di PHP, bukan web server

High concurrency (10k+ concurrent connections):
  Apache MPM Prefork  ████░░░░░░░░░░░░░░  Tidak cocok
  Apache MPM Event    ████████████████░░  Baik
  Caddy               ████████████████████  Sangat baik (goroutine)

Kapan Memilih Masing-masing #

Pilih Caddy jika:
  ✓ Deployment VPS/cloud baru tanpa legacy .htaccess
  ✓ Kamu ingin HTTPS otomatis tanpa Certbot
  ✓ Tim tidak familiar dengan Apache dan tidak mau belajar
  ✓ Kamu butuh konfigurasi dinamis via Admin API
  ✓ Arsitektur modern dengan PHP-FPM
  ✓ High concurrency workload

Pilih Apache jika:
  ✗ Kamu mengoperasikan shared hosting platform
  ✗ Banyak aplikasi legacy menggunakan .htaccess
  ✗ Tim sudah sangat familiar dengan ekosistem Apache
  ✗ Kamu butuh mod_php untuk legacy application
  ✗ Kamu menggunakan modul Apache spesifik yang tidak ada padanannya

Ringkasan #

  • Apache unggul dalam ekosistem matang, .htaccess per-direktori, mod_php untuk legacy apps, dan dominasi shared hosting.
  • Caddy unggul dalam HTTPS otomatis, konfigurasi modern, concurrency tinggi via goroutine, dan kemudahan operasional.
  • .htaccess tidak ada padanannya di Caddy — ini adalah perbedaan fundamental yang tidak bisa disiasati.
  • PHP-FPM yang digunakan Caddy sebenarnya lebih modern dari mod_php Apache — arsitektur yang lebih baik dengan isolasi dan performa yang lebih baik.
  • Performa keduanya sebanding untuk sebagian besar workload PHP — bottleneck ada di PHP, bukan web server.
  • Untuk green-field deployment di VPS atau cloud, Caddy lebih mudah dioperasikan. Untuk shared hosting, Apache adalah standar yang tidak tergantikan.

← Sebelumnya: Caddy vs Nginx   Berikutnya: Arsitektur Caddy →

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