VPS پر اپنی music library stream کرنے کا طریقہ

VPS پر self-hosted music streaming سے آپ کو کیا ملتا ہے

VPS پر self-hosted music streaming کا مطلب ہے کہ player آپ چلاتے ہیں اور music آپ فراہم کرتے ہیں۔ سرور پر وہ files محفوظ ہوتی ہیں جو آپ پہلے سے own کرتے ہیں، اور کوئی بھی phone عام login کے ذریعے internet پر ان تک رسائی حاصل کر سکتا ہے۔ شروع کرنے سے پہلے اس trade-off کو واضح طور پر سمجھ لیں: یہ streaming service کے player کی جگہ لیتا ہے، اس کے catalogue کی نہیں۔ آپ کی library میں کوئی نیا مواد اس وقت تک شامل نہیں ہوگا جب تک آپ اسے خرید نہ لیں یا rip نہ کر لیں، اور file کو سرور پر copy نہ کر دیں۔

Audio، video کے مقابلے میں سرور پر بہت کم بوجھ ڈالتا ہے۔ files چھوٹی ہوتی ہیں، phones ہر عام format کو اضافی مدد کے بغیر decode کر لیتے ہیں، اور ایک listener، video call کے مقابلے میں کم bandwidth استعمال کرتا ہے۔ یہاں CPU مسئلہ نہیں بنتا۔ اصل پابندی disk space ہے۔ مزید دو عوامل یہ طے کرتے ہیں کہ یہ setup مؤثر رہے گا یا نہیں: آپ کے tags کا معیار، اور یہ کہ آپ کی phone app music کو offline استعمال کے لیے download کر سکتی ہے یا نہیں۔

کون سا music server: Navidrome، Jellyfin یا Funkwhale؟

Navidrome اس وقت default انتخاب ہے جب آپ کو صرف audio کی ضرورت ہو۔ یہ ایک container میں ایک Go binary کے طور پر چلتا ہے اور اپنی state ایک SQLite database میں رکھتا ہے۔ یہ Subsonic API کو support کرتا ہے، اسی لیے third-party phone apps کی ایک بڑی ecosystem موجود ہے۔ August 2026 میں version 0.63.2 موجودہ version تھا۔ project کے مطابق یہ Raspberry Pi Zero جیسے کم وسائل والے hardware پر بھی اچھی طرح چلتا ہے، اس لیے server software وہ حصہ نہیں جس پر آپ کو خرچ کرنا پڑے گا۔

Jellyfin اس وقت موزوں ہے جب آپ پہلے ہی VPS پر Jellyfin کو media server کے طور پر چلا رہے ہوں۔ اس کی music library کام کرتی ہے، اور Finamp Android اور iOS کے لیے Jellyfin music app ہے جو offline listening کے لیے tracks download کرتی ہے۔ اس کی حد API ہے۔ Jellyfin میں built-in Subsonic endpoint نہیں ہے، اور اسے شامل کرنے والا community plugin 2022 میں update ہونا بند ہو گیا تھا، اس لیے Subsonic apps کی ecosystem اس کے لیے دستیاب نہیں۔ اس کے بجائے آپ کو وہ apps استعمال کرنی ہوں گی جو Jellyfin کی اپنی API سے بات کرتی ہیں، اور ایسی apps کم ہیں۔

Funkwhale federated اختیار ہے، اور version 2.0 March 2026 میں release ہوا۔ Funkwhale server کو pod کہا جاتا ہے، pods ActivityPub کے ذریعے federate کرتے ہیں، اور ایک pod کا user دوسرے pod کی public library کو follow کر سکتا ہے۔ یہ Subsonic API کے ایک حصے کو بھی support کرتا ہے، لیکن ایک فرق اہم ہے: ہر user اپنی settings میں الگ Subsonic password مقرر کرتا ہے، کیونکہ Subsonic protocol ایسے password کا تقاضا کرتا ہے جسے server واپس پڑھ سکے۔ Funkwhale کی installation زیادہ بھاری ہے، کیونکہ web app کے ساتھ PostgreSQL اور task queue بھی درکار ہوتے ہیں۔

Navidrome منتخب کریں، الا یہ کہ آپ کو federation درکار ہو یا Jellyfin پہلے سے چل رہا ہو۔ اس guide کے باقی حصے میں Docker کے ساتھ Navidrome setup کیا جائے گا۔

