Fizzy

Fizzy is an open-source Kanban board built by 37signals — the creators of Basecamp and HEY — as an opinionated alternative to bloated project management tools like Trello, Jira, and Asana. It delivers a clean, drag-and-drop interface for tracking bugs, issues, and ideas without the overhead of feature-packed enterprise software. Every design decision prioritizes speed and visual clarity over configuration depth.

Built on Ruby on Rails with the Hotwire stack (Turbo, Stimulus, Importmap, Propshaft), Fizzy delivers a server-driven experience that feels native without shipping a heavy JavaScript framework. It supports rich card descriptions, file attachments, webhooks, a REST API, and push notifications — giving teams everything they need without the kitchen sink.

Self-hosting Fizzy is straightforward: deploy via Docker using a pre-built image from GitHub Container Registry, or use Kamal for teams that want to customize and redeploy from source. Storage is handled through SQLite by default for development and MySQL/Trilogy for production, with optional S3-compatible backends for file attachments. The hosted version at fizzy.do is operated by 37signals and subsidized by Basecamp and HEY subscribers.

With over 7,800 GitHub stars, more than 1,000 forks, and an extraordinarily active release cadence — multiple releases per week — Fizzy is under continuous improvement by the 37signals team and a growing open-source community of 94+ contributors.

What You Get

• Kanban boards with drag-and-drop cards - A clean board interface with customizable columns for organizing bugs, issues, and ideas through drag-and-drop reordering and column-based workflows.
• Auto-close and stale detection - Cards inactive beyond a configurable threshold are automatically flagged as stalled or closed, keeping boards clean without manual pruning.
• Webhooks and real-time notifications - Publish card lifecycle events (created, assigned, completed, closed) to Slack, Campfire, or any webhook endpoint for live team alerts.
• REST API with JSON responses - A documented API that allows external tools to read and manipulate boards, cards, columns, tags, and access tokens programmatically.
• Public board publishing - Make any board publicly visible so stakeholders, contributors, or customers can follow progress without creating an account.
• Rich card descriptions and file attachments - Cards support ActionText-powered rich text descriptions and image/file attachments with optional S3-compatible storage backends.
• Push notifications - Native push notification support for web (via web-push) and mobile platforms, keeping team members informed of card activity wherever they are.
• Triage and postpone workflows - Cards can be sent to a triage queue or postponed (“not now”) with automatic timestamps and attribution, supporting lightweight inbox-zero-style workflows.

Common Use Cases

• Bug and issue tracking for small teams - A startup engineering team uses Fizzy to manage bug reports and feature requests without the complexity of Jira, assigning cards to engineers and closing them as PRs land.
• Open-source project roadmap - An open-source maintainer publishes a Fizzy board publicly so contributors can track what’s in progress, what’s planned, and what needs triage — without requiring login.
• Customer support queue management - A small SaaS company routes incoming support requests to a Fizzy board, using columns for triage, in-progress, and resolved, with webhooks posting updates to a Slack channel.
• Personal project and idea capture - A solo developer keeps a private Fizzy board for tracking side project ideas, backlogs, and in-progress work with a fast, distraction-free interface.
• Content and editorial pipeline - A content team tracks article ideas, drafts in review, and published pieces across columns, using tags and assignments to coordinate between writers and editors.
• IT and operations ticket tracking - An internal IT team uses a self-hosted Fizzy instance to track infrastructure requests, outage investigations, and maintenance tasks with complete data ownership.

Under The Hood

Architecture Fizzy is a disciplined monolithic Rails application organized through heavy use of ActiveSupport::Concern to compose domain behavior. The Card model alone includes over twenty concerns — Closeable, Postponable, Stallable, Assignable, Broadcastable, Eventable, Exportable, and more — each encapsulating a single lifecycle behavior with its own scopes, callbacks, and state transitions. This pattern trades explicit service layer boundaries for compositional clarity: behavior lives close to the data, making it easy to trace state changes without indirection. Real-time updates flow through Turbo Streams and Solid Cable, keeping the frontend in sync without client-side state management. Solid Queue handles background jobs including webhook delivery, push notifications, card triage automation, and search reindexing. The architecture is intentionally Rails-idiomatic — convention over configuration carried to its logical conclusion.

