VPS پر Nextcloud چلائیں: Docker، TLS اور بیک اپ

آپ اصل میں کیا بنا رہے ہیں

یہ رہنماور Nextcloud کو Docker Compose کے ساتھ VPS پر چلاتی ہے، اس کے سامنے Let's Encrypt TLS لگاتی ہے، اور ایسا backup ترتیب دیتی ہے جسے واقعی restore کیا جا سکے۔ اس میں چار containers اور ایک proxy شامل ہیں: سرکاری nextcloud image جو loopback پر listening کرتی ہے، Postgres جو file metadata کا ہر حصہ محفوظ رکھتا ہے، Redis جو file locks محفوظ رکھتا ہے، Nextcloud image کی دوسری copy جو صرف cron loop چلاتی ہے، اور host پر nginx جو ان سب کے سامنے TLS termination کرتا ہے۔ مکمل installation میں بیس منٹ لگتے ہیں، لیکن اصل اہمیت اس کی نہیں ہے۔ پہلے گھنٹے میں کیے گئے دو فیصلے طے کرتے ہیں کہ ایک سال بعد بھی آپ کی files موجود ہوں گی یا نہیں: SQLite کے بجائے حقیقی database استعمال کرنا، اور ایسا backup بنانا جس میں data directory، database اور config.php کو ایک ہی consistent set کے طور پر محفوظ کیا جائے۔

اس رہنما کے لیے Ubuntu 24.04 LTS یا Debian 13، Docker کے اپنے repository سے نصب کیا گیا Compose v2 plugin والا Docker Engine، اور پہلے سے ایسا DNS A record درکار ہے جو cloud.example.com کو VPS کی طرف point کرے، نیز اگر آپ کے پاس IPv6 ہے تو AAAA بھی درکار ہوگا۔ اس پورے setup کے لیے ایسا server ضروری ہے جس کا control آپ کے پاس ہو؛ کسی دوسرے کی SaaS پر TLS termination اور database dump کرنے کا کوئی طریقہ نہیں ہے۔

میموری کا اصل استعمال: کیا چیز واقعی memory استعمال کرتی ہے

Nextcloud کی memory usage بنیادی طور پر 3 چیزوں سے متعین ہوتی ہے، اور ان میں سے کوئی بھی بذاتِ خود "Nextcloud" نہیں ہے۔

PHP workers۔ -apache image ہر بیک وقت آنے والی request کو ایک worker process کے ذریعے handle کرتی ہے، جس میں PHP interpreter موجود ہوتا ہے۔ ہر worker PHP_MEMORY_LIMIT تک بڑھ سکتا ہے، اس کے بعد PHP request کو ختم کر دیتا ہے۔ بدترین صورت میں resident memory تقریباً بیک وقت requests × memory limit کے برابر ہوتی ہے، اور desktop sync client ہر user کے لیے کئی parallel connections کھولتا ہے۔ حد user count نہیں بلکہ concurrency متعین کرتی ہے۔

Database۔ Postgres ہر connection کے لیے ایک backend fork کرتا ہے اور shared buffers کو memory میں resident رکھتا ہے۔ اس کا working set bytes کی تعداد کے بجائے files کی تعداد کے ساتھ بڑھتا ہے: oc_filecache میں ہر user کی ہر file کے لیے ایک row ہوتی ہے۔ ایک لاکھ چھوٹی files کا database، ایک سو بڑی files کے database سے زیادہ memory استعمال کرتا ہے۔

Preview generation۔ Thumbnail بنانے کے لیے source image کو اس کی مکمل resolution پر memory میں decode کیا جاتا ہے۔ Video previews کے لیے ffmpeg کو shell command کے ذریعے چلایا جاتا ہے۔ occ preview:generate-all چلانے سے یہ memory spike مسلسل بار بار پیدا ہوتا ہے، اور چھوٹے VPS کو OOM killer تک پہنچانے کی یہ سب سے عام وجہ ہے۔

