সার্ভারে Claude Code নিরাপদে চালানোর নিয়ম

সার্ভারে Claude Code নিরাপদে চালানোর অর্থ কী

সার্ভারে Claude Code নিরাপদে চালাতে এর permission prompts চালু রাখুন, এটিকে একটি ডেডিকেটেড unprivileged user হিসেবে চালান, এবং unattended runs-এর জন্য কেবল বিশ্বাসের ওপর নির্ভর না করে একটি প্রকৃত সীমানা (boundary) দিন: বিল্ট-ইন sandbox, একটি container, অথবা একটি disposable VPS যাতে আপনার গুরুত্বপূর্ণ কোনো ডেটা নেই। The --dangerously-skip-permissions flag ব্যবহার করলে মডেল এবং আপনার shell-এর মধ্যে approval stepটি রিমুভ হয়ে যায়। unattended কাজের জন্য এই পরিবর্তনটি যুক্তিযুক্ত হতে পারে, তবে কেবল এমন একটি সীমানার মধ্যে যা একটি ভুল command-এর প্রভাব সীমিত করে। এই গাইডটি ব্যাখ্যা করে যে এই flag আসলে কী পরিবর্তন করে এবং কীভাবে ধাপে ধাপে আইসোলেশন বাড়িয়ে সেই সীমানা তৈরি করা যায়।

আপনার মেশিনে Claude Code কী করতে পারে

Claude Code হলো একটি coding agent যা আপনার terminal-এ চলে। এটি ফাইল পড়তে পারে, ফাইল লিখতে পারে এবং যে user দিয়ে এটি শুরু করা হয়েছে সেই user হিসেবে shell commands চালাতে পারে। এটাই এই টুলের মূল সুবিধা: আপনি প্রতিটি command টাইপ না করেই এটি একটি repository clone করতে পারে, code এডিট করতে পারে, tests চালাতে পারে, failure পড়তে পারে এবং একটি লুপে code ঠিক করতে পারে। আপনি যদি এখনও এটি কোনো সার্ভারে সেটআপ না করে থাকেন, তবে tmux সহ একটি VPS-এ Claude Code চালানো ইন্সটলেশন এবং session handling সম্পর্কে ধারণা দেবে। এই পেজটি এটি সেটআপ করার পর এর ক্ষমতা নিয়ে আলোচনা করে।

এর ঝুঁকি হলো একই বাক্য দ্বিতীয়বার পড়া। একটি process যা আপনার user হিসেবে shell commands চালাতে পারে, সেটি আপনার user যা যা করতে পারে সব করতে পারে। এটি ~/.ssh/id_ed25519, ~/.aws/credentials, এবং আপনার user যে সব .env ফাইল ওপেন করতে পারে তার প্রতিটি ফাইল পড়তে পারে। এটি curl চালাতে পারে এবং সার্ভার যে সব host-এ পৌঁছাতে পারে সেখানে ডেটা পাঠাতে পারে। এটি git push --force চালাতে পারে। এজেন্টটির নিজস্ব কোনো উদ্দেশ্য নেই। বিপদ হলো কোনো কাজ ভুল হওয়া, অথবা এটি কাজ করার সময় যে টেক্সট পড়েছে তাতে অন্য কেউ লিখে রাখা কোনো নির্দেশাবলী থাকতে পারে: যেমন কোনো ওয়েব পেজ যা এটি fetch করেছে, অথবা কোনো issue-এর কমেন্ট যা এটি ঠিক করার জন্য বলা হয়েছে। এই দ্বিতীয় ঘটনাটিকে prompt injection বলা হয়, এবং এই কারণেই "the model is usually sensible" কোনো সিকিউরিটি প্ল্যান নয়। আপনাকে গড়পড়তা কাজের জন্য নয়, বরং ভুল কাজের (bad run) জন্য প্রস্তুতি নিতে হবে।

সহজ ভাষায় permission system