فون پر ملنے والی ایپ کا فیصلہ Subsonic API کیسے کرتی ہے

Subsonic ایک music server تھا جس کی HTTP API self-hosted audio کے لیے مشترکہ زبان بن گئی، اور OpenSubsonic وہ community project ہے جو اسے مسلسل توسیع دے رہا ہے۔ اسی تاریخ کی وجہ سے آپ کے فون کے لیے کئی اختیارات موجود ہیں۔ Navidrome اپنی mobile app فراہم نہیں کرتا اور اسے اس کی ضرورت بھی نہیں، کیونکہ ہر Subsonic client server address اور آپ کے account details کے ذریعے login کرتا ہے۔

یہ بات offline sync کے لیے سب سے زیادہ اہم ہے، کیونکہ یہی feature طے کرتا ہے کہ یہ setup روزمرہ استعمال میں قابلِ اعتماد رہے گا یا نہیں۔ tunnel میں موجود فون آپ کے server تک نہیں پہنچ سکتا، اس لیے client کو پہلے ہی files مقامی storage میں copy کرنی ہوں گی۔ ہر client streaming کرتا ہے۔ صرف کچھ clients download بھی کرتے ہیں۔ navidrome.org/apps پر موجود client directory بتاتی ہے کہ کون سے clients یہ کام کرتے ہیں، اور دونوں platforms پر انتخاب وسیع ہے: Android پر Substreamer اور Ultrasonic، جبکہ iOS پر Amperfy اور play:Sub۔ کئی بہترین clients paid apps ہیں، اور Android پر Symfonium کا نام سب سے زیادہ لیا جاتا ہے۔ فیصلہ کرنے سے پہلے دو clients install کریں، کیونکہ system کا یہی حصہ آپ ہر روز استعمال کریں گے۔

موسیقی لائبریری کے لیے کتنی storage درکار ہوتی ہے؟

[
  {
    "label": "Opus 128k",
    "kbps": 128,
    "gb_per_1000_albums": 43
  },
  {
    "label": "MP3 320k",
    "kbps": 320,
    "gb_per_1000_albums": 108
  },
  {
    "label": "FLAC 16/44.1",
    "kbps": 900,
    "gb_per_1000_albums": 304
  },
  {
    "label": "FLAC 24/96",
    "kbps": "3,000",
    "gb_per_1000_albums": "1,013"
  }
]

یہ اعداد حقیقی مجموعے کی پیمائش نہیں بلکہ bitrate سے اخذ کردہ order of magnitude اعداد ہیں، اور حساب اتنا آسان ہے کہ آپ اپنی فائلوں سے اس کی تصدیق کر سکتے ہیں۔ ایک album کو 45 منٹ، یعنی 2,700 seconds، تصور کریں۔ bitrate کو kilobits per second میں 2,700 سے ضرب دیں، پھر megabytes حاصل کرنے کے لیے 8,000 پر تقسیم کریں۔ 320 kbps پر ایک album کے لیے 108 MB درکار ہوتے ہیں، اس لیے ایک ہزار albums تقریباً 108 GB ہوں گے۔

Lossless format سے جواب بدل جاتا ہے۔ عام مواد میں CD quality FLAC کا اوسط تقریباً 900 kbps ہوتا ہے، اس لیے انہی ایک ہزار albums کے لیے تقریباً 304 GB درکار ہوں گے۔ 24 bit، 96 kHz لائبریری کا حجم تقریباً 1,013 GB تک پہنچ جاتا ہے، یعنی ایسے مجموعے کے لیے پورا terabyte جس کی فہرست کاغذ پر لکھی جا سکتی ہے۔ فون کے لیے موزوں 128 kbps Opus copy انہی ایک ہزار albums کو 43 GB میں رکھتی ہے۔ اپنی موجودہ لائبریری پر du -sh /path/to/music چلائیں، کیونکہ plan منتخب کرتے وقت اہم واحد عدد آپ کا اپنا average bitrate ہوتا ہے۔

