Wildebeest: ActivityPub and Mastodon-compatible server on Cloudflare, now archived

The README declares Wildebeest archived and no longer actively maintained

At the top of the README, Cloudflare has placed an explicit warning: the project has been archived and is no longer actively maintained or supported. The README invites anyone to fork the repository, explore the codebase, and adapt it to their needs. The last push to the repository was on 2026-04-23, and the repository has no tagged releases (the version in package.json is 0.0.1).

The archive notice coexists with an earlier promise in the same README that Cloudflare would continue to evolve the project. That promise predates the archive decision. Engineers reading the README today see a contradiction between the project's stated ambitions and its current status: the code is available, but no active maintenance path exists.

For teams considering a fork, the codebase is written in TypeScript, the license is a custom one GitHub cannot classify (see the LICENSE file at the repository root), and all deployment depends on Cloudflare services that are paid or quota-limited at scale.

Wildebeest runs entirely on Cloudflare primitives with no self-hosted server required

The design goal was to let anyone operate a Fediverse server and identity on their own domain without running infrastructure. Wildebeest achieves that by using only Cloudflare products for every layer of the stack, which means setup requires a Cloudflare account and the appropriate service plans rather than a VPS or a container registry.

Compute runs on Workers and Pages. State is stored in the D1 database for metadata and configuration, and in Durable Objects for coordination. Queues handle asynchronous messaging between components. Cloudflare Images handles media storage and delivery. Authentication is managed by Zero Trust Access, which accepts email-based login or any compatible identity provider.

That architecture means there is no database server process to run and no operating system to patch. It also means you cannot run Wildebeest anywhere that is not Cloudflare. Moving an instance to a different provider requires a full rewrite of the storage, compute, and auth layers, because every persistent and stateful component is a Cloudflare-specific service.

ActivityPub, WebFinger, NodeInfo, WebPush, and the Mastodon API are all implemented

Wildebeest implements ActivityPub for federation, WebFinger for actor discovery, NodeInfo for server metadata, WebPush for push notifications, and the Mastodon-compatible REST API for client access. Those five protocols together cover what a Mastodon server exposes, which is why existing Mastodon clients can connect to a Wildebeest instance without modification.

Federation works in both directions: a Wildebeest instance can connect to other Fediverse servers and receive connections from them. Client compatibility extends to the most popular Mastodon web, desktop, and mobile clients. Pinafore is listed by name as a compatible web client, and the README also notes a simple read-only web interface for exploring timelines and user profiles that ships with Wildebeest itself.

Publishing supports text and images at the time the README was written. Video support is described as coming soon, a statement that reflects the project's status at the time the README was last updated rather than its current state. Since the project is now archived, that video feature may never have shipped.

Authentication accepts email or any Cloudflare Access-compatible IdP, including GitHub and Google

Authentication is handled entirely by Cloudflare Zero Trust Access. An instance can be configured for email-based login or any IdP that Access supports. The README names GitHub and Google as examples of compatible providers.

User management covers single and multiple accounts under one instance, which means a Wildebeest deployment can serve more than one user identity on the same domain. Account settings include profile information, avatar, and header image. Account migration from Mastodon to Wildebeest is listed as a supported feature, following the documented Mastodon migration flow.

Account migration away from Wildebeest to another server is not mentioned in the README. The standard Mastodon migration process allows exporting followers and then importing them on a new server, but whether Wildebeest exports the necessary data is not documented in the README. Anyone planning to migrate off a Wildebeest instance should check docs/updating.md and the troubleshooting guide before committing to the platform.

Local development uses wrangler 2.7.1, D1 SQLite, and a mock database script

The package.json lists wrangler at version 2.7.1 as a dev dependency, and the scripts section defines a "dev" script that builds the frontend with yarn --cwd frontend build, applies D1 migrations locally through wrangler d1, and then starts a Pages dev server against the built frontend at frontend/dist. It uses a local D1 binding and a compatibility date of 2022-12-20, and injects binding values for INSTANCE_TITLE and INSTANCE_DESCR inline.

The "database:migrate" script applies migrations through the D1 CLI. In the package.json it is defined as:

yarn d1 migrations apply DATABASE

A separate "database:create-mock" script sets up a local development database by removing .wrangler/state/d1/DATABASE.sqlite3, running database migrations with CI=true to suppress prompts, and then calling node ./frontend/mock-db/run.mjs to populate mock data. These scripts assume wrangler is available as a local dev dependency and that the D1 binding is named DATABASE, which matches the NO_D1_WARNING=true wrangler d1 alias defined elsewhere in the scripts.

For production deployment, the README points to seven tutorial documents in the docs/ directory: requirements, getting-started, access-policy, supported-clients, updating, other-services, and troubleshooting. Those documents contain the actual steps to deploy a new Wildebeest instance to Cloudflare, and the README does not reproduce them inline. Anyone forking the project for their own deployment should start with docs/requirements.md to understand which Cloudflare services and account types are needed before writing a single config line.

Mastodon on a VPS is the alternative when an active, self-hostable Fediverse server is the goal

Mastodon is the direct alternative for running a Fediverse server. A standard Mastodon deployment runs on a Linux VPS with PostgreSQL, Redis, Elasticsearch, and nginx, and it is actively maintained with regular releases and security patches.

Wildebeest's difference was the absence of server management: no VPS, no database process, no cache process. For someone who already uses Cloudflare for their domain and wants a Fediverse presence without learning server administration, that tradeoff made sense when the project was active.

With the project now archived, the comparison shifts. Mastodon receives ongoing updates, whereas Wildebeest's last push was on 2026-04-23 and no further updates are planned. A new deployment of Wildebeest starts from a codebase that will not receive security fixes unless you fork it and maintain them yourself. For a production Fediverse instance that will receive real traffic and real users, Mastodon or another actively maintained server is the more defensible choice.

The license is custom, the version is 0.0.1, and Cloudflare services are required dependencies

GitHub classifies the Wildebeest license as Other because it does not match a recognized open-source license template. The LICENSE file at the repository root contains the actual terms. Anyone intending to fork and redistribute Wildebeest needs to read that file, since the custom terms may differ from what Apache 2.0 or MIT allows.

The version declared in package.json is 0.0.1, which indicates the project never reached a formal v1 release. Combined with the archive notice, this means the codebase should be treated as a reference implementation rather than a production-ready package.

The Cloudflare service dependencies are not optional. Workers, Pages, D1, Durable Objects, Queues, and Cloudflare Images are all used at runtime. Each has its own pricing tier and quota limits at the Cloudflare level. A fork that aims to remove the Cloudflare dependency would need to replace every one of those layers with alternatives, which is a substantial rewrite.

Editorial conclusion

Wildebeest is worth examining if you want a serverless Fediverse instance on Cloudflare and are prepared to fork and maintain it yourself, since the README explicitly says the project is no longer actively maintained or supported. Skip it if you need active security patches or a supported upgrade path. Before forking, read docs/requirements.md to confirm which Cloudflare services are required, check docs/supported-clients.md for client compatibility, and verify that wrangler 2.7.1 still deploys to the current Workers platform, since that dependency has not been updated since the last push on 2026-04-23.

Frequently asked questions

Official sources

1. cloudflare/wildebeest on GitHub
2. Issues
3. README