ডিফল্টভাবে, Claude Code কোনো কাজ করার আগে অনুমতি চায়। প্রজেক্টের ভেতরের ফাইল পড়া নীরবে ঘটে, কিন্তু কোনো ফাইল এডিট করা বা shell command চালানোর ক্ষেত্রে এটি প্রথমে আপনাকে সঠিক এডিট বা command দেখাবে এবং 'yes' করার জন্য অপেক্ষা করবে। আপনি একটি নির্দিষ্ট action অনুমোদন করতে পারেন, অথবা পুরো session-এর জন্য সেই ধরণের action অনুমোদন করতে পারেন। এই approvals গুলো session-scoped: CLI বন্ধ করে দিলে পরবর্তী session আবার সতর্কভাবে শুরু হবে। আপনি যে নিয়মগুলো স্থায়ী রাখতে চান, তার জন্য settings file-এ persistent allow, ask, এবং deny list থাকে। উদাহরণস্বরূপ: allow git status, ask on git push, deny reads of .env। Deny rules সবসময় অগ্রাধিকার পায়।

এই ডিজাইনটি ধরে নেয় যে একজন মানুষ terminal পর্যবেক্ষণ করছে, যা ল্যাপটপের ক্ষেত্রে সত্য। সার্ভারের ক্ষেত্রে সমস্যা হলো সেখানে কেউ পর্যবেক্ষণ করে না। আপনি tmux-এর ভেতরে একটি দীর্ঘ কাজ শুরু করে ঘুমানোর জন্য চলে যান, আর রাত ২টায় কোনো প্রশ্ন করার জন্য থেমে যাওয়া এজেন্ট সকাল না হওয়া পর্যন্ত কোনো অগ্রগতি করতে পারে না। এতে সময়ের পাশাপাশি অর্থেরও অপচয় হয়, কারণ একটি idle Claude Code session তার warm prompt cache হারায় এবং পরবর্তী টার্নে সেটি পুনরায় তৈরি করতে খরচ হয়। সার্ভারে মানুষ কেন skip flag ব্যবহার করতে চায় তার আসল কারণ এটাই, এবং এটি যে সমস্যার সমাধান করে তা বাস্তব। এই গাইডের বাকি অংশ হলো সমস্ত guardrail ত্যাগ না করেই এই সমস্যার সমাধান করা।

--dangerously-skip-permissions কী পরিবর্তন করে

claude --dangerously-skip-permissions approval stepটি বন্ধ করে দেয়। এডিট কোনো prompt ছাড়াই ঘটে। Shell commands কোনো prompt ছাড়াই চলে। সংবেদনশীল লোকেশনগুলো রক্ষার জন্য যে protected-path checks থাকে, সেগুলোও স্কিপ করা হয়। আপনার explicit deny rules তখনও কার্যকর থাকবে, এবং কিছু অত্যন্ত গুরুতর ক্ষেত্রে এটি এখনও থামবে, কিন্তু কাজের সারসংক্ষেপ হলো সহজ: মডেল যা চালানোর সিদ্ধান্ত নেবে, তা-ই চলবে।

সার্ভারের ক্ষেত্রে এই flag-এর দুটি দিক গুরুত্বপূর্ণ। প্রথমত, Linux এবং macOS-এ Claude Code যখন root বা sudo হিসেবে চলে তখন এটি ব্লক করা হয়, কারণ কোনো prompt ছাড়া root মেশিনের যেকোনো ফাইল বা service পরিবর্তন করতে পারে। এজেন্টের নিজস্ব unprivileged account থাকা প্রয়োজন এবং এই flag সেটি নিশ্চিত করে। দ্বিতীয়ত, এই flag মডেলের আচরণ কোনোভাবেই পরিবর্তন করে না। এটি লুপ থেকে মানুষকে সরিয়ে দেয় কিন্তু অন্য কিছু পরিবর্তন করে না, তাই একটি prompt যা ভুল ধরতে পারত, তা এখন সরাসরি execute হয়ে যায়।

তাই আসল হিসাবটি হলো: আপনি যদি permissions skip করেন, তবে সিকিউরিটি প্রশ্নটি "এজেন্ট কি খারাপ কিছু করবে" থেকে পরিবর্তিত হয়ে "একটি ভুল কাজ কতটা ক্ষতি করতে পারে" এ পরিণত হয়। আপনি প্রতিটি সিদ্ধান্ত নিয়ন্ত্রণ করার চেষ্টা করা বন্ধ করে দেবেন এবং এর পরিবর্তে blast radius নিয়ন্ত্রণ করা শুরু করবেন। এর সমাধান হলো containment, যা ধাপে ধাপে করা সম্ভব।

বিল্ট-ইন Claude Code sandbox

ধাপগুলোর আগে জেনে রাখুন যে Claude Code এখন এর কমান্ডগুলোর জন্য একটি OS-level sandbox প্রদান করে, যা মানুষকে skip flag ব্যবহার করার অধিকাংশ কারণ দূর করে দেয়। Linux-এ এটি filesystem isolation-এর জন্য bubblewrap এবং network traffic একটি proxy-র মাধ্যমে পাঠানোর জন্য socat ব্যবহার করে। Sandbox-এর ভেতরে, একটি command কেবল প্রজেক্ট ডিরেক্টরি এবং একটি session temp ডিরেক্টরিতে লিখতে পারে, এবং এটি কেবল একটি proxy-র মাধ্যমে নেটওয়ার্কে পৌঁছাতে পারে যা প্রতিটি domain-কে একটি allow list-এর সাথে যাচাই করে। যখন কোনো command প্রথমবারের মতো নতুন কোনো domain ব্যবহার করতে চায়, Claude Code আপনাকে জিজ্ঞাসা করে।

একটি session-এর ভেতরে /sandbox কমান্ড দিয়ে এটি চালু করুন। Ubuntu এবং Debian-এ, প্রথমে এর প্রয়োজনীয় দুটি প্যাকেজ ইন্সটল করুন:

sudo apt install bubblewrap socat

Ubuntu 24.04 এবং পরবর্তী ভার্সনগুলোতে, ডিফল্ট AppArmor policy bubblewrap-কে প্রয়োজনীয় user namespaces তৈরি করতে বাধা দেয়। sandbox panel আপনাকে জানাবে যখন কিছু মিসিং থাকবে, এবং Claude Code sandboxing documentation-এ এর সমাধান হিসেবে একটি ছোট AppArmor profile দেওয়া আছে।

Sandbox-এর একটি auto-allow mode আছে: sandboxed commands কোনো prompt ছাড়াই চলে, কারণ এখন enforced boundary সেই কাজ করে যা আগে prompt করত। যেসব command sandbox-এর ভেতরে চলতে পারে না, সেগুলো সাধারণ permission flow-তে ফিরে যায়, তাই সত্যিই অস্বাভাবিক কাজের জন্য এটি এখনও জিজ্ঞাসা করে। বেশিরভাগ সার্ভার ওয়ার্কফ্লোর জন্য এটি skip flag-এর সঠিক বিকল্প, কারণ আপনি কোনো সুরক্ষা ছাড়াই নয়, বরং একটি OS-enforced boundary সহ অনেক কম প্রশ্ন পাবেন।

এর সীমাবদ্ধতা সম্পর্কে সচেতন থাকুন। ডিফল্টভাবে একটি sandboxed command এখনও বেশিরভাগ filesystem পড়তে পারে, যার মধ্যে credential files অন্তর্ভুক্ত, যদি না আপনি সেই path গুলো deny করেন; sandbox.credentials setting ঠিক এই কাজের জন্যই তৈরি। Network proxy শুধুমাত্র domain name চেক করে এবং ট্রাফিক পরিদর্শন করে না, তাই github.com এর মতো একটি broad allow এখনও ডেটা বাইরে পাঠানোর সুযোগ রাখে। Docker এর ভেতরে কাজ করে না। Sandbox নিরাপত্তার স্তর অনেক বাড়িয়ে দেয়। এটি সম্পূর্ণ isolation boundary নয়, তাই নিচের ধাপগুলো এখনও গুরুত্বপূর্ণ।

The containment ladder

আইসোলেশনের ক্রম অনুযায়ী তিনটি ধাপ। আপনার মেশিনে যা আছে তার সাথে সামঞ্জস্যপূর্ণ সর্বনিম্ন ধাপটি বেছে নিন।

Rung 1: একটি ডেডিকেটেড unprivileged user। এজেন্ট একটি নিজস্ব account, নিজস্ব home directory, নিজস্ব project directory পাবে এবং কোনো sudo পাবে না:

sudo adduser --disabled-password --gecos "" agent

এই account boundary এজেন্টকে আপনার ফাইলগুলো থেকে দূরে রাখে: আপনার SSH keys এবং মেশিনে থাকা অন্য যেকোনো প্রজেক্ট। এটি skip flag ব্যবহার করাকেও সম্ভব করে তোলে, কারণ এই flag root হিসেবে চলতে অস্বীকার করে। এটি প্রতিটি service-কে unprivileged user হিসেবে চালানো এর মতোই একটি নীতি যা এজেন্টের ক্ষেত্রে প্রয়োগ করা হয়েছে। Rung 1 যা নিয়ন্ত্রণ করতে পারে না: নেটওয়ার্ক এবং মেশিনে থাকা যেকোনো world-readable ফাইল।

