Make sure that your database is actually ready before the pre-deploy command runs. Laravel bootstraps, attempts the connection to the database, fails fast, exits non-zero and then prints nothing depending on your configuration.

This can happen intermittently, which explains why it's not really happened to you before. This could've suddenly started because the database had a cold start, the staging database may have been auto-scaled, or the timing of your deployment has changed.

One thing you were correct in though is that Metal builds don't affect this.

In some Laravel and PHP versions, running migrate --force when you have zero migrations can still exit if a migration table lock check fails or the permissions it has are read-only, or if there's a mismatch with the schema state.

One thing you could try is, this is usually a quick fix:

php artisan migrate --force || true

But, if that doesn't work and you want to be a bit safer, you could also try the following which will wait a couple of seconds before running your migrate command, just to make sure that the database is ready to go:

until php artisan migrate:status; do
  echo "Waiting for database"
  sleep 3
done

php artisan migrate --force

You can also force output using php artisan migrate --force -vvv.

Hope this helps!

php artisan migrate --force

Try that, if not...

/bin/sh -c "set -e; php artisan migrate --force; exit_code=$?; echo 'Migration exit code:' $exit_code; exit $exit_code"

php artisan migrate --force --verbose

The most likely underlying cause is a race condition or misconfiguration where the necessary environment variables (specifically your database credentials, DB_HOST, DB_DATABASE, etc.) are not available or not correct when the pre-deploy command runs.

In a typical Railway setup, if your database is a Service Dependency that hasn't fully settled, or if your application container hasn't received its full set of environment variables yet, the php artisan migrate command will connect to the wrong host or fail to authenticate.

Check the Staging Environment Variables: Go to your staging environment's Variables tab and ensure the DB_* variables are explicitly set for that environment and point to the correct staging database.

Thanks for the help everyone.

The strange thing is that I've had this service running for 5 months and this problem never happened before. There haven't been any changes to the project that would allow this to start happening.

As a solution, I removed the command "php artisan migrate --force" from the pre-deploy command and included this command directly in my startup script.

Solved!