Bandwidth لاگت کا نسبتاً چھوٹا حصہ ہے۔ 320 kbps stream کی رفتار 40 kilobytes per second ہوتی ہے، اس لیے ایک گھنٹے کی listening سے تقریباً 144 MB منتقل ہوتا ہے۔ ایک مہینے میں سو گھنٹے کی listening تقریباً 14 GB بنتی ہے، جسے کوئی VPS transfer allowance محسوس نہیں کرتا۔ استثنا فون کی پہلی offline sync ہے، جو ایک ہی شام میں دسیوں gigabytes منتقل کر سکتی ہے۔

اسٹوریج ٹئیر یا کمپیوٹ ٹئیر؟

میوزک سرور بڑی مقدار میں cold data رکھتا ہے اور اس پر تقریباً کوئی computation نہیں ہوتی۔ 40 kilobytes per second کی رفتار سے فائل پڑھنے پر کوئی بھی disk idle رہتی ہے، جبکہ CPU صرف library scan یا transcoding کے دوران کام کرتا ہے، اور آپ عموماً یہ کام نہیں کریں گے۔ اس لیے compute plan کا تیز NVMe یہاں آپ کو کوئی فائدہ نہیں دیتا، جبکہ اس کی فی gigabyte قیمت ہی وہ وجہ بنتی ہے جو آپ کو FLAC copies upload کرنے سے روکتی ہے۔ یہ وہ صورت ہے جس میں storage VPS باقاعدہ VPS سے بہتر ہے، کیونکہ ان plans کی قیمت core کے بجائے terabyte کے حساب سے مقرر ہوتی ہے۔

Memory کی ضرورت محدود ہے۔ Navidrome چند سو megabytes میں ذاتی library فراہم کر دیتا ہے، اور scan کے دوران استعمال peak پر ہوتا ہے، playback کے دوران نہیں۔ مشین کو 1 GB یا 2 GB RAM دیں اور باقی بجٹ disk پر خرچ کریں۔

Docker Compose کے ساتھ Navidrome انسٹال کریں

پہلے directories بنائیں اور ان کی ownership اس user id کو دیں جس کے تحت container چلے گا۔ اگر Compose آپ کے لیے نیا ہے تو VPS پر Docker Compose میں اس file کے مفروضوں کی وضاحت موجود ہے۔

sudo install -d -m 755 -o 1000 -g 1000 /srv/navidrome /srv/music

docker-compose.yml کو اپنے directory میں لکھیں، اور وہاں تقریباً کوئی دوسری چیز نہ رکھیں:

services:
  navidrome:
    image: deluan/navidrome:0.63.2
    user: "1000:1000"
    ports:
      - "127.0.0.1:4533:4533"
    restart: unless-stopped
    environment:
      ND_LOGLEVEL: "info"
      ND_SESSIONTIMEOUT: "24h"
      ND_SCANNER_SCHEDULE: "@every 24h"
      ND_BACKUP_PATH: "/data/backup"
      ND_BACKUP_SCHEDULE: "0 4 * * *"
      ND_BACKUP_COUNT: "7"
    volumes:
      - /srv/navidrome:/data
      - /srv/music:/music:ro

docker compose up -d
docker compose ps

docker compose ps میں service کی حالت running ہونی چاہیے، restarting نہیں۔ مسلسل restart ہونے والا container تقریباً ہمیشہ /srv/navidrome پر permissions کے مسئلے کی نشاندہی کرتا ہے، اور docker compose logs navidrome اس file کا نام بتاتا ہے جسے وہ لکھ نہیں سکا۔

اس file کی چار تفصیلات قابلِ وضاحت ہیں۔ port صرف 127.0.0.1 پر publish کیا گیا ہے، اس لیے server reverse proxy کے ذریعے قابلِ رسائی ہے اور open internet سے port 4533 پر براہِ راست دستیاب نہیں۔ Docker اپنے firewall rules خود لکھتا ہے، اس لیے سادہ 4533:4533 ایسے server پر بھی exposed رہتا ہے جہاں ufw ہر چیز کو denied ظاہر کرتا ہے۔ Music volume read-only ہے، جس کا مطلب ہے کہ scanner میں موجود bug آپ کی واحد copy حذف نہیں کر سکتا۔ ND_SCANNER_SCHEDULE by default disabled ہے، اور Navidrome 0.55 سے پہلے لکھی گئی guides اسے ND_SCANSCHEDULE کہتی ہیں؛ یہ نام اب موجود نہیں ہے۔ Backup کی تین settings built-in database backup کو فعال کرتی ہیں، جس پر ذیل کا backup section انحصار کرتا ہے۔

