Fizzy: 37signals' Self-Hosted Kanban for Issues and Ideas

What Fizzy Is and Who It Is Built For

Fizzy is the source code of fizzy.do, described in the README as "the Kanban tracking tool for issues and ideas by 37signals." The repository is Ruby, tagged with hotwire, kanban, rails and ruby, and the homepage is fizzy.do. Two things follow from that description. It tracks issues and ideas rather than general project work, and it is published by the company that runs the hosted version, so the source is the same product rather than a stripped-down community edition.

The audience is narrower than "anyone who wants a Kanban board." The README addresses people who want to run their own instance, and it splits them into three groups: those who want the simplest single-machine deployment, those who want to run a pre-built image themselves, and those who want to change the code and deploy those changes. That third group is the one the repository is really written for. The README says you are "welcome -- and encouraged -- to modify Fizzy to your liking," and it links a development guide for local setup. If you never intend to touch Ruby, you are paying the cost of a source distribution for a benefit you will not use.

There is also a saas/ directory and Gemfile.saas alongside the main Gemfile, which suggests the hosted product carries dependencies the self-hosted build does not. The README does not explain the split. Treat it as a signal that running Fizzy and running fizzy.do are not byte-identical experiences.

How Fizzy Is Put Together: Rails, Hotwire, SQLite

The stack is visible in the repository layout. It is a Rails application with app/, config/, db/, lib/ and test/ at the top level, a config.ru, a Rakefile, and a Procfile.dev for local process management. The Hotwire topic tag matches a Rails app that renders server-side HTML and updates the page over the wire rather than shipping a separate JavaScript client.

The Dockerfile is the most concrete architectural document in the repository. It builds from ruby:3.4.8-slim, sets WORKDIR /rails, and installs curl, libjemalloc2, libvips, sqlite3 and libssl-dev. Two of those choices are worth naming. SQLite in the production image means a single-machine deployment is the expected shape, not a horizontally scaled cluster behind a load balancer. libvips means image processing happens in-process, which fits attachments on cards.

The build is split into a base stage and a throw-away build stage. The build stage adds build-essential, git, libyaml-dev and pkg-config, runs bundle install, then strips bundler caches and vendored .git directories before the final image is assembled. Production environment variables are set in the base stage: RAILS_ENV="production", BUNDLE_DEPLOYMENT="1", BUNDLE_PATH="/usr/local/bundle", BUNDLE_WITHOUT="development:test", and LD_PRELOAD pointing at the jemalloc shared object, which the comment says is for "reduced memory usage and latency." The Dockerfile also links jemalloc into /usr/local/lib for that preload to resolve.

One detail that matters for anyone building by hand: the file comments give the exact invocation, including that RAILS_MASTER_KEY must come from config/master.key. Without that key the container will not boot, because Rails credentials are encrypted.

Installing Fizzy with ONCE or Docker

The README calls ONCE "the easiest way to self-host Fizzy." It guides you through initial setup and, per the README, keeps your instance up to date automatically, and it is described as having "everything you need for a fully-functional, single-machine deployment." You run one command on the target machine:

curl https://get.once.com/fizzy | sh

That pipes a remote script into a shell, so read it before running it if that pattern concerns you. After it completes, you should have a running Fizzy instance on that machine and a setup flow to walk through.

If you would rather manage the container yourself, the README points to docs/docker-deployment.md for the pre-built image. The Dockerfile carries its own usage comment, which is the shape of the manual path:

docker build -t fizzy .
docker run -d -p 80:80 -e RAILS_MASTER_KEY=<value from config/master.key> --name fizzy fizzy

The first command builds the image and tags it fizzy. The second runs it detached, publishes port 80, passes the Rails master key as an environment variable, and names the container fizzy. Substitute the real value from config/master.key; the placeholder in the comment is not a literal. The Dockerfile header notes it is "designed for production, not development" and points to the Rails Dev Containers guide for a containerized dev environment.

For a first real use, the README's own framing is the guide: Fizzy tracks issues and ideas on a Kanban board. Create a board, add a card for an issue, and move it between columns. The repository does not document specific board or card commands, so treat the UI as the interface rather than looking for a CLI.

Deploying Fizzy with Kamal When You Change the Code

The third path exists for a specific reason. The README says Kamal is recommended "if you want more flexibility to customize your Fizzy installation by changing its code, and deploy those changes to your server," and it links docs/kamal-deployment.md as a complete walkthrough. The Dockerfile header repeats the pairing: "Use with Kamal or build'n'run by hand."

This is the deployment route that matches the repository's stated intent. The README encourages modification, and Kamal is the mechanism the project offers for getting modified code onto a server. Choosing Docker or ONCE instead does not prevent you from editing the source, but it does mean you are maintaining a fork without the deployment tooling the project documents for that case.

The trade-off is operational. Kamal deployment assumes you are comfortable with server provisioning, container registries and the Kamal configuration model. The contents of docs/kamal-deployment.md are not reproduced here, so the specific configuration keys and registry settings are not something this article can state. Read that guide before you commit to this path. If you cannot answer where your image gets pushed and how the server pulls it, you are not ready for the Kamal route.

The O'Saasy License Is the Real Adoption Question

