2 years ago
I have just generated a domain that points to port 4000 of my railway deployment.
Problem is, it's stll pointing to the port of my custom domain (9600)
Any idea why?
60 Replies
2 years ago
can you show me the public networking section of your service please
2 years ago
what port did you choose when you setup the custom domain?
Tried creating another domain with another running port (4001). It's still showing a blank screen https://curator-production-658d.up.railway.app/
2 years ago
where does this 9600 port come in play?
I'm running two services in the same instance here. The start command runs the 9600 port and the other application runs after the first has initialized
2 years ago
your custom domain works?
Oddly enough, if I create a new domain and point it to 9600, it works just fine
2 years ago
but the railway provided domain does not?
The railway provided domain (sj-curator-production.up.railway.app) works just fine. If I create a new domain pointing to 9600 it also works https://curator-production-1d4f.up.railway.app/
2 years ago
im lost, then what is the issue?
One on port 9600 (default). That is connected to my custom domain and the railway provided domain which works just fine
But when I do, it only shows a blank screen like so https://curator-production-2781.up.railway.app/
And when I provision a new domain for port 9600, it works fine too. https://curator-production-1d4f.up.railway.app/
2 years ago
how do you know the blank screen is not your app?
I've noticed this also happens when I choose a port that isn't running.
2 years ago
the white screen is a 0 byte response
2 years ago
how do you know your app is running on the port 4000?
2 years ago
you are running a dev server, you can't really expect things to work properly when you run a dev server
2 years ago
from this, i assume you are trying to run a frontend and a backend in the same service?
So the use-case is a little weird.
I'm trying to run an automated integration test suite and preview the results in vitest (so I can post it to slack).
2 years ago
okay well thats better than just running a dev server to handle the sites traffic
2 years ago
where are these tests being ran from? within the container?
2 years ago
so why does it need to be exposed publicly if the tests are being ran inside the container?
The goal was being able to debug quickly. We're running a few snapshot tests (the json structure we're testing can often change), so being able to see the snapshots in vitest's ui is very helpful
2 years ago
gotcha
Ideally it would just be a static html page, and I could serve that from the main server, but there's no way to do this in vitest afaik
2 years ago
hey as long as you arent serving the actual site with a dev server thats good with me
2 years ago
very common mistake
2 years ago
try having the dev server listen on the 0.0.0.0 host
2 years ago
no problem!


