2026 میں self-host کرنے کے لیے 25 بہترین ایپس

آپ کیا تیار کر رہے ہیں

یہ ایک ایپ نہیں بلکہ مختصر فہرست ہے۔ یہ اس سائٹ پر موجود باقی تمام مواد کا مرکزی نقطۂ آغاز ہے: 2026 میں اپنے VPS پر واقعی چلانے کے قابل 25 ایپلی کیشنز، جنہیں ان کے کام کے مطابق گروپ کیا گیا ہے۔ ہر ایپ کے لیے آپ کو اس سے تبدیل ہونے والی service، RAM اور disk کی حقیقت پسندانہ ضرورت، اور وہ ایک اہم مسئلہ ملے گا جو اسے نظرانداز کرنے پر پیش آ سکتا ہے۔ جہاں مکمل مرحلہ وار رہنما موجود ہے، روابط اسی کی طرف لے جاتے ہیں۔

میں پندرہ سال سے VPS host چلا رہا ہوں، اور ان میں سے بیشتر ایپس اپنے سرورز پر چلاتا ہوں۔ اس لیے ذیل میں دیے گئے resource اعداد و شمار وہ ہیں جو ایپ چھوٹے مگر حقیقی workload کے دوران واقعی استعمال کرتی ہے، نہ کہ کسی marketing page پر دی گئی "minimum" ضرورت۔ انہیں بنیادی budget سمجھیں اور پھر اضافی گنجائش رکھیں۔

لازمیات اور حقیقی صورتِ حال

اس فہرست کی ہر ایپ root یا sudo کے ساتھ ایک نئے Ubuntu 24.04 KVM VPS پر چلتی ہے۔ یہی فہرست آپ کی اپنی الماری میں موجود سرور پر بھی اتنی ہی اچھی طرح چل سکتی ہے۔ اگر آپ ماہانہ کرایے کا موازنہ ایک بار RAM خریدنے سے کر رہے ہیں تو گھر پر Proxmox بمقابلہ کرائے کا VPS ہارڈویئر اور بجلی کے حساب کی وضاحت کرتا ہے۔ ان میں تقریباً سبھی Docker containers کے طور پر فراہم کی جاتی ہیں، اس لیے Docker ایک بار install کریں اور پوری فہرست کے لیے تیار ہو جائیں:

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
newgrp docker
docker run --rm hello-world

اگر docker commands، permission denied while trying to connect to the Docker daemon socket کے ساتھ fail ہوں تو آپ نے group والا مرحلہ چھوڑ دیا ہے یا نیا shell نہیں کھولا۔ log out کرکے دوبارہ log in کریں۔ اگر docker compose، docker: 'compose' is not a docker command واپس کرے تو آپ کے پاس پرانا standalone binary ہے۔ اوپر والا script جدید Compose plugin install کرتا ہے، جسے آپ docker compose کے طور پر چلاتے ہیں؛ یہاں space ہے، hyphen نہیں۔

ذیل کی تمام چیزوں کی ساخت تین حقائق طے کرتے ہیں۔ اول، رکاوٹ RAM ہے، disk یا CPU نہیں۔ 1 GB VPS صرف ایک چھوٹی ایپ چلا سکتا ہے، اس سے زیادہ نہیں۔ "چند چیزیں self-host کرنے" والے سرور کے لیے 4 GB حقیقی طور پر موزوں مقدار ہے۔ 2 GB ایک مشکل درمیانی حالت ہے۔ اس میں beginner تیسری service شامل کرتا ہے، خاموش Out-Of-Memory kill کا سامنا کرتا ہے، اور کبھی معلوم نہیں کر پاتا کہ container اچانک کیوں غائب ہو گیا۔ sudo dmesg میں وہ Out of memory: Killed process line دکھائی دیتی ہے جسے daemon نے نگل لیا تھا۔ دوم، ہر public سروس کے لیے نام اور certificate ضروری ہیں۔ سادہ IP testing کے لیے کام کرتا ہے، لیکن phone app یا browser کے لیے اس وقت ناکام ہو جاتا ہے جب آپ چاہتے ہیں کہ وہ اسے قابلِ اعتماد سمجھے۔ سوم، دو ports آپ کے نصف اختیارات طے کرتے ہیں: automatic TLS کے لیے 80 اور 443 کو سرور تک پہنچنا چاہیے، جبکہ زیادہ تر providers outbound 25 کو block کرتے ہیں۔ اسی وجہ سے آخر میں email کو "نہیں" والی فہرست میں رکھا گیا ہے۔

