השוואת קוראי RSS בניהול עצמי ל-VPS: מה הכי חסכוני?

איזה קורא RSS בניהול עצמי מתאים ל-VPS קטן

Miniflux הוא קורא ה-RSS בניהול עצמי המומלץ ל-VPS קטן. הוא מורכב מקובץ binary יחיד של Go לצד PostgreSQL. הוא תומך ב-APIs של Fever ו-Google Reader, כך שאפליקציות צד-שלישי לטלפון יכולות להתחבר אליו, ושדרוג מתבצע באמצעות docker compose pull אחד. בחרו ב-FreshRSS אם אתם זקוקים לתוספים ולמכולה (container) אחת הכוללת SQLite בתוכה.

חמישה קוראים מצדיקים את שטח הדיסק ב-VPS: Miniflux, FreshRSS, CommaFeed, yarr ו-Tiny Tiny RSS. דף זה משווה את ההבדלים המהותיים ביניהם: צריכת הזיכרון של כל stack, מסד הנתונים שכל אחד מחייב, ה-API לסנכרון שדרושה לאפליקציה בטלפון שלכם, ומה קורה ביום השדרוג. כל נתון כאן פורסם על ידי הפרויקט או מבוסס על חישוב אריתמטי פשוט, והטקסט מציין מהו המקור. אף אחד מהנתונים אינו מהווה benchmark לחומרה שלכם, לכן מדדו את השרת שלכם בעזרת docker stats.

חמשת הקוראים, פסקה לכל אחד

Miniflux כתוב ב־Go ומופץ כקובץ בינארי יחיד שעבר הידור סטטי. התיעוד שלו מצהיר בגלוי על תלות אחת הכרחית: הוא "עובד רק עם PostgreSQL". אין מצב SQLite. הוא מציע REST API, ממשק תואם Fever וממשק תואם Google Reader, בנוסף לייבוא וייצוא OPML. חיפוש טקסט מלא מבוצע על ידי PostgreSQL, וזו אחת הסיבות לכך שמסד הנתונים אינו אופציונלי.

FreshRSS מבוסס PHP ורץ כמכולה אחת המכילה גם את שרת האינטרנט וגם את היישום. SQLite הוא מסד הנתונים המוגדר כברירת מחדל ואינו דורש שירות נוסף, בעוד ש־PostgreSQL ו־MySQL נתמכים עבור התקנות גדולות יותר. הוא תומך ב־Google Reader API וב־Fever API. התקנתו כבר מכוסה בתוך המדריך שלנו להתקנת FreshRSS על גבי VPS, לכן דף זה משווה בינו לבין האחרים במקום לחזור על תהליך ההתקנה.

CommaFeed מבוסס Java על גבי Quarkus עם פריסה המעתיקה את Google Reader. מסד הנתונים נבחר בזמן ההידור ולא בזמן הריצה, לכן הפרויקט מפרסם אימג' אחד לכל מסד נתונים: athou/commafeed:latest-h2 עבור מסד הנתונים המוטמע H2, athou/commafeed:latest-postgresql עבור PostgreSQL, וגרסאות נוספות עבור MySQL ו־MariaDB. הוא חושף REST API וממשק תואם Fever.

yarr (קיצור של yet another rss reader) הוא קובץ בינארי יחיד של Go עם SQLite מוטמע, והוא אינו זקוק למכולה כלל. פקודת ./yarr פשוטה מאזינה ב־127.0.0.1:7070. הדגלים קצרים: -addr 0.0.0.0:7070 -auth alice:secret פותח אותו לרשת מאחורי סיסמה, ו־-db /data/yarr.db מציב את מסד הנתונים במיקום הרצוי. הוא כולל ממשק תואם Fever. הגרסה האחרונה שלו היא v2.8, מיולי 2024, שנבדקה באוגוסט 2026, לכן יש להתייחס אליו כאל תוכנה מוגמרת ולא כאל פרויקט בפיתוח פעיל.