Rung 2: একটি container। Anthropic একটি reference devcontainer প্রকাশ করেছে যা Claude Code-কে non-root user হিসেবে চালায়, যেখানে firewall rules থাকে যা এজেন্ট কোন host-এ পৌঁছাতে পারবে তা সীমিত করে। আপনি নিজে তৈরি করা container-ও একই কাজ করে। Filesystem কেবল আপনার mount করা volumes-এর মধ্যে সীমাবদ্ধ থাকে এবং egress কেবল container-এর rules অনুযায়ী হয়। যখন সার্ভারে আপনার প্রয়োজনীয় অন্যান্য service চলে, তখন এটি সঠিক মধ্যম ধাপ। এর সীমাবদ্ধতা হলো container গুলো host kernel শেয়ার করে, এবং একটি ভুল mount সীমানা নষ্ট করে দিতে পারে; container-কে /var/run/docker.sock দিলে এটি পুরো host-এ পৌঁছাতে পারে।

Rung 3: একটি ডেডিকেটেড VPS। সবচেয়ে শক্তিশালী ধাপটি হলো সবচেয়ে সহজ: এজেন্টকে একটি সম্পূর্ণ মেশিন দিন যাতে আপনার প্রয়োজনীয় কিছুই নেই। একটি ছোট VPS প্রতি মাসে মাত্র কয়েক ডলার খরচ করে। এটিকে একটি নতুন VPS-এর প্রথম দশ মিনিটের runbook দিয়ে সেটআপ করুন, clean state-এর snapshot নিন এবং এজেন্টকে কাজ করতে দিন। সেখানে অন্য কিছু থাকে না। কোনো ব্যক্তিগত SSH key নেই, কেবল একটি নির্দিষ্ট repository-র জন্য scoped deploy key আছে। কোনো cloud credentials নেই, কোনো production data নেই। কোনো কাজ ভুল হলে, অথবা আপনি যখন কেবল একটি clean slate চান, তখন snapshotটি রিস্টোর করুন অথবা কয়েক মিনিটে মেশিনটি ধ্বংস করে পুনরায় তৈরি করুন। এখানে blast radius হলো ভাড়ার পরিমাণ। এটি এমন একটি সেটআপ যেখানে --dangerously-skip-permissions ভীতিজনক নয়, কারণ সবচেয়ে খারাপ ফলাফল হলো একটি রিস্টোর করা সার্ভার এবং একটি বাতিল করা টোকেন।

এই ধাপগুলো স্তরে স্তরে কাজ করে। একটি sandboxed agent, যা unprivileged user হিসেবে চলে এবং একটি disposable VPS-এ থাকে, এতে অতিরিক্ত খরচ প্রায় নেই বললেই চলে এবং এটি ব্যর্থতার ঝুঁকি কমিয়ে দেয়। Boring বা সাধারণ ফলাফল অর্জন করাই হলো লক্ষ্য।

Credentials রক্ষা করুন

এমন একটি নিয়ম যা অন্য সবকিছুর জন্য কাজ করে: এজেন্টের user অন্য কোনো কিছুর secret পড়তে পারবে না।

API key শুধুমাত্র এজেন্টকে দিন, অন্য কিছুকে নয়। এটি এজেন্ট user-এর মালিকানাধীন একটি ফাইলে রাখুন যার mode 600, এবং shell শুরু হওয়ার সময় এটি load করুন:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