The repository metadata reports the licence as NOASSERTION, and the README names it: "Fizzy is released under the O'Saasy License," linking LICENSE.md. O'Saasy is not a licence GitHub's classifier recognizes, which is why the metadata says NOASSERTION rather than MIT or Apache-2.0. That is a mechanical consequence of a non-standard licence, not a sign that the licence is missing.

What matters for adoption is that O'Saasy is not an OSI-approved permissive licence in the way MIT is. The name itself signals a restriction aimed at competing hosted offerings, which is a common pattern for companies that publish the source of a commercial product. The README does not summarize the terms, and this article cannot either, because the text of LICENSE.md is not reproduced here. Anyone planning to run Fizzy as a service for other people needs to read that file directly and, if the stakes are high, get their own legal review. Do not assume that "open source" in casual conversation means the same thing as the terms in that file.

For an internal team running Fizzy on its own hardware for its own work, the practical exposure is usually small. For a company whose business model involves hosting tools for customers, the licence is the first thing to check, not the last. There is also a Gemfile.saas and a saas/ directory in the tree, which implies the hosted product has its own dependency set; the README does not say whether those files carry different licensing or terms.

Where Fizzy Is the Wrong Choice

The clearest limitation is the one the architecture implies. The production image installs SQLite, and ONCE is described as a "single-machine deployment." If your team needs multi-region failover, read replicas, or the ability to add application servers behind a load balancer without rethinking storage, Fizzy's documented deployment model does not describe that. You would be adapting the app rather than deploying it.

The second limitation is update cadence. The README says ONCE keeps your instance up to date automatically, which is convenient and also means you have delegated upgrade timing to a third-party installer. If your environment requires change windows and staged rollouts, automatic updates are a liability. The Docker and Kamal paths put you back in control, at the cost of doing the work yourself.

Third, the project is young in release terms. The recent releases listed are build identifiers (fizzy@db36756 and similar) rather than semantic version numbers, all dated within the same week in September 2026. That naming makes it hard to reason about upgrade risk from version strings alone. You will need to read commit history, not release notes, to judge what changed between deployments.

Finally, consider whether you want a Kanban tool at all. Fizzy is scoped to issues and ideas. If your work is time-boxed sprints with story points, burndown charts and backlog grooming ceremonies, a tool built around issue and idea cards may fight your process rather than support it.

What Fizzy Is Not: Alternatives and the Difference in Approach

The obvious comparison is with hosted Kanban and issue trackers that you do not run yourself. The difference is not features, it is who holds the database. With a hosted tool, someone else operates the servers, handles backups, and decides when the software changes. With Fizzy, the README puts the machine in your hands: you choose ONCE, Docker or Kamal, and you own the data and the uptime. That is the entire trade. You gain control over the code and the data, and you take on patching, backups and the consequences of a bad deploy.

A second comparison is with self-hosted trackers written in other stacks. Fizzy is Rails and Hotwire, and the repository is explicit that you are "welcome -- and encouraged -- to modify" it. If your team writes Ruby, that is a genuine advantage: the code you are modifying is in a language you already read, and the deployment guides assume a Rails-shaped workflow. If your team does not write Ruby, the modification path the README promotes is closed to you, and you are effectively choosing between ONCE and Docker, both of which treat Fizzy as a black box you configure rather than change.

A third comparison is with the hosted fizzy.do itself. The README frames the repository as the source of that product, which means the self-hosted path is a real option rather than a crippled demo. The presence of Gemfile.saas and saas/ suggests the hosted service carries extra pieces, but the README does not describe what they are, so the honest position is that the two are close and not provably identical.

Maintenance, Upgrades and What to Verify First

The last push to the repository was on 2026-09-19, three days before this article, and the repository is not archived. That is the only maintenance signal available here, and it says the project is being worked on now. It does not tell you how the project handles breaking changes, because the release identifiers are commit hashes rather than version numbers with changelogs attached.

Upgrade cost depends entirely on which path you chose. ONCE updates your instance automatically per the README, so your cost is verifying that an update did not break your instance. Docker puts image pulls in your hands. Kamal puts the whole build-and-deploy cycle in your hands, which is the highest cost and the highest control.

Before adopting, verify four things in this order. Read LICENSE.md and decide whether the O'Saasy terms fit your use. Confirm which deployment guide applies to your server by reading docs/docker-deployment.md or docs/kamal-deployment.md, not just the README summary. Check that you have config/master.key available or know how to generate one, because the Dockerfile requires RAILS_MASTER_KEY at runtime. And check the Ruby version against .ruby-version if you plan to build locally, since the Dockerfile pins RUBY_VERSION=3.4.8 and warns that it must match that file.

Editorial conclusion

Adopt Fizzy if you want a Rails codebase you can modify and you accept the O'Saasy License's non-compete clause; the ONCE installer at get.once.com/fizzy is the shortest path. Do not adopt it if you need an externally audited licence or a vendor SLA, because 37signals publishes neither. Before committing, read LICENSE.md in full and confirm which deployment guide matches your server, since the README points to three and they are not interchangeable.

Frequently asked questions

Official sources

1. basecamp/fizzy on GitHub
2. Issues
3. Project website
4. README
5. Releases