가이드

작성자 Matt Connor 2026-08-05 · 업데이트됨 2026-08-07

VPS용 셀프 호스팅 RSS 리더 5종 비교 분석

Q: 1 GB VPS에서 셀프 호스팅 RSS 리더를 운영할 수 있습니까?

네, 가능합니다. 각 컨테이너에 mem_limit을 설정하면 Miniflux와 PostgreSQL을 320 MB 이내에서 운영할 수 있으며, FreshRSS는 SQLite를 사용하여 단일 컨테이너로 구성할 수 있습니다. 1 GB 환경에서 피해야 할 것은 공식 Tiny Tiny RSS 스택입니다. 이 스택은 자체 PostgreSQL을 포함하여 4개의 서비스로 구성되기 때문입니다. 항상 메모리 제한을 설정하십시오. 제한이 없는 컨테이너가 메모리를 가득 채우면 커널이 프로세스를 강제 종료하는데, 이때 문제가 되는 애플리케이션 대신 데이터베이스가 종료되는 경우가 많습니다.

Miniflux, FreshRSS, CommaFeed, yarr, Tiny Tiny RSS의 메모리 사용량과 DB 요구 사항을 비교합니다. API 지원 여부와 업그레이드 편의성을 확인하여 자신의 VPS 환경에 최적화된 RSS 리더를 선택하십시오.

소규모 VPS에 적합한 셀프 호스팅 RSS 리더는 무엇인가

Miniflux는 소규모 VPS에 설치하기 가장 적합한 셀프 호스팅 RSS 리더입니다. PostgreSQL과 함께 실행되는 단일 Go 바이너리 형태입니다. Fever 및 Google Reader API를 지원하므로 타사 모바일 앱과 연동할 수 있으며, 업그레이드 또한 docker compose pull 한 번으로 완료됩니다. 확장 기능이 필요하거나 SQLite를 포함한 단일 컨테이너 구성을 선호한다면 FreshRSS를 선택하십시오.

VPS의 디스크 공간을 할애할 가치가 있는 RSS 리더는 Miniflux, FreshRSS, CommaFeed, yarr, Tiny Tiny RSS 총 5가지입니다. 이 페이지에서는 각 서비스의 실질적인 차이점, 즉 스택별 메모리 요구량, 필수 데이터베이스 종류, 모바일 앱 연동을 위한 동기화 API, 그리고 업그레이드 시의 작업 내용을 비교합니다. 여기에 기재된 모든 수치는 프로젝트 공식 발표 자료이거나 단순 산술 계산 결과이며, 출처를 명시하였습니다. 이 내용은 사용자의 하드웨어 성능을 측정하는 벤치마크가 아니므로, 실제 환경에서의 성능은 docker stats를 사용하여 직접 측정하십시오.

다섯 가지 리더, 각 단락별 요약

Miniflux는 Go로 작성되었으며 정적으로 컴파일된 단일 바이너리로 배포됩니다. 문서에서는 "PostgreSQL에서만 작동한다"는 단 하나의 필수 의존성을 명확히 밝히고 있습니다. SQLite 모드는 지원하지 않습니다. REST API, Fever 호환 API, Google Reader 호환 API를 제공하며 OPML 가져오기 및 내보내기를 지원합니다. 전문 검색은 PostgreSQL이 담당하며, 이것이 데이터베이스가 선택 사항이 아닌 이유 중 하나입니다.

FreshRSS는 PHP 기반이며 웹 서버와 애플리케이션을 하나의 컨테이너에서 실행합니다. SQLite가 기본 데이터베이스이므로 별도의 서비스가 필요 없지만, 대규모 설치를 위해 PostgreSQL과 MySQL도 지원합니다. Google Reader API와 Fever API를 지원합니다. 설치 방법은 VPS에서의 FreshRSS 설치 가이드에서 이미 다루었으므로, 이 페이지에서는 설치 과정을 반복하는 대신 다른 서비스와 비교합니다.

CommaFeed는 Quarkus 기반의 Java 애플리케이션으로 Google Reader를 모방한 레이아웃을 갖추고 있습니다. 데이터베이스는 런타임이 아닌 빌드 시점에 결정되므로, 프로젝트는 데이터베이스별로 별도의 이미지를 배포합니다. 내장 H2 데이터베이스용 athou/commafeed:latest-h2, PostgreSQL용 athou/commafeed:latest-postgresql, 그리고 MySQL 및 MariaDB용 변형 이미지가 있습니다. REST API와 Fever 호환 API를 제공합니다.

