Post deploy commands

# Get ready

You have followed the deployment section and are ready to deploy code via git using the GitHub integration.

# Architecture

Post deploy commands are similar to build commands, but they run after the build files have been copied into the live environment. Both build commands and post deploy commands are run in a separate deployment container.

# Use cases

• Database migrations: Apply schema changes after code deployment
• Cache clearing: Refresh application caches to reflect new code
• Configuration updates: Apply environment-specific settings
• Search index rebuilding: Update search indexes with new content structure

# Relation to deployments

Post deploy commands are done as part of the deployment object. This means that a deployment might show as failed, but new files were already deployed, if the failure happened in the post deploy commands.

# Setting up post deploy commands

Post deploy commands are configured in the fortrabbit dashboard for each environment. You can access these settings through the deployment configuration:

# Preset via software templates

Many software presets, such as those for Laravel, Symfony and Craft CMS, already include pre-configured post deploy commands.

# Examples

# Laravel
php artisan migrate --force
php artisan config:cache
php artisan route:cache

# Craft CMS
php craft project-config/apply
php craft clear-caches/all

# Symfony
php bin/console doctrine:migrations:migrate --no-interaction
php bin/console cache:clear --env=prod
bash

# Limits

Post deploy commands are run in a separate deploy resource, which is separate from frontend web delivery resources. The deploy resources are still limited by your booked PHP plan.

# Timing and execution

Post deploy commands run after the deployment has been marked as successful. This means:

• If a post deploy command fails, deployment is shown as failed, but new files have already been copied
• Commands execute in sequence, not parallel
• Each command must complete before the next one starts
• Total execution time should be kept reasonable to avoid timeouts

# Best practices

• Cache management: Consider the impact before clearing all caches every time, especially in production. Cache clearing not only consumes resources, but cache rebuilding can also significantly slow performance.
• Error handling: Design your commands to be idempotent (safe to run multiple times) and handle errors gracefully.
• Monitoring: Log important post deploy actions so you can troubleshoot issues later.
• Performance: Keep commands lightweight and avoid long-running processes that might timeout.