AI Agent yang Deploy Website Sendiri Tanpa Manual

Saya mengetik satu kalimat: "deploy WordPress blog baru". Dua menit kemudian ada situs WordPress hidup di blog.jayax.dev, database siap, nginx proxy terpasang, SSL aktif lewat Cloudflare Tunnel. Saya tidak membuka terminal, tidak membuat database manual, tidak edit config nginx. Sebuah AI agent yang deploy website otomatis melakukan semuanya.

Sistem ini bukan teori. Ini berjalan di mesin saya setiap hari, melayani klien yang butuh situs WordPress, Laravel, dan Next.js di subdomain terpisah. Artikel ini adalah peta lengkap arsitekturnya — bagaimana AI agent yang deploy website otomatis bekerja dari permintaan sampai HTTP 200, keputusan desain yang saya ambil, dan batasan yang masih saya jalani.

TL;DR:

• AI agent hidup di container Docker, deploy website dengan menjatuhkan file perintah ke queue yang dibaca oleh watcher di host Windows
• Satu skrip deploy menangani WordPress, Laravel, dan Next.js — lengkap dengan pembuatan database otomatis dan rule nginx
• Cloudflare Tunnel menjadi satu-satunya pintu masuk — tanpa port forwarding, tanpa IP publik terekspos
• Sistem ini punya batasan jujur: tidak semua hal otomatis, dan beberapa keputusan desain punya trade-off yang harus diterima

Masalahnya bukan deploy, tapi jarak antara niat dan eksekusi

Deploy manual sebuah website WordPress melibatkan 7 langkah yang selalu sama. Buat database, buat user, grant privilege, tulis docker-compose, jalankan container, konfigurasi nginx reverse proxy, reload. Setiap langkah butuh 2-5 menit jika saya fokus. Total 15-30 menit per situs.

Tapi biaya sebenarnya bukan waktu. Biaya sebenarnya adalah atensi. Di tengah pekerjaan lain, konteks switching untuk deploy satu situs mengganggu alur. Hasilnya: saya menunda deploy sampai "nanti", atau lupa langkah karena terburu-buru, atau salah konfigurasi karena mengikuti checklist dari ingatan.

AI agent yang deploy website otomatis menyelesaikan ini dengan cara menghapus jarak antara niat dan eksekusi. Saya bilang "deploy WordPress blog baru", agent menjalankan prosedur yang sudah teruji, dan 2 menit kemudian situsnya hidup. Tanpa konteks switching, tanpa kesalahan manual.

Arsitektur singkat: 5 komponen yang bikin ini jalan

Sistem ini terdiri dari 5 komponen yang masing-masing punya satu tugas spesifik. Berikut diagram alur lengkapnya:

User request (Discord/CLI)
       ↓
  Hermes Agent (container Docker, s6-overlay)
       ↓ tulis file .cmd
  /hermes-queue/  (= C:\hermes-ops\queue\)
       ↓ poller PowerShell (hermes-bridge.ps1, interval ~60s)
       ↓ validasi whitelist + reject metacharacters
       ↓ switch keyword: wsl-deploy | docker-restart | dll
       ↓ eksekusi via wsl.exe atau docker CLI
  deploy.sh (WSL host: ~/ai-stack/scripts/)
       ↓ buat docker-compose.yml per situs
       ↓ CREATE DATABASE db_<nama>, CREATE USER, GRANT
       ↓ docker compose up -d
       ↓ tulis rule nginx, reload
  Cloudflare Tunnel (cloudflared container)
       ↓
  HTTPS://<nama>.jayax.dev — LIVE

1. Hermes Agent (otak)

Agent hidup di container Docker yang diawasi s6-overlay. Dia menerima request dari Discord atau CLI, memahami intent, dan menjalankan prosedur deploy. Detail bagaimana agent belajar tugas ini lewat SKILL.md. Detail teknis bagaimana agent menulis perintah ke host Windows tanpa SSH ada di artikel bridge WSL2.

2. Bridge Queue (jembatan)

Container Docker tempat agent hidup terisolasi dari host Windows. Tapi deploy butuh akses ke Docker Desktop dan WSL di host. Solusinya: drop-file queue. Agent menulis file .cmd ke folder yang di-mount bersama. Watcher PowerShell di host membaca file itu, memvalidasi, dan mengeksekusi. Detail lengkap pola ini ada di artikel menjalankan perintah Windows dari WSL2.

