Rakazo সেলফ-হোস্টিং গাইড: VPS-এ নিজস্ব AI বট সেটআপ

Rakazo self-hosting-এ যা যা চলে

Rakazo self-hosting করার অর্থ হলো একটি Linux সার্ভারে পাঁচটি জিনিস চালানো: PostgreSQL, একটি Graphile Worker প্রসেস, API, ওয়েব অ্যাপ এবং একটি স্যান্ডবক্স কন্টেইনার যা বটগুলোর কম্পিউটার হিসেবে কাজ করে। Rakazo হলো Grok Bot-এর একটি ওপেন-সোর্স বিকল্প, যা elie222 কর্তৃক Apache 2.0 লাইসেন্সের অধীনে প্রকাশিত হয়েছে। প্রতিটি বট তার নিজস্ব কথোপকথন, মেমোরি, রুটিন এবং হিস্ট্রি পায়; ওয়ার্কস্পেসের অন্যান্য বটের সাথে একটি Team Computer শেয়ার করে (যদি না তাকে Private Computer দেওয়া হয়), এবং নতুন পিয়ার বা স্বল্পস্থায়ী সাব-এজেন্ট তৈরি করতে পারে। যদি এই বাক্যে মেমোরি, সাব-এজেন্ট এবং টুল কল-এর মতো শব্দগুলো আপনার কাছে অপরিচিত মনে হয়, তবে এজেন্টরা কীভাবে কাজ করে তার একটি পর্যায়ক্রমিক গাইড পড়ে নেওয়া ভালো, কারণ নিচের বেশিরভাগ সেটিংস তখনই বোধগম্য হবে যখন আপনি বুঝতে পারবেন একটি বট জেগে ওঠার সময় কী করছে।

শেষের এই অংশটির কারণেই এটি কোনো ডেস্কটপের পরিবর্তে একটি VPS (virtual private server)-এ চালানো উচিত। যে বট মেমোরি ধরে রাখে এবং নির্ধারিত কাজ সম্পাদন করে, তাকে আপনার ঘুমের সময়ও সচল থাকতে হয়। ল্যাপটপ স্লিপ মোডে চলে গেলে এই কিউ (queue) ড্রপ হয়ে যায়।

Rakazo অক্টোবর 2026 পর্যন্ত নিজেকে বিটা হিসেবেই বর্ণনা করে, যদিও এখন তারা স্টেবল-নাম্বারযুক্ত রিলিজ প্রকাশ করে। তাই এটিকে একটি সমাপ্ত অ্যাপ্লায়েন্সের পরিবর্তে একটি চলমান সেটআপ হিসেবে বিবেচনা করুন। পুরো স্ট্যাকটি TypeScript-এ তৈরি: ওয়েব অ্যাপের জন্য React 19 এবং Vite, API-এর জন্য Hono, Prisma-সহ Postgres, অ্যাকাউন্টের জন্য Better Auth এবং ব্যাকগ্রাউন্ড জব-এর জন্য Graphile Worker। Graphile Worker তার কিউ Postgres-এর ভেতরেই জমা রাখে, তাই আলাদা করে Redis বা দ্বিতীয় কোনো ডেটা স্টোর চালানোর প্রয়োজন নেই। .env.example সেট করে WAKEUP_DRIVER=graphile, যার অর্থ হলো একটি বট জেগে ওঠা মানেই সেটি একটি Postgres-ব্যাকড জব। Postgres বন্ধ করলে নির্ধারিত সব বট অ্যাকশনও তার সাথে বন্ধ হয়ে যাবে। আপনি যদি অন্যের প্রোডাক্ট না চালিয়ে পার্টস দিয়ে নিজের মতো করে একটি এজেন্ট তৈরি করতে চান, তবে কম্পোনেন্ট ব্যবহার করে নিজের এজেন্ট তৈরি করা হলো অন্য একটি উপায়।

কেন 1 জিবি প্ল্যান এটি ধারণ করতে পারবে না

প্রসেসগুলোর সংখ্যা গণনা করুন। Postgres একটি। API হলো একটি Node প্রসেস। ওয়ার্কার হলো দ্বিতীয়টি। ওয়েব অ্যাপ হলো তৃতীয়টি। স্যান্ডবক্স সুপারভাইজার হলো চতুর্থটি। এরপর আসে বটদের কম্পিউটার: ডিফল্টভাবে একটি শেয়ারড Team Computer কন্টেইনার, যা একটি গ্রাফিক্যাল Linux ডেস্কটপ ধারণ করে এবং প্রতিটি সক্রিয় বটের জন্য আলাদা X ডিসপ্লে ও Chrome প্রসেস চালায়।

প্রজেক্টের সেলফ-হোস্ট নথিতে এখন আর হোস্টের আকার উল্লেখ করা থাকে না। এর আগস্ট 2026 বিটা সংস্করণে বলা হয়েছিল যে, যখন E2B বট ডেস্কটপগুলোর মালিকানা নেয়, তখন API, ওয়ার্কার এবং Postgres-এর জন্য 2 vCPU এবং 4 জিবি র‍্যামের মেশিন যথেষ্ট। v0.3.1-এ থাকা নথি, যা 21 অক্টোবর 2026 তারিখে যাচাই করা হয়েছে, সেখানে শুধুমাত্র সফটওয়্যার প্রয়োজনীয়তাগুলো তালিকাভুক্ত করা হয়েছে। এটি যা প্রদান করে তা হলো কম্পিউটার প্রতি একটি সর্বোচ্চ সীমা (ceiling): Docker স্যান্ডবক্সের ক্ষেত্রে, RAKAZO_COMPUTER_MEMORY ডিফল্টভাবে 2g এবং RAKAZO_COMPUTER_CPUS ডিফল্টভাবে 2 নির্ধারণ করে। এই সর্বোচ্চ সীমা প্রতিটি কম্পিউটারের জন্য প্রযোজ্য, প্রতিটি বটের জন্য নয়। প্রতিটি ওয়ার্কস্পেস ডিফল্টভাবে একটি Team Computer পায় এবং প্রতিটি সক্রিয় Team বট তার ডেস্কটপ ও ব্রাউজারকে এর ভেতরেই চালায়, তাই তারা সবাই মিলে সেই 2 জিবি র‍্যাম এবং দুটি কোর শেয়ার করে। শুধুমাত্র Private Computer-এ সরানো বটগুলোই আলাদা কন্টেইনার এবং নিজস্ব সর্বোচ্চ সীমা পায়। SANDBOX_PROVIDER=docker সেট করলে সেই ডেস্কটপগুলো আপনার VPS-এ, কন্ট্রোল প্লেনের উপরে চলে আসে, তাই 4 জিবি র‍্যাম এখানে লক্ষ্যমাত্রা নয়, বরং সর্বনিম্ন প্রয়োজনীয়তা। আপনি যদি একাধিক বট চালু রাখতে চান তবে 8 জিবি র‍্যাম দিয়ে শুরু করুন, RAKAZO_COMPUTER_MEMORY বাড়িয়ে দিন যাতে শেয়ারড কম্পিউটারটি প্রকৃতপক্ষে সেই মেমোরি ব্যবহার করতে পারে, এবং বটগুলো কাজ করার সময় docker stats দিয়ে প্রকৃত সংখ্যাটি পরিমাপ করুন। স্যান্ডবক্সের ভেতরের ব্রাউজারই মেমোরির ব্যবহার বাড়িয়ে দেয়, তাই স্পেক শিট দেখে আপনি তা বুঝতে পারবেন না। একটি ছোট বক্সে যাতে একসাথে খুব বেশি ব্রাউজার না চলে, তা নিশ্চিত করতে একটি পজিটিভ SANDBOX_TEAM_SCREEN_LIMIT সেট করুন, যা একটি Docker Team Computer-এ সক্রিয় ডেস্কটপের সংখ্যা সীমিত করে। শিপ করা 0-এ এটি আনক্যাপড বা অসীম রাখা থাকে। যদি সামগ্রিকভাবে মেমোরির সংকট থাকে, তবে RAKAZO_COMPUTER_MEMORY-এ 1536m-এর মতো ছোট মানও গ্রহণ করা হয়। এজেন্ট কাজের জন্য বক্সের আকার নির্ধারণের সাধারণ পদ্ধতির বিষয়ে, এজেন্ট VPS-এর জন্য কতটুকু র‍্যাম ও CPU প্রয়োজন নিবন্ধে পরিমাপের বিষয়টি বিস্তারিত আলোচনা করা হয়েছে।

