कम संसाधन वाले सेटअप

SnapOtter छोटे हार्डवेयर पर अच्छी तरह चलता है: Raspberry Pi 4 या 5, कोई पुराना लैपटॉप, या 2 GB का VPS। यह पेज ऐसी मशीनों के लिए व्यावहारिक गाइड है: क्या अपेक्षा करें, समझदार सीमाओं के साथ एक कॉपी-पेस्ट सेटअप, और कौन से फ़ीचर छोड़ देने चाहिए। इन संख्याओं के पीछे का पूरा बेंचमार्क डेटा Hardware Requirements में है।

शुरू में ही दो सख़्त सीमाएँ:

• केवल 64-बिट। इमेज linux/amd64 और linux/arm64 के लिए बनाई जाती है। 32-बिट ARM (armv7/armhf) समर्थित नहीं है, इसलिए पहली पीढ़ी के Pi और Pi Zero परिवार बाहर हैं।
• 2 GB मेमोरी की न्यूनतम सीमा। 512 MB स्टैक शुरू ही नहीं कर सकता, और 1 GB बहु-फ़ाइल बैचों पर विफल हो जाता है। 2 कोर के साथ 2 GB सबसे छोटा कॉन्फ़िगरेशन है जो आराम से काम करता है।

छोटे हार्डवेयर पर क्या अच्छा चलता है

हर गैर-AI टूल 2 GB / 2-कोर मशीन पर काम करता है: पूरे Image और Files सेक्शन, PDF टूल, और स्ट्रीम-कॉपी वाले वीडियो व ऑडियो ऑपरेशन (ट्रिम, म्यूट, कंटेनर रीमक्स)। अधिकांश एक सेकंड से भी कम में पूरे हो जाते हैं।

दो वर्कलोड अपवाद हैं:

• वीडियो री-एन्कोडिंग (कोडेक के बीच रूपांतरण) CPU-बाउंड है। जो 1080p क्लिप किसी तेज़ डेस्कटॉप CPU पर ~40 सेकंड लेती है, वह Pi-श्रेणी के CPU पर कई मिनट ले सकती है। स्ट्रीम-कॉपी ऑपरेशन तब भी तुरंत ही होते हैं।
• AI टूलों को RAM (4 GB अनुशंसित) और डिस्क चाहिए (बड़े बंडल 4-5 GB प्रत्येक होते हैं), और भारी वाले (अपस्केलिंग, फोटो बहाली, पृष्ठभूमि हटाना) Pi-श्रेणी के CPU पर व्यावहारिक नहीं हैं। चेहरा पहचान और OCR जैसा हल्का AI उपयोग करने योग्य है, बशर्ते आपके पास उसके लिए मेमोरी हो।

जब तक आप इनका उपयोग नहीं करते, इनमें से कुछ भी इंस्टॉल या चालू नहीं होता: बिना किसी AI बंडल के ऐप लगभग 360 MB पर निष्क्रिय रहता है, और AI बंडल केवल तभी डाउनलोड होते हैं जब कोई एडमिन उन्हें सक्षम करता है।

Raspberry Pi / पुराने लैपटॉप की वॉकथ्रू

यह Getting Started वाला ही स्टैंडर्ड Compose इंस्टॉल है, साथ में रिसोर्स लिमिट और सतर्क सीमाएँ। यह 64-बिट OS मानकर चलता है (Pi पर: Raspberry Pi OS 64-bit या Ubuntu Server arm64)।

services:
  snapotter:
    image: snapotter/snapotter:latest
    ports:
      - "1349:1349"
    volumes:
      - ./snapotter-data:/data
    environment:
      - DATABASE_URL=postgres://snapotter:snapotter@db:5432/snapotter
      - REDIS_URL=redis://redis:6379
      # Small-box profile: see the table below for what each cap does.
      - CONCURRENT_JOBS=1
      - MAX_WORKER_THREADS=2
      - MAX_BATCH_SIZE=5
      - MAX_UPLOAD_SIZE_MB=100
      - MAX_MEGAPIXELS=50
      - MAX_VIDEO_DURATION_S=300
    deploy:
      resources:
        limits:
          cpus: "2"
          memory: 2G
    depends_on:
      - db
      - redis
    restart: unless-stopped

  db:
    image: postgres:17-alpine
    environment:
      - POSTGRES_USER=snapotter
      - POSTGRES_PASSWORD=snapotter
      - POSTGRES_DB=snapotter
    volumes:
      - ./postgres-data:/var/lib/postgresql/data
    restart: unless-stopped

  redis:
    image: redis:8-alpine
    command: redis-server --maxmemory 256mb --maxmemory-policy noeviction
    restart: unless-stopped

Pi-श्रेणी की मशीनों के लिए नोट्स:

