Deploy and Host OpenObserve on Railway

OpenObserve is an open-source observability platform for logs, metrics, traces and front-end monitoring — a simpler, far cheaper alternative to Datadog, Splunk and Elasticsearch, claiming roughly 140x lower storage costs thanks to a columnar, object-storage-backed design. This template runs it the way it is meant to run in production: a single binary with its bulk data in a managed object-storage bucket.

About Hosting OpenObserve

This deploys OpenObserve v0.92.0 (pinned) as one service in single-node mode, and — unlike the other OpenObserve templates in the marketplace — points its storage backend at a Railway object-storage bucket instead of a local disk. That is the whole point of OpenObserve: the ingested parquet data and its full-text index live in the bucket (ZO_LOCAL_MODE_STORAGE=s3), which is cheap and grows without bumping into a volume size limit. A small attached volume keeps only what must be local — the SQLite metadata (users, orgs, stream schemas, dashboards, alerts) and the transient write-ahead log.

The image is distroless, so everything is configured through ZO_* environment variables — there is no start command to maintain. The admin password is generated for you and already satisfies OpenObserve's strength policy (upper, lower, digit and a special character), so there is nothing to fill in before deploying.

Common Use Cases

Centralised logs, metrics and traces: ship application and infrastructure telemetry over OTLP or the HTTP ingestion API and query it with SQL.
A cheaper Datadog / Elasticsearch replacement: keep months of data in object storage at a fraction of the cost of an ELK stack or a SaaS bill.
Self-hosted APM and RUM: traces and front-end/browser monitoring in one place.

Dependencies for OpenObserve Hosting

Deployment Dependencies

The upstream openobserve/openobserve image — no fork, no custom build.
A Railway object-storage bucket (provisioned by this template) for the parquet data and index.
A small volume mounted at /data for metadata and the write-ahead log.

Implementation Details

ZO_LOCAL_MODE=true + ZO_LOCAL_MODE_STORAGE=s3: single node, data in the bucket.
The bucket credentials are wired automatically via ${{ Storage.* }} references.
PORT and ZO_HTTP_PORT are both 5080; the public domain is created for you.
ZO_TELEMETRY=false — no anonymous phone-home.
Log in with ZO_ROOT_USER_EMAIL (default admin@example.com) and the generated ZO_ROOT_USER_PASSWORD (see the service variables after deploy).

Why Deploy OpenObserve on Railway?

Railway provisions the compute, the object-storage bucket and the public domain together, so the production-shaped deployment — the one that actually keeps storage costs low — comes up on the first deploy with nothing to wire by hand. Expect roughly 400–700 MB of RAM at idle for a single-node instance; cost scales with how much telemetry you ingest and retain, and because the bulk of that lives in object storage rather than on a fixed-size disk, you are not forced to resize a volume as your data grows.