Pipeline Templates

Pipeline templates are pre-built collections of deployment hooks tied to a specific platform. Instead of building hooks from scratch, you start from a template that already understands how apps on that platform are typically built, deployed, and released. Devpilot ships with built-in templates, and you can create your own.

Why use pipeline templates

When you configure multiple applications on the same platform — for example, several Laravel APIs or multiple React apps — you end up repeating the same hook configuration. Pipeline templates solve this by letting you:

• Start from a known-good pipeline. Built-in templates cover the common hooks for each supported platform.
• Eliminate repetitive setup. Apply a template to a new application in a few clicks rather than adding each hook by hand.
• Keep deployments consistent. Applications that share a template follow the same lifecycle, reducing misconfiguration.
• Capture institutional knowledge. When your team develops a reliable pipeline for a platform, save it as a template so new projects inherit it automatically.

Supported platforms

Each pipeline template is tied to a platform. Devpilot currently supports these platforms for templates:

• Laravel
• Vanilla PHP
• Vanilla Javascript
• Nuxt Js
• React Js
• Vue Js

When you apply a template, Devpilot checks that the application is on the same platform as the template.

Built-in templates

Devpilot provides built-in templates for common platforms. For example, the Laravel Basic Setup template installs its hooks in the standard lifecycle stages:

• Post Setup — Install Composer Dependencies: composer install --no-interaction --no-dev
• Post Setup — Sync Storage Directory: sync directory with path storage
• Post Setup — Run migration: php artisan migrate --force
• Post Setup — Artisan optimize: php artisan optimize

Built-in templates are marked Public and owned by the system, so every workspace can use them.

Template fields

Every pipeline template records:

• Name — A short label, such as "Basic Setup" or "Laravel Production".
• Description — What the template does and any platform prerequisites.
• Platform — Which platform the template targets (Laravel, React Js, and so on).
• Category — Always deployment today.
• Visibility — Public templates are shared system-wide. Custom templates you create are scoped to your workspace.
• Status — Active templates are available for new applications; Inactive templates are hidden from the picker.

Applying a template to an application

Creating your own template

You can create workspace-scoped templates for platforms you use frequently.

Managing templates

Editing a template

Open the template, adjust its details or hooks, and save. Existing applications that previously applied the template are not affected — they keep the hooks they had at the time of application.

Deactivating a template

Switch a template to Inactive to hide it from the picker without deleting it. This is useful when retiring a template you no longer want new applications to use.

Deleting a template

Remove a template from your workspace when it is no longer needed. Deleting a template does not affect applications that previously applied it.

Best practices

• Name for the platform and workflow. Include the platform and any distinguishing details: "Laravel + Horizon", "React Js with Nginx reload".
• Document prerequisites in the description. Spell out assumed runtime versions, installed system services, and environment variables users must set before applying.
• Keep commands generic. Avoid hardcoding application names, domains, or secrets. Rely on application-level environment variables for these values.
• Split by environment. If staging and production differ meaningfully, create separate templates rather than trying to make one template serve both.

Next steps