Deploy Fizzy
Kanban tracker for issues, ideas and small projects
mailpit
Just deployed
/data
fizzy-jobs
Just deployed
Just deployed
MySQL
Just deployed
/var/lib/mysql
fizzy-storage
Bucket
Just deployed
Deploy and Host Fizzy on Railway
Fizzy is the kanban tracker 37signals built for its own bugs, ideas and small projects — the same team behind Basecamp and HEY. Cards move through a handful of columns, every card carries a description, a checklist of steps, tags, reactions and attachments, and anything that sits ignored for too long bubbles back up on its own. Pages are fast, keyboard shortcuts are everywhere, and nothing stands between an idea and a card. Teams self-host Fizzy to get that workflow on their own domain, with their own data and no per-seat bill.
Deploy Fizzy on Railway and the whole production shape comes up at once. The fizzy service runs the Rails app behind Thruster on a public domain; fizzy-jobs runs the Solid Queue supervisor separately, so notifications, webhooks and cleanup never compete with web requests; MySQL stores boards, cards and the queue tables; a Railway object storage bucket holds every upload; and mailpit captures the six-digit sign-in codes Fizzy mails, so you can sign in without wiring up an SMTP provider first. Both app services are stateless, so redeploys and replicas are safe.

Getting Started with Fizzy on Railway
Open the fizzy service's public URL and you land on the sign-in screen. Fizzy has no passwords: you type an email address and it mails you a six-digit code. The template seeds the owner account on first boot from ADMIN_EMAIL, which also closes signups, so no stranger can claim your instance. Enter that address on the sign-in screen, open the mailpit URL in another tab, log in with the credentials in its MP_UI_AUTH variable, and read the code from the newest message.
Then create a board and try the parts that make Fizzy different: press C to add a card from anywhere, give it a checklist of steps, drop an image on it to confirm object storage works, and move it to "Done" to watch it reach the activity timeline. For real email later, point SMTP_ADDRESS, SMTP_PORT, SMTP_USERNAME and SMTP_PASSWORD at a provider such as Postmark or SES.



