Cara Hos Sendiri KiroCrew di VPS Agar Sentiasa Aktif

Mengapa hos sendiri KiroCrew pada VPS berbanding komputer riba

Hos sendiri KiroCrew hanya berbaloi pada mesin yang tidak pernah tidur, jadi VPS adalah tempat yang sesuai untuknya manakala komputer riba tidak. KiroCrew menyimpan sejarah sesi, memori semantik, tugasan berjadual dan baris gilir kelulusan pada cakera, dan ia memuatkan semula semua itu apabila proses dimulakan semula. Tiada gunanya jika proses tersebut tidak berjalan pada pukul 03:00 apabila tugasan berjadual perlu dilaksanakan, dan komputer riba yang ditutup tidak akan menjalankannya.

KiroCrew ialah ruang kerja ejen sumber terbuka daripada pasukan Kiro, dilesenkan di bawah Apache 2.0, dengan keluaran awam pertamanya bermula pada awal Ogos 2026. Satu proses, yang dipanggil gateway, memegang status dan menyediakan papan pemuka web pada port 5476. Anda mencapai gateway tersebut daripada papan pemuka, daripada kirocrew CLI, atau daripada saluran sembang seperti Slack. Gateway ialah satu-satunya perkara yang anda hos sendiri, jadi panduan ini adalah tentang memastikan ia terus hidup, menjauhkannya daripada internet awam, dan keupayaan untuk memulihkannya selepas naik taraf yang gagal.

Dua perkara untuk diketahui sebelum anda bermula. KiroCrew memacu kiro-cli, yang memerlukan log masuk sekali sahaja dengan akaun Kiro, dan inferens ejen dibilkan kepada pelan Kiro, jadi setakat Ogos 2026 ini bukanlah persediaan luar talian. Projek ini juga baru berusia beberapa minggu. Anda harus mengandaikan bahawa anda perlu membuat rollback pada satu ketika, dan pasanglah ia dengan cara yang membolehkan anda berbuat demikian. Jika anda belum pernah menjalankan ejen pada pelayan sebelum ini, menjalankan ejen pengekodan pada VPS merangkumi peraturan asas yang menjadi asas kepada panduan ini.

Keperluan KiroCrew dan lokasi penyimpanan datanya

Pemasangan natif memerlukan Python 3.10 atau lebih baharu (projek ini mengesyorkan 3.12), Node.js 18 atau lebih baharu jika anda membina papan pemuka daripada kod sumber, dan kiro-cli, yang akan dipasang dan dilog masuk secara automatik semasa pelancaran pertama. Pemasangan kontena tidak memerlukan semua itu pada hos. Ia hanya memerlukan Docker. Itulah sebab utama mengapa kaedah ini lebih disyorkan.

Data disimpan dalam ~/.kiro/crew, dan pemboleh ubah persekitaran KIROCREW_HOME boleh digunakan untuk memindahkannya ke lokasi lain. Kandungan di dalamnya adalah:

• config.json: tetapan gateway dan kelayakan saluran sembang.
• .env: rahsia (secrets).
• workspace/memory/: keutamaan, nota projek dan sejarah sembang.
• memory.db dan memory_index.db: indeks semantik dan teks penuh.
• models/: model embedding, yang dimuat turun pada permulaan pertama.
• gateway.log dan security_events.jsonl: log masa jalan dan log peristiwa keselamatan.

Direktori tersebut adalah pemasangan itu sendiri. Salin direktori itu ke VPS baharu dan anda telah memindahkan ejen anda; itulah sebabnya bahagian sandaran di bawah lebih penting daripada bahagian pemasangan.

Rancang penggunaan ruang cakera dan bukannya RAM. Gateway ialah proses Python; perkara yang sebenarnya membebankan pelayan ialah apa sahaja yang dijalankan oleh ejen, sama ada binaan atau suite ujian. Direktori data akan berkembang mengikut sejarah sembang, dan model embedding akan dimuat turun pada permulaan pertama. Oleh itu, ukur saiznya pada pelayan anda sendiri menggunakan du -sh ~/.kiro/crew selepas beberapa minggu dan jangan hanya bergantung pada angka yang diterbitkan pada bulan pertama projek.

