# Campfire: self-hosted group chat from Basecamp, deployed with ONCE or Docker

> Basecamp's Campfire is an MIT-licensed Rails chat app you run on your own machine. It ships as a single Docker image, and the README's recommended install path is the ONCE tool, not a manual server build.

**basecamp/once-campfire** — Super simple group chat, without a subscription

- Repository: https://github.com/basecamp/once-campfire
- Website: https://once.com/campfire
- Stars: 4,665 · Forks: 799
- Language: Ruby
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/basecamp-once-campfire

## What Campfire is, and who it is for

Campfire is a web-based chat application from Basecamp, released under the MIT licence in the basecamp/once-campfire repository. The README lists the feature set plainly: multiple rooms with access controls, direct messages, file attachments with previews, search, notifications over Web Push, @mentions, and an API with support for bot integrations. That list is the whole pitch. There is no federation, no bridge to other networks, no plugin marketplace described in the README.

The audience is narrow and specific. It is for a team that already runs its own infrastructure and wants chat to sit inside that boundary, and for Rails developers who want a chat codebase small enough to modify. The README says you are welcome, and encouraged, to modify Campfire to your liking, and points at docs/development.md for local setup. If you want a hosted service where someone else owns the uptime, this is the wrong shape of product. The name of the repository is the tell: it is the ONCE-packaged distribution of Campfire, not the Basecamp SaaS product.

## One container, one machine: the deployment model

The README states that Campfire's Docker image contains everything needed for a fully-functional, single-machine deployment: the web app, background jobs, caching, file serving, and SSL. That sentence is the architecture. There is no separate Redis cluster to provision, no object storage bucket to wire up, no reverse proxy you must configure by hand. The image carries its own TLS termination.

The Dockerfile backs this up. It builds on ruby:3.4.10-slim, installs libsqlite3-0, libvips, libjemalloc2, ffmpeg and redis in the base stage, and sets RAILS_ENV to production with BUNDLE_DEPLOYMENT=1. A throw-away build stage installs the gems, copies the application code, and precompiles assets with SECRET_KEY_BASE_DUMMY=1 so the build does not require your RAILS_MASTER_KEY. The final stage runs as a non-root rails user with uid 1000.

The presence of libvips and ffmpeg in the runtime image explains the attachment previews: those are the libraries that process images and video. The presence of redis inside the same container, rather than as a sibling service, is what makes the single-machine claim true. It also means horizontal scaling is not described anywhere in the README. The trade-off is real: you get one command to run, and you get one machine to grow out of.

## Installing Campfire with ONCE, step by step

The README calls ONCE the easiest way to self-host Campfire, and says it will guide you through initial setup and then keep your instance up to date automatically. If once is not already on the machine, the README gives this install command, which you run on the machine that will host Campfire:

```bash
curl https://get.once.com | sh
```

According to the README, once launches as soon as the install finishes. From there you pick Campfire from the list of applications and follow the instructions; the README says ONCE takes care of the rest. If you would rather not use the dashboard, the README documents a direct command-line deploy, substituting your own hostname:

```bash
once deploy ghcr.io/basecamp/once-campfire --host chat.example.com
```

That pulls the pre-built image from ghcr.io/basecamp/once-campfire. You can also build your own image from the repository instead of using the published one.

The first thing you will meet is the setup wizard. The README's tip is worth reading before you type anything: the email address you enter for the admin account will be visible on the sign-in page, published there so people have someone to contact about their account. If that bothers you, the README suggests entering any email address you want and then creating yourself a new admin account. That is a workaround, not a setting, and it is the kind of detail that is easy to miss until the address is already on a public page.

## Self-hosting with Docker instead of ONCE

The README does not put the Docker instructions in the main body. It says that if you would rather run the Docker image yourself, you can read more in docs/self-hosting.md. That file is not reproduced in the README, so the exact flags, volume mounts, port mappings and environment variables for a manual Docker run cannot be confirmed from the README alone. Anyone planning a Docker deployment should read docs/self-hosting.md in the repository before assuming a command shape.

What can be confirmed is the image reference and the build inputs. The README names ghcr.io/basecamp/once-campfire:latest as the pre-built image. The repository carries a Dockerfile, a Dockerfile-export, a .env.erb template, a Procfile, a .ruby-version file and a Gemfile. The Dockerfile comment says the Ruby version argument should match the version in .ruby-version and Gemfile, so a custom build should start by checking those three agree.

