Studi Kasus — Setup Dual-Laptop
Halaman ini bukan rekomendasi hardware dari kitab — murni penerapan seluruh urutan playbook ke situasi konkret: kebetulan punya dua laptop dengan profil sangat berbeda.
- MacBook Pro 16" Intel i9, 32GB RAM (2019) — bertenaga, tidak portable, boros baterai/panas.
- MacBook Pro 13" Apple Silicon M1, 8GB RAM (2020) — ringan, portable, RAM terbatas untuk kerja berat.
Pemetaan peran dulu, sebelum setup apapun
| Laptop | Peran | Alasan |
|---|---|---|
| i9 16" / 32GB | Runner — mesin kerja berat | RAM besar cocok untuk Docker multi-service, database lokal, test suite penuh, dan menjalankan agent otonom jangka panjang. Karena tidak portable, biarkan menetap di satu tempat, selalu menyala + tercolok charger. |
| M1 13" / 8GB | Daily driver — control plane | Portable, baterai tahan lama, cukup untuk koding ringan, review PR, dan mengontrol agent yang jalan di i9 lewat jaringan privat. |
Dengan peran yang jelas, ikuti playbook secara berurutan — jangan loncat ke langkah remote sebelum fondasi repo dan agent selesai.
Langkah 1 — Persiapan repo (sama seperti satu mesin)
Ikuti Langkah 1 — Persiapan Repo seperti biasa. Dua catatan khusus untuk setup dual-mesin:
Lockfile dan native binding: hindari commit package-lock.json / yarn.lock yang menyimpan hash architecture-specific tanpa menguji install di kedua mesin. Dependency native (misalnya sharp, bcrypt, binding FFI) sering resolve binary berbeda per arsitektur. Cara aman:
# setelah install di M1 (arm64), uji install dari scratch di i9:
ssh <user>@i9-runner.tailnet-name.ts.net
cd <repo>
rm -rf node_modules && npm ci
npm run check && npm test
Docker image platform: kalau target deploy akhirnya Linux x86_64 (VPS umum, CI default), build eksplisit:
docker build --platform linux/amd64 -t myapp .
Image dari M1 (arm64) tanpa flag ini akan gagal di server x86_64.
Checkpoint: npm ci && npm run check && npm test lolos di kedua laptop dari clone bersih, termasuk Docker build dengan platform eksplisit kalau relevan.
Langkah 2 — Setup jaringan antar-laptop (Tailscale)
Sebelum install agent, sambungkan dua mesin dulu — ini fondasi untuk semua akses remote setelahnya.
Install Tailscale di kedua mesin:
# Di kedua laptop
brew install tailscale
sudo tailscale up
Di i9 (sebagai runner), aktifkan SSH via Tailscale dan matikan SSH publik:
tailscale up --ssh
Dari M1:
ssh <user>@i9-runner.tailnet-name.ts.net
Checkpoint: SSH dari M1 ke i9 berhasil via Tailscale; nmap dari jaringan luar tidak menemukan port 22 i9.
Langkah 3 — Setup agent CLI di kedua mesin
Ikuti Langkah 2 — Setup Agent di kedua laptop. Catatan arsitektur:
- Di M1 (arm64): install versi native arm64. Sebagian besar tool modern (Node, runtime agent CLI seperti opencode, oh-my-pi, maupun Claude Code) sudah punya build arm64 — cek dokumentasi tool-mu.
- Di i9 (x86_64/Intel): pastikan tidak salah unduh binary arm64. Dependency native (
node-gyp, binding C++) perlu di-build ulang untuk x86_64.
Permission model: M1 vs i9 punya profil berbeda
| Mesin | Mode pakai | Permission |
|---|---|---|
| M1 (control plane) | Interaktif, kamu di depannya | Standar + konfirmasi untuk yang berbahaya — ikuti tab di setup-agent.mdx |
| i9 (runner) | Sering tanpa pengawasan langsung | Lebih ketat — kalau agent otonom: wajib di dalam container (lihat Langkah 5) |
Hindari mode bypass / skip-permissions di luar container, terutama di i9.
Checkpoint: agent di M1 dan i9 masing-masing bisa menyelesaikan task uji end-to-end — kode berubah, test baru ada, npm run check + npm test hijau, commit rapi.
Langkah 4 — Remote: hubungkan M1 ke i9
Dengan dua mesin siap, ikuti Langkah 3 — Pilih Control Plane Remote. Peta jalur untuk dual-laptop:
| Jalur | Cara konkret |
|---|---|
| A. Native remote | Kalau tool yang dipakai punya fitur remote bawaan, aktifkan dari i9 — kontrol sesi dari M1 atau HP tanpa terminal manual. |
| E. Terminal DIY | ssh i9-runner.tailnet-name.ts.net lalu tmux new -s work — task tetap jalan walau koneksi putus. Ini jalur paling sederhana dan cukup untuk mulai. |
Alur kerja harian:
- Kerja ringan / mobile → langsung di M1: editing, review PR, ngobrol dengan agent untuk task kecil.
- Butuh compute besar → dari M1, buka sesi ke i9 via SSH + tmux (Jalur E) atau native remote kalau tool mendukung (Jalur A).
- Opsional: kalau ingin build/test otomatis tiap push, lanjut ke CI/CD dengan Agent.
Checkpoint: dari M1 (atau HP), kamu bisa memulai agent task di i9 dan menyetujui permission request — tanpa membuka tutup laptop i9.
Langkah 5 — Jadikan i9 runner yang aman untuk otonom
Kalau kamu ingin i9 menjalankan agent tanpa pengawasan langsung (cron, webhook, bridge chat), ikuti pola dari Self-Hosted Runner 24/7 — diterapkan ke i9 lokal, bukan VPS.
5a. User terpisah untuk agent
# di i9, sebagai admin
sudo dscl . -create /Users/agent
sudo dscl . -create /Users/agent UserShell /bin/zsh
sudo dscl . -create /Users/agent NFSHomeDirectory /Users/agent
sudo createhomedir -c -u agent
# JANGAN beri akses admin
Semua proses agent otonom berjalan sebagai user agent. Kredensial deploy production tidak disimpan di user ini.
Checkpoint: sudo -u agent sudo whoami gagal.
5b. Jalankan bridge/service sebagai launchd (macOS)
tmux untuk eksperimen interaktif; launchd untuk yang harus survive reboot:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key> <string>dev.agentbridge</string>
<key>ProgramArguments</key>
<array>
<string>/Users/agent/bridge/start.sh</string>
</array>
<key>RunAtLoad</key> <true/>
<key>KeepAlive</key> <true/>
<key>WorkingDirectory</key> <string>/Users/agent/bridge</string>
<key>StandardOutPath</key> <string>/tmp/agentbridge.out.log</string>
<key>StandardErrorPath</key><string>/tmp/agentbridge.err.log</string>
</dict>
</plist>
launchctl load ~/Library/LaunchAgents/dev.agentbridge.plist
5c. Isolasi agent otonom dalam container
Untuk agent yang berjalan tanpa pengawasan — agent bekerja di dalam container yang hanya melihat repo dan tool yang dibutuhkan:
docker run --rm \
-v /Users/agent/repos/proyek:/workspace \
-w /workspace \
--memory 2g --pids-limit 256 \
--network bridge \
-e MODEL_API_KEY \
node:22-bookworm \
npx -y <agent-cli> -p "jalankan triage harian sesuai AGENTS.md" \
--skip-permissions # nama flag bervariasi per tool — cek docs masing-masing
:::tip Mode bypass hanya di dalam sandbox Mode "skip permissions" yang membuat agent otonom produktif hanya boleh dipakai di dalam container — blast radius-nya dinding container, bukan seluruh mesin i9. Pola yang sama berlaku untuk tool agent apapun yang kamu pakai. :::
Checkpoint: dari dalam container, agent tidak bisa membaca ~/.ssh maupun repo lain di i9.
Langkah 6 — Monitoring runner i9
Runner yang mati diam-diam = agent yang bolos tanpa kabar. Ikuti pola dari Langkah 7 — Monitoring, minimum untuk i9 lokal:
- Heartbeat: cron tiap jam kirim status ke channel chat-mu — atau pakai healthchecks.io yang alert saat ping tidak datang.
- Log per hari: semua output agent ke file supaya bisa audit "apa saja yang dia lakukan semalam".
# tambahkan ke crontab user agent (crontab -e)
0 * * * * curl -fsS -m 10 https://hc-ping.com/<UUID> \
-d "i9 hidup — disk: $(df -h /Users/agent | awk 'NR==2{print $5}')" > /dev/null 2>&1
Checkpoint: matikan bridge service secara sengaja → alert datang dalam beberapa menit tanpa membuka laptop.
Rangkuman urutan setup
[L1: Persiapan repo] → [L2: Tailscale] → [L3: Agent CLI] → [L4: Remote control] → [L5: User + container] → [L6: Monitoring]
:::warning Jangan loncat ke L5 sebelum L3 selesai Agent otonom di mesin yang belum dikalibrasi hanya memperbesar blast radius kesalahan, bukan produktivitas. :::