Bonfire: a federated community framework built from Elixir extensions

What Bonfire actually is, and who the repository is written for

Bonfire is not a single social network you install and log into. The README describes it as "an open-source framework for building federated digital spaces where people can gather, interact, and form communities online", and the repository reflects that: it ships configurations for several flavours rather than one product. Ember is the minimal base, Social is the classical social networking build, Community adds groups and topics, and Open Science, Coordination and Cooperation sit at alpha or pre-alpha stages. The README states that the release candidate of Bonfire Social 1.0 is ready, while other flavours are at alpha or beta.

The intended audience is split in three, and the README says so directly. Developers are pointed at docs/HACKING.md for a local setup and docs/topics/JUST.md for the CLI commands. Users are pointed at the Community Manual. Community organisers and sysadmins are pointed at docs/DEPLOY.md. If you are none of those three, the repository has little for you: there is no hosted signup, and the homepage is a project site, not a service.

Extensions as the unit of customisation

The architectural claim is that every feature and every UI element lives in an extension, with the code for each extension in a separate repository. A flavour is then a selection of extensions plus default settings. That is a real design decision with consequences: enabling groups and topics in Community is not a config flag inside one codebase, it means pulling in the extension that provides them. The README frames this as letting communities "enable or disable these extensions to customize their space according to their needs and vision".

The cost is that the surface area of a deployment is not visible from this repository alone. If you want to know what Community actually contains, you have to read the community flavour repository. The same applies to Social and the rest. For an operator, that means auditing several repositories before you can answer a simple question like which extensions handle federation or which ones touch the database schema.

The stack is stated plainly: Elixir, Phoenix with LiveView, Surface for the official web UI, and PostgreSQL as the primary database. A GraphQL API is exposed for developers who want to build custom frontends. The README lists Elixir, Phoenix/LiveView, Surface and PostgreSQL as prerequisite knowledge, so this is not a project that hides its stack to widen the audience.

Release channels decide whether federation is safe

The README gives a table that matters more than any feature list. Stable releases are described as thoroughly tested and federation safe. Release candidates are federation safe and aimed at early adopters who want to catch issues before stable. Beta releases should be federated "with caution". Alpha releases are marked as not federation safe, with the instruction to turn federation off.

That is an unusually direct statement, and it should shape deployment plans. Running an alpha flavour with federation enabled is explicitly outside what the project supports. The recent release history shows the project is still moving through these channels: v1.0.7 appeared on 2026-08-30, and two v1.0.8 beta builds followed on 2026-09-08. The last push to the repository was on 2026-09-10.

A second constraint follows from the flavour split. Choosing Social gets you the release candidate. Choosing Coordination or Cooperation gets you pre-alpha code. The channel is not a global setting you can upgrade out of; it is attached to the flavour you picked.

Installing Bonfire with Docker and just

The repository's own entry point is the justfile, and the Makefile exists only to tell you so: running make prints "Please use 'just' instead". The justfile documents the command runner at just.systems and notes that variables are loaded from a .env file. The default flavour is ember and Docker is used for everything, and both are read through env_var_or_default, so you can override them before running a recipe.

The justfile defines WITH_DOCKER with three documented values: total for using Docker for everything, easy for using Docker only for services like the database and compiled utilities, and no to opt out. It also defines DB_DOCKER_IMAGE, which defaults to postgis/postgis with version 17-3.5 on x86_64 and a ghcr.io/baosystems/postgis image on aarch64, with a comment noting the project only relies on features available in Postgres 12 or newer.

The development compose file is the other concrete artefact. It builds from Dockerfile.dev, mounts the repository at /opt/app, and reads config/dev/.env. It maps the web service to 127.0.0.1:4000 on the host and PostgreSQL to 127.0.0.1:5432, and it sets POSTGRES_HOST=db inside the container. Note that the search and graph services are commented out in that file, and the web service depends only on db, with the health condition also commented out.