একটি সেটিং পরিস্থিতি খারাপ হওয়া থেকে রক্ষা করে। .env.example-এ SANDBOX_IDLE_MS=600000 শিপ করা হয় এবং এর মন্তব্যে বলা হয়েছে যে, নির্দিষ্ট সংখ্যক মিলিসেকেন্ড অলস (idle) থাকার পর কম্পিউটারগুলো পজ বা বন্ধ হয়ে যায়। দশ মিনিট অলস থাকলে কম্পিউটারটি বন্ধ হয়ে যায়। সর্বনিম্ন গ্রহণযোগ্য মান হলো 30000 এবং 0 দিলে আইডল স্লিপ নিষ্ক্রিয় হয়ে যায়। একই মন্তব্যে Docker সেলফ-হোস্টের জন্য 0 ব্যবহারের পরামর্শ দেওয়া হয়েছে, যেখানে একটি অলস কম্পিউটার কোনো খরচ বাড়ায় না, তাই দীর্ঘস্থায়ী অ্যাপ এবং সেশনগুলো চালু থাকে। এটি অর্থের ক্ষেত্রে প্রযোজ্য, মেমোরির ক্ষেত্রে নয়। একটি ছোট VPS-এ টাইমারটি চালু রাখুন, কারণ এটি ছাড়া আপনার শুরু করা প্রতিটি কম্পিউটার এবং তার ভেতরের প্রতিটি ব্রাউজার চলতেই থাকবে।

ডিস্কের ধারণক্ষমতাও গুরুত্বপূর্ণ। স্যান্ডবক্স ইমেজ, Node মডিউল এবং Postgres ভলিউম একটি ডিস্ক শেয়ার করে, তাই 40 জিবি একটি যুক্তিসঙ্গত প্রারম্ভিক পয়েন্ট।

ক্লোন করার আগে একটি ভার্সন পিন করুন

Rakazo দ্রুত পরিবর্তিত হয় এবং main কোনো রিলিজ নয়। 21 অক্টোবর 2026 পর্যন্ত এই রিপোজিটরিতে 12টি ট্যাগ রয়েছে। 13 আগস্ট 2026-এ প্রকাশিত v0.1.0-beta এখনো একটি প্রি-রিলিজ হিসেবে চিহ্নিত, এবং এর পরে দশটি স্টেবল ভার্সন ট্যাগ এসেছে: 3 থেকে 8 সেপ্টেম্বর 2026-এর মধ্যে v0.1.0 থেকে v0.1.6, 10 অক্টোবর 2026-এ v0.2.0, এবং 19 অক্টোবর 2026-এ v0.3.0 ও v0.3.1। v0.3.0 শুধুমাত্র একটি ট্যাগ হিসেবে বিদ্যমান, v0.3.1 হলো Latest হিসেবে চিহ্নিত রিলিজ, এবং দ্বাদশ ট্যাগটি, android, সার্ভারের পরিবর্তে Android অ্যাপের সাথে সম্পর্কিত।

git clone https://github.com/elie222/rakazo.git
cd rakazo
git checkout 926710a09b30a6c1f83029da88dfe06656b031f2
git log -1 --format='%H %ci'

সেই কমিটটিই হলো সেটি যার দিকে v0.3.1 নির্দেশ করে। ব্রাঞ্চ বা ট্যাগের পরিবর্তে কমিটটি পিন করুন। পরবর্তী git pull-এর সময় ব্রাঞ্চ আপনার অজান্তেই পরিবর্তিত হতে পারে এবং ট্যাগ হলো একটি পরিবর্তনযোগ্য লেবেল যা মেইনটেইনার যেকোনো সময় সরিয়ে নিতে পারেন, তাই এগুলোর কোনোটিই এমন কোনো ট্রি শনাক্ত করে না যেখানে আপনি ফিরে আসতে পারবেন। একটি কমিট আইডেন্টিফায়ার কখনো পরিবর্তিত হয় না। আপনার অন্যান্য সার্ভার তথ্যের পাশাপাশি এটি লিখে রাখুন, কারণ আপগ্রেডের ফলে কোনো সমস্যা হলে দ্রুত সমাধানের উপায় হলো git checkout <old commit> এবং রিবিল্ড করা, আর এটি তখনই কাজ করে যদি আপনি জানেন কোন কমিটটি সঠিকভাবে কাজ করছিল। Rakazo এখনো নিজেকে বেটা হিসেবে দাবি করে, তাই এই সূক্ষ্ম পিনিংয়ের জন্য সামান্য প্রচেষ্টা করা সার্থক। দীর্ঘ সময় ধরে সুপরিকল্পিত রিলিজ প্রদানকারী কোনো প্রজেক্টের ক্ষেত্রে প্রকাশিত ট্যাগ ব্যবহার করা যেতে পারে, যা openGym-এর মতো ছোট কোনো self-hosted stack অনুসরণ করে।