3. Deploy Script (tangan)

Skrip deploy.sh di host WSL menerima argumen jenis framework dan nama situs, lalu melakukan semua langkah deploy: buat compose file, buat database, jalankan container, pasang nginx, reload. Satu skrip untuk tiga framework — WordPress, Laravel, dan Next.js. Cara kerja lengkapnya dibedah di artikel satu skrip tiga framework dan auto-deploy WordPress.

4. Nginx Site-Server (pintu)

Satu instance nginx menjadi reverse proxy untuk semua situs. Setiap situs baru mendapat server block sendiri yang mem-proxy ke port container-nya. Cara kerja dan infrastruktur self-hosting lengkapnya di artikel self-host banyak website.

5. Cloudflare Tunnel (jalur publik)

Container cloudflared membuat tunnel ke edge Cloudflare. Semua traffic publik masuk lewat tunnel ini, diteruskan ke nginx, lalu ke container situs. Tanpa port forwarding, tanpa IP publik terekspos. cloudflared adalah container yang dilindungi — tidak boleh di-stop, karena dia satu-satunya jalur akses remote.

Anatomi satu request, dari kalimat sampai HTTP 200

Mari telusuri satu deploy nyata end-to-end. User meminta deploy WordPress untuk klien "kopi-surgent".

Agent menulis file perintah ke queue:

# /hermes-queue/deploy-wordpress-kopi-surgent.cmd
wsl-deploy wordpress kopi-surgent

Bridge poller (hermes-bridge.ps1) menemukan file .cmd ini. Validasi whitelist: keyword wsl-deploy diizinkan, action wordpress valid, nama kopi-surgent cocok pattern [a-z0-9-]{1,32}. Lalu bridge menjalankan:

cd ~/ai-stack && ./scripts/deploy.sh wordpress kopi-surgent

Skrip deploy.sh membuat direktori /app-stacks/kopi-surgent/, menulis docker-compose.yml dengan image WordPress + MariaDB credentials, lalu membuat database:

CREATE DATABASE IF NOT EXISTS db_kopi-surgent;
CREATE USER IF NOT EXISTS 'db_kopi-surgent'@'%' IDENTIFIED BY '<DB_PASSWORD>';
GRANT ALL PRIVILEGES ON db_kopi-surgent.* TO 'db_kopi-surgent'@'%';
FLUSH PRIVILEGES;

Container WordPress naik, nginx proxy rule ditulis untuk kopi-surgent.jayax.dev, nginx di-reload. Hasilnya ditulis kembali ke queue:

# /hermes-queue/result-deploy-wordpress-kopi-surgent.txt
exit=0
SITE 'kopi-surgent' TERDEPLOY

Agent membaca result file, melaporkan ke user. Total waktu: 60-90 detik untuk polling bridge, 30-60 detik untuk eksekusi deploy. HTTP 200 hidup di https://kopi-surgent.jayax.dev (WordPress fresh install akan redirect ke wp-admin/install.php, yang normal).

Keputusan desain yang saya ambil (dan alternatif yang saya tolak)

Setiap arsitektur adalah rangkaian trade-off. Berikut keputusan utama dan alternatifnya:

Queue file vs SSH ke host. Saya pilih queue file karena blast radius kecil — whitelist command membatasi apa yang bisa dieksekusi, dan setiap perintah tercatat di log. SSH ke host memberi akses penuh shell: sekali agent salah, konsekuensinya besar. Queue file kalah di latency (polling 60 detik), tapi menang di keamanan dan auditability.

Container per situs vs shared container. Container per situs. Setiap situs dapat WordPress instance sendiri, database sendiri (db_<nama>), volume sendiri. Alternatif: satu WordPress multisite dengan satu database. Multisite lebih efisien resource tapi gagal saat satu situs bermasalah — semua situs ikut down. Isolasi lebih mahal di RAM tapi lebih aman.

Database per situs vs shared database. Database per situs, tapi dalam satu instance MariaDB. Buat database baru (db_<nama>) lebih murah daripada jalankan container MariaDB baru per situs. Ini adalah tengah antara isolasi penuh dan efisiensi.

Agent punya akses docker langsung vs lewat skrip terbatas. Agent TIDAK punya akses docker langsung. Agent hanya bisa menulis file perintah ke queue, dan queue hanya menerima keyword yang di-whitelist (wsl-deploy, docker-restart, dll). Skrip deploy yang punya akses docker — bukan agent. Ini memastikan agent tidak bisa, misalnya, menghapus container secara tidak sengaja.