services:
  web:
    build:
      context: .
      dockerfile: "Dockerfile.dev"
    ports:
      - "127.0.0.1:4000:${SERVER_PORT}"
    environment:
      - POSTGRES_HOST=db
    env_file:
      - config/dev/.env

For a real deployment the README points at docs/DEPLOY.md, and the repository also carries docker-compose.release.yml and a CloudronManifest.json. The README does not describe the steps in DEPLOY.md, so read that file rather than guessing from the development compose setup.

Where Bonfire is the wrong choice

The clearest limitation is documentation coverage relative to the number of moving parts. The README states that the code for each extension lives in a separate repository, which means neither the README nor this repository can tell you what a given extension does to your database or your federation behaviour. An operator who wants a single auditable codebase will find the opposite here.

The second is the stability matrix. If you need a federated instance that behaves predictably today, only the Stable and RC channels are described as federation safe, and the README only names Social 1.0 as a release candidate. Community is beta, Open Science is alpha or beta, and Coordination and Cooperation are pre-alpha. Picking a flavour for its features rather than its channel is a documented way to end up running code the project says may be broken.

The third is operational. The README does not document rollback, and it does not describe an upgrade procedure between releases. The repository has both Dockerfile.old and Dockerfile.release, plus a git-publish.sh script, but nothing in the README explains how a running instance moves from one version to the next. If your team cannot read the Elixir and PostgreSQL configuration directly, that gap is a real risk.

Finally, Bonfire is a poor fit if you want a managed service. There is no hosted offering described in the README; the paths given are local development, self-hosting and Cloudron.

How this differs from other fediverse server software

The obvious comparison is Mastodon, which most people evaluating a federated server will already know. Mastodon is a Rails application you install as a unit: features arrive with the release, and customisation happens through configuration and themes rather than by swapping components. Bonfire inverts that. The README describes a framework where functionality and UI both live in extensions, and where a flavour is a curated set of them.

That difference cuts both ways. With Mastodon, the question "what does upgrading change?" has one answer per release. With Bonfire, the answer depends on the extensions your flavour pulls in, and those live in separate repositories. The trade is customisation for auditability.

A second difference is the UI stack. Bonfire's official interface is built with Surface on top of Phoenix LiveView, and the README treats familiarity with both as prerequisite knowledge. Someone coming from a PHP or Ruby background will spend their first days learning LiveView before they can change anything in the interface. The GraphQL API exists as an escape hatch for building a custom frontend, but the README does not document its schema beyond the module reference.

Licensing and the cost of staying current

The repository carries a LICENSES/ directory rather than a single licence file at the root, and the README does not state a licence identifier. That is worth resolving before you build on it, because a directory of licences usually means different components are covered by different terms. This is not legal advice; read LICENSES/ and the individual extension repositories yourself.

On maintenance cost, the release cadence visible in the repository is active: v1.0.7 on 2026-08-30 and two v1.0.8 beta builds on 2026-09-08, with the last push on 2026-09-10. Frequent beta releases during a release candidate cycle mean an operator tracking the RC channel should expect to test and redeploy regularly. The justfile defaults to the ember flavour and to Docker for everything, which keeps a local rebuild cheap, but the README gives no equivalent guidance for production upgrades.

Funding is disclosed: the project has received funding from NGI0 Discovery and NGI0 Entrust, funds established by NLnet with support from the European Commission's Next Generation Internet programme. That is a grant-funded project, not a commercial one, and the README's community channels are Matrix, Slack, the Elixir Forum, the Fediverse and an email address.

Editorial conclusion

Adopt Bonfire if you are comfortable with Elixir, PostgreSQL and Docker and want a federated space whose features you can turn on and off per community; the Social flavour is the only one the README describes as release candidate. Do not adopt it if you need a stable, fully documented hosting path today, because several flavours are alpha or pre-alpha and the README does not document rollback or upgrade procedures. Verify first which flavour and release channel you are actually deploying, and read docs/DEPLOY.md before you point a domain at anything.

Frequently asked questions

Official sources

1. bonfire-networks/bonfire-app on GitHub
2. Issues
3. Project website
4. README
5. Releases