Redis نسبتاً کم memory استعمال کرتا ہے۔ بعد میں شامل کی جانے والی ہر چیز، مثلاً Collabora، full-text search یا antivirus scanner، اپنی memory footprint رکھنے والی الگ resident service ہوتی ہے۔ اسے enable کرنے سے پہلے اپنی sizing plan میں شامل کریں۔

اگر RAM کم ہو تو یہ settings کم کریں: PHP_MEMORY_LIMIT کی قدر گھٹائیں، preview_max_x / preview_max_y / preview_max_filesize_image کی حد مقرر کریں، enabledPreviewProviders کو صرف ان formats تک محدود کریں جنہیں آپ واقعی browse کرتے ہیں، اور trashbin_retention_obligation اور versions_retention_obligation مقرر کریں تاکہ data directory خاموشی سے آپ کی files کے حجم سے کئی گنا نہ بڑھ جائے۔ ایک swap file شامل کریں۔ Swap سست ہوتی ہے، لیکن upgrade کے دوران OOM kill اس سے بھی زیادہ نقصان دہ ہے۔

SQLite کیوں ناکام ہوتا ہے

Nextcloud، SQLite کی معاونت کے ساتھ جاری ہوتا ہے، اور official image اسے آسانی سے استعمال کر لیتی ہے۔ ایسا نہ کریں۔ SQLite، پورے database پر lock لگا کر writes کو serialise کرتا ہے: ایک وقت میں صرف ایک writer، اور وہ بھی پوری file کے لیے۔ Nextcloud مسلسل writes کرتا ہے، file locks بناتا ہے، activity rows اور cache entries لکھتا ہے، اور ایک واحد desktop client کی جانب سے directory tree کو sync کرنے پر متعدد parallel requests پیدا ہوتی ہیں۔ اس صورتِ حال میں SQLSTATE[HY000]: General error: 5 database is locked اور HTTP 500 errors ملتے ہیں، اور failure عین اس وقت ظاہر ہوتی ہے جب instance واقعی مفید ہونا شروع ہوتی ہے۔

بعد میں occ db:convert-type کے ذریعے conversion ممکن ہے، لیکن live dataset پر یہ طویل اور all-or-nothing migration ہوتی ہے۔ آغاز ہی Postgres یا MariaDB سے کریں۔

Compose فائل

اسے /srv/nextcloud/compose.yaml میں رکھیں، جبکہ secrets کو اسی کے ساتھ موجود .env فائل میں mode 600 کے ساتھ محفوظ کریں۔

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: redis-server --requirepass ${REDIS_PASSWORD}

  app:
    image: nextcloud:31-apache
    restart: unless-stopped
    depends_on: [db, redis]
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - html:/var/www/html
      - /srv/nextcloud/data:/var/www/html/data
    environment:
      POSTGRES_HOST: db
      POSTGRES_DB: nextcloud
      POSTGRES_USER: nextcloud
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      REDIS_HOST: redis
      REDIS_HOST_PASSWORD: ${REDIS_PASSWORD}
      NEXTCLOUD_ADMIN_USER: admin
      NEXTCLOUD_ADMIN_PASSWORD: ${ADMIN_PASSWORD}
      NEXTCLOUD_TRUSTED_DOMAINS: cloud.example.com
      TRUSTED_PROXIES: 172.16.0.0/12
      OVERWRITEPROTOCOL: https
      OVERWRITECLIURL: https://cloud.example.com
      APACHE_DISABLE_REWRITE_IP: "1"
      PHP_MEMORY_LIMIT: 512M
      PHP_UPLOAD_LIMIT: 10G

  cron:
    image: nextcloud:31-apache
    restart: unless-stopped
    entrypoint: /cron.sh
    depends_on: [db, redis]
    volumes:
      - html:/var/www/html
      - /srv/nextcloud/data:/var/www/html/data

volumes:
  db:
  html:

major tag کو pin کریں، اور 31 کو بعینہ نقل کرنے سے پہلے Docker Hub پر موجودہ tag کی جانچ کریں۔ مستقبل کے کسی docker compose pull میں latest آپ کو major version کی حد پار کروا دے گا، اور Nextcloud اس کی حمایت نہیں کرتا۔

