Deploy Fizzy

Kanban tracker for issues, ideas and small projects

Deploy Fizzy

Just deployed

/data

Just deployed

Just deployed

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.

Diagram of the Fizzy web, jobs, MySQL and Mailpit services

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.

Fizzy board holding release cards with step counters

Fizzy card showing its checklist and uploaded background image

Fizzy activity timeline listing cards added and finished today

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:main image
  • MySQL — Railway's managed mysql:9.4, holding the app, queue, cache and cable databases
  • mailpitaxllent/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

VariablePurpose
SECRET_KEY_BASERails signing key; also seeds the Web Push keypair
ADMIN_EMAIL / ADMIN_NAMESeeds the owner account on first boot and closes signups
BASE_URLPublic URL used in emailed links
DATABASE_ADAPTERmysql selects MySQL over the default SQLite
MULTI_TENANTtrue allows more than one account to sign up
SMTP_ADDRESS / SMTP_PORT / SMTP_USERNAME / SMTP_PASSWORDMail delivery; point these at a real provider for production
WEB_CONCURRENCY / JOB_CONCURRENCYPuma workers and Solid Queue processes
ACTIVE_STORAGE_SERVICEs3 stores uploads in the bucket instead of on disk
THRUSTER_HTTP_READ_TIMEOUTRaise it before importing a multi-gigabyte account export

Deployment Dependencies

Hardware Requirements for Self-Hosting Fizzy

ResourceMinimumRecommended
CPU1 vCPU2–4 vCPU across the app and worker
RAM1 GB2–4 GB (Puma workers are the biggest consumer)
Storage1 GB for MySQL5 GB plus object storage for attachments
RuntimeRuby 3.4 / Rails 8Same, 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

More templates in this category

View Template
Rocky Linux
Hosted Rocky Linux 9 workspace with SSH and persistent storage. 🚀

codestorm
47
View Template
Foundry Virtual Tabletop
A Self-Hosted & Modern Roleplaying Platform

Lucas
71
View Template
Letta Code Remote
Run a Letta Code agent 24/7. No inbound ports, just deploy.

Letta
50