প্রয়োজনীয়তা: Node 22, pnpm 9 এবং Docker

node -v
pnpm -v
docker --version

package.json ঘোষণা করে "engines": { "node": "^22.22.2 || ^24.0.0 || >=26.0.0" } এবং "packageManager": "pnpm@9.15.0"। তাই node -v-কে অবশ্যই v22.22.2 বা তার পরবর্তী 22.x সংস্করণ, যেকোনো v24, অথবা v26 বা তার উপরের সংস্করণ দেখাতে হবে। 22.22.2-এর চেয়ে পুরনো যেকোনো v22 এই সীমার বাইরে, এবং README-তে স্পষ্টভাবে বলা হয়েছে যে Node.js 23.x এবং 25.x সমর্থিত নয়। Ubuntu আর্কাইভের Node প্যাকেজ সাধারণত এর চেয়ে পুরনো হয়, তাই NodeSource বা nvm থেকে ইনস্টল করুন। pnpm, corepack-এর মাধ্যমে Node-এর সাথেই আসে:

corepack enable
corepack prepare pnpm@9.15.0 --activate

Docker Engine এবং compose প্লাগইন বাকি প্রয়োজনীয়তা পূরণ করে। self-host ডকুমেন্টেশনে bot home ভলিউম সাবপাথের জন্য Docker Engine 26 বা তার নতুন সংস্করণ এবং API 1.45 বা তার নতুন সংস্করণ ব্যবহারের কথা বলা হয়েছে, সেই সাথে curl এবং OpenSSL প্রয়োজন। আপনার ব্যবহারকারীরও daemon-এর সাথে সংযোগ স্থাপনের সক্ষমতা থাকতে হবে। যদি docker ps কমান্ডটি permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock উত্তর দেয়, তবে আপনার ব্যবহারকারীকে docker গ্রুপে যুক্ত করুন এবং একটি নতুন লগইন শেল খুলুন। এটি কী সুবিধা দেয় তা আগে জেনে নিন: docker গ্রুপের সদস্যপদ মেশিনে root-এর সমতুল্য, কারণ এই গ্রুপের যেকোনো সদস্য এমন একটি কন্টেইনার চালু করতে পারে যা হোস্ট ফাইলসিস্টেমকে মাউন্ট করে।

.env কনফিগার করুন, তারপর Postgres চালু করুন

cp .env.example .env
chmod 600 .env

কোনো কিছু শুরু করার আগে বেশ কিছু মান পরিবর্তন করতে হবে। .env.example-এর সাথে BETTER_AUTH_SECRET=replace-with-32-plus-character-secret, ENCRYPTION_KEY=replace-with-64-random-hex-characters, SCREEN_PROXY_SECRET=replace-with-32-plus-character-screen-proxy-secret এবং SANDBOX_SUPERVISOR_TOKEN=replace-with-32-plus-character-supervisor-token আসে এবং এটি POSTGRES_PASSWORD-কে খালি রাখে। এই প্রতিটি প্লেসহোল্ডার রিপোজিটরিতে প্রকাশিত থাকে, তাই কোনো একটি রেখে দিলে তা এমন একটি সিক্রেট ব্যবহার করে যা যে কেউ পড়তে পারে। প্রতিটির জন্য আলাদা র‍্যান্ডম মান দিন। ENCRYPTION_KEY অবশ্যই 64টি র‍্যান্ডম হেক্স ক্যারেক্টারের হতে হবে, যা openssl rand -hex 32 কমান্ডটি প্রিন্ট করে। অন্যান্য সিক্রেটের জন্য 32 বা তার বেশি ক্যারেক্টার প্রয়োজন, তাই প্রতিটি সিক্রেটের জন্য base64 লাইনটি একবার করে চালান। POSTGRES_PASSWORD-এর জন্য সেলফ-হোস্ট ডকুমেন্টেশন একটি URL-সেফ মান চায়, যা শেষ লাইনটি প্রদান করে এবং v0.3.1-এ একই পাসওয়ার্ড DATABASE_URL-এ দিতে হয়, যা postgres://rakazo:REPLACE_WITH_POSTGRES_PASSWORD@127.0.0.1:5433/rakazo হিসেবে আসে। v0.3.1-এর পরে main-এ করা কমিটগুলো এটিকে দুই ভাগে ভাগ করেছে: ওনার স্ট্রিংটি DATABASE_MIGRATION_URL-এ চলে গেছে এবং DATABASE_URL এখন postgres://rakazo_app:REPLACE_WITH_POSTGRES_APP_PASSWORD@127.0.0.1:5433/rakazo হয়েছে, যা সুপারইউজার অধিকার ছাড়া একটি আলাদা লগইন, রো-লেভেল সিকিউরিটির অধীনে এবং এর নিজস্ব POSTGRES_APP_PASSWORD রয়েছে। আপনার পিন v0.3.1 অতিক্রম করলে এই দ্বিতীয় পাসওয়ার্ডটি সেট করার আশা রাখুন।

openssl rand -base64 48
openssl rand -hex 32
openssl rand -hex 24

এরপর ডাটাবেসটি আলাদাভাবে চালু করুন এবং মাইগ্রেশনগুলো রান করুন।

docker compose --env-file .env -f infra/compose/docker-compose.yml -f infra/compose/docker-compose.postgres-host.yml up postgres -d
pnpm install
pnpm db:generate
pnpm db:migrate
pnpm sandbox:build

pnpm sandbox:build বট কম্পিউটার ইমেজটি তৈরি করে, যা package.json-এ docker build -t rakazo/computer:local infra/sandboxes/computer হিসেবে সংজ্ঞায়িত। এটি একটি গ্রাফিক্যাল ইমেজ, তাই প্রথমবার বিল্ড করার সময় অনেক কিছু ডাউনলোড হয় এবং সময় লাগে। docker image ls rakazo/computer দিয়ে এটি নিশ্চিত করুন, যা একটি সারি প্রিন্ট করবে।

বেস compose ফাইলটি কোনো Postgres পোর্ট পাবলিশ করে না। ওই কমান্ডের docker-compose.postgres-host.yml ওভারলে এটিকে 127.0.0.1:5433 হিসেবে পাবলিশ করে, যা শুধুমাত্র লুপব্যাক (loopback), তাই pnpm db:migrate এবং pnpm dev-এর মতো হোস্ট-সাইড টুলগুলো এতে পৌঁছাতে পারে। এটিকে এভাবেই রাখুন। .env-এ POSTGRES_PASSWORD ছাড়া Compose Postgres চালু করতে অস্বীকার করে, কিন্তু ইন্টারনেট থেকে অ্যাক্সেসযোগ্য Postgres পোর্ট পাসওয়ার্ড যাই হোক না কেন, কয়েক ঘণ্টার মধ্যেই স্ক্যানারদের নজরে পড়ে যায়। প্রোডাকশন compose ফাইলটি একই ভেরিয়েবল পড়ে এবং কোনো ডাটাবেস পোর্ট পাবলিশ করে না।