فائلیں اور تصاویر

• Nextcloud ایک ہی سوٹ میں Google Drive، Dropbox اور Google Calendar کی جگہ لیتا ہے۔ کم از کم 1–2 GB RAM مختص کریں، اس کے علاوہ آپ کی فائلوں کے لیے درکار storage بھی رکھیں۔ اہم بات یہ ہے کہ SQLite demo کے لیے مناسب، لیکن production میں مسئلہ بن سکتا ہے۔ اسے پہلے boot سے ہی PostgreSQL پر install کریں، کیونکہ data شامل ہونے کے بعد database migrate کرنا Nextcloud کو خراب کرنے کا سب سے عام طریقہ ہے۔ مکمل Docker، TLS اور backups کے ساتھ VPS پر Nextcloud guide اسے پہلی بار درست طریقے سے configure کرنے کا طریقہ بتاتی ہے۔
• Immich Google Photos کی جگہ لیتا ہے۔ اس میں وہ phone app بھی شامل ہے جو camera roll کو خودکار طور پر upload کرتی ہے، نیز faces اور objects کی search بھی موجود ہے۔ 6 GB RAM مختص کریں؛ Immich کی documentation اسے minimum قرار دیتی ہے، جبکہ 8 GB زیادہ آرام دہ ہے۔ machine-learning container سب سے زیادہ RAM استعمال کرتا ہے۔ disk space آپ کی library کے حجم کے برابر، اور thumbnails کے لیے تقریباً 20 فیصد اضافی ہونی چاہیے۔ اہم بات یہ ہے کہ Immich اب بھی releases کے درمیان breaking changes جاری کرتا ہے، اس لیے latest کو کبھی بھی آنکھ بند کر کے pull نہ کریں۔ version pin کریں اور ہر upgrade سے پہلے release notes پڑھیں۔ self-hosted Immich photo library guide محفوظ upgrade path بیان کرتی ہے۔ اگر 6 GB کی یہ minimum ضرورت آپ کے server کی صلاحیت سے زیادہ ہے تو PhotoPrism اور Immich کا ساتھ ساتھ جائزہ دونوں کا حقیقی memory استعمال، phone apps اور وہ backup commands کا موازنہ کرتا ہے جو library کو کسی ایک سروس میں منتقل کرنے سے پہلے درکار ہوتے ہیں۔
• Seafile تینوں میں سب سے تیز sync engine کے ساتھ Dropbox کی جگہ لیتا ہے۔ تقریباً 1 GB RAM مختص کریں۔ اہم بات یہ ہے کہ Seafile آپ کی فائلیں disk پر عام files کے طور پر نہیں بلکہ content-addressed blocks کے طور پر محفوظ کرتا ہے۔ اس لیے آپ ls کے ذریعے data browse نہیں کر سکتے، اور backup کسی folder کو copy کرنے کے بجائے Seafile کے اپنے tools کے ذریعے لینا ضروری ہے۔

پاس ورڈز

• Vaultwarden ایک مختصر Rust server ہے جو Bitwarden protocol استعمال کرتا ہے اور Bitwarden کے paid tier، LastPass اور 1Password کا متبادل فراہم کرتا ہے۔ اس لیے ہر official Bitwarden app اور browser extension براہِ راست کام کرتا ہے۔ 100–200 MB RAM مختص کریں؛ disk کی ضرورت تقریباً نہ ہونے کے برابر ہے۔ اہم بات یہ ہے کہ اس server میں آپ کے تمام passwords محفوظ ہوں گے، اس لیے یہاں TLS اور backups اختیاری نہیں بلکہ بنیادی ضرورت ہیں۔ ADMIN_TOKEN کو Argon2 hash کے طور پر set کریں، کیونکہ compose file میں plaintext token رکھنا master key کو cleartext میں محفوظ کرنے کے مترادف ہے۔ Vaultwarden password manager guide سے self-hosting کا آغاز کرنا بہترین انتخاب ہے۔

میڈیا

