expose-zymtrace-backend

Configure Kubernetes ingress or service exposure for a zymtrace backend with TLS.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

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

What problem does it solve?

This Skill helps you expose an already-installed zymtrace backend to users and agents by configuring Kubernetes network exposure (NodePort, LoadBalancer, or Ingress) with correct TLS and controller-specific settings, so the gateway becomes reachable and functional.

Core Features & Use Cases

  • Helm-based exposure changes: Edits the customer’s canonical Helm values file in place and applies it via helm upgrade --install.
  • Multiple exposure modes with safe defaults: Supports NodePort, NGINX Ingress + cert-manager TLS, and AWS ALB + ACM TLS (with hostname and scheme handling).
  • Controller-correct protocol configuration: Ensures gRPC behavior works by using backend-protocol: "GRPC" for NGINX and the required ALB HTTP/HTTP2 pairing to avoid the HTTP 464 failure mode.
  • Verification and rollout confidence: Runs a verification script to confirm ingress/service address, TLS reachability, and gateway health/gRPC behavior.

Quick Start

Tell the Skill: which exposure mode you want (NodePort, NGINX Ingress, or AWS ALB), the target namespace and release name, the gateway hostname, and the TLS source (ACM ARN for ALB or cert-manager issuer/secret for NGINX).

Frequently Asked Questions about expose-zymtrace-backend

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

FAQPage Schema
How do I expose a Kubernetes service with TLS using NGINX ingress and cert-manager?

To expose a Kubernetes service with TLS using NGINX ingress, you configure the canonical Helm values with a cert-manager issuer or secret and apply the changes via helm upgrade. This ensures the gateway becomes externally reachable with correct gRPC protocol behavior and TLS verification.

Why does gRPC fail with an HTTP 464 error on AWS ALB ingress?

gRPC fails with an HTTP 464 error on AWS ALB ingress when protocol pairing is incorrect. You must configure the required ALB HTTP and HTTP2 pairing to avoid the HTTP 464 failure mode and ensure proper gRPC compatibility for the backend gateway.

Can I use a NodePort service for proof of concept without an ingress controller?

You can use a NodePort service for proof of concept without an ingress controller to expose the backend gateway. This mode provides basic external reachability for non-AWS clusters or testing scenarios before configuring full TLS and ingress routing.

How do I configure AWS ALB ingress with an ACM certificate for my backend?

To configure AWS ALB ingress with an ACM certificate, you update the Helm values file with the ACM ARN, target hostname, and scheme for internal or internet-facing routing. A helm upgrade applies the configuration with rollback guardrails to ensure safe deployment.

Does this Helm upgrade process include rollback guardrails and verification?

The Helm upgrade process includes rollback guardrails and runs a verification script to confirm ingress address resolution, TLS reachability, and gateway health. This ensures controller-specific gRPC compatibility requirements are met before completing the rollout.

What is required to ensure gRPC compatibility with NGINX ingress controller?

To ensure gRPC compatibility with the NGINX ingress controller, you must set the backend-protocol annotation to GRPC in your Helm values. This controller-correct protocol configuration prevents routing failures and verifies gateway gRPC behavior during deployment.