Tiny Tiny RSS הוא הוותיק מבין החמישה והכבד ביותר להרצה. הגדרת ה־Docker הרשמית כוללת ארבעה שירותים: מכולת PostgreSQL, מכולת יישום PHP-FPM, מכולת עדכון נפרדת שמושכת את הפידים, ומכולת nginx בחזית. התיעוד מציין בבירור כי "הגדרה זו משתמשת ב־PostgreSQL". יש לו JSON API משלו, שבו משתמשים הלקוח לאנדרואיד ומספר יישומי צד-שלישי. תמיכה ב־Fever אינה חלק ממנו.

כמה זיכרון נדרש לכל stack

הנתונים להלן הם תקציבי זיכרון, לא מדידות בפועל: מדובר בתקרת הזיכרון שכל stack אמור לעמוד בה על גבי VPS קטן. המספר עבור CommaFeed הוא דוגמה רשמית שפורסמה על ידי הפרויקט, המגבילה את ה־container ל־256 MB. שאר המספרים הם תקרות המשאירות מרווח פעולה עבור רכיב משיכת הפידים (feed fetcher), שכן זהו החלק שצריכת הזיכרון שלו מזנקת בתחילת מחזור רענון.

[
  {
    "label": "yarr (SQLite)",
    "containers": 1,
    "mem_limit_mb": 128
  },
  {
    "label": "FreshRSS (SQLite)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "CommaFeed (H2)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "Miniflux + Postgres",
    "containers": 2,
    "mem_limit_mb": 320
  },
  {
    "label": "Tiny Tiny RSS",
    "containers": 4,
    "mem_limit_mb": 640
  }
]

yarr נמצא בתחתית הרשימה עם 128 MB, כיוון שהוא מורכב מקובץ binary אחד ומקובץ SQLite אחד, ללא שרת מסד נתונים או runtime של שפת תכנות מתחתיו. Miniflux דורש 320 MB על פני 2 מכולות, כאשר רוב הזיכרון מוקצה ל־PostgreSQL ולא ל־Miniflux עצמו. Tiny Tiny RSS הוא החריג עם 640 MB על פני 4 מכולות, כיוון שהיישום, המעדכן (updater), מסד הנתונים ושרת האינטרנט הם ארבעה תהליכים נפרדים עם ארבעה אזורי זיכרון (heaps) נפרדים.

הגדירו ערכים אלו כמגבלות ממשיות ולא כמשאלות לב. המדריך מגבלות זיכרון ב־Docker Compose מסביר את התחביר ומה קורה למכולה כאשר היא מגיעה לתקרה. מכולה ללא הגבלה אינה קורסת בצורה מסודרת כאשר השרת מתמלא: ה־kernel בוחר תהליך "קורבן" ומסיים אותו, ולרוב לא מדובר במכולה שגרמה לעומס מלכתחילה.

איזה מסד נתונים כל קורא כופה עליך

מסד הנתונים הוא ההבדל התפעולי המשמעותי ביותר בין חמש האפשרויות הללו. זו החלטה כבדת משקל יותר מכל הבדל בממשק המשתמש, כיוון שהיא קובעת את נוהל הגיבוי ואת הסיכון בעת שדרוג.

PostgreSQL נדרש על ידי Miniflux ועל ידי ההתקנה הרשמית של Tiny Tiny RSS. הוא מספק חיפוש טקסט מלא אמיתי וכתיבה מקבילית בטוחה. המחיר הוא מכולה נוספת, נפח אחסון (volume), ובעיה חוזרת אחת: תמונות ה-PostgreSQL הרשמיות אינן יכולות לבצע הגירה (migration) של נתונים בין גרסאות ראשיות (major versions) במקום. התיעוד של Tiny Tiny RSS מציין זאת במפורש ומזהיר כי "למכולות PostgreSQL רשמיות אין תמיכה בהגירת נתונים בין גרסאות ראשיות". האפשרויות הריאליות שלך הן לקבע (pin) את הגרסה הראשית הישנה, או לבצע dump ו-restore באמצעות pg_dump ו-pg_restore. תכנן זאת אחת לשנה או שנתיים.

SQLite הוא ברירת המחדל של FreshRSS ושל yarr. מדובר בקובץ אחד, ללא שרת, ללא פורט וללא סיסמה. הוא מתפקד היטב עבור משתמש יחיד עם כמה מאות ערוצי תוכן (feeds), אך מאט כאשר כמה משתמשים כותבים בו זמנית; זהו השלב שבו האפשרות ל-PostgreSQL ב-FreshRSS מתחילה להצדיק את עצמה. yarr הוסיפה תמיכה אופציונלית ב-PostgreSQL בגרסה v2.7, אך הקובץ המוטמע הוא הדרך המקובלת להריץ אותה.