এরপর অন্য দিকটি বন্ধ করুন। Debian এবং Ubuntu-তে home directories প্রায়ই মেশিনের প্রতিটি user-এর জন্য readable অবস্থায় তৈরি করা হয়, তাই আপনার নিজের ডিরেক্টরি টাইট করে রাখুন: chmod 750 /home/youruser। ls -ld /home/* দিয়ে চেক করুন এবং এজেন্ট অ্যাকাউন্ট যা list করতে পারে তা ঠিক করুন।

প্রতিটি token-কে scope করুন। একটি নির্দিষ্ট repository-র জন্য সীমিত fine-grained GitHub token, অথবা একটি per-repository deploy key নিশ্চিত করে যে একটি leaked credential কেবল একটি প্রজেক্ট হারাবে, আপনার পুরো অ্যাকাউন্ট নয়। আপনি যদি sandbox ব্যবহার করেন, তবে এর credential settings যোগ করুন যাতে ~/.ssh এবং ~/.aws এমনকি reads-এর জন্যও deny করা হয়। এবং production credentials সম্পূর্ণভাবে মেশিনের বাইরে রাখুন, কারণ এজেন্ট এমন কোনো secret ফাঁস করতে পারে না যা সেখানে ছিল না।

Git হলো safety net

এজেন্ট যে পরিবর্তনগুলো করে তার প্রতিটি review করা এবং revert করা সম্ভব হওয়া উচিত, এবং এজেন্ট যদি একটি branch-এ কাজ করে তবে git আপনাকে এই দুটি সুবিধা বিনামূল্যে দেয়:

git switch -c agent/refactor-auth

কাজ শেষ হওয়ার পর git diff main...agent/refactor-auth দিয়ে এটি রিভিউ করুন, যা ভালো তা merge করুন, এবং কাজ না হলে branch টি ডিলিট করে দিন। Forge সাইডে main branch টি সুরক্ষিত রাখুন, যাতে এজেন্টের token দিয়ে সেখানে push করা না যায় এবং force-push করা না যায়। Commit history আপনার ঘুমানোর সময় কী ঘটেছে তার একটি audit log হিসেবে কাজ করে, যা terminal scrollback-এর চেয়ে অনেক বেশি মূল্যবান।

নেটওয়ার্ক হলো blast radius-এর অংশ

একটি এজেন্ট curl চালাতে পারে। এই একটি বাক্যই হলো egress সমস্যার মূল কারণ: এজেন্ট যা পড়তে পারে, তা সে কোথাও পাঠাতেও পারে, এবং একটি prompt-injected এজেন্ট তা করতে পারে। একটি সাধারণ unprivileged user এটি মোটেও নিয়ন্ত্রণ করতে পারে না, কারণ যেকোনো user সার্ভার যে সব কিছুতে পৌঁছাতে পারে তাতে পৌঁছাতে পারে। Sandbox এর proxy-র মাধ্যমে domain অনুযায়ী এটি নিয়ন্ত্রণ করে। একটি container তার নিজস্ব firewall rules দিয়ে এটি নিয়ন্ত্রণ করতে পারে। একটি ডেডিকেটেড VPS মূলত কী ফাঁস হতে পারে তা নিয়ন্ত্রণ করে, যা এই তিনটির মধ্যে সবচেয়ে শক্তিশালী সমাধান।

শুধুমাত্র ufw দিয়ে egress সমাধান করার চেষ্টা করবেন না। ufw ডিফল্টভাবে সমস্ত outgoing traffic অনুমতি দেয়, এবং apt, npm, git, এবং Claude API অনুমতি দেয় এমন outbound rules লেখা বেশ জটিল কাজ যা নীরবে ভেঙে পড়তে পারে। এর পরিবর্তে sandbox, container, অথবা machine লেভেলে সীমানা নির্ধারণ করুন, যেখানে একটি domain allow list বা একটি খালি মেশিন একই কাজ খুব সহজে করতে পারে।

আপনি যদি Claude Code চালানোর পরিবর্তে API ব্যবহার করে নিজের এজেন্ট তৈরি করেন, তবে একই চিন্তাভাবনা প্রযোজ্য। Claude দিয়ে একটি AI agent তৈরি করা সেই পথটি নিয়ে আলোচনা করে, এবং সেই এজেন্টেরও একই ডেডিকেটেড user, একই scoped tokens, এবং একই disposable box প্রয়োজন।

প্রথমে মেশিনটি harden করুন

আপনি যে ধাপই বেছে নিন না কেন, এজেন্ট আসার আগে মেশিনটিকে কিছু মৌলিক বিষয় নিশ্চিত করতে হবে: শুধুমাত্র SSH keys, কোনো root login নয়, একটি default-deny firewall, এবং automatic security updates। আপনার checklist এখানে তৈরি করুন এবং একবার এটি সম্পন্ন করুন:

FAQ

সার্ভারে --dangerously-skip-permissions ব্যবহার করা কি নিরাপদ?

নিজে নিজে নয়। এই flag প্রতিটি approval prompt সরিয়ে দেয়, তাই মডেলটি কোনো কমান্ড তৈরি করার সাথে সাথেই সেটি চলতে শুরু করে। যখন blast radius নিয়ন্ত্রিত থাকে তখন এটি একটি যুক্তিযুক্ত পরিবর্তন হতে পারে: অন্তত একটি ডেডিকেটেড unprivileged user, এবং unattended কাজের জন্য একটি container বা একটি disposable VPS যাতে কেবল একটি প্রজেক্ট এবং একটি scoped token থাকে। এমন কোনো মেশিনে এটি কখনও ব্যবহার করবেন না যেখানে production credentials বা এমন ডেটা আছে যা আপনি হারাতে পারবেন না।

Claude Code-এ কি sandbox আছে?

হ্যাঁ। Claude Code-এ shell commands-এর জন্য একটি বিল্ট-ইন sandbox আছে, যা /sandbox কমান্ড দিয়ে চালু করা হয়। এটি Linux-এ bubblewrap এবং macOS-এ Seatbelt ব্যবহার করে, writes গুলো প্রজেক্ট ডিরেক্টরির মধ্যে সীমাবদ্ধ রাখে, এবং নেটওয়ার্ক অ্যাক্সেস একটি proxy-র মাধ্যমে পরিচালনা করে যা কেবল অনুমোদিত domain গুলোকে অনুমতি দেয়। এর auto-allow mode কোনো prompt ছাড়াই sandboxed commands চালায়, যা skip flag-এর মতো বাধা দূর করে কিন্তু একটি OS-enforced boundary বজায় রাখে। এটি সম্পূর্ণ isolation boundary নয়, তাই unattended runs-এর জন্য এটিকে একটি ডেডিকেটেড user বা ডেডিকেটেড মেশিনের সাথে ব্যবহার করুন।

skip flag কেন root হিসেবে চলতে অস্বীকার করে?

কারণ root কোনো permission prompt ছাড়াই সিস্টেমের যেকোনো ফাইল এবং যেকোনো service পরিবর্তন করতে পারে, তাই Claude Code Linux এবং macOS-এ root বা sudo হিসেবে চললে --dangerously-skip-permissions ব্লক করে দেয়। এর সমাধান চেকটি নিয়ে লড়াই করা নয়। এজেন্টের জন্য একটি unprivileged user তৈরি করুন এবং সেখানে এটি চালান; সেই account boundary হলো containment-এর প্রথম এবং সবচেয়ে সহজ স্তর।

Claude Code কি আমার SSH keys এবং .env ফাইল পড়তে পারে?

এটি যে user হিসেবে চলে তার যা যা পড়ার ক্ষমতা আছে তা সব পড়তে পারে, এমনকি sandbox-এর ডিফল্ট policy-তেও credential paths পড়া সম্ভব যতক্ষণ না আপনি সেগুলো deny করছেন। তাই এজেন্টকে তার নিজস্ব user হিসেবে চালান, আপনার নিজের home directory-র mode 750 বা তার চেয়ে বেশি রাখুন, sandbox settings-এ credential paths deny করুন, এবং production secrets সম্পূর্ণভাবে মেশিনের বাইরে রাখুন। মেশিনটি যা কখনো ধারণ করেনি তা পড়া বা ফাঁস করা সম্ভব নয়।

unattended ভাবে Claude Code চালানোর সবচেয়ে নিরাপদ উপায় কী?

শুধুমাত্র এজেন্ট কাজের জন্য ব্যবহৃত একটি সস্তা ডেডিকেটেড VPS: যা দশ মিনিটে harden করা হয়েছে, clean state-এর snapshot নেওয়া হয়েছে, sandbox চালু থাকা অবস্থায় একটি unprivileged user হিসেবে Claude Code চালানো হচ্ছে, mode-600 ফাইলে API key রাখা হয়েছে, একটি per-repository deploy key আছে, এবং সমস্ত কাজ এমন branch-এ করা হচ্ছে যা merge করার আগে আপনি রিভিউ করবেন। যদি কোনো কাজ ভুল হয়, আপনি কেবল একটি টোকেন বাতিল করবেন এবং snapshotটি রিস্টোর করবেন, এবং আপনার মালিকানাধীন অন্য কিছুর কোনো ক্ষতি হবে না।