Antara tiga laluan pemasangan, yang manakah perlu anda gunakan

Projek ini menerbitkan tiga laluan. Pemasang satu baris mengambil wheel dan meletakkan kirocrew pada PATH anda:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

Ia menerima flag saluran dan flag versi:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --channel insider
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --version 0.1.3

Imej kontena diterbitkan pada ghcr.io/kirodotdev/kirocrew, untuk linux/amd64 dan linux/arm64 di bawah setiap tag. Binaan sumber adalah git clone ditambah make build, dan ia ditujukan untuk mereka yang mengubah kod, bukan untuk mereka yang menjalankannya.

Gunakan kontena. Pemasangan natif meletakkan pakej Python, Node dan kiro-cli pada hos yang sama yang menjalankan servis anda yang lain, jadi naik taraf yang bermasalah akan menyebabkan anda terpaksa membaikinya secara manual. Kontena menyimpan runtime dalam satu imej dan keadaan dalam satu volum, yang menjadikan proses rollback hanya melibatkan pertukaran tag dan but semula.

Sematkan imej kepada tag keluaran, bukan kepada stable

Contoh projek itu sendiri menggunakan tag stable:

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

stable ialah tag yang berubah-ubah. Ia menghala kepada apa jua keluaran stabil terkini, jadi tarikan (pull) seterusnya boleh menukar versi yang anda jalankan tanpa pilihan anda, dan tag tersebut tidak merekodkan versi yang digunakan. Tag versi adalah tidak boleh ubah (immutable), jadi sematkan satu versi. Keluaran terkini setakat 6 Ogos 2026 ialah 0.1.3, yang diterbitkan pada 5 Ogos 2026. Terdapat juga tag nightly, yang bagi projek semuda ini bermakna kod telah berubah pagi tadi.

Tulis /opt/kirocrew/compose.yaml:

services:
  kirocrew:
    image: ghcr.io/kirodotdev/kirocrew:0.1.3
    container_name: kirocrew
    restart: unless-stopped
    ports:
      - "127.0.0.1:5476:5476"
    volumes:
      - kirocrew-home:/home/kirocrew

volumes:
  kirocrew-home:

Mulakan ia, kemudian periksa endpoint kesihatan yang turut digunakan oleh imej tersebut untuk HEALTHCHECK miliknya sendiri:

cd /opt/kirocrew
docker compose up -d
docker compose ps
curl -s http://127.0.0.1:5476/api/health

docker compose ps sepatutnya melaporkan kontena sebagai sihat dalam masa seminit atau lebih, dan /api/health menjawab tanpa token (begitu juga /api/live dan /api/ready, yang menjadikannya boleh digunakan sebagai probe). Jika status kekal pada starting, baca docker logs kirocrew sebelum menukar apa-apa. Jalankan kali pertama akan memuat turun model embedding, jadi sambungan yang perlahan akan menyebabkan permulaan pertama mengambil masa yang lama.

Memastikan ia terus berjalan dengan systemd

restart: unless-stopped akan menghidupkan semula kontena selepas ranap dan selepas but semula, selagi Docker sendiri bermula semasa but. Fail unit menjadikan dependency tersebut jelas dan memberikan anda satu arahan untuk menghentikan keseluruhan stack sebelum membuat sandaran. Memulakan stack Docker Compose semasa but merangkumi corak umum ini. Ini adalah bentuk KiroCrew untuknya, dalam /etc/systemd/system/kirocrew.service:

[Unit]
Description=KiroCrew gateway
Requires=docker.service
After=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/opt/kirocrew
ExecStart=/usr/bin/docker compose up -d
ExecStop=/usr/bin/docker compose down
TimeoutStartSec=0

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now kirocrew
systemctl status kirocrew

