ডেভেলপমেন্টে WSL নাকি VPS, কোনটি আপনার জন্য ভালো?

ডেভেলপমেন্টের জন্য WSL নাকি VPS ব্যবহার করবেন?

ডেভেলপমেন্টের জন্য WSL বনাম VPS বেছে নেওয়ার মূল বিষয় একটি: availability। WSL (Windows Subsystem for Linux) এমন একটি virtual machine-এর ভেতরে Ubuntu চালায়, যা আপনার Windows session চালু থাকা পর্যন্ত চলে এবং session শেষ হলে বন্ধ হয়ে যায়। VPS (virtual private server) একই Ubuntu এমন একটি public IP address-এ চালায়, যা আপনার laptop বন্ধ থাকলেও চালু থাকে। অধিকাংশ developer শেষ পর্যন্ত দুটিই ব্যবহার করেন, যেখানে server-টি এমন machine হিসেবে থাকে যেটিতে সব সময় reach করা যায়।

দুটিই Ubuntu হওয়ায় operating system-এর পার্থক্যটি গুরুত্বপূর্ণ নয়। পার্থক্য হলো uptime, internet থেকে reachability, systemd কী নিশ্চয়তা দিতে পারে, file access কত দ্রুত, network কীভাবে আচরণ করে এবং backup কার নিয়ন্ত্রণে থাকে। নিচের প্রতিটি section-এ এমন একটি পার্থক্য দেখানো হয়েছে, যা আপনি নিজের machine-এ ঘটতে দেখতে পারবেন।

ল্যাপটপ বন্ধ করলে WSL কেন বন্ধ হয়ে যায়?

WSL 2 একটি lightweight virtual machine-এর মধ্যে বাস্তব Linux kernel চালায়। Windows প্রয়োজন অনুযায়ী এই virtual machine চালু করে। কোনো distribution চলমান থাকলেই কেবল virtual machine-টি সক্রিয় থাকে। কোনো কিছু distribution ব্যবহার করলেই কেবল distribution-টি চলে। PowerShell থেকে অবস্থা পরীক্ষা করুন:

wsl --version
wsl --list --running

সব WSL terminal বন্ধ করুন, এক মিনিট অপেক্ষা করুন, তারপর আবার wsl --list --running চালান। যখন এটি জানাবে যে কোনো running distribution নেই, তখন আপনি যে shell চালু করেছিলেন সেটি এবং সেটিতে চলমান সবকিছু বন্ধ হয়ে গেছে। wsl --shutdown একই কাজ সঙ্গে সঙ্গে করে। Restart-এর পরে আপনার setup কীভাবে আচরণ করে তা পরীক্ষা করার এটি একটি কার্যকর উপায়।

Sleep এবং hibernate virtual machine-টিকেও বন্ধ করে দেয়। 03:00 সময়ে database dump করার জন্য সেট করা timer lid বন্ধ থাকা অবস্থায় চলবে না, কারণ এটি চালানোর kernel তখন executing অবস্থায় থাকে না। কোনো কিছু error log করে না। তাই মনে হয় job-টি যেন কখনো schedule-ই করা হয়নি। এই আচরণের কারণেই অনেকে দ্বিতীয় machine ব্যবহার করেন। Build queue, chat bot, nightly backup বা webhook receiver চালাতে এমন একটি computer প্রয়োজন, যা চালু থাকে।

WSL-এ কি systemd কাজ করে?

হ্যাঁ। WSL 0.67.6-এ এর সমর্থন যোগ হয়েছিল। পুরোনো installation-এ এটি ডিফল্টভাবে বন্ধ থাকে। এটি ছাড়া systemctl status ssh এই ফলাফল দেখায়:

System has not been booted with systemd as init system (PID 1). Can't operate.

প্রথমে configuration file পড়ুন, কারণ সেখানে আগে থেকেই configuration থাকতে পারে। এতে [boot] section না থাকলে একটি section যোগ করুন। section থাকলে, ইতিমধ্যে থাকা section-এর ভেতরে শুধু ওই একটি line যোগ করুন।

cat /etc/wsl.conf
sudo tee -a /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

