Hey there! We've found the following might help you get unblocked faster:

• 🧵 Application failed to respond

• 🧵 container closed error

• 📚 No Start Command Could be Found

If you find the answer from one of these, please let us know by solving the thread!

Your container is shutting down because it's listening on port 8080 instead of Railway's dynamically assigned $PORT. Change your Gunicorn command from --bind 0.0.0.0:8080 to --bind 0.0.0.0:$PORT and add ALLOWED_HOSTS = ['.railway.app', 'localhost', '127.0.0.1'] to your Django settings.py. Railway requires apps to bind to the PORT environment variable it provides, not a hardcoded port. Once you make this change and redeploy, your container will stay running properly.

sorry but it didn't worked, I tried to change default ports etc, but the error is still persistent

sorry but it didn't worked,

1. I have already made the binding with $PORT in Procfile,
My Procfile:
web: python manage.py migrate && python manage.py collectstatic --noinput && gunicorn yt_notes.wsgi --bind 0.0.0.0:$PORT --timeout 120 --keep-alive 2

2. I also tried to update the default ports too, but idk what's the issue, the same error come, and closes the container

this is the log which im getting

Railway requires apps to bind to the PORT environment variable it provides, not a hardcoded port

This is not completely aligned with the documentation https://docs.railway.com/guides/public-networking, as nothing prevents you from defining your own $PORT variable and make the app listen to it. Railway supplies the $PORT variable only in case you don't have one

Also, the port the application listens to should not affect the application lifecycle as long as the port is bindable. Unless you have the Serverless option enabled on the server that scales down the service when no activity is detected for long time, there should be nothing that could SIGTERM the container seconds later it was booted

Accordingly to your logs your container process receives a SIGTERM, thus something from the outside wants it to become stopped. Could you check if you could get some insights on your Deployments tab? Could it be that you're starting another deployment immediately after the first once was completed and thus as the doc states https://docs.railway.com/reference/deployments#singleton-deploys your old containers gets a SIGTERM?

Also, by any chance, do you have any HEALTHCHECK instructions on your Dockerfile?

ya I did, but everything seems fine

can you check if this is alright?
if I made any errors with the deployment itself

The build log and the settings look normal to me. You probably don't really need the pre-build command as Nixpack/Railpack should detect your Django app automatically and install reqs anyway, but it's not the cause of the issue. The healthcheck also looks normal

Could you check the Deployments tab please? I am mainly interested whether you'll see there lots of frequent redeployments or just a few

here you are:

Exact same issue here, have no idea how to fix it yet