data directory جان بوجھ کر named volume کے بجائے bind mount ہے۔ ایسے path کی افادیت زیادہ ہے جسے آپ backup tool کو براہ راست دے سکیں۔ اسے image کے www-data UID اور Nextcloud کی مطلوبہ permissions کے ساتھ بنائیں:

sudo mkdir -p /srv/nextcloud/data
sudo chown -R 33:33 /srv/nextcloud/data
sudo chmod 0770 /srv/nextcloud/data

port publish پر غور کریں: 127.0.0.1:8080:80۔ Docker، DNAT rules لکھ کر ports publish کرتا ہے۔ یہ rules ufw کی INPUT chain تک packet پہنچنے سے پہلے evaluate ہو جاتے ہیں۔ ایک سادہ 8080:80، ufw کی configuration سے قطع نظر، غیر encrypted Nextcloud کو public internet پر دستیاب کر دیتا ہے۔ loopback سے bind کرنے پر یہ public interface سے الگ رہتا ہے۔ اس کے بعد firewall کو صرف proxy کی اجازت دینی ہوتی ہے۔ اگر آپ SSH کو پورے internet کے لیے کھلا نہیں رکھنا چاہتے تو self-hosted WireGuard VPN کے ذریعے VPS تک رسائی حاصل کر کے public rules سے port 22 مکمل طور پر ہٹا سکتے ہیں:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

اسے docker compose up -d کے ساتھ شروع کریں، پھر docker compose logs -f app کو monitor کریں۔ پہلی boot میں پوری application tree کو volume میں copy کیا جاتا ہے اور installer چلایا جاتا ہے۔ یہ عمل مکمل ہونے تک container کسی request کا جواب نہیں دیتا۔

TLS اور reverse proxy

Distro سے nginx اور certbot انسٹال کریں، درست server_name کے ساتھ سادہ port-80 server block بنائیں، پھر certbot کو اسے دوبارہ لکھنے دیں۔ HTTP-01 challenge، renewal timer اور failure modes کی مکمل وضاحت Ubuntu 24.04 پر certbot اور nginx کے ساتھ Let's Encrypt certificates جاری کرنا میں موجود ہے:

sudo apt install nginx certbot python3-certbot-nginx
sudo certbot --nginx -d cloud.example.com

Certbot ssl_certificate لائنیں اور :80 → :443 redirect شامل کرتا ہے، اور ایک systemd timer انسٹال کرتا ہے جو 90-day certificate کی تجدید کرتا ہے۔ systemctl list-timers | grep certbot سے تصدیق کریں کہ یہ موجود ہے۔ ایسا renewal timer جسے کبھی enable نہ کیا گیا ہو، 90-day fuse ہوتا ہے۔

Proxy block خود یہ ہے:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name cloud.example.com;

    # certbot manages ssl_certificate / ssl_certificate_key here

    add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;

    client_max_body_size 10G;
    client_body_timeout 300s;

    location = /.well-known/carddav { return 301 /remote.php/dav; }
    location = /.well-known/caldav  { return 301 /remote.php/dav; }

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host  $host;
        proxy_request_buffering off;
        proxy_buffering off;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

nginx 1.25 اور اس کے بعد کے versions میں http2 on; شامل کریں۔ Ubuntu 24.04 میں ایک پرانا build شامل ہے، جہاں اس کے مساوی directive listen 443 ssl http2; ہے۔ nginx -t بتائے گا کہ آپ کا build کون سا directive قبول کرتا ہے۔

client_max_body_size اور طویل read timeouts بڑے uploads کو درمیان میں fail ہونے سے روکتے ہیں۔ proxy_request_buffering off upload کو پہلے پوری file کو proxy کی disk پر spool کرنے کے بجائے براہ راست stream کرتا ہے۔

ایک app کے لیے host پر nginx سب سے آسان قابلِ عمل حل ہے۔ اگر Nextcloud اسی VPS پر دیگر containers کے ساتھ چلنا ہے تو متعدد apps کے لیے Docker Compose reverse proxy کے طور پر Traefik چلانا routing اور certificate issuance کو container labels میں منتقل کرتا ہے۔ وہاں بھی وہی client_max_body_size اور timeout کے مسائل middleware اور transport settings کی صورت میں دوبارہ سامنے آتے ہیں۔

