0.1.49 introduced multi-instance apps. A Mechanics app no longer had to mean
exactly one live deployment. It could have independently reconciled overlays
such as main, prod, staging, or pr-42.
The manifest layout changed
New apps are scaffolded as a Kustomize base plus one overlay per instance:
apps/<app>/base/ and
apps/<app>/overlays/<instance>/. Each overlay carries its own
name suffix and app.kubernetes.io/instance labels, so Services,
Deployments, Pods, and routes can be distinguished inside the same tenant
namespace.
Each overlay is reconciled as its own Argo CD Application. That means one app can have multiple independently synced and rolled-out instances, each pointing at its own image tag or manifest patches.
Instances became first-class commands
app instance add copies an existing overlay to a new instance while
preserving user patches and the source image tag. app instance remove
deletes one overlay and its associated routes after preflighting the write
policy for every file it would touch.
App commands gained -i/--instance where it matters: app info,
app wait, app set-image, and app sync. If an app has multiple
instances and the user does not specify one, Mechanics refuses with a
disambiguation error instead of guessing.
Routes follow the instance
Routes target one app instance. That makes preview and promotion patterns much clearer: a pull-request instance can have its own route, while production keeps serving from another overlay. Deleting an instance cleans up the routes for that instance without deleting the entire app family.
Multi-instance apps make previews and promotions fit the same GitOps model as the main deployment.