H2 הוא ברירת המחדל המוטמעת של CommaFeed, והוא דורש מחשבה לפני שמתחילים, כיוון ש-CommaFeed בוחרת את מסד הנתונים שלה בעת בניית התמונה (image). מעבר מ-H2 ל-PostgreSQL בשלב מאוחר יותר אינו שינוי הגדרות פשוט. זוהי תמונה שונה בתוספת הגירת נתונים שעליך לבצע בעצמך, לכן החלט על כך לפני שצברת שנה של היסטוריית קריאה בתוך המערכת.

האם אפליקציית הטלפון שלי תעבוד

שאלה זו מכריעה יותר ממה שנהוג לחשוב, כיוון שממשק האינטרנט הוא רק חלק מהאופן שבו משתמשים בקורא עדכונים.

Miniflux תומך ב-API תואם Fever וב-API תואם Google Reader, לכן רוב הלקוחות ב-iOS וב-Android מתחברים אליו. FreshRSS תומך באותם שני ממשקים, והתיעוד שלו מדרג אותם: ה-API של Google Reader הוא ה"טוב ביותר" עם תמיכה מלאה בתכונות, בעוד ה-API של Fever מציע "תכונות מוגבלות והתנהגות פחות יעילה". FreshRSS דורש גם שני שלבים לפני שניתן להתחבר מכל אפליקציה. יש להפעיל את "Allow API access (required for mobile apps)" תחת Authentication, ולאחר מכן ליצור סיסמת API בפרופיל המשתמש. דילוג על יצירת סיסמת ה-API יוביל לכשל אימות באפליקציה בזמן שההתחברות דרך הדפדפן תמשיך לעבוד, מה שעלול לבלבל עד שמבינים היכן לחפש את הבעיה.

CommaFeed ו-yarr חושפים שניהם API תואם Fever בלבד, לכן הם עובדים עם לקוחות התומכים ב-Fever ולא עם אפליקציות שתומכות ב-Google Reader בלבד. ל-Tiny Tiny RSS יש API משלו, מה שאומר שדרוש לקוח שנכתב במיוחד עבורו. ודאו שהאפליקציה המועדפת עליכם תומכת בקורא לפני שאתם מייבאים אליו 300 עדכונים.

קובץ compose תקין עבור שרת בעל 1 GB זיכרון

זהו ה-stack של Miniflux, מותאם מתוך דוגמת ה-Docker הרשמית של הפרויקט נכון לאוגוסט 2026. הפורט המפורסם קשור ל-loopback, כתובת ההאזנה מוגדרת במפורש, ושני הקונטיינרים כוללים הגבלת זיכרון.

services:
  miniflux:
    image: miniflux/miniflux:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:CHANGE_ME@db/miniflux?sslmode=disable
      - LISTEN_ADDR=0.0.0.0:8080
      - BASE_URL=https://rss.example.com/
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=CHANGE_ME_TOO
      - POLLING_FREQUENCY=60
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    mem_limit: 128m
  db:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=CHANGE_ME
      - POSTGRES_DB=miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      start_period: 30s
    mem_limit: 192m
volumes:
  miniflux-db:

שלוש שורות בקובץ זה הן המקור לטעויות נפוצות. LISTEN_ADDR=0.0.0.0:8080 מוגדר כך כיוון שברירת המחדל המתועדת של הבינארי היא 127.0.0.1:8080, ותהליך שקשור ל-loopback בתוך קונטיינר אינו נגיש דרך הפורט המפורסם; התוצאה היא connection reset למרות שהקונטיינר נראה תקין. נתיב ה-volume ב-/var/lib/postgresql תואם ל-PostgreSQL 18; גרסה 17 וגרסאות מוקדמות יותר מאחסנות נתונים ב-/var/lib/postgresql/data, ומיפוי נתיב שגוי גורם לכך שספריית הנתונים אינה נמצאת על ה-volume, מה שמוביל לאובדן נתונים בכל יצירה מחדש של הקונטיינר. 127.0.0.1:8080:8080 מונע מהפורט להיחשף לאינטרנט הציבורי, שכן פרסום פורט ללא הגדרת כתובת יוצר חוק ב-chain ש-ufw אינו מנהל. Docker ports bypass ufw מסביר את המנגנון הזה, ו-a Traefik reverse proxy הוא הדרך להוסיף TLS לפני השירות.

