Browse documentation
DURPDEPLOY DOCUMENTATION

Templates, runbooks, and schedules

Reuse proven steps and make routine operations easier to repeat.

On this page

Start with a working manual deployment. Then use these features to reduce repeated setup. Maintainers and administrators can author this content, subject to project permissions.

Reuse a step template

Templates save step configuration for later use. Use Save Template on an existing step to capture a reusable version. Review the script, interpreter, container image, and required variables before applying a template elsewhere.

The curated library includes Bash, PowerShell, Python, and Terraform starters. Follow the template library guide to browse and apply them. Supply your own environment values and credentials.

Reuse a project template

A project template can copy a larger project configuration into a new project. Supply fresh secret values and map the source environments to destination environments during application. Templates do not copy secret-variable values or package credentials.

Existing projects created from a template remain independent. Changing the source project does not automatically change those projects.

Use a runbook

Runbooks hold operational scripts, such as a maintenance task or a diagnostic check. Open the project’s runbooks and create the required steps. Save a runbook version before running it against an environment. Review its selected version, variables, and execution target before each run.

Runbook execution requires Maintainer permission or higher. Deployment-only accounts cannot execute runbooks. Approval gates require a global administrator.

Schedule a deployment

Open the project’s schedules and choose a release, environment, and cron schedule. Schedules use the server’s local time zone. Use five-field cron syntax, such as 0 3 * * * for 3:00 a.m. daily. Do not add a TZ= prefix. Review the next execution time before enabling the schedule. Keep the schedule disabled until a manual deployment succeeds. Enable it only when the scripts can safely run unattended.

Schedules use saved releases. Project edits need a new release or release refresh before scheduled deployments can use them. Disable schedules before maintenance or isolated recovery tests.

Keep recovery in mind

Repeated execution can repeat real changes on a target system. Check retry behavior, credentials, approval requirements, and notifications before enabling automation. Keep a tested recovery procedure for each production task.