17 days ago
Project IDs:
CRM project: d26827d7-f841-4e60-b525-9c7e81ff185f
N8N project: e0127e06-7d9c-45d5-b615-60ec956d2108
Hi Railway team & community,
I'd appreciate guidance on optimizing my production setup. I'm on the Pro plan running a B2B SaaS for a client in production.
Current setup:
CRM project: contains my CRM service with a custom domain (CNAME → my Railway service URL, with SSL via Railway).
N8N project: contains n8n Primary + Worker, plus the shared Postgres and Redis (both with persistent volumes).
The issue: my CRM connects to Postgres in the N8N project via the public connection URL, generating $10+ in egress per month and growing. I want to eliminate this by having everything talk over internal/private networking.
Critical constraint: the custom domain on my client's side MUST continue working without any changes (CNAME + TXT verification already configured by the client's IT team). I cannot ask them to modify DNS again.
Questions:
Does Railway support private networking between projects in the same workspace on the Pro plan? If so, how do I enable it?
If not, is there a way to transfer a service from one project to another while preserving its public Railway URL, so the client's CNAME keeps working?
What's the safest path to consolidate this setup with minimal downtime?
Thanks in advance!
1 Replies
16 days ago
Treat the CRM service and its custom domain as the immovable part of the system. That is the public production edge your client already points to.
Private networking only helps when the caller and callee are in the same project and environment. With CRM in one project and Postgres/Redis/n8n in another, the CRM service has to use the public database URL, which explains the egress. The clean fix is to bring the internal dependencies to the CRM project/environment, not to move the public CRM service away from the working domain.
Suggested path:
- Leave the CRM service and custom domain in place.
- Create or move Postgres and Redis into the CRM project's production environment.
- If n8n needs the same database/Redis, recreate the n8n primary and worker in that same project/environment as well.
- Rehearse the database migration on a copied environment first. For production, use a maintenance window, take a final backup, restore/import into the new database, then cut over.
- Change CRM, n8n, and worker variables to private same-environment connection values. For HTTP service calls, use
http://<service>.railway.internal:<port>, not the public URL. - Make sure every service receiving private traffic listens on all interfaces. Use
::when the runtime supports it. - Redeploy and verify from inside the Railway environment that the app is connecting to the private hostname. A temporary health/debug endpoint or one-off command is enough.
- Remove the old public database URL from CRM after the private path is confirmed, so the app cannot silently fall back to the egress path.
On the specific questions:
- Cross-project private networking: no. Plan around one project and one environment for private traffic.
- Preserving the custom domain while moving the CRM service: do not count on that as a self-service move. If you recreate or move the public CRM service, expect domain reattachment or re-verification risk. Only Railway support can tell you whether they can preserve the existing service/domain binding without a DNS change.
- Safest route: keep the public edge stable, move the private dependencies behind it, cut over variables during a maintenance window, then monitor DB connectivity, application logs, and egress.