Plume

Last reviewed Sep 13, 2026 · 793 words

Plume does one thing no other self-hosted blog engine does well: several authors publishing to a shared blog that people on Mastodon can follow like an account. It is Rust, AGPL-3.0, light on memory at 256 MB, and its commit graph has thinned since about 2022. Those two facts have to be weighed together. If you want a group publication that federates, Plume is still the most direct route; if you are one person who wants a federated blog, WriteFreely is the better-maintained choice and I would go there first.

What Plume does that WriteFreely doesn't

WriteFreely's model is one person, one or a few blogs, minimal Markdown, and federation of posts as ActivityPub articles. Plume's model is an instance hosting many blogs, each blog having many authors, with a real editor, cover images, tags, comments that arrive from the fediverse as replies, and likes and boosts that show up under the post. Follow a Plume blog from a Mastodon account and new articles land in your timeline; reply there and the reply appears as a comment on the article. For a collective (a hackerspace, a research group, a small magazine) that wants a shared masthead without a WordPress install, that combination is exactly right. Mastodon is the audience; Plume is the long-form surface.

The editor is Markdown with a live preview and drafts, media uploads go to a per-instance gallery, and there is a basic search. There is no theme marketplace, no plugin system, and the design is the design.

Setup: Postgres, plm, and one secret

Plume ships a Docker image, plumeorg/plume, and runs against PostgreSQL by default (SQLite builds exist but I would not use them for anything public). The environment needs three things: BASE_URL set to your public hostname, DATABASE_URL pointing at Postgres, and ROCKET_SECRET_KEY, a base64 secret that signs sessions. The server listens on port 7878. After the containers start, the plm command-line tool does the one-time work: plm migration run creates the schema, plm instance new names the instance and sets its domain, and plm users new --admin creates you. Mail settings (MAIL_SERVER, MAIL_USER, MAIL_PASSWORD) are optional but enable password resets.

Put Caddy or another TLS-terminating proxy in front and get BASE_URL right before the first federation event, because ActivityPub actor IDs embed the domain, and changing it later means every remote follower points at a dead URL. That warning applies to every fediverse server, and Plume is no exception.

Federation in practice

Once live, each blog is an ActivityPub actor at https://yourdomain/~/blogname/. Remote users search that handle, follow, and receive articles. Plume also federates comments both ways and shows remote authors' avatars, which works with Mastodon reliably and with smaller servers mostly. Two limits to know. Plume does not fetch and display the wider fediverse timeline; it is a publishing tool, not a social client, so you still want a Mastodon or GoToSocial account for conversation. And because the instance is the federation unit, a shared Plume for a community means one domain and one moderation policy for every blog on it, which suits a collective and does not suit strangers.

The maintenance reality

At 2,222 stars Plume has a fan base and a small volunteer team, and releases have been infrequent since the original maintainers stepped back. That means dependencies age, Rust toolchain updates lag, and a security advisory in a library can sit unaddressed longer than you would like. In my view it is still safe to run behind a reverse proxy for a low-traffic publication, provided you watch the repository and are willing to rebuild the image yourself if a fix lands unreleased. It is not something I would put in front of a large audience or rely on for a business. If federation is a nice-to-have rather than the point, Ghost or WordPress with the official ActivityPub plugin now cover most of the same ground with active teams behind them, and the blogging category lays the options out.

What I'd do

For a group of three or more authors who want a federated publication and can tolerate a project in maintenance mode: Plume with Postgres, one blog per topic, and a calendar reminder to check the repository every couple of months. For a single writer: WriteFreely, which is smaller, faster to set up, and actively released. For a group that mostly wants a good blog and only incidentally wants Mastodon followers: WordPress plus the ActivityPub plugin, because you will never be the person maintaining the federation code. That is how I would replace Medium today, and Plume earns its slot only in the first case.