Deploy and Host Formbricks 5 on Railway

Formbricks, the survey and feedback platform, self-hosted at version 5, with the two services it refuses to start without: the Hub and Cube.

Nothing to fill in. Every secret and both database passwords are generated.

About Hosting Formbricks 5

The existing Formbricks template pulls formbricks/formbricks:latest from Docker Hub, where the newest tag is 3.6.0, from March 2025. The project moved to GHCR and never published to Docker Hub again, so that template keeps deploying a build from March 2025 and will never update on its own.

Bringing it current is not a tag change. Formbricks 5 refuses to boot without a Hub and a Cube service: its environment validation fails on CUBEJS_API_URL, CUBEJS_API_SECRET, HUB_API_URL and HUB_API_KEY before the application starts. Upstream runs those services with one-shot migration containers and condition: service_completed_successfully, which a template cannot express. The implementation details below are how it is expressed here instead.

That makes six services: Formbricks, its Postgres, Valkey, the Hub, the Hub's Postgres, and Cube. Six, because that is what Formbricks 5 needs to start.

Common Use Cases

Surveys and feedback collection on your own infrastructure, with responses stored in your own Postgres.
Running a current Formbricks 5 build from GHCR instead of the Docker Hub image frozen at 3.6.0.

Dependencies for Formbricks 5 Hosting

Deployment Dependencies

Formbricks ghcr.io/formbricks/formbricks:5.2.1 (public)
Hub ghcr.io/formbricks/hub:0.8.4
Cube, built from ak40u/formbricks-cube-railway
Postgres pgvector/pgvector:pg18, for Formbricks
HubPostgres pgvector/pgvector:pg18, for the Hub
Valkey valkey/valkey:8.1.4-alpine

Formbricks is by Formbricks GmbH; the parts used here are AGPL-3.0.

Implementation Details

The Hub's migrations moved into its start command. goose … up && river migrate-up … && exec /app/hub-api: "migrate, then serve" is an ordering inside one service, so no separate migration container is needed.
Cube's configuration is baked into an image. Upstream bind-mounts cube.js and the data model from its repository. There is no host directory to mount from here, so they live in ak40u/formbricks-cube-railway instead.
The Hub gets its own database. Sharing one meant the Hub migrated first, and the Formbricks Prisma migration then sat on a lock until it timed out at 300 seconds. Upstream supports HUB_DATABASE_URL for exactly this.
Both databases are pgvector images. The Hub's first migration runs CREATE EXTENSION vector, and plain Postgres answers "extension is not available".

Verification

Deployed from this template: /health returns 200, the sign-up page is served, and the management API answers unauthenticated calls with not_authenticated rather than a 404. The environment validation that blocks a misconfigured Formbricks 5 passes, which is only possible if the Hub and Cube are both reachable and their secrets match.

Creating the first account happens in the browser and was not driven during testing.

Why Deploy Formbricks 5 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 Formbricks 5 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.