docker compose up -d
docker compose ps
docker compose logs -f miniflux
docker stats --no-stream

docker compose ps אמור להציג את שני השירותים כפעילים, כאשר מסד הנתונים מסומן כ-healthy. ההפעלה הראשונה של Miniflux מתעדת את ה-schema migrations בלוגים, וזה מה ש-RUN_MIGRATIONS=1 מפעיל. docker stats --no-stream מדפיס את עמודת הזיכרון החי, וזהו המספר שיש להשוות למגבלות בטבלה לעיל. אם קונטיינר Miniflux מתחיל מחדש בלולאה, קראו את הלוג שלו: connect: connection refused מציין שהוא עלה לפני ש-PostgreSQL היה מוכן לקבל חיבורים, וזה בדיוק מה שהתנאי service_healthy מונע, לכן ודאו שהתנאי נשמר לאחר העריכה. אם אתם חדשים ב-Compose, Docker Compose basics on a VPS מכסה את מבנה הקובץ הבסיסי.

מה לא יתאים לשרת בנפח 1 GB

מומלץ לוותר על Tiny Tiny RSS. ערימת ארבעת השירותים הרשמית שלו רצה על VPS בנפח 1 GB רק כאשר השרת אינו מריץ שום דבר אחר, והיא לא תרוץ שם לצד יישום אחר מבוסס מסד נתונים ו־reverse proxy. ארבעה שירותים משמעותם ארבע מערכות של תקורה (overhead), ואחד מהם הוא PostgreSQL.

CommaFeed מתאים, אך רק עם ה־image של H2 ועם מגבלת ה-256 MB שהדוגמה הרשמית של הפרויקט מגדירה. השילוב שגורם לקריסת שרת קטן הוא JVM לצד שרת מסד נתונים נפרד, כיוון ש־JVM צורך כל מרווח זיכרון פנוי שתשאיר לו. התיעוד של CommaFeed מצביע על -Xmx256m כמגבלה קשיחה ועל OpenJ9 כ"חלופה יעילה יותר בזיכרון ל-HotSpot JVM", מה שמעיד על אופן צריכת הזיכרון שלו.

כאשר השרת אוזל מזיכרון, ה-out of memory killer של ה-kernel בוחר תהליך ומסיים אותו. dmesg -T מציג שורה כמו Out of memory: Killed process 1234 (java), והמכולה פשוט נעלמת מ-docker compose ps ללא הודעה בלוג של היישום, כיוון שהיישום מעולם לא הספיק לכתוב אותה.

כיצד מתנהלים שדרוגים בכל אחד מהם

• Miniflux: docker compose pull && docker compose up -d, כאשר העברות סכימה (schema migrations) מוחלות בעת ההפעלה אם RUN_MIGRATIONS=1 מוגדר. הסיכון בשדרוג אינו נובע מ-Miniflux, אלא מגרסת ה-major של PostgreSQL שמתחתיו.
• FreshRSS: משכו את ה-image החדש. בשימוש ב-SQLite אין מנוע מסד נתונים לשדרג, לכן תקלות נפוצות נובעות בדרך כלל מתוספים של צד שלישי שלא עודכנו.
• CommaFeed: משכו את גרסת ה-image התואמת למסד הנתונים שלכם. מעבר מ-latest-h2 ל-latest-postgresql אינו מעביר את הנתונים שלכם.
• yarr: החליפו את ה-binary ושמרו את קובץ מסד הנתונים. מאחר שלא שוחררה גרסה מאז v2.8 ביולי 2024 (נבדק באוגוסט 2026), בדרך כלל אין מה לשדרג.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. העברות סכימה מתבצעות אוטומטית, והממשק מפנה אתכם למסך העברה כאשר נדרש אישור.

בצעו גיבוי (dump) למסד הנתונים לפני כל אחד מהתהליכים הללו, לא אחרי.

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

העלות ברוחב פס של מרווח רענון

