VPS-এ KiroCrew কীভাবে self-host করবেন

ল্যাপটপের পরিবর্তে VPS-এ KiroCrew কেন self-host করবেন

KiroCrew শুধুমাত্র এমন একটি মেশিনে চালানোই কার্যকর যা কখনোই বন্ধ হয় না, তাই এর জন্য ল্যাপটপের চেয়ে VPS-ই সঠিক জায়গা। KiroCrew সেশন হিস্ট্রি, সিম্যান্টিক মেমোরি, শিডিউল করা কাজ এবং অ্যাপ্রুভাল কিউ ডিস্কে জমা রাখে এবং প্রসেস রিস্টার্ট হলে তা পুনরায় লোড করে। ভোর 3টায় যখন কোনো শিডিউল করা কাজ চলার কথা, তখন প্রসেসটি চালু না থাকলে এর কোনোটিই কাজে আসে না, আর ল্যাপটপ বন্ধ থাকলে তা চালানো সম্ভব নয়।

KiroCrew হলো Kiro টিমের একটি ওপেন সোর্স এজেন্ট ওয়ার্কস্পেস, যা Apache 2.0 লাইসেন্সের অধীনে এবং এর প্রথম পাবলিক রিলিজ 2026 সালের আগস্ট মাসের শুরুতে আসে। gateway নামক একটি প্রসেস এর স্টেট নিয়ন্ত্রণ করে এবং 5476 পোর্টে একটি ওয়েব ড্যাশবোর্ড পরিবেশন করে। আপনি ড্যাশবোর্ড থেকে, kirocrew CLI থেকে অথবা Slack-এর মতো কোনো চ্যাট চ্যানেল থেকে এই gateway-তে পৌঁছাতে পারেন। আপনি শুধুমাত্র এই gateway-টিই self-host করছেন, তাই এই নির্দেশিকাটি কীভাবে এটিকে সচল রাখা যায়, কীভাবে পাবলিক ইন্টারনেট থেকে দূরে রাখা যায় এবং কোনো খারাপ আপগ্রেডের পর কীভাবে আগের অবস্থায় ফিরিয়ে আনা যায়, তা নিয়ে।

শুরু করার আগে দুটি বিষয় জেনে রাখা প্রয়োজন। KiroCrew kiro-cli ব্যবহার করে, যার জন্য একটি Kiro অ্যাকাউন্টের মাধ্যমে একবার সাইন-ইন করা প্রয়োজন এবং এজেন্ট ইনফারেন্সের খরচ Kiro প্ল্যান থেকে কাটা হয়, তাই 2026 সালের আগস্ট পর্যন্ত এটি কোনো অফলাইন সেটআপ নয়। প্রজেক্টটিও মাত্র কয়েক সপ্তাহ পুরনো। ধরে নিন যে কোনো এক পর্যায়ে আপনাকে আগের ভার্সনে ফিরে যেতে (roll back) হতে পারে, তাই এমনভাবে ইনস্টল করুন যাতে আপনি তা করতে পারেন। আপনি যদি আগে কখনো সার্ভারে এজেন্ট না চালিয়ে থাকেন, তবে VPS-এ কোডিং এজেন্ট চালানো বিষয়টি পড়ে নিন, কারণ এই নির্দেশিকাটি সেই মৌলিক বিষয়গুলোর ওপর ভিত্তি করেই তৈরি করা হয়েছে।

KiroCrew-এর যা প্রয়োজন এবং এর স্টেট যেখানে থাকে

একটি নেটিভ ইনস্টলেশনের জন্য Python 3.10 বা তার পরবর্তী সংস্করণ (প্রজেক্টটি 3.12 ব্যবহারের পরামর্শ দেয়), ড্যাশবোর্ড সোর্স থেকে বিল্ড করতে চাইলে Node.js 18 বা তার পরবর্তী সংস্করণ এবং kiro-cli প্রয়োজন, যা প্রথমবার চালু করার সময় স্বয়ংক্রিয়ভাবে ইনস্টল ও সাইন-ইন হয়ে যায়। কন্টেইনার ইনস্টলেশনের ক্ষেত্রে হোস্ট মেশিনে এগুলোর কোনোটিরই প্রয়োজন নেই। এর জন্য শুধু Docker প্রয়োজন। এটিই কন্টেইনার ব্যবহারের প্রধান কারণ।

