Fedify: a TypeScript framework for building ActivityPub servers

The server side of the fediverse, as a library

Fedify is a TypeScript library for building federated server apps powered by ActivityPub and other standards, the so-called fediverse. The stated aim is to eliminate the complexity and boilerplate code of building a federated server, so that you can focus on your business logic and user experience.

That framing matters because the fediverse is a set of overlapping specifications. ActivityPub is the W3C recommendation for the protocol itself, ActivityStreams is the vocabulary of objects and activities that travels inside it, WebFinger is how a domain is mapped to an actor, and there are several ways to sign a request. Any one of them is a weekend; all of them together, done correctly enough to interoperate with other people's servers, is a project.

The feature list is what the framework provides out of the box. There are type-safe objects for the Activity Vocabulary, including some vendor-specific extensions, so your code gets a typed object model rather than a bag of dictionaries. There is a WebFinger client and server. There is support for HTTP Signatures and for HTTP Message Signatures, which are different specifications with different properties. There is support for Object Integrity Proofs under FEP-8b32 and for Linked Data Signatures. There are middlewares for handling webhooks, and the NodeInfo protocol is implemented. There is enhanced interoperability with Mastodon and other popular fediverse software, and there is integration with various web frameworks, plus a CLI toolchain for testing and debugging.

The licence is MIT, the site is fedify.dev, and the framework is published both to JSR and to npm under the @fedify scope.

The signature story is the hard part

The list of signature mechanisms deserves attention, because that is where federated software actually breaks.

HTTP Signatures is the older scheme, tracked as a draft at the IETF tools site, and it is what most of the existing fediverse speaks. HTTP Message Signatures is the successor, published as RFC 9421, and it is the one the project also implements. Linked Data Signatures is the JSON Web Signature based scheme that signs the document body rather than the request, and Object Integrity Proofs under FEP-8b32 is a newer proposal for making the payload tamper evident.

Having all four means a server can verify requests signed in any of the ways its peers use, and can sign in whichever way the receiving server expects. That is interoperability work, and it is the kind of work that is invisible until it is missing, at which point your server is silently invisible to a slice of the network.

The example directory includes a dedicated rfc-9421-test/ example, which is a good signal about how seriously this is taken. A test harness whose only purpose is to exercise the RFC 9421 implementation suggests the authors have been bitten by the details.

The other side of the same problem is Object Integrity Proofs, which is a FEP, a Fediverse Enhancement Proposal, rather than a published standard. Supporting a proposal in flight is a choice with a cost, and the fact that it is listed as a shipped feature tells you the project tracks the edge of the specification rather than only the settled parts of it.

A monorepo of framework integrations

Fedify is a monorepo with several packages, each providing a different piece, and the main one is @fedify/fedify, the core of the framework. The rest are integrations and drivers.

The tooling packages are @fedify/cli, a CLI toolchain for testing and debugging, and @fedify/create, which creates a new Fedify project. The web framework integrations include @fedify/adonisjs, @fedify/astro, @fedify/elysia and @fedify/express, and the storage and platform drivers include @fedify/amqp for AMQP and RabbitMQ, @fedify/denokv for Deno KV, @fedify/cfworkers for Cloudflare Workers and @fedify/backfill for ActivityPub backfill support.

Two of them are unusual enough to call out. @fedify/debugger is an embedded ActivityPub debug dashboard, which is the kind of feature that tells you the author has run a federation server and fought with it. @fedify/backfill exists because a server that was not federating before, or that wants to catch up, needs to ask other servers for activity it missed, and that is a hard problem to solve in the general case.

The distribution model is worth noticing as well. The core package, the CLI and several of the drivers are published to JSR, the JavaScript ecosystem registry, as well as to npm, which means the package works in a Deno project without a node_modules directory and in a Node project without a Deno-style import map. The framework integrations that are npm only are the ones tied to a Node-oriented framework.

The root package.json is a monorepo orchestrator rather than a package. It has a single script, and it shows the shape of the build:

{
  "scripts": {
    "prepare": "pnpm -r run build:self"
  },
  "pnpm": {
    "onlyBuiltDependencies": [
      "esbuild"
    ],
    "patchedDependencies": {
      "@netlify/[email protected]": "patches/@[email protected]"
    }
  }
}

The prepare script runs the build in every workspace package, the pnpm field allows esbuild to run its install scripts, and a patched dependency is declared for @netlify/blobs with the patch file kept in the repository's patches/ directory.

