SSD Nodes Learn 🎉 VPS $5.50/மாதம் முதல்
கல்வி வழிகாட்டிகள் Matt Connorஆல் Matt Connor · புதுப்பிக்கப்பட்டது 2026-08-13

VPS-ல் KiroCrew-ஐ self-host செய்வது எப்படி?

KiroCrew-ஐ VPS-ல் Docker மற்றும் systemd மூலம் நிறுவி 24/7 இயங்க வைப்பது எப்படி என்பதை அறியுங்கள். session memory, scheduled jobs மற்றும் rollback முறைகளை இதில் காணலாம்.

லேப்டாப்பிற்குப் பதிலாக VPS-ல் KiroCrew-ஐ ஏன் self-host செய்ய வேண்டும்

KiroCrew-ஐ எப்போதும் இயங்கிக்கொண்டிருக்கும் ஒரு கணினியில் self-host செய்வது மட்டுமே பலன் தரும்; எனவே, லேப்டாப்பிற்குப் பதிலாக VPS-ஐத் தேர்ந்தெடுப்பதே சரியானது. KiroCrew தனது session history, semantic memory, scheduled jobs மற்றும் approval queue ஆகியவற்றை disk-ல் சேமித்து வைக்கிறது; process restart ஆகும்போது இவை அனைத்தையும் மீண்டும் ஏற்றிக்கொள்கிறது. ஒரு scheduled job இயங்க வேண்டிய 03:00 மணிக்கு process இயங்கவில்லை என்றால், இந்த வசதிகள் எதற்கும் பயன் இல்லை; லேப்டாப் மூடிய நிலையில் இருந்தால் அது இயங்காது.

KiroCrew என்பது Kiro குழுவினரால் உருவாக்கப்பட்ட ஒரு open source agent workspace ஆகும். இது Apache 2.0 உரிமம் பெற்றது. இதன் முதல் பொது வெளியீடு ஆகஸ்ட் 2026 தொடக்கத்தில் வெளிவந்தது. gateway எனப்படும் ஒரு process, state-ஐ நிர்வகிப்பதோடு port 5476-ல் web dashboard-ஐயும் வழங்குகிறது. இந்த gateway-ஐ dashboard மூலமாகவோ, kirocrew CLI மூலமாகவோ அல்லது Slack போன்ற chat channel மூலமாகவோ நீங்கள் அணுகலாம். நீங்கள் self-host செய்வது இந்த gateway-ஐ மட்டுமே. எனவே, இந்த வழிகாட்டி அதை எப்போதும் இயங்க வைப்பது, பொது இணையத்திலிருந்து பாதுகாப்பது மற்றும் தவறான upgrade-க்குப் பிறகு மீண்டும் பழைய நிலைக்குக் கொண்டு வருவது பற்றியது.

நீங்கள் தொடங்குவதற்கு முன் இரண்டு விஷயங்களை அறிந்து கொள்ள வேண்டும். KiroCrew kiro-cli-ஐ இயக்குகிறது; இதற்கு Kiro account மூலம் ஒருமுறை sign-in செய்ய வேண்டும். மேலும், agent inference-க்கான கட்டணம் Kiro plan-ல் வசூலிக்கப்படும். எனவே, ஆகஸ்ட் 2026 நிலவரப்படி இது offline setup கிடையாது. இந்தத் திட்டம் தொடங்கப்பட்டு சில வாரங்களே ஆகின்றன. ஏதேனும் ஒரு கட்டத்தில் நீங்கள் முந்தைய பதிப்பிற்கு (roll back) மாற வேண்டியிருக்கும் என்பதை உணர்ந்து, அதற்கேற்ப இதை நிறுவவும். நீங்கள் இதற்கு முன்பு server-ல் agent-ஐ இயக்கியதில்லை என்றால், running a coding agent on a VPS என்ற பகுதி இந்த வழிகாட்டிக்குத் தேவையான அடிப்படை விதிகளை விளக்குகிறது.

KiroCrew-க்குத் தேவையானவை மற்றும் அதன் நிலை (state) எங்குள்ளது

