13 days ago
Hi, I am currently designing a clustering system to support a scalable Twitch chatbot for an custom overlay platform for which I'd like to use the Replicas feature to easily add more shards and have a way to easily connect or contact a single shard from my server with an auto-discovery system.
My main issue is that I understand that internal DNS names are linked to a service and load balances requests between replicas and I wasn't able to find any documentation on direct access within private network to a replica.
For extra context, all my services are NodeJS based and will be deployed inside Docker containers, most likely Alpine-based.
I am thinking about storing the replica's address (IP or internal DNS name) in Valkey with some service handling heartbeat and other clustering health check/LB systems.
- What would be the best way to handle a usecase like mine?
- Is there a Railway-provided environment variable containing a FQDN or a private IP address I could send to a cluster manager service to handle autodiscovery?
- Are Railway replicas designed for this kind of cluster system?
If anyone has experience with this kind of setup on Railway infra, I'd love to hear your feedback and/or any tips you gathered with it!
4 Replies
13 days ago
The internal DNS name (service.railway.internal) resolves to the IPs of all replicas of that service with no per-query record limit, so a DNS lookup from your cluster manager will return every replica's address for client-side discovery. Each replica receives a unique RAILWAY_REPLICA_ID environment variable, but there is no per-replica DNS name or per-replica FQDN/IP variable provided by the platform. Your approach of resolving the service DNS to enumerate replica IPs and registering them in Valkey with heartbeats is a solid pattern given this setup. See the Scaling docs and Private Networking docs for full details.
Status changed to Awaiting User Response Railway • 13 days ago
13 days ago
So if I understand correctly, if I want to get the internal IP for a replica, I'd need to:
- Do a DNS lookup on the internal DNS name
- Store all the IPs returned by the lookup
The main thing missing here would be how to associate an IP with a replica (ID), which may require some metadata inside the heartbeat response just so I can better track each replica's behavior (especially within logs)
Is there something else I could use to make my system more bulletproof?
Could I grab the internal IP of a replica from the Docker container itself? This would make development easier as well as I could use the same system locally without requiring a custom DNS setup.
Status changed to Awaiting Railway Response Railway • 13 days ago
13 days ago
Each replica can read its own internal IP from the container's network interfaces at runtime and has access to its own RAILWAY_REPLICA_ID env var, so a self-registration pattern works well here: each replica registers both its IP and replica ID in Valkey on startup, giving your cluster manager the full IP-to-replica mapping. There is no Railway-provided env var for the replica's private IP, but reading it from the container's interfaces (e.g., os.networkInterfaces() in Node) works on Railway and locally, keeping the same discovery logic in both environments.
Status changed to Awaiting User Response Railway • 13 days ago
Status changed to Solved alex73630 • 13 days ago
13 days ago
Got it, I'll experiment with this and come back with feedbacks on how it went!
Also, comment for the Railway team, it's actually refreshing to have a good and useful AI bot giving the right response, kudos to the team!
Status changed to Awaiting Railway Response Railway • 13 days ago
Status changed to Solved alex73630 • 13 days ago