Tech Stack Fizzy runs on Ruby on Rails tracking the main branch, paired with the full Hotwire ecosystem: Turbo for page-fragment updates, Stimulus for lightweight JavaScript controllers, Importmap for zero-build asset delivery, and Propshaft as the asset pipeline. The database layer uses SQLite for development and Trilogy (MySQL) for production, with Solid Cache, Solid Queue, and Solid Cable providing queue, cache, and websocket functionality without Redis. File storage uses ActiveStorage with local disk or S3-compatible backends. Deployment targets Docker with Thruster as the HTTP accelerator (handling SSL termination, compression, and asset caching) and Kamal for orchestrated deploys. The Ruby runtime is pinned to 3.4.x with jemalloc for reduced memory fragmentation.

Code Quality The test suite spans 267 test files covering models, controllers, mailers, integrations, jobs, and middleware — a comprehensive coverage posture for a Rails application of this size. Tests are organized to mirror the domain structure, with integration tests verifying end-to-end card lifecycle transitions, authorization boundaries, and Active Storage access controls. The project enforces rubocop-rails-omakase for consistent style, and includes Brakeman for static security analysis and bundler-audit for dependency vulnerability scanning. Error handling leans on explicit domain exceptions and database-level constraints rather than silent rescue blocks. Background job tests validate queue side effects and concurrency behavior, demonstrating attention to the async layer.

What Makes It Unique Fizzy’s most distinctive architectural choice is the depth of its concern-based composition — each card behavior (staleness detection, postponement, auto-close, triage, goldness, entropy) is an independently testable module that composes cleanly at the model level, a pattern that scales better than service objects for this domain. The bridge controller directory exposes a native-flavored mobile layer using Strada-style bridge components, enabling the same Rails views to power both web and native app experiences. The “stalled” card detection synchronizes Ruby logic with client-side Stimulus JavaScript to maintain consistent state without duplication. Entropy tracking measures board health over time, surfacing boards with accumulating unresolved cards before they become unmanageable — a behavioral insight mechanism absent from most Kanban tools.

Self-Hosting

Fizzy is released under the O’Saasy License, a source-available license created by 37signals for projects where they want to share the code openly but protect their hosted business. The license is permissive in the MIT tradition — you can use, modify, distribute, and sell the software — with one meaningful restriction: you cannot use Fizzy to offer a competing hosted Kanban SaaS product to third parties. For teams self-hosting internally, building products on top of Fizzy, or contributing to the open-source version, this restriction is unlikely to matter. It is not an OSI-approved open-source license, so organizations with strict open-source-only procurement policies should be aware of this distinction.

Self-hosting Fizzy is operationally accessible for teams comfortable with Docker. You need a Linux server, a persistent storage volume for SQLite and file uploads, and an SMTP provider for transactional email. The Docker image is published at ghcr.io/basecamp/fizzy:main and updated continuously — keeping up with releases means pulling the latest image. SSL termination, compression, and asset caching are handled by Thruster inside the container, so you can run without an external reverse proxy. For more control, Kamal provides a complete deployment workflow with rolling deploys and secrets management. There is no managed database, no automatic backup orchestration, and no built-in HA — these are your responsibility to configure. File storage can be pointed at S3-compatible services like Backblaze B2 or MinIO for durability beyond local disk.

The hosted version at fizzy.do is operated by 37signals and includes a free tier with a 1 GB file storage limit, subsidized by revenue from Basecamp and HEY. Self-hosters get unlimited storage bounded only by their own infrastructure, complete data ownership, and the ability to customize the codebase. What you give up is the operational simplicity of a managed service: 37signals handles uptime, upgrades, backups, and mobile app distribution for fizzy.do users. There is no enterprise tier, SLA, or priority support channel for the open-source edition — support flows through the public GitHub repository.