Deployment Hooks

Deployment hooks are the commands and file-sync actions that Devpilot executes during each stage of the deployment lifecycle. They define what happens when your code is deployed — from installing dependencies to restarting services. Every application in Devpilot has its own set of hooks that you configure to match your build and release process.

How hooks work

When you trigger a deployment, Devpilot moves through the deployment lifecycle in order: Pre Execution, Pre Source Control, Post Source Control, Post Setup, Post Release. At each stage, Devpilot runs the Active hooks assigned to that stage in priority order. If a hook fails (returns a non-zero exit code), the deployment stops and is marked as Failed. Hooks that never ran in that deployment are marked Skipped.

Each hook has:

• A name — A short label that shows up in the deployment log.
• A stage — When the hook runs in the lifecycle.
• An action type — What the hook does (run a shell command, sync a file, or sync a directory).
• Metadata — Stage-specific configuration, such as the command to run or the path to sync.
• A priority — The position of the hook within its stage. Hooks run in ascending priority order.
• A status — Either Active (runs during deployment) or Inactive (stored but skipped).

Hook stages explained

Devpilot's deployment lifecycle has five stages:

Hook action types

Devpilot supports three action types for hooks:

Shell Command

Runs a shell command on the server. This is the most common action type. The command executes in a bash shell in the context of the current release directory. You enter the command in the hook's Command field.

Examples seen across live templates:

composer install --no-interaction --no-dev

php artisan migrate --force

php artisan optimize

npm install

npm run build

php artisan horizon:terminate

php artisan cache:clear

Sync File

Copies a single file from a shared location to the release directory. Use this to place configuration files, environment files, or other static files into each new release so they do not need to be committed to the repository.

Configure a sync file hook by specifying the source and destination paths in the hook's Source and Destination fields.

Sync Directory

Copies or links an entire directory from a shared location. Use this for directories that should persist across releases, such as storage, vendor, public, or an uploads folder. This avoids re-downloading large dependency trees on every deployment and preserves user-generated files.

Configure a sync directory hook by specifying the directory path in the hook's Path field.

Creating hooks with the visual editor

Example configurations

These examples mirror the hook patterns used by Devpilot's built-in Laravel template and by real production applications deployed through the platform.

Laravel application

• Post Source Control
  • Shell Command — "Install Composer Dependencies": composer install --no-interaction --no-dev
• Post Setup
  • Sync Directory — "Sync Storage Directory" with path storage
  • Shell Command — "Run migration": php artisan migrate --force
  • Shell Command — "Artisan optimize": php artisan optimize
  • Shell Command — "Storage link": php artisan storage:link
• Post Release
  • Shell Command — "Restart Horizon": php artisan horizon:terminate

Node.js / JavaScript application

• Post Source Control
  • Shell Command — "Install NPM dependencies": npm install
• Post Setup
  • Shell Command — "Build": npm run build
• Post Release
  • Shell Command — "Restart app": pm2 restart ecosystem.config.js

Adding persistent directories

For any application, configure a Sync Directory hook in Post Setup for directories that should survive across releases — uploads, generated files, caches, or a shared vendor folder. This is how Devpilot templates handle paths like storage, public, and vendor on Laravel apps.

Best practices

• Keep hooks focused. Each hook should do one thing. Instead of chaining multiple commands with && in a single hook, create separate hooks so each runs with its own status, duration, and exit code in the deployment log.
• Use meaningful names. Hook names appear in every deployment log. Clear names like "Install Composer Dependencies" or "Run migration" make logs easier to scan.
• Keep definitions but pause them when needed. Switch a hook from Active to Inactive to skip it temporarily without deleting the configuration.
• Start from a template. If you have a hook configuration that works, save it as a pipeline template to reuse across applications.
• Test commands on the server first. Before promoting a command to a hook, run it manually on the server via the Web Terminal to verify it works in the deployment environment.