TL;DR / Summary: A personal RSS reader on a cheap VPS is one of the few services that genuinely fits in 1 GB of RAM. Run a budget VPS with a modest database, cap feed refreshes, and prune old articles so the box stays fast without an upgrade.
Why feed readers suit small servers
Feed readers look like heavy applications because the popular hosted versions are heavy. The self-hosted reality is different: a reader is mostly a database with a polling loop. It stores text, occasionally an image URL, and a read/unread flag. There is no video transcoding, no image pipeline, no user-facing search at scale.
That profile matches a low-end VPS almost perfectly. The workload is bursty rather than sustained: a cron job wakes up, fetches a few dozen XML files, writes rows, and sleeps. A single shared vCPU handles that comfortably when the batch is spread out.
The trap is not CPU or RAM. It is unbounded growth—feeds that return thousands of historical items, databases that never prune, and logging that fills the disk. Solve those and the server stays cheap for years.
Sizing the box honestly
For one or two users, 1 GB of RAM with 1 vCPU is workable if you avoid running a full control panel. If you insist on a panel, plan for 2 GB because the panel’s own services will consume a large share of the memory before your reader even starts.
Disk matters more than CPU. A feed reader with a year of articles from a hundred busy feeds can reach a few gigabytes with a database that is not pruned. Twenty-five gigabytes of SSD is a reasonable floor; ten is possible but leaves little room for logs and backups.
- 1 vCPU — sufficient; refresh jobs are short and sequential
- 1 GB RAM — comfortable without a control panel, tight with one
- 25 GB SSD — enough for text feeds and a few weeks of backups
- 1 TB transfer — generous; text traffic is tiny
Check the provider’s acceptable-use policy for scheduled tasks. A refresh every fifteen minutes across two hundred feeds is ordinary, but some budget hosts enforce vague limits on “resource-intensive cron jobs.”
Container or bare install
A single Docker Compose stack with the reader and its database is the easiest thing to rebuild. Two containers, one volume for data, one for the database, and a reverse proxy if you already run one.
On 1 GB of RAM, watch the database container’s memory ceiling. Left unbounded, MySQL or PostgreSQL will happily claim whatever it can and leave the web process to swap. Set an explicit limit and tune the database’s buffer pool to something small but not absurd.
Bare-metal installs use less memory and are easier to debug with the tools already on the box, but they are harder to migrate. For a service you will keep for years, the container’s rebuildability usually wins.
A minimal memory budget for a 1 GB box
Reserve roughly 40 percent for the database container, 25 percent for the application, and keep the rest for the OS, SSH, and spikes. That is not a precise science, but it prevents the common failure where the database grows until the web process is killed by the kernel.
Disable any bundled full-text search index unless you actively use search. Search indexes are the single largest avoidable memory and disk cost in a small reader deployment.
Refreshing feeds without hammering the box
Refresh frequency should follow how often the sources actually publish. A news site might publish twenty times a day; a personal blog publishes twice a month. Uniform fifteen-minute polling wastes both bandwidth and CPU on the quiet sources.
Where the reader supports per-feed intervals, set them. Where it does not, stagger refreshes by hashing feed IDs across a window so the work spreads across the hour instead of arriving in one burst.
Cap the number of items fetched per feed on first subscription. Some feeds return the entire archive, and importing five thousand historical posts from each of forty feeds is what turns a lean install into a slow one in a single afternoon.
Fetch the last fifty items, not the last five thousand. You will not read the archive anyway.
Pruning and backups
Set a retention rule for read articles and enforce it. Ninety days is generous for most readers; thirty days is enough for news-heavy subscriptions. Unread articles can be kept longer, but even those should have a ceiling so the database cannot grow without bound.
Back up the database nightly and keep a week of copies, plus one monthly copy off the server. A reader’s value is its accumulated state—subscriptions, stars, read positions—which is precisely the data you cannot recreate.
Test the restore once. A backup you have never restored is a rumour, and restores are the one operation where a 1 GB box with a busy database will genuinely struggle, so give the database container more memory temporarily during a restore rather than letting it crawl.
Access and hardening
Put the reader behind TLS, even for personal use. Feed URLs often contain private tokens, and credentials in URLs are a real pattern in this space. A certificate costs nothing and prevents the worst failure mode.
Restrict administrative endpoints by IP if you have a stable address, and enforce a strong password plus two-factor authentication if the app supports it. A personal reader is a small target, but automated scanners do not care about the size of your audience.
Keep automatic security updates on for the host, and pin the application image version so an unattended rebuild does not surprise you with a breaking change mid-week.
When the cheap VPS stops being enough
The honest upgrade signals are database size approaching disk limits, refresh jobs overlapping because they take longer than the interval, and memory pressure forcing regular swaps. None of these appear in the first year for a single user.
If you add family members, expect memory to grow before CPU does. Four users on the same box is usually fine at 2 GB; forty users is a different product with different architecture.
For a personal reader, a modest instance from affordablevpsserver.com lasts a long time precisely because the workload is predictable. Buy for the database growth you expect at year two, not for the archive you imagine importing on day one.
