Deploy OpenStatus

Deploy and Host OpenStatus on Railway

Self-host OpenStatus to run synthetic uptime checks against your APIs and publish a branded status page customers can subscribe to. It is the open-source alternative to Better Stack, Instatus and Atlassian Statuspage, for teams who want incident history and a public availability page without handing monitoring data to a vendor. Deploy OpenStatus on Railway and you own the checks, the timeline and the page users see during an outage.

This template runs the full stack, not a cut-down single container. dashboard is the admin interface and status-page serves the public page on its own domain. server is the REST and MCP API, and workflows runs the schedulers, incident transitions and notification outbox. ingest receives results from probes; probe performs the HTTP, TCP, DNS, ICMP and gRPC checks. libsql is the database, running Turso's sqld, and bootstrap applies migrations and wires the probe to your first workspace.

Getting Started with OpenStatus on Railway

Open the dashboard service's URL and you land on the sign-in screen. Self-hosted OpenStatus signs you in with a magic link, and rather than requiring an email provider on day one it prints that link to its own log. Enter any address you control, read the link from the dashboard's logs in Railway, and open it. The first account to sign in owns the workspace, so do this before sharing the URL.

Then create your first monitor: name it, choose HTTP, paste the URL to watch, and submit. On its settings tab scroll to Private Locations and tick railway, the probe in this project. Checks begin on the next cycle; restart the probe to skip its ten-minute refresh. Finally create a status page, add the monitor as a component, and open the status-page URL.

About Hosting OpenStatus

OpenStatus watches endpoints on a schedule, records each result, opens and resolves incidents automatically, and publishes the outcome. Teams self-host it when monitoring data is sensitive, when endpoints sit inside a private network, or when a status page priced per subscriber stops making sense.

• HTTP, TCP, DNS, ICMP and gRPC monitors with response assertions
• Automatic incident open and resolve, with a public event timeline
• Status pages with components, subscribers, passwords and translations
• Notifications via Slack, Discord, PagerDuty, Opsgenie, ntfy and webhooks
• A REST API and MCP server, so agents and scripts can manage monitors
• Importers for Better Stack, Instatus and Atlassian Statuspage

The split matters when you scale: the probe is its own service, so several can run in different regions or VPCs against one ingest server, and the public page is a separate origin carrying no admin surface.

Why Deploy OpenStatus on Railway

Railway supplies what this stack needs without the assembly.

• Private networking across all eight services, no ports exposed
• Persistent volumes for the database and the workflows replica
• Public domains and TLS for the dashboard, API and status page
• One-click redeploys that pick up new upstream images
• Per-service logs, where the sign-in link appears

Common Use Cases

• Publishing a customer-facing status page with incident history and subscribers
• Monitoring internal APIs and admin panels no public probe can reach
• Replacing a per-subscriber status page once the list outgrows a free tier
• Driving uptime checks from CI or an AI agent over the REST and MCP endpoints

Dependencies for OpenStatus

• ghcr.io/openstatushq/openstatus-dashboard:latest — admin interface
• ghcr.io/openstatushq/openstatus-status-page:latest — public status pages
• ghcr.io/openstatushq/openstatus-server:latest — REST and MCP API
• ghcr.io/openstatushq/openstatus-workflows:latest — schedulers and notifications
• ghcr.io/openstatushq/openstatus-private-location:latest — probe ingest
• ghcr.io/openstatushq/private-location:latest — probe agent
• ghcr.io/tursodatabase/libsql-server:latest — application database
• gridalpha/openstatus-railway — migrations and first-run bootstrap

libsql holds every workspace, monitor, incident and status page, and is reachable only on the private network. workflows keeps a synced local replica on a volume so its schedulers read without a round trip. bootstrap applies the schema on every boot, enables private locations on new workspaces, registers the probe and drives the one background job with no in-process scheduler.

Environment Variables Reference

Deployment Dependencies

• Source: https://github.com/openstatusHQ/openstatus
• Self-hosting guide: https://www.openstatus.dev/docs/guides/self-hosting-openstatus
• Database engine: https://github.com/tursodatabase/libsql
• Bootstrap image: https://github.com/gridalpha/openstatus-railway

Hardware Requirements for Self-Hosting OpenStatus

Eight services sounds heavy, but six idle under 256 MB. The database and the two Next.js tiers use most of the memory.

Self-Hosting OpenStatus

Upstream ships a Compose file for running it on a single box. Clone the repository and copy the example environment file:

git clone https://github.com/openstatusHQ/openstatus
cd openstatus
cp .env.docker.example .env.docker

Set AUTH_SECRET, SELF_HOST=true and CRON_SECRET in that file, then start the prebuilt images rather than building the monorepo:

docker compose -f docker-compose.github-packages.yaml up -d

The dashboard comes up on port 3002 and the status page on 3003. Two manual steps remain there that this Railway template handles for you: raising the workspace plan so private locations are allowed, and starting a probe with a key copied from the dashboard.

Is OpenStatus Free to Self-Host?

OpenStatus is open source under AGPL-3.0, so there is no seat count, monitor cap or subscriber limit to buy your way past. On Railway you pay only for the compute, memory and volume storage the eight services use, which for a handful of endpoints is a few dollars a month. The hosted openstatus.dev service remains if you would rather not operate it.

FAQ

What is OpenStatus? OpenStatus is an open-source synthetic monitoring and status page platform. It runs scheduled checks against your endpoints, opens incidents when they fail, and publishes availability on a page you brand and share.

What does this Railway template deploy? Eight services: the dashboard, the public status page, the API server, the workflows engine, the probe ingest server, a probe agent, a libSQL database, and a bootstrap worker that migrates the schema and completes first-run setup.

Why does the template include a separate database and probe service? OpenStatus stores workspaces, monitors and incidents in libSQL rather than a file beside the app, so the database is its own service with its own volume. The probe is separate because it is the component you normally run in several places at once, one per region or network.

How do I log in to a self-hosted OpenStatus for the first time? Enter your email on the sign-in page, then read the magic link from the dashboard's log. With SELF_HOST=true it is printed rather than emailed, so no mail provider is needed. Add a Resend API key later for real delivery.

Why are the latency charts empty on my self-hosted instance? Upstream stores raw check results in Tinybird, which is not in this template: its local container needs CLI-driven setup and issues a token that cannot be wired up automatically. Monitors, uptime, incidents and the status page all work without it. Point TINYBIRD_URL and TINY_BIRD_API_KEY at a Tinybird Cloud workspace to turn the charts on.

Can I monitor endpoints inside a private network with OpenStatus? Yes, and that is the main reason to self-host. Run another copy of ghcr.io/openstatushq/private-location inside that network, point its OPENSTATUS_INGEST_URL at this deployment's ingest service and give it a key from Settings. It reports back outbound only.

How do I put my status page on my own domain? Add the custom domain to the status-page service in Railway, then set the same hostname on the page in the dashboard. The app picks which page to render from the request host, so the two must match exactly.