Deploy and Host

Deploy Kanboard to Railway with one click. The repo's Dockerfile builds a 7MB Alpine-based image; Railway provides HTTPS, persistent disk volumes, and zero-config builds. Pricing fits within Railway's free tier for solo and small-team use, and the SQLite backend keeps the running cost predictable as your data grows.

About Hosting

Railway is the runtime that hosts this template. Each push to main (or a click of Deploy in the dashboard) triggers Railway's build → push → run cycle. Key hosting features this template relies on:

HTTPS at the edge — Kanboard serves plain HTTP on a private port; Railway's reverse proxy terminates TLS in front of the app.
Persistent disk volume — /var/www/app/data holds Kanboard's SQLite database and uploaded attachments across deploys.
Health checks at /healthcheck.php — Railway restarts the service if the endpoint stops returning 200.
Free-tier compatible — the 7MB image and SQLite backend fit comfortably within Railway's Hobby plan allotment.
GitHub-driven deploys — push to main and Railway rebuilds; no CI glue required to keep the demo fresh.

Why Deploy

No DevOps overhead — git push deploys. No nginx config, no PHP-FPM tuning, no certificate renewal.
Reproducible builds — the Dockerfile pins Kanboard's version and base image so every deploy is byte-identical.
Data you own — your SQLite file lives on a Railway volume you can snapshot, download, and migrate elsewhere at any time.
No third-party telemetry — Kanboard doesn't phone home. Your task data stays on your volume, not in someone else's analytics DB.
Cheap to run — one container, one volume, free-tier friendly.

Common Use Cases

Personal task management across multiple side-projects
Small-team sprint boards without per-seat SaaS pricing
Solo / freelance client tracking with attachments and subtasks
Internal IT, ops, or engineering request intake
Self-hosted Trello alternative with full data export at any time

Dependencies for

This template has a thin, self-contained dependency profile.

Deployment Dependencies

Dockerfile-based build — no Railway-specific buildpack workarounds; the build is the standard Docker one
Alpine 3.20 base image — small footprint (≈7MB) and broadly compatible with PHP extensions
PHP 8.x with SQLite extension — Kanboard's default runtime; no separate database server required
Health-check endpoint — /healthcheck.php must return 200 within Railway's startup window; this template ships that route
Persistent volume on /var/www/app/data — must be attached before first deploy or tasks/attachments will be lost on restart

Runtime Dependencies (resolved inside the image)

Kanboard v1.2.52 source
PHP CLI + FPM with pdo_sqlite, gd, mbstring, zip, xml
SQLite 3 client library
No nginx, no Caddy — Railway's edge proxy terminates TLS, so the container listens on plain HTTP only

What's included in this template

✅ Single-container deploy (Kanboard v1.2.52 on Alpine)
✅ SQLite persistence out of the box, no Postgres required
✅ Persistent volume mount for /var/www/app/data
✅ Health-checked at /healthcheck.php (works with Railway's built-in health checker)
✅ Patched to run without SSL (Railway terminates TLS at the edge)
✅ Alpine base image keeps the image under 10MB pulled

Why this template

Small footprint: 7MB Docker image, runs on Railway's free tier.
No telemetry: Kanboard doesn't phone home. Your tasks stay yours.
No vendor lock-in: Your SQLite file lives on a Railway volume — export it any time and run Kanboard elsewhere.
Active upstream: Kanboard has regular releases and a stable PostgreSQL backend option if your team grows beyond SQLite.

Common setup tweaks

Set DEFAULT_LANGUAGE=en_US and DEFAULT_TIMEZONE=UTC for English.
For teams, replace the SQLite volume with a managed Postgres database (Railway-managed PG or Coolify-managed PG both work).
Disable ENABLE_USER_REGISTRATION after creating your first admin.
To migrate from SQLite to Postgres later, use Kanboard's built-in db_export.php / db_import.php scripts — both ship in this image.