The practical difference between the two paths is who owns upgrades. ONCE is described as keeping your instance up to date automatically. A manual Docker deployment means you pull a new tag and restart the container yourself, and the README does not document a rollback procedure for either path.

## Where Campfire is the wrong tool

The single-machine constraint is the first boundary. The README describes a fully-functional single-machine deployment and says nothing about running multiple app instances behind a load balancer, sharing sessions, or moving Redis out of the container. If your team's chat needs to survive the loss of one host without a restore, this design does not offer that, and the README does not claim otherwise.

Search is listed as a feature but the README does not describe its scope, indexing strategy or retention, so do not assume it behaves like a hosted chat service's search. Notifications are Web Push only; there is no mention of email digests or mobile push through app stores. The API is listed with support for bot integrations, but the README does not document endpoints, authentication or rate limits, so a bot integration starts by reading the code.

There is also a governance question. The repository is MIT-licensed and the README invites modification, which means forks can diverge. If you modify Campfire and ONCE later updates your instance, the README does not explain how local changes interact with that update process. Teams that need a stable, vendor-supported chat product with an SLA should look elsewhere; Campfire is a codebase you run.

## How Campfire compares to running a general-purpose chat server

The obvious alternative for a team that wants self-hosted chat is a general-purpose chat server such as Matrix or Mattermost. The difference in approach is structural rather than cosmetic. Those projects are built around extensibility and, in Matrix's case, federation between independent servers. Campfire is built around the opposite assumption: one machine, one container, everything inside it.

That makes Campfire simpler to stand up and harder to extend outward. A federated server lets your instance talk to other organisations' instances; Campfire has no such concept in the README. A general-purpose chat platform typically separates the database, cache and file store so each can be scaled or backed up independently; Campfire's Dockerfile deliberately bundles SQLite, Redis, libvips and ffmpeg into one image so there is nothing to separate.

If your requirement is a small team chatting on a box you own, with attachments and mentions, the bundled approach removes a category of operational work. If your requirement is cross-organisation messaging or a plugin ecosystem, the bundled approach is the thing that disqualifies it. The README's ONCE-first recommendation also means Campfire is easier to adopt for people who are not Rails developers, since ONCE handles setup and updates, but harder to customise for those same people, since the customisation path runs through docs/development.md and a local Rails environment.

## Conclusion

Adopt Campfire if you want group chat on hardware you control, you accept a single-machine deployment, and you are comfortable running a Rails container or letting ONCE keep it updated. Skip it if you need federation, a hosted free tier, or multi-node scaling; the README describes none of those. Before committing, read docs/self-hosting.md for the Docker path, confirm which Ruby version your build needs from .ruby-version, and decide what the admin email shown on the sign-in page should be, because the wizard publishes it.

## FAQ

### Is Campfire a free app?

The repository is MIT-licensed, so the code is free to use and modify under that licence. The README describes self-hosting the Docker image yourself or through ONCE; it does not describe a paid tier or a subscription, which matches the project's tagline of group chat without a subscription.

### What is a Campfire chat?

In this project, Campfire is a web-based chat application from Basecamp with multiple rooms and access controls, direct messages, file attachments with previews, search, Web Push notifications, @mentions, and an API for bot integrations. You run it yourself rather than signing up for a hosted service.

### What does the company Campfire do?

Campfire is a product from Basecamp, published as the basecamp/once-campfire repository. The README describes it as a web-based chat application that you deploy on your own machine, either with the ONCE tool or with the Docker image directly.

### What does campfire mean?

For this project the name refers to Basecamp's chat application, not to a literal fire. The README uses it as the product name throughout, and the repository is the ONCE-packaged distribution of that application.

## Sources

- [basecamp/once-campfire on GitHub](https://github.com/basecamp/once-campfire)
- [License: MIT](https://github.com/basecamp/once-campfire/blob/main/LICENSE)
- [Project website](https://once.com/campfire)
- [README](https://github.com/basecamp/once-campfire/blob/main/README.md)
- [Releases](https://github.com/basecamp/once-campfire/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/basecamp-once-campfire