Native install-க்கு Python 3.10 அல்லது அதற்குப் புதிய பதிப்பு தேவை (இந்தத் திட்டம் 3.12-ஐப் பரிந்துரைக்கிறது). நீங்கள் dashboard-ஐ source-லிருந்து build செய்கிறீர்கள் என்றால், Node.js 18 அல்லது அதற்குப் புதிய பதிப்பு தேவை. மேலும் kiro-cli தேவைப்படுகிறது; இதை முதல்முறை இயக்கும்போது அதுவே நிறுவி, உள்நுழைந்து கொள்ளும். Container install-க்கு host-ல் இவை எதுவும் தேவையில்லை. அதற்கு Docker மட்டும் போதும். இதையே பெரும்பாலானோர் விரும்புவதற்கு இதுவே முக்கிய காரணம்.

இதன் நிலை (state) ~/.kiro/crew-ல் சேமிக்கப்படுகிறது. KIROCREW_HOME environment variable மூலம் இதை வேறு இடத்திற்கு மாற்றலாம். அந்த directory-க்குள் இருப்பவை:

  • config.json: gateway அமைப்புகள் மற்றும் chat channel நற்சான்றிதழ்கள்.
  • .env: ரகசியங்கள் (secrets).
  • workspace/memory/: விருப்பத்தேர்வுகள், திட்டக் குறிப்புகள் மற்றும் chat வரலாறு.
  • memory.db மற்றும் memory_index.db: semantic மற்றும் full-text indexes.
  • models/: embedding model, இது முதல்முறை இயக்கும்போது தரவிறக்கம் செய்யப்படும்.
  • gateway.log மற்றும் security_events.jsonl: runtime log மற்றும் பாதுகாப்பு நிகழ்வு log.

அந்த directory-யே முழுமையான install ஆகும். அதை ஒரு புதிய VPS-க்கு நகலெடுத்தால், உங்கள் agent-ஐயும் நகர்த்தியதாகிவிடும். இதனால்தான், install பகுதியை விட கீழே உள்ள backup பகுதி முக்கியமானது.

RAM-ஐ விட disk இடத்திற்குத் திட்டமிடுங்கள். Gateway என்பது ஒரு Python process; உண்மையில் கணினியின் சுமையை அதிகரிப்பது agent இயக்கும் காரியங்கள், build அல்லது test suite போன்றவைதான். Chat வரலாறு அதிகரிக்க அதிகரிக்க state directory-யின் அளவும் வளரும். Embedding model முதல்முறை இயக்கும்போதுதான் தரவிறக்கம் செய்யப்படும். எனவே, திட்டத்தின் முதல் மாதத்தில் வெளியிடப்படும் புள்ளிவிவரங்களை நம்புவதை விட, சில வாரங்களுக்குப் பிறகு உங்கள் சொந்த கணினியில் du -sh ~/.kiro/crew மூலம் அளவிடுங்கள்.

எந்த நிறுவல் முறையை நீங்கள் பயன்படுத்த வேண்டும்

இந்தத் திட்டம் மூன்று வழிகளை வெளியிடுகிறது. ஒற்றை வரி நிறுவி (one-line installer) ஒரு wheel-ஐப் பதிவிறக்கி, kirocrew-ஐ உங்கள் PATH-ல் சேர்க்கிறது:

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

இது ஒரு channel flag மற்றும் version flag-ஐ எடுத்துக்கொள்கிறது:

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

Container image ghcr.io/kirodotdev/kirocrew-ல் வெளியிடப்படுகிறது, இது ஒவ்வொரு tag-ன் கீழும் linux/amd64 மற்றும் linux/arm64 ஆகியவற்றுக்குக் கிடைக்கிறது. Source build என்பது git clone மற்றும் make build ஆகும்; இது குறியீட்டை (code) மாற்றும் பயனர்களுக்கானது, இயக்கும் பயனர்களுக்கானது அல்ல.

Container-ஐப் பயன்படுத்தவும். ஒரு native நிறுவல், உங்கள் பிற சேவைகளை இயக்கும் அதே host-ல் Python packages, Node மற்றும் kiro-cli ஆகியவற்றை வைக்கிறது. எனவே, ஒரு upgrade தோல்வியடைந்தால், அதை நீங்கள் கையால் சரிசெய்ய வேண்டியிருக்கும். Container, runtime-ஐ ஒரே image-லும், state-ஐ ஒரே volume-லும் வைத்திருக்கிறது. இதனால், ஒரு rollback என்பது வெறும் tag மாற்றமாகவும், மறுதொடக்கமாகவும் (restart) எளிதாகிறது.

Image-ஐ stable-க்கு பதிலாக ஒரு release tag-உடன் இணைக்கவும்

இந்தத் திட்டத்தின் சொந்த உதாரணம் stable tag-ஐப் பயன்படுத்துகிறது:

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

