Prebuilt Mqtt Service and Ports
Looking for some guidance. Currently have a couple different services in my project, including a postgres db, mqtt broker, a publisher and a subscriber. The mqtt broker service uses an officially hosted docker image. That service internally opens port 1883 for http mqtt communication, 8080 for ws mqtt communication, as well as other ports for misc things like 8888 has routes /health for health check and /status for a management dashboard. Right now only 8080 is exposed via Railways PORT env var and works perfectly for my web socket connections on other services.
Since I can only expose one port via railway does that mean it’s impossible to take advantage of those other pieces? I’m open to any sort of strategy, but don’t know if I could handle modifying the source of the broker itself so would prefer a different option than that
Thanks!
17 Replies
Project ID:
40a3bc08-0c66-4f5e-a268-736ec53f0cac40a3bc08-0c66-4f5e-a268-736ec53f0cac
youd need to run a proxy service to map routes to ports on the mqtt service.
this proxy service would be exposed publicly, and proxy incoming requests to the mqtt service via the private network, example:
mqtt-proxy.up.railway.app -> mqtt.railway.internal:1883
mqtt-proxy.up.railway.app/ws -> mqtt.railway.internal:8080
mqtt-proxy.up.railway.app/misc-> mqtt.railway.internal:8888
Ohh I see, so the internal ports are still available to other services on the network?
yep, its a private/local network after all
So I have an express api also running in my project. If I add a route say /mqtt/health. I can make an internal request to the appropriate port and just forward that response?
yes, but you really should use a proper proxy service like caddy
or nginx if thats more your thing, but i think caddy is far more approachable
Gotcha thanks for helping me out so quickly. Feel kinda dumb needing to ask that question… lol
no worries at all
proxy is pretty easy to see since it’s a private local network
I think I’ll checkout caddy, though nginx is something I do have experience with using before
caddy is just simpler imo, ive done this with both nginx and caddy, and caddy was the clear winner purely on ease of use and ease of configuration, example
https://github.com/brody192/reverse-proxy/blob/main/Caddyfile
Gonna check it out right after I finish eating lunch and try deploying it - really appreciate the guidance!
no problem! if you need help with caddy let me know
I've got to make a choice. I have an custom domain,
my-project.app and right now have railway connected on two difference services to two different subdomains, specifically, mqtt.my-project.app and api.my-project.app. mqtt is going to have a reverse proxy to cover things like / - http, /ws - ws, /health - health check, /admin dashboard, and the api contains the other business logic (mainly uses trpc mounted at /trpc), but will also expose public graphql endpoints for a different piece.
Do you think I'd be doing too much by having a caddy proxy in front of both so that there can continue to be a separation of concerns. Or would it be better to remove the mqtt sub domain entirely and just use one proxy to route all the relevant mqtt requests using a /mqtt/... prefix?I don't see why you'd want to put a proxy Infront of your api.
remove any and all public domains from the mqtt service and move them over to the proxy service
I like that option, it really doesn't need to be in front of the api. So I'll have caddy at
mqtt.my-project.app to handle proxying the request to different ports on the mqtt service and I'll keep my standalone api service unaffected.
Thanks again for the directionexactly!
id love to hear about the outcome of this!