Your application will deploy after it completes building from the configuration files commited to the code repository. The deploy process connects each container from the build process (including any services like databases), makes the containers live and replace any previous versions, with minimal interruption in service. During the deploy phase, you can access other services (such as MySQL, Solr, Redis), mounts are writable and the disk where the application lives is read-only.
Deploy Hook
The deploy hook is run after the app container has been started but before it has started accepting requests. Note that the deploy hook only runs on web instances, not worker instances.
This hook should be used when something needs to run once for all instances of an app when new code is deployed. It isn’t run when a host is restarted (such as during region maintenance), so anything that needs to run each time an app starts (regardless of whether there’s new code) should go in the start key in your web configuration. For example, clearing the cache for ephemeral Redis.
Be aware: The deploy hook blocks the site accepting new requests. If your deploy hook is only a few seconds, incoming requests in that time are paused and continue when the hook is finished. So it effectively appears as if the site just took a few extra seconds to respond. If the hook takes too long, requests can’t be held and appear as dropped connections. Only run tasks in your deploy hook that have to be run exclusively, such as database schema updates or some types of cache clear (those where the code must match what’s on the disk). A task that can safely run concurrently with new incoming requests should be run as a post_deploy hook instead.
The execution of the deploy hook is logged in the deploy log. For example:
[2022-03-01 08:27:25.495579] Launching command 'bash export-config.sh'.
🔥 Successfully cleared configuration
🚀 Added new configuration detailsYour deploy hook is tied to commits in the same way as your builds. Once a commit has been pushed and a new build image has been created, the result of both the build and deploy hooks are reused until there is a new git commit. Redeploys with no changes trigger only the post_deploy hook. If you need the deploy hook to run, manually trigger a build.
Post-deploy hook
The post_deploy hook functions exactly the same as the deploy hook, but after the container is accepting connections. It runs concurrently with normal incoming traffic. That makes it well suited to any updates that don’t require exclusive database access.
What’s “safe” to run in a post_deploy hook vs. in a deploy hook varies by the application. Often times content imports, some types of cache warmups, and other such tasks are good candidates for a post_deploy hook.
In addition to the activity log, the post_deploy hook logs to the post-deploy log.
The post_deploy hook is the only hook that runs during a redeploy.
Further References
- Build and Deploy phase: overview of the steps involved in both the build and deploy phases
- Using build and deploy hooks: sample usage of build and deploy hooks for an example application
- Comparison of hooks: see what resources are available for each hook and how it affects the application