اپنی موسیقی سرور پر منتقل کریں

rsync کے ذریعے library کو سرور پر copy کریں۔ اگر connection منقطع ہو جائے تو یہ دوبارہ شروع سے کام کرنے کے بجائے وہیں سے جاری رہتا ہے۔

rsync -av --info=progress2 ~/Music/ user@music.example.com:/srv/music/

source کے آخر میں موجود slash اہم ہے۔ اس کے بغیر آپ کو /srv/music/Music ملتا ہے۔ copy مکمل ہونے کے بعد ownership درست کریں:

sudo chown -R 1000:1000 /srv/music
id -u

container user id 1000 کے طور پر چلتا ہے، اور mount صرف read-only ہے۔ اس لیے ہر file اس id کے لیے readable ہونی چاہیے۔ اگر VPS پر آپ کے SSH account کا uid 1000 نہیں ہے تو copy کسی دوسرے user کی ownership میں محفوظ ہوگی۔ اس صورت میں scan کو کوئی track نہیں ملے گا، جبکہ web interface خالی دکھائی دے گا۔ id -u آپ کا حقیقی id دکھاتا ہے، اور Docker containers میں PUID اور PGID کیسے کام کرتے ہیں اس mapping کی مکمل وضاحت کرتا ہے۔

فون ہر جگہ سے کام کرنے کے لیے reverse proxy اور TLS

VPS کی طرف DNS A record point کریں، پھر Caddy کو یہ تین لائنیں دیں:

music.example.com {
    reverse_proxy 127.0.0.1:4533
}

sudo systemctl reload caddy

Caddy پہلی request پر certificate حاصل کرتا ہے۔ Ports 80 اور 443 دونوں کھلے ہونے چاہییں، کیونکہ ACME (خودکار certificate management environment) challenge کا جواب port 80 پر دیا جاتا ہے۔ nginx میں location block میں proxy_buffering off; شامل کریں: Navidrome ایک طویل عرصے تک قائم رہنے والے connection کے ذریعے web interface کو progress events بھیجتا ہے۔ Buffering فعال ہونے پر interface انتظار کرتا رہتا ہے، کیونکہ nginx response کو اپنے پاس روکے رکھتا ہے۔ اگر آپ اسے اپنے subdomain کے بجائے /music جیسی path کے تحت serve کرتے ہیں تو ND_BASEURL کو بھی اسی path پر set کریں، ورنہ interface خالی صفحے کے طور پر load ہوگا۔ تین عام proxies کا موازنہ VPS پر Nginx، Caddy اور Traefik میں کیا گیا ہے۔

site کھولیں اور پہلا account بنائیں۔ کوئی default password نہیں ہوتا۔ پہلے visitor سے admin user بنانے کو کہا جاتا ہے، اس لیے address کسی اور کو بتانے سے پہلے یہ کام کریں۔ پھر وہ exact path test کریں جسے phone client استعمال کرتا ہے:

SALT=$(openssl rand -hex 6)
TOKEN=$(printf '%s%s' 'YOUR_PASSWORD' "$SALT" | md5sum | cut -d' ' -f1)
curl -s "https://music.example.com/rest/ping.view?u=YOUR_USER&t=$TOKEN&s=$SALT&v=1.16.1&c=curl&f=json"