stable என்பது மாறும் தன்மை கொண்ட ஒரு tag ஆகும். இது எந்த நேரத்திலும் சமீபத்திய stable release-ஐச் சுட்டிக்காட்டும். எனவே, நீங்கள் தேர்வு செய்யாமலேயே அடுத்த pull-ன் போது நீங்கள் இயக்கும் version மாறக்கூடும்; மேலும், எந்த version இயங்குகிறது என்பதை இந்த tag பதிவு செய்யாது. Version tags மாற்ற முடியாதவை, எனவே ஒரு குறிப்பிட்ட version-ஐப் பயன்படுத்தவும். 6 August 2026 நிலவரப்படி, 5 August 2026 அன்று வெளியிடப்பட்ட 0.1.3 என்பதே புதிய release ஆகும். இதில் nightly என்ற tag-உம் உள்ளது; இது போன்ற புதிய திட்டங்களில், இந்த tag-ன் பொருள் குறியீடு இன்று காலை மாற்றப்பட்டது என்பதாகும்.

/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:

இதைத் தொடங்கி, அந்த image அதன் சொந்த HEALTHCHECK-க்காகப் பயன்படுத்தும் health endpoint-ஐச் சரிபார்க்கவும்:

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

docker compose ps ஒரு நிமிடத்திற்குள் container-ஐ healthy நிலையில் காட்ட வேண்டும், மேலும் /api/health எந்த token-உம் இன்றி பதிலளிக்கும் (/api/live மற்றும் /api/ready ஆகியவையும் அவ்வாறே பதிலளிக்கும், இதனால்தான் இவற்றை probes-ஆகப் பயன்படுத்த முடிகிறது). ஒருவேளை அதன் நிலை starting என்றே நீடித்தால், எதையும் மாற்றும் முன் docker logs kirocrew-ஐப் படிக்கவும். முதல் முறை இயக்கும்போது embedding model தரவிறக்கம் செய்யப்படும், எனவே இணைய வேகம் குறைவாக இருந்தால் முதல் தொடக்கம் தாமதமாகலாம்.

systemd மூலம் சேவையைத் தொடர்ந்து இயக்குதல்

restart: unless-stopped, Docker தொடங்கும் வரை காத்திருந்து, crash அல்லது reboot-க்கு பிறகு container-ஐ மீண்டும் இயக்கும். ஒரு unit file மூலம் இந்த dependency-ஐ தெளிவாக வரையறுக்கலாம்; இது backup எடுப்பதற்கு முன் முழு stack-ஐயும் ஒரே கட்டளையில் நிறுத்த உதவுகிறது. Docker Compose stack-ஐ boot-ல் தொடங்குதல் என்ற பகுதி இதற்கான பொதுவான முறையை விளக்குகிறது. KiroCrew-ன் கட்டமைப்பு /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-ல் active (exited) என்று இருக்க வேண்டும், இதுவே இந்த unit-க்கான சரியான நிலையாகும். Type=oneshot-ல் RemainAfterExit=yes-ஐப் பயன்படுத்துவது அவசியம், ஏனெனில் docker compose up -d கட்டளை container தொடங்கியவுடன் உடனடியாக முடிந்துவிடும்: systemd இங்கே stack இயங்குகிறதா என்பதைக் கண்காணிக்கிறதே தவிர, foreground process-ஐ அல்ல. இதற்குப் பதிலாக Type=simple என்று எழுதினால், systemd அந்த கட்டளை உடனடியாக முடிவடைவதைக் கண்டு, சேவையை dead என்று குறிக்கும்; பின் உங்கள் Restart= அமைப்பைப் பொறுத்து அது முயற்சியைக் கைவிடும் அல்லது restart-loop-ல் சிக்கிக்கொள்ளும். ஒரு native install-க்கு, அந்த project-ஆனது kirocrew service install என்ற சொந்த unit file-ஐ வழங்குகிறது; இது /etc/systemd/system/kirocrew.service-ஐ எழுதி, gateway-ஐ உங்கள் user-ஆக இயக்கும். இரண்டு unit-களையும் ஒரே நேரத்தில் இயக்க வேண்டாம். இந்தத் தலைப்பைப் பற்றிய விரிவான தகவல்களை VPS-ல் systemd services மற்றும் timers பகுதியில் காணலாம்.

முதல் முறை இயக்குதல்: உள்நுழைந்து dashboard token பெறுதல்

