Skip to main content
Railway can run the public Bifrost image as a long-running service. The deployment below uses PostgreSQL so configuration and logs survive service replacement.
Support level: Preview. This guide is not continuously exercised against a live Railway project.

Compatibility summary

Bifrost Enterprise requires PostgreSQL 16 or later for both stores and does not support the SQLite alternative on this page.

Deploy Bifrost

Step 2: Create the Bifrost service

Create the file that Bifrost will load:

Step 3: Supply configuration and secrets

In the service settings, set the start command to:
Set the health-check path to /health and deploy one replica. The configuration requires authentication on inference routes. If external access is needed, generate a public domain, use the configured setup token to create the first admin account, and create a virtual key before sending inference traffic or sharing the hostname with clients.

Step 4: Verify

One-click status

Railway supports Deploy on Railway buttons only after a project is created and published as a Railway template. Bifrost does not currently have a verified Maxim-owned template ID, so this page does not fabricate a deploy link. Image-backed Railway templates also require an explicit process for testing and publishing each new Bifrost image version.

SQLite storage alternative (OSS only)

This alternative is available only for OSS Bifrost. For a single-instance SQLite deployment, create config.json from the SQLite configuration, encode and inject it using Step 3, remove the PostgreSQL variables, and attach a Railway volume at /app/data. Before using the deployment, confirm that the mounted path is writable by container UID 1000. Railway volumes can be root-owned; if the platform configuration cannot provide safe write access, use PostgreSQL instead. Keep one replica because SQLite files are not a replica-coordination mechanism.

Scaling and upgrades

  • OSS SQLite volume: one replica.
  • PostgreSQL-backed OSS configuration: one replica.
  • File-only OSS: multiple replicas only with identical immutable config and secrets.
  • Enterprise mesh: not qualified on this page; validate required peer networking or use release-qualified broker mode.
Set RAILWAY_DEPLOYMENT_DRAINING_SECONDS to give Bifrost time after SIGTERM; the platform default is not a Bifrost guarantee. Pin versioned images and use Railway deployment history or the prior tag for rollback. Database migrations are not reversed automatically.

Troubleshooting

  • service unavailable: verify PORT, APP_PORT, target port, and APP_HOST are aligned.
  • Health timeout: inspect startup migration/database logs and adjust the deployment health timeout only after correcting connectivity.
  • /app/data permission error: the root-owned Railway volume is not writable by UID 1000; use a safe ownership mechanism or PostgreSQL.
  • Configuration disappears: the deployment used ephemeral local storage.
  • Stream terminates during deploy: configure sufficient draining overlap and client retry behavior.
See Bifrost Deployment Requirements, its deployment verification checklist, and Enterprise clustering for the remaining operational guidance.