PowerShell-এ wsl --shutdown চালান। একটি নতুন Ubuntu shell খুলুন। এরপর systemctl list-units --type=service --state=running দিয়ে পরীক্ষা করুন। unit-এর একটি তালিকা দেখালে systemd PID 1 হিসেবে চলছে। এরপর থেকে journalctl -b কাজ করবে।

সমস্যাটি হলো, প্রতিটি machine-এ enable কী নিশ্চয়তা দেয়। VPS-এ sudo systemctl enable --now caddy-এর অর্থ হলো service boot-এর সময় start হয়। তাই কেউ লগ ইন না থাকলেও reboot বা kernel upgrade-এর পরে এটি আবার চালু হয়। WSL-এ এর অর্থ হলো distribution start হলে service start হয়। আর distribution start হয় যখন আপনি একটি terminal খোলেন। তাই আপনি কাজ করার সময়ই service চালু থাকে। service থাকার মূল উদ্দেশ্যের সঙ্গে এটি বিপরীত। Container-এও একই সীমাবদ্ধতা থাকে। তাই Docker Compose service-কে boot-এর সময় start করানো এমন একটি boot-এর ওপর নির্ভর করে, যা WSL কেবল আপনি চাইলে সম্পন্ন করে।

WSL-এ চলা কোনো server কি webhook-এ পৌঁছাতে পারে?

সহায়তা ছাড়া পারে না। কারণটি network layout-এ। Default mode-এ WSL 2 virtual machine-কে নিজের virtual adapter-এ NAT (network address translation)-এর পেছনে রাখে। Address-টি দেখুন:

ip -4 addr show eth0
ip route show default

এই address private এবং virtual machine চালু হওয়ার প্রতিবার আবার বরাদ্দ হয়, তাই এটি পরিবর্তিত হয়। Windows নিজে এখনও localhost:3000-এ পৌঁছাতে পারে, কারণ WSL localhost connection-গুলো distribution-এর ভেতরে forward করে। আপনার network-এর অন্য কোনো machine তা পারে না, যদি না Administrator PowerShell থেকে একটি proxy rule যোগ করেন:

netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=172.24.108.3

এই rule-এ একটি নির্দিষ্ট address দেওয়া থাকে। তাই address পরিবর্তিত হলে পরবর্তীবার এটি কাজ করে না। Mirrored networking ভালো বিকল্প। এতে distribution Windows-এর মতো একই interface ও address পায়। August 2026 অনুযায়ী এর জন্য Windows 11 22H2 বা নতুন সংস্করণ প্রয়োজন। %UserProfile%\.wslconfig-এ এটি লিখে wsl --shutdown চালান:

[wsl2]
networkingMode=mirrored

Mirrored mode local network-এর সমস্যা সমাধান করে। এটি আপনাকে public address দেয় না। আপনার router আবার NAT চালায়। বেশিরভাগ home connection-এ আপনার নিয়ন্ত্রণাধীন কোনো inbound port থাকে না। অনেক ISP-এর ক্ষেত্রে এর ওপর আরও একটি NAT স্তর থাকে। তাই GitHub আপনার laptop-এ কোনো event POST করতে পারে না এবং কোনো colleague আপনার demo link খুলতে পারে না। Tunnel service এই সীমাবদ্ধতা এড়াতে পারে। তবে tunnel client laptop-এ চলে। তাই laptop-টিকেই চালু রাখতে হয়।

VPS এই সমস্যার বিপরীত দিক থেকে শুরু হয়। এতে একটি public IPv4 address এবং সাধারণত একটি public IPv6 address থাকে। আপনি শুধু যেসব port খুলবেন, সেগুলোই ব্যবহারের জন্য উন্মুক্ত থাকবে। VPS-এর দিকে একটি A record নির্দেশ করুন, 80 এবং 443 অনুমতি দিন, তাহলেই এটি যেকোনো স্থান থেকে response দেবে। Public certificate পাওয়ার জন্যও এটি প্রয়োজনীয়। কারণ HTTP-01 challenge-এ Let's Encrypt-কে public name-এর port 80 দিয়ে একটি file fetch করতে হয়। Certbot ও nginx দিয়ে Let's Encrypt certificate পাওয়া server-এ পাঁচ মিনিটের কাজ, কিন্তু WSL-এ অসম্ভব। Local কাজের জন্য আপনি Ubuntu trust store-এ নিজের CA যোগ করে WSL-এর ভেতরে browser-trusted HTTPS চালু করতে পারেন।

