CI/CD from source change to post-deployment checks and rollback

• Build service images from the connected source revision.
• Release images to Wodby Registry or a compatible external registry.
• Deploy all services or only the services included in the change.
• Run stack-aware post-deployment scripts.
• Use workload health checks and deployment state to identify failure.
• Return selected services to eligible previous builds when recovery is needed.

Wodby integrates with supported Git providers so teams can connect repositories, create applications, and start using build and deployment automation without stitching together separate identity and repository handoffs.

Wodby CI provides ready-to-use build pipelines that understand the platform model. Many public boilerplates include a .wodby/pipeline.yml definition, which shortens setup time and keeps the release workflow aligned with how the application is actually deployed.

Pipelines run the same app-aware flow used by external CI: initialize the build, build service images, release them to the configured registry, and deploy the released images. Teams can also define .wodby/post-deployment.yml scripts that run after deployments complete.

Teams can also start from public examples in the wodby/wodby-ci repository and adapt them to their own delivery process.

• Start from stack-aware boilerplates instead of assembling pipelines from scratch.
• Trigger builds from Git activity and keep release automation closer to the app workflow.
• Run post-deployment scripts after the application deployment finishes.

Teams can keep their existing GitHub Actions, GitLab CI, CircleCI, or other CI workflows and deploy into Wodby using Wodby CLI. The CLI reads stack information and runs the same init, build, release, and deploy flow, which makes it easier to adopt the platform incrementally without breaking established automation or retraining every team all at once.

• Use WODBY_API_KEY and WODBY_APP_SERVICE_ID to authenticate third-party CI jobs.
• Let the CLI detect Git and build metadata automatically in GitHub Actions, GitLab CI, and CircleCI.
• Prefer VM-style runners when Docker image builds need simpler access to Docker.
• Keep provider-specific setup in CI while Wodby handles release and deployment state.

See what was deployed, which services were included, whether post-deployment scripts ran, and how the deployment finished. A deployment can target selected services, force a release, or skip post-deployment scripts when the situation calls for a narrower change.

When an app service upgrade fails workload health checks, automatic rollback makes a best-effort attempt to restore that service to its latest previous successful release. The failed deployment remains visible, and services that already deployed successfully are not reverted.

Manual rollback can select eligible previous builds per service. It restores application images; it does not downgrade the stack or restore databases, configuration, secrets, volumes, or other persistent data.

• Deploy all services or only the services that need to change.
• Review warnings before using builds created for an older stack revision.
• See whether rollback was skipped, completed, failed, or unavailable.
• Keep image rollback distinct from stack, database, and persistent-data recovery.

Wodby Registry is the default registry path for teams that want an integrated image store, while external registries remain available when existing compliance, security, or tooling requirements make that the better choice.