প্রথমবার চালানো

pnpm dev

এটি চারটি বিষয় চালু করে: 3100 পোর্টে API, Graphile Worker, 5173 পোর্টে Vite ওয়েব অ্যাপ এবং 7091 পোর্টে sandbox supervisor। অ্যাপটি http://127.0.0.1:5173-এ রয়েছে এবং আপনি সেখানে একটি সাইন-ইন পেজ দেখতে পাবেন।

একটি VPS-এ আপনি সরাসরি সেই মেশিনের সামনে বসে নেই, তাই এটি অ্যাক্সেস করার জন্য 5173 পোর্টটি পাবলিশ করা উচিত নয়। এর পরিবর্তে আপনার নিজের মেশিন থেকে SSH (secure shell) ব্যবহার করে পোর্টগুলো ফরওয়ার্ড করুন।

ssh -L 5173:127.0.0.1:5173 -L 3100:127.0.0.1:3100 you@your-server

এটি চালানোর বিভিন্ন পদ্ধতির পার্থক্যের বিষয়ে সতর্ক থাকুন। pnpm dev কমান্ডটি Vite-কে হোস্ট মেশিনে লোকালি বাইন্ড করে চালায়। ডেভেলপমেন্ট compose ফাইলে থাকা web সার্ভিসটি 127.0.0.1:5173:5173 এবং এর api সার্ভিসটি 127.0.0.1:3100:3100 পোর্ট পাবলিশ করে, যার উভয়ই শুধুমাত্র লুপব্যাক ইন্টারফেসে সীমাবদ্ধ, তাই একই টানেল উভয়টির জন্যই কাজ করে। প্রোডাকশন ফাইলে ওয়েব অ্যাপটি শুধুমাত্র ইন্টারনাল নেটওয়ার্কে উন্মুক্ত থাকে এবং শুধুমাত্র Caddy পোর্ট 80 ও 443 পাবলিশ করে। তাই দীর্ঘমেয়াদে কোনো কিছু চালানোর জন্য প্রোডাকশন ফাইল এবং এর রিভার্স প্রক্সি ব্যবহার করুন।

সার্ভারে কোন স্যান্ডবক্স প্রোভাইডার নিরাপদ?

এই সেটিংসটি সঠিকভাবে কনফিগার করা অত্যন্ত গুরুত্বপূর্ণ। SANDBOX_PROVIDER-এ .env ডিফল্টভাবে docker থাকে এবং সেলফ-হোস্ট ডকুমেন্টেশনে আটটি ভ্যালুর তালিকা দেওয়া আছে।

• docker হলো ডিফল্ট অপশন। বট কম্পিউটারগুলো আপনার মেশিনে কন্টেইনার হিসেবে চলে, যা pnpm sandbox:build ইমেজ থেকে তৈরি হয় এবং একটি সুপারভাইজারের অধীনে পরিচালিত হয়। ডিফল্টভাবে একটি ওয়ার্কস্পেসের সব বট একটি Team Computer শেয়ার করে এবং শুধুমাত্র Private Computer-এর ক্ষেত্রেই প্রতিটি বট আলাদা কন্টেইনার পায়। এর জন্য কোনো E2B অ্যাকাউন্টের প্রয়োজন নেই।
• e2b বট কম্পিউটারগুলোকে E2B-তে চালায় এবং এর জন্য E2B_API_KEY প্রয়োজন। সেলফ-হোস্ট ডকুমেন্টেশন অনুযায়ী এটি পাবলিক বা মাল্টি-ইউজার প্রোডাকশনের জন্য উপযুক্ত, কারণ এটি বট কম্পিউটারগুলোকে আপনার API এবং ডেটাবেস হোস্ট থেকে আলাদা রাখে।
• daytona, createos এবং box হলো অন্যান্য রিমোট প্রোভাইডার, যার প্রতিটির জন্য আলাদা কী প্রয়োজন: DAYTONA_API_KEY, CREATEOS_SANDBOX_API_KEY অথবা BOX_API_KEY।
• desktop বটের কমান্ডগুলোকে সরাসরি API এবং ওয়ার্কার হোস্টে চালায়। পাবলিক বা শেয়ার্ড সার্ভিসে এটি কখনোই এনাবল করবেন না।
• fake শুধুমাত্র ভেরিফিকেশনের জন্য একটি এমুলেটর। এটি কোনো রানটাইম নয়।
• none কোনো কম্পিউটার হোস্ট ছাড়াই প্রোডাক্টটি চালু করে।

এই বিষয়টি আক্ষরিক অর্থে গ্রহণ করুন। ডেস্কটপ মোডে কোনো আইসোলেশন বাউন্ডারি থাকে না, তাই বটটি API প্রসেস চালানো ইউজারের পারমিশন নিয়ে শেল কমান্ড চালায়। এর ফলে বটটি ওই ইউজারের হোম ডিরেক্টরি, SSH কী, ক্লাউড ক্রেডেনশিয়াল এবং .env অ্যাক্সেস করতে পারে। বটের পড়া ওয়েব পেজের টেক্সট আপনার সার্ভারে কমান্ড হিসেবে কার্যকর হতে পারে। সার্ভারে ডেস্কটপ মোড ব্যবহার করলে বটের কাছে আপনার ক্রেডেনশিয়াল চলে যাওয়ার ঝুঁকি থাকে। এটি শুধুমাত্র নিজের ব্যক্তিগত মেশিনে ব্যবহার করুন অথবা একেবারেই ব্যবহার করবেন না। প্রোভাইডার পরিবর্তন করলে ওয়েব পেজ পাথটি একটি কন্টেইনারের ভেতর চলে যায়, কিন্তু তা পুরোপুরি বন্ধ হয় না। এছাড়া বটকে নিজস্ব SearXNG সার্চ ব্যাকএন্ড দেওয়া সার্চের দিক থেকে একই ধরনের ইনজেকশন ঝুঁকি নিয়ন্ত্রণ করে।

