a month ago
Hello Railway Support Team,
We are running Chargify, an OCPP-based EV charging station management platform, on Railway. Our backend maintains persistent WebSocket connections with physical EV chargers.
Our current production configuration is:
Railway plan: Hobby
Service: ws-engine
Protocol: OCPP 1.6J over plain WebSocket
Internal application port: 8081
Railway TCP Proxy hostname: maglev.proxy.rlwy.net
Railway-assigned public port: 57134
Custom hostname: ocpp.chargify.co.in
Current charger URL:
ws://ocpp.chargify.co.in:57134/ocpp/{chargerId}
The TCP Proxy and plain WebSocket connection are working correctly. Our WSS endpoint is also working correctly and does not require any changes.
The problem is specifically the Railway-assigned external TCP port 57134.
Several physical EV charger models we need to support have firmware that accepts port numbers only in the range 0–9999. Their configuration interface cannot store or connect to a five-digit port such as 57134.
We therefore need a stable public TCP Proxy port below 10000, preferably:
8080
If 8080 is unavailable, any stable port between 1024 and 9999 would work.
Our required connection would be:
ws://ocpp.chargify.co.in:8080/ocpp/{chargerId}
The internal application can continue listening on port 8081. We only need the Railway public TCP Proxy mapping to become:
Public TCP port 8080 → internal service port 8081
Our requirements are:
Keep the existing ws-engine Railway service.
Keep the hostname ocpp.chargify.co.in.
Keep the /ocpp/{chargerId} path.
Keep the protocol as plain ws:// for legacy chargers.
Assign or reserve a public TCP port below 10000.
Ensure the assigned port remains stable across deployments and restarts.
Avoid requiring an external proxy, VPS, Cloudflare port bridge, or another hosting provider.
Do not disrupt the existing production connection until a coordinated migration is ready.
We understand that the Railway dashboard currently allows us to select the internal application port but automatically generates the external TCP Proxy port.
Could you please clarify the following?
Can Railway Support manually assign or reserve a four-digit external TCP Proxy port for our existing service?
Is there an undocumented or newer Railway configuration/API option that allows selecting the external TCP Proxy port?
Is this capability available on the Pro or Enterprise plan?
If it requires a plan upgrade, which specific plan supports it, and is the selected port contractually guaranteed to remain stable?
Can the existing TCP Proxy remain active while a second fixed-port proxy is provisioned for testing?
If manual port assignment is unavailable, can Railway provide another Railway-native solution for accepting plain WebSocket connections on external port 8080 without redirecting them to HTTPS?
Would deleting and recreating the TCP Proxy ever allocate a port below 10000, or are Railway TCP Proxy ports intentionally allocated only from a five-digit range? We do not want to recreate the current proxy without confirmation because it is already used in production.
This is not a cosmetic URL preference. It is a physical charger firmware limitation. These chargers cannot be modified remotely to accept five-digit ports, and some deployed units would otherwise be incompatible with our platform.
Please do not modify or remove the existing TCP Proxy without coordinating with us first. We need to preserve:
maglev.proxy.rlwy.net:57134
until a replacement endpoint has been tested successfully.
We can privately provide the following information when requested:
Railway Project ID:
Railway Environment ID:
Railway Service ID:
Current Deployment ID:
Region:
Approximate number of persistent charger connections:
Expected connection growth:
We would appreciate either:
Manual assignment of a stable public port between 1024–9999, or
Confirmation of the Railway plan/product that supports this, or
A definitive confirmation that selectable external TCP ports are currently unavailable.
Thank you for reviewing this infrastructure requirement.
Regards,
Chargify Engineering
OCPP/EV Charging Platform Team
4 Replies
a month ago
TCP proxy external ports are auto-assigned by the platform and cannot be manually selected, reserved, or constrained to a specific range. This applies to all plans, including Pro and Enterprise, and there is no API option, dashboard setting, or support-side override for it. Deleting and recreating a TCP proxy would assign a new random port with no guarantee it falls below 10000. Your existing proxy at port 57134 would be safe to keep as-is, but we cannot provision a second one on a chosen port. For chargers that require a port below 10000, an external TCP relay (e.g. a lightweight proxy on a VPS forwarding to your Railway TCP proxy endpoint) would be the way to bridge that firmware limitation.
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
The bot is correct; we cannot assign custom ports for the TCP proxy.
But why is a TCP proxy used in the first place? You mentioned this is WebSockets, so why wouldn't you use the HTTP proxy exclusively? That way, the port becomes 443, the public HTTP proxy fully supports WebSockets, and you benefit from using WSS. Are the chargers that old? Traffic over the TCP proxy is not encrypted at any stage on our end.
brody
The bot is correct; we cannot assign custom ports for the TCP proxy. But why is a TCP proxy used in the first place? You mentioned this is WebSockets, so why wouldn't you use the HTTP proxy exclusively? That way, the port becomes 443, the public HTTP proxy fully supports WebSockets, and you benefit from using WSS. Are the chargers that old? Traffic over the TCP proxy is not encrypted at any stage on our end.
a month ago
already supports WSS over Railway's HTTP proxy, and that works correctly for modern chargers.
The reason we also require plain ws:// is that we need to support a number of legacy OCPP 1.6J charge points that do not implement TLS/WSS. Their firmware only supports unencrypted WebSocket connections (ws://) and cannot establish a WSS connection.
In addition, several of these charger models have another firmware limitation: their configuration only accepts port numbers below 10000.
Status changed to Awaiting Railway Response Railway • about 1 month ago
a month ago
Then, unfortunately, we wouldn't be able to offer a solution. We cannot assign custom ports to the TCP proxy or disable SSL on the HTTP proxy.
Status changed to Awaiting User Response Railway • about 1 month ago
a month ago
This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!
Status changed to Solved Railway • 26 days ago