Bonfire: a federated social framework where every feature is an extension
Bonfire - tend to your digital life in community. Customise and host your own online space and control your experience at the most granular level.
At a glance
- What is it?
- Bonfire is an Elixir and Phoenix LiveView framework for hosting federated communities, assembled from separately versioned extensions. It fits operators who want to compose their own space, not people looking for a single installable app.
- Who is it for?
- Adopt Bonfire if you run Elixir and PostgreSQL and want to assemble a federated space from extensions rather than accept one product's fixed feature set. Do not adopt it if you need a single stable artefact: the README marks only Bonfire Social as a 1.0 release candidate, while Community is beta and Coordination and Cooperation are pre-alpha, and alpha flavours are documented as not federation safe.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Elixir, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Bonfire solves: one federated space, assembled rather than accepted
Most federated software ships as a finished product. You install it, you get the feature set its maintainers chose, and customisation means forking or patching. Bonfire inverts that. The README describes it as "an open-source framework for building federated digital spaces", and all features and user interface elements are implemented in extensions, each with its code in a separate repository. A community enables or disables those extensions to shape what its space does. The intended audience is stated plainly: developers building on Bonfire, community organisers and sysadmins launching a space, and users joining one. The prerequisite list is Elixir, Phoenix with LiveView and Surface, and PostgreSQL. That is a narrow audience by design. If you do not already operate an Elixir service, the framework's flexibility is paid for in a stack you have to learn before you can evaluate it.
Flavours: the same framework shipped as different default extension sets
The repository bundles configurations for several flavours, each a different combination of extensions and default settings. Ember provides the basics. Social covers classical social networking and is the one the README calls a 1.0 release candidate. Community adds groups and topics and is at 1.0 beta. Open Science is alpha or beta. Coordination, for work and projects, and Cooperation, for cooperative production and exchange, are both pre-alpha. This is the practical shape of the project: the framework is one codebase, but what you deploy is a flavour, and the flavours are not at the same maturity. Picking Bonfire therefore means picking two things at once, the flavour and the stability channel, and the README's own table makes the second choice consequential. Stable and RC channels are marked federation safe. Beta is federation safe "with caution". Alpha is marked no, with the instruction to turn federation off. A pre-alpha flavour is not a lighter version of the same product; it is a configuration the maintainers do not yet consider safe to connect to the wider network.
How the pieces fit: extensions, PostgreSQL, and a GraphQL surface
The architecture visible in the README is a Phoenix application whose behaviour is assembled from extension modules. The web interface is built with Surface on top of Phoenix LiveView, so the UI is server-rendered and updated over a persistent connection rather than through a separate frontend. PostgreSQL is the primary database. Federation is a framework-level capability that lets spaces communicate with each other, and the README frames it as users interacting across communities while keeping their own identities and preferences, which is the ActivityPub model the repository topics also list. For anyone building a custom frontend, Bonfire exposes a GraphQL API, documented as Bonfire.API.GraphQL. That API is the seam between the framework and anything you want to put in front of it. The consequence of the extension model is that the running system is not fully described by this repository: enabling an extension pulls in code that lives elsewhere, so the behaviour of your deployment depends on the versions of repositories this app configuration selects.
Getting it running: the documented entry points
The README does not print an install command. It points to documents in the repository, and those are the real starting points. Developers are directed to docs/HACKING.md for a local setup, then to docs/topics/JUST.md for the CLI commands, which indicates the project drives its tasks through just rather than a bespoke script. From there the README suggests docs/building/create-a-new-extension.md for extension work and docs/topics/ARCHITECTURE.md for internals. Operators are sent to docs/DEPLOY.md. Users get docs/user_guides/user-guides.md. Because the commands themselves are not in the README, anyone evaluating Bonfire should open docs/HACKING.md and docs/DEPLOY.md first and read the actual invocation and configuration keys before assuming the setup resembles a standard Phoenix release. The one concrete interface named in the README is the GraphQL module, Bonfire.API.GraphQL, which is what a custom client would target. Treat the docs tree as the specification; the README is an index to it.
The stability channel is the real limitation
The most useful thing in the README is the table that maps channels to risk, and it is also the strongest argument for caution. Only the Social flavour is described as a release candidate at 1.0. Community is beta. Open Science is alpha or beta. Coordination and Cooperation are pre-alpha. The repository's recent releases are versioned v1.0.8-beta.4, v1.0.8-beta.2 and v1.0.7, so the bleeding edge of this app repository is itself in beta while a stable line exists alongside it. The README asks beta users to focus bug reports on pre-existing functionality, which is an admission that new functionality is expected to move. For an operator, the failure mode is not a crash. It is connecting a space to the fediverse on a channel the maintainers mark as not federation safe, or building a community workflow on a pre-alpha flavour whose extension set can change under you. The README's own instruction for alpha is to turn federation off, and that instruction should be read as the boundary of what the project currently supports, not as a suggestion.
Bonfire against Mastodon-style single applications
The obvious alternative is a federated server distributed as one application, where the feature set is fixed and configuration is limited to what the application exposes. That model asks less of an operator: no Elixir toolchain, no extension graph, no flavour decision. Bonfire's difference is not cosmetic. Its features and UI elements live in separate repositories and are toggled per space, and developers can add extensions that introduce new activities or new interfaces for existing ones. So the comparison is between accepting someone else's product decisions and composing your own from parts that are versioned independently. The cost of Bonfire's approach is that your deployment's behaviour is a function of which extensions you enabled and which versions they resolved to, and the maturity of that combination is whatever the flavour's channel says it is. If your requirement is a social server you configure and forget, the single-application model is the better fit. If your requirement is a space whose activity types and interface are yours to define, Bonfire is built for exactly that, and the extension repositories are where the work happens.
Maintenance, versions, and the licence gap
Two maintenance facts follow from the structure. First, because extensions live in separate repositories, upgrading the app means tracking the versions of the extensions your flavour enables, not just one release number. The README's channel table is the mechanism for deciding how much of that churn you accept: stable for a server you run, RC if you want to catch issues early, beta for co-design input, alpha only with federation off. Second, the flavours themselves mature at different rates, so a maintenance plan built around Social will not transfer unchanged to Coordination. On licensing, the repository metadata supplied here lists the licence as unknown, and the README does not state one. That matters more than usual for a federation framework, because the code you run is spread across many repositories, and each could carry different terms. Anyone deploying Bonfire commercially or in a cooperative should confirm the licence of the app repository and of every extension in their flavour before relying on it. The README does note funding from NGI0 Discovery and NGI0 Entrust via NLnet, which says something about how the work has been supported but nothing about the terms you receive it under.
Editorial conclusion
Adopt Bonfire if you run Elixir and PostgreSQL and want to assemble a federated space from extensions rather than accept one product's fixed feature set. Do not adopt it if you need a single stable artefact: the README marks only Bonfire Social as a 1.0 release candidate, while Community is beta and Coordination and Cooperation are pre-alpha, and alpha flavours are documented as not federation safe. Before committing, verify which flavour and stability channel you are actually installing, what extensions it pulls in, and which licence the repository carries, since the licence field in the repository metadata is empty and the README does not state one.
Community notes