docker বট এবং আপনার হোস্টের মধ্যে একটি প্রকৃত বাউন্ডারি তৈরি করে, তবে বটগুলোর নিজেদের মধ্যে এটি দুর্বল। ডিফল্টভাবে তারা একটি Team Computer শেয়ার করে। কম্পিউটার রানটাইম ডকুমেন্টেশন অনুযায়ী, টিম বটগুলো একই OS ইউজার, ওয়ার্কস্পেস, ব্রাউজার প্রোফাইল এবং শেল ও X11 অ্যাক্সেস শেয়ার করে। বট-ভিত্তিক ফোল্ডারগুলো কাজ গুছিয়ে রাখতে সাহায্য করলেও সেগুলো কোনো নিরাপত্তা বাউন্ডারি নয়। তাই যেকোনো টিম বট অন্য টিম বটের ফাইল পড়তে পারে। যে বটের নিজস্ব নিরাপত্তা প্রয়োজন, তাকে Private Computer-এ রাখা উচিত, যা ডকার প্রোভাইডারের মাধ্যমে নিজস্ব নেটওয়ার্কে একটি আলাদা সিবলিং কন্টেইনার হিসেবে চলে। তবে যে সুপারভাইজার এই কন্টেইনারগুলো তৈরি করে, তা /var/run/docker.sock মাউন্ট করে। সেলফ-হোস্ট ডকুমেন্টেশন অনুযায়ী, এই সকেটের অ্যাক্সেস থাকা মানে ডকার হোস্টের নিয়ন্ত্রণ থাকা। তাই সুপারভাইজারকে প্রাইভেট রাখুন। .env.example, SANDBOX_SUPERVISOR_TOKEN-কে BETTER_AUTH_SECRET থেকে আলাদা একটি ডেডিকেটেড ক্রেডেনশিয়াল হিসেবে গণ্য করে, যা লোকাল ডেভেলপমেন্টের বাইরে ডকার স্যান্ডবক্সের জন্য প্রয়োজন। এটি GitHub-এ একটি প্লেসহোল্ডারসহ আসে যা যে কেউ পড়তে পারে। তাই এটিকে একটি র‍্যান্ডম ভ্যালু দিন। এখানে সর্বোচ্চ নিরাপত্তার জন্য e2b ব্যবহার করুন অথবা Rakazo-কে এমন একটি মেশিন দিন যাতে অন্য কোনো গুরুত্বপূর্ণ ডেটা নেই। কোডিং এজেন্টগুলোকে ডিসপোজেবল VM-এ চালানোর পেছনেও একই যুক্তি কাজ করে: এজেন্ট কোনো ভুল করলে তা থেকে বাঁচার সবচেয়ে সাশ্রয়ী উপায় হলো এমন একটি মেশিন ব্যবহার করা যার কোনো ক্ষতি হলেও আপনার বড় কোনো ঝুঁকি নেই।

মডেল API key কোথায় রাখতে হয়?

Rakazo-তে কোনো ম্যানেজড মডেল বিলিং নেই। আপনাকে নিজের key ব্যবহার করতে হবে। .env.example সেট করে PI_DEFAULT_PROVIDER=openrouter, তাই OPENROUTER_API_KEY হলো এর সাধারণ জায়গা এবং প্রোভাইডার key-গুলো একই সেটিংয়ের মাধ্যমে কাজ করে।

key-টিকে .env-এ রাখুন এবং এমন কোনো ফাইলে রাখবেন না যা আপনি commit করেন। রিপোজিটরিতে থাকা উভয় compose কমান্ডই --env-file .env পাস করে, তাই মানগুলো git-এ ট্র্যাক করা YAML ফাইলে না লিখেও সরাসরি কন্টেইনারে পৌঁছে যায়। আপনি চাইলে OPENROUTER_API_KEY খালি রেখে সাইনআপের পরে অ্যাপের ভেতর থেকেও মডেল কানেক্ট করতে পারেন; এটি আরও একটি কারণ কেন ENCRYPTION_KEY-এ ডিফল্ট প্লেসহোল্ডারের পরিবর্তে একটি প্রকৃত র‍্যান্ডম মান থাকা প্রয়োজন।

বট ব্যবহারের আগেই প্রোভাইডারের কাছে key-টির জন্য একটি স্পেন্ডিং লিমিট সেট করুন। কোনো বট যদি লুপে পড়ে যায় তবে তা খরচ বাড়াতে থাকে, আর প্রতি-key লিমিটই একমাত্র সুরক্ষা যা আপনার পর্যবেক্ষণের ওপর নির্ভর করে না। এই key-টির একটি আলাদা নাম দিন যাতে প্রয়োজনে শুধু সেটিকে revoke করা যায়। আপনি যদি নিজের পরিবর্তে কোনো টিমের জন্য এটি সেটআপ করেন, তবে সবার এজেন্টের সামনে OneCLI-এর একটি গেটওয়ে এই সমস্যার একটি ভিন্ন সমাধান, কারণ এটি প্রোভাইডার key-গুলোকে প্রতি ব্যক্তির জন্য আলাদা না রেখে এক জায়গায় রাখে।

ডেভেলপমেন্ট মোড থেকে প্রোডাকশন মোডে রূপান্তর

এই রিপোজিটরিতে একটি প্রোডাকশন compose ফাইল দেওয়া আছে যা Postgres, API, worker, web app এবং Caddy চালায়। Caddy স্বয়ংক্রিয়ভাবে TLS (transport layer security) সার্টিফিকেট সংগ্রহ করে। এই স্ট্যাকের মধ্যে শুধুমাত্র Caddy-ই পোর্ট পাবলিশ করে। বট কম্পিউটারগুলোর জন্য এটি ডিফল্টভাবে E2B ব্যবহার করে। একটি অপশনাল ওভারলে, infra/compose/docker-compose.prod.docker.yml, একই স্ট্যাকে লোকাল Docker কম্পিউটার চালায়। ডকুমেন্টেশনে সতর্ক করা হয়েছে যে, এটি যে সুপারভাইজার যোগ করে তা হোস্ট মেশিনে root-এর সমতুল্য ক্ষমতা রাখে।

sudo DEPLOY_USER=deploy bash infra/compose/harden-host.sh
docker compose --env-file .env -f infra/compose/docker-compose.prod.yml \
  build --build-arg GIT_SHA=$(git rev-parse HEAD)
docker compose --env-file .env -f infra/compose/docker-compose.prod.yml \
  up -d --wait --pull never
curl --fail https://app.example.com/health