yarr(yet another rss reader)는 SQLite가 내장된 단일 Go 바이너리이며 컨테이너가 전혀 필요하지 않습니다. 기본적으로 ./yarr가 127.0.0.1:7070 포트에서 대기합니다. 플래그는 간단합니다. -addr 0.0.0.0:7070 -auth alice:secret은 비밀번호를 설정하여 네트워크에 공개하며, -db /data/yarr.db는 데이터베이스 경로를 지정합니다. Fever 호환 API를 지원합니다. 최신 태그 버전은 2024년 7월에 릴리스된 v2.8이며, 2026년 8월 기준으로 확인했으므로 활발한 개발보다는 완성된 소프트웨어로 간주하는 것이 좋습니다.

Tiny Tiny RSS는 다섯 가지 리더 중 가장 오래되었으며 실행 시 가장 무겁습니다. 공식 Docker 설정은 PostgreSQL 컨테이너, PHP-FPM 애플리케이션 컨테이너, 피드를 가져오는 별도의 업데이트 컨테이너, 그리고 앞단에 위치한 nginx 컨테이너까지 총 4개의 서비스로 구성됩니다. 문서는 "이 설정은 PostgreSQL을 사용한다"고 명시합니다. 자체 JSON API를 보유하고 있으며, Android 클라이언트와 여러 타사 앱이 이를 사용합니다. Fever는 지원하지 않습니다.

각 스택에 필요한 메모리 용량

아래 수치는 측정값이 아닌 예산이며, 소규모 VPS에서 각 스택이 유지해야 할 메모리 상한선입니다. CommaFeed의 수치는 프로젝트에서 공식적으로 게시한 예시이며, 컨테이너를 256 MB로 제한합니다. 다른 수치들은 피드 가져오기(feed fetcher)를 위한 여유 공간을 고려한 상한선입니다. 피드 가져오기는 새로고침 주기가 시작될 때 메모리 사용량이 급증하는 부분입니다.

ChartMemory ceiling per reader stack, in MB

label

containers

mem_limit_mb

yarr (SQLite)

128

FreshRSS (SQLite)

256

CommaFeed (H2)

256

Miniflux + Postgres

320

Tiny Tiny RSS

640

The data behind this chart