Batasan jujur: apa yang masih belum otomatis

Sistem ini tidak sempurna. Beberapa hal masih manual atau belum terautomasi:

1. WordPress install wizard masih manual. Setelah container hidup dan database siap, user harus membuka URL dan menjalankan wizard instalasi WordPress (memilih bahasa, judul situs, admin user). Agent tidak mengisi form WP install.

2. Migrasi data belum otomatis. Deploy membuat situs kosong. Memindahkan konten dari situs lama (upload files, import database) masih proses manual terpisah. Backup otomatis menutup sebagian, tapi restore ke situs baru belum seamless.

3. Resource limit fisik. Host punya 16GB RAM, ~11GB dialokasikan ke WSL2. Hermes sendiri reserve 6GB. Sisanya cukup untuk 2-3 situs WordPress/Laravel aktif bersamaan. Deploy situs keempat bisa menyebabkan OOM. Skrip deploy belum mengecek kapasitas sebelum mulai.

4. SSL certificate bergantung Cloudflare. Tidak ada Let's Encrypt atau sertifikat lokal. Semua HTTPS lewat Cloudflare Tunnel. Kalau tunnel putus, situs tidak accessible dari publik meskipun container masih jalan di local.

5. Tidak ada rollback otomatis. Kalau deploy gagal di tengah (container naik tapi nginx error), tidak ada mekanisme untuk otomatis undo. Teardown manual (wsl-deploy down <nama>) lalu re-deploy. Saya bahas ini detail di artikel testing pipeline.

6. Monitoring masih dasar. Ada homepage dashboard dan docker stats, tapi tidak ada alerting otomatis kalau situs down. Agent tidak aktif memantau kesehatan situs yang sudah di-deploy.

Apa yang saya pelajari

Membangun sistem ini mengajarkan beberapa hal yang tidak obvious di awal:

Keamanan bukan fitur tambahan, tapi fondasi. Whitelist command di bridge queue adalah hal pertama yang saya bangun, sebelum skrip deploy. Setiap kali saya tergoda untuk menambah "shortcut" yang melewati whitelist, saya ingat bahwa agent adalah program otonom yang bisa salah dengan cara yang tidak terduga.

Otomatisasi yang baik menghilangkan keputusan, bukan menambahnya. Skrip deploy punya interface minimal: jenis framework + nama. Tidak ada 20 flag konfigurasi. Konvensi (database db_<nama>, container <nama>, subdomain <nama>.jayax.dev) menghilangkan kebutuhan untuk memilih.

Container yang dilindungi menyelamatkan sistem. Dua container — hermes dan cloudflared — di-hard-block dari stop/down di whitelist bridge. Tanpa ini, satu perintah agent yang salah bisa memutus satu-satunya jalur akses remote ke sistem.

Latency polling bukan masalah. Awalnya saya khawatir 60 detik polling terlalu lambat. Ternyata untuk operasi deploy (yang memang butuh menit untuk build container), 60 detik queue delay tidak signifikan. Kepentingan reliability jauh mengalahkan latency.

Langkah berikutnya

Artikel ini adalah pengenalan. Setiap komponen punya artikel deep-dive sendiri:

• Mau paham cara agent menjalankan perintah di host Windows tanpa SSH? Baca cara menjalankan perintah Windows dari WSL2 dengan drop-file queue bridge.
• Mau tahu bagaimana agent belajar tugas deploy lewat file SKILL.md? Baca skill engineering: mengajari AI agent lewat SKILL.md.
• Mau ikut deploy WordPress dari nol sampai live? Baca auto-deploy WordPress dengan Docker dan MariaDB.
• Mau lihat satu skrip yang menangani tiga framework? Baca satu skrip deploy untuk WordPress, Laravel, dan Next.js.
• Mau bangun infrastruktur self-hosting sendiri? Baca self-host puluhan website di satu server dengan Cloudflare Tunnel.
• Mau pastikan data aman? Baca backup database MariaDB otomatis untuk homelab.
• Mau uji pipeline deploy end-to-end? Baca blueprint uji pipeline deploy otomatis.

Mulai dari artikel bridge WSL2 jika ingin memahami fondasi komunikasi agent-host, atau langsung ke auto-deploy WordPress jika ingin melihat hasil akhirnya.