Container gateway-ஐத் தொடங்குகிறது, ஆனால் agent runtime இன்னும் உள்நுழையவில்லை. Container-க்குள் உள்நுழையவும்:

docker exec -it kirocrew kiro-cli login

இது ஒரு device code மற்றும் நீங்கள் உங்கள் browser-ல் திறக்க வேண்டிய URL-ஐக் காட்டும். பிறகு ஒரு dashboard token-ஐ உருவாக்கவும்:

docker exec kirocrew kirocrew token --ttl 2h

Dashboard URL என்பது http://localhost:5476/?token=<the token> ஆகும். Tokens காலாவதியாகும்: sessions இயல்பாக ஒரு மணிநேரம் மட்டுமே இருக்கும், ஆவணப்படுத்தப்பட்ட அதிகபட்ச காலம் இருபது மணிநேரம் ஆகும். Dashboard காலியாகத் தெரிந்தாலோ அல்லது உங்களை மீண்டும் வெளியேற்றினாலோ, அது பெரும்பாலும் token காலாவதியானதைக் குறிக்கும், எனவே புதிய ஒன்றை உருவாக்கவும். Token-ஐ ஒரு ticket-லோ அல்லது chat message-லோ ஒருபோதும் பகிர வேண்டாம், ஏனெனில் அதை வைத்திருப்பவர் உங்கள் agent-ஐக் கட்டுப்படுத்த முடியும்.

SSH வழியாக dashboard-ஐ அணுகுதல் மற்றும் port 5476-ஐ ஒருபோதும் பொதுவெளியில் வெளியிடக்கூடாது

திட்டத்தின் உதாரணத்தில் உள்ள bind address-ஐ மீண்டும் கவனிக்கவும்: -p 127.0.0.1:5476:5476. container-க்குள் gateway 0.0.0.0-ல் கேட்கிறது (listen), ஏனெனில் அது port mapping வழியாக அணுகப்பட வேண்டும். ஆனால், அந்த mapping host-ன் loopback முகவரியில் மட்டுமே வெளியிடப்படுகிறது. 127.0.0.1: முன்னொட்டை நீக்கினால், அந்த port-ஐ ஸ்கேன் செய்யும் எவருக்கும் gateway பொது இணையத்தில் கிடைத்துவிடும். firewall விதி கூட உங்களைக் காப்பாற்றாது: Docker, ufw-ன் filtering-க்கு முன்பே செயல்படுத்தப்படும் DNAT விதிகளை எழுதுவதன் மூலம் port-களை வெளியிடுகிறது, எனவே ufw deny 5476 வெளியிடப்பட்ட port-க்கு எந்தப் பாதுகாப்பையும் தராது. Docker ports bypassing ufw அந்தச் செயல்பாட்டை விளக்குகிறது.

அதற்குப் பதிலாக, உங்கள் மடிக்கணினியிலிருந்து SSH வழியாக port-ஐ forward செய்யவும்:

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

அதை இயங்கவிட்டு, உள்ளூரில் http://localhost:5476/?token=<the token>-ஐத் திறக்கவும். ஒவ்வொரு இணைப்பிலும் இந்த forward தானாகவே நடக்க, அதை ~/.ssh/config-ல் சேர்க்கவும்:

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

உங்கள் மடிக்கணினியில் port 5476 ஏற்கனவே பயன்பாட்டில் இருந்தால், இடதுபுற எண்ணை மட்டும் மாற்றவும்: ssh -N -L 45476:127.0.0.1:5476 you@your-server.example.com, பிறகு http://localhost:45476/?token=...-க்குச் செல்லவும்.

tunnel வழியாகச் செல்லும்போது எதிர்பார்க்க வேண்டிய ஒரு ஆவணப்படுத்தப்பட்ட செயல்பாடு இது: gateway, forward செய்யப்பட்ட கோரிக்கைகளை remote கோரிக்கைகளாகக் கருதுகிறது, எனவே dashboard-ல் உள்ள config-write மற்றும் secret-reveal endpoints அவற்றை நிராகரிக்கும். SSH வழியாகச் செய்ய முடியாத settings மாற்றம் இது, இது பிழை (bug) அல்ல. அதற்குப் பதிலாக host-ல் config-ஐத் திருத்தவும்:

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

