fly launch command sets you up with a useful starting point, but you can customize just about everything to meet your needs. Here’s a few things that might be useful to know.
fly launch command generated a
.fly/scripts directory. Any file in here ending in
.sh will run (via
bash) anytime your application is started.
These scripts are called from the Docker
ENTRYPOINT script (
.fly/entrypoint.sh) before anything else is ran.
fly launch generates a startup script
.fly/scripts/caches.sh, which runs various artisan cache commands such as
You can enable or disable those as you see fit, as well as add your own
You may want to use the
release_command to perform database migrations or other tasks. The release command is run in a temporary VM that is created just before your application is deployed and released. Keep in mind that this temporary VM doesn’t have access to volumes. This potentially helps with zero-downtime deploys.
Note, however, that any Startup Script in
.fly/scripts will also be run when a
release_command is used.
If you need a startup script to do something (or NOT do something) during a release command, your scripts can detect the presence of the
RELEASE_COMMAND environment variable.
if [ -z "$RELEASE_COMMAND" ]; then # We are NOT in a temporary VM, run as normal... else # We are in the temporary VM created # for release commands... fi
Note that release commands run in a temporary VM. Any file-based changes done in the release command (such as
artisan view:cache) will be lost when the release command is completed. The subsequently deployed application is a totally different VM. Commands that result in file-based changes (such as
artisan view:cache) is best run as a Startup Script.