The examples tell you which stack to pick

The examples/ directory is the best guide to which combination of runtime and framework is actually supported, and it is long.

The framework coverage includes adonisjs, astro, cloudflare-workers, elysia, express, fastify, h3, hono-sample, koa, next-integration, next14-app-router, next15-app-router, nuxt, solidstart and sveltekit-sample, plus netlify-astro and a fresh/ example.

The Next.js entries are worth a second look, because there are three of them. next-integration, next14-app-router and next15-app-router are separate examples, which suggests the App Router integration is version-sensitive and the project maintains a working example per major version rather than one that claims to work everywhere.

The remaining examples are about the protocol rather than the stack: actor-lookup-cli, custom-collections, lint, monitoring, rfc-9421-test and test-examples. The monitoring example in particular suggests that running a federation server in production needs its own instrumentation, which anyone who has done it will recognise.

The runtimes are equally varied. The repository topics list bun, deno and nodejs, and the root contains both deno.json with deno.lock and a pnpm-workspace.yaml with pnpm-lock.yaml, so the monorepo is developed in a way that supports both package managers. There is a.devcontainer/ for a reproducible development environment, a mise.toml for tool versions, and a scripts/ directory for the build and release automation.

The tutorials mirror the examples, with a learning the basics of Fedify tutorial, then ones for building a federated microblog, a federated image sharing service, an Astro blog and a threadiverse community platform. There is also a migrating from other libraries guide, which tells you that a meaningful number of projects are moving to it from something else.

Project governance, spelled out in the repository

Several files in the root are about how the project is run rather than what it does, and they are unusual enough to be worth reading.

FEDERATION.md is the interesting one. In a project whose whole job is talking to other people's servers, a document about federation rules is the equivalent of a protocol compliance policy, and having it in the repository rather than only on a website means it changes with the code.

Then there is the modern tooling set. AI_POLICY.md states a position on AI contributions, CLAUDE.md and AGENTS.md and the.claude/ and.agents/ directories carry instructions for coding agents, and.claude-plugin/ and skills-lock.json show that the project ships agent tooling as part of itself. context7.json is a configuration for a documentation context service, cspell.json is the spell checker dictionary, and.repomixignore and repomix.config.json configure a repository packing tool.

The change management is conventional and well set up. CHANGES.md is the rendered changelog and changes.d/ holds the per-change fragments, which is a common convention for keeping changelog fragments. CONTRIBUTING.md is the contribution guide, SECURITY.md is the security policy, and SPONSORS.md acknowledges the funding.

For a project of this size that is a well-organised repository, and the practical benefit is that a contributor can find the rules rather than guess them. The one risk is that the number of configuration surfaces has grown, and the AI policy and the agent instructions in particular are documents that did not exist a few years ago.

Maintenance across three version lines at once

The release pattern is unusual and worth understanding, because it affects which version you install.

Three tags were published on the same day, 2026-10-12: 2.2.19, 2.3.14 and 2.4.4. Three lines, three different patch levels, one release run. That is what maintaining a framework with several supported release lines looks like, and it is a good sign, because it means the 2.2 line is still receiving fixes rather than being abandoned the moment 2.3 appeared.

The last push was on 2026-10-14, two days after those tags, so the main branch is already ahead of the newest release. The repository is not archived.

The MIT licence is the permissive one, which matters here for a different reason than usual. A federation server is a public-facing service that has to interoperate with software you do not control, and the licence of the framework you build it with determines what you can do with the result.

The project is also unusually social for a library. There is a Matrix chat space, GitHub Discussions, and a Mastodon account with the #Fedify hashtag, plus a hackers.pub account with a follower badge. For a protocol ecosystem, a place to ask questions about interop details is a genuine part of the tooling, because the specification leaves room for interpretation and the community is where the interpretations converge.

Editorial conclusion

Adopt Fedify if you are building a server that has to talk to Mastodon and the rest of the fediverse and you would rather not implement WebFinger, HTTP Message Signatures and ActivityPub inbox and outbox handling yourself. Do not adopt it if you are building a client rather than a server, since the framework is oriented at servers publishing their own actors. Before you start, read FEDERATION.md for the rules the project follows, check the installation page for the runtime you use, since the packages ship on both JSR and npm and the examples cover Deno, Node and Bun, and plan for the fact that signature verification is the part that will generate support load.

Frequently asked questions

Official sources

1. fedify-dev/fedify on GitHub
2. License: MIT
3. Project website
4. README
5. Releases