המספרים להלן הם חשבוניים, לא מדידה בפועל. הם מניחים 100 הזנות (feeds), בקשה אחת לכל הזנה בכל מרווח, ו-40 KB לכל תגובה. תעבורה אמיתית נמוכה יותר כאשר שרת מכבד בקשות מותנות, וגבוהה יותר כאשר ההזנות כוללות את מלוא טקסט המאמר.

[
  {
    "label": "Every 5 minutes",
    "fetches_per_month": "864,000",
    "gb_per_month": 34.6
  },
  {
    "label": "Every 15 minutes",
    "fetches_per_month": "288,000",
    "gb_per_month": 11.5
  },
  {
    "label": "Every 30 minutes",
    "fetches_per_month": "144,000",
    "gb_per_month": 5.8
  },
  {
    "label": "Every 60 minutes",
    "fetches_per_month": "72,000",
    "gb_per_month": 2.9
  }
]

מרווח של חמש דקות עבור 100 הזנות הוא 864,000 בקשות ובערך 34.6 GB בחודש. תשאול (polling) שעתי הוא 72,000 בקשות ובערך 2.9 GB. התוכנה Miniflux מופצת כאשר POLLING_FREQUENCY מוגדר ל-60 דקות, שזו השורה האחרונה בטבלה, וערך ברירת מחדל זה מתאים כמעט לכולם. מאמר לא מגיע מוקדם יותר רק בגלל שביקשת אותו בתדירות גבוהה יותר.

בקשות מותנות הן מה ששומר על המספר האמיתי נמוך מהחישוב החשבוני. קורא ששומר את ה-headers מסוג ETag ו-Last-Modified שהחזירה הזנה, שולח אותם בחזרה כ-If-None-Match ו-If-Modified-Since, ושרת שאין לו תוכן חדש משיב 304 Not Modified ללא גוף הודעה. החיבור עדיין דורש לחיצת יד (handshake), אך ללא ה-payload. הזנות שמתעלמות מבקשות מותנות מגישות לך את כל המסמך בכל פעם מחדש, לכן כמה הזנות גדולות יכולות להכריע את חשבון התעבורה שלך בעצמן.

תשאול אגרסיבי עלול גם להוביל לחסימה. שרת שמחליט שאתה מציף אותו משיב 429 Too Many Requests, וחלק מהאתרים משיבים 403 במקום זאת. Miniflux מתעדת את השגיאה האחרונה עבור ההזנה עצמה, לכן רשימת ההזנות היא המקום הראשון לבדוק כאשר הזנה אחת מפסיקה להתעדכן בעוד השאר ממשיכות לעבוד.

עדכוני RSS מפסיקים לעבוד, וקובץ OPML אינו מהווה גיבוי

עדכוני RSS מתיישנים מהר יותר ממה שנדמה לכם. דומיינים פוקעים, אתרים עוברים לפלטפורמות ללא תמיכה בעדכונים, וכתובת URL שסיפקה בעבר XML מתחילה להחזיר דף שגיאה בפורמט HTML עם קוד סטטוס 200 OK. המקרה האחרון הוא הבעייתי ביותר: הבקשה מצליחה, אך הניתוח (parsing) נכשל, והקורא שלכם מתעד שגיאת ניתוח במקום שגיאת רשת. פעם בשנה, מיינו את רשימת העדכונים לפי תאריך עדכון אחרון ומחקו את אלו שחדלו לפעול.

ייצוא OPML הוא בסך הכול רשימת המנויים שלכם. הוא מכיל כתובות URL של עדכונים ושמות תיקיות. הוא אינו שומר מצב קריאה, מאמרים מסומנים בכוכב, הגדרות פרטניות לכל עדכון, חוקי סינון או את תוכן המאמרים ששמרתם. ייבוא של קובץ OPML כזה להתקנה חדשה יחזיר לכם את העדכונים, אך כל מאמר שקראתם אי פעם יסומן שוב כלא נקרא.

