#### Fixes
- Render templated per-node macros (`shard`, `replica`) in ClickHouse
`config.yaml` so multi-shard/multi-replica clusters get unique Keeper
paths instead of collisions
- Use the first TelemetryStore TCP address (not comma-joined) for
`SIGNOZ_TELEMETRYSTORE_CLICKHOUSE_DSN` and ingester ClickHouse DSNs
#### Refactors
- `telemetrystore` molding now emits `config-{shard}-{replica}.yaml` per
node (mirrors `telemetrykeeper` per-replica pattern)
Related: https://github.com/SigNoz/platform-pod/issues/1332
Railway Template
| Field | Value |
|---|---|
| Mode | - |
| Flavor | template |
| Platform | railway |
Overview
Generates per-component Dockerfiles, railway.json service definitions, and config files for deploying SigNoz on Railway. Deployment is manual via the Railway dashboard.
Note
foundryctl castdoes not deploy to Railway automatically. It generates the files and prints instructions for manual deployment.
Prerequisites
- A Railway account
Configuration
apiVersion: v1alpha1
metadata:
name: signoz
spec:
deployment:
flavor: template
platform: railway
Deploy
# Generate the template files
foundryctl forge -f casting.yaml
After forging, use the generated files in pours/deployment/ to create services on Railway.
Generated output
pours/deployment/
telemetrykeeper/
Dockerfile
railway.json
keeper.d/
telemetrystore/
Dockerfile
railway.json
config.d/
metastore/
Dockerfile
railway.json
signoz/
Dockerfile
railway.json
ingester/
Dockerfile
railway.json
migrator/
Dockerfile
railway.json
Customization
For changes to the generated files, use patches.