கைபேசி அணுகலுக்கு, இந்தத் திட்டம் Tailscale-ன் tailscale serve-ஐப் பரிந்துரைக்கிறது. இது dashboard-ஐ பொதுவான hostname-ல் வைக்காமல், உங்கள் சொந்த tailnet-க்குள் வைத்திருக்கும். பொது reverse proxy-ஐ விட இதைத் தேர்ந்தெடுக்கவும். token URL-ல் பயணிக்கிறது, மேலும் அந்தப் பாதையில் உள்ள ஒவ்வொரு access log-லும் URL எழுதப்படும்.

ஏஜெண்டிற்கு மிகச்சிறிய பாதிப்பு எல்லையை (blast radius) வழங்குதல்

முதல்முறை தொடங்கும்போதே, sandbox ஆதரவு உள்ளதா என்பதை container கண்டறியும்; அதன் முடிவைப் பொறுத்தே ஏஜெண்டுகள் எதையும் இயக்க முடியுமா என்பது தீர்மானிக்கப்படும். namespace isolation வசதி இருந்தால், ஏஜெண்டின் subprocess-கள் தனிமைப்படுத்தப்பட்டு இயங்கும். இந்த வசதி இல்லாமலும், KIROCREW_ALLOW_UNSANDBOXED=1 அமைக்கப்படாமலும் இருந்தால், பாதுகாப்பற்ற முறையில் இயக்குவதற்குப் பதிலாக, execution மறுக்கப்படும். எனவே, ஒரு gateway ஆரோக்கியமாகத் தெரிந்து, ஆனால் அனைத்து task-களும் தேங்கி நின்றால், பெரும்பாலும் இதுவே காரணமாக இருக்கும். அந்த முதல் இயக்கத்தின் முடிவு docker logs kirocrew-ல் சேமிக்கப்படும். இந்தத் திட்டம் ஒரு seccomp (secure computing mode) profile-ஐயும் வெளியிடுகிறது, அதை நீங்கள் பயன்படுத்தலாம்:

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

நீங்கள் KIROCREW_ALLOW_UNSANDBOXED=1-ஐ அமைத்தால், என்ன மாற்றம் நிகழ்ந்துள்ளது என்பதைத் தெளிவாகப் புரிந்துகொள்ளுங்கள்: இப்போது ஏஜெண்டிற்கும் உங்கள் server-க்கும் இடையே உள்ள ஒரே பாதுகாப்பு எல்லை அந்த container மட்டும்தான். இந்தத் திட்டத்தின் எச்சரிக்கையை முழுமையாக மீண்டும் குறிப்பிடுவது அவசியம். ஏஜெண்டிற்கு நேரடியாக வழங்க விரும்பாத எந்தவொரு host path-ஐயும் mount செய்யாதீர்கள். நடைமுறையில், Docker socket, /-ன் எந்தவொரு bind mount, மற்றும் பிற service-களின் தரவுகளைக் கொண்ட எந்தவொரு directory-யையும் இதில் சேர்க்கக்கூடாது.

மீதமுள்ளவை, கட்டளைகளை இயக்க அனுமதிக்கப்படும் ஒவ்வொரு ஏஜெண்டிற்கும் பொருந்தும் கட்டமைப்பாகும். அதன் credentials-ஐ அதற்குத் தேவையான ஒரு repository அல்லது ஒரு bucket-க்கு மட்டும் கட்டுப்படுத்துங்கள்; கணக்கு முழுமைக்குமான உரிமைகளைக் கொண்ட personal token-ஐ ஒருபோதும் பயன்படுத்தாதீர்கள். அதன் home directory-யில் வேறெதுவும் இல்லாத ஒரு பிரத்யேக user-ஆக அதை இயக்குங்கள்; இதற்காகத்தான் VPS-ல் குறைந்தபட்ச உரிமை கொண்ட பயனர்கள் உருவாக்கப்பட்டுள்ளது. ஏஜெண்ட் குறியீட்டை எழுதி, பின் அதை இயக்கும்போது, அது சேதப்படுத்த அனுமதிக்கப்பட்ட ஒரு machine-ஐ அதற்கு வழங்குங்கள்: coding ஏஜெண்டுகளுக்கான தற்காலிக VM என்பது இந்த compose file-ல் உள்ள எந்தவொரு flag-ஐ விடவும் வலிமையான எல்லையாகும், ஏனெனில் அதை நீங்கள் சுத்தம் செய்வதற்குப் பதிலாக அழித்துவிடலாம். இதே காரணம்தான் VPS-ல் OpenClaw-ஐ பாதுகாப்பாக இயக்குதல் மற்றும் VPS-ல் Hermes ஏஜெண்டைத் தாமாகவே hosting செய்தல் ஆகியவற்றையும் வடிவமைக்கிறது. கருவிகளும் பாதிப்பு எல்லையின் ஒரு பகுதியே: ஏஜெண்டிற்கு இணையத் தேடல் வசதியை வழங்குவது, அது எடுக்கும் ஒவ்வொரு பக்கத்தையும் நம்பகத்தன்மையற்ற உள்ளீடாக மாற்றும், எனவே உங்கள் சொந்த SearXNG instance-ஐப் பயன்படுத்துவது என்பது ஒரு தொழில்நுட்ப முடிவாக மட்டுமல்லாமல், prompt injection-ஐத் தடுக்கும் முடிவாகவும் அமைகிறது. திட்டமிடப்பட்ட வேலைகள் நீங்கள் தூங்கும்போது பணத்தைச் செலவழிக்கும், ஏனெனில் inference உங்கள் Kiro திட்டத்தின் கீழ் கட்டணம் வசூலிக்கும், எனவே nightly job-ஐச் சேர்ப்பதற்கு முன் VPS-ல் AI ஏஜெண்டின் செலவைக் கட்டுப்படுத்துதல் என்பதில் விவரிக்கப்பட்டுள்ள வரம்புகளை அமைத்திடுங்கள்.

