Deploy and Host SigNoz on Railway

SigNoz is an open-source observability platform — distributed traces, metrics and logs in one application, stored in ClickHouse. It is the self-hosted alternative to Datadog and New Relic, speaks OpenTelemetry natively, and needs no proprietary agent.

This template deploys SigNoz as three services: ClickHouse (with ClickHouse Keeper embedded in the same process), the SigNoz application, and an OpenTelemetry collector that accepts your telemetry over OTLP.

About Hosting SigNoz

SigNoz is not a single container. It needs a ClickHouse cluster, a coordination service for the replicated-table DDL it issues, a schema migration step that must complete before the application starts, and a collector to receive OTLP. Getting those four things to agree is most of the work, and it is where self-hosted SigNoz deployments usually go wrong.

Three things this template does that are easy to get wrong:

Coordination state lives on the volume. ClickHouse Keeper runs embedded in the ClickHouse process and writes its log and snapshots under /var/lib/clickhouse/coordination, which is inside the mounted volume. If coordination state is lost, ClickHouse brings the replicated tables back read-only — the container still looks healthy, the UI still loads, and ingest silently stops. Verified here by destroying the container and bringing it back on the same volume: existing spans were still readable and a fresh OTLP push still landed.
The schema migrations run before the collector serves. The collector service runs migrate bootstrap, migrate sync up and migrate async up against ClickHouse, retrying until ClickHouse accepts connections, and only then starts receiving. Migrations are idempotent, so a redeploy is safe.
Both stateful services have volumes. ClickHouse holds your telemetry, and the SigNoz application holds its SQLite database — users, dashboards, saved views and alert rules. Without a volume on the second one, every redeploy loses your dashboards even though the telemetry survives.

Why Deploy SigNoz on Railway

Railway gives each service a private network address, a managed volume and a public domain, which is exactly the shape this stack needs — ClickHouse stays private, the application and the ingest endpoint each get their own URL.

Two problems in the general self-hosted case are closed here by construction:

The admin account is yours before anyone else can take it. A stock SigNoz has no users on first boot, and its /api/v1/register endpoint hands out the first account with isRoot: true to whoever calls it. On a public URL that is a race, and losing it means a stranger owns your observability data. This template registers the first account from your own template variables during boot, so by the time the URL answers, setup is complete and SigNoz reports self-registration is disabled to everybody else. Verified against the running deployment.

The ingest endpoint requires a token. SigNoz Core has no ingest authentication of its own, so a public OTLP endpoint lets anyone write into your ClickHouse — on a platform that bills for the storage. The collector here is configured with a bearer-token authenticator, so OTLP pushes without Authorization: Bearer $INGEST_TOKEN are rejected with 401.

All three images are pinned to explicit versions rather than a floating tag, so a redeploy rebuilds what you already tested. ClickHouse carries one-way schema migrations, which makes an unpinned tag a genuine risk rather than a stylistic preference.

Common Use Cases

Replace Datadog or New Relic for application traces, metrics and logs at a fixed hosting cost
Give an OpenTelemetry-instrumented service a backend to send to, without signing up for a SaaS
Debug latency across services with distributed traces and flamegraphs
Centralise logs from several Railway services and query them alongside the traces
Run dashboards and alert rules over telemetry you keep on your own infrastructure

Dependencies for SigNoz

ClickHouse — the telemetry store, with ClickHouse Keeper embedded for cluster coordination
OpenTelemetry collector — the SigNoz distribution, which also runs the schema migrations
OpenTelemetry SDK or collector in your own app — to produce the telemetry

Deployment Dependencies

SigNoz: https://signoz.io — source at https://github.com/SigNoz/signoz
OpenTelemetry OTLP specification: https://opentelemetry.io/docs/specs/otlp/
ClickHouse: https://clickhouse.com

After deploying

Set ADMIN_EMAIL on the deploy form. That address becomes the owner account.
After the deploy finishes, read ADMIN_PASSWORD from the SigNoz service's variables and sign in with it. Change it from inside the UI once you are in.
Point your application at the collector's public URL, with the token:
```
OTEL_EXPORTER_OTLP_ENDPOINT=https://
OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer 
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
```
INGEST_TOKEN is generated for you and lives on the collector service's variables. Services running inside the same Railway project can also reach the collector privately on port 4317 (OTLP gRPC) without going through the public domain.

A note on plan sizing. ClickHouse is the memory-hungry part of this stack. It idles at roughly 250 MB and settles near 550 MB once the SigNoz schema is in place, so it fits a 1 GB service, but it will want considerably more as your telemetry volume grows — ClickHouse trades memory for query speed by design. Give it Hobby-plan headroom if you intend to keep more than a little data, and set a retention period in SigNoz's settings early rather than late.