• Jellyfin Plex کی جگہ لیتا ہے اور آپ کی اپنی library کے لیے Netflix کا متبادل فراہم کرتا ہے۔ یہ مکمل طور پر open ہے، account کی ضرورت نہیں ہوتی، اور remote streaming کسی paywall کے پیچھے نہیں ہے۔ idle حالت میں 1–2 GB RAM مختص کریں، لیکن transcode کے دوران CPU کا استعمال اچانک بہت بڑھ سکتا ہے۔ اہم مسئلہ یہ ہے کہ 4K stream کو software transcoding کے ذریعے چلانے سے چھوٹا VPS شدید بوجھ کا شکار ہو سکتا ہے۔ یا تو سرور کو hardware acceleration دیں، یا فائلیں ایسے format میں رکھیں جسے clients براہِ راست چلا سکیں (Direct Play)۔ اس صورت میں سرور صرف bytes منتقل کرتا ہے۔ VPS پر Jellyfin media server کی گائیڈ اس فرق کی وضاحت کرتی ہے۔ سروس چلنے کے بعد، Halcyon اسی library کو browser میں 90s کی کرائے کی دکان جیسا بنا دیتا ہے۔ گھر کے افراد کو ہر چیز کے آگے scroll کرنے کے بجائے shelves براؤز کروانے کے لیے یہ میرے علم میں سب سے مضحکہ خیز اور مؤثر طریقہ ہے۔

• Navidrome آپ کی اپنی music library کے لیے Spotify کی جگہ لیتا ہے اور کسی بھی Subsonic-compatible app پر streaming فراہم کرتا ہے۔ 150–300 MB RAM مختص کریں۔ یہ Go میں لکھا گیا ہے اور وسائل کا استعمال تقریباً محسوس نہیں ہوتا۔ اہم مسئلہ یہ ہے کہ پہلی library scan کے دوران ہر file کے tags پڑھے جاتے ہیں، اور بڑی collection میں اس عمل کو ایک گھنٹہ لگ سکتا ہے۔ غلط ID3 tags کا نتیجہ خراب browsing experience کی صورت میں نکلتا ہے۔

• Audiobookshelf Audible اور آپ کی podcast app کی جگہ لیتا ہے اور مختلف devices پر playback position برقرار رکھتا ہے۔ 200–500 MB RAM مختص کریں۔ اہم مسئلہ یہ ہے کہ اسے ہر book کے لیے الگ folder والی سخت ساخت درکار ہوتی ہے۔ بے ترتیب import folder کے نتیجے میں library کا کچھ حصہ detect نہیں ہوتا اور باقی بھی غیر منظم رہتا ہے، جسے بعد میں درست کرنا مشکل ہوتا ہے۔

آٹومیشن اور AI

• n8n بصری workflow builder کے ذریعے Zapier اور Make کی جگہ لیتا ہے، جس کا کنٹرول آپ کے پاس رہتا ہے اور فی task billing نہیں ہوتی۔ 400 MB–1 GB RAM مختص کریں۔ اہم مسئلہ یہ ہے کہ n8n پہلی بار چلنے پر ایک key خود بناتا ہے اور محفوظ credentials کو اسی سے encrypt کرتا ہے۔ اگر یہ key ضائع ہو جائے، یا آپ N8N_ENCRYPTION_KEY سیٹ کیے بغیر اسے دوبارہ generate ہونے دیں، تو ہر saved credential ناقابلِ مطالعہ ہو جاتا ہے اور آپ کو سب credentials دوبارہ درج کرنے پڑتے ہیں۔ HTTPS کے ساتھ self-hosted n8n گائیڈ key کو مستقل رکھتی ہے اور webhook URLs کے سامنے ایک حقیقی certificate نصب کرتی ہے۔
• Ollama مقامی اور نجی LLM inference کے لیے ChatGPT subscription کی جگہ لیتا ہے۔ وسائل کا اندازہ model کے مطابق لگائیں: 7–8B model کے لیے تقریباً 8 GB RAM درکار ہوتی ہے، اور ہر model disk پر 4–8 GB لیتا ہے۔ اہم مسئلہ یہ ہے کہ صرف CPU والے VPS پر inference قابلِ اعتماد مگر سست ہوتا ہے۔ Hosted API سے ملنے والے فوری جوابات کے بجائے words per second کے حساب سے توقعات قائم کریں، یا GPU box کرائے پر لیں۔ LLM کو self-host کرنے کے لیے Ollama چلائیں گائیڈ میں حقیقت پسندانہ اعداد دیے گئے ہیں۔

مواصلات

