VPS-এ KiroCrew হোস্ট করার নিয়ম ও গাইড

ল্যাপটপের পরিবর্তে 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 সালের আগস্ট পর্যন্ত এটি কোনো অফলাইন সেটআপ নয়। প্রজেক্টটিও মাত্র কয়েক সপ্তাহ পুরনো। ধরে নিন যে কোনো এক পর্যায়ে আপনাকে রোলব্যাক করতে হবে, তাই এমনভাবে ইনস্টল করুন যেন তা সম্ভব হয়। আপনি যদি আগে কখনো সার্ভারে এজেন্ট না চালিয়ে থাকেন, তবে running a coding agent on a VPS-এ সেই মৌলিক নিয়মগুলো আলোচনা করা হয়েছে যার ওপর ভিত্তি করে এই নির্দেশিকাটি তৈরি। যদি সার্ভার সাইডের চেয়ে এজেন্ট সাইড আপনার কাছে নতুন হয়, তবে learning what an agent loop, its tools and its memory actually are আগে পড়ে নিলে নিচের সিদ্ধান্তগুলো আপনার কাছে স্পষ্ট হবে।

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 কমান্ড চালিয়ে এর আকার পরিমাপ করুন। এর বিপরীতে এমন একটি রানটাইম যেখানে প্রতিটি কর্মীর জন্য আলাদা কন্টেইনার এবং ব্রাউজার থাকে, সেখানে OpenBot-এর AI সহকর্মীদের সেলফ-হোস্টিং করার ক্ষেত্রে সাইজিং বা আকার নির্ধারণের বিষয়টি ডিস্কের আগে RAM-এর ওপর নির্ভর করে।

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

প্রকল্পটি তিনটি পদ্ধতি প্রকাশ করে। এক-লাইনের ইনস্টলারটি একটি 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 স্ট্যাক চালু করা-তে সাধারণ নিয়মটি আলোচনা করা হয়েছে। /etc/systemd/system/kirocrew.service-এ KiroCrew-এর পদ্ধতিটি দেওয়া হলো:

[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 সার্ভিস এবং টাইমার-এ রয়েছে। কোনো ইউনিট পুনরায় চালু হতে ব্যর্থ হলে তা নীরব থাকে যদি না আপনি সেটিকে সক্রিয় করেন, তাই একটি OnFailure= হ্যান্ডলার যোগ করুন যা আপনার নিজস্ব ntfy সার্ভারে অ্যালার্ট পাঠাবে। এতে কোনো শিডিউলড জব কাজ না করার পরিবর্তে গেটওয়ে ডাউন হওয়ার খবর আপনি সরাসরি আপনার ফোনে পাবেন।

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

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

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। কন্টেইনারের ভেতরে gateway 0.0.0.0-এ লিসেন করে, কারণ এটিকে port mapping-এর মাধ্যমে অ্যাক্সেসযোগ্য হতে হয়, কিন্তু এই ম্যাপিংটি হোস্টের শুধুমাত্র loopback-এ প্রকাশিত হয়। 127.0.0.1: প্রিফিক্সটি মুছে ফেললে gateway-টি পাবলিক ইন্টারনেটে উন্মুক্ত হয়ে যাবে এবং যে কেউ পোর্টটি স্ক্যান করতে পারবে। ফায়ারওয়াল রুলও আপনাকে রক্ষা করবে না: 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=...-এ ব্রাউজ করুন। দ্বিতীয় কোনো এজেন্ট সার্ভারটি শেয়ার করার সাথে সাথেই আপনাকে এভাবে ফরওয়ার্ডিং স্ট্যাক করতে হবে, কারণ self-hosting open-kritt for security scanning একই সার্ভারে port 5173-এ আরেকটি শুধুমাত্র loopback-এ সীমাবদ্ধ ড্যাশবোর্ড তৈরি করে।

টানেলের মাধ্যমে ব্যবহারের সময় একটি প্রত্যাশিত আচরণ হলো: gateway ফরওয়ার্ড করা অনুরোধগুলোকে রিমোট হিসেবে গণ্য করে, তাই ড্যাশবোর্ডের 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 ব্যবহারের পরামর্শ দেয়। এতে dashboard একটি public hostname-এ না থেকে আপনার নিজস্ব tailnet-এর ভেতরে থাকে। public reverse proxy-এর বদলে এটিই ব্যবহার করুন। Token URL-এর মধ্যে থাকে, এবং সেই URL যে পথ অতিক্রম করে তার প্রতিটি access log-এ লেখা হয়। এই নিয়মটি port নিজে সম্পর্কে নয়; port-এর পেছনে কী চলছে, তা সম্পর্কে। যেমন Halcyon, যা Jellyfin library-কে browsable 90s video store হিসেবে পুনর্গঠন করে অন্যরা খোলার জন্য তৈরি এবং reverse proxy-এর জন্য উপযুক্ত প্রার্থী। কিন্তু আপনার server-এ command চালাতে পারে এমন gateway reverse proxy-এর জন্য উপযুক্ত নয়।

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

কন্টেইনারটি প্রথমবার চালু হওয়ার সময় স্যান্ডবক্স সাপোর্ট আছে কি না তা পরীক্ষা করে এবং এই ফলাফলের ওপর ভিত্তি করেই নির্ধারিত হয় যে এজেন্ট কোনো কিছু এক্সিকিউট করতে পারবে কি না। যদি নেমস্পেস আইসোলেশন উপলব্ধ থাকে, তবে এজেন্টের সাব-প্রসেসগুলো আইসোলেটেড অবস্থায় চলে। যদি এটি উপলব্ধ না থাকে এবং KIROCREW_ALLOW_UNSANDBOXED=1 সেট করা না থাকে, তবে আনকনফাইন্ড (unconfined) অবস্থায় চালানোর পরিবর্তে এক্সিকিউশন প্রত্যাখ্যান করা হয়। তাই গেটওয়ে যদি সুস্থ দেখায় কিন্তু প্রতিটি টাস্ক আটকে থাকে, তবে সাধারণত এর কারণ এটিই। প্রথমবার চালানোর পর এই সিদ্ধান্তটি 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 এজেন্ট সেলফ-হোস্ট করা-এর ক্ষেত্রেও প্রযোজ্য। টুলগুলোও ব্লাস্ট রেডিয়াসের অংশ: এজেন্টকে ওয়েব সার্চের ক্ষমতা দিলে প্রতিটি পেজ যা সে ফেচ করে তা আনট্রাস্টেড ইনপুট হিসেবে গণ্য হয়, তাই সেটিকে আপনার নিজস্ব SearXNG ইনস্ট্যান্সের দিকে নির্দেশ করা একটি প্লাম্বিং সিদ্ধান্তের পাশাপাশি প্রম্পট ইনজেকশন প্রতিরোধের সিদ্ধান্তও বটে। নির্ধারিত কাজগুলো আপনার ঘুমের সময়ও খরচ বাড়াতে পারে, কারণ ইনফারেন্সের বিল আপনার Kiro প্ল্যানে যোগ হয়, তাই রাতের বেলা কোনো জব যোগ করার আগে VPS-এ AI এজেন্টের খরচ নিয়ন্ত্রণ-এ বর্ণিত সীমাগুলো সেট করে নিন।

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

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

docker volume ls

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

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 পুরনো হোস্টের সাথে সম্পর্কিত, তাই এগুলো বাদ দিন এবং নতুন বক্সে সিক্রেটগুলো পুনরায় ইনপুট দিন।

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

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

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 ইমেজটি যদি বক্সে আগে থেকে না থাকে তবে সেটি পুল (pull) করে নেয়, তাই ট্যাগ এডিট করাই হলো সম্পূর্ণ আপগ্রেড প্রক্রিয়া। রোল ব্যাক করার ক্ষেত্রেও পুরনো নম্বর দিয়ে একই ধাপ অনুসরণ করতে হয়, এবং এটি আপনাকে ঠিক আগের ইমেজটিই ফিরিয়ে দেয়, কারণ ভার্সন ট্যাগগুলো অপরিবর্তনীয় (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 ডেটাবেস, তাই গেটওয়ে যখন ডেটা লিখছে তখন কপি নিলে তা অসামঞ্জস্যপূর্ণ (inconsistent) হতে পারে। নতুন হোস্টে স্থানান্তর করার সময় workspace/memory/, দুটি ডেটাবেস ফাইল এবং config.json স্থানান্তর করুন। PID ফাইল, সিকিউরিটি ইভেন্ট লগ এবং .env পুরনো হোস্টের অংশ, তাই এগুলো নতুন হোস্টে নেওয়ার প্রয়োজন নেই।

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

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

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

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

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

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