/mnt/c-এ git ধীর কেন?

কারণ ফাইলগুলো Linux filesystem-এ নেই। WSL আপনাকে খরচের দিক থেকে খুব ভিন্ন দুটি storage area দেয়। আপনার home directory একটি virtual disk-এর ভেতরের ext4 filesystem-এ থাকে এবং সাধারণ Linux disk-এর মতো কাজ করে। /mnt/c হলো Windows drive, যা Windows side-এর একটি component Plan 9 filesystem protocol (9P protocol)-এর মাধ্যমে পরিবেশন করে। তাই প্রতিটি open এবং প্রতিটি stat ওই boundary অতিক্রম করে।

একটি ফাইল নিয়ে সমস্যা হয় না। git status-এর মতো বড় repository হাজার হাজার stat call করে, এবং প্রতিটি call-এ boundary অতিক্রমের খরচ হয়। কারও দেওয়া সংখ্যা, এমনকি এই পৃষ্ঠার সংখ্যার ওপর নির্ভর না করে নিজেই মাপুন:

cd /mnt/c/Users/you/code/myrepo && time git status
cp -r /mnt/c/Users/you/code/myrepo ~/myrepo
cd ~/myrepo && time git status

প্রতিটি command দুবার চালান এবং দ্বিতীয়বারের ফল তুলনা করুন, যাতে উভয় run warm থাকে। Windows-এর real-time antivirus scanning /mnt/c side-এ অতিরিক্ত খরচ যোগ করে। তাই একই repository ব্যক্তিগত laptop-এর তুলনায় company laptop-এ ধীর মনে হতে পারে।

WSL-এর ভেতরের সমাধান হলো working copy ~-এর অধীনে রাখা এবং editor-এর WSL remote mode ব্যবহার করে সেটি খোলা। এতে editor server distribution-এর ভেতরেই চলে এবং boundary অতিক্রম করে না। Explorer এখনও \\wsl.localhost\Ubuntu\home\you-এ ওই ফাইলগুলো browse করতে পারে। VPS-এ এই সমস্যা নেই, কারণ সেখানে একটি filesystem-ই আছে এবং সেটি Linux। সেখানে যে খরচ হয়, তা হলো edit করার সময় network latency। তাই অনেকে terminal multiplexer অথবা remote editor session ব্যবহার করেন। ছোট server-এ shared CPU একটি বাস্তব সীমাবদ্ধতা। ব্যস্ত প্রতিবেশীর কারণে steal time top-এ st column হিসেবে দেখা যায়।

যেখানে WSL স্পষ্টভাবে এগিয়ে

• এটি বিনামূল্যে এবং মেশিনে আগে থেকেই থাকে। এটি চালু করুন, Ubuntu install করুন, এবং এক মিনিটের মধ্যে কাজ শুরু করুন। কোনো খরচ নেই, আর সুরক্ষার জন্য কোনো public surface-ও নেই।
• Server-এর মতো এটি স্থায়ী নয়; প্রয়োজনে সহজে বাদ দেওয়া যায়। wsl --export Ubuntu D:\wsl-backups\ubuntu.tar সম্পূর্ণ distribution-টি একটি file-এ লেখে, আর wsl --import সেটি restore করে বা দ্বিতীয় নামে clone করে। এখানে নতুন Ubuntu release পরীক্ষা করা মানে clone তৈরি করা এবং প্রয়োজনে rollback করা। কিন্তু 24.04 থেকে 26.04-এ VPS upgrade করা একমুখী পরিবর্তন; VPS-এ চলমান service-গুলোর সময়সূচির সঙ্গে মিলিয়ে এটি করতে হয়।
• GPU-ভিত্তিক কাজ সরাসরি করা যায়। বর্তমান Windows GPU driver থাকলে distribution-এর ভেতরেই card-টি ব্যবহার করা যায়। ফলে আপনার নিজের hardware-এ CUDA এবং ROCm workload চালানো সম্ভব। একই শ্রেণির GPU প্রতি ঘণ্টায় ভাড়া নিলে বাস্তব খরচ হয়।
• Editing loop ছোট হয়। আপনার file এবং browser দুটিই local থাকে। তাই localhost:5173-এ চলা dev server আপনি যে browser-এ ইতিমধ্যে signed in আছেন, সেখানেই খুলতে পারেন।