About Hosting Fizzy
Fizzy is a Rails 8 application built on the modern Rails stack rather than a pile of services: Solid Queue for jobs, Solid Cache for caching and Solid Cable for live updates, all backed by the same database. Self-host it when your issues are internal, when you want the board on your own domain, or when you would rather own the data behind a tool your team uses all day.
Features worth knowing about:
- Columns you name yourself, with cards moved by drag, keyboard or the card screen
- Steps — a checklist inside each card, with progress shown on the board
- Tags, reactions, comments, assignments and pinned cards
- Auto-close, which prunes cards nobody has touched, and "not now" for deferred work
- Webhooks for publishing card events to Slack, Campfire or anything else
- Web Push notifications, a public-board mode, passkey sign-in and a documented HTTP API
The deployment is split the way a production Rails app should be. fizzy serves HTTP through Thruster, which handles keep-alives and asset caching in front of Puma. fizzy-jobs runs the same image with FIZZY_ROLE=jobs, so background work scales and restarts on its own. MySQL holds four databases — app, queue, cache and cable — created on first boot. The bucket keeps uploads off the container filesystem, which is what lets both app services stay stateless.
Why Deploy Fizzy on Railway
Railway gives this stack the pieces it needs without any assembly:
- Managed MySQL with backups, on the private network
- Object storage provisioned with the template, for card attachments
- A separate worker service that scales independently of web traffic
- Automatic HTTPS on a generated domain, or your own custom domain
- Health checks on both app services, so a bad deploy rolls back instead of serving errors
Common Use Cases
- A product team tracking bugs, ideas and small projects without paying per seat
- An agency running a public board so clients can follow progress without an account
- An internal ops team logging recurring maintenance issues across sites or properties
- A solo developer replacing a private repo's issue list with a faster, prettier board
Dependencies for Fizzy
- fizzy and fizzy-jobs — built from gridalpha/fizzy-railway, a thin wrapper over the official
ghcr.io/basecamp/fizzy:mainimage - MySQL — Railway's managed
mysql:9.4, holding the app, queue, cache and cable databases - mailpit —
axllent/mailpit:latest, a capture-only inbox for the sign-in codes - fizzy-storage — a Railway object storage bucket used by Active Storage
Environment Variables Reference
| Variable | Purpose |
|---|---|
SECRET_KEY_BASE | Rails signing key; also seeds the Web Push keypair |
ADMIN_EMAIL / ADMIN_NAME | Seeds the owner account on first boot and closes signups |
BASE_URL | Public URL used in emailed links |
DATABASE_ADAPTER | mysql selects MySQL over the default SQLite |
MULTI_TENANT | true allows more than one account to sign up |
SMTP_ADDRESS / SMTP_PORT / SMTP_USERNAME / SMTP_PASSWORD | Mail delivery; point these at a real provider for production |
WEB_CONCURRENCY / JOB_CONCURRENCY | Puma workers and Solid Queue processes |
ACTIVE_STORAGE_SERVICE | s3 stores uploads in the bucket instead of on disk |
THRUSTER_HTTP_READ_TIMEOUT | Raise it before importing a multi-gigabyte account export |
Deployment Dependencies
- Source: github.com/basecamp/fizzy
- Image:
ghcr.io/basecamp/fizzy:main - Self-hosting guide: docs/docker-deployment.md
- API reference: docs/api
- Runtime: Ruby 3.4, Rails 8, MySQL 9
Hardware Requirements for Self-Hosting Fizzy
| Resource | Minimum | Recommended |
|---|---|---|
| CPU | 1 vCPU | 2–4 vCPU across the app and worker |
| RAM | 1 GB | 2–4 GB (Puma workers are the biggest consumer) |
| Storage | 1 GB for MySQL | 5 GB plus object storage for attachments |
| Runtime | Ruby 3.4 / Rails 8 | Same, via the published container image |
A small team fits in the minimum. WEB_CONCURRENCY is the dial to turn under load; each Puma worker costs roughly 300 MB.
Self-Hosting Fizzy Outside Railway
The published image runs anywhere Docker does. The simplest single-container form keeps everything in SQLite on one volume:
docker run -d \
--volume fizzy:/rails/storage \
--publish 80:80 \
--env SECRET_KEY_BASE=$(openssl rand -hex 64) \
--env BASE_URL=https://fizzy.example.com \
--env DISABLE_SSL=true \
ghcr.io/basecamp/fizzy:main
To run it against MySQL the way this template does, set the adapter and the connection variables instead of relying on the volume:
docker run -d \
--env DATABASE_ADAPTER=mysql \
--env MYSQL_HOST=db.internal --env MYSQL_USER=root \
--env MYSQL_PASSWORD=secret \
--env SECRET_KEY_BASE=$(openssl rand -hex 64) \
--env SOLID_QUEUE_IN_PUMA=false \
ghcr.io/basecamp/fizzy:main
Run a second container with bin/jobs as its command for the worker tier. 37signals also ship a Kamal configuration in the repo if you would rather deploy to a bare server.
Is Fizzy Free to Self-Host?
Fizzy is free, both hosted at fizzy.do and as source you run yourself, under 37signals' O'Saasy License — commercial internal use is fine; reselling Fizzy itself as a competing hosted service is not. There is no paid tier, seat count or license key, so on Railway you pay only for the compute, database and storage you use.
FAQ
What is Fizzy? An open-source kanban tracker from 37signals for issues, bugs and ideas. Cards move through columns you define, carry checklists and attachments, and resurface when ignored.
What does this Railway template deploy? Four services: the Fizzy web app, a separate background-jobs service, a managed MySQL database and a Mailpit inbox, plus an object storage bucket for uploads.
Why does the template include a mail service? Fizzy signs people in with a code sent by email, so without a mail service nobody can log in. Mailpit captures those codes so the first sign-in works immediately; swap in a real SMTP provider when you want mail delivered to real inboxes.
Why is there a separate jobs service instead of running jobs in the web app? Fizzy can run Solid Queue inside Puma, but splitting it keeps a slow webhook or notification job from delaying page loads, and lets the worker scale on its own.
Can more than one team sign up on my instance?
By default no — the first account closes signups, which keeps a public URL from being claimed by a stranger. Set MULTI_TENANT=true if you want to run several accounts on one deployment.
How do I connect Fizzy to Slack or another tool? Each board has webhooks in its settings, and Fizzy ships a documented HTTP API covering boards, cards, steps, comments and activities, so bots read and write the same data the UI does.
Template Content