systemctl status kirocrew sepatutnya membaca active (exited), yang merupakan hasil sihat untuk unit ini. Type=oneshot dengan RemainAfterExit=yes adalah tepat di sini kerana docker compose up -d kembali sebaik sahaja kontena dimulakan: systemd menjejaki fakta bahawa stack tersebut sedang berjalan, bukan proses latar depan. Tulis Type=simple sebaliknya dan systemd melihat arahan tersebut tamat serta-merta, menandakan servis sebagai mati, dan kemudian sama ada berputus asa atau melakukan gelung mulakan semula bergantung pada tetapan Restart= anda. Untuk pemasangan natif, projek ini membekalkan setara miliknya sendiri, kirocrew service install, yang menulis /etc/systemd/system/kirocrew.service dan menjalankan gateway sebagai pengguna anda. Jangan jalankan kedua-dua unit tersebut. Versi yang lebih luas mengenai topik ini terdapat dalam servis dan pemasa systemd pada VPS.

Jalankan kali pertama: daftar masuk dan dapatkan token papan pemuka

Kontena memulakan gateway, tetapi runtime ejen belum didaftarkan masuk. Daftar masuk di dalam kontena:

docker exec -it kirocrew kiro-cli login

Perintah tersebut akan memaparkan kod peranti dan URL yang perlu anda buka dalam pelayar web anda sendiri. Kemudian, jana token papan pemuka:

docker exec kirocrew kirocrew token --ttl 2h

URL papan pemuka ialah http://localhost:5476/?token=<the token>. Token mempunyai tempoh tamat: sesi ditetapkan secara lalai kepada satu jam dan tempoh maksimum yang didokumentasikan ialah dua puluh jam. Papan pemuka yang dimuatkan kosong atau terus mengeluarkan anda biasanya disebabkan oleh token yang telah tamat tempoh, jadi jana token yang baharu. Jangan sekali-kali menampal token ke dalam tiket atau mesej sembang, kerana sesiapa yang memegangnya akan mempunyai akses kepada ejen anda.

Capai papan pemuka melalui SSH, dan jangan sekali-kali terbitkan port 5476

Perhatikan semula alamat bind dalam contoh projek: -p 127.0.0.1:5476:5476. Di dalam kontena, gateway mendengar pada 0.0.0.0, kerana ia perlu boleh dicapai melalui pemetaan port, tetapi pemetaan itu sendiri hanya diterbitkan ke loopback pada hos. Padamkan awalan 127.0.0.1: dan gateway tersebut akan berada di internet awam untuk sesiapa sahaja yang mengimbas port itu. Peraturan firewall juga tidak akan menyelamatkan anda: Docker menerbitkan port dengan menulis peraturan DNAT yang dinilai sebelum penapisan ufw, jadi ufw deny 5476 tidak memberi kesan kepada port yang diterbitkan. Docker ports bypassing ufw menghuraikan mekanisme tersebut.

Sebaliknya, forward port tersebut melalui SSH dari komputer riba anda:

ssh -N -L 5476:127.0.0.1:5476 you@your-server.example.com

Biarkan ia berjalan dan buka http://localhost:5476/?token=<the token> secara setempat. Untuk menjadikan forward tersebut automatik pada setiap sambungan, letakkannya dalam ~/.ssh/config:

Host your-server.example.com
    LocalForward 5476 127.0.0.1:5476

Jika port 5476 sudah digunakan pada komputer riba anda, tukar nombor di sebelah kiri sahaja: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com, kemudian layari http://localhost:45476/?token=....

Satu tingkah laku yang didokumentasikan untuk dijangka melalui tunnel: gateway membaca permintaan yang diforward sebagai jauh (remote), jadi titik akhir config-write dan secret-reveal dalam papan pemuka akan menolaknya. Perubahan tetapan yang tidak dapat disimpan melalui SSH adalah disebabkan perkara ini, bukannya pepijat. Sebaliknya, edit konfigurasi pada hos:

docker cp kirocrew:/home/kirocrew/.kiro/crew/config.json .
# edit config.json here
docker cp config.json kirocrew:/home/kirocrew/.kiro/crew/config.json
docker exec -u 0 kirocrew chown kirocrew:kirocrew /home/kirocrew/.kiro/crew/config.json
docker restart kirocrew

