selfhosted-gateway-seamless-upgrade

Upgrade a live backend behind a Pingora gateway using blue/green slots and SIGHUP reloads.

2|Updated Jun 18, 2026
One-click install
npx skills add https://github.com/zero-yx/static_flow --skill selfhosted-gateway-seamless-upgrade-zero-yx
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: selfhosted-gateway-seamless-upgrade
Source: https://github.com/zero-yx/static_flow/tree/main/skills/selfhosted-gateway-seamless-upgrade
Command: npx skills add https://github.com/zero-yx/static_flow --skill selfhosted-gateway-seamless-upgrade-zero-yx

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Upgrading a self-hosted backend behind a running Pingora gateway risks downtime if the gateway is restarted or traffic is switched prematurely. This Skill provides a strict blue/green rollout procedure that keeps the gateway on port 39180 alive while a new backend binary is built, verified, and cut over via config edit plus SIGHUP. ## Core Features & Use Cases - Blue/Green Slot Rollout: Runs the candidate backend on the inactive slot (39080 or 39081) while the active slot keeps serving traffic. - In-Process Gateway Reload: Applies the active_upstream config change with kill -HUP <gateway-pid> only, never restarting the gateway process. - Stable-Path Verification and Rollback: Requires repeated health checks through 39180 and the public domain before declaring success, with config-restore rollback if checks fail. - Use Case: You deploy a new StaticFlow backend build in a tmux-supervised production setup. The Skill walks you through preflight topology checks, capped-parallelism build, candidate startup, cutover, verification, and safe cleanup of the old slot. ## Quick Start Use this skill to roll out the newly built StaticFlow backend to the inactive slot and switch gateway traffic without restarting the gateway.

Frequently Asked Questions about selfhosted-gateway-seamless-upgrade

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

FAQPage Schema
How do I upgrade a backend behind a reverse proxy without downtime?▼

Use blue/green deployment: start the new backend on the inactive slot, verify its health directly, then update the gateway's active_upstream config and send SIGHUP to reload in place. Verify traffic through the stable gateway port before stopping the old slot.

How to reload Pingora gateway config without restarting the process?▼

Edit the gateway YAML config to point active_upstream at the candidate slot, then send kill -HUP to the gateway pid identified from the port 39180 listener. The running gateway reloads the config in process without dropping connections.

Can I restart the gateway during a blue/green backend rollout?▼

No. Restarting, killing, or recreating the gateway process is forbidden during rollout because it interrupts the stable entry point on port 39180. The only permitted gateway signal is SIGHUP for config reload.

Why is a healthy candidate slot not enough to switch traffic?▼

Direct checks on the candidate port only prove that slot works in isolation. Cutover is proven only through the gateway port 39180 and the public domain, requiring at least three consecutive stable-path health checks reporting the candidate port.

How do I roll back a failed blue/green backend deployment?▼

Restore the backed-up gateway config so active_upstream names the old slot, confirm the change, then send SIGHUP to the same running gateway process. Verify the gateway health endpoint reports the old slot port; never restart the gateway to roll back.