trusted_proxies اور overwriteprotocol

یہ وہ مقام ہے جہاں زیادہ تر self-hosted Nextcloud instances میں خرابی پیدا ہوتی ہے، جبکہ علامات کی وجہ اصل خرابی سے غیر متعلق دکھائی دیتی ہے۔

X-Forwarded-Proto: https صرف اسی وقت منظور کیا جاتا ہے جب request ایسے address سے آئے جو trusted_proxies میں درج ہو۔ اگر اسے منظور نہ کیا جائے تو Nextcloud سمجھتا ہے کہ request سادہ HTTP ہے اور http:// URLs بناتا ہے؛ proxy انہیں HTTPS پر redirect کرتا ہے؛ browser اس redirect کی پیروی کرتا ہے؛ پھر Nextcloud دوبارہ http:// بناتا ہے۔ یہی redirect loop ہے۔ OVERWRITEPROTOCOL: https scheme کو ہر صورت مقرر کر دیتا ہے۔

TRUSTED_PROXIES میں مسئلہ یہ ہے کہ Nextcloud جس address کو دیکھتا ہے، وہ 127.0.0.1 نہیں ہوتا۔ nginx host پر چلتا ہے اور published port سے connect ہوتا ہے، اس لیے container کو Docker bridge gateway نظر آتا ہے، جو 172.x میں موجود کسی address کی صورت میں ہوتا ہے۔ اصل subnet معلوم کریں:

docker network inspect nextcloud_default \
  -f '{{range .IPAM.Config}}{{.Subnet}}{{end}}'

اس CIDR، یا اسے شامل کرنے والے 172.16.0.0/12، کو TRUSTED_PROXIES میں درج کریں۔ اسے بہت وسیع مقرر کرنے پر کوئی بھی client X-Forwarded-For کی جعل سازی کر سکتا ہے؛ غلط value مقرر کرنے پر ہر login gateway address سے آتا ہوا دکھائی دے گا، brute-force protection پوری instance کو بیک وقت block کر دے گی، اور admin overview میں یہ پیغام دکھائی دے گا: "The reverse proxy header configuration is incorrect, or you are accessing Nextcloud from a trusted proxy."

OVERWRITECLIURL cron container کے لیے اہم ہے، کیونکہ اس کے پاس hostname معلوم کرنے کے لیے کوئی incoming request نہیں ہوتی۔ اس کے بغیر background jobs localhost کے links بناتے ہیں اور email notifications میں ناقابلِ استعمال URLs شامل ہوتے ہیں۔

پس منظر میں چلنے والے کام: AJAX کے بجائے cron

Nextcloud کا default job runner، AJAX ہے: کام اس وقت side effect کے طور پر execute ہوتے ہیں جب کوئی صفحہ load کرتا ہے۔ 04:00 بجے کوئی browsing نہیں کرتا، اس لیے trash expiry، versions cleanup، previews اور federated retries رک جاتے ہیں۔ پہلی علامت یہ ہوتی ہے کہ data directory کا سائز بڑھنا بند نہیں کرتا۔ اوپر دیا گیا cron service انہی volumes کے خلاف official /cron.sh loop چلاتا ہے۔ Nextcloud کو بتائیں کہ اسے اسی کی توقع رکھنی چاہیے:

docker compose exec -u www-data app php occ background:cron

ہر occ command اسی structure کی پیروی کرتی ہے: docker compose exec -u www-data app php occ <command>۔ اس کے لیے alias بنانا مفید ہے۔

بیک اپ: تین چیزیں، یا کچھ بھی نہیں

