Managed Cloud, VPS, atau Lokal

Kalau trigger datang saat laptop mati, setup lokal yang mulus saat demo tetap gagal menjalankan pekerjaannya.

Kalimat itu terdengar obvious. Namun, banyak keputusan infrastruktur dimulai dari setup yang paling cepat dicoba, lalu dianggap otomatis cocok untuk operasi. Demo lokal berjalan, workflow terlihat promising, dan baru belakangan tim sadar agent seharusnya menerima trigger ketika perangkat pengguna sedang offline.

Kebalikannya juga sering terjadi. Pekerjaan sederhana langsung dipindahkan ke server karena terasa lebih serius, padahal tim belum membutuhkan ketersediaan 24/7 dan belum siap merawat infrastrukturnya.

Managed cloud, VPS, dan komputer lokal bukan tangga kematangan. Ketiganya menjawab kebutuhan berbeda tentang ketersediaan, akses, kontrol, dan tanggung jawab pengelolaan.

Managed Cloud: Mengurangi Urusan Runtime, Bukan Menghapus Tata Kelola

Pada layanan managed, penyedia menangani sebagian besar infrastruktur. Pengguna biasanya mengakses kemampuan lewat web, desktop, perangkat seluler, atau aplikasi resmi yang tersedia.

Pilihan ini masuk akal ketika tim ingin mulai tanpa mengelola server, deployment, dan pembaruan runtime sendiri. Proses awalnya dapat lebih sederhana, terutama jika alur kerja sesuai dengan konektor dan lingkungan yang sudah didukung.

Konsekuensinya, batas lingkungan mengikuti kemampuan penyedia. Lokasi pemrosesan, batas penggunaan, integrasi, model, dan cara akses bergantung pada layanan serta konfigurasi yang dipilih. Akses ke file atau aplikasi lokal juga perlu jalur yang memang disediakan.

Managed tidak berarti tim bebas dari pekerjaan pengendalian. Kebijakan ruang kerja, konektor, kredensial, izin, batas data, dan persetujuan tetap harus dirancang. Penyedia dapat mengelola infrastrukturnya, tetapi tidak otomatis memahami siapa di organisasi lo yang boleh mengirim email, membaca folder tertentu, atau mengubah catatan pelanggan.

Gunakan managed cloud ketika kemudahan dan beban operasional yang lebih ringan lebih penting daripada kontrol penuh atas runtime, selama kebutuhan data dan aksesnya terpenuhi.

VPS: Ketersediaan dan Kontrol dengan Tanggung Jawab Operasional

VPS atau server sendiri relevan ketika agent self-hosted perlu tetap aktif, menerima pemicu terjadwal, atau tersedia melalui kanal pesan walaupun perangkat pengguna mati.

Tim bisa memiliki kontrol lebih besar atas runtime, penyedia model, penyimpanan, jaringan, dan integrasi. Lingkungannya dapat disesuaikan dengan kebutuhan alur kerja yang tidak tersedia pada layanan managed.

Namun, kontrol tersebut bukan bonus tanpa biaya. Ada deployment, pembaruan, firewall, kredensial, pencadangan, pencatatan, pemantauan, pemulihan, dan penelusuran masalah. Ketika dependensi berubah atau layanan berhenti, seseorang perlu tahu apa yang harus diperiksa.

Self-hosting juga tidak otomatis membuat data aman. Misconfiguration dapat membuka port, membocorkan secret, atau memberi agent permission terlalu luas. Server yang berjalan terus-menerus memperpanjang window ketika masalah bisa terjadi.

Sebelum memilih VPS, tentukan owner operasionalnya. Siapa yang menerima alert? Bagaimana backup diuji? Bagaimana credential dirotasi? Apa yang terjadi kalau integrasi eksternal gagal setelah sebagian action selesai?

VPS fit ketika availability dan kontrolnya memang dibutuhkan, serta tim siap memiliki pekerjaan operasional tersebut.

Lokal: Dekat dengan Resource, Terikat pada Perangkat

Runtime lokal punya keunggulan saat agent perlu bekerja dekat dengan file, repository, terminal, atau aplikasi di komputer user. Setup ini dapat memberi visibility langsung terhadap environment yang sedang dipakai.

Untuk coding atau pekerjaan yang berlangsung dalam sesi aktif, ketergantungan pada perangkat mungkin bukan masalah. User memang sedang ada di depan komputer dan dapat melihat perubahan sebelum menyetujuinya.