স্টেট ~/.kiro/crew ডিরেক্টরিতে থাকে এবং KIROCREW_HOME এনভায়রনমেন্ট ভেরিয়েবল ব্যবহার করে এটিকে অন্য কোথাও সরিয়ে নেওয়া যায়। এর ভেতরে যা থাকে:

• config.json: গেটওয়ে সেটিংস এবং চ্যাট চ্যানেলের ক্রেডেনশিয়াল।
• .env: সিক্রেটস বা গোপনীয় তথ্য।
• workspace/memory/: পছন্দসমূহ, প্রজেক্ট নোট এবং চ্যাট হিস্ট্রি।
• memory.db এবং memory_index.db: সিমান্টিক এবং ফুল-টেক্সট ইনডেক্স।
• models/: এম্বেডিং মডেল, যা প্রথমবার চালানোর সময় ডাউনলোড হয়।
• gateway.log এবং security_events.jsonl: রানটাইম লগ এবং সিকিউরিটি ইভেন্ট লগ।

এই ডিরেক্টরিটিই হলো মূল ইনস্টলেশন। এটিকে একটি নতুন VPS-এ কপি করলেই আপনার এজেন্ট স্থানান্তরিত হয়ে যাবে, আর এই কারণেই ইনস্টলেশন সেকশনের চেয়ে নিচের ব্যাকআপ সেকশনটি বেশি গুরুত্বপূর্ণ।

RAM-এর চেয়ে ডিস্কের জায়গার পরিকল্পনা করুন। গেটওয়ে একটি Python প্রসেস; তবে এজেন্ট যা রান করে—যেমন কোনো বিল্ড বা টেস্ট স্যুট—সেটিই মূলত সিস্টেমের ওপর চাপ সৃষ্টি করে। চ্যাট হিস্ট্রির সাথে সাথে স্টেট ডিরেক্টরির আকার বাড়তে থাকে এবং প্রথমবার চালু করার সময় এম্বেডিং মডেলটি ডাউনলোড হয়। তাই প্রজেক্টের শুরুর দিকে প্রকাশিত কোনো তথ্যের ওপর নির্ভর না করে, কয়েক সপ্তাহ ব্যবহারের পর আপনার নিজের মেশিনে du -sh ~/.kiro/crew কমান্ড দিয়ে এর আকার মেপে দেখুন।

তিনটি ইন্সটলেশন পথের মধ্যে কোনটি আপনার ব্যবহার করা উচিত

প্রকল্পটি তিনটি পদ্ধতি প্রকাশ করে। এক লাইনের ইন্সটলারটি একটি 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

কন্টেইনার ইমেজটি ghcr.io/kirodotdev/kirocrew-এ প্রকাশিত হয়, যা প্রতিটি ট্যাগ-এর অধীনে linux/amd64 এবং linux/arm64-এর জন্য উপলব্ধ। সোর্স বিল্ডটি হলো git clone এবং make build-এর সমষ্টি, এবং এটি তাদের জন্য যারা কোড পরিবর্তন করছেন, যারা এটি চালাচ্ছেন তাদের জন্য নয়।

কন্টেইনার ব্যবহার করুন। একটি নেটিভ ইন্সটলেশন আপনার অন্যান্য সার্ভিস যে হোস্টে চলছে, সেখানেই Python প্যাকেজ, Node এবং kiro-cli স্থাপন করে। ফলে আপগ্রেড ব্যর্থ হলে আপনাকে তা হাতে ঠিক করতে হবে। কন্টেইনার রানটাইমকে একটি ইমেজে এবং স্টেটকে একটি ভলিউমে রাখে, যার ফলে রোলব্যাক করা মানে কেবল একটি ট্যাগ পরিবর্তন এবং রিস্টার্ট করা।

ইমেজটিকে একটি রিলিজ ট্যাগের সাথে পিন করুন, stable-এর সাথে নয়

প্রজেক্টের নিজস্ব উদাহরণে stable ট্যাগটি ব্যবহার করা হয়েছে:

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