ஒவ்வொரு மேம்படுத்தலுக்கு முன்பும் state volume-ஐ காப்புப்பிரதி எடுக்கவும்

முதலில் உண்மையான volume பெயரை கண்டறியவும். Compose, project பெயரை முன்னொட்டாகக் கொண்டு volumes-ஐ உருவாக்கும். இது இயல்பாக directory பெயராக இருக்கும். எனவே kirocrew-home என /opt/kirocrew/compose.yaml-ல் குறிப்பிடப்பட்ட volume, kirocrew_kirocrew-home என உருவாக்கப்படும்:

docker volume ls

எதையும் நகலெடுக்கும் முன் gateway-ஐ நிறுத்தவும். memory.db மற்றும் memory_index.db ஆகியவை SQLite databases ஆகும். தரவுத்தளம் எழுதப்படும்போது அதை நகலெடுத்தால், முழுமையற்ற transaction நகலெடுக்கப்படலாம். இது மீட்டமைக்கும்போது கோப்பை சிதைத்துவிடும். project-ன் சொந்த migration வழிமுறைகளும் இதையே கூறுகின்றன: gateways நிறுத்தப்பட்டிருக்கும்போது மட்டுமே memory-ஐ நகர்த்தவும்.

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

archive-ஐ server-லிருந்து வெளியே நகலெடுக்கவும். மீட்டமைப்பதும் இதே கட்டளைதான், ஆனால் container நிறுத்தப்பட்டிருக்க வேண்டும் மற்றும் tar czf-க்கு பதிலாக tar xzf-ஐ பயன்படுத்த வேண்டும்:

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

புதிய host-க்கு மாறுவது என்பது, அதே இடத்தில் மீட்டமைப்பதிலிருந்து மாறுபட்டது. இது குறித்து project தெளிவாகக் குறிப்பிடுகிறது. workspace/memory/-ன் கீழ் உள்ள chat history மற்றும் project notes ஆகியவற்றை மாற்றிக்கொள்ளலாம். அதேபோல் இரண்டு database கோப்புகளையும் config.json-ஐயும் மாற்றலாம். PID கோப்புகள், security event log மற்றும் .env ஆகியவை பழைய host-டன் தொடர்புடையவை. எனவே அவற்றை விட்டுவிட்டு, புதிய server-ல் secrets-ஐ மீண்டும் உள்ளிடவும்.

தவறான upgrade-ஐ எவ்வாறு rollback செய்வது

Upgrade செய்வது எளிதானது, ஏனெனில் நீங்கள் ஒரு version-ஐ pin செய்துள்ளீர்கள், அதுவே பாதுகாப்பானது. முதலில் backup எடுக்கவும், பிறகு 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 அந்த image ஏற்கனவே server-ல் இல்லையென்றால் அதைத் தரவிறக்கம் செய்யும், எனவே tag-ஐ மாற்றுவதே முழுமையான upgrade ஆகும். Rollback செய்வதும் பழைய version எண்ணைப் பயன்படுத்தி அதே வரிசையில் செய்வதே ஆகும். Version tags மாற்ற முடியாதவை என்பதால், இது உங்களுக்கு முன்பு இருந்த அதே image-ஐத் தரும்.

