Deploy and Host Swetrix on Railway

Swetrix is open-source, privacy-first web analytics — a cookieless Google Analytics alternative with funnels, custom events, error tracking, performance monitoring and session replay, and no consent banner to bolt on. This template runs the pinned v5.3.1 Community Edition release across four services, and the deploy form is empty: every value is filled in for you.

Three things this template does that the other Swetrix listing on this marketplace does not:

Your accounts and analytics survive a redeploy. Swetrix CE has no second database. The user, project, refresh_token and salt tables live in ClickHouse alongside the event data, so a ClickHouse service with no volume loses the login as well as the traffic history on every redeploy. Verified on 2026-08-02: recreate a volumeless ClickHouse container and the next query returns Code: 60 ... UNKNOWN_TABLE. Here the volume is mounted at /var/lib/clickhouse, and the same recreate returns the account intact.
The API is actually reachable from the UI. The Swetrix web app calls its backend at ${BASE_URL}/backend in self-hosted mode, so the gateway has to strip that prefix. Doing it the natural-looking way — an nginx proxy_pass http://$upstream/; with a variable upstream — sends every API call to the backend root instead, because nginx skips its usual prefix rewrite when the upstream is a variable. Measured here: POST /backend/v1/auth/register came back {"message":"Cannot POST /","statusCode":404}. This template strips the prefix with an explicit rewrite and registration returns 201, login 200.
ClickHouse gets the CPU you are paying for. Swetrix's own self-hosting compose pins concurrent_threads_soft_limit_num=1 so it fits a 1 GB VPS. On Railway that serialises every dashboard query onto a single thread. This image reads the container's cgroup quota instead. Measured in a 4-vCPU container on the same aggregation, three runs each: 3.89 s median pinned to one thread vs 2.16 s sized to the container.

About Hosting Swetrix

Swetrix Community Edition is a NestJS API plus a React Router web UI, backed by ClickHouse for storage and Redis for caching. ClickHouse is the whole instance state, not just the event store — accounts, projects, funnels, feature flags, refresh tokens and the key salt all live there — which makes persistent storage the difference between a working install and one that resets to a fresh signup screen whenever the platform replaces a container.

The UI hardcodes its API base to the same origin it is served from, so the two have to share a public hostname. Upstream's compose does that with a separate nginx container; this template runs nginx beside the frontend it fronts, which is one fewer always-on service to pay for. If either the frontend or the gateway exits, the container exits with it, so Railway restarts a broken deploy instead of leaving a gateway answering healthchecks in front of nothing.

Railway provisions four services — web UI + gateway, API, ClickHouse on a volume, Redis on a volume — wires them over the private network, generates the ClickHouse password, the Redis password and the JWT secret, and issues an HTTPS domain. The API waits for ClickHouse to answer /ping before it boots, because Swetrix's schema-initialisation step exits successfully even when it cannot reach the database, and an API that starts too early serves an instance with no tables until someone redeploys it.

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

Swetrix specifically benefits: ClickHouse keeps its data on a Railway volume rather than an ephemeral container filesystem, the analytics database and Redis stay off the public internet on the private network, and the query thread limit follows the plan you scale to instead of a number chosen for a 1 GB box.

Common Use Cases

Replace Google Analytics with cookieless, GDPR-oriented traffic analytics you own, with no consent banner and no third-party tracking vendor
Measure product funnels, custom events and real-user performance for a SaaS or marketing site on infrastructure you control
Run analytics for client sites under one self-hosted instance, with per-project sharing rather than per-seat pricing

Dependencies for Swetrix Hosting

ClickHouse — analytics storage and the application state (accounts, projects, tokens)
Redis — caching layer for the API

Deployment Dependencies

Swetrix — the Community Edition application
Swetrix self-hosting reference — upstream compose, log and RAM configs
swetrix-railway — the Railway-tuned images this template deploys

Implementation Details

The first account you register becomes the owner. DISABLE_REGISTRATION=true is set, and Swetrix allows the first signup regardless of that flag, so registration closes behind you automatically — set it to false on the api service if you want an open instance.

To send password-reset and invite emails, set SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASSWORD and FROM_EMAIL on the api service and set SMTP_MOCK=false. Without them the API logs emails instead of sending them, which is fine for a single-owner instance.

Point a site at it with the tracking snippet from Settings → your project, which is already filled in with this deployment's own domain.