স্ক্রিপ্টটি চালানোর আগে একটি কি-অনলি (key-only) deploy অ্যাকাউন্ট তৈরি করুন এবং নিশ্চিত করুন যে আপনি সেটি দিয়ে লগইন করতে পারছেন। harden-host.sh SSH পাসওয়ার্ড এবং root লগইন নিষ্ক্রিয় করে, SSH-এর জন্য রেট-লিমিট সেট করে, UFW (uncomplicated firewall)-এর মাধ্যমে শুধুমাত্র SSH, HTTP এবং HTTPS-কে অনুমতি দেয় এবং fail2ban, unattended security updates, AppArmor ও audit রুল চালু করে। এটি চালানোর আগে অবশ্যই পড়ে নিন, কারণ এটি আপনার লগইন পদ্ধতি পরিবর্তন করে এবং SSH রিলোড করে। নতুন SSH লগইন সফল না হওয়া পর্যন্ত আপনার প্রোভাইডারের কনসোল খোলা রাখুন।

প্রোডাকশন .env-এর জন্য ডেভেলপমেন্ট মোডের চেয়ে বেশি কিছু প্রয়োজন। সেলফ-হোস্ট ডকুমেন্টেশনে এই ন্যূনতম প্রয়োজনীয়তা এবং সিক্রেটগুলোর তালিকা দেওয়া আছে।

NODE_ENV=production
RAKAZO_HOST=app.example.com
BETTER_AUTH_URL=https://app.example.com
WEB_ORIGIN=https://app.example.com
API_URL=https://app.example.com
SIGNUPS_ENABLED=true
SIGNUP_ALLOWLIST=you@example.com
SANDBOX_PROVIDER=e2b
AGENT_RUNTIME=pi
WAKEUP_DRIVER=graphile
DATA_DIR=/data
RAKAZO_DEPLOY_DIR=/srv/rakazo
RAKAZO_IMAGE_TAG=local
POSTGRES_PASSWORD=<random, URL-safe>
BETTER_AUTH_SECRET=<random>
ENCRYPTION_KEY=<64 random hex characters>
SCREEN_PROXY_SECRET=<random>
E2B_API_KEY=<your key>
OPENROUTER_API_KEY=<your key>

প্রথম up চালানোর আগেই সার্ভারের দিকে একটি A রেকর্ড পয়েন্ট করুন। Caddy RAKAZO_HOST-এ দেওয়া নামের জন্য সার্টিফিকেট অনুরোধ করে। যদি নামটি এই সার্ভারে রিজলভ না হয় অথবা পোর্ট 80 বাইরের জন্য বন্ধ থাকে, তবে অনুরোধটি ব্যর্থ হবে।

শুরু থেকেই SIGNUP_ALLOWLIST-কে আপনার নিজস্ব ঠিকানায় সেট করে রাখুন। SIGNUPS_ENABLED=true ডিফল্ট হিসেবে থাকে এবং এটি শুধুমাত্র API-এর প্রথম স্টার্টের সময় কার্যকর হয়। তাই পাবলিক ডোমেইনে থাকা কোনো ইনস্ট্যান্স যে কেউ খুঁজে পেলে রেজিস্ট্রেশন করতে পারবে। একটি নন-এম্পটি (non-empty) allowlist প্রতিবার স্টার্টের সময় কার্যকর হয় এবং সংরক্ষিত তালিকাকে প্রতিস্থাপন করে। SMTP কনফিগার করা না থাকলে, প্রথম allowlisted অ্যাকাউন্টটি ইমেইল ভেরিফিকেশন ছাড়াই রেজিস্ট্রেশন করতে পারে। তাই নামটি পাবলিক করার আগেই আপনার অ্যাকাউন্টটি তৈরি করে নিন। প্রথমে allowlist ব্যবহার করুন, পরে প্রয়োজন হলে তা শিথিল করতে পারেন। যদি আপনি একই সার্ভারে একাধিক সার্ভিস চালান এবং প্রতি অ্যাপের জন্য আলাদা allowlist না রেখে একটি সাধারণ তালিকা রাখতে চান, তবে সামনে একটি Authentik ইনস্ট্যান্স বসানো সেই সিদ্ধান্তটি প্রক্সির ওপর ছেড়ে দেয়, যদিও এটি Rakazo-এর নিজস্ব Better Auth অ্যাকাউন্টগুলোকে প্রতিস্থাপন না করে সেগুলোর সামনে অবস্থান করে।

রিপোজিটরিতে থাকা docs/self-host.md-কে প্রোডাকশন সেটিংসের জন্য চূড়ান্ত কর্তৃপক্ষ হিসেবে গণ্য করুন, কারণ কোডের পরিবর্তনের সাথে সাথে এটিও পরিবর্তিত হয়, যা এই গাইডে সবসময় আপডেট করা সম্ভব নয়। যেহেতু Compose সব কাজ পরিচালনা করছে, তাই সাধারণ নিয়মগুলোই প্রযোজ্য। VPS-এর জন্য Docker Compose-এর মৌলিক বিষয়গুলো আলোচনা করে কেন --env-file এবং named volumes গুরুত্বপূর্ণ, বিশেষ করে যখন কোনো স্ট্যাক আপনি দীর্ঘ সময়ের জন্য চালু রেখে দিচ্ছেন।

ব্যাকআপ

Postgres এবং data/ ডিরেক্টরি মিলেই পুরো ইনস্ট্যান্সটি গঠিত।

./scripts/backup.sh
./scripts/restore.sh backups/BACKUP_TIMESTAMP

backup.sh কমান্ডটি Postgres-এর ডাম্প নেয় এবং data/ আর্কাইভ করে। restore.sh কমান্ডটি ডেভেলপমেন্ট Compose স্ট্যাকে কাজ করে, যেখানে অ্যাপ্লিকেশন সার্ভিসগুলো বন্ধ রেখে একটি খালি ডেটাবেসে কাজ করা হয় এবং এটি প্রোডাকশন ব্যাকআপ ফাইলগুলো পড়ে না। যে মেশিনের ওপর আপনি নির্ভরশীল, সেখানে রিপোজিটরিতে থাকা টাইমার ব্যবহার করে infra/compose/backup-prod.sh-কে /usr/local/sbin/rakazo-backup হিসেবে ইনস্টল করুন। এটি একটি যাচাইকৃত ডাম্প এবং অ্যাপ-ডেটা আর্কাইভ /var/backups/rakazo-এ লেখে এবং ডিফল্টভাবে নতুন তিনটি যাচাইকৃত স্ন্যাপশট সংরক্ষণ করে, যা RAKAZO_BACKUP_KEEP দ্বারা নির্ধারিত। নতুন ব্যাকআপ যাচাই হওয়ার পরেই কেবল পুরনো ব্যাকআপ মুছে ফেলা হয়, তাই রোটেশন প্রক্রিয়াটি স্বয়ংক্রিয়ভাবে সম্পন্ন হয়। ডেটাবেস যে ডিস্কে আছে, সেই একই ডিস্কে রাখা ব্যাকআপ আসলে কোনো ব্যাকআপ নয়; তাই ফাইলগুলো অন্য কোনো মেশিনে কপি করে রাখুন। এরপর, প্রয়োজনে ব্যবহারের আগে অন্তত একবার একটি অতিরিক্ত সার্ভারে এটি রিস্টোর করে পরীক্ষা করে নিন।

