--- title: "Deploy OpenObserve [Updated Sep '26]" description: "Observability in one binary: logs, metrics, traces, RUM. Data on a volume." category: "Observability" url: https://railway.com/deploy/openobserve-updated-sep-26 --- # Deploy OpenObserve [Updated Sep '26] Observability in one binary: logs, metrics, traces, RUM. Data on a volume. **[Deploy OpenObserve [Updated Sep '26] on Railway](https://railway.com/template/openobserve-updated-sep-26)** Machine-readable deploy manifest (JSON, validated by TemplateCI): https://railway.com/deploy/openobserve-updated-sep-26/manifest.json - **Creator:** Auromations - **Category:** Observability - **Total deploys:** 1 ## Template content ### OpenObserve - **Image:** openobserve/openobserve:v0.92.2 - **Health check:** /healthz - **Public domain:** Yes ## Documentation # Deploy and Host OpenObserve on Railway OpenObserve is an open source observability platform for logs, metrics, traces, RUM and session replay. It ships as a single Rust binary and stores data as compressed Parquet, which is why its authors measure roughly 140x lower storage cost than an Elasticsearch based stack for the same data. ## About Hosting OpenObserve This template runs OpenObserve v0.92.2 as one service backed by a Railway volume mounted at `/data`. It runs in local mode, so metadata lives in an embedded store and data lives on the volume. No Postgres, no etcd and no object storage bucket are involved, and there is nothing to wire together after deploy. The root user is created on first boot from two variables. You supply the login email, the password is generated for you, and both stay visible in the service's Variables tab so you can retrieve them at any time. Telemetry to the upstream vendor is turned off. Ingestion works over several protocols on the same instance: OpenTelemetry OTLP for logs, traces and metrics, a plain JSON endpoint, Elasticsearch `_bulk` and Loki. Most collectors and shippers you already run can point at it with only a URL and a basic auth header changed. ## Common Use Cases - Central log search for a group of Railway services, replacing scattered per service log tabs with one queryable store - An OTLP endpoint for an OpenTelemetry Collector already running traces and metrics, without paying per host for a hosted vendor - Frontend RUM and session replay for a small product, kept on infrastructure you control - A cheap long retention tier for logs that would be expensive to keep in a hosted observability service ## Dependencies for OpenObserve Hosting None. The binary is self contained and this template provisions everything it needs. ### Deployment Dependencies - Upstream project: https://github.com/openobserve/openobserve - Container image: `openobserve/openobserve:v0.92.2` on Docker Hub - Documentation: https://openobserve.ai/docs/ - A Railway volume, created automatically by this template ### Implementation Details **Logging in.** `ZO_ROOT_USER_EMAIL` defaults to `admin@example.com` and is prompted at deploy so you can set your own. `ZO_ROOT_USER_PASSWORD` is generated and readable in the Variables tab. Open the public URL and sign in with that pair. Editing the variables later does not rotate an existing user's password, because the root account is seeded only when the volume is empty. **Sending logs.** ```bash curl -u "$EMAIL:$PASSWORD" -H 'Content-Type: application/json' \ -d '[{"level":"info","msg":"hello","service":"my-app"}]' \ https://YOUR-DOMAIN/api/default/my_stream/_json ``` **OpenTelemetry endpoints**, all requiring an `Authorization: Basic` header built from the same email and password: ``` https://YOUR-DOMAIN/api/default/v1/logs https://YOUR-DOMAIN/api/default/v1/traces https://YOUR-DOMAIN/api/default/v1/metrics ``` **Querying from the API.** Search window timestamps are in microseconds, not milliseconds. A window in the wrong unit returns zero hits and no error, which is the single most common cause of a "my data vanished" report. **Retention.** There is no retention limit by default, so the volume grows for as long as you ingest. Set a per stream retention in the stream's settings, or set `ZO_COMPACT_DATA_RETENTION_DAYS` globally, and resize the volume in the Railway dashboard before it fills. A full volume fails ingestion while the UI keeps serving, so it looks like a data problem rather than a disk problem. **Configuration choices worth knowing.** The port is pinned to 5080 on the app, on `PORT` and on the service domain, because Railway's port autodetection is unreliable against this image. `ZO_HTTP_IPV6_ENABLED=true` so Railway's IPv6 private network can reach the container, and the IPv4 healthcheck on `/healthz` was confirmed to still pass with it enabled. The image is distroless and has no shell, so the template runs the image's own entrypoint rather than a wrapped start command. **Scaling past one node.** Local mode is deliberate and is the right shape for a single instance. For a cluster, switch to `ZO_LOCAL_MODE=false` with `ZO_META_STORE=postgres` and S3 compatible object storage for data. That is a multi service topology and is not what this template deploys. **Troubleshooting.** - Blank page or a redirect loop right after deploy: the app is still doing first boot directory initialisation on a new volume. Give it a minute and reload. - Searches return nothing although ingestion returned `successful`: check the time range unit, microseconds, and check the stream name in the Streams page. - Ingestion suddenly returns errors while the UI works: the volume is full. Resize it and set retention. - 401 on every ingest call: the credentials are the root email and password from the Variables tab, sent as HTTP basic auth, not a bearer token. ## Why Deploy OpenObserve on Railway? Railway gives OpenObserve the two things it actually needs, a persistent volume and a public HTTPS domain, without any of the cluster machinery its HA mode would otherwise pull in. The pinned image means your instance does not change version underneath you, the volume means a redeploy does not lose the data you have already ingested, and scaling is a volume resize rather than a migration. Both were verified empirically before publishing: the template was click deployed into a clean project, logs were ingested and read back through the search API, and the data was still queryable after a full redeploy. ## Similar templates - [Pyroscope profiling](https://railway.com/deploy/pyroscope-profiling) — Protected continuous profiling with durable Pyroscope storage. - [SigOnly](https://railway.com/deploy/sigonly) — Deploy SigNoz with a working demo app & config in one click - [Unwrapped Spotify Music Stats](https://railway.com/deploy/wide-bold) — Unwrapped Spotify Music Stats, Estatísticas de músicas disponíveis Open this page in a browser: https://railway.com/deploy/openobserve-updated-sep-26