@microscopic-river-74022 do you need more information to answer the above?

---------------------- No—there’s enough info to answer: using app.garden.io is not required to use Garden; the OSS CLI can run locally and against your own clusters, while the app provides UI, logs, graphs, and optional ephemeral clusters for convenience (you can configure your own Kubernetes instead) ([Discord: Is using app.garden.io required?]()). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

message has been deleted

---------------------- Short answer: make your Deploy action depend only on the manifest inputs, not the Build action, so Garden won’t rebuild images when you change manifests. Practical ways based on the docs: - Use a kubernetes Deploy action that reads manifests via spec.files (or spec.manifests) and do not declare a dependency on the container Build action. Then a change to those files will only re-apply/patch the manifests, with no rebuild triggered ([Referencing manifests]()). - If you also need to set the image built by Garden, keep the Build and Deploy separate, but avoid coupling rebuilds to manifest-only edits. The recommended pattern is to patch the image in the Deploy via spec.patchResources; changing only other manifest fields (replicas, env, etc.) will cause only a redeploy/patch, not a rebuild, as long as the Build action’s inputs (your app code) haven’t changed ([Deploying a container image built by Garden — Option 1: patchResources](), [Overwriting values with patchResources]()). - Ensure your Deploy action’s versioning picks up manifest changes by listing the files under spec.files; Garden will detect those changes and re-apply without rebuilding the image ([Referencing manifests]()).

If you rely on Garden template strings inside manifest files that reference project variables, be aware of a known nuance: edits to variables used only inside manifest files may not always trigger action re-versioning unless those variables also appear in the action config. This is an open discussion in the project ([Issue: versioning plugin‑resolved files]()). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

message has been deleted

---------------------- Yes. You can use spec.kustomize and still redeploy only manifest changes without triggering a rebuild. - The kubernetes Deploy action supports spec.kustomize to resolve a kustomization and include the resulting resources; it can be used alongside (or instead of) manifest files/templates ([spec.kustomize]()). - Keep your Build (container) and Deploy (kubernetes) as separate actions, and reference the built image in Deploy via patchResources (recommended). Then, edits to kustomize inputs (kustomization.yaml, overlays, patches, etc.) will cause Garden to re-apply the rendered resources, while the image won’t rebuild unless the Build action’s inputs changed ([Deploying a container image built by Garden — patchResources]()). In short: using spec.kustomize does not change the behavior—you can safely update kustomize manifests and Garden will redeploy them without rebuilding the image, provided the Build action’s inputs (app code) are unchanged and you wire the image via patchResources. ([spec.kustomize](), [Deploying with patchResources]()). ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

message has been deleted

Let me check the knowledge base for you again. One moment! :books:

message has been deleted