Share $PORT across services for private networking
I have two services, CMS and Web. CMS listens on
:: at port $PORT. Web listens on 0.0.0.0 at port $PORT. CMS needs to be publicly accessible through the Internet (so that Admin and Content Editors can edit content) (hence why it listens at port $PORT), but also privately available through Private Networking (so that Web can make API calls to retrieve content) (hence why it listens at ::). Web needs to know ${{CMS.PORT}} so that it can call http://cms.railway.internal:$${CMS.PORT}/. It seems like this kind of service cross-referencing the $PORT variable doesn't work. Due to a limitation in CMS, I can only listen at one (interface, port) combination, so listening both at (0.0.0.0, ${PORT}) and (::, 1234) wouldn't work (if it did, Iwouldn't need to know the Railway-assigned port, right?). How can I make this work?24 Replies
Project ID:
38204806-70b2-434c-972d-215f6a2beec038204806-70b2-434c-972d-215f6a2beec0
just simply set a PORT service variable
wait, I thought I needed to use Railway's generated PORT variable if I want to access it publicly?
yeah but then when you set your own PORT in the service variables that now becomes both what your app uses and what Railway uses, provided your app already does listen on PORT
ohhhh
that's pretty neat
indeed
Somewhat unrelated to $PORT, but Web is a Next.js project running Node 18 and this is happening:
so it seems like the resolver Node 18 is using doesn't know about private networking
are you saying this worked on node 16?
no, but I had a somewhat similar issue locally where getaddrinfo failed for
localhost on Node 18 and not on Node 16 so I thought Node version might be relevant.gotcha
that is the correct hostname for the cms as per it's internal domain listed in its service settings?
yup
what what stage of the next apps lifecycle does it make this request?
at build time.
the private network is not available at build time
the build gets ran on a separate build machine that isn't part of your project
oh. that's unfortunate
I guess I'll have to use public networking then
yeah it is, I wonder if the team has any interest in including the builder for a service in its private network
switching from private networking at build time to public networking at deploy time is asking for trouble with Next.js data cache
yeah sounds tricky
it's unfortunate because my public network is behind CloudFlare Access so I have to deal with more auth steps
I think including the builder in the private network makes perfect sense especially since many web frameworks do pre-rendering at build time nowadays
100% agree with you
and you definitely should speak up about that in #🤗｜feedback
awesome feedback!!