صرف filesystem کا بیک اپ کسی خراب instance کو بحال نہیں کر سکتا۔ data directory میں bytes محفوظ ہوتے ہیں؛ Postgres میں file cache، shares، users اور app state محفوظ ہوتی ہے؛ config.php میں database credentials، instance ID اور password salt محفوظ ہوتے ہیں۔ database کے بغیر files بحال کریں تو Nextcloud انہیں نہیں دیکھ سکتا۔ config.php کے بغیر database بحال کریں تو یہ database کھول نہیں سکتا۔ پرانی database کو نئی data directory کے ساتھ بحال کریں تو ایسی shares بنیں گی جو ان files کی طرف اشارہ کریں گی جو منتقل ہو چکی ہیں۔

تینوں کا بیک اپ quiesced instance سے لیں:

#!/usr/bin/env bash
set -euo pipefail
cd /srv/nextcloud
DEST="/var/backups/nextcloud/$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$DEST"

occ() { docker compose exec -T -u www-data app php occ "$@"; }

occ maintenance:mode --on
trap 'occ maintenance:mode --off' EXIT

docker compose exec -T db \
  pg_dump -U nextcloud --clean --if-exists nextcloud | gzip > "$DEST/db.sql.gz"

docker compose exec -T app \
  tar -C /var/www/html -cf - config custom_apps themes > "$DEST/app.tar"

rsync -a --delete /srv/nextcloud/data/ /var/backups/nextcloud/data/

Maintenance mode dump اور file copy کو ایک دوسرے سے مطابقت رکھنے کے قابل بناتا ہے۔ اسے چھوڑ دیں تو بالآخر ایسی database محفوظ ہو جائے گی جو کسی ایسی file کا حوالہ دیتی ہے جس تک rsync ابھی نہیں پہنچا تھا۔ یاد رکھیں کہ script timestamped database dumps محفوظ رکھتی ہے، لیکن data directory کا صرف ایک rolling mirror رکھتی ہے؛ rsync --delete ہر run میں اسے overwrite کرتا ہے، اس لیے صرف تازہ ترین dump ہی file copy کے ساتھ مطابقت رکھتا ہے۔

اس کے بعد بیک اپ کو server سے باہر منتقل کریں۔ جو بیک اپ اسی VPS پر موجود ہو جس چیز کا وہ بیک اپ ہے، وہ copy ہے، بیک اپ نہیں۔ restic کو object storage یا دوسرے host کے ساتھ استعمال کرنا معمول کا حل ہے، اور اس کی deduplication data directory کو nightly tarball کے مقابلے میں کہیں بہتر سنبھالتی ہے۔ repository init سے nightly timer اور restore drill تک مکمل setup off-box VPS backups with restic میں موجود ہے۔

Restore محض اسی عمل کو الٹا کرنا نہیں ہے۔ نئی شروع کی گئی stack installer چلاتی ہے اور بالکل نیا config.php، نیا instance ID اور password salt لکھتی ہے۔ اس نئی identity کے اوپر dump import کرنے سے broken sessions اور share tokens رہ جاتے ہیں۔ پہلے پرانی identity بحال کریں، اس ترتیب سے:

docker compose up -d && docker compose stop app cron    # create the volumes, then halt the app
sudo rsync -a --delete /var/backups/nextcloud/data/ /srv/nextcloud/data/
docker compose run --rm -T --entrypoint "" app \
  tar -C /var/www/html -xf - < app.tar                  # the original config.php returns
gunzip -c db.sql.gz | docker compose exec -T db psql -U nextcloud -d nextcloud
docker compose start app cron
docker compose exec -T -u www-data app php occ maintenance:mode --off
docker compose exec -T -u www-data app php occ files:scan --all

files:scan file cache کو disk پر موجود اصل files کے ساتھ ہم آہنگ کرتا ہے۔ ضرورت پیش آنے سے پہلے اس عمل کی ایک بار spare VPS پر مشق کریں۔ Disk پر موجود bytes اور Postgres میں موجود metadata کے درمیان یہی تقسیم اسی نوعیت کی ہر دوسری app پر بھی لاگو ہوتی ہے۔ اسی لیے ایسا Immich backup جو library محفوظ کرے لیکن database نہیں، empty timeline بحال کرتا ہے۔

اپ گریڈز: ایک وقت میں ایک major version