stable একটি পরিবর্তনশীল ট্যাগ। এটি সবসময় সর্বশেষ স্থিতিশীল রিলিজকে নির্দেশ করে, তাই পরবর্তী pull-এর সময় আপনার অজান্তেই ভার্সন পরিবর্তিত হয়ে যেতে পারে এবং কোন ভার্সনটি ব্যবহৃত হচ্ছে তার কোনো রেকর্ড থাকে না। ভার্সন ট্যাগগুলো অপরিবর্তনীয়, তাই একটি নির্দিষ্ট ভার্সন পিন করুন। 6 আগস্ট 2026 অনুযায়ী সর্বশেষ রিলিজ হলো 0.1.3, যা 5 আগস্ট 2026-এ প্রকাশিত হয়েছে। এছাড়া একটি nightly ট্যাগও রয়েছে, যা এই ধরনের নতুন প্রজেক্টের ক্ষেত্রে বোঝায় যে কোডটি আজ সকালেই পরিবর্তিত হয়েছে।

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

এটি চালু করুন, তারপর হেলথ এন্ডপয়েন্টটি চেক করুন যা ইমেজটি তার নিজস্ব HEALTHCHECK-এর জন্য ব্যবহার করে:

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

docker compose ps-এর উচিত এক মিনিটের মধ্যে কন্টেইনারটিকে healthy হিসেবে রিপোর্ট করা, এবং /api/health কোনো টোকেন ছাড়াই উত্তর দেয় (যেমনটা /api/live এবং /api/ready-এর ক্ষেত্রেও হয়, যা এদেরকে প্রোব হিসেবে ব্যবহারের উপযোগী করে তোলে)। যদি অবস্থা starting-তেই আটকে থাকে, তবে কোনো কিছু পরিবর্তন করার আগে docker logs kirocrew পড়ুন। প্রথমবার চালানোর সময় এটি এম্বেডিং মডেল ডাউনলোড করে, তাই ধীরগতির সংযোগের ক্ষেত্রে প্রথমবার চালু হতে সময় বেশি লাগতে পারে।

systemd দিয়ে সার্ভিস চালু রাখা

restart: unless-stopped ক্র্যাশ বা রিবুট হওয়ার পর কন্টেইনারটিকে পুনরায় চালু করে, যদি Docker স্বয়ংক্রিয়ভাবে বুট হওয়ার সময় চালু হয়। একটি unit file এই নির্ভরতাকে স্পষ্ট করে এবং ব্যাকআপ নেওয়ার আগে পুরো স্ট্যাকটি বন্ধ করার জন্য একটি কমান্ড প্রদান করে। বুট হওয়ার সময় Docker Compose স্ট্যাক চালু করা-তে সাধারণ পদ্ধতিটি আলোচনা করা হয়েছে। 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) হওয়া উচিত, যা এই ইউনিটের জন্য সঠিক ফলাফল। Type=oneshot-এর সাথে RemainAfterExit=yes এখানে ব্যবহার করা হয়েছে কারণ কন্টেইনার চালু হওয়ার সাথে সাথেই docker compose up -d কমান্ডটি শেষ হয়ে যায়: systemd এখানে স্ট্যাকটি চালু আছে কি না তা ট্র্যাক করে, কোনো foreground প্রসেস নয়। এর পরিবর্তে Type=simple লিখলে systemd দেখবে যে কমান্ডটি সাথে সাথেই শেষ হয়ে গেছে, তাই এটি সার্ভিসটিকে মৃত হিসেবে চিহ্নিত করবে এবং আপনার Restart= সেটিং অনুযায়ী হয় হাল ছেড়ে দেবে অথবা রিস্টার্ট লুপে পড়ে যাবে। নেটিভ ইন্সটলেশনের জন্য প্রজেক্টটি নিজস্ব সমতুল্য ফাইল kirocrew service install প্রদান করে, যা /etc/systemd/system/kirocrew.service তৈরি করে এবং আপনার ইউজার হিসেবে গেটওয়েটি চালায়। উভয় ইউনিট একসাথে চালাবেন না। এই বিষয়ের বিস্তারিত আলোচনা VPS-এ systemd সার্ভিস এবং টাইমার-এ রয়েছে।

প্রথমবার চালানো: সাইন ইন করুন এবং ড্যাশবোর্ড টোকেন পান

কন্টেইনারটি গেটওয়ে চালু করে, কিন্তু এজেন্ট রানটাইম তখনও সাইন ইন করা থাকে না। কন্টেইনারের ভেতরে সাইন ইন করুন:

docker exec -it kirocrew kiro-cli login

এটি একটি ডিভাইস কোড এবং একটি URL প্রদর্শন করবে যা আপনাকে আপনার নিজের ব্রাউজারে খুলতে হবে। এরপর একটি ড্যাশবোর্ড টোকেন তৈরি করুন:

docker exec kirocrew kirocrew token --ttl 2h

ড্যাশবোর্ড URL হলো http://localhost:5476/?token=<the token>। টোকেনের মেয়াদ শেষ হয়ে যায়: সেশন সাধারণত এক ঘণ্টার জন্য কার্যকর থাকে এবং নথিপত্র অনুযায়ী সর্বোচ্চ মেয়াদ বিশ ঘণ্টা। যদি ড্যাশবোর্ড খালি দেখায় বা আপনাকে সরাসরি বের করে দেয়, তবে সাধারণত টোকেনের মেয়াদ শেষ হয়ে গেছে বলে ধরে নিতে হবে; সেক্ষেত্রে নতুন একটি টোকেন তৈরি করুন। কোনো টিকিট বা চ্যাট মেসেজে কখনোই টোকেন পেস্ট করবেন না, কারণ যার কাছে টোকেন থাকবে, সে আপনার এজেন্টের নিয়ন্ত্রণ পেয়ে যাবে।

SSH-এর মাধ্যমে ড্যাশবোর্ড অ্যাক্সেস করুন এবং কখনোই port 5476 পাবলিক করবেন না

প্রজেক্টের উদাহরণে bind address-টি আবার দেখুন: -p 127.0.0.1:5476:5476। কন্টেইনারের ভেতরে গেটওয়েটি 0.0.0.0-এ লিসেন করে, কারণ এটিকে port mapping-এর মাধ্যমে অ্যাক্সেসযোগ্য হতে হয়, কিন্তু এই ম্যাপিংটি হোস্টের শুধুমাত্র loopback-এ প্রকাশিত হয়। 127.0.0.1: প্রিফিক্সটি মুছে ফেললে গেটওয়েটি পাবলিক ইন্টারনেটে উন্মুক্ত হয়ে যাবে এবং যে কেউ পোর্টটি স্ক্যান করতে পারবে। ফায়ারওয়াল রুলও আপনাকে রক্ষা করতে পারবে না: Docker পোর্টগুলোকে DNAT রুল লিখে পাবলিশ করে, যা ufw-এর ফিল্টারিংয়ের আগেই কার্যকর হয়, তাই ufw deny 5476 একটি প্রকাশিত পোর্টের ক্ষেত্রে কোনো কাজ করে না। Docker ports bypassing ufw লিঙ্কে এই মেকানিজমটি বিস্তারিত আলোচনা করা হয়েছে।

এর পরিবর্তে আপনার ল্যাপটপ থেকে SSH-এর মাধ্যমে পোর্টটি ফরওয়ার্ড করুন:

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

এটি চালু রাখুন এবং লোকালি http://localhost:5476/?token=<the token> ওপেন করুন। প্রতিটি কানেকশনে স্বয়ংক্রিয়ভাবে ফরওয়ার্ড করার জন্য এটি ~/.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=...-এ ব্রাউজ করুন।

টানেলের মাধ্যমে ব্যবহারের ক্ষেত্রে একটি নথিভুক্ত আচরণ লক্ষ্য করবেন: গেটওয়ে ফরওয়ার্ড করা অনুরোধগুলোকে রিমোট হিসেবে গণ্য করে, তাই ড্যাশবোর্ডের config-write এবং secret-reveal এন্ডপয়েন্টগুলো সেগুলোকে প্রত্যাখ্যান করে। SSH-এর মাধ্যমে সেটিংস পরিবর্তন সেভ না হওয়াটা কোনো বাগ নয়, বরং এটিই স্বাভাবিক। এর পরিবর্তে হোস্টে কনফিগারেশন এডিট করুন:

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 ব্যবহারের পরামর্শ দেয়, যা ড্যাশবোর্ডটিকে পাবলিক হোস্টনামের পরিবর্তে আপনার নিজস্ব tailnet-এর ভেতরে রাখে। পাবলিক রিভার্স প্রক্সির চেয়ে এটি বেশি নিরাপদ। টোকেনটি URL-এর মাধ্যমে পরিবাহিত হয় এবং প্রতিটি অ্যাক্সেস লগে URL-টি লেখা থাকে।

