upgrade-zymtrace-backend

Upgrade deployed zymtrace Helm backends with preflight checks and atomic verification.

5|1|Updated May 17, 2026
One-click install
npx skills add https://github.com/zystem-io/zymtrace-skills --skill upgrade-zymtrace-backend
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: upgrade-zymtrace-backend
Source: https://github.com/zystem-io/zymtrace-skills/tree/main/zymtrace/skills/upgrade-zymtrace-backend
Command: npx skills add https://github.com/zystem-io/zymtrace-skills --skill upgrade-zymtrace-backend

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

Upgrading an already-deployed zymtrace backend without breaking workloads or forgetting critical operational steps like Helm migration jobs and rollback behavior.

Core Features & Use Cases

  • Guided upgrade paths: Handles image-only bumps, chart-version bumps, or combined upgrades for Helm-deployed backends.
  • Guardrails before and after upgrade: Runs an explicit preflight script, refreshes the Helm repo, confirms the exact upgrade command and resolved values, and verifies deployment health and migrations.
  • Rollback-aware operations: Uses --atomic plus a documented manual rollback path to recover safely if the upgrade fails.

Quick Start

Ask the skill to upgrade your existing zymtrace Helm backend by running: "upgrade zymtrace to 26.5.0 on my cluster" and confirm the resolved namespace/release, chart version, and image tag when prompted.

Frequently Asked Questions about upgrade-zymtrace-backend

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I safely upgrade zymtrace on Kubernetes without breaking workloads?

A safe zymtrace Helm upgrade requires preflight checks, a mandatory Helm repo refresh, explicit user confirmation of resolved values, and the --reset-then-reuse-values flag combined with --atomic to ensure automatic rollback on failure.

What is the difference between an image-only bump and a chart version upgrade for zymtrace?

An image-only bump updates the container tag, while a chart version upgrade updates the Helm chart configuration. A combined upgrade applies both, but all three scenarios require running migration jobs and post-upgrade verification to maintain backend stability.

Can I use this Helm upgrade process for an air-gapped Kubernetes cluster?

Yes, the zymtrace Helm upgrade supports air-gapped Kubernetes environments. You must ensure the required container images and chart versions are mirrored to your local registry before executing the preflight checks and upgrade commands.

How does Helm rollback work if a zymtrace backend migration fails?

Helm rollback for a failed zymtrace upgrade relies on the --atomic flag to automatically revert the release. If migrations fail, a documented manual rollback path is provided to recover the backend to its previous stable state.

Do I need to run preflight checks before upgrading the zymtrace Helm chart?

Yes, preflight checks are mandatory before upgrading the zymtrace Helm chart. They validate the existing deployment state, refresh the Helm repository, and ensure the target chart and image versions are compatible before any changes are applied.

What are the limitations when upgrading zymtrace on Kubernetes?

The zymtrace upgrade only applies to existing Kubernetes deployments already managed by the zymtrace Helm chart. It does not support fresh installations and requires explicit user confirmation of resolved values before proceeding with the upgrade.