Pleroma

Last reviewed Sep 13, 2026 · 774 words

Before you install Pleroma, decide whether you actually want Akkoma. Akkoma forked Pleroma in 2022, kept the same Elixir codebase, database schema and Mastodon-compatible API, and has since shipped features and fixes at a faster cadence. Pleroma itself is still maintained at git.pleroma.social, still ships releases, and still does the one thing it was built for: run a federated microblogging server for a handful of people on a 512 MB VPS. If you have a reason to prefer upstream, this guide is for you. If you do not, read it anyway, because nearly everything below applies to both.

The resource claim holds up

Pleroma is an Elixir application on the BEAM VM with PostgreSQL underneath and nothing else. No Redis, no Sidekiq, no separate streaming server, no Node build step at runtime. On a single-user instance I have seen the BEAM sit at 250 to 350 MB resident with Postgres adding another 100 to 200 MB, which is how the 512 MB minimum is possible. Mastodon on the same workload wants 2 to 4 GB across its Ruby, Node and Redis processes. The difference is not marginal; it is the gap between the cheapest VPS tier and the one three rungs up.

Federation traffic is handled sensibly too. Incoming ActivityPub deliveries go through Oban job queues inside the same process, so a burst from a busy relay slows things down rather than crashing a worker pool.

Installation is OTP release or Docker, and the OTP path is better documented

The project publishes prebuilt OTP releases for amd64 and arm64. The install script fetches one, creates a pleroma user, and puts configuration under /etc/pleroma/config.exs. The generator walks you through domain, admin email and database settings:

su pleroma -s $SHELL -lc "./bin/pleroma_ctl instance gen --output /etc/pleroma/config.exs --output-psql /tmp/setup_db.psql"
sudo -Hu postgres psql -f /tmp/setup_db.psql
su pleroma -s $SHELL -lc "./bin/pleroma_ctl migrate"

Pleroma listens on 127.0.0.1:4000 and expects a reverse proxy in front; the repository ships an nginx example, and Caddy needs a two-line site block. The Docker route works but is community-maintained rather than official, and every Pleroma admin I know who started on Docker moved to the OTP release within a year, because upgrades are pleroma_ctl update followed by pleroma_ctl migrate and that is hard to improve on.

Create your admin account from the shell, not the web:

./bin/pleroma_ctl user new admin [email protected] --admin

Frontends are pluggable, which is both the appeal and the confusion

Pleroma's backend serves whichever frontend you install. Pleroma-FE is the default and looks like a Twitter-era timeline. Because the Mastodon API is implemented, Mastodon's own web frontend, Soapbox, and most Mastodon mobile apps (Tusky, Ivory, Fedilab) work against a Pleroma server without modification. Switch frontends from the admin UI or with pleroma_ctl frontend install.

The trap is that "Mastodon API compatible" is not "Mastodon". Some clients probe for Mastodon-specific endpoints and behave oddly; character limits, custom emoji reactions and the chat feature are Pleroma extensions that other software does not understand. Expect small rough edges rather than outright failures.

Moderation tooling is the weak spot

"Less polished admin tools" is a fair summary. Pleroma's admin frontend covers user management, reports and instance blocks, but the MRF (Message Rewrite Facility) that does the real policy work is configured in config.exs. It is powerful: you can reject media from listed domains, force sensitive flags, strip follower-only visibility from specific instances, and write your own policies in Elixir. It is also invisible to anyone who does not read the config. On a single-user or friends-only instance this is fine. If you are opening registrations to strangers, the moderation UI in Mastodon, or the lighter and stricter GoToSocial, will save you more time than Pleroma saves you in RAM.

What I'd do

For a personal instance or a small group of friends: the OTP release on a 1 GB arm64 VPS, PostgreSQL on the same box, Caddy in front, pg_dump nightly to object storage. Pick Akkoma over Pleroma unless you have a specific attachment to upstream, because the fork is where fixes land first and migrating between the two is not guaranteed to stay easy forever. For anything with open registrations and more than 50 active users, budget the extra RAM and run Mastodon; the moderation tooling is worth a VPS tier. The rest of the social category covers the options that do not federate at all.