এজেন্টকে সর্বনিম্ন ব্লাস্ট রেডিয়াস প্রদান করুন

কন্টেইনারটি প্রথমবার চালু হওয়ার সময় স্যান্ডবক্স সাপোর্ট আছে কি না তা পরীক্ষা করে এবং এই ফলাফলের ওপর ভিত্তি করেই নির্ধারিত হয় যে এজেন্ট কোনো কিছু এক্সিকিউট করতে পারবে কি না। যদি নেমস্পেস আইসোলেশন উপলব্ধ থাকে, তবে এজেন্টের সাবপ্রসেসগুলো আইসোলেটেড অবস্থায় চলে। যদি এটি উপলব্ধ না থাকে এবং KIROCREW_ALLOW_UNSANDBOXED=1 সেট করা না থাকে, তবে আনকনফাইন্ড অবস্থায় চালানোর পরিবর্তে এক্সিকিউশন প্রত্যাখ্যান করা হয়। তাই কোনো গেটওয়ে যদি দেখতে সুস্থ মনে হয় কিন্তু প্রতিটি টাস্ক আটকে থাকে, তবে সাধারণত এর কারণ এটিই। প্রথমবার রান করার পর এই সিদ্ধান্তটি docker logs kirocrew-এ সংরক্ষিত থাকে। প্রজেক্টটি একটি seccomp (secure computing mode) প্রোফাইলও প্রকাশ করে যা আপনি প্রয়োগ করতে পারেন:

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 সেট করেন, তবে কী পরিবর্তন হয়েছে সে সম্পর্কে পরিষ্কার ধারণা রাখুন: এখন এজেন্ট এবং আপনার সার্ভারের মধ্যে একমাত্র সীমানা হলো এই কন্টেইনার। প্রজেক্টের সতর্কবার্তাটি সম্পূর্ণভাবে পুনরায় উল্লেখ করা প্রয়োজন। হোস্টের এমন কোনো পাথ মাউন্ট করবেন না যা আপনি সরাসরি এজেন্টকে দিতে চাইতেন না। কার্যত, এর অর্থ হলো Docker সকেট, /-এর কোনো বাইন্ড মাউন্ট এবং অন্য কোনো সার্ভিসের ডেটা ধারণকারী কোনো ডিরেক্টরি মাউন্ট করা যাবে না।

বাকি অংশটি সেই ফ্রেমওয়ার্ক যা কমান্ড চালানোর অনুমতিপ্রাপ্ত প্রতিটি এজেন্টের ক্ষেত্রে প্রযোজ্য। এজেন্টের ক্রেডেনশিয়ালগুলোকে শুধুমাত্র প্রয়োজনীয় একটি রিপোজিটরি বা একটি বাকেটের মধ্যে সীমাবদ্ধ রাখুন, কখনোই অ্যাকাউন্ট-ব্যাপী অধিকারসম্পন্ন কোনো পার্সোনাল টোকেন ব্যবহার করবেন না। এটিকে এমন একজন ডেডিকেটেড ব্যবহারকারী হিসেবে চালান যার হোম ডিরেক্টরিতে অন্য কিছু নেই, আর এজন্যই VPS-এ least privilege ব্যবহারকারী বিষয়টি গুরুত্বপূর্ণ। যখন এজেন্ট কোড লেখে এবং তারপর সেই কোড রান করে, তখন তাকে এমন একটি মেশিন দিন যা নষ্ট হলেও আপনার সমস্যা নেই: কোডিং এজেন্টের জন্য একটি ডিসপোজেবল VM এই কম্পোজ ফাইলের যেকোনো ফ্ল্যাগের চেয়ে শক্তিশালী সীমানা তৈরি করে, কারণ আপনি এটি পরিষ্কার করার পরিবর্তে ডিলিট করে দিতে পারেন। একই যুক্তি VPS-এ নিরাপদে OpenClaw চালানো এবং VPS-এ Hermes এজেন্ট সেলফ-হোস্ট করা-এর ক্ষেত্রেও প্রযোজ্য। শিডিউল করা কাজগুলো আপনার ঘুমের সময়ও অর্থ খরচ করতে পারে, কারণ ইনফারেন্সের বিল আপনার Kiro প্ল্যানে যোগ হয়। তাই কোনো নাইটলি জব যোগ করার আগে VPS-এ AI এজেন্টের খরচ নিয়ন্ত্রণ-এ বর্ণিত সীমাগুলো সেট করে নিন।