Binary எந்தச் சிக்கலும் இன்றி rollback ஆகிவிடும். ஆனால், state மாறுபடலாம். புதிய gateway, config.json-ஐ மாற்றியமைக்கலாம் அல்லது memory databases-ஐ பழைய gateway-ஆல் படிக்க முடியாத வடிவத்திற்கு மாற்றலாம். ஆகஸ்ட் 2026 நிலவரப்படி, downgrade செய்வதற்கான வழிமுறைகள் எதுவும் ஆவணப்படுத்தப்படவில்லை. எனவே, பழைய image இயங்கியும் அது சரியாகச் செயல்படவில்லை என்றால், அதை debug செய்ய வேண்டாம். அதை நிறுத்திவிட்டு, upgrade செய்வதற்கு முன்பு எடுத்த backup-ஐ restore செய்துவிட்டு மீண்டும் தொடங்கவும். இதற்காகவே backup முதலில் எடுக்கப்பட வேண்டும். Upgrade-ஐ உடனே செய்துவிட்டு, backup-ஐப் பிறகு எடுத்துக்கொள்ளலாம் என்ற பழக்கம், இவ்வளவு புதிய திட்டங்களில் தோல்வியையே தரும்.

இங்கு நிரூபிக்கப்படாதவை

இந்த மென்பொருளின் வயது குறித்து வெளிப்படையாக இருக்க வேண்டும். இந்த வழிகாட்டி எழுதப்படும் நேரத்தில், 0.1.3 பதிப்பு வெளியாகி சில நாட்களே ஆகின்றன. இதன் release notes என்பது தானியங்கி changelog இணைப்புகளே தவிர, migration குறிப்புகள் அல்ல. மேலும், மேம்படுத்தல்கள் (upgrades) குறித்த நீண்டகால அனுபவம் இன்னும் இல்லை. இந்த வழிகாட்டியில் உள்ள எதுவும் நீண்டகால முடிவுகள் அல்ல. எனவே, memory பயன்பாடு, database அளவு மற்றும் scheduler-ன் நம்பகத்தன்மை ஆகியவற்றை உங்கள் சொந்த server-ல் நீங்களே அளவிட வேண்டும்; அவற்றை அப்படியே எடுத்துக்கொள்ள வேண்டாம்.

நீங்கள் சார்ந்திருப்பதற்கு முன்பு, இரண்டு செயல்பாடுகளை நீங்களே சோதித்துப் பார்ப்பது நல்லது. முதலாவதாக, புதிய பதிப்பால் எழுதப்பட்ட தரவை பழைய பதிப்பு (downgrade) வாசிக்கிறதா என்பதைச் சோதிக்கவும். இதைச் செய்யும்போது, பாதிப்பு ஏற்படாதவாறு volume-ன் நகலில் (copy) சோதிக்கவும்; சேவை முடங்கியிருக்கும்போது செய்ய வேண்டாம். இரண்டாவதாக, திட்டமிடப்பட்ட ஒரு பணி (scheduled job) நடக்கும்போது, Kiro sign-in காலாவதியானால் gateway என்ன செய்கிறது என்பதைச் சோதிக்கவும். இவை இரண்டுமே ஒரு புதிய திட்டத்தில் (project) அடுத்தடுத்த வெளியீடுகளில் மெதுவாகச் சரிசெய்யப்படும் குறைபாடுகள் ஆகும். இவற்றை இப்போதே சரிபார்ப்பது எளிது.

FAQ

எனது server-ன் public IP-ல் KiroCrew dashboard ஏன் திறக்கவில்லை?

ஏனெனில், கொடுக்கப்பட்டுள்ள உதாரணம் port-ஐ loopback முகவரியுடன் இணைக்கிறது (bind). -p 127.0.0.1:5476:5476, container-ன் port-ஐ host-ன் loopback முகவரிக்கு மட்டுமே மாற்றுகிறது; இது திட்டமிட்டே செய்யப்பட்டுள்ளது. ssh -N -L 5476:127.0.0.1:5476 you@your-server மூலம் SSH வழியாக port-ஐ forward செய்து, உங்கள் laptop-ல் http://localhost:5476/?token=<token>-ஐத் திறந்து அணுகவும். 127.0.0.1: முன்னொட்டை நீக்கி அதை அணுகக்கூடியதாக மாற்றினால், gateway பொது இணையத்தில் (public internet) வெளிப்படும். Docker-ன் published-port DNAT விதிகள் ufw traffic-ஐ வடிகட்டுவதற்கு முன்பே செயல்படுத்தப்படுவதால், firewall விதியால் இதைத் தடுக்க முடியாது.

