Deploy and Host bittery on Railway

Bittery is a source-available, zero-knowledge password manager. Passwords, notes, cards, and TOTP secrets are encrypted on your device before they reach the server—so plaintext vault data never leaves client devices. It supports web, desktop, mobile, and browser extension clients, with optional self-hosting or Bittery Cloud.

About Hosting bittery

Hosting Bittery means running a Caddy reverse proxy, a Rust API server, and a web vault (static SPA behind nginx), backed by PostgreSQL. Caddy terminates TLS and routes API traffic (/rpc, /sync, /cdn, etc.) to the server and everything else to the web app on a single domain. The server handles authentication (SRP), encrypted vault sync, teams, and share links; it does not decrypt user data. Database migrations run automatically on server startup. The Railway template pre-wires DATABASE_URL and object-storage bucket variables—after deploy you mainly set DOMAIN on the Caddy service and optionally customize JWT_SECRET or CORS_ORIGIN. Redis/Valkey is optional for cross-instance SSE sync and distributed rate limiting. Official images: ghcr.io/bittery-org/bittery-server:latest, ghcr.io/bittery-org/bittery-web:latest, and caddy:2-alpine with the repo's Caddyfile.

Common Use Cases

Personal or family vault — Run your own password manager without relying on a third-party cloud.
Team or org data sovereignty — Keep encrypted vault metadata and auth on infrastructure you control, with vault sharing and share links in self-hosted mode.
Quick self-hosted trial — One-click Railway deploy with managed Postgres and storage instead of setting up Docker Compose on a VPS.

Dependencies for bittery Hosting

PostgreSQL 15+ (required) — Primary datastore for users, sessions, and encrypted vault blobs. Provisioned and linked by the template.
Caddy (required) — Reverse proxy with automatic HTTPS. Uses {$DOMAIN} from the DOMAIN environment variable to bind the site and route traffic.
bittery-server — Rust/Axum API (PORT defaults to 3000, health check at /healthz).
bittery-web — Vite-built SPA served on port 8080 (health check at /nginx-health).
Object storage (included in template) — S3-compatible bucket for file attachments; credentials are pre-filled by the template.

Deployment Dependencies

Implementation Details

DOMAIN on the Caddy service

In the Caddyfile, {$DOMAIN} is Caddy's syntax for an environment variable. Set DOMAIN on the Caddy service to your public hostname—either the Railway-generated URL (e.g. your-app.up.railway.app) or a custom domain you've attached in Railway networking settings. Caddy uses it as the site address and to obtain TLS certificates.

Template pre-fills (no manual setup needed)

DATABASE_URL — wired from the Railway Postgres plugin
BITTERY_STORAGE_* — wired from the template's object-storage bucket

What you configure after deploy

# Caddy service
DOMAIN=your-app.up.railway.app

# Server service (template may auto-generate JWT_SECRET)
JWT_SECRET=
CORS_ORIGIN=https://your-app.up.railway.app
BITTERY_MODE=self-hosted

VITE_SERVER_URL is not required. With Caddy serving both the web app and API on the same domain, the web app uses the current page origin for RPC and sync requests.

Optional server vars: REDIS_URL (cross-instance sync), SHARE_LINK_DAILY_LIMIT (default 50).

Updates: redeploy each service to pull the latest latest image tags; migrations apply on server boot.

Why Deploy bittery on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying bittery on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.