• डेटा वॉल्यूम और Postgres के लिए SD कार्ड के बजाय USB SSD चुनें। जॉब वर्कस्पेस असली डिस्क IO करते हैं, और SD कार्ड धीमे भी होते हैं और जल्दी घिस भी जाते हैं।
• ऑल-इन-वन एकल कंटेनर यहाँ भी काम करता है (DATABASE_URL/REDIS_URL अनसेट होने पर एंबेडेड Postgres और Redis), और मेमोरी की तंगी वाले होस्ट पर आपको REDIS_MAXMEMORY से इसकी एंबेडेड Redis सीमा घटा देनी चाहिए (Configuration देखें)। Compose हर सेवा पर बारीक नियंत्रण देता है, इसीलिए यह वॉकथ्रू उसी का उपयोग करती है।
• 2 GB डिवाइसों पर स्वैप जोड़ें। इससे कभी-कभार का स्पाइक (कोई बड़ी PDF, कोई बैच जिस पर सीमा लगाना आप भूल गए) आउट-ऑफ़-मेमोरी किल में खत्म नहीं होता। zram SD-कार्ड के लिए अनुकूल विकल्प है।
• arm64 इमेज केवल CPU वाली है; ARM बोर्डों पर कोई CUDA नहीं है।

ट्यूनिंग के विकल्प

सभी सीमाएँ एनवायरनमेंट वेरिएबल हैं, जिनका पूरा विवरण Configuration में है। 0 का मतलब असीमित या ऑटो है। छोटे हार्डवेयर पर जो मायने रखती हैं:

वेरिएबल	छोटी मशीन के लिए सुझाव	यह किससे बचाता है
CONCURRENT_JOBS	1	कितने जॉब समानांतर चलते हैं। ऑटो-डिटेक्ट CPU कोर घटा एक का उपयोग करता है, जो बड़ी मशीनों पर ठीक है लेकिन मेमोरी दबाव में 2-कोर मशीन पर ज़रूरत से ज़्यादा आक्रामक है।
MAX_WORKER_THREADS	2	इमेज-प्रोसेसिंग थ्रेड पूल।
MAX_BATCH_SIZE	5	बैच ही वह जगह है जहाँ 1-2 GB मशीनों की मेमोरी सबसे पहले खत्म होती है।
MAX_UPLOAD_SIZE_MB	100	एक ही विशाल फ़ाइल को पूरा वर्कस्पेस घेरने से रोकता है।
MAX_MEGAPIXELS	50	100+ MP इमेज को डिकोड करने में RAM खर्च होती है, फ़ाइल आकार चाहे जो हो।
MAX_VIDEO_DURATION_S	300	लंबे ट्रांसकोड छोटे CPU पर मिनटों से घंटों तक कब्ज़ा कर लेते हैं।
PROCESSING_TIMEOUT_S	600	सख़्त ऊपरी सीमा, ताकि कोई बेकाबू जॉब अंततः मशीन को मुक्त कर दे।

ये सीमाएँ इस पर लागू होती हैं कि सर्वर क्या स्वीकार करता है, इसलिए इन्हें जितना संभव हो उतना छोटा रखने के बजाय अपने वास्तविक उपयोग के अनुसार सेट करें। अगर आप वीडियो कभी नहीं छूते, तो MAX_VIDEO_DURATION_S सीमा का कोई नुकसान नहीं; अगर आप रोज़ दस्तावेज़ स्कैन करते हैं, तो MAX_PDF_PAGES पर सीमा न लगाएँ।

क्या छोड़ दें

• भारी AI बंडल। अपस्केलिंग, फोटो बहाली, और पृष्ठभूमि हटाने को GPU या तेज़ मल्टी-कोर CPU चाहिए, और हर बंडल 4-5 GB डिस्क लेता है। छोटी मशीन पर इन्हें बस इंस्टॉल ही न करें; जिन टूलों का बंडल मौजूद नहीं है वे चलने के बजाय इंस्टॉल का संकेत दिखाते हैं।
• नियमित वर्कलोड के रूप में वीडियो री-एन्कोडिंग। कभी-कभार के ट्रांसकोड ठीक हैं (वे बस धीमे होते हैं); लगातार चलने वाली ट्रांसकोड कतार को CPU कोर चाहिए, Pi नहीं।
• सामान्य तौर पर अप्रयुक्त टूल। एडमिन Settings में अलग-अलग टूल बंद कर सकता है, जिससे वे UI से हट जाते हैं और उनके API रूट रजिस्टर होना बंद हो जाते हैं। इससे अपने आप मेमोरी नहीं बचती, लेकिन यह साझा छोटी इंस्टेंस को उसी एक वर्कलोड में इस्तेमाल होने से बचाता है जिसे हार्डवेयर झेल नहीं सकता।

अगर बाद में आप इंस्टेंस को बड़े हार्डवेयर पर ले जाते हैं, तो सीमाएँ हटा दें (उन्हें वापस 0 पर सेट करें) और वही डेटा वॉल्यूम साथ चला जाता है।