Untuk akses telefon, projek ini mencadangkan tailscale serve daripada Tailscale, yang mengekalkan papan pemuka di dalam tailnet anda sendiri dan bukannya pada nama hos awam. Utamakan kaedah itu berbanding reverse proxy awam. Token tersebut bergerak dalam URL, dan URL akan ditulis ke dalam setiap access log pada laluannya.

Berikan ejen radius letupan terkecil yang mungkin

Kontena akan membuat pemeriksaan untuk sokongan sandbox pada permulaan pertama, dan hasilnya menentukan sama ada ejen boleh melaksanakan sebarang arahan. Jika pengasingan namespace tersedia, subproses ejen akan berjalan secara terasing. Jika ia tidak tersedia dan KIROCREW_ALLOW_UNSANDBOXED=1 tidak ditetapkan, pelaksanaan akan ditolak daripada berjalan tanpa kawalan, jadi gateway yang kelihatan sihat tetapi setiap tugas terhenti biasanya berpunca daripada perkara ini. Keputusan tersebut berada dalam docker logs kirocrew daripada larian pertama itu. Projek ini juga menerbitkan profil seccomp (secure computing mode) yang boleh anda gunakan:

curl -fsSL https://raw.githubusercontent.com/kirodotdev/KiroCrew/main/docker/seccomp/kirocrew-seccomp.json \
  -o /opt/kirocrew/kirocrew-seccomp.json

    security_opt:
      - seccomp:./kirocrew-seccomp.json

Jika anda menetapkan KIROCREW_ALLOW_UNSANDBOXED=1, fahami dengan jelas apa yang berubah: kontena kini menjadi satu-satunya sempadan antara ejen dan pelayan anda. Amaran projek ini perlu diulang sepenuhnya. Jangan lekapkan (mount) laluan hos yang anda tidak akan berikan terus kepada ejen. Secara praktikalnya, ini mengecualikan Docker socket, sebarang bind mount bagi /, dan mana-mana direktori yang menyimpan data servis lain.

Selebihnya ialah kerangka yang terpakai untuk setiap ejen yang dibenarkan menjalankan arahan. Hadkan kelayakan (credentials) kepada satu repositori atau satu bucket yang diperlukan sahaja, jangan gunakan token peribadi dengan hak akses seluruh akaun. Jalankan ia sebagai pengguna khusus yang direktori home-nya tidak menyimpan apa-apa perkara lain, itulah tujuan pengguna dengan keistimewaan paling rendah pada VPS. Apabila ejen menulis kod dan kemudian menjalankan kod tersebut, berikan ia mesin yang ia dibenarkan untuk rosakkan: VM pakai buang untuk ejen pengekodan adalah sempadan yang lebih kuat daripada mana-mana flag dalam fail compose ini, kerana anda memadamkannya dan bukannya membersihkannya. Penaakulan yang sama membentuk menjalankan OpenClaw dengan selamat pada VPS dan self-hosting ejen Hermes pada VPS. Alatan juga dikira sebagai radius letupan: memberikan ejen keupayaan carian web menjadikan setiap halaman yang diambilnya sebagai input yang tidak dipercayai, jadi menghalakannya ke instans SearXNG anda sendiri adalah keputusan berkaitan prompt injection sama seperti keputusan teknikal. Kerja berjadual juga akan membelanjakan wang semasa anda tidur, memandangkan inferens dibilkan kepada pelan Kiro anda, jadi tetapkan had yang diterangkan dalam mengawal kos ejen AI pada VPS sebelum anda menambah tugasan malam.

Sandarkan volum keadaan sebelum setiap naik taraf

Cari nama volum sebenar terlebih dahulu. Compose memberikan awalan kepada volum bernama dengan nama projek, yang secara lalai menggunakan nama direktori, jadi volum yang diisytiharkan sebagai kirocrew-home dalam /opt/kirocrew/compose.yaml dicipta sebagai kirocrew_kirocrew-home:

docker volume ls