প্রতিটি আপগ্রেডের আগে স্টেট ভলিউমের ব্যাকআপ নিন

প্রথমে প্রকৃত ভলিউমের নাম খুঁজে বের করুন। Compose প্রজেক্টের নামের সাথে ভলিউমের নাম যুক্ত করে, যা ডিফল্টভাবে ডিরেক্টরির নাম হয়। তাই /opt/kirocrew/compose.yaml ফাইলে kirocrew-home হিসেবে ঘোষিত ভলিউমটি kirocrew_kirocrew-home নামে তৈরি হয়:

docker volume ls

যেকোনো কিছু কপি করার আগে গেটওয়েটি বন্ধ করুন। memory.db এবং memory_index.db হলো SQLite ডেটাবেস। ডেটাবেস লেখার সময় কপি করলে অসম্পূর্ণ ট্রানজ্যাকশন কপি হতে পারে, যা রিস্টোর করার সময় ফাইলটিকে নষ্ট করে দিতে পারে। প্রজেক্টের নিজস্ব মাইগ্রেশন নির্দেশনায়ও একই কথা বলা হয়েছে: গেটওয়ে বন্ধ থাকা অবস্থায় শুধুমাত্র মেমোরি স্থানান্তর করুন।

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

আর্কাইভটি সার্ভার থেকে কপি করে সরিয়ে নিন। রিস্টোর করার প্রক্রিয়াটি একই, তবে কন্টেইনার বন্ধ রেখে 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

নতুন হোস্টে স্থানান্তর করা এবং একই জায়গায় রিস্টোর করা ভিন্ন বিষয়, এবং প্রজেক্টের নথিতে এ বিষয়ে সুনির্দিষ্ট নির্দেশনা রয়েছে। workspace/memory/-এর অধীনে থাকা চ্যাট হিস্ট্রি এবং প্রজেক্ট নোটগুলো স্থানান্তর করা যায়, সেই সাথে দুটি ডেটাবেস ফাইল এবং config.json-ও স্থানান্তর করা সম্ভব। PID ফাইল, সিকিউরিটি ইভেন্ট লগ এবং .env পুরনো হোস্টের সাথে সম্পর্কিত, তাই এগুলো বাদ দিন এবং নতুন সার্ভারে সিক্রেটগুলো পুনরায় ইনপুট দিন।

একটি ত্রুটিপূর্ণ আপগ্রেড কীভাবে রোল ব্যাক করবেন

আপগ্রেড প্রক্রিয়াটি সংক্ষিপ্ত এবং এটি কেবল তখনই নিরাপদ যখন আপনি একটি নির্দিষ্ট ভার্সন পিন করে রাখেন। প্রথমে ব্যাকআপ নিন, তারপর ট্যাগ পরিবর্তন করুন:

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 ইমেজটি যদি বক্সে আগে থেকে না থাকে তবে তা পুল করে, তাই ট্যাগ এডিট করাই হলো সম্পূর্ণ আপগ্রেড। রোল ব্যাক করার প্রক্রিয়াটি পুরনো ভার্সন নম্বর দিয়ে একই রকম, এবং এটি আপনাকে ঠিক আগের ইমেজটিই ফিরিয়ে দেয়, কারণ ভার্সন ট্যাগগুলো অপরিবর্তনীয় (immutable)।

বাইনারিটি সঠিকভাবে রোল ব্যাক হয়। কিন্তু স্টেট (state) অংশটি হয়তো নাও হতে পারে। একটি নতুন গেটওয়ে config.json ফাইলটি নতুনভাবে লিখতে পারে অথবা মেমোরি ডাটাবেসগুলোকে এমন ফরম্যাটে মাইগ্রেট করতে পারে যা পুরনো গেটওয়ে পড়তে পারে না, এবং আগস্ট 2026 পর্যন্ত কোনো ডাউনগ্রেড পাথ নথিবদ্ধ করা হয়নি। তাই যদি পুরনো ইমেজটি চালু হওয়ার পর অস্বাভাবিক আচরণ করে, তবে তা ডিবাগ করার চেষ্টা করবেন না। এটি বন্ধ করুন, আপগ্রেডের আগে নেওয়া ব্যাকআপটি রিস্টোর করুন এবং পুনরায় শুরু করুন। ব্যাকআপ আগে নেওয়ার মূল কারণ এটিই, এবং এই কারণেই আগে আপগ্রেড করে পরে ব্যাকআপ নেওয়ার অভ্যাসটি এই ধরনের নতুন প্রজেক্টের ক্ষেত্রে ব্যর্থ হয়।