הגיבוי שבאמת חשוב הוא בסיס הנתונים. עבור PostgreSQL, הפקודה pg_dump שצוינה לעיל מבצעת את כל העבודה. עבור קורא המבוסס על SQLite כמו FreshRSS או yarr, עצרו את תהליך הכתיבה והעתיקו את הקובץ, או בצעו העתקה עקבית בזמן שהשירות רץ באמצעות sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'". ביצוע cp פשוט לבסיס נתונים שמתבצעת אליו כתיבה עלול להניב קובץ שלא ייפתח מאוחר יותר, כיוון שההעתקה תתפוס כתיבה לא שלמה. לאחר מכן, העבירו את הקבצים הללו אל מחוץ לשרת לפי לוח זמנים; זהו בדיוק הייעוד של גיבויי restic בשרת VPS. שחזרו אחד מהם לתוך מכולה זמנית לפחות פעם אחת כדי לוודא שתהליך השחזור עובד.

קורא עדכוני RSS הוא אחד השירותים הזולים ביותר לאירוח עצמי, וזו הסיבה שהוא מופיע בכל רשימה של דברים שכדאי לארח באופן עצמאי בשנת 2026. הציבו מופע SearXNG באירוח עצמי לצדו, וכך גם הקריאה שלכם וגם החיפושים שלכם יישארו על חומרה שבשליטתכם.

FAQ

איזה קורא RSS בהתקנה עצמית צורך הכי פחות זיכרון?

yarr. מדובר בקובץ binary יחיד של Go עם SQLite מוטמע, כך שאין צורך בשרת מסד נתונים או ב־runtime נוסף, ותקרה של 128 MB היא די והותר עבורו. הפשרה היא בתחזוקה ובתכונות: הגרסה האחרונה שלו היא v2.8 מיולי 2024, והוא תומך ב־Fever API בלבד. אם אתם מחפשים פרויקט מתוחזק פעיל עם טביעת רגל דומה, Miniflux יחד עם PostgreSQL ב־320 MB היא התשובה העדיפה.

האם ניתן להריץ קורא RSS בהתקנה עצמית על שרת VPS עם 1 GB זיכרון?

כן. Miniflux עם PostgreSQL נכנס בתוך כ־320 MB כאשר מגדירים mem_limit בשני ה־containers, ו־FreshRSS עם SQLite נכנס ב־container אחד. השירות שיש להימנע ממנו ב-1 GB הוא ה־stack הרשמי של Tiny Tiny RSS, הכולל 4 שירותים כולל ה־PostgreSQL שלו. תמיד הגדירו מגבלות זיכרון, שכן container ללא הגבלה על שרת עמוס יגרום ל־kernel להרוג תהליך, ולרוב התהליך שייבחר יהיה מסד הנתונים ולא היישום הבעייתי.

אילו מהם עובדים עם אפליקציות RSS ל-iOS ו-Android?

Miniflux ו־FreshRSS תומכים גם ב־Fever API וגם ב־Google Reader API, כך שכמעט כל לקוח מובייל יתחבר אליהם. CommaFeed ו־yarr מציעים את Fever API בלבד. Tiny Tiny RSS משתמש ב־API משלו, לכן נדרש לקוח שנבנה עבורו. ב־FreshRSS עליכם גם להפעיל גישת API תחת Authentication ולהגדיר סיסמת API נפרדת בפרופיל, אחרת האפליקציה לא תצליח להתחבר בעוד שהאתר ימשיך לעבוד.

האם ייצוא OPML מהווה גיבוי לקורא ה-RSS שלי?

לא. OPML מכיל רק את כתובות ה־feeds והתיקיות, כך שהוא משחזר את רשימת המנויים שלכם בלבד. מצב הקריאה, פריטים מסומנים בכוכב, חוקי סינון ותוכן המאמרים – כולם נמצאים במסד הנתונים. גבו את מסד הנתונים עצמו באמצעות pg_dump עבור PostgreSQL, או פקודת .backup עבור SQLite, והעתיקו את התוצאה מחוץ לשרת.

האם Miniflux תומך ב-SQLite?

לא. תיעוד הפרויקט מציין שהוא "עובד עם PostgreSQL בלבד", וחיפוש טקסט מלא ממומש באמצעות תכונות של PostgreSQL, כך שאין מצב פעולה קל יותר למעבר. אם אתם מחפשים קורא feeds ללא container של מסד נתונים כלל, הריצו את FreshRSS עם ה־backend המובנה של SQLite או את yarr עם קובץ הנתונים המוטמע שלו.