Nextcloud ایک وقت میں صرف ایک major version کے اپ گریڈ کی حمایت کرتا ہے۔ 29 سے 31 پر براہِ راست جانے پر graceful failure نہیں ہوتا، بلکہ یہ Exception: Updates between multiple major versions and downgrades are unsupported. کے ساتھ ناکام ہو جاتا ہے اور آپ maintenance mode میں رہ جاتے ہیں۔

Docker کے لیے اپ گریڈ کا طریقہ یہ ہے: backup لیں، دونوں app اور cron services میں tag کو 31 سے 32 میں تبدیل کریں، پھر docker compose pull && docker compose up -d چلائیں، اور اس کے بعد docker compose logs -f app۔ image entrypoint موجودہ data کے مقابلے میں نیا code شناخت کرتا ہے اور خود occ upgrade چلاتا ہے۔ اس عمل میں مداخلت نہ کریں۔ جب logs خاموش ہو جائیں تو docker compose exec -u www-data app php occ status چلائیں، پھر versionstring چیک کریں اور تصدیق کریں کہ apps دوبارہ enabled ہیں۔

دو اصول آپ کو مسائل سے بچاتے ہیں: ایک major version بڑھائیں، تصدیق کریں، پھر اگلا بڑھائیں۔ اور app service میں tag کو کبھی بھی cron سے مطابقت پیدا کیے بغیر تبدیل نہ کریں۔ ایک ہی database کے ساتھ Nextcloud کی دو مختلف versions استعمال کرنے سے data corruption ہو سکتا ہے۔

وہ غلطیاں جو آپ کو حقیقت میں نظر آئیں گی

"Your data directory is readable by other users. Please change the permissions to 0770." bind-mounted directory میں group یا world read bits موجود ہیں۔ sudo chmod 0770 /srv/nextcloud/data اور sudo chown -R 33:33 /srv/nextcloud/data۔

"Your data directory is invalid. Ensure there is a file called .ocdata in the root." bind mount ایسی جگہ کی طرف اشارہ کرتا ہے جسے Nextcloud نے کبھی initialize نہیں کیا، path میں typo ہے، یا چلتے ہوئے instance کے نیچے نیا خالی directory رکھ دیا گیا ہے۔ تصدیق کریں کہ host path volume line سے مطابقت رکھتا ہے۔

"Access through untrusted domain." request میں موجود hostname trusted_domains میں شامل نہیں ہے۔ NEXTCLOUD_TRUSTED_DOMAINS صرف پہلی installation پر لاگو ہوتا ہے؛ اس کے بعد اسے live طور پر set کریں: occ config:system:set trusted_domains 1 --value=cloud.example.com۔

502 Bad Gateway، جس میں connect() failed (111: Connection refused) while connecting to upstream، /var/log/nginx/error.log میں موجود ہے۔ nginx کو 127.0.0.1:8080 پر کوئی سروس نہیں ملی۔ یا تو container ابھی initialize ہو رہا ہے (docker compose logs app دیکھیں)، وہ exit ہو گیا ہے (docker compose ps)، یا publish line proxy_pass port سے مطابقت نہیں رکھتی۔ ss -ltnp | grep 8080 سے تصدیق کریں۔

redirect loop، یا admin overview میں "insecure" warnings۔ OVERWRITEPROTOCOL: https موجود نہیں ہے، یا TRUSTED_PROXIES میں Docker gateway subnet شامل نہیں ہے۔ اوپر والا proxy section دیکھیں۔

LockedException: "files/..." is locked۔ REDIS_HOST set ہونے پر image، Redis کو locking backend کے طور پر configure کرتی ہے اور stale locks کم ہی رہتے ہیں۔ اس کے بغیر locks database table oc_file_locks میں محفوظ ہوتے ہیں، اور write کے دوران request ختم ہو جائے تو rows باقی رہ جاتی ہیں۔ ہاتھ سے lock rows صاف کرنے سے پہلے تصدیق کریں کہ Redis واقعی استعمال ہو رہا ہے؛ occ config:system:get memcache.locking کو Redis class واپس کرنی چاہیے۔

