power-push

Update a production Kubernetes cluster to the latest published image tag.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/neon-law-foundation/navigator --skill power-push
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: power-push
Source: https://github.com/neon-law-foundation/navigator/tree/main/.claude/skills/power-push
Command: npx skills add https://github.com/neon-law-foundation/navigator --skill power-push

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill safely updates a live production stack to the newest already-published application image without rebuilding locally, while preventing version skew between the web app and the workflows worker.

Core Features & Use Cases

  • Pinned Cluster Rollouts: Resolves the latest release tag, verifies both published images exist, and updates both deployments together so they stay in lockstep.
  • Production Safety Checks: Confirms the live secret contains every boot-required key before rollout, reducing crash loops caused by missing configuration.
  • Operational Recovery: Supports no-rebuild secret-rotation refreshes with a restart workflow and re-registers the worker so new handlers stay reachable.
  • Use Case: A lawyer-facing production site needs today’s released image live in Google Kubernetes Engine, with the worker refreshed in Restate and the cluster kept consistent across web and background execution.

Quick Start

Use the power-push skill to update the production cluster to the newest published release, verify secret readiness, roll both deployments together, and re-register the worker.

Frequently Asked Questions about power-push

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

FAQPage Schema
How do I roll out the latest published image to a GKE production cluster without rebuilding code?

Pinning both Kubernetes deployments to the same image tag prevents version skew between the web app and workflows worker, ensuring both services run identical application code and avoiding communication failures caused by mismatched API contracts.

Can I refresh Kubernetes pods after a secret rotation without triggering a new image build?

Before a rollout, this process confirms the live Kubernetes secret contains every boot-required key, reducing crash loops caused by missing configuration values by checking secret invariants against application requirements prior to deployment.

What is the best way to keep a Restate worker registration in sync during a Kubernetes deployment rollout?

The best way to keep a Restate worker in sync is to re-register the worker immediately after pinning both deployments to the new image tag, ensuring new handlers stay reachable and the background execution service matches the updated web app version.

Does this deployment approach work for dual-service release rollouts on Google Kubernetes Engine?

Yes, this deployment approach works for dual-service release rollouts on Google Kubernetes Engine by resolving the latest release tag, pinning both the web app and workflows service to the same image, and confirming the worker registration stays synchronized.