Deploy and Host ClickHouse on Railway

ClickHouse is an open-source column-oriented database built for analytics: it scans billions of rows and returns aggregates in the time a row-store spends planning the query.

About Hosting ClickHouse

This template runs the official clickhouse/clickhouse-server:26.7.3.19-alpine image with no custom build in between, so you get upstream ClickHouse and upstream security updates on a pinned, immutable tag. Data lives on a persistent Railway volume mounted at /var/lib/clickhouse, and a random password is generated at deploy time — nothing ships with a default credential.

Both interfaces are wired up. The HTTP interface is served over your public Railway domain on port 8123, which is what curl, the JDBC/ODBC drivers and the built-in /play query console speak. The native protocol is exposed through a Railway TCP proxy on port 9000, so clickhouse-client and the official Python, Go and Node drivers connect from outside the project without extra configuration. SQL-driven access management is enabled, so you can CREATE USER, CREATE ROLE and GRANT instead of editing XML files you cannot reach on a managed platform.

Common Use Cases

Product and event analytics: Store raw events and aggregate them on read, instead of maintaining pre-rolled summary tables that answer only the questions you anticipated.
Observability and log storage: Keep logs, metrics and traces at full resolution for far longer than a row-oriented store makes affordable, and still filter across them interactively.
The warehouse behind a dashboard: Serve user-facing charts and reports directly, where sub-second GROUP BY over large tables is the whole requirement.

Dependencies for ClickHouse Hosting

Deployment Dependencies

ClickHouse 26.7 — the database itself
A Railway volume for /var/lib/clickhouse, and a TCP proxy for the native protocol on port 9000

Implementation Details

The image already binds :: through its bundled docker_related_config.xml, which is what Railway's IPv6-only private network needs, so no listen-address override is applied.

The service sets PORT=8123. ClickHouse itself ignores that variable — it is there for Railway. The image exposes 9000, 8123 and 9009, native protocol first, and without an explicit PORT the platform aims HTTP traffic and healthchecks at the binary protocol port, which never answers.

There is deliberately no healthcheck path. Railway keeps the previous container running until a new one reports healthy, and ClickHouse takes an exclusive lock on /var/lib/clickhouse/status. With both containers on one volume the new instance cannot start, so it can never report healthy, so the old one never stops — every redeploy would fail with:

Cannot lock file /var/lib/clickhouse/status.
Another server instance in same directory is already running.

Omitting the healthcheck lets Railway stop the old container first, which is the only ordering a single-writer database survives.

The start command is:

/entrypoint.sh -- --logger.console=1 --logger.level=information

It names the image's own entrypoint because Railway replaces ENTRYPOINT rather than appending to it. The bare -- matters: only after it does clickhouse-server accept free-form config overrides. These two turn on console logging — the image otherwise writes to files inside the container, where Railway's log view cannot reach them — at information rather than the default trace, which would bury real errors under hundreds of lines a second about part merges.

Credentials come from CLICKHOUSE_PASSWORD, generated per deployment for the default user. Change it with ALTER USER rather than by editing the variable, since the password is written into the server's user configuration at boot.

Why Deploy ClickHouse 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 ClickHouse 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.

Resources: about 2 GB RAM is a comfortable starting point — ClickHouse sizes its caches from the container limit and will use what it is given — and a 1 GB volume you can grow later without downtime. Analytical queries are memory-hungry by nature; raise the memory before assuming a query is at fault.