Laravel Artisan is not reading the .env file on DigitalOcean LAMP droplet with DB Cluster
I have a laravel app that is deployed on the LAMP digital ocean droplet that is tied to a database cluster (From digital ocean).
Whenever I try to run php artisan migrate, it doesn't consider the .env file at all. Instead, it connects to the defaultdb on the same database cluster. I don't understand how or why it does that. From where does the application get the correct host domain, username, password and "defaultdb" as a db name for the database?
Update: when trying to interact with the application itself (from the browser or postman), it reads the .env values correctly and shows that the correct_database_name.table does not exist which is what i'm expecting to see.
@sr57 I think my problem is somewhere on the server itself. Somehow, the db connections are getting overridden by default connection params from somewhere in the server.
After investigating a bit, I found a file in the root directory which contained connection details to the db cluster. I tried renaming and moving that file hoping it would break whatever is using it, but nothing changed.
I'll keep looking around. Will keep this thread updated.
@sr57 To clarify a bit, I can access the cluster normally from within my droplet. Just not the DB that I want. the connection is defaulted to a specific db, namely defaultdb and it seems that overriding the .env file has no effect on the artisan tool.
my guess is that somewhere, somehow, the php-cli has a default db connection ? i don't even know if that makes sense but I think this is what is happening.
And after more than a few hours of debugging and frustration; I fixed it.
The issue was that the LAMP droplet + db cluster had a local environment variable DATABASE_URL which was somehow overriding Laravel's Artisan migrate command.
After running unset DATABASE_URL everything worked as expected.
In case anyone comes across this, I used env | grep DATABASE to see what environment variables were already set in the server. and I tried to unset them one by one. Eventually, the unset DATABASE_URL worked.