• Rocket.Chat ٹیم کے لیے Slack کی جگہ استعمال ہوتا ہے اور اس میں threads، calls اور integrations شامل ہیں۔ کم از کم 2 GB RAM مختص کریں، کیونکہ یہ MongoDB پر چلتا ہے اور زیادہ وسائل اسی کو درکار ہوتے ہیں۔ اہم نکتہ یہ ہے کہ Rocket.Chat ہر release کے لیے MongoDB کی مخصوص major version مقرر کرتا ہے۔ Upgrade کے دوران کوئی version چھوڑنے سے database ناقابلِ استعمال ہو سکتا ہے۔ اس لیے ہر بار صرف ایک step upgrade کریں۔ Docker Compose کے ساتھ Rocket.Chat کی گائیڈ version ladder کی وضاحت کرتی ہے۔
• Matrix (Synapse) Slack اور Discord کی جگہ ایک federated، end-to-end-encrypted network فراہم کرتا ہے، جس میں homeserver آپ کے اپنے اختیار میں ہوتا ہے۔ 1–2 GB RAM مختص کریں؛ بڑے public rooms میں شامل ہونے کے ساتھ یہ ضرورت بڑھ سکتی ہے۔ اہم نکتہ یہ ہے کہ بڑے federated rooms میں Synapse کا memory استعمال بہت بڑھ جاتا ہے۔ اسے PostgreSQL پر چلانا ضروری ہے۔ default SQLite صرف single-user test کے لیے موزوں ہے اور federation شروع ہوتے ہی ناکام ہو جاتا ہے۔ اگر Synapse زیادہ وسائل استعمال کرے تو ہلکے Conduit یا Dendrite servers بھی یہی protocol استعمال کرتے ہیں۔

نیٹ ورکنگ اور رسائی

• WireGuard تجارتی VPN کی جگہ استعمال ہوتا ہے اور آپ کو اپنے IP اور دیگر سروسز تک ایک نجی tunnel فراہم کرتا ہے۔ وسائل کی ضرورت تقریباً نہ ہونے کے برابر ہے: 50 MB سے کم، جبکہ cryptographic عمل kernel میں چلتا ہے۔ مسئلہ یہ ہے کہ container-based virtualization، جیسے OpenVZ اور بعض LXC ماحول، میں module RTNETLINK answers: Operation not supported کے ساتھ fail ہو جاتا ہے؛ اس لیے KVM استعمال کریں۔ خود میزبان WireGuard VPN گائیڈ بنیادی حوالہ ہے۔ اسے tunnel سے bind کی گئی سروسز کے ساتھ استعمال کرنے سے سروسز کو مکمل طور پر public internet سے دور رکھا جا سکتا ہے۔ اگر آپ ہر نئے device کے لیے peer config خود edit نہیں کرنا چاہتے تو VPS پر Tailscale subnet router چلانا اس کے بجائے پوری private range آپ کی دیگر machines کے لیے advertise کرتا ہے۔ اس کے لیے route کو approve کریں اور IP forwarding کو reboot کے بعد بھی فعال رہنے کے لیے configure کریں۔
• Traefik ہاتھ سے لکھی گئی nginx virtual hosts اور manual certificate renewal کی جگہ استعمال ہوتا ہے۔ یہ Docker labels کے ذریعے آپ کے containers دریافت کرتا ہے اور Let's Encrypt certificates خودکار طور پر حاصل کرتا ہے۔ تقریباً 100 MB RAM مختص کریں۔ مسئلہ یہ ہے کہ label-based config model ابتدا میں واقعی پیچیدہ محسوس ہوتا ہے، اور ایک غلط label کسی app کو route کے بغیر چھوڑ دیتا ہے، جبکہ کوئی واضح error بھی ظاہر نہیں ہوتی۔ متعدد Docker apps کے لیے Traefik reverse proxy گائیڈ اسی مقصد کے لیے ہے کہ اس صفحے کی کئی apps کو ایک ہی entry point کے پیچھے چلایا جا سکے۔
• AdGuard Home Pi-hole box اور paid DNS filtering کی جگہ استعمال ہوتا ہے۔ یہ DNS layer پر آپ کے network کے ہر device کے لیے ads اور trackers کو block کرتا ہے۔ 100–150 MB RAM مختص کریں۔ مسئلہ یہ ہے کہ یہ port 53 اپنے استعمال میں لینا چاہتا ہے، جو Ubuntu پر systemd-resolved سے متصادم ہے؛ port پہلے خالی کیے بغیر یہ listen udp 0.0.0.0:53: bind: address already in use کے ساتھ start نہیں ہوتا۔

نگرانی

• Uptime Kuma صاف dashboard اور تقریباً ہر channel پر alerts کے ذریعے Pingdom، UptimeRobot اور StatusPage کا متبادل ہے۔ 150–300 MB RAM مختص کریں۔ اہم نکتہ، جسے لوگ ہمیشہ نظرانداز کرتے ہیں: اپنے production box کی نگرانی ایک مختلف box سے کریں۔ اسی server پر چلنے والا Uptime Kuma، جس کی وہ نگرانی کر رہا ہے، اس server کے بند ہونے کی اطلاع نہیں دے سکتا۔ Uptime Kuma status monitoring guide بیرونی placement کا طریقہ بیان کرتی ہے۔
• Zabbix گہرے agent-based metrics، triggers اور history کے ساتھ Datadog اور enterprise monitoring suites کا متبادل ہے۔ 2 GB RAM یا اس سے زیادہ مختص کریں، اور اس کے اپنے database کے لیے بھی وسائل درکار ہوں گے۔ اہم نکتہ: Zabbix طاقتور ہے اور اسے setup کرنا واقعی بھاری کام ہے۔ تین containers کی نگرانی کے لیے یہ ضرورت سے زیادہ ہے، لیکن servers کے بڑے مجموعے کے لیے درست tool ہے۔ Uptime Kuma سے شروع کریں؛ جب واقعی نگرانی کے لیے infrastructure موجود ہو تو Zabbix monitoring server کی طرف منتقل ہوں۔

Prometheus اور Grafana کو اس فہرست میں جان بوجھ کر شامل نہیں کیا گیا: یہ بڑے پیمانے کے fleet کے لیے بہترین tools ہیں، لیکن دو یا تین servers کے ذاتی stack کے لیے انہیں چلانے اور tune کرنے کا بوجھ ضرورت سے زیادہ ہے۔ اس scale پر Uptime Kuma اور Zabbix کم maintenance کے ساتھ وہی سوالات حل کر دیتے ہیں۔

ڈیش بورڈز اور کنٹرول پینلز

یہ پورے طریقۂ کار کو بدل دیتے ہیں۔ Compose فائلیں ہاتھ سے چلانے کے بجائے، پینل ایپس کا انتظام خود کرتا ہے۔

• Cloudron ایک بہتر app store، خودکار TLS اور built-in backups کے ذریعے اس خواہش کو پورا کرتا ہے کہ کاش یہ کام ایک کلک سے ہو جاتا۔ کم از کم 2 GB RAM مختص کریں؛ 4 GB پر یہ آرام سے چلتا ہے۔ مسئلہ یہ ہے کہ اس کی configuration رائے پر مبنی ہے اور یہ پورے server کا انتظام اپنے ہاتھ میں رکھنا چاہتا ہے۔ یہ صرف 2 ایپس تک free ہے؛ اس سے زیادہ کے لیے یہ paid product ہے۔
• CasaOS پیچیدہ homelab dashboard کی جگہ ایک آسان app grid فراہم کرتا ہے۔ یہ free اور lightweight ہے۔ خود CasaOS کے لیے تقریباً 150 سے 300 MB مختص کریں۔ مسئلہ یہ ہے کہ اسے trusted home network کے لیے ڈیزائن کیا گیا ہے اور public internet کے لیے hardened نہیں ہے۔ اسے براہ راست expose نہ کریں؛ WireGuard کے ذریعے access کریں۔
• Coolify آپ کے اپنے server پر Heroku، Vercel اور Netlify، git-push deployments، databases اور previews کا متبادل فراہم کرتا ہے۔ کم از کم 2 GB RAM مختص کریں۔ مسئلہ یہ ہے کہ یہ نسبتاً نیا project ہے اور تیزی سے تبدیل ہوتا ہے، اس لیے versions کو pin کریں اور upgrade سے پہلے release notes پڑھیں۔ Cloudron بمقابلہ CasaOS بمقابلہ Coolify کا تقابلی جائزہ واضح کرتا ہے کہ ان تینوں میں سے کون سا آپشن کس صارف کے لیے موزوں ہے۔

Developer اور productivity tools

• Gitea (یا Forgejo) نجی repositories، issues اور CI کے لیے GitHub کی جگہ لیتا ہے۔ تقریباً 200–500 MB RAM مختص کریں۔ اہم نکتہ: Forgejo، Gitea کا community-governed fork ہے اور اب بہت سے لوگ اسی کی سفارش کرتے ہیں؛ دونوں بہترین ہیں، لیکن ایک کا انتخاب کریں اور repositories اور database دونوں کا ایک ساتھ backup لیں، کیونکہ database کے بغیر repo backup میں ہر issue اور pull request ضائع ہو جاتی ہے۔
• Paperless-ngx filing cabinet اور paid document scanners کی جگہ لیتا ہے۔ یہ ہر چیز پر OCR چلا کر documents کو searchable بنا دیتا ہے۔ تقریباً 1 GB RAM مختص کریں، جبکہ OCR کے دوران CPU استعمال میں عارضی اضافہ ہو سکتا ہے۔ اہم نکتہ: OCR results آپ کے scans کے معیار جتنے ہی اچھے ہوں گے، اور بڑے archive کو دوبارہ process کرنا سست ہوتا ہے؛ دس سال کے کاغذات bulk-import کرنے سے پہلے اسے tune کریں۔
• Actual Budget تیز، local اور private envelope budgeting کے ذریعے YNAB اور Mint کی جگہ لیتا ہے۔ تقریباً 150 MB RAM مختص کریں۔ اہم نکتہ: automatic bank sync ایک الگ add-on ہے جس کی اپنی setup درکار ہوتی ہے، اس لیے out of the box آپ transactions manually import کرتے ہیں۔
• FreshRSS Feedly اور اب دستیاب نہ رہنے والے Google Reader کی جگہ لیتا ہے۔ یہ mobile apps کے ساتھ تیز اور private feed reader ہے۔ تقریباً 150 MB RAM مختص کریں۔ اہم نکتہ: cron-based feed refresh ترتیب دیں، ورنہ feeds صرف اس وقت update ہوں گی جب آپ اتفاقاً page کھولیں گے۔
• BookStack documentation کے لیے Notion اور Confluence کی جگہ لیتا ہے۔ اس میں content کو shelves، books اور pages کی صورت میں منظم کیا جاتا ہے۔ PHP اور MySQL پر تقریباً 500 MB RAM مختص کریں۔ اہم نکتہ: یہ content کو free-form notes کے بجائے اپنے مخصوص طریقے سے structure کرتا ہے۔ کچھ لوگوں کو یہ پسند آتا ہے، جبکہ کچھ اسے rigid سمجھتے ہیں؛ اپنی پوری wiki منتقل کرنے سے پہلے اسے آزمائیں۔
• Home Assistant SmartThings اور مختلف vendors کی درجنوں apps کی جگہ لیتا ہے اور آپ کے smart home کو locally یکجا کرتا ہے۔ تقریباً 1 GB RAM مختص کریں۔ اہم نکتہ: اس کی بہت سی سہولتوں کے لیے آپ کے devices تک local network access درکار ہوتا ہے، اس لیے یہ remote VPS کے بجائے گھر میں موجود hardware پر زیادہ فطری طور پر چلتا ہے۔ اگر ضروری ہو تو dashboard remotely چلائیں اور واپس bridge قائم کریں۔

ایک نمائندہ installation

اسے واضح کرنے کے لیے self-host کی مکمل ساخت یہ ہے: ایک compose file، ایک حقیقی certificate، اور ایک backup۔ یہ Uptime Kuma ہے، لیکن فہرست میں شامل ہر app اسی pattern کی پیروی کرتی ہے۔

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"
    restart: unless-stopped

docker compose up -d
docker compose logs -f

127.0.0.1: کو نوٹ کریں۔ app صرف localhost پر listen کرتی ہے، جبکہ Traefik یا nginx جیسا reverse proxy اس کے سامنے TLS termination کرتا ہے۔ براہ راست 0.0.0.0:3001 پر bind کرنے سے لوگ غیر ارادی طور پر ایک unencrypted admin panel پورے internet پر publish کر دیتے ہیں۔

ابھی کن چیزوں کو self-host نہیں کرنا چاہیے

• Email۔ یہ سب سے واضح معاملہ ہے۔ زیادہ تر VPS providers outbound port 25 کو block کرتے ہیں؛ آپ کو Connection timed out، telnet aspmx.l.google.com 25 سے نظر آئے گا، اور اسے درست کرنے کے لیے کچھ نہیں کیا جا سکتا کیونکہ یہ policy ہے۔ اگر port 25 کھلا بھی ہو تو fresh IP، جس کی کوئی reputation، PTR record، SPF، DKIM یا DMARC نہ ہو، آپ کی mail کو spam میں پہنچائے گا یا اسے براہِ راست reject کر دیا جائے گا۔ یہ ایک حقیقی اور مسلسل کام ہے، weekend کا کام نہیں۔ اگر آپ پھر بھی یہ کرنا چاہتے ہیں تو Mailcow کے ساتھ self-hosted email guide دیکھ کر صورتِ حال کو پوری طرح سمجھتے ہوئے شروع کریں، اور کئی ماہ تک deliverability کی مسلسل نگرانی کرنے کے لیے تیار رہیں۔
• ایسی کوئی بھی چیز جس کا قابلِ اعتماد backup اور restore نہ کیا جا سکے۔ اگر آپ نے کبھی test restore نہیں کیا تو آپ کے پاس backup نہیں، صرف امید ہے۔ ناقابلِ تلافی data، اپنی photos کی واحد copy یا اپنے accounts کسی service پر اس وقت تک نہ رکھیں جب تک اس کا restore کامیابی سے ثابت نہ ہو جائے۔
• کسی اہم dependency کی واحد copy۔ ایسا self-hosted DNS server جس کے crash ہونے پر آپ کے پورے network کا internet بند ہو جائے، پہلے project کے لیے برا انتخاب ہے۔ upstream fallback برقرار رکھیں۔
• Real-time safety systems۔ Home alarms، medical alerts اور ایسی ہر چیز، جہاں پانچ منٹ کا downtime بھی حقیقی مسئلہ ہو، ایسے hobby box پر نہیں ہونی چاہیے جسے آپ Sunday night کو upgrade کرتے ہوں۔

اپنی پہلی ایپ کا انتخاب اور دو لازمی اصول

ایسی ایپ منتخب کریں جو وہ بل ختم کرے جس سے آپ واقعی تنگ ہیں، یا ایسی privacy تشویش دور کرے جسے آپ حقیقتاً محسوس کرتے ہیں۔ عملی طور پر پہلی installation کے لیے بہترین انتخاب Vaultwarden اور Uptime Kuma ہیں: دونوں کم وسائل استعمال کرتی ہیں، فوراً مفید ثابت ہوتی ہیں، اور غلطی ہونے پر نسبتاً آسانی سے سنبھل جاتی ہیں۔ دوسری ایپ شامل کرنے سے پہلے ایک ایپ کو شروع سے آخر تک درست طور پر چلائیں: installation، certificate، backup، اور restore test مکمل کریں۔ آپ جو مہارت حاصل کر رہے ہیں وہ operations کی ہے، صرف install button دبانے کی نہیں۔

مندرجہ بالا ہر ایپ کے لیے دو چیزیں لازمی ہیں، کسی استثنا کے بغیر:

1. ہر public سروس پر TLS۔ صرف IP address پر چلنے والی plaintext سروس deployment نہیں بلکہ demo ہے۔ nginx پر Certbot اور Let's Encrypt کے ذریعے اس کے سامنے حقیقی certificate لگائیں، یا Traefik کو یہ کام خودکار طور پر کرنے دیں۔ پھر Ubuntu 24.04 پر SSH کے لیے Fail2ban کے ذریعے بیرونی رسائی کے دروازے کو مضبوط کریں۔
2. ایسے backups جنہیں آپ نے حقیقت میں restore کیا ہو۔ ہر رات dump خودکار بنائیں، database اور data volume دونوں کو ایک ساتھ شامل کریں، اسے اسی machine سے باہر بھیجیں، اور ماہ میں ایک بار اسے عارضی VPS پر restore کر کے ثابت کریں کہ یہ کام کرتا ہے۔ جس دن disk خراب ہو، وہ دن یہ دریافت کرنے کے لیے نامناسب ہے کہ backup خالی تھا۔

ان دونوں چیزوں کو درست طور پر نافذ کر لیں تو self-hosting خوش آئند تجربہ بن جاتی ہے۔ انہیں نظرانداز کریں تو مسئلہ پیدا ہونے تک وقت کی گنتی شروع ہو جاتی ہے۔

