The pattern you're describing—app starting successfully but stopping after about 6 minutes—usually points to a health check timeout rather than a build cache issue. When Railway assigns a public domain, it runs health checks to verify your app is responding to HTTP requests on the expected port. If those checks fail within the timeout window, the deployment gets stopped.

Start by checking your deployment logs for the specific reason the container stopped—look for error messages or exit codes that might give us a clue. Then verify that your app is actually binding to $PORT and not hardcoding a port elsewhere that could override your Procfile settings.

If you want to take more direct control, try setting a custom start command instead of relying on the Procfile. Head to your service's Settings tab, find the Deploy section, and set a Custom Start Command like gunicorn app:app --bind 0.0.0.0:$PORT --timeout 120 --workers 2 --log-level debug. This gives you more visibility into what's happening during startup.

Also double-check that app:app correctly references your Flask application object—if your file is named differently or your Flask instance has a different name, that would definitely cause issues. The difference between PythonAnywhere and Railway often comes down to how the PORT environment variable is handled, since PythonAnywhere manages this differently on their end.

If you can share the exact logs showing why the container stopped (not just the startup logs), whether you have a public domain configured, and the contents of your main Flask file showing how the app is initialized, that would help narrow things down.