Cara Menjalankan SandBase Agent Runtime Sendiri
Jalankan SandBase Harness v0.3.2 di VPS sendiri dengan instalasi bertag, agent YAML, server MCP, mode sandbox, dan Anthropic SDK ke server Anda.
Yang Anda dapatkan saat men-host sendiri runtime agent SandBase
Men-host sendiri runtime agent SandBase berarti menjalankan SandBase Harness pada server milik Anda. Dengan demikian, sesi, kredensial, memori, dan jejak audit tersimpan di disk Anda, bukan di disk pihak lain. SandBase Harness adalah service Node. Service ini mendengarkan pada 127.0.0.1:3000, menyediakan API HTTP /v1 dan konsol web, serta menyimpan statusnya dalam SQLite di samping file agent Anda.
API /v1 mengikuti bentuk Claude Managed Agents (CMA), yaitu API managed-agent yang di-host. Hal ini membuat runtime ini menarik untuk dua skenario: Anda dapat menulis kode menggunakan Anthropic SDK dan mengarahkan baseURL ke server Anda sendiri, lalu memindahkan kode yang sama ke deployment yang di-host pada kemudian hari.
SandBase Harness tidak menyertakan model. SandBase Harness memanggil model. Per Agustus 2026, SandBase Harness mendukung endpoint yang kompatibel dengan OpenAI, Anthropic, dan OpenAI. Dukungan ini mencakup gateway yang di-host sendiri dan provider seperti DeepSeek V4. Anda tetap harus menyediakan API key atau server lokal yang menggunakan API OpenAI.
Yang perlu disiapkan sebelum memulai
- VPS yang menjalankan Ubuntu 24.04 dengan RAM minimal 2 GB. Build TypeScript adalah tahap instalasi yang paling berat.
- Node.js 22 atau yang lebih baru, serta npm 10 atau yang lebih baru. Keduanya merupakan batas minimum yang ditetapkan oleh project.
git, serta API key untuk model provider yang ingin Anda gunakan.- Docker, tetapi hanya jika Anda ingin menggunakan sandbox container per sesi.
Ubuntu 24.04 menyediakan Node 18.19 di repositorinya sendiri. Versi ini berada di bawah batas minimum. Karena itu, gunakan Node dari NodeSource.
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs git
node -v
npm -vnode -v harus menampilkan v22 atau yang lebih baru, sedangkan npm -v harus menampilkan 10 atau yang lebih baru. Jika node -v masih menampilkan v18.19.1, paket dari distribusi masih terpasang dan menjadi pilihan utama pada PATH. Hapus paket tersebut sebelum melanjutkan, karena build berjalan menggunakan node yang ditemukan shell.
Instal SandBase dari tag v0.3.2
Instal dari tag, bukan dari branch yang terus berubah. Kloning bare dari main akan memberi Anda apa pun yang ditambahkan satu jam lalu, dan kunci konfigurasi di bawah mungkin tidak cocok dengannya. v0.3.2 adalah tag saat ini per 16 August 2026.
sudo install -d -o "$USER" -g "$USER" /opt/sandbase
cd /opt/sandbase
git clone --branch v0.3.2 --depth 1 https://github.com/sandbaseai/sandbase-harness.git
cd sandbase-harness
npm ci
npm run buildGunakan npm ci, bukan npm install. ci menginstal versi persis yang tercatat dalam lockfile yang dikomit, sehingga tree Anda sama dengan tree yang diuji oleh pengelola. npm install dapat menyelesaikan versi yang lebih baru. Akibatnya, tag yang dipatok dapat diam-diam tidak lagi terpaku pada versi tertentu.
Sekarang buat workspace. Workspace adalah direktori terpisah yang menyimpan file agent dan seluruh state runtime. Menyimpannya di luar checkout source memungkinkan Anda menarik tag yang lebih baru tanpa menyentuh data Anda.
mkdir -p /opt/sandbase/workspace
cd /opt/sandbase/workspace
node /opt/sandbase/sandbase-harness/dist/index.js init
node /opt/sandbase/sandbase-harness/dist/index.js startinit menulis direktori .managed-agents/ ke dalam workspace. start menjalankan console pada http://127.0.0.1:3000/dashboard dan API pada http://127.0.0.1:3000/v1. Keduanya belum dapat diakses dari laptop Anda. Itu sudah benar dan dibahas lebih lanjut di bawah. Untuk sementara, akses console melalui SSH:
ssh -N -L 3000:127.0.0.1:3000 you@your-serverPath node .../dist/index.js yang panjang akan merepotkan, jadi beri nama.
alias sandbase='node /opt/sandbase/sandbase-harness/dist/index.js'Perintah di bawah ditulis sebagai sandbase <command> berdasarkan konfigurasi tersebut.
Jangan menginstalnya dari npm
Dokumentasi instalasi project ini menyatakan bahwa package managed-agents tanpa scope yang terlihat di npm bukanlah project ini. Jadi, npx managed-agents dan npm install -g managed-agents mengambil sesuatu yang tidak berkaitan dengan runtime yang Anda inginkan. Instal dari source GitHub bertag sampai maintainer mengumumkan package scoped resmi. Ini bukan catatan kecil dalam riwayat project: v0.3.1 terutama dirilis untuk mengganti panduan singkat npm lama dengan jalur source bertag yang versinya dipatok.
Arahkan workspace ke penyedia model
init menulis .managed-agents/config.yaml. Satu penyedia dikonfigurasi untuk seluruh workspace, lalu setiap agen memilih ID model tertentu.
model:
provider: openai
api_key: ${OPENAI_API_KEY}
storage:
metadata:
provider: sqlite
options: {}
artifacts:
provider: local
options:
base_path: filesFormulir ${OPENAI_API_KEY} mengambil nilainya dari lingkungan proses. Dengan demikian, kunci tetap berada di luar file konfigurasi dan di luar setiap cadangan file tersebut. Simpan kunci itu dalam file lingkungan yang hanya dapat dibaca oleh root, karena systemd membaca EnvironmentFile= sebagai root sebelum menurunkan hak akses.
sudo install -d -m 750 /etc/sandbase
sudo touch /etc/sandbase/runtime.env
sudo chmod 600 /etc/sandbase/runtime.envBuka file tersebut dalam editor dan tambahkan satu baris, OPENAI_API_KEY=sk-.... Kunci penyedia disimpan di sini. Rahasia yang digunakan oleh agen selama sesi sebaiknya disimpan di vault kredensial runtime. Itu merupakan masalah berbeda dengan cakupan dampak yang berbeda. Baca menjaga rahasia tetap di luar agen AI sebelum menempelkan token produksi ke salah satu tempat tersebut.
YAML agent: mcp_servers, tools, dan kebijakan izin
Agent didefinisikan sebagai file YAML di direktori workspace agents/. Di sinilah sebagian besar waktu Anda akan digunakan saat mengelola runtime.
name: Incident commander
description: Triages alerts and coordinates response.
model: gpt-4o
system: |-
You are an on-call incident commander.
mcp_servers:
- name: sentry
type: url
url: https://mcp.sentry.dev/mcp
tools:
- type: agent_toolset_20260401
default_config:
permission_policy: { type: always_ask }
configs:
- name: bash
permission_policy: { type: always_ask }
- type: mcp_toolset
mcp_server_name: sentry
metadata:
template: incident-commanderMuat file tersebut dan periksa apakah file berhasil dimuat:
sandbase reload
sandbase list
sandbase chat agent_assistant --message "hello"reload mengimpor YAML awal ke SQLite. list sekarang seharusnya menampilkan agent beserta ID-nya. Jika list tidak menampilkannya, file tersebut tidak berhasil diurai, dan alasannya ditulis di .managed-agents/logs/runtime.log.
mcp_servers mendeklarasikan endpoint MCP (model context protocol). type: url berarti runtime berkomunikasi melalui HTTP dengan server yang berjalan di tempat lain. Karena itu, layanan apa pun yang sudah Anda operasikan dapat digunakan di sini, termasuk MCP server yang di-host pada VPS yang sama dengan runtime.
Mendeklarasikan server tidak otomatis memberikan tool-nya kepada agent. Daftar tools yang melakukannya, melalui entri mcp_toolset yang nilai mcp_server_name-nya cocok dengan name di atas. Jika agent berperilaku seolah-olah tool MCP tidak ada, bandingkan kedua string tersebut karakter demi karakter sebelum memeriksa bagian lain.
agent_toolset_20260401 adalah kumpulan tool bawaan. Sufiks bertanggal tersebut merupakan versi skema. Dengan demikian, agent yang dikunci pada versi itu tetap menggunakan definisi tool yang menjadi acuannya. default_config menetapkan kebijakan untuk setiap tool dalam kumpulan tersebut, sedangkan setiap entri di bawah configs mengganti kebijakan satu tool berdasarkan namanya, yaitu bash pada contoh ini.
permission_policy adalah bagian yang membuat runtime lebih berguna daripada pemanggilan model biasa. always_ask menghentikan sementara sesi dan menunggu manusia menyetujui pemanggilan tersebut sebelum dijalankan. always_allow mengizinkan pemanggilan itu berjalan. Menetapkan bash ke always_ask berarti agent tidak dapat menjalankan perintah shell tanpa Anda melihat perintah persisnya terlebih dahulu. Kontrol ini sama dengan yang digunakan saat menjalankan Claude Code dengan aman pada VPS.
Tiga mode sandbox dan kapan masing-masing sesuai
Panggilan alat yang menjalankan kode berlangsung di dalam sandbox. Backend dipilih per lingkungan melalui sandbox_provider pada objek config lingkungan tersebut, atau melalui Settings lalu Sandbox di konsol. Lingkungan dibuat melalui API pada POST /v1/environments.
local menjalankan kode sebagai proses anak dari runtime, pada host, dengan user runtime itu sendiri. Mode ini adalah default dan sesuai selama Anda satu-satunya user serta agent hanya membaca file yang Anda miliki. Mode ini bukan isolasi. Panggilan alat yang menghapus file akan menghapus file Anda, dan panggilan alat yang membaca /etc/sandbase/runtime.env akan membaca provider key Anda.
docker menjalankan satu container untuk setiap sesi.
{
"sandbox_provider": "docker",
"image": "node:22-slim",
"resources": { "memory": "1g", "cpu": 1 }
}Sesi tersebut memiliki filesystem, batas memori, dan jatah CPU sendiri. Container dihapus bersama sesi. Beralihlah ke mode ini segera setelah agent menjalankan kode yang tidak Anda tulis. Konsekuensinya, user runtime harus memiliki akses ke Docker socket, dan keanggotaan dalam grup docker setara dengan root pada host. Container per sesi memiliki bentuk yang sama dengan sandbox agent self-hosted dengan satu container per eksekusi, sehingga pertimbangan tentang apa yang dapat dijangkau proses yang berhasil keluar dari sandbox berlaku tanpa perubahan di sini.
kubernetes menjalankan workload sesi sebagai pod dan mengendalikannya dengan kubectl exec dan kubectl cp. Image runtime harus memiliki kubectl, dan ServiceAccount-nya memerlukan izin RBAC (role-based access control) untuk membuat, menghapus, mendapatkan, mencantumkan, dan memantau pod pada namespace target, serta subresource exec. Mode ini sepadan dengan upaya penyiapannya hanya jika Anda sudah menjalankan cluster.
Mengapa runtime terikat ke 127.0.0.1?
Karena runtime dimulai tanpa autentikasi. Runtime mengaktifkan autentikasi bearer token jika terdapat setidaknya satu API key, sedangkan init yang baru dibuat tidak memiliki API key. Jika runtime tanpa autentikasi, yang memiliki shell tool dan provider key Anda, terikat ke 0.0.0.0 secara default, runtime tersebut akan terekspos ke Internet publik.
Jadi, jika runtime perlu dapat diakses, biarkan alamat bind tersebut dan lakukan dua hal berikut.
Pertama, aktifkan autentikasi. Tetapkan MANAGED_AGENTS_API_KEY dalam file environment service, atau buat key dengan POST /v1/api-keys. Perintah tersebut menampilkan field secret_key satu kali dan tidak pernah menampilkannya lagi. Selanjutnya, klien mengirimkan Authorization: Bearer <key> pada setiap request.
Kedua, tempatkan reverse proxy di depannya dan lakukan terminasi TLS (transport layer security) di sana. Runtime memang menyajikan HTTP biasa dan mengharapkan komponen lain menangani sertifikat.
server {
listen 443 ssl;
server_name agents.example.com;
ssl_certificate /etc/letsencrypt/live/agents.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/agents.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Connection "";
proxy_buffering off;
proxy_read_timeout 3600s;
}
}Dua baris tersebut bukan sekadar hiasan. proxy_buffering off penting karena sesi dialirkan melalui server-sent events (SSE). Jika buffering aktif, nginx menahan respons hingga buffer penuh. Akibatnya, konsol tidak menampilkan apa pun saat agent bekerja, lalu menampilkan seluruh respons sekaligus pada akhir proses. proxy_read_timeout 3600s penting karena nilai default-nya adalah 60 detik. Jadi, stream yang tidak mengirim data selama lebih dari satu menit akan ditutup oleh proxy di tengah proses, dan kegagalan tersebut terlihat seperti runtime mengalami crash.
Pada firewall, buka port 22 dan 443. Biarkan port 3000 tetap tertutup karena proxy mengaksesnya melalui loopback dan tidak ada akses dari luar host yang diperlukan.
Arahkan Anthropic SDK ke server Anda sendiri
Runtime ini mengimplementasikan surface berbentuk CMA, /v1, sehingga klien Anthropic SDK dapat berkomunikasi dengannya dengan mengubah satu field.
import Anthropic from '@anthropic-ai/sdk';
const client = new Anthropic({
apiKey: process.env.MANAGED_AGENTS_API_KEY ?? 'local-dev-key',
baseURL: 'http://127.0.0.1:3000'
});Runtime ini juga menerima header beta yang dikirim oleh klien Claude Managed Agents, anthropic-beta: managed-agents-2026-04-01 dan anthropic-beta: agent-memory-2026-07-22. Header tersebut bersifat opsional jika digunakan dengan runtime lokal. Header itu disediakan agar kode yang ditulis untuk deployment hosted dapat berjalan tanpa perubahan di sini.
Kompatibilitasnya hampir sepenuhnya sesuai, tetapi tidak total. Baca docs/api-matrix.md di checkout sebelum menganggap suatu surface tersedia, karena proyek ini mendokumentasikan keterbatasannya sendiri di sana, termasuk custom tools sisi klien yang masih memerlukan registrasi bernama di atas protokol event-result saat ini.
Plain HTTP juga dapat digunakan dan merupakan cara tercepat untuk membuktikan bahwa runtime aktif:
curl -N -X POST http://127.0.0.1:3000/v1/sessions/SESSION_ID/messages \
-H "Content-Type: application/json" \
-d '{"content": "Hello", "stream": true}'Respons yang sehat berupa stream event yang terus diterima. Jika koneksi terputus, lanjutkan dari event terakhir yang Anda lihat, bukan dengan memutar ulang seluruh turn:
curl -N http://127.0.0.1:3000/v1/sessions/SESSION_ID/events/stream \
-H "Last-Event-ID: EVENT_ID"Stream yang dapat dilanjutkan inilah yang membuat session tetap bertahan meskipun laptop ditutup. Event disimpan di server, sehingga klien memutar ulang log, bukan menyimpan satu-satunya salinan.
Lokasi kredensial, memori, dan jejak audit di disk
Semua yang dikelola runtime berada di bawah .managed-agents/ dalam workspace.
.managed-agents/
├── config.yaml
├── data.db
├── logs/runtime.log
├── files/
├── skills/
├── snapshots/
└── sandbox/data.dbadalah metadata SQLite: agen, sesi, entri vault kredensial, entri penyimpanan memori, dan kunci API.files/menyimpan byte file yang diunggah, sedangkanskills/menyimpan paket skill yang diunggah.snapshots/menyimpan snapshot workspace sesi, sedangkansandbox/menyimpan direktori kerja sesi mode lokal.logs/runtime.logadalah tempat pertama yang perlu diperiksa jika sesuatu tidak melakukan apa pun secara diam-diam.
Vault kredensial adalah kumpulan secret. Setiap vault ditambahkan dengan auth_type seperti environment_variable, lalu dikaitkan ke sesi melalui vault_ids saat sesi dibuat. Penyimpanan memori berisi entri bernama yang Anda mount ke sesi sebagai memory_store, dengan pengaturan akses dan instruksinya sendiri. Keduanya berada di data.db. Inilah perbedaan utama antara runtime ini dan pemanggilan model mentah: runtime mengingat data antarsesi dan mencatat apa yang terjadi.
Karena semuanya berada dalam satu direktori, cadangkan direktori tersebut sebagai satu kesatuan.
sudo systemctl stop sandbase
sudo tar czf /root/sandbase-$(date +%F).tgz -C /opt/sandbase/workspace .managed-agents
sudo systemctl start sandbaseHentikan service terlebih dahulu. Menyalin database SQLite saat runtime sedang menulis ke dalamnya dapat menghasilkan file yang tidak dapat dibuka saat dipulihkan, dan masalah itu baru diketahui ketika cadangan diperlukan. Jika Anda ingin menyimpan YAML agen di git dan state di lokasi lain, dokumentasi deployment mendukung penetapan lokasi state melalui --data-dir pada start.
Pemulihan dilakukan secara terbalik: checkout tag yang sama pada server baru, ekstrak arsip ke dalam workspace, lalu start service. Kunci provider Anda tidak ada dalam arsip jika Anda menggunakan bentuk ${OPENAI_API_KEY}. Karena itu, simpan kunci tersebut di tempat yang tetap dapat Anda akses.
Jalankan dengan systemd
Berikan runtime pengguna tersendiri agar pemanggilan alat dalam mode sandbox lokal tidak dapat bertindak sebagai Anda.
sudo adduser --system --group --no-create-home --home /opt/sandbase sandbase
sudo chown -R sandbase:sandbase /opt/sandbaseSimpan ini sebagai /etc/systemd/system/sandbase.service.
[Unit]
Description=SandBase Harness runtime
After=network-online.target
[Service]
User=sandbase
Group=sandbase
WorkingDirectory=/opt/sandbase/workspace
EnvironmentFile=/etc/sandbase/runtime.env
ExecStart=/usr/bin/node /opt/sandbase/sandbase-harness/dist/index.js start --host 127.0.0.1 --port 3000
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.targetContoh deployment dari proyek menggunakan binary managed-agents pada PATH. Instalasi dari source yang diberi tag tidak membuat binary tersebut, sehingga ExecStart menjalankan node terhadap entry point yang telah dibangun.
sudo systemctl daemon-reload
sudo systemctl enable --now sandbase
sudo systemctl status sandbase
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/dashboardHasil yang sehat adalah active (running) dari status dan 200 dari curl. Jika hasilnya berbeda, baca journalctl -u sandbase -n 50 terlebih dahulu, lalu .managed-agents/logs/runtime.log. enable --now adalah bagian yang penting karena proses yang dijalankan secara manual akan hilang setelah reboot berikutnya.
Hal yang gagal dan pesan yang akan Anda lihat
npm run build dihentikan tanpa error dari npm. Pada VPS 1 GB, proses kompilasi TypeScript dihentikan oleh kernel karena kehabisan memori. Kernel mencatat kejadian ini di log kernel, bukan di npm. Konfirmasikan dengan journalctl -k | grep -i "out of memory", yang menampilkan baris berisi nama proses node yang dihentikan. Tambahkan swap, atau lakukan build pada instance yang lebih besar lalu salin dist/ ke server.
Error: listen EADDRINUSE: address already in use 127.0.0.1:3000. Proses lain sudah menggunakan port tersebut. sudo ss -lntp | grep 3000 menampilkan nama prosesnya. Hentikan proses tersebut, atau jalankan runtime dengan --port 3001 lalu perbarui proxy.
Dashboard tidak dapat dimuat dari laptop Anda. Ini adalah perilaku yang diharapkan karena runtime melakukan bind ke loopback. Gunakan SSH tunnel di atas, atau selesaikan konfigurasi reverse proxy. Jangan memperbaikinya dengan --host 0.0.0.0 karena autentikasi tetap nonaktif sampai sebuah key tersedia.
Sandbox Docker gagal dengan permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock. User sandbase tidak termasuk dalam group docker. Perbaiki dengan sudo usermod -aG docker sandbase lalu restart service. Pahami izin yang Anda berikan: group tersebut memiliki akses root pada host, sehingga sebagian alasan Anda memberikan runtime user khusus menjadi tidak berlaku.
Sandbox Kubernetes gagal dengan Error from server (Forbidden). ServiceAccount tidak memiliki izin pod atau subresource exec. Periksa langsung dengan kubectl auth can-i create pods/exec -n <namespace>, yang mengembalikan yes atau no.
Setiap request mengembalikan 401 setelah Anda menambahkan API key. Autentikasi diaktifkan saat key pertama tersedia, dan berlaku untuk console serta API. Kirim Authorization: Bearer <key>. Jika key hilang, buat key lain karena secret_key hanya dikembalikan satu kali dan tidak disimpan dalam bentuk yang dapat dibaca.
Tool dari server MCP tidak pernah muncul dalam session. Bandingkan mcp_server_name dalam blok tools dengan name dalam mcp_servers, lalu periksa apakah runtime dapat mengakses URL tersebut dari server itu sendiri dengan curl -i <url>. Server MCP bertipe URL merupakan dependensi jaringan. VPS menyelesaikan nama dan merutekan traffic secara berbeda dari laptop Anda.
FAQ
Dapatkah saya menjalankan SandBase Harness tanpa key OpenAI atau Anthropic?
Ya, jika Anda memiliki endpoint yang kompatibel dengan OpenAI. Runtime ini mendukung provider OpenAI, Anthropic, dan yang kompatibel dengan OpenAI, sehingga server lokal yang menggunakan OpenAI API dapat digunakan. Atur provider workspace di .managed-agents/config.yaml, lalu arahkan api_key dan endpoint ke sana. Runtime ini tidak menyertakan model sendiri, sehingga harus ada komponen yang menjawab panggilan tersebut.
Apakah aman mengekspos runtime pada port publik?
Tidak dengan konfigurasi saat instalasi. Runtime terikat pada 127.0.0.1:3000 dan dimulai tanpa autentikasi, sedangkan solusinya bukan mengganti alamat bind. Buat API key, atau tetapkan MANAGED_AGENTS_API_KEY, agar autentikasi bearer-token aktif. Selanjutnya, tempatkan nginx atau Caddy di depannya untuk TLS, dan tutup port 3000 pada firewall agar satu-satunya jalur masuk adalah melalui proxy.
Apa perbedaan antara sandbox local, Docker, dan Kubernetes?
local menjalankan kode tool sebagai proses child dari runtime pada host, menggunakan izin pengguna runtime dan tanpa isolasi. docker memberikan setiap sesi container sendiri dengan filesystem, batas memori, dan jatah CPU sendiri, lalu menghapusnya saat sesi berakhir. kubernetes menjalankan sesi sebagai pod dan mengendalikannya dengan kubectl exec, yang memerlukan kubectl di dalam image runtime serta RBAC pada pod dan subresource exec di namespace target.
Apa saja yang sebenarnya perlu saya cadangkan?
Direktori .managed-agents/ di dalam workspace. Direktori ini berisi config.yaml, database SQLite data.db yang menyimpan agent, sesi, entri credential vault, dan entri memori, serta file yang diunggah, paket skill, dan snapshot sesi. Hentikan service sebelum menyalinnya agar SQLite tidak sedang ditulis saat proses pengarsipan berlangsung. API key provider yang direferensikan sebagai ${OPENAI_API_KEY} tidak berada di dalam backup, jadi simpan secara terpisah.
Mengapa harus melakukan clone tag v0.3.2, bukan main?
Tag adalah tree tetap, sehingga key konfigurasi dan perintah CLI yang Anda baca adalah yang benar-benar akan tersedia. main dapat berubah, dan key konfigurasi dapat diganti namanya antara saat panduan ditulis dan saat Anda menjalankannya. Proyek ini juga memperingatkan bahwa paket managed-agents tanpa scope di npm bukan proyek ini, sehingga npx managed-agents akan menginstal sesuatu yang tidak terkait. Rilis v0.3.1 terutama dibuat untuk mengganti quick start npm tersebut dengan langkah instalasi dari source bertag yang ditetapkan versinya.