Introducing Wodby auto updates

This is not one global switch. The update path depends on what is being updated, and each path keeps its own policy. A Git-backed service can follow a branch or semver tags. A copied catalog stack can keep its services current and sync with its origin. A Kubernetes cluster can receive Wodby infrastructure upgrades separately from infrastructure app stack upgrades. An app instance can opt in to stack auto-upgrade after an automatic stack update creates a new revision.

The goal is to remove routine maintenance work without removing rollout control. Teams can keep development environments moving quickly, keep production behind a manual review step, or turn on broader automation when the stack and operational process are ready for it.

What can update automatically

Git-backed services and stacks

Services and stacks imported from Git can now update when a supported Git provider sends a matching push event. Branch-based sources follow the tracked branch. Tag-based sources can follow newer semantic-version tags, with patch, minor, and major update types controlled separately.

For services, auto-update creates a new service revision from the service template in Git. Stacks that use the service still decide when to move to that new service revision. For stacks, auto-update imports the updated stack.yml and creates a new stack revision directly from Git.

Commit-pinned Git sources are intentionally excluded from automatic updates. They stay pinned until you manually move them to another valid branch, tag, or commit.

Services auto update and origin auto-sync

Not every stack should follow a Git repository. Dashboard-managed and copied catalog stacks can still stay current through Services auto update. When a service gets a new revision, Wodby can create a new stack revision that moves eligible stack services forward while preserving the stack definition.

The service auto-update policy has two parts: scope and version matching. Scope can be Stateless only or All services. Version matching can be semantic version, non-semver, or revision based. Wodby catalog stacks default to stateless-only semantic-version patch and minor updates, with major updates off.

Copied catalog stacks can also use Auto sync with origin. This watches the origin stack revision and syncs catalog-side changes such as newly introduced services, stack service defaults, and removed services. Sync is conservative by default: it adds missing origin objects and preserves local extras unless you enable pruning options.

App instance auto-upgrade

A new stack revision does not automatically move every running app instance. App instance auto-upgrade is configured per instance, so production, staging, and development can use different rollout behavior even when they share the same app stack.

Auto-upgrade can run after supported automatic stack updates: Git-backed stack auto-updates, automatic stack service revision updates, and automatic sync with origin. It uses the same settings as the manual Upgrade stack form, including whether to update versions, replicas, resources, integrations, enabled services, settings, links, tokens, configs, cron schedules, volumes, and the main app service.

If the new stack revision adds an app service that still needs instance-specific configuration, Wodby records warnings and waits for you to finish that configuration before deploying. Manual stack updates, manual origin syncs, and manually published drafts still leave app instance rollout under manual control.

Kubernetes infrastructure auto-upgrade

Clusters now track two infrastructure update states: the cluster-level Wodby infrastructure version and the stack revisions used by cluster infrastructure apps. Infrastructure apps are the Wodby-managed apps that install platform services such as Envoy Gateway, monitoring, FRPC proxy components, and provider-specific controller apps.

Automatic infrastructure upgrades have separate controls for Infrastructure and Infrastructure apps. Each uses a semver-only policy with patch and minor upgrades allowed by default and major upgrades disabled. If both the cluster infrastructure version and infrastructure app stacks need updates, Wodby upgrades the infrastructure version first, then checks infrastructure apps again.

Wodby Cloud clusters keep infrastructure auto-upgrade enabled because Wodby operates that infrastructure. For managed Kubernetes in your own cloud account and for K3S clusters, the dashboard lets you review and change the policy from the cluster Infrastructure operations screen.

How to adopt it

Read the docs

For the evergreen product overview, see the automatic updates feature page. For implementation details, start with the stack updates documentation, the service updates documentation, the application stack documentation, and the Kubernetes cluster updates documentation.