Railway

Deploy OpenObserve — Self-Hosted Logs, Metrics & Traces

Self-host observability — logs, metrics & traces in one binary

Deploy OpenObserve — Self-Hosted Logs, Metrics & Traces

Just deployed

Deploy and Host OpenObserve on Railway

OpenObserve is the open-source alternative to Datadog, Splunk, and Elasticsearch — a Rust-native observability platform for logs, metrics, traces, and real user monitoring (RUM), behind a single binary and one web UI. Its Parquet columnar storage cuts telemetry storage cost by up to 140× versus ELK, and it needs no external database or search cluster. This template deploys it as a single service with a persistent volume, so you have a full observability stack on your own infrastructure in minutes.


What This Template Deploys

ServicePurpose
OpenObserveThe full observability platform — ingestion, search, dashboards, alerts, and RUM on port 5080

A single service — no external database, Elasticsearch, or S3 bucket required. A persistent volume at /data holds the embedded SQLite meta-store and the Parquet telemetry files, so your observability data survives redeploys.


About Hosting

OpenObserve's whole appeal is doing what a Datadog or ELK stack does without the operational weight — and this template keeps it that simple.

One binary, no external dependencies. In local mode, OpenObserve uses an embedded SQLite meta-store and local-disk Parquet storage — no Postgres, Elasticsearch, Redis, or S3 to provision. The single container is feature-complete for logs, metrics, traces, dashboards, alerts, and RUM. That's the point: full observability without running a complex stack. This template deploys exactly that, one service with ZO_LOCAL_MODE=true.

Up to 140× lower storage cost than ELK. OpenObserve stores telemetry as compressed Parquet columnar files instead of Elasticsearch's Lucene shards, which the makers measure at up to 140× lower storage cost. For high-volume logs and metrics, that's the difference between an affordable stack and a runaway Datadog or Splunk bill.

The /data volume is your entire observability history — persist it. Everything lives under /data: the SQLite metadata and all Parquet telemetry files. Without the mounted volume, every redeploy wipes your logs, metrics, and traces. This template mounts it so your history survives.

Your admin account is created from environment variables. Set ZO_ROOT_USER_EMAIL and ZO_ROOT_USER_PASSWORD before deploying, and OpenObserve creates the root user on first boot — no wizard. Open the web UI and log in with those credentials.

This is single-node local mode. Local mode is a complete, feature-rich observability platform ideal for one application, a small team, or a startup's whole stack. The distributed cluster mode (multiple node roles with Postgres and S3) is a separate, heavier deployment — out of scope here. For most self-hosters, single-node is exactly right.

Send data via OpenTelemetry. OpenObserve is OTel-native, so point your OpenTelemetry collectors, SDKs, or agents at its ingestion endpoint to stream logs, metrics, and traces. It also ingests from Fluent Bit and Vector.

Typical cost: ~$5–15/month on Railway depending on ingestion volume and retention. OpenObserve is open source and free — versus Datadog and Splunk, which bill per GB ingested.


How It Compares

OpenObserve (self-hosted)DatadogElasticsearch / ELKGrafana Loki
Cost modelFlat infraPer GB / hostInfra + heavy opsInfra + stack
Storage costUp to 140× lower (Parquet)Vendor pricingHigh (Lucene)Low-ish
SignalsLogs, metrics, traces, RUMAllLogs (mainly)Logs (mainly)
DependenciesNone (single binary)ManagedManySeveral
Data ownershipFull — your infraVendorFullFull
Self-hostableYesNoYesYes

Datadog and Splunk are powerful but bill per GB and keep your telemetry on their servers. ELK is capable but operationally heavy and storage-hungry. Loki handles logs but not the full signal set. OpenObserve's edge is all four signals — logs, metrics, traces, and RUM — in one dependency-free binary with Parquet storage that cuts cost, self-hosted with your telemetry on infrastructure you own.


Deploy in Under 5 Minutes

  1. Click Deploy on Railway — OpenObserve builds automatically (~2 minutes)
  2. Set ZO_ROOT_USER_EMAIL and a strong ZO_ROOT_USER_PASSWORD
  3. Confirm the volume is mounted at /data and ZO_DATA_DIR=/data
  4. Open your Railway domain on port 5080 and log in with your root credentials
  5. Point your OpenTelemetry collectors or log shippers at the ingestion endpoint

Explore the sample data, build dashboards, and set alerts once your telemetry is flowing.