এগুলো বাস্তব সুবিধা। তাই সাধারণত একটি মেশিনের বদলে দুই মেশিন ব্যবহারের পরামর্শ দেওয়া হয়।

ব্যাকআপের মালিক কে?

দুই মেশিনের ক্ষেত্রেই দায়িত্ব আপনার। WSL-এর ক্ষেত্রে এই বিষয়টি অনেকের কাছেই বিস্ময়কর। Distribution একটি virtual disk file (ext4.vhdx), যা আপনার Windows user profile-এর ভিতরে থাকে। কোনো provider আপনার হয়ে এর snapshot তৈরি করে না। wsl --unregister Ubuntu কোনো undo ছাড়াই এটি মুছে দেয়, এবং Windows reinstall হলে অন্যান্য সবকিছুর সঙ্গে এটিও মুছে যায়। আপনি বাস্তবে যে schedule মেনে চলবেন, সেই schedule অনুযায়ী এটি export করুন:

wsl --export Ubuntu D:\wsl-backups\ubuntu-2026-08-18.tar

VPS-এ provider snapshot আপনাকে host নষ্ট হয়ে যাওয়ার পরিস্থিতি থেকে সুরক্ষা দেয়। কিন্তু এটি ভুল directory-তে থাকা rm -rf থেকে সুরক্ষা দেয় না। একই account-এ server-এর সঙ্গে রাখা snapshot একটি চুরি হওয়া login-এর কারণে server-এর সঙ্গেই হারিয়ে যেতে পারে। File-level backup server-এর বাইরে পাঠান এবং প্রয়োজন হওয়ার আগেই অন্তত একটি backup restore করে পরীক্ষা করুন। দুই ক্ষেত্রেই দায়িত্ব আপনার। বাস্তব পার্থক্য হলো, server কাউকে laptop চালু রাখতে না বলেই 03:00-এ নিজে তার backup পাঠাতে পারে।

সেতু: WSL থেকে VPS-এ SSH

সংযোগ সঠিকভাবে সেট আপ না করা পর্যন্ত দ্বিতীয় মেশিন ব্যবহার করা ঝামেলার মনে হয়। WSL-এর ভিতরে এটি একবার করুন।

Windows পাশে নয়, distribution-এর ভিতরে key তৈরি করুন। এতে private key Unix permission-সহ ext4 filesystem-এ থাকে, যা ssh গ্রহণ করে:

ssh-keygen -t ed25519 -C "dev@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

Ed25519 key ছোট এবং দ্রুত। ssh-copy-id server-এর ~/.ssh/authorized_keys-এ public key সঠিক mode-সহ যোগ করে। পরে key rotate ও revoke করার জন্য SSH key management-এর মূল বিষয় দেখুন।

~/.ssh/config-এ server-এর একটি নাম দিন:

Host dev
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ForwardAgent yes
  ServerAliveInterval 30

এখন ssh dev সংযোগ করে। IdentitiesOnly yes client-কে তার কাছে থাকা প্রতিটি key offer করা বন্ধ করে। agent-এ একাধিক key loaded থাকলে Too many authentication failures সাধারণত এভাবেই তৈরি হয়। ServerAliveInterval 30 home connection ব্যবহার করে চলা session-কে কোনো message ছাড়াই বন্ধ হয়ে যাওয়া থেকে রক্ষা করে।