"The PHP memory limit is below the recommended value of 512MB." PHP_MEMORY_LIMIT بڑھائیں اور container دوبارہ بنائیں۔ یاد رکھیں کہ اس سے worst-case ceiling پر کیا اثر پڑتا ہے۔

بڑے پیمانے پر کیا خراب ہوتا ہے

پہلی رکاوٹ یہ ہے کہ data directory کی گنجائش volume سے بڑھ جاتی ہے۔ VPS پر volume بڑھانے کے لیے resize کے ساتھ filesystem grow بھی کرنا پڑتا ہے، اور یہ کام volume کے 100% بھرنے کے بعد کے مقابلے میں پہلے سے schedule کیا جائے تو بہت کم تکلیف دہ ہوتا ہے۔ ابھی disk usage پر alert لگائیں، بعد میں نہیں۔

دوسری رکاوٹ oc_filecache ہے۔ File listings اور sync scans میں rows کی تعداد بڑھنے کے ساتھ رفتار کم ہو جاتی ہے۔ اس کا حل database کی دیکھ بھال ہے: Postgres کو تیز storage پر رکھیں، اسے کافی shared memory استعمال کرنے دیں، اور retention settings کے ذریعے trash اور versions کو باقاعدگی سے صاف کریں، بجائے اس کے کہ انہیں ہمیشہ جمع ہونے دیں۔

تیسری رکاوٹ preview generation کا باقی تمام کام کے ساتھ وسائل میں مقابلہ کرنا ہے۔ چھوٹے server پر preview providers کی حد محدود رکھیں اور working hours کے دوران کبھی occ preview:generate-all نہ چلائیں۔ اگر آپ کے ذخیرہ کردہ data کا زیادہ تر حصہ phone camera roll ہے تو thumbnails بنانے کا کام purpose-built photo server پر ہونا چاہیے۔ RAM، phone apps اور backup commands کے لحاظ سے PhotoPrism اور Immich کا تقابل میں بتایا گیا ہے کہ Nextcloud box کے ساتھ ان میں سے ہر ایک کی لاگت کتنی پڑتی ہے۔

اس کے بعد دیانت دار جواب یہ ہے کہ اضافی services کے لیے الگ machine چاہیے۔ Collabora اور full-text search الگ resident services ہیں اور ہر ایک کا memory profile مختلف ہے۔ انہیں اس machine پر چلانے سے، جہاں آپ کی files کی واحد copy بھی موجود ہو، failure domain بلا فائدہ بڑا ہو جاتا ہے۔ اگر in-browser document editing وہ اضافی سہولت ہے جو آپ چاہتے ہیں تو vendor کے RAM floors اور connection limits جن کی بنیاد پر OnlyOffice اور Collabora میں فرق ہوتا ہے طے کرتے ہیں کہ 2 سے 4 GB کا VPS ان میں سے کسی کو چلا بھی سکتا ہے یا نہیں۔ جب volume کی ساخت موزوں نہ رہے تو file storage کو S3-compatible primary storage پر منتقل کریں۔ یہ بھی یاد رکھیں کہ اس سے backups آسان نہیں بلکہ مشکل ہوتے ہیں: database میں metadata بدستور موجود رہتا ہے، اور اسے bucket کے ساتھ ہم وقت dump کرنا ضروری ہے۔

جب instance حقیقی users کو service دینے لگے تو اس کے سامنے Uptime Kuma رکھیں، تاکہ sync clients سے پہلے آپ کو downtime کا علم ہو جائے۔ Private cloud، اپنے mail server کے ساتھ اچھی طرح کام کرتا ہے۔ اگر آپ services کو دستی طور پر آپس میں جوڑنا نہیں چاہتے تو Cloudron، CasaOS اور Coolify ان platforms کا تقابل کرتے ہیں جو یہ کام آپ کے لیے کرتے ہیں۔ اگر self-hosted search engine اس فہرست میں اگلا مرحلہ ہے تو اوپر بیان کردہ مسائل سے مختلف نوعیت کے مسئلے کی توقع رکھیں: SearXNG کی 429 errors یا تو اس کے اپنے rate limiter سے پیدا ہوتی ہیں یا upstream engines آپ کے VPS IP کو block کر رہے ہوتے ہیں۔ دونوں میں فرق صرف log سے معلوم ہوتا ہے۔

