Deploy OpenObserve | (Just Updated) Datadog Alternative That Actually Boots
Logs, metrics and traces. Boots first try, unlike every other listing.
openobserve
Just deployed
/data
Deploy and Host OpenObserve on Railway
OpenObserve is an open-source observability platform for logs, metrics and traces — a self-hosted alternative to Datadog, Grafana Loki and Elasticsearch. It ingests OTLP, Elasticsearch-compatible and plain JSON data, stores it as compressed Parquet, and ships with a query UI, dashboards, alerts and an OpenAPI/MCP surface.
This template runs OpenObserve v0.92.2 in local mode as a single service on a persistent volume: no external database, no object store, no cluster.
About Hosting OpenObserve
OpenObserve is a single Rust binary. In local mode it keeps its metadata in an embedded
SQLite store and its data as Parquet files on disk, so the only infrastructure it needs is
one container and one volume mounted at /data. It listens on a fixed port unless told
otherwise, it refuses to start without a valid root user, and it enforces a password policy
on that user at first boot — three details that decide whether a deploy works at all on a
platform that injects its own port and generates its own secrets.
This image handles all three: it binds whatever port Railway injects, it validates the root credential before the server starts and fails with a readable message instead of a Rust panic, and it re-applies the root password on every boot so a redeploy is a working password reset.
Why Deploy OpenObserve 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 OpenObserve 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.
Observability is an always-on workload: ingestion, compaction and retention run continuously, and Railway's usage-based billing suits that better than a fixed instance you have to size in advance. The volume keeps every ingested stream across redeploys.
Common Use Cases
- Central log store for services already running in the same Railway project, over OTLP or the Elasticsearch-compatible ingest API.
- Metrics and traces backend for OpenTelemetry collectors, with dashboards and alerting.
- A cheaper, self-hosted replacement for Datadog or a hosted ELK stack for small teams.
- Long-term archive of application events queried with SQL from the built-in UI.
Dependencies for OpenObserve
- The OpenObserve binary (bundled in the image), running in local mode.
- A Railway volume mounted at
/datafor the metadata store, WAL and Parquet files.
Deployment Dependencies
- OpenObserve source and documentation: https://github.com/openobserve/openobserve
- Upstream is licensed AGPL-3.0.
Implementation Details
Two variables are set for you and both carry working defaults, so the deploy form asks for nothing:
ZO_ROOT_USER_EMAIL— defaults toadmin@.ZO_ROOT_USER_PASSWORD— generated per deploy, in a shape that satisfies OpenObserve's password policy (lowercase, uppercase, digit and special character). Change it in the Railway variables panel and redeploy; the new password is applied on the next boot.
Log in at your public URL with that email and password. The credential is also what the ingest APIs authenticate against.
Template Content
openobserve
ghcr.io/bon5co/openobserve-railway:v0.92.2