TL;DR / Summary: A single-user fediverse instance is a 2 vCPU, 2 GB server with fast disk and a domain you intend to keep. Pick the domain first because handles cannot be renamed, cap remote media caching before it fills the disk, and back up the database to storage outside the VPS.
What a one-person instance actually needs
A single-account ActivityPub server is closer to a small blog than to a social network. Expect 2 vCPU, 2 GB of RAM, and 40 GB of SSD to be comfortable for one active person following a few hundred accounts, with headroom for a rebuild and a database dump.
The resources that matter most are disk input/output and memory, in that order. Federation writes many small rows, and a host with slow shared storage turns every timeline refresh into a visible pause. Cheap does not have to mean oversold, but it often does, so run a quick disk latency check on arrival.
Why a lightweight server beats full Mastodon here
Full Mastodon expects a Rails stack, Sidekiq workers, Redis, and Postgres, which is a lot of moving parts for an audience of one. Lighter ActivityPub implementations written in Go or with SQLite support can run comfortably in a gigabyte or two and restart in seconds after a reboot.
Fewer components also means a smaller attack surface and a shorter upgrade path. You are the entire operations team, so choosing software that survives a busy week without attention is a feature rather than a compromise.
Sizing storage before the media cache fills it
Remote media is the quiet consumer. Every avatar, header, and attachment your instance fetches is cached locally, and a follow-heavy account can accumulate several gigabytes in a month. Plan for growth, and check disk usage weekly for the first month.
Set a retention window for cached remote media rather than keeping everything forever. Most implementations let you prune media older than a set number of days; thirty to ninety days is a reasonable balance between snappy timelines and a disk that stays half empty.
Local media you upload is different, and it should be backed up rather than pruned. Split the two policies early: cache is disposable, your own attachments are not. Confusing them is how people delete their own posting history while tidying up a cache.
The domain decision you cannot undo
Your handle is built from the domain, so @[email protected] is permanent in practice. Moving to a new domain later means new handles, broken mentions, and followers who have to find you again. Buy the domain before the server, and register it at a registrar you control.
Pick something short, pronounceable, and yours. Avoid a domain tied to a hosting brand, a joke that will age badly, or a spelling you will have to correct verbally. This is the one part of the build where a small extra spend is clearly justified.
Reverse proxy, TLS, and the ports you actually open
Federation needs HTTPS on port 443 and a valid certificate, so put a reverse proxy in front of the app and let it handle certificates automatically. Expose only 80, 443, and SSH; close everything else, including the app’s internal port, to the public interface.
Test federation from another instance rather than from your own browser. Search for your handle from a different server, follow it, and confirm that posts appear in both directions. A local page load proves nothing about whether the outside world can reach you.
Moderation when the audience is one person
You still need domain blocks, because a single account can be mentioned into unpleasant threads. Start with a small default blocklist, review notifications daily for the first fortnight, and set your account to require approval for follow requests if you want a quiet timeline while you learn the tooling.
Keep a written note of every block and why it was added. Six months later you will not remember, and an undocumented block list becomes impossible to audit or migrate. That note also stops you from re-blocking a domain you already decided to tolerate for a specific reason.
Turn on notifications for mentions only, not for the whole federated timeline. A single-user instance has no moderation team, so the cheapest safety measure is simply not reading everything that arrives.
Backups for a social graph you cannot rebuild
Back up the database nightly and copy the archive off the VPS. The followers and following tables are the parts you cannot recreate; posts and media are recoverable from other sources at a cost, but relationships are not. Test a restore once, on a spare machine, before you need it.
Store the backup somewhere with versioning so a corrupted dump does not overwrite the last good one. This is a ten-minute setup that separates a hobby instance from a project you will eventually abandon out of frustration.
The first month is a tuning exercise, not a launch
Do not promote the handle widely in week one. Follow a small set of accounts, watch memory and disk, and adjust media retention and worker counts before you invite anyone. Most single-user instances fail on storage or on an upgrade that was never rehearsed, not on federation itself.
After thirty days you will know whether the plan is right. If memory sits near the limit, move to 4 GB; if disk is filling, shorten media retention. A cheap VPS is a fine home for one voice as long as you keep measuring it with affordable VPS server headroom in mind rather than hoping the numbers stay still.