FAQ

کیا میں Postgres کے بجائے Nextcloud کو SQLite پر چلا سکتا ہوں؟

آپ ایسا کر سکتے ہیں، اور official image بھی اس کی اجازت دے گی، لیکن parallel requests بھیجنے والا ایک desktop sync client SQLSTATE[HY000]: General error: 5 database is locked اور HTTP 500 errors کا سبب بنے گا۔ SQLite پورے database پر write lock لگا دیتا ہے، جبکہ Nextcloud مسلسل writes کرتا رہتا ہے، مثلاً file locks، activity rows اور job state۔ Postgres یا MariaDB سے آغاز کریں؛ occ db:convert-type موجود ہے، لیکن live data پر یہ طویل اور all-or-nothing migration ہوتی ہے۔

Nextcloud VPS کو حقیقت میں کتنی RAM درکار ہوتی ہے؟

Sizing صارفین کی تعداد کے بجائے concurrency کے مطابق کریں۔ بدترین صورت میں resident memory تقریباً concurrent requests کی تعداد کو PHP_MEMORY_LIMIT سے ضرب دینے کے برابر ہوتی ہے، اس کے علاوہ Postgres shared buffers، ہر connection کے لیے ایک backend، اور preview generation کے دوران memory spike بھی شامل ہوتا ہے۔ 2 GB کی مشین چھوٹے گھریلو instance کو چلا سکتی ہے، بشرطیکہ آپ previews محدود کریں اور swap شامل کریں؛ Collabora یا full-text search شامل کرنے پر resident services کے لیے تقریباً ایک دوسرے سیٹ کی sizing کرنا ہوگی۔

nginx reverse proxy کے پیچھے بڑے uploads کیوں ناکام ہوتے ہیں؟

Proxy پر دو settings عموماً اس کی وجہ ہوتی ہیں: client_max_body_size کو 1 MB کے default پر چھوڑنے سے request truncate ہو جاتی ہے، جبکہ مختصر proxy_read_timeout / proxy_send_timeout values طویل transfers کو درمیان میں ختم کر دیتی ہیں۔ دونوں کو مناسب حد تک بڑھائیں، proxy_request_buffering off کو spool کے بجائے stream پر set کریں، اور app container میں PHP_UPLOAD_LIMIT کو بھی اسی کے مطابق بڑھائیں۔

Nextcloud redirect loop میں کیوں چلا جاتا ہے یا reverse proxy کے بارے میں warning کیوں دیتا ہے؟

Container کو nginx 127.0.0.1 پر نظر نہیں آتا؛ اسے Docker bridge gateway نظر آتا ہے، جو کہیں 172.x میں ہوتا ہے۔ جب یہ address TRUSTED_PROXIES میں موجود نہ ہو تو X-Forwarded-Proto: https header نظرانداز کر دیا جاتا ہے، Nextcloud http:// URLs بناتا ہے، اور proxy انہیں دوبارہ واپس بھیج دیتا ہے۔ TRUSTED_PROXIES کو اصل bridge subnet پر set کریں اور OVERWRITEPROTOCOL: https کو pin کریں۔

کیا میں Nextcloud کو 29 سے براہ راست 31 پر upgrade کر سکتا ہوں؟

نہیں۔ Nextcloud ہر upgrade میں صرف ایک major version کی اجازت دیتا ہے، اور version skip کرنے پر Updates between multiple major versions and downgrades are unsupported. کے ساتھ عمل رک جاتا ہے، جس سے instance maintenance mode میں رہتا ہے۔ Backup لیں، app اور cron دونوں services پر tag کو ایک major version بڑھائیں، docker compose pull && docker compose up -d، پھر occ status سے تصدیق کریں اور یہی عمل دوبارہ دہرائیں۔