Service operations

Service operations are workflows a service can expose for application maintenance, lifecycle hooks, recurring tasks, data backup, and data import.

For the full manifest schema, see the service template reference.

Actions

Services can define actions that run commands in an app. Actions can be user-runnable from the app-service UI or run automatically during deployment and upgrades. Each run creates a task with execution logs.

Actions run in the selected service workload. If an action does not specify workload, Wodby uses the service's primary workload.

Deployment and upgrade actions run simultaneously unless dependencies are set between them.

Action types

An action type defines how and when the action runs.

button

User-runnable action. Actions of this type are shown on the app service's Actions tab in the Wodby dashboard. Each run creates a task; command output is available in the task logs.

output

User-runnable action. Actions of this type are shown on the app service's Actions tab. Running the action creates a task; output is associated with the task logs and is not returned directly by the run operation.

post_deploy

Runs after every service deployment. If a deployment includes more than one service, the action runs only after all deployments succeed. It can be limited to a specific build boilerplate.

post_deploy_once

Same as post_deploy, but runs only during the first deployment. It can be limited to a specific build boilerplate.

post_upgrade

Runs after an app environment is upgraded to a new stack revision.

empty

No-op action type used when a service needs to define an action placeholder without running a command. Empty actions are not exposed as user-runnable app-service actions.

App service actions

The app-service Actions tab shows only user-runnable service actions from the selected app service:

• button
• output

The dashboard does not derive runnable app-service actions from the raw service manifest. Wodby evaluates the app service state and exposes only actions that can be considered for manual execution.

An app-service action can be disabled even when it appears in the tab. Actions are disabled when the app service or app environment is not in a healthy OK state, and actions are not available for external or derivative app services.

Service actions are defined under the actions section in a service template.

Backups

Services can define data-backup behavior. There are three main backup methods.

Simple files backup

Wodby creates a tar stream from the specified directory. The stream can optionally be gzipped.

The result is uploaded directly to the configured object-storage destination without staging a complete archive in the service's persistent volume.

Staged backup through action

Wodby runs a Kubernetes job with the configured command or args override to create the backup archive. That job is expected to place the archive in the specified volume path, after which Wodby uploads it to the configured object-storage bucket.

Streamed backup through action

For compatible service and image versions, Wodby runs the service's streaming action as a producer and sends its output directly to Wodby Blob Storage or supported third-party object storage. The producer and uploader share only an in-memory stream and status file; they do not create a complete archive on the service's persistent volume.

For third-party storage, Wodby streams to the final object name but keeps the multipart or resumable upload incomplete until the producer reports success. If the producer or upload fails, Wodby terminates the incomplete upload without publishing a completed object. Wodby Blob Storage uses a backup-specific signed upload and removes its object if the producer or upload fails.

Services declare exactly which option versions support this action. They must also retain the staged create and upload.filepath definitions so older service revisions and unsupported versions have a compatible fallback.

Service backups are defined under the backups section in a service template.

Imports

Services can define data-import behavior. There are two main import methods.

Simple files import

Wodby imports files directly into the running volume by unpacking the provided tar archive to the specified path.

This method is not transactional.

Import through init volume

Wodby mounts the import archive into the init volume provided by the service, and a container performs the import during startup. This pattern is commonly used for databases.

This method is transactional. Wodby starts a copy of the app service with a new persistent volume. If the import succeeds, Wodby redeploys the service using the new volume that contains the imported data.

Service imports are defined under the imports section in a service template.

Cron schedules

Services can define cron schedules for recurring tasks. Each schedule includes a name, a command or argument override, and a cron expression. Every run creates a task with execution logs.

Use standard five-field crontab syntax such as 0 * * * *. Cron schedules cannot run more often than once per hour.

Cron schedules are defined under the cron section in a service template.