Hentikan gateway sebelum menyalin apa-apa. memory.db dan memory_index.db adalah pangkalan data SQLite, dan menyalin pangkalan data semasa ia sedang ditulis boleh menangkap transaksi yang separuh ditulis, yang akan menjadi fail rosak apabila dipulihkan. Arahan migrasi projek itu sendiri menyatakan perkara yang sama: pindahkan memori hanya apabila gateway dihentikan.

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data:ro -v "$PWD":/backup \
  alpine tar czf /backup/kirocrew-2026-08-06.tgz -C /data .
sudo systemctl start kirocrew

Salin arkib keluar dari kotak tersebut. Pemulihan menggunakan arahan yang sama dengan bekas dihentikan dan tar xzf menggantikan tar czf:

sudo systemctl stop kirocrew
docker run --rm -v kirocrew_kirocrew-home:/data -v "$PWD":/backup \
  alpine tar xzf /backup/kirocrew-2026-08-06.tgz -C /data
sudo systemctl start kirocrew

Berpindah ke hos baharu adalah tugas yang berbeza daripada pemulihan di tempat asal, dan projek tersebut mempunyai spesifikasi khusus mengenainya. Sejarah sembang dan nota projek di bawah workspace/memory/ akan dibawa bersama, begitu juga dengan dua fail pangkalan data dan config.json. Fail PID, log peristiwa keselamatan dan .env terikat pada hos lama, jadi tinggalkan fail-fail tersebut dan masukkan semula rahsia (secrets) pada kotak baharu.

Bagaimana untuk membuat rollback selepas naik taraf yang bermasalah

Proses naik taraf adalah singkat, dan ia hanya selamat kerana anda telah menetapkan versi (pin). Lakukan sandaran (backup) terlebih dahulu, kemudian tukar tag:

sudo systemctl stop kirocrew
# take the backup here, as above
sudo nano /opt/kirocrew/compose.yaml   # set the new image tag
sudo systemctl start kirocrew
docker compose -f /opt/kirocrew/compose.yaml ps
curl -s http://127.0.0.1:5476/api/health

docker compose up -d akan menarik imej tersebut jika ia belum ada pada pelayan, jadi suntingan tag adalah keseluruhan proses naik taraf. Melakukan rollback adalah urutan yang sama dengan nombor versi lama, dan ia memberikan anda imej yang tepat seperti yang anda miliki sebelum ini, kerana tag versi adalah tidak boleh diubah (immutable).

Binari tersebut melakukan rollback dengan bersih. Bahagian yang mungkin tidak bersih adalah state. Gateway yang lebih baharu boleh menulis semula config.json atau memindahkan pangkalan data memori ke dalam bentuk yang tidak boleh dibaca oleh gateway yang lebih lama, dan tiada laluan turun taraf (downgrade) yang didokumentasikan setakat Ogos 2026. Jadi, jika imej lama bermula dan kemudian berkelakuan ganjil, jangan nyahpepijat (debug) ia. Hentikan servis tersebut, pulihkan sandaran yang anda ambil sebelum naik taraf, dan mulakan semula. Itulah sebab utama mengapa sandaran perlu dilakukan terlebih dahulu, dan itulah sebab mengapa tabiat menaik taraf sekarang dan membuat sandaran kemudian akan gagal pada projek yang masih baharu ini.

Perkara yang tidak dibuktikan di sini

Bersikap jujurlah tentang usia perisian ini. Versi 0.1.3 baru berusia beberapa hari semasa penulisan ini dibuat, nota keluarannya hanyalah pautan changelog automatik dan bukannya nota migrasi, serta belum ada rekod prestasi bagi proses naik taraf. Tiada apa-apa dalam panduan ini merupakan hasil jangka panjang, jadi anggaplah pertumbuhan memori, saiz pangkalan data dan kebolehpercayaan penjadual sebagai perkara yang perlu diukur pada pelayan anda sendiri, bukannya perkara yang boleh diandaikan.

Dua kelakuan wajar diuji sendiri sebelum anda bergantung kepadanya. Pertama, sama ada proses turun taraf (downgrade) boleh membaca keadaan yang ditulis oleh versi yang lebih baharu: cubalah pada salinan volum semasa ia tidak mendatangkan masalah, bukan semasa gangguan berlaku. Kedua, apa yang dilakukan oleh gateway apabila log masuk Kiro tamat tempoh semasa tugasan berjadual perlu dijalankan. Kedua-duanya adalah jenis kekasaran yang biasanya diperhalusi secara senyap oleh projek baharu antara keluaran, dan kedua-duanya mudah untuk diperiksa sekarang.