এখানে যা প্রমাণিত নয়

এই সফটওয়্যারের বয়স সম্পর্কে সৎ থাকা প্রয়োজন। এই গাইডটি লেখার সময় 0.1.3 ভার্সনটি মাত্র কয়েক দিন আগে রিলিজ হয়েছে। এর রিলিজ নোটগুলো মূলত স্বয়ংক্রিয়ভাবে তৈরি করা চেঞ্জলগ, কোনো মাইগ্রেশন নোট নয় এবং এর আপগ্রেড করার কোনো পূর্ব অভিজ্ঞতা বা রেকর্ড এখনো নেই। এই গাইডের কোনো কিছুই দীর্ঘমেয়াদী ফলাফলের ভিত্তিতে তৈরি নয়। তাই মেমোরি বৃদ্ধি, ডাটাবেজের আকার এবং শিডিউলারের নির্ভরযোগ্যতাকে ধরে নেওয়া কোনো বিষয় হিসেবে না দেখে, আপনার নিজের সার্ভারে এগুলো পরীক্ষা করে দেখুন।

দুটি আচরণ কোনো কিছুর ওপর নির্ভর করার আগে নিজে পরীক্ষা করে দেখা উচিত। প্রথমত, নতুন ভার্সনে লেখা ডাটা পুরনো ভার্সনে ডাউনগ্রেড করলে পড়া যায় কি না; এটি কোনো জরুরি অবস্থার সময় না করে ভলিউমের একটি কপিতে পরীক্ষা করুন। দ্বিতীয়ত, শিডিউল করা কোনো কাজ চলার সময় যদি Kiro সাইন-ইন এক্সপায়ার হয়ে যায়, তবে গেটওয়ে কী আচরণ করে। এই দুটি বিষয়ই নতুন প্রজেক্টের অমসৃণ দিক, যা সাধারণত পরবর্তী রিলিজগুলোতে ঠিক করা হয়। এগুলো এখনই যাচাই করে নেওয়া সাশ্রয়ী।

FAQ

আমার সার্ভারের পাবলিক IP-তে KiroCrew ড্যাশবোর্ড কেন খোলে না?

কারণ প্রকাশিত উদাহরণে পোর্টটিকে লুপব্যাক (loopback) ইন্টারফেসের সাথে বাইন্ড করা হয়েছে। -p 127.0.0.1:5476:5476 শুধুমাত্র হোস্টের লুপব্যাক ঠিকানায় কন্টেইনারের পোর্ট ম্যাপ করে, যা ইচ্ছাকৃতভাবেই করা হয়েছে। এটি অ্যাক্সেস করতে ssh -N -L 5476:127.0.0.1:5476 you@your-server ব্যবহার করে SSH-এর মাধ্যমে পোর্ট ফরওয়ার্ড করুন এবং তারপর আপনার ল্যাপটপে http://localhost:5476/?token=<token> খুলুন। এটিকে পাবলিক ইন্টারনেটে উন্মুক্ত করার জন্য 127.0.0.1: প্রিফিক্সটি সরিয়ে ফেললে গেটওয়েটি সরাসরি ইন্টারনেটে চলে আসবে। এক্ষেত্রে কোনো ফায়ারওয়াল রুল এটিকে আটকাতে পারবে না, কারণ Docker-এর প্রকাশিত পোর্টের DNAT রুলগুলো ufw ট্রাফিক ফিল্টার করার আগেই কার্যকর হয়।

KiroCrew তার ডেটা কোথায় জমা রাখে এবং আমার কী ব্যাকআপ নেওয়া উচিত?