[
  {
    "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는 단일 바이너리와 하나의 SQLite 파일로 구성되며, 별도의 데이터베이스 서버나 언어 런타임이 필요하지 않으므로 128 MB로 가장 낮습니다. Miniflux는 2개의 컨테이너를 합쳐 320 MB가 필요하며, 이 중 대부분은 Miniflux 자체가 아닌 PostgreSQL이 차지합니다. Tiny Tiny RSS는 4개의 컨테이너를 합쳐 640 MB를 사용하는 예외적인 경우입니다. 애플리케이션, 업데이트 도구, 데이터베이스, 웹 서버가 각각 별도의 힙을 사용하는 4개의 독립된 프로세스로 동작하기 때문입니다.

이 수치들을 막연한 기대치가 아닌 실제 제한값으로 설정하십시오. Docker Compose의 메모리 제한에서 관련 구문과 컨테이너가 상한선에 도달했을 때 발생하는 동작을 다룹니다. 제한이 없는 컨테이너는 서버 자원이 가득 찼을 때 정상적으로 종료되지 않습니다. 커널이 임의의 프로세스를 희생양으로 선택해 강제 종료하며, 이때 선택되는 프로세스는 종종 메모리 압박을 유발한 컨테이너가 아닐 수도 있습니다.

각 리더가 강제하는 데이터베이스

이 다섯 가지 도구 사이의 가장 큰 운영상 차이점은 데이터베이스입니다. 이는 사용자 인터페이스의 차이보다 훨씬 중요한 결정인데, 백업 절차와 업그레이드 위험을 결정하기 때문입니다.

Miniflux와 공식 Tiny Tiny RSS 설정은 PostgreSQL을 요구합니다. 이를 통해 실제 전문 검색(full text search)과 안전한 동시 쓰기가 가능해집니다. 대신 두 번째 컨테이너와 볼륨이 필요하며, 한 가지 반복적인 문제가 발생합니다. 공식 PostgreSQL 이미지는 메이저 버전 간의 데이터 마이그레이션을 제자리에서 수행할 수 없습니다. Tiny Tiny RSS 문서에도 이 점이 명시되어 있으며, "공식 PostgreSQL 컨테이너는 메이저 버전 간 데이터 마이그레이션을 지원하지 않는다"고 경고합니다. 현실적인 선택지는 이전 메이저 버전을 고정(pin)하여 사용하거나, pg_dump 및 pg_restore를 사용하여 덤프 및 복원을 수행하는 것입니다. 1~2년에 한 번씩 이 작업을 수행할 계획을 세워야 합니다.

SQLite는 FreshRSS와 yarr의 기본 데이터베이스입니다. 파일 하나로 구성되며 서버, 포트, 비밀번호가 필요 없습니다. 수백 개의 피드를 구독하는 1인 사용자에게는 충분히 잘 작동하지만, 여러 사용자가 동시에 쓰기 작업을 수행하면 속도가 느려집니다. 이때부터 FreshRSS의 PostgreSQL 옵션이 제값을 하기 시작합니다. yarr는 v2.7부터 PostgreSQL 지원을 추가했지만, 내장 파일 방식을 사용하는 것이 일반적입니다.

H2는 CommaFeed의 기본 내장 데이터베이스입니다. CommaFeed는 이미지가 빌드될 때 데이터베이스가 결정되므로 시작하기 전에 잠시 고려해야 합니다. 나중에 H2에서 PostgreSQL로 전환하는 것은 단순한 설정 변경이 아닙니다. 다른 이미지를 사용해야 하며 직접 데이터 마이그레이션을 수행해야 하므로, 1년 치 읽기 기록이 쌓이기 전에 미리 결정하십시오.

모바일 앱이 작동하는지 확인

이 질문은 예상보다 훨씬 중요한 의미를 갖습니다. 웹 인터페이스는 피드 리더 사용 방식의 절반에 불과하기 때문입니다.

Miniflux는 Fever 호환 API와 Google Reader 호환 API를 모두 지원하므로 대부분의 iOS 및 Android 클라이언트와 연결할 수 있습니다. FreshRSS 역시 동일한 두 가지 API를 지원하며, 자체 문서에서는 Google Reader API를 모든 기능을 지원하는 "최고"의 선택으로, Fever API는 "기능이 제한적이고 효율성이 떨어지는" 방식으로 평가합니다. 또한 FreshRSS는 앱에서 로그인하기 전에 두 단계를 거쳐야 합니다. Authentication 설정에서 "Allow API access (required for mobile apps)"를 활성화한 다음, 사용자 프로필에서 API 비밀번호를 생성하십시오. API 비밀번호 설정을 건너뛰면 웹 로그인은 정상적으로 작동함에도 앱에서는 인증 실패가 발생하는데, 어디를 확인해야 할지 모르면 혼란을 겪을 수 있습니다.

CommaFeed와 yarr는 Fever 호환 API만 제공하므로 Fever를 지원하는 클라이언트에서는 작동하지만, Google Reader API만 지원하는 앱에서는 사용할 수 없습니다. 반면 Tiny Tiny RSS는 자체 API를 사용하므로 해당 API 전용으로 작성된 클라이언트가 필요합니다. 300개의 피드를 가져오기 전에 사용하려는 앱이 해당 리더를 지원하는지 반드시 확인하십시오.

1 GB 메모리 서버를 위한 작동 가능한 compose 파일

이 구성은 2026년 8월 기준 Miniflux 프로젝트의 공식 Docker 예제를 수정한 Miniflux 스택입니다. 공개 포트는 루프백 주소에 바인딩되었고, 리슨 주소는 명시적으로 설정되었으며, 두 컨테이너 모두 메모리 제한이 적용되어 있습니다.

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이기 때문입니다. 컨테이너 내부에서 루프백에 바인딩된 프로세스는 공개된 포트를 통해 접근할 수 없으므로, 컨테이너는 정상으로 보이지만 연결이 재설정되는 현상이 발생합니다. 볼륨 경로 /var/lib/postgresql은 PostgreSQL 18 버전과 일치합니다. 17 이하 버전은 데이터를 /var/lib/postgresql/data에 저장하므로, 잘못된 경로를 마운트하면 데이터 디렉터리가 볼륨에 위치하지 않게 되어 컨테이너를 재생성할 때 모든 데이터가 사라집니다. 127.0.0.1:8080:8080는 포트가 공용 인터넷에 노출되지 않도록 합니다. 주소 지정 없이 포트를 공개하면 ufw가 관리하지 않는 체인에 규칙이 작성되기 때문입니다. Docker 포트가 ufw를 우회하는 이유에서 해당 메커니즘을 설명하며, Traefik 리버스 프록시를 사용하면 그 앞에 TLS를 적용할 수 있습니다.

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

docker compose ps을 실행하면 두 서비스가 모두 실행 중이어야 하며, 데이터베이스는 healthy 상태로 표시되어야 합니다. Miniflux가 처음 시작될 때 스키마 마이그레이션 로그가 출력되는데, 이는 RUN_MIGRATIONS=1가 트리거하는 작업입니다. docker stats --no-stream은 실시간 메모리 사용량을 출력하며, 이 값을 위 차트의 제한 수치와 비교해야 합니다. 만약 Miniflux 컨테이너가 반복적으로 재시작된다면 로그를 확인하십시오. connect: connection refused는 PostgreSQL이 연결을 수락할 준비가 되기 전에 Miniflux가 먼저 시작되었음을 의미합니다. 이는 service_healthy 조건이 방지하는 상황이므로, 해당 조건이 편집 과정에서 누락되지 않았는지 확인하십시오. Compose가 처음이라면 VPS에서의 Docker Compose 기초에서 파일 구조를 먼저 살펴보시기 바랍니다.

1 GB 서버에 설치하기 어려운 서비스

Tiny Tiny RSS는 피해야 할 서비스입니다. 공식적인 4개 서비스 스택은 다른 작업을 하지 않는 1 GB VPS에서 겨우 돌아가며, 데이터베이스를 사용하는 다른 애플리케이션이나 리버스 프록시와 함께 운영할 수 없습니다. 4개의 서비스는 곧 4개의 오버헤드를 의미하며, 그중 하나는 PostgreSQL이기 때문입니다.

CommaFeed는 설치가 가능하지만, H2 이미지를 사용하고 프로젝트 예제에 명시된 256 MB 제한을 설정했을 때만 가능합니다. 작은 서버에서 문제가 되는 조합은 JVM과 별도의 데이터베이스 서버를 함께 운영하는 경우입니다. JVM은 여유 메모리가 있으면 그만큼을 모두 점유하려 하기 때문입니다. CommaFeed 문서에서는 -Xmx256m을 하드 리밋으로, OpenJ9를 "HotSpot JVM보다 메모리 효율적인 대안"으로 언급하고 있는데, 이는 메모리가 어디에 소모되는지를 잘 보여줍니다.

서버의 메모리가 부족해지면 커널의 OOM(Out of Memory) 킬러가 프로세스를 선택하여 강제로 종료합니다. dmesg -T에는 Out of memory: Killed process 1234 (java)과 같은 메시지가 나타나며, 애플리케이션은 로그를 기록할 기회조차 얻지 못하므로 docker compose ps에서 아무런 메시지 없이 컨테이너가 사라지게 됩니다.

각 서비스의 업그레이드 방식

Miniflux: docker compose pull && docker compose up -d을 사용하며, RUN_MIGRATIONS=1이 설정된 상태에서 시작 시 스키마 마이그레이션이 적용됩니다. 업그레이드 위험 요소는 Miniflux 자체가 아니라 그 기반이 되는 PostgreSQL 메이저 버전입니다.
FreshRSS: 새 이미지를 가져옵니다(pull). SQLite를 사용하면 업그레이드할 데이터베이스 엔진이 없으므로, 일반적으로 발생하는 문제는 업데이트되지 않은 타사 확장 기능에서 비롯됩니다.
CommaFeed: 데이터베이스와 일치하는 이미지 버전을 가져옵니다. latest-h2에서 latest-postgresql으로 전환해도 데이터는 이전되지 않습니다.
yarr: 바이너리를 교체하고 데이터베이스 파일을 유지합니다. 2026년 8월 확인 기준으로 2024년 7월 v2.8 이후 릴리스가 없으므로, 일반적으로 업그레이드할 항목이 없습니다.
Tiny Tiny RSS: docker compose pull && docker compose up -d를 사용합니다. 스키마 마이그레이션은 자동으로 실행되며, 확인이 필요한 경우 인터페이스가 마이그레이션 화면으로 리다이렉트합니다.

이 작업들을 수행하기 전에는 반드시 데이터베이스 덤프를 생성하십시오. 작업 후에 생성하는 것은 의미가 없습니다.

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

새로 고침 주기가 대역폭에 미치는 비용

아래 수치는 측정값이 아닌 산술적인 계산 결과입니다. 피드 100개, 피드당 주기별 1회 요청, 응답당 40 KB를 가정합니다. 서버가 조건부 요청을 준수하면 실제 트래픽은 이보다 낮아지고, 피드에 전체 기사 본문이 포함되면 더 높아집니다.

ChartMonthly fetches and bandwidth for 100 feeds at 40 KB per response

label

fetches_per_month

gb_per_month

Every 5 minutes

864,000

34.6

Every 15 minutes

288,000

11.5

Every 30 minutes

144,000

5.8

Every 60 minutes

72,000

2.9

The data behind this chart

[
  {
    "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개 피드에 대해 5분 주기를 설정하면 864,000회의 요청이 발생하며, 월간 약 34.6 GB의 트래픽이 소모됩니다. 1시간 단위 폴링은 72,000회의 요청과 약 2.9 GB의 트래픽을 발생시킵니다. Miniflux는 POLLING_FREQUENCY를 60분으로 설정하여 배포하며, 이는 해당 차트의 마지막 행에 해당합니다. 이 기본값은 거의 모든 사용자에게 적합합니다. 더 자주 요청한다고 해서 기사가 더 빨리 도착하지는 않습니다.

조건부 요청은 실제 트래픽을 산술적 계산값보다 낮게 유지하는 핵심 요소입니다. 피드가 반환한 ETag 및 Last-Modified 헤더를 저장하는 리더는 이를 If-None-Match 및 If-Modified-Since로 다시 전송하며, 새로운 내용이 없는 서버는 본문 없이 304 Not Modified으로 응답합니다. 연결 시 핸드셰이크 비용은 발생하지만 페이로드는 전송되지 않습니다. 조건부 요청을 무시하는 피드는 매번 전체 문서를 전송하므로, 몇 개의 대용량 피드만으로도 전송 비용이 크게 증가할 수 있습니다.

과도한 폴링은 차단으로 이어질 수 있습니다. 서버가 사용자의 요청을 공격으로 판단하면 429 Too Many Requests로 응답하며, 일부 사이트는 403를 반환하기도 합니다. Miniflux는 피드 자체에 마지막 오류를 기록하므로, 다른 피드는 정상인데 특정 피드만 업데이트가 멈췄다면 피드 목록을 가장 먼저 확인해야 합니다.

피드는 사라지며, OPML 파일은 백업이 아닙니다

피드는 예상보다 빠르게 부패합니다. 도메인 만료, 피드를 지원하지 않는 플랫폼으로의 이전, XML을 제공하던 URL이 200 OK 상태 코드를 반환하는 HTML 오류 페이지로 바뀌는 경우가 발생합니다. 마지막 사례가 가장 까다롭습니다. 가져오기(fetch)는 성공하지만 파싱(parse)은 실패하며, 리더는 네트워크 오류가 아닌 파싱 오류를 기록하기 때문입니다. 1년에 한 번씩 피드 목록을 마지막 업데이트 순으로 정렬하고, 응답이 없는 피드는 삭제하십시오.

OPML 내보내기는 구독 목록일 뿐입니다. 여기에는 피드 URL과 폴더 이름만 포함됩니다. 읽음 상태, 별표 표시한 기사, 피드별 설정, 필터 규칙, 저장한 기사 본문은 포함되지 않습니다. 이 OPML을 새로 설치한 환경에 가져오면 피드는 복구되지만, 읽었던 모든 기사가 다시 읽지 않음 상태로 표시됩니다.

진정한 백업은 데이터베이스입니다. PostgreSQL의 경우 위에서 언급한 pg_dump 명령이 전체 작업의 전부입니다. FreshRSS나 yarr 같은 SQLite 기반 리더는 쓰기 작업을 중단한 뒤 파일을 복사하거나, sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'"를 사용하여 실행 중에도 일관된 복사본을 생성해야 합니다. 쓰기 작업이 진행 중인 데이터베이스를 단순히 cp으로 복사하면, 복사 시점에 완료되지 않은 쓰기 데이터가 캡처되어 나중에 파일을 열 수 없게 될 수 있습니다. 이러한 파일은 일정에 따라 서버 외부로 전송해야 하며, 이것이 바로 VPS에서의 restic 백업이 필요한 이유입니다. 또한 복구 절차가 정상적으로 작동하는지 확인하기 위해 최소 한 번은 스크래치 컨테이너에 복구해 보십시오.

피드 리더는 직접 운영하기에 가장 저렴한 서비스 중 하나이며, 이것이 2026년에 직접 호스팅할 가치가 있는 서비스 목록에 항상 포함되는 이유입니다. 그 옆에 직접 호스팅하는 SearXNG 인스턴스를 함께 배치하면 읽기 작업과 검색 작업 모두 본인이 제어하는 하드웨어 내에서 유지할 수 있습니다.

FAQ

메모리를 가장 적게 사용하는 셀프 호스팅 RSS 리더는 무엇입니까?

yarr입니다. SQLite가 내장된 단일 Go 바이너리 형태이므로 별도의 데이터베이스 서버나 런타임이 필요 없으며, 128 MB 정도의 메모리 제한으로도 충분히 원활하게 동작합니다. 다만 유지보수와 기능 면에서 타협이 필요합니다. 최신 릴리스는 2024년 7월에 나온 v2.8이며, Fever API만 지원합니다. 비슷한 수준의 리소스를 사용하면서 활발하게 개발되는 프로젝트를 원한다면 320 MB 환경의 Miniflux와 PostgreSQL 조합이 더 나은 선택입니다.

1 GB VPS에서 셀프 호스팅 RSS 리더를 운영할 수 있습니까?

네, 가능합니다. 각 컨테이너에 mem_limit을 설정하면 Miniflux와 PostgreSQL을 320 MB 이내에서 운영할 수 있으며, FreshRSS는 SQLite를 사용하여 단일 컨테이너로 구성할 수 있습니다. 1 GB 환경에서 피해야 할 것은 공식 Tiny Tiny RSS 스택입니다. 이 스택은 자체 PostgreSQL을 포함하여 4개의 서비스로 구성되기 때문입니다. 항상 메모리 제한을 설정하십시오. 제한이 없는 컨테이너가 메모리를 가득 채우면 커널이 프로세스를 강제 종료하는데, 이때 문제가 되는 애플리케이션 대신 데이터베이스가 종료되는 경우가 많습니다.

이 중 iOS 및 Android RSS 앱과 연동되는 것은 무엇입니까?

Miniflux와 FreshRSS는 Fever 호환 API와 Google Reader 호환 API를 모두 지원하므로 거의 모든 모바일 클라이언트와 연결할 수 있습니다. CommaFeed와 yarr은 Fever API만 제공합니다. Tiny Tiny RSS는 자체 API를 사용하므로 전용 클라이언트가 필요합니다. FreshRSS의 경우 Authentication 설정에서 API 접근을 활성화하고 프로필에서 별도의 API 비밀번호를 설정해야 합니다. 그렇지 않으면 웹사이트는 정상 작동하더라도 앱에서는 로그인이 실패합니다.

OPML 내보내기가 RSS 리더의 백업이 됩니까?

아니요. OPML은 피드 URL과 폴더 정보만 담고 있으므로 구독 목록을 복구할 뿐입니다. 읽음 상태, 별표 표시 항목, 필터 규칙, 기사 본문 등은 모두 데이터베이스에 저장됩니다. PostgreSQL은 pg_dump을 사용하여, SQLite는 .backup 명령어를 사용하여 데이터베이스 자체를 백업하고 해당 파일을 서버 외부로 복사해야 합니다.

Miniflux는 SQLite를 지원합니까?

아니요. 프로젝트 문서에 따르면 Miniflux는 "PostgreSQL에서만 작동"하며, 전체 텍스트 검색 기능도 PostgreSQL의 기능을 활용하여 구현되었으므로 더 가벼운 모드로 전환할 수 없습니다. 별도의 데이터베이스 컨테이너 없이 피드 리더를 운영하고 싶다면 기본 SQLite 백엔드를 사용하는 FreshRSS나 내장 파일을 사용하는 yarr을 선택하십시오.

#rss #self-hosted #docker#miniflux#freshrss