ForwardAgent yes-ই workflow-টি সহজ করে। laptop-এর agent-এ key loaded থাকলে git clone git@github.com:you/app.git server-এ কাজ করে, কিন্তু কোনো private key সেখানে কখনো যায় না। VPS থেকে ssh -T git@github.com চালিয়ে এটি পরীক্ষা করুন। এর উত্তর Hi you! You've successfully authenticated হওয়া উচিত। শুধু বিশ্বস্ত server-এ agent forward করুন, কারণ আপনি সংযুক্ত থাকা অবস্থায় সেই machine-এর root আপনার agent socket ব্যবহার করতে পারে। অন্যদের সঙ্গে ভাগ করা server-এ প্রতি repository-র জন্য deploy key ব্যবহার করা নিরাপদ।

WSL shell-এর মধ্যে agent চালু রাখে না। তাই প্রতিটি নতুন terminal আবার key চায়। keychain এটি সমাধান করে:

sudo apt update && sudo apt install -y keychain
echo 'eval "$(keychain --eval --quiet id_ed25519)"' >> ~/.bashrc

নতুন shell খুলে ssh-add -l চালান। এতে key fingerprint দেখানো উচিত। Error connecting to agent-এর অর্থ হলো line-টি পড়া হচ্ছে না। তাই আপনার shell সত্যিই ~/.bashrc source করছে কি না পরীক্ষা করুন।

কাজটি server-এ terminal multiplexer-এর ভিতরে চালান। এতে connection বিচ্ছিন্ন হলেও কাজ বন্ধ হবে না:

tmux new -s dev
# Ctrl-b then d to detach
tmux attach -t dev

আপনি laptop বন্ধ করলেও build চলতে থাকবে। দ্বিতীয় machine ব্যবহারের মূল কারণ এটাই। একই পদ্ধতিতে মানুষ tmux-এ VPS-এ Claude Code চালায় এবং অন্য device থেকে session আবার চালু করে।

কোনো কিছু server-এ দেওয়ার আগে সেটিকে নিরাপদ করুন। নতুন VPS-এ প্রথম দশ মিনিট non-root user, key-only SSH, firewall এবং automatic security update সেট আপ করার ধাপ দেখায়। এতে এমন ক্রম অনুসরণ করা হয় যাতে আপনি server থেকে নিজেকেই lock out না করেন।

কোন কাজের জন্য কোন মেশিন?

কাজটি আপনার স্ক্রিনে থাকলে WSL ব্যবহার করুন। কোড সম্পাদনা, test suite চালানো, localhost-এ dev server, notebook, GPU experiment—আপনি যেসব কাজ শুরু করে পর্যবেক্ষণ করেন, সেগুলো এর মধ্যে পড়ে।

কাজটি অন্যদের কাছে পৌঁছানো দরকার হলে বা আপনার session শেষ হওয়ার পরও চালু থাকতে হলে VPS ব্যবহার করুন। যেমন, client যে staging URL খুলতে পারে, একটি webhook endpoint, বাস্তব clock অনুযায়ী চলা cron job, একটি bot, অন্য service যে small database-এর সঙ্গে যোগাযোগ করে, অথবা শুক্রবার বিকেলে শুরু করা কোনো import।

দ্বিতীয় মেশিনটি কী কাজে ব্যবহার করবেন, তা এখনও ঠিক না করলে মানুষ বাস্তবে VPS-এ যেসব কাজ চালায় specification তুলনার চেয়ে বেশি কার্যকর তালিকা। virtualisation-এর অভ্যন্তরীণ প্রক্রিয়া জানতে VPS কী দেখুন। আপনার tooling যদি শুধু Windows-এ চলে, সেটি আলাদা সিদ্ধান্ত; এর জন্য Windows Server-এর সঙ্গে Linux-এর তুলনা পৃষ্ঠাটি দেখুন।

একটি অভ্যাস দুই মেশিনকে অর্ধেক configured দুইটি মেশিনে পরিণত হওয়া ঠেকায়: code git-এ থাকে, এবং উভয় মেশিন repository-এর client হিসেবে কাজ করে। গুরুত্বপূর্ণ কোনো কিছু শুধু একটি মেশিনে থাকে না।