সবকিছু ~/.kiro/crew ডিরেক্টরির অধীনে থাকে, যা কন্টেইনার ইমেজের ভেতরে /home/kirocrew/.kiro/crew হিসেবে থাকে এবং KIROCREW_HOME ব্যবহার করে এটিকে স্থানান্তর করা যায়। গেটওয়ে বন্ধ থাকা অবস্থায় পুরো ডিরেক্টরি অথবা পুরো Docker ভলিউমের ব্যাকআপ নিন। memory.db এবং memory_index.db হলো SQLite ডেটাবেস, তাই গেটওয়ে যখন ডেটা লিখছে তখন কপি নিলে তা অসামঞ্জস্যপূর্ণ হতে পারে। নতুন হোস্টে স্থানান্তরের সময় workspace/memory/, দুটি ডেটাবেস ফাইল এবং config.json স্থানান্তর করুন। অন্যদিকে PID ফাইল, সিকিউরিটি ইভেন্ট লগ এবং .env পুরনো হোস্টে রেখে দেওয়া উচিত।

আমার কি stable ট্যাগ ব্যবহার করা উচিত নাকি ভার্সন ট্যাগ?

ভার্সন ট্যাগ ব্যবহার করুন। stable প্রতিবার নতুন রিলিজ আসার সাথে সাথে পরিবর্তিত হয়, তাই পরবর্তী pull-এর সময় আপনার চলমান ভার্সনটি বদলে যেতে পারে এবং এই ট্যাগটি দেখে বোঝা সম্ভব নয় যে বর্তমানে কী চলছে। 0.1.3-এর মতো ভার্সন ট্যাগগুলো অপরিবর্তনীয় (immutable), আর ঠিক এই কারণেই রোলব্যাক করা সম্ভব: আপনি পুরনো ভার্সন নম্বরটি পুনরায় সেট করলেই হুবহু একই ইমেজ ফিরে পাবেন। 6 আগস্ট 2026 অনুযায়ী সর্বশেষ রিলিজ হলো 0.1.3।

আমার এজেন্ট কোনো কমান্ড চালাতে অস্বীকার করছে কেন?

কন্টেইনারটি প্রথমবার চালু হওয়ার সময় স্যান্ডবক্স সাপোর্ট আছে কি না তা পরীক্ষা করে। যদি এটি এজেন্টের সাব-প্রসেসগুলোকে আইসোলেট করতে না পারে এবং KIROCREW_ALLOW_UNSANDBOXED=1 সেট করা না থাকে, তবে এটি কোনো সুরক্ষা ছাড়াই কমান্ড চালানোর পরিবর্তে তা প্রত্যাখ্যান করে। ফলে গেটওয়েকে সচল মনে হলেও প্রতিটি টাস্ক আটকে থাকে। docker logs kirocrew কমান্ডটি চালালে প্রথমবার রান করার সময় নেওয়া স্যান্ডবক্সের সিদ্ধান্তটি দেখা যাবে। এই ভেরিয়েবলটি সেট করলে কন্টেইনারটিই এজেন্ট এবং হোস্টের মধ্যে একমাত্র সীমানা হিসেবে কাজ করে। তাই এটি সেট করলে এমন কোনো কিছু মাউন্ট করবেন না যা আপনি সরাসরি এজেন্টকে দিতে চান না।

KiroCrew সেলফ-হোস্ট করার জন্য কি আমার Kiro অ্যাকাউন্ট প্রয়োজন?

হ্যাঁ, আগস্ট 2026 অনুযায়ী এটি প্রয়োজন। KiroCrew হলো Apache 2.0 লাইসেন্সের অধীনে একটি ফ্রি সফটওয়্যার, কিন্তু এটি kiro-cli-এর মাধ্যমে পরিচালিত হয়, যার জন্য একবার সাইন-ইন করা প্রয়োজন এবং এজেন্টের ইনফারেন্সের খরচ Kiro প্ল্যানের মাধ্যমে বিল করা হয়। কন্টেইনারের ভেতরে docker exec -it kirocrew kiro-cli login কমান্ডটি চালান এবং আপনার ব্রাউজারে ডিভাইস কোডটি অনুমোদন করুন। এই সাইন-ইন প্রক্রিয়া সম্পন্ন না হওয়া পর্যন্ত গেটওয়ে চালু হবে এবং ড্যাশবোর্ড লোড হবে, কিন্তু এজেন্টের কথা বলার জন্য কোনো মডেল থাকবে না।