درست جواب {"subsonic-response":{"status":"ok" سے شروع ہوتا ہے اور server type کے طور پر navidrome کا نام دیتا ہے۔ اگر body میں "status":"failed" اور error code 40 موجود ہو تو proxy درست کام کر رہا ہے اور credentials غلط ہیں۔ اس مرحلے پر certificate error کو پہلے درست کریں، کیونکہ زیادہ تر phone clients خراب certificate مسترد کر دیتے ہیں اور صارف کو ایسی message دکھاتے ہیں جس سے مسئلے کی وجہ معلوم نہیں ہوتی۔

پہلا scan مکمل ہونے کے بعد آپ کی library غلط کیوں دکھائی دیتی ہے

Navidrome فولڈرز کے بجائے tags کے ذریعے براؤز کرتا ہے، اس لیے آپ کو جو کچھ دکھائی دیتا ہے اس کا فیصلہ tags کرتے ہیں۔ جس track میں album artist tag نہ ہو، اسے اس کے track artist کے تحت درج کیا جاتا ہے۔ اسی وجہ سے ہر track پر مختلف artist رکھنے والی ایک compilation، ایک ایک track والے بیس albums میں تبدیل ہو جاتی ہے۔ یہ مسئلہ Navidrome میں نہیں بلکہ files میں درست کریں: MusicBrainz Picard اور beets دونوں MusicBrainz database میں album تلاش کرتے ہیں اور standard tags واپس files میں لکھتے ہیں۔

Navidrome ایک multi artist tag کو الگ الگ artists میں بھی تقسیم کرتا ہے۔ اس لیے جس band کے نام میں separator شامل ہو، وہ غلطی سے تقسیم ہو جاتا ہے۔ AC/DC اس مسئلے کی عام مثال ہے۔ ND_SCANNER_ARTISTSPLITEXCEPTIONS میں وہ نام شامل ہیں جنہیں کبھی تقسیم نہیں کیا جانا چاہیے۔

نئی files شامل ہونے کے چند seconds بعد file watcher انہیں تلاش کر لیتا ہے۔ watcher کا انحصار kernel change notifications پر ہوتا ہے، لیکن کسی دوسری machine سے mounted network share پر لکھی گئی files کے لیے یہ notifications موصول نہیں ہوتیں۔ اس طرح کے setup میں periodic ND_SCANNER_SCHEDULE ہی library کو تازہ رکھتا ہے۔ full rescan ہر file کے tags پڑھتا ہے، جو بڑی library میں سست عمل ہے۔ اسی لیے نیچے دیے گئے database کو محفوظ رکھنا ضروری ہے۔

صارفین، پلے لسٹس اور اشتراک

ایڈمن web interface میں دیگر accounts بناتا ہے، اور self signup دستیاب نہیں ہوتا۔ ہر user کے play counts، playlists، favourites اور ratings الگ ہوتے ہیں، اس لیے گھر کے تمام افراد کا taste profile مشترک نہیں بنتا۔

Playlists دو طریقوں سے آتی ہیں۔ client میں بنائی گئی playlist database میں محفوظ ہوتی ہے۔ library folder میں رکھی گئی .m3u file scan کے دوران import ہو جاتی ہے۔ Desktop player سے playlists منتقل کرنے کا یہ آسان طریقہ ہے۔ Smart playlists .nsp files ہوتی ہیں۔ یہ چھوٹی JSON rule files ہیں جو اسی طریقے سے import ہوتی ہیں، اور library تبدیل ہونے پر خودکار طور پر update ہو جاتی ہیں۔

Sharing version 0.63.0 سے by default enabled ہے، جو July 2026 میں released ہوا تھا۔ اس سے user کسی album کا public link بنا سکتا ہے جسے کوئی بھی شخص login کیے بغیر کھول سکتا ہے۔ مکمل library رکھنے والے server پر شاید آپ یہ نہ چاہتے ہوں، اور ND_ENABLESHARING کو false پر set کرنے سے یہ feature بند ہو جاتا ہے۔

موسیقی کی فائلوں سے الگ database کا backup لیں

Navidrome کا اپنا backup صرف database کا احاطہ کرتا ہے۔ documentation اس بارے میں واضح ہے: backup process database، یعنی users، play counts اور دیگر متعلقہ data کا backup لیتا ہے، لیکن music یا config کا نہیں۔ اس تقسیم کو سمجھنے کا یہی درست طریقہ ہے، کیونکہ دونوں حصے مختلف انداز میں ناکام ہوتے ہیں۔ Music files کو اس disk سے دوبارہ copy کیا جا سکتا ہے جس سے آپ نے انہیں rip کیا تھا۔ Play counts، ratings، favourites اور playlists کہیں اور موجود نہیں ہوتیں، اور rescan انہیں واپس نہیں لاتا۔

compose file پہلے ہی رات کے وقت ایک copy /data/backup میں لکھتی ہے اور اس کی سات copies رکھتی ہے۔ upgrade سے پہلے ایک copy دستی طور پر بنائیں:

sudo docker compose run --rm navidrome backup create

Restore موجودہ database کو حذف کر کے backup کو اس کی جگہ copy کرتا ہے، اور یہ عمل Navidrome کے stopped ہونے کے دوران چلانا ضروری ہے۔ Live server پر restore محفوظ نہیں ہوتا۔

یہ files اب بھی اسی VPS پر موجود رہتی ہیں، اس لیے VPS کے ساتھ یہ بھی ضائع ہو سکتی ہیں۔ مقررہ schedule کے مطابق /srv/navidrome کو کسی دوسری machine یا object storage پر push کریں۔ یہی کام restic اور BorgBackup کے لیے بنائے گئے ہیں۔ پوری directory چھوٹی ہوتی ہے، عموماً ایک gigabyte سے کافی کم۔ اس لیے box سے باہر روزانہ encrypted copy رکھنے کی لاگت تقریباً نہ ہونے کے برابر ہے، اور اس سے وہ تمام data واپس مل سکتا ہے جسے rescan واپس نہیں لا سکتا۔

FAQ

کیا VPS پر موسیقی کو دوبارہ encode کرنا ضروری ہے؟

تقریباً کبھی نہیں۔ فون اور browsers خود MP3، AAC، Opus اور FLAC کو decode کر لیتے ہیں، اس لیے server فائل کو اسی حالت میں بھیجتا ہے اور CPU کا استعمال تقریباً نہیں ہوتا۔ اسے فعال کرنے کی ایک قابلِ غور صورت یہ ہے: mobile data پر FLAC library stream کی جائے، جہاں تقریباً 900 kbps سے Opus پر 128 kbps میں تبدیل کرنے سے استعمال ہونے والا data تقریباً سات گنا کم ہو جاتا ہے۔ Navidrome یہ کام ہر user اور ہر player کے لیے الگ کر سکتا ہے، اور جب تک آپ اسے فعال نہ کریں، یہ بند رہتا ہے۔

میری phone app offline listening کے لیے موسیقی download کیوں نہیں کر سکتی؟

کیونکہ offline storage client کی خصوصیت ہے، server کی نہیں۔ Subsonic API ہر client کو پوری فائل fetch کرنے کی اجازت دیتی ہے، لیکن فون پر اس کی copy محفوظ رکھنی ہے یا نہیں، یہ app طے کرتی ہے۔ navidrome.org/apps پر client directory دیکھیں اور ایسا client منتخب کریں جس کی description میں offline downloads یا caching کا ذکر ہو۔ کچھ clients صرف وہی مواد cache کرتے ہیں جسے آپ پہلے چلا چکے ہوں۔ یہ سفر سے پہلے پورا album sync کرنے کے برابر نہیں ہے۔

scan کے بعد ایک album کئی albums میں کیوں تقسیم ہو گیا؟

Tracks میں album artist tag موجود نہیں ہے یا مختلف ہے۔ Navidrome folder کے بجائے tags کی بنیاد پر grouping کرتا ہے، اس لیے بارہ tracks میں بارہ مختلف artist values ہوں اور کوئی مشترک album artist value نہ ہو تو وہ بارہ albums دکھائی دیں گے۔ Album کے ہر track پر album artist tag درج کریں۔ Compilation کے لیے عموماً اسے Various Artists رکھیں، پھر دوبارہ scan چلائیں۔ MusicBrainz Picard یا beets یہ کام ایک پورے folder کے لیے بیک وقت کر سکتے ہیں۔

کیا self-hosted music streaming، Spotify کی جگہ لے سکتی ہے؟

یہ player اور library کی جگہ لیتی ہے، catalogue کی نہیں۔ آپ کو ہر device پر اپنی collection ملتی ہے، جس میں playlists اور play counts بھی شامل ہوتے ہیں، اور licensing میں کوئی تبدیلی انہیں آپ سے نہیں چھین سکتی۔ آپ کو نئی releases نہیں ملتیں، اور نہ ہی دوسرے لوگوں کی listening کی بنیاد پر recommendations ملتی ہیں۔ زیادہ تر لوگ جو یہ setup چلاتے ہیں، اپنی موسیقی خریدتے ہیں اور نئی موسیقی دریافت کرنے کے لیے ایک سستا streaming account برقرار رکھتے ہیں۔