Background
These automations include:
-
Cache management (commented out due to a Laravel Bug with Rate Limiting)
- Database migrations (
php artisan migrate --force)
- Storage linking (
php artisan storage:link)
Why I think this is a problem
At first, I thought I was helping the user out by automating database migrations. As I looked into scaling containers, having this run on every container update could cause more issues than anything. Sometimes users may want it, but the I don’t think it is a smart engineering .
Possible side-effects
- If I change the default behavior to disable the automatons, I need to communicate this out to users since they will automatically receive image updates and probably wonder why their database migrations are no longer running
What needs to needs to be determined
- Should database migrations (
php artisan migrate --force) default to NOT running automatically?
- Does storage linking (
php artisan storage:link) need to run all of the time (on a new container initialization)?
Moving forward
I am interesting in hearing additional thoughts on this. Maybe @danpastori or @cstriuli could comment from their perspective? Looking forward to getting extra insight on this! 
@jaydrogers Good thing you brought this up. In a multi-dev environment, I’d recommend not running automations automatically, with the exception of storage:link since you will have to do that on a new container. With migrations, it can get hairy because there could be other things needed to be done BEFORE running the migrations.
That’s where I want to build that Laravel Package that manages an update by giving an order of operations. Sometimes you will need to seed a database before running a migration, or after. Sometimes you will need to rebuild a cache, etc.
The Pros of running an automatic migration are you don’t have to remember to do it on deploy. I’d definitely leave it as an option for indie hackers and smaller projects cause SSH-ing in and running the migrate command can be a pain. However, I’d default it to off.
Just personal opinion. I’d love to hear other’s thoughts. Maybe @connor has some insight too?
1 Like
Thanks @danpastori!
Just to be clear
-
storage:link is a core function of Laravel, correct?
My biggest fear is having this run when a library is not installed or Laravel is not configured to handle this behavior.
With this in mind, it is still safe to assume to run this? Should I still allow the option to disable it?
Hi there~
I have multiple projects where the pre-deploy / post-deploy commands are unique, so my answer it’s: No, by default, should be false. Larger projects setup tend to be a bit more complex, so we should not target the production environment to run unexpected commands, right?
I hope this will help 
1 Like
Yes, it’s a core function. You can check how it works here
Under the hood, it runs the function symlink(). Once the link is created and you try to rerun, it will try to delete the previous link to recreate the new one.
1 Like
: