Hexclave (self-hosted)

About Hosting Hexclave

Hexclave is an open-source "user infrastructure" platform: authentication, teams, and analytics for your app. This template runs Hexclave's official all-in-one server image (dashboard + API in one container) on Railway, alongside the Postgres and ClickHouse databases it needs.

Common Use Cases

Running your own auth server for a SaaS product without depending on Hexclave Cloud
Prototyping or testing Hexclave's authentication, teams, and analytics features in an environment you fully control
Self-hosting user infrastructure for compliance or data-residency reasons

Dependencies for Hexclave Hosting

Postgres — stores hexclave's own data (projects, users, teams). Included in this template.
ClickHouse — stores the analytics data hexclave's dashboard reads. Included in this template.
hexclave-cron — a small scheduled job that calls hexclave's internal maintenance endpoints (email queue, external DB sync) every 5 minutes over Railway's private network, since the Docker image doesn't run its own scheduler. Included in this template.
hexclave-proxy — a Caddy reverse proxy that routes traffic by path: the dashboard at / and the API at /api/*. Included in this template. Exposes a single public domain so users don't have to manually generate two separate ports and paste their URLs.

Why Deploy Hexclave on Railway?

Railway generates the Postgres and ClickHouse passwords for you and wires every service together automatically, so you get a working auth/teams/analytics backend without hand-managing three separate pieces of infrastructure. Railway's private networking also keeps the cron job's calls to hexclave's internal endpoints off the public internet. The proxy service handles public routing so the dashboard and API are available immediately on deploy with zero manual domain setup.

Deploy and Host Hexclave on Railway

Click deploy. This template deploys with a single public domain already configured — the dashboard and API are both served through the hexclave-proxy service, one at the root, the other under /api/. No manual domain setup is required. Note that the hexclave service takes a few minutes to boot on first deploy (it seeds the database and prepares the app), and you'll see a "still starting up" message at the URL until it's ready. Visit the dashboard URL generated on the hexclave-proxy service and sign in with the seeded admin account: the email you set in HEXCLAVE_SEED_INTERNAL_PROJECT_USER_EMAIL, and the password in HEXCLAVE_SEED_INTERNAL_PROJECT_USER_PASSWORD (check that service's Variables tab if you left it auto-generated).

Known limitations

After your first deploy, set HEXCLAVE_SKIP_SEED_SCRIPT to true. On its first boot the app seeds the database and creates your admin account. But the image's seed script crashes the container if it runs a second time (an upstream bug), so on the first restart or redeploy the hexclave service will crash-loop with an error about "Environment configuration overrides cannot be changed in a development environment." The fix: open the hexclave service's Variables, set HEXCLAVE_SKIP_SEED_SCRIPT to true, and redeploy. Note this is a different variable from the HEXCLAVE_SEED_INTERNAL_* settings — only HEXCLAVE_SKIP_SEED_SCRIPT stops the crash.
Email and webhooks aren't configured out of the box. Password verification codes need HEXCLAVE_EMAILABLE_API_KEY/SMTP configured for real delivery; webhooks need a Svix key. See hexclave's self-host docs for those variables.
External DB sync runs inline (HEXCLAVE_EXTERNAL_DB_SYNC_DIRECT=true) instead of through Upstash QStash, which this template doesn't set up. Fine for most self-hosted use; configure QStash yourself if you need queued/retryable delivery.