اختیارات عملی استعمال سے لے کر انتہائی غیر معمولی صورتوں تک پھیلے ہوئے ہیں: خاندان کے لیے VPS پر Minecraft server سے لے کر، اگر آپ کسی سبق آموز واقعے میں دلچسپی رکھتے ہوں، دنیا کے کم ترین مؤثر datacenter تک۔

FAQ

مجھے سب سے پہلے کیا self-host کرنا چاہیے؟

Vaultwarden۔ password manager روزمرہ فائدہ دیتا ہے، کسی subscription کی جگہ لے لیتا ہے، اور آپ کو پورا workflow سیکھنے پر مجبور کرتا ہے، جس میں Docker، reverse proxy، TLS اور backups شامل ہیں۔ یہ ایسی چھوٹی app ہے جسے خراب ہونے کی صورت میں دس منٹ میں دوبارہ بنایا جا سکتا ہے۔ Uptime Kuma دوسری بہترین choice ہے، کیونکہ اس سے آپ اپنے users سے پہلے outages کے بارے میں جان لیتے ہیں۔

مجھے حقیقت میں کتنے VPS کی ضرورت ہے؟

ایک چھوٹی app کے لیے 1 GB RAM کافی ہے۔ ایسی machine کے لیے جس پر آرام سے "چند چیزیں چلائی" جا سکیں، 4 GB کا ہدف رکھیں۔ 2 GB وہ درمیانی حد ہے جہاں لوگوں کو خاموشی سے ہونے والے Out-Of-Memory container kills کا سامنا ہوتا ہے اور وہ وجہ معلوم نہیں کر پاتے۔ عموماً اصل حد RAM ہوتی ہے؛ disk کی مقدار اس data کے مطابق رکھیں جسے آپ store کرنے کا ارادہ رکھتے ہیں۔ Immich، Ollama اور بڑی database والی apps سے توقع رکھیں کہ انہیں RAM اور disk، دونوں میں زیادہ وسائل درکار ہوں گے۔

مجھے کیا self-host نہیں کرنا چاہیے؟

سب سے پہلے email۔ زیادہ تر providers outbound port 25 کو block کرتے ہیں، اور email deliverability برقرار رکھنا مسلسل دشوار کام ہے۔ اس کے بعد ایسی ہر چیز سے گریز کریں جس کا قابلِ اعتماد backup اور restore نہ کر سکیں، اور ایسے ہر single point of failure سے بھی جس کے downtime سے حقیقی نقصان ہو سکتا ہے، مثلاً ایسا DNS server جس کا کوئی fallback نہ ہو یا گھر کا safety system۔ اس فہرست کی باقی ہر چیز self-host کرنے کے لیے مناسب ہے۔

کیا مجھے اس سب کے لیے Docker کی ضرورت ہے؟

نہیں، لیکن اسے استعمال کرنا بہتر ہے۔ یہاں ہر app کی Docker image موجود ہے، اور Docker صاف ستھری installation، آسان removal، version pinning اور نئے host پر portability فراہم کرتا ہے۔ چند apps، مثلاً WireGuard اور Zabbix، آپ کی ترجیح کی صورت میں apt سے native طور پر بھی install ہو جاتی ہیں۔ جب آپ ایک compose file سمجھ لیتے ہیں تو باقی سب بھی سمجھ آ جاتی ہیں۔ اسی لیے پوری فہرست قابلِ رسائی بن جاتی ہے۔

میں یہ سب محفوظ کیسے رکھوں؟

چار عادات زیادہ تر ضروریات پوری کر دیتی ہیں: ہر چیز کے سامنے TLS رکھیں؛ key-only login کے ساتھ SSH کو محدود رکھیں اور Fail2ban brute-force کوششوں کو block کرتا ہے؛ عوامی طور پر صرف وہ ports expose کریں جن کی واقعی ضرورت ہے، اور باقی تک اپنے WireGuard VPN کے ذریعے رسائی حاصل کریں؛ اور release notes پڑھتے ہوئے باقاعدگی سے update کریں تاکہ کوئی upgrade آپ کے لیے اچانک نہ ہو۔ Backups پانچویں عادت ہیں۔ جب پہلی چار احتیاطوں سے کوئی غلطی بچ نکلے تو recovery کے لیے یہی آپ کا ذریعہ ہوتے ہیں۔