Common Use Cases

  • Self-hosted Datadog alternative — logs, metrics, traces, and RUM in one platform without per-GB billing
  • Application observability — collect and search your app's logs and traces from one searchable UI
  • OpenTelemetry backend — a native OTel destination for your collectors, SDKs, and agents
  • Startup observability — a full monitoring stack for a whole product on one affordable service

Configuration

VariableRequiredDescription
ZO_ROOT_USER_EMAILRequiredRoot admin email — creates the account on first boot
ZO_ROOT_USER_PASSWORDRequiredRoot admin password — set a strong value
ZO_DATA_DIRPre-set/data — telemetry and metadata on the mounted volume
ZO_LOCAL_MODEPre-settrue — single-node mode with embedded SQLite and local Parquet
PORT / ZO_HTTP_PORTPre-set5080 — the web UI and ingestion API
ZO_HTTP_ADDRPre-set0.0.0.0 so Railway can route to it

Persist the /data volume. The SQLite meta-store and all Parquet telemetry live there — without the volume, every redeploy erases your logs, metrics, and traces. This template mounts it.

Set the root credentials before deploy. ZO_ROOT_USER_EMAIL and ZO_ROOT_USER_PASSWORD create the admin on first boot — no wizard. Use a strong password.


Dependencies for OpenObserve Hosting

  • Railway account — ~$5–15/month depending on ingestion volume and retention
  • A persistent Railway volume mounted at /data (included)
  • No external database, Elasticsearch, or S3 — local mode needs none
  • OpenTelemetry collectors or log shippers (Fluent Bit, Vector) to send data

Deployment Dependencies

Implementation Details

The template runs the official openobserve/openobserve image as a single service on port 5080 with ZO_LOCAL_MODE=true. In local mode, OpenObserve uses an embedded SQLite meta-store and stores telemetry as Parquet columnar files on local disk, so no external Postgres, Elasticsearch, Redis, or S3 is required — the container is a complete observability platform on its own. A persistent volume at ZO_DATA_DIR=/data holds both metadata and Parquet files, so all logs, metrics, traces, and RUM data survive redeploys.

The root admin is created at first boot from ZO_ROOT_USER_EMAIL and ZO_ROOT_USER_PASSWORD — no setup wizard — and ZO_HTTP_ADDR=0.0.0.0 lets Railway route to the service over automatic HTTPS. OpenObserve is OpenTelemetry-native, accepting data from OTel collectors and SDKs as well as Fluent Bit and Vector. This is single-node local mode, feature-complete for a single app or small team; distributed cluster mode (multiple node roles with PostgreSQL and S3) is a separate, heavier architecture. Because storage uses compressed Parquet rather than Lucene shards, retention costs are dramatically lower than an equivalent Elasticsearch deployment.


Frequently Asked Questions

Does it need Postgres, Elasticsearch, or S3? No. Local mode uses an embedded SQLite meta-store and local-disk Parquet, so the single container is complete on its own. Those are only needed for distributed cluster mode.

How does it cut storage cost so much? OpenObserve stores telemetry as compressed Parquet columnar files rather than Elasticsearch's Lucene shards, which the makers measure at up to 140× lower storage cost.

How do I log in the first time? Set ZO_ROOT_USER_EMAIL and ZO_ROOT_USER_PASSWORD before deploying; OpenObserve creates the root user on first boot. Open your Railway domain and sign in — no setup wizard.

Does my telemetry persist across redeploys? Yes, with the /data volume mounted. All metadata and Parquet files live there. Without the volume, redeploys wipe your observability history.

How do I send data to it? OpenObserve is OpenTelemetry-native — point your OTel collectors, SDKs, or agents at its ingestion endpoint. It also accepts data from Fluent Bit, Vector, and similar shippers.

Is single-node enough? For one application, a small team, or a startup's whole stack, yes — local mode is feature-complete. Distributed cluster mode is for very high-scale, multi-node deployments.

What signals does it handle? Logs, metrics, traces, and real user monitoring (RUM), plus dashboards and alerts — all four observability signals in one platform.


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 get a full observability platform in one click — a single dependency-free binary, the /data volume persisted, root credentials set, and automatic HTTPS. Logs, metrics, traces, and RUM with Parquet storage that slashes cost, on infrastructure you own.


Template Content

More templates in this category

View Template
SigOnly
Deploy SigNoz with a working demo app & config in one click

zoeyjones
22
View Template
Unwrapped Spotify Music Stats
Unwrapped Spotify Music Stats, Estatísticas de músicas disponíveis

Jorge Henrique
1
View Template
OpenTelemetry Collector and Backend
OpenTelemetry Collector with Backend Stack

Melissa
112