Automatic updates
Keep stacks, services, and infrastructure current without losing rollout control
Use automatic update policies for Git-backed services and stacks, stack service revisions, copied stack origins, app instance upgrades, and Kubernetes infrastructure.
Automatic updates in Wodby are not one global switch. Each update path has its own policy, scope, and rollout behavior, so teams can remove routine maintenance work while keeping production changes visible and controlled.
Use separate policies for separate update paths
Automatic updates are safer when each resource type has its own controls.
Wodby separates update behavior for Git-backed services, Git-backed stacks, stack service revisions, copied stack origins, app instance stack upgrades, and Kubernetes infrastructure. That means a team can automate low-risk maintenance while keeping sensitive rollout steps manual.
Source updates
Git-backed services and stacks can follow branches or newer allowed semantic-version tags.
Stack revisions
Service revision updates and origin sync create new stack revisions instead of silently changing running apps.
Infrastructure upgrades
Cluster infrastructure and infrastructure app stacks use their own automatic upgrade switches and version policies.
Follow Git-backed services and stacks automatically
Git-backed resources can stay aligned with their source repository without a manual import step every time.
Services and stacks imported from Git can update automatically when a supported Git provider sends a matching push event. Branch-based sources follow the tracked branch, while tag-based sources can follow newer semantic-version tags with patch, minor, and major update types controlled separately.
- Create a new service revision when an allowed Git-backed service update arrives.
- Import an updated
stack.ymlinto a new stack revision when an allowed Git-backed stack update arrives. - Keep commit-pinned services and stacks fixed until the team moves them manually.
- Configure Git auto-update separately from services auto update on Git-backed stacks.
Create new stack revisions from service updates and origin sync
Stack automation keeps the blueprint current without immediately changing every running environment.
Services auto update can move eligible stack services to newer service revisions in a new stack revision. The policy controls whether Wodby updates stateless services only or all services, and whether the update follows semantic-version, non-semver, or revision-based matching.
Copied catalog stacks can also use auto-sync with origin. The default sync behavior is conservative: Wodby adds missing origin objects while preserving local customizations unless pruning options are explicitly enabled.
- Use stateless-only defaults when automatic stateful-service changes need more review.
- Allow patch and minor semantic-version updates while keeping major updates disabled by default.
- Pin stack services that should stay on their current service revision.
- Sync copied catalog stacks with their origin while preserving local overrides by default.
Choose which app instances should move forward automatically
A new stack revision does not have to roll into every running app instance at once.
App instance auto-upgrade is configured per instance. Development can move quickly, staging can follow after a controlled policy, and production can stay behind manual review when that is the better operational choice.
Auto-upgrade uses the same settings as the manual stack upgrade form. The saved policy decides which app-instance overrides Wodby replaces with values from the latest stack revision, including versions, replicas, resources, integrations, settings, links, tokens, configs, cron schedules, volumes, and the main app service.
- Enable auto-upgrade only for instances where moving to the latest stack revision without manual review is acceptable.
- Keep manual stack updates, manual origin syncs, and manually published drafts from forcing app instances forward.
- Review warnings when a new stack revision adds app services that still need instance-specific configuration.
Upgrade Kubernetes infrastructure with cluster-level controls
Platform infrastructure has its own update path because it affects the cluster underneath the apps.
Kubernetes clusters track Wodby infrastructure version updates and infrastructure app stack updates separately. Infrastructure version upgrades affect cluster-level wiring, while infrastructure app updates cover platform services such as Envoy Gateway, monitoring, proxy components, and provider-specific controller apps.
Each infrastructure upgrade type has its own auto-upgrade switch and semantic-version policy. Patch and minor upgrades are allowed by default, while major automatic upgrades are not enabled by default. Wodby Cloud clusters keep automatic infrastructure upgrades enabled because Wodby operates that infrastructure.
Infrastructure version
Upgrade cluster-level Wodby infrastructure before infrastructure apps when both update types are pending.
Infrastructure apps
Move platform service stacks forward through their own upgrade policy and task history.
Keep automatic work visible through tasks and notifications
Automation should reduce maintenance, not hide operational changes.
Automatic updates run as Wodby tasks, the same way manual updates do. Task history and logs show what ran, whether warnings were recorded, and whether follow-up work is needed before deployment can continue.
- Review update and upgrade task history when an automatic workflow runs.
- Use notification settings to receive emails when automatic infrastructure upgrades succeed or fail.
- Keep production review boundaries by enabling automation only where the saved policy matches the risk.
For a release-oriented view of app changes, pair automatic updates with CI/CD deployment controls.
Adopt automatic updates environment by environment
The safest rollout usually starts with the environments that can tolerate more movement.
- Review stack automation first: Git auto-update, services auto update, and origin auto-sync.
- Enable app instance auto-upgrade where moving to the latest stack revision is acceptable.
- Review cluster infrastructure auto-upgrade policy separately from app stack policy.
- Keep production manual until the stack, service, and infrastructure update behavior is well understood.
Next step
Automate the maintenance paths that are safe for your team
Keep low-risk environments moving quickly, leave production behind review when needed, and use task history and notifications to see what changed.