Constraint-nya jelas: agent hanya tersedia ketika perangkat menyala, terhubung, dan runtime berjalan. Laptop tidur, koneksi terputus, atau aplikasi ditutup bisa menghentikan workflow.

Permission lokal juga perlu sangat diperhatikan. Akses terminal atau filesystem dapat berdampak besar. Batasi folder, repository, command, dan credential sesuai pekerjaan. Jangan memberi akses seluruh mesin hanya karena setup awal terasa lebih gampang.

Lokal juga bukan sinonim dari pemrosesan offline. Jika model atau tools memakai provider eksternal, sebagian data dapat keluar mengikuti konfigurasi tersebut. Petakan jalur data secara konkret, bukan dari label deployment saja.

Enam Pertanyaan untuk Mempersempit Pilihan

Daripada mulai dari preferensi teknis, jawab pertanyaan berikut.

1. Kapan agent harus aktif?

Kalau hanya dipakai saat user bekerja, lokal mungkin cukup. Kalau harus menerima trigger ketika semua laptop mati, pertimbangkan runtime yang terus tersedia.

2. Resource berada di mana?

File lokal, repository, database internal, SaaS, dan messaging channel punya jalur akses berbeda. Pilih environment yang bisa mencapai resource tanpa membuka permission berlebihan.

3. Siapa yang memberi instruksi?

Engineer di terminal, manager lewat web, dan tim lapangan lewat chat membutuhkan interface serta approval experience yang berbeda.

4. Siapa yang merawat runtime?

Kalau jawabannya tidak ada, server sendiri dapat menjadi liability. Kalau ada owner yang clear, kontrol tambahan mungkin worth it.

5. Apa batas data dan keamanannya?

Tentukan data apa yang boleh diproses di lingkungan tertentu, kredensial apa yang digunakan, dan tindakan apa yang membutuhkan manusia.

6. Apa kemungkinan kegagalannya?

Pikirkan laptop mati, server berhenti, permintaan API melewati batas waktu, penyimpanan penuh, token kedaluwarsa, dan tindakan yang hanya selesai separuh. Setup terbaik adalah yang kegagalannya bisa dideteksi dan dipulihkan sesuai kebutuhan bisnis.

Arsitektur Campuran Boleh, tetapi Jangan Jadi Default

Agent dapat berjalan di VPS untuk menerima instruksi, lalu meneruskan action tertentu ke environment lain yang punya resource relevan. Managed service juga dapat dipakai bersama komponen lokal.

Kombinasi ini kadang diperlukan. Ia juga menambah network boundary, credential, dependency, dan titik gagal. Setiap perpindahan perlu observability serta rule tentang apa yang terjadi ketika salah satu komponen unavailable.

Jangan membuat arsitektur hybrid hanya karena semua opsi terlihat menarik. Gunakan ketika requirement-nya memang tidak dapat dipenuhi dengan setup yang lebih sederhana.

Pilih Setup Paling Sederhana yang Memenuhi Constraint

Tidak ada deployment target yang selalu menang.

Managed cloud cocok ketika tim mengutamakan kemudahan operasional dan platform memenuhi kebutuhan aksesnya. VPS cocok ketika agent perlu selalu tersedia dan tim siap menjaga infrastrukturnya. Lokal cocok ketika pekerjaan bergantung pada resource perangkat dan availability penuh bukan kebutuhan utama.

Keputusan ini sebaiknya datang setelah workflow dipetakan. Outcome, trigger, context, tools, permission, approval, dan evaluation akan menunjukkan runtime seperti apa yang dibutuhkan.

Di workshop Building AI Employees, Hermes digunakan sebagai lab praktik, sementara pilihan deployment tetap dibahas sebagai keputusan berbasis use case. Tidak ada janji bahwa satu setup akan cocok untuk semua peserta atau semua pekerjaan.

Kalau lo mau membangun blueprint yang menghubungkan pekerjaan dengan keputusan runtime-nya, lo bisa cek detail kelas di sini:

https://goakal.com/ai-builders-id/building-ai-employees

Sebelum memilih cloud, VPS, atau lokal, jawab tiga hal: agent harus aktif kapan, mengakses apa, dan siapa yang bertanggung jawab ketika runtime-nya gagal. Lokasi deployment baru punya arti setelah tiga constraint itu jelas.