FAQ

Mengapa papan pemuka KiroCrew tidak terbuka pada IP awam pelayan saya?

Kerana contoh yang diterbitkan mengikat port kepada loopback. -p 127.0.0.1:5476:5476 memetakan port kontena kepada alamat loopback hos sahaja, dan ini dilakukan dengan sengaja. Capai papan pemuka tersebut dengan memajukan port melalui SSH menggunakan ssh -N -L 5476:127.0.0.1:5476 you@your-server, kemudian buka http://localhost:5476/?token=<token> pada komputer riba anda. Membuang awalan 127.0.0.1: untuk menjadikannya boleh dicapai akan meletakkan get laluan pada internet awam, dan peraturan firewall tidak akan menyekatnya, kerana peraturan DNAT port yang diterbitkan oleh Docker dinilai sebelum ufw menapis trafik tersebut.

Di manakah KiroCrew menyimpan datanya, dan apakah yang perlu saya sandarkan?

Segala-galanya terletak di bawah ~/.kiro/crew, iaitu /home/kirocrew/.kiro/crew di dalam imej kontena, dan KIROCREW_HOME memindahkannya ke lokasi lain. Sandarkan keseluruhan direktori, atau keseluruhan Docker volume, semasa get laluan dihentikan. memory.db dan memory_index.db merupakan pangkalan data SQLite, jadi salinan yang diambil semasa get laluan sedang menulis data boleh menjadi tidak konsisten. Apabila berpindah ke hos baharu, workspace/memory/, kedua-dua fail pangkalan data dan config.json perlu dipindahkan, manakala fail PID, log peristiwa keselamatan dan .env adalah milik hos lama.

Patutkah saya menggunakan tag stable atau tag versi?

Gunakan tag versi. stable berubah setiap kali keluaran baharu dilancarkan, jadi versi yang anda jalankan boleh berubah tanpa disedari pada tarikan (pull) seterusnya, dan tag itu sendiri tidak memberikan maklumat tentang apa yang sedang dijalankan. Tag versi seperti 0.1.3 adalah tidak boleh diubah, dan itulah yang membolehkan proses rollback berfungsi: anda meletakkan semula nombor versi lama dan mendapatkan imej yang sama. Setakat 6 Ogos 2026, keluaran terbaharu ialah 0.1.3.

Mengapa ejen saya enggan menjalankan sebarang arahan?

Kontena tersebut memeriksa sokongan sandbox pada permulaan pertamanya. Jika ia tidak dapat mengasingkan subproses ejen dan KIROCREW_ALLOW_UNSANDBOXED=1 tidak ditetapkan, ia enggan melaksanakannya daripada menjalankannya tanpa kawalan, jadi get laluan kelihatan sihat walaupun setiap tugas terhenti. docker logs kirocrew menunjukkan keputusan sandbox daripada permulaan pertama itu. Menetapkan pemboleh ubah tersebut menjadikan kontena sebagai satu-satunya sempadan antara ejen dan hos, jadi jika anda menetapkannya, jangan lekapkan (mount) apa-apa yang anda tidak mahu berikan terus kepada ejen tersebut.

Adakah saya memerlukan akaun Kiro untuk mengehos sendiri KiroCrew?

Ya, setakat Ogos 2026. KiroCrew ialah perisian percuma di bawah Apache 2.0, tetapi ia memacu kiro-cli, yang memerlukan log masuk sekali sahaja, dan inferens ejen dibilkan kepada pelan Kiro. Di dalam kontena, jalankan docker exec -it kirocrew kiro-cli login dan luluskan kod peranti dalam pelayar anda. Sehingga log masuk itu selesai, get laluan akan bermula dan papan pemuka akan dimuatkan, tetapi ejen tidak mempunyai model untuk dihubungi.