KiroCrew தனது தரவை எங்கே சேமிக்கிறது, எதை backup எடுக்க வேண்டும்?

அனைத்து தரவுகளும் ~/.kiro/crew-ன் கீழ் உள்ளன. இது container image-க்குள் /home/kirocrew/.kiro/crew ஆக உள்ளது, மேலும் KIROCREW_HOME இதை வேறு இடத்திற்கு மாற்றுகிறது. gateway-ஐ நிறுத்திவிட்டு, முழு directory-ஐயோ அல்லது முழு Docker volume-ஐயோ backup எடுக்கவும். memory.db மற்றும் memory_index.db ஆகியவை SQLite databases என்பதால், gateway எழுதும்போதே நகல் எடுத்தால் தரவு முரண்பாடு ஏற்படலாம். புதிய host-க்கு மாறும்போது, workspace/memory/, இரண்டு database கோப்புகள் மற்றும் config.json ஆகியவற்றை எடுத்துச் செல்லவும். PID கோப்புகள், security event log மற்றும் .env ஆகியவை பழைய host-க்கு உரியவை.

நான் stable tag-ஐப் பயன்படுத்த வேண்டுமா அல்லது version tag-ஐப் பயன்படுத்த வேண்டுமா?

Version tag-ஐப் பயன்படுத்தவும். ஒவ்வொரு முறை software release செய்யப்படும்போதும் stable மாறுகிறது. எனவே, அடுத்த முறை pull செய்யும்போது நீங்கள் இயக்கும் version மாறக்கூடும், மேலும் அந்த tag-ஐ வைத்து நீங்கள் எதை இயக்குகிறீர்கள் என்பதை அறிய முடியாது. 0.1.3 போன்ற version tags மாற்ற முடியாதவை (immutable). இதுவே rollback செய்ய உதவுகிறது: பழைய எண்ணை மீண்டும் இட்டால், அதே image கிடைக்கும். 6 August 2026 நிலவரப்படி, புதிய release 0.1.3 ஆகும்.

எனது agent ஏன் எந்தக் கட்டளையையும் இயக்க மறுக்கிறது?

container தனது முதல் தொடக்கத்தின்போது sandbox ஆதரவைச் சோதிக்கும். agent subprocess-களைத் தனிமைப்படுத்த முடியாமல், KIROCREW_ALLOW_UNSANDBOXED=1 அமைக்கப்படாமல் இருந்தால், அவற்றை unconfined நிலையில் இயக்குவதற்குப் பதிலாக, இயக்க மறுத்துவிடும். இதனால் gateway சரியாக இருப்பது போலத் தோன்றும், ஆனால் அனைத்து task-களும் தேங்கி நிற்கும். docker logs kirocrew அந்த முதல் இயக்கத்தின் sandbox முடிவைக் காட்டும். இந்த variable-ஐ அமைப்பது, agent-க்கும் host-க்கும் இடையே container-ஐ மட்டுமே எல்லையாக மாற்றும். எனவே, இதை அமைத்தால், agent-க்கு நேரடியாக வழங்க விரும்பாத எதையும் mount செய்ய வேண்டாம்.

KiroCrew-ஐ self-host செய்ய எனக்கு Kiro கணக்கு தேவையா?

ஆம், August 2026 நிலவரப்படி தேவை. KiroCrew என்பது Apache 2.0 உரிமத்தின் கீழ் உள்ள இலவச மென்பொருள், ஆனால் இது kiro-cli-ஐ இயக்குகிறது. இதற்கு ஒருமுறை sign-in செய்ய வேண்டும், மேலும் agent inference கட்டணங்கள் Kiro plan-ன் கீழ் வசூலிக்கப்படும். container-க்குள், docker exec -it kirocrew kiro-cli login-ஐ இயக்கி, உங்கள் browser-ல் device code-ஐ அங்கீகரிக்கவும். அந்த sign-in முடியும் வரை, gateway தொடங்கும் மற்றும் dashboard தோன்றும், ஆனால் agent-க்குத் தொடர்புகொள்ள எந்த model-ம் இருக்காது.

#kirocrew#ai-agents#docker#systemd#self-hosting