কেন এটি ব্যর্থ হয় এবং আপনি কী দেখতে পাবেন

pnpm db:migrate ডাটাবেসের সাথে সংযোগ করতে পারছে না। মাইগ্রেশন রিপোর্ট করে যে এটি 127.0.0.1:5433-এ ডাটাবেস সার্ভারের সাথে যোগাযোগ করতে পারছে না। হয় Postgres কন্টেইনারটি চালু নেই, অথবা এটি চালু থাকলেও এখনো প্রস্তুত নয়, অথবা এটি docker-compose.postgres-host.yml ওভারলে ছাড়া শুরু করা হয়েছে, যা মূলত হোস্টের 5433 পোর্টে সার্ভিসটি প্রকাশ করে। docker compose --env-file .env -f infra/compose/docker-compose.yml ps চালান এবং দেখুন postgres সার্ভিসটি healthy রিপোর্ট করছে কি না, কারণ কম্পোজ ফাইলে একটি হেলথ চেক দেওয়া আছে যা প্রতি তিন সেকেন্ডে একবার চলে। একটি কন্টেইনার যদি লুপে রিস্টার্ট হতে থাকে, তবে সাধারণত এর অর্থ হলো pgdata ভলিউমটি ভিন্ন ক্রেডেনশিয়াল দিয়ে তৈরি করা হয়েছে। docker compose ... down -v এটি পরিষ্কার করে দেয় এবং এর সাথে থাকা ডাটা মুছে ফেলে।

পোর্টটি ইতিমধ্যে ব্যবহৃত হচ্ছে। অন্য কোনো কিছু 5433 পোর্ট দখল করে রাখলে Postgres চালু হতে bind: address already in use ত্রুটি দেখায়, সাধারণত এটি এমন কোনো পুরনো Rakazo স্ট্যাক যা আপনি বন্ধ করতে ভুলে গেছেন। sudo ss -lntp | grep 5433 প্রসেসটির নাম বলে দেয়। ওভারলেটি POSTGRES_HOST_PORT থেকে হোস্ট পোর্টটি পড়ে, তাই আপনি চাইলে এটি পরিবর্তন করতে পারেন, তবে শর্ত হলো DATABASE_URL-কেও এর সাথে পরিবর্তন করতে হবে।

বট কোনো কম্পিউটার পাচ্ছে না। SANDBOX_PROVIDER=docker এবং কোনো rakazo/computer:local ইমেজ না থাকলে, শুরু করার মতো কিছুই থাকে না। docker image ls rakazo/computer এক লাইনে এর উত্তর দেয় এবং pnpm sandbox:build এটি ঠিক করে। সুপারভাইজার যদি Docker সকেটে পৌঁছাতে না পারে তবে এটি কন্টেইনারও তৈরি করতে পারে না, এবং মেসেজটিতে পাথটি উল্লেখ থাকে: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock।

একটি দীর্ঘ কমান্ড মাঝপথে বন্ধ হয়ে যায়। .env.example, SANDBOX_COMMAND_TIMEOUT_MS=300000 সেট করে, তাই বটের কম্পিউটারের ভেতরের একটি কমান্ড পাঁচ মিনিট পর বন্ধ হয়ে যায়। স্যান্ডবক্স ক্র্যাশ করেছে মনে না করে ধীরগতির বিল্ডের জন্য এটি বাড়িয়ে দিন।

pnpm install বিভ্রান্তিকরভাবে কাজ করা বন্ধ করে দেয়। অন্য কিছু করার আগে node -v চেক করুন। ওয়ার্কস্পেসটি ^22.22.2 || ^24.0.0 || >=26.0.0 ঘোষণা করে, তাই 23.x, 25.x এবং 22.22.2-এর আগের যেকোনো 22.x এর আওতার বাইরে থাকে, এবং একটি অসমর্থিত Node ভার্সন সম্পর্কে মেসেজ দেওয়ার পরিবর্তে ডিপেন্ডেন্সি কোডে ব্যর্থ হয়।

লোকালি সাইন-ইন কাজ করলেও ডোমেইনের মাধ্যমে কাজ করছে না। BETTER_AUTH_URL, WEB_ORIGIN এবং API_URL সবগুলোর মধ্যেই অ্যাড্রেস বারের মতো একই পাবলিক অরিজিন থাকতে হবে, যার মধ্যে স্কিমও অন্তর্ভুক্ত। এগুলোর কোনো একটিতে পুরনো http://127.0.0.1:5173 থেকে যাওয়া সেশন স্থায়ী না হওয়ার সাধারণ কারণ।

পিন করা চেকআউট আপডেট করা

আপনার চেকআউট থেকে তৈরি প্রোডাকশন Compose স্ট্যাকের জন্য সেলফ-হোস্ট ডক-এ আপগ্রেড করার পদ্ধতিটি সংক্ষিপ্ত: নতুন সোর্স পুল করুন, তারপর API, worker এবং web app রিবিল্ড ও রিস্টার্ট করুন। API শুরু হওয়ার সময় মাইগ্রেশনগুলো স্বয়ংক্রিয়ভাবে চলে, কারণ এর স্টার্ট কমান্ড সার্ভিস চালু করার আগেই মাইগ্রেশন প্রয়োগ করে।

sudo /usr/local/sbin/rakazo-backup
git fetch --all --tags
git checkout NEW_COMMIT_SHA
export GIT_SHA=$(git rev-parse HEAD)
docker compose --env-file .env -f infra/compose/docker-compose.prod.yml \
  up -d --wait --pull never --build api worker web