FAQ

বাস্তব domain দিয়ে WSL-এ কি website host করা যায়?

নির্ভরযোগ্যভাবে নয়। WSL 2 আপনার machine-এর ভেতরে NAT-এর পেছনে চলে, আপনার router আবার NAT চালায়, এবং অধিকাংশ home connection-এ forward করার মতো inbound port থাকে না। একটি tunnel service local port-কে বাইরে প্রকাশ করতে পারে, কিন্তু tunnel client laptop-এ চলে। তাই laptop sleep করলে site-ও বন্ধ থাকে। Certificate ব্যবস্থাপনায় সমস্যা আরও বাড়ে, কারণ HTTP-01 challenge-এর জন্য Let's Encrypt-কে public name-এর port 80 দিয়ে একটি file আনতে হয়। Public IP address এবং A record-সহ একটি VPS কোনো workaround ছাড়াই উভয় শর্ত পূরণ করে।

systemctl enable কি WSL-এ কাজ করে?

systemd চালু থাকলে এটি কাজ করে। এর জন্য /etc/wsl.conf-এর অধীনে [boot]-এ systemd=true চালিয়ে তারপর wsl --shutdown দিতে হয়। এটি না থাকলে systemctl, System has not been booted with systemd as init system (PID 1). Can't operate. উত্তর দেয়। systemd চললেও enable distribution চালু হলে service start করে, আর distribution চালু হয় যখন আপনি shell খোলেন। Server-এ একই command-এর অর্থ হলো কেউ login না করলেও reboot-এর পরে service আবার চালু হবে।

আমার WSL IP address কেন বারবার পরিবর্তিত হয়?

Default NAT mode-এ virtual machine প্রতিবার চালু হওয়ার সময় WSL virtual adapter থেকে নতুন private address পায়। ফলে কোনো netsh interface portproxy rule বা hard-coded address wsl --shutdown-এর পরে কাজ করা বন্ধ করে। বর্তমান address ip -4 addr show eth0 দিয়ে দেখুন। Windows 11-এর Mirrored networking mode distribution-কে Windows-এর একই interface দেওয়ার মাধ্যমে আলাদা address সরিয়ে দেয়: %UserProfile%\.wslconfig-এর অধীনে [wsl2]-এ networkingMode=mirrored সেট করুন।

/mnt/c কি সত্যিই ধীর, নাকি এটি একটি প্রচলিত ভুল ধারণা?

এটি ধীর। নিজের machine-এ এক মিনিট পরীক্ষা করলেই তা প্রমাণ হবে। ~-এর অধীনের file-গুলো ext4 virtual disk-এ থাকে। /mnt/c-এর অধীনের file-গুলো Windows-side component-এর মাধ্যমে 9P protocol-এ পরিবেশিত হয়। তাই প্রতিটি stat call boundary অতিক্রম করে, এবং git status একটি বড় tree-র ওপর হাজার হাজার এমন call তৈরি করে। Repository-টি ~-এ copy করুন, প্রতিটি location-এ time git status দুইবার চালান এবং দ্বিতীয়বারের run-এর ফল তুলনা করুন। Working copy ~-এর অধীনে রাখুন এবং আপনার editor-এর WSL remote mode ব্যবহার করুন।

VPS পাওয়ার পরও কি WSL প্রয়োজন?

অধিকাংশ মানুষ দুটিই ব্যবহার করেন। WSL বিনামূল্যে এবং তাৎক্ষণিকভাবে চালু হয়। তাই edit ও test করার জায়গা হিসেবে WSL-ই থাকে, আর GPU-সংক্রান্ত কাজও সেখানে করা হয়। Server হলো সব সময় চালু থাকা machine। এটি public name ধরে রাখে এবং laptop বন্ধ থাকলেও চলতে হবে এমন job চালায়। Code git-এ রাখুন এবং উভয় machine-কে repository-এর client হিসেবে ব্যবহার করুন। তাহলে একটির মধ্যে কাজ করে অন্যটিতে নেওয়ার জন্য কোনো অতিরিক্ত খরচ হয় না।