Misskey

Last reviewed Aug 26, 2026 · 824 words

Budget 2 GB of RAM and a disk that grows by gigabytes a month, and Misskey is a delightful thing to run. Budget a Raspberry Pi and a 32 GB card and it is a slow-motion disaster, because federation means every server you touch sends you its media, its emoji and its posts, and Misskey caches them enthusiastically. The catalogue's 2048 MB minimum is the honest floor for a single-user instance with a handful of federated contacts; a 20-user instance wants 4 GB and a PostgreSQL that someone has tuned. Get the storage plan right and you get the most playful software in the fediverse: emoji reactions instead of a single like, a drive for files, antennas that follow keywords across the network, pages, channels, and an interface that users customise to the point of unrecognisability.

Postgres, Redis and a reverse proxy are non-negotiable

Misskey is a Node.js application with PostgreSQL for everything durable and Redis for queues, caching and rate limits. The repository ships a docker-compose.yml that runs all three; the pieces you edit are .config/default.yml for Misskey and .config/docker.env for the database credentials. The keys that matter on day one:

url: https://mk.example.com/
port: 3000
db:
  host: db
  port: 5432
  db: misskey
  user: misskey
  pass: change-me
redis:
  host: redis
  port: 6379
id: 'aidx'

url is permanent. Federation identifies your users by it, and changing it later means every remote server has stale records of you; pick the domain you will keep. The id format is likewise fixed at first run. Put a reverse proxy in front of port 3000 with a generous body size limit, because uploads and federated media go through it. First visit creates the admin account and the instance settings; the federation queue will then start pulling in whatever your first follows bring.

Put media on object storage before it matters

Local media storage works and then quietly becomes the largest thing on the server. Misskey supports S3-compatible object storage in the control panel under Object Storage: endpoint, bucket, region, keys, and a public URL prefix. A self-hosted MinIO, Backblaze B2 or Cloudflare R2 all work. Do this before the first month is over. Migrating existing files later is possible but manual, and the remote-media cache can be told to expire after a set number of days, which is the second largest disk saver. The Postgres database itself will still grow with notes and federation metadata; a single-user instance with active follows accumulates a few gigabytes a year.

The upgrade routine, and why it bites

Misskey uses date-based versions (year, then release number) and ships often. Each upgrade is pull, migrate, restart; the compose setup runs migrations on start, and against a large database they can take minutes. The two rules: read the release notes for breaking changes, which the project flags clearly, and take a database dump first. The .config directory and Postgres are the whole state; media, if you followed the previous section, is in the bucket. The "complex configuration" con in the catalogue is really about this ongoing care rather than the initial setup.

Search deserves a mention. Full-text search over notes is minimal by default; connect a Meilisearch instance in default.yml and it becomes fast and typo-tolerant, at the cost of another container and a few hundred megabytes.

Misskey versus Mastodon and the forks

Mastodon is the conservative choice: Ruby, more widely documented, a larger third-party app ecosystem, and a plainer feature set. Misskey is more fun and more opinionated, with rich text (MFM), reactions, and a web UI that most users prefer to any app. Clients written for the Mastodon API are hit and miss on stock Misskey; users rely on the web UI as a PWA or on Misskey-specific clients. The fork family matters here: Sharkey and Iceshrimp add Mastodon-API compatibility and moderation tools on top of the Misskey base, so if a Mastodon client for your users is a hard requirement, one of the forks is the practical answer. For the smallest possible footprint, GoToSocial runs in a few hundred megabytes with none of the flourishes, and Akkoma sits between. The social category has the full list.

What I'd do

A VPS with 4 GB and 80 GB of disk, the official compose with Postgres and Redis, a reverse proxy in front, a domain you will keep. Object storage for media configured on day one, remote media cache set to expire after 30 days, nightly pg_dump to somewhere else. Close open signups unless you intend to moderate, and update monthly after reading the notes. If your users will insist on Mastodon mobile apps, run Sharkey instead; if you want a personal outpost on the fediverse and enjoy custom emoji, Misskey is the one I would pick.