A lightweight ActivityPub server

One binary.
A whole fediverse server.

littleFedi is a small ActivityPub server written in Go. It ships as a single static executable with a server-rendered web interface, a Mastodon-compatible client API, a durable federation queue, moderation tools, and optional PostgreSQL and S3 support. No runtime to install, no services to wire together.

Beta software. The source is not published yet.

Why this exists

I have spent a long time running servers for other people, and a good part of the last few years running fediverse infrastructure for a community. What I kept wanting was something I could put on a small machine, in a corner, and then stop thinking about. No runtime to keep current, no database server to babysit, no container stack, no build pipeline that breaks the week I am travelling.

littleFedi is that. One static binary with an embedded database, an interface that works with JavaScript switched off, and operations you can actually follow: a health endpoint, a readiness endpoint, a queue you can look at, and backups that restore. Small is where it starts, not where it stops: the same binary takes PostgreSQL, object storage and several processes when you need them. What it is really trying to be is the server you stop thinking about.

It is also written for the machines I actually use. FreeBSD, illumos, Linux, NetBSD and OpenBSD each get their own operations guide and their own service definitions, and none of them is treated as the default with the others bolted on afterwards.

None of this is here to replace anything. It takes what the fediverse platforms do well, fills a few gaps, and adds one more independent implementation, because a monoculture is a bad outcome even when the single crop is a good one. More plurality, more portability, less waste.

"Little" is meant affectionately, not as a measurement. littleFedi does not make you choose in advance between a personal server and a large community: it can grow with you. And it is not only trying to consume fewer resources. It is trying to ask for fewer sacrifices: less given up in control, in understanding, in portability, and in the freedom to pick the computer your own space lives on.

What you get

  • One static binary

    Built with CGO disabled. No interpreter, no shared libraries, no external database unless you want one. Copy it to the machine and run it.

  • Real federation

    ActivityPub, WebFinger, shared inboxes, relays, RSA HTTP signing, RSA and Ed25519 verification, and FEP-8b32 Object Integrity Proofs.

  • Chronological timelines

    Home, local, federated, list, tag, direct and bubble, all in time order. The one ranked view lives on a separate page you have to open on purpose.

  • Works without JavaScript

    Pages are rendered on the server. Posting, reading, settings and moderation all work with scripting off, and the composer keeps its plain textarea fallback.

  • Mastodon-compatible API

    OAuth, the REST API, WebSocket and SSE streaming, and Web Push. Clients that already speak Mastodon connect to it.

  • Static blogs

    Turn selected public posts into a plain static site with permalinks, an Atom feed, hashtag indexes and four themes, without leaving the fediverse.

  • littleMesh

    Federate from behind home NAT or CGNAT with no public address, no DNS name and no inbound port. The transport changes, ActivityPub does not.

  • Ten themes and your own CSS

    Four skins that dress the interface as a macOS, Plasma, GNOME or Xfce application, four light and dark modes, and a per-account stylesheet.

  • SQLite or PostgreSQL

    SQLite is embedded and needs nothing. PostgreSQL and S3 are build tags, so the default binary never carries their dependencies.

  • Operations you can see

    Health and readiness endpoints, Prometheus metrics, a durable queue with retries, built-in backups, and written runbooks for when it goes wrong.

Small enough for a Pi, big enough for a cluster

There is one preset for constrained machines. Set low_power = true and littleFedi picks one database connection, one queue worker, one image decoder, a bounded memory cache, a 13 million pixel ceiling on decoded images, a 1600 pixel cap on stored uploads, cheaper thumbnail resampling and no dynamic gzip.

low_power = true

[media]
cache_remote = "off"

At the other end, build with make build-postgres-s3 and several processes share one PostgreSQL database and one S3 bucket, with cross-process streaming and exactly one process doing housekeeping. That profile works, but read the caveats before you rely on it.

Numbers on this page describe defaults and presets, not benchmark results. Measure on the device you actually own before making capacity claims.

Runs where you run

Every supported system has its own guide: where files go, which service manager starts the process, which firewall admits the two public ports, and where the logs land.

  • FreeBSD
  • illumos
  • Linux
  • Alpine Linux
  • NetBSD
  • OpenBSD
  • macOS (development)
  • Windows (development)
  • Solaris (builds)
  • DragonFly BSD (builds)
  • AIX (builds)
  • Plan 9 (builds)
  • Android (builds)

Release binaries cover amd64, arm64 and 32-bit ARM, plus the less common Linux architectures the Go toolchain supports. macOS and Windows binaries are built for development and evaluation; there is no operations guide for them.

Beyond those, make allreleases builds 40 targets across 12 operating systems, Solaris, DragonFly BSD, AIX, Plan 9 and Android included, because the matrix is derived from the Go toolchain rather than hand-typed. Those binaries link; nobody has run them in anger. The full matrix says exactly which column each one is in.

Compare the platform conventions

See it running

littleOne is the official instance, and it runs the same server described on this site. It is invite only for now, which is the advice given to every other operator here: do not open registration until somebody is willing to moderate.

You do not need an account to look. Signed-out visitors land on the local timeline, so the interface, the rendering and the themes are all visible from outside, with scripting off if you prefer.

What it does not do yet

A features page that only lists wins is an advertisement. Here is the other half, so nobody discovers it after the install.

  • The source is not published yet. This site is a preview of the project, not a download page.
  • Trends, suggestions and endorsements answer with empty results on purpose. There is no instance-wide popularity feature.
  • Remote custom emoji are parsed and rendered. Uploading and managing local custom emoji is not implemented.
  • Static blog generation is a single-process feature. Leave it off in a multi-process deployment.
  • The PostgreSQL and S3 profile is not certified yet. The checks it has to pass are written down, and they are still open.
  • No release is certified until the external drills pass: real peers, a real object store, a real device, a real restore, a real soak.

Where to go next