প্রথমে ব্যাকআপ নিন। মাইগ্রেশনগুলো কেবল সামনের দিকে অগ্রসর হয় এবং বিটা ভার্সনে কোনো নির্ভরযোগ্য রিভার্স পাথ নেই। যদি আপনার চেকআউট 30 আগস্ট 2026-এর আগের হয়, যার মধ্যে v0.1.0-beta কমিট অন্তর্ভুক্ত রয়েছে, তবে আপগ্রেড করার আগে 20260830200000_space_scope_names_and_user_credentials মাইগ্রেশন সংক্রান্ত ডকের নোটটি পড়ুন। এটি একটি সমন্বিত কাটওভার প্রক্রিয়া, তাই প্রথমে পুরনো API এবং worker বন্ধ করুন এবং ডক-এ দেওয়া Space privacy-boundary চেকটি চালান। নতুন কমিটগুলো গ্রহণ করার আগে আপনার বর্তমান পিন করা SHA এবং নতুনটির মধ্যবর্তী কমিটগুলো পড়ে নিন, কারণ এই নতুন প্রজেক্টে প্রায়ই কোনো ঘোষণা ছাড়াই এনভায়রনমেন্ট ভেরিয়েবলের নাম পরিবর্তন করা হয়। কোনো ভেরিয়েবল মিসিং থাকলে সার্ভিসটি চালু হয়েই আবার বন্ধ হয়ে যাবে। আপনি যদি এখনও সিদ্ধান্ত না নিয়ে থাকেন যে Rakazo আপনার জন্য সঠিক সমাধান কি না, তবে সেলফ-হোস্টেড AI এজেন্টদের সারাংশ নিবন্ধটি দেখুন; সেখানে এই ক্যাটাগরির অন্যান্য টুল এবং সেগুলো সচল রাখতে কী পরিমাণ খরচ হয় তা আলোচনা করা হয়েছে।

FAQ

আমি কি 1 জিবি র‍্যামের VPS-এ Rakazo চালাতে পারব?

না। Postgres, API, worker, sandbox supervisor এবং web app—সবগুলো একই সময়ে চলে। এছাড়া SANDBOX_PROVIDER=docker ব্যবহার করলে বটের কম্পিউটারে একটি গ্রাফিক্যাল ডেস্কটপসহ কন্টেইনার যুক্ত হয়, যেখানে প্রতিটি সক্রিয় বটের জন্য আলাদা X display এবং Chrome process থাকে। এই সবকিছুর জন্য ডিফল্টভাবে 2 জিবি মেমোরি এবং দুটি সিপিইউ-এর একটি সর্বোচ্চ সীমা (ceiling) নির্ধারিত থাকে। v0.3.1-এর self-host ডকুমেন্টেশনে কোনো নির্দিষ্ট হোস্ট সাইজের উল্লেখ নেই। আগস্ট 2026-এর বেটা ভার্সনে বলা হয়েছিল যে, যখন E2B বটের ডেস্কটপগুলো হোস্ট করে, তখন শুধুমাত্র API, worker এবং Postgres-এর জন্য 2 vCPU এবং 4 জিবি র‍্যাম যথেষ্ট। কন্ট্রোল প্লেনের জন্য 4 জিবি র‍্যামকে সর্বনিম্ন সীমা হিসেবে ধরুন এবং যখন ডেস্কটপগুলো আপনার নিজস্ব মেশিনে চলবে, তখন এর চেয়ে বেশি র‍্যাম ব্যবহার করুন।

সার্ভারে ডেস্কটপ স্যান্ডবক্স প্রোভাইডার কি নিরাপদ?

না। self-host ডকুমেন্টেশন অনুযায়ী desktop সরাসরি API এবং worker হোস্টের ওপর কমান্ড চালায়। ফলে বটটি সেই প্রসেসটি চালানো ব্যবহারকারীর পরিচয়ে কাজ করে এবং সেই ব্যবহারকারীর ফাইল ও ক্রেডেনশিয়াল বটের নাগালের মধ্যে থাকে। এটিকে কোনো পাবলিক বা শেয়ার্ড সার্ভারে রাখবেন না। docker ব্যবহার করুন, যা বটকে একটি Private Computer দেয় যখন সে ওয়ার্কস্পেসের অন্য বটের সাথে ফাইল শেয়ার করতে পারবে না, অথবা e2b ব্যবহার করুন যখন একাধিক ব্যক্তি সাইন-ইন করেন।

Rakazo-এর কোন ভার্সনটি আমার ইনস্টল করা উচিত?

21 অক্টোবর 2026 অনুযায়ী সর্বশেষ রিলিজ হলো v0.3.1, যা 19 অক্টোবর 2026-এ প্রকাশিত হয়েছে এবং Latest হিসেবে চিহ্নিত। main বা আগস্টের v0.1.0-beta প্রি-রিলিজ ট্র্যাক না করে এটি যে কমিটকে নির্দেশ করে, সেই 926710a09b30a6c1f83029da88dfe06656b031f2 কমিটটি দেখুন। একটি ব্রাঞ্চ যেকোনো সময় পরিবর্তিত হতে পারে এবং একটি ট্যাগ পুনরায় অন্য কোথাও পয়েন্ট করা হতে পারে, তাই এগুলোর কোনোটিই এমন কোনো নির্দিষ্ট ভার্সনকে চিহ্নিত করে না যেখানে আপনি ফিরে যেতে পারবেন। কমিটটি রেকর্ড করে রাখুন, কারণ কোনটি কাজ করছিল তা জানা থাকলেই কেবল রোলব্যাক করা সম্ভব।

আমার OpenRouter API key কোথায় রাখব?

.env-এ OPENROUTER_API_KEY হিসেবে রাখুন, এবং কখনোই এমন কোনো compose ফাইলে রাখবেন না যা আপনি কমিট করেন। রিপোজিটরির উভয় compose কমান্ডই --env-file .env পাস করে, তাই ট্র্যাক করা YAML ফাইলে না লিখেও মানটি কন্টেইনারে পৌঁছে যায়। আপনি চাইলে এটি খালি রেখে সাইন-আপের পর অ্যাপের ভেতর মডেল কানেক্ট করতে পারেন। প্রোভাইডারের কাছে কি-এর জন্য একটি খরচ সীমা (spending limit) নির্ধারণ করে দিন, কারণ লুপে থাকা কোনো বট থামানো না পর্যন্ত মডেলটিকে কল করতেই থাকবে।

আমার কি ডোমেইন নেম এবং TLS প্রয়োজন?

প্রাথমিক পরীক্ষার পরের যেকোনো কিছুর জন্য, হ্যাঁ। প্রোডাকশন compose ফাইলটি Caddy চালায় এবং স্বয়ংক্রিয়ভাবে সার্টিফিকেট সংগ্রহ করে। এছাড়া RAKAZO_HOST, BETTER_AUTH_URL, WEB_ORIGIN এবং API_URL—সবগুলোরই একই পাবলিক HTTPS অরিজিন থাকা আবশ্যক। প্রথমবার দেখার জন্য আপনি ডোমেইন বাদ দিতে পারেন: pnpm dev চালান এবং পোর্ট 5173 পাবলিশ না করে SSH-এর মাধ্যমে ফরোয়ার্ড করুন।