2026-09-03
ActivityPub is probably the best-known protocol in the open social web today. After experimenting with several implementations, I wanted to see how far I could take a personal, self-hosted presence without committing to a large Mastodon-style stack.
I tried seven approaches: a minimal Fedify implementation, two publishing plugins, one bridge, and three more complete Fediverse implementations. They occupy very different points on the spectrum of convenience, autonomy, and resource usage.
ActivityPub is somewhat like a combination of email and RSS. Actors have inboxes and outboxes, and when someone follows you, your posts are delivered to their inbox.
One unintuitive consequence is that historical visibility depends heavily on federation. If nobody follows you and your activities have never been delivered to another server, searching for your account elsewhere may not reveal your older posts. Your own server remains the canonical place to find them.
The ecosystem is excellent: many publishing platforms have ActivityPub support, and Mastodon-compatible software is everywhere. The tradeoff is that full-featured platforms can be tightly bundled and relatively demanding to host. Discovery can also be difficult on a small, single-user instance.
That led me to a simpler question: how much can I keep under my own control while still having a usable Fediverse presence?
| Implementation | UI / UX | Configuration and Deployment | Hosting | Features | Resource Usage | Custom Handle Domain | Bridgy Support |
|---|---|---|---|---|---|---|---|
| My Fedify | Minimal | Easy | Deno, Deno KV | Publishing only | Low | Yes | No |
| Ech0 | Integrated | Integrated | Docker, Bare Metal | Publishing only | Low | No | No |
| idno/idno | Integrated | Integrated | PHP, MySQL | Publishing only | Low | No | No |
| Starling | Full web UI | Easy | PHP | Full | Low | No | No |
| Bridgy Fed | Source-dependent | Hosted | Hosted | Bridged | N/A | Yes | No |
| GoToSocial | Client-dependent | Moderate | Docker, Bare Metal | Full | Low | Yes | Yes |
| snac2 | Minimal web UI | Moderate | sudo required | Full | Very low | No | Yes |
The biggest distinction is whether ActivityPub is the identity itself or simply another publishing destination. Plugins and bridges are convenient because your existing site remains authoritative; dedicated servers give you much more control, but also make you responsible for the entire social application.
I started with Fedify and Deno, treating an ActivityPub actor as what it fundamentally is: a collection of JSON API responses and federation endpoints.
After several days of trial and error, I eventually got a minimal publisher working. The actor was discoverable by Mastodon servers, follow requests were handled, followers were stored, and new notes were delivered to their inboxes.
I also discovered that the handle domain can be separate from the server itself. With the appropriate redirects, the public identity can live on one domain while the actual application runs somewhere else.
It was a useful proof of concept, but I stopped there. Building the inbox, frontend, authentication, and Mastodon API compatibility would turn a small publisher into an entire social platform. I wanted to know that it could be done, not reinvent Mastodon.
Publishing plugins take the opposite approach. They add ActivityPub to an existing application, but generally don't turn that application into a complete Fediverse client.
Ech0 is a Go-based note-taking application that initially caught my attention because of its ActivityPub support.
The integration is pleasantly simple: enable federation, configure the actor, and your notes can appear on Mastodon once you have followers. It works well as an extension of an existing notes application.
Unfortunately, ActivityPub support has been deprecated in newer versions. I had to deploy an older release for testing, and the newer versions also introduced a considerably more complicated build environment.
Customization is limited because parts of the actor profile are effectively hardcoded. It works, but it feels like an ActivityPub publishing feature rather than a first-class social identity.
idno takes a similar approach, but with tighter integration into the IndieWeb application.
The plugin works and publishes posts directly to the Fediverse without requiring Bridgy. You can also see follower counts, which is a nice improvement over Ech0.
The downside is operational complexity: the asynchronous pipeline needs to be configured, and updates are more involved than I would like. Recent releases also moved away from prebuilt packages, making Composer-based installation more practical.
Interoperability was mixed in my testing. Posts appeared on Starling, but Mastodon did not consistently receive them. For an existing idno installation, however, it remains an appealing low-maintenance way to add ActivityPub publishing.
Bridgy Fed approaches the problem from another direction: instead of self-hosting an ActivityPub server, it bridges an existing identity into the Fediverse.
I tried both its Bluesky and IndieWeb integrations. The Bluesky side was especially impressive. Because Bluesky has a rich event stream, changes can often be reflected into ActivityPub almost immediately, making the bridge feel surprisingly seamless.
The IndieWeb side is more dependent on Webmentions and RSS, so publication can lag. RSS discovery also cannot always distinguish notes from articles correctly, which can produce undesirable ActivityPub representations.
Bridgy Fed also supports using your own domain as the visible handle through redirects. The important distinction is that the ActivityPub actor remains a bridge: you control it indirectly through the source identity rather than owning the actor server itself.
That tradeoff is worthwhile for the interoperability alone. Bluesky and ActivityPub can effectively become two views of the same social presence.
The next category provides an actual Fediverse actor rather than just a publishing endpoint. You get an inbox and can participate in activities such as likes and replies.
The downside is storage. A server that actively follows and reads other people can accumulate a surprising amount of data, so small deployments need some housekeeping.
Single-user instances also have a discovery problem: if nobody follows you, there is little reason for other servers to encounter your content. You generally need to participate in the network before the network starts bringing people to you.
Starling was the first production-oriented ActivityPub server I tried.
It is remarkably easy to deploy: essentially PHP hosting, a domain, and some storage. The web UI is polished enough to serve as a Mastodon alternative by itself, with an admin panel and support for several mobile clients.
Mastodon interoperability was excellent in my testing.
The major limitation is that Starling does not support a separate handle domain. If you want your actor to live at the same domain as your personal website while the application runs elsewhere, GoToSocial is a better fit.
For someone who wants a self-hosted actor with a proper built-in interface and has enough storage, Starling is probably my favorite option.
GoToSocial is probably the most compelling dedicated server for a small self-hosted deployment.
Its split-domain deployment is particularly interesting. You can have the public handle use your top-level domain while the actual GoToSocial instance runs on a subdomain. That makes it possible to keep a personal website at example.com while hosting the Fediverse service at social.example.com.
It is written in Go, straightforward to deploy, and supports a broad range of platforms, including BSD.
The main difference from Starling is the UI: GoToSocial intentionally does not provide a full web frontend. You interact through compatible clients instead. That keeps the server considerably lighter while still providing a complete ActivityPub implementation.
For self-hosting, this is probably the best balance I found between flexibility, completeness, and resource usage.
snac2 is the minimalist option.
Written in portable C, it feels almost aggressively small compared with modern social platforms. I like that. It provides the core ActivityPub functionality without trying to become a massive social application.
The deployment story is less convenient, though. Because binary releases are not readily available, practical installation generally means using a package on a supported system or compiling it yourself. In my testing, that effectively meant having a real VPS rather than relying on shared hosting or a pubnix.
If GoToSocial feels lightweight, snac2 feels like the version designed by someone who really, really wanted to minimize the amount of software running on their server.
There isn't one winner because these implementations solve different problems.
For an existing website: use an ActivityPub plugin or Bridgy Fed. You keep your canonical site and add federation without operating another social application.
For maximum control: Fedify is the most flexible, but only if you actually want to build and maintain the missing pieces yourself.
For a polished self-hosted experience: Starling is excellent if PHP hosting and storage are available.
For a flexible Fediverse server: GoToSocial is probably my overall pick. Split-domain support, broad hosting compatibility, and a complete ActivityPub implementation make it unusually well suited to personal infrastructure.
For the smallest possible server: snac2 is fascinating, provided you are comfortable with its more hands-on deployment requirements.
The biggest lesson for me is that ActivityPub does not require a Mastodon-sized server. There is a surprisingly large space between "install Mastodon" and "write ActivityPub yourself". Plugins, bridges, lightweight servers, and custom implementations let you choose exactly how much infrastructure you actually want to own.