We brought Skew Protection to your Kubernetes

We're excited to share a new experimental feature for Platformatic: Skew Protection in the Intelligent Command Center (ICC). This brings Vercel-style deployment safety to Kubernetes, letting you deploy without downtime and avoid version-mismatch problems.

You can think of this as akin to Vercel’s Skew Protection functionality, but running right in your existing Kubernetes setup: no migration or changes to your CI/CD pipeline or security policies needed, just out-of-the-box version pinning for your frontend applications.

The Problem: Version Skew in Kubernetes

When you update a web application, users who loaded the old frontend might send requests to the new backend. This is called “version skew,” and it can cause problems if APIs, assets, or data schemas have changed. For example, if you rename a form field, old clients might still send data using the old field name.

This problem matters even more for modern frontend apps, where the same codebase runs on both the client and server. Frameworks like Next.js, Remix, and monorepos often share TypeScript types, API definitions, or business logic between frontend and backend. If these shared parts change between versions, it can cause serious issues:

• Hydration Errors and Broken UI: React Server Components tightly couples client and server in a single deployment; when a new version goes live, the server produces updated RSC payloads that older client bundles still in users' browsers cannot reconcile, causing hydration errors and broken UI

• API contract violations: OpenAPI or protobuf definitions change between versions, leading to serialization/deserialization failures

• Type discrepancies: Shared TypeScript interfaces or zod schemas break when frontend and backend versions diverge, causing runtime errors.

• Codependent features: Frontend components that rely on backend-specific functionality fail when that functionality changes or is removed

The implications for your users are fairly straightforward: some might see API errors, missing fields, or broken features if their client and server versions don’t match; others might see data loss or corruption when schemas change across app versions. All this ultimately puts a load on support teams, who often need to coordinate across multiple feature teams to effectively untangle and ultimately resolve these issues.

Outside of the obvious impact on users (and revenue), k8s version skew is another example of how distributed systems, if not operated with the proper guardrails, actually impede developer velocity. In a world that is increasingly reliant on using AI to write code, the bottleneck is no longer the ability to write lines of code (if it ever was), but what happens between when your code is written and when it actually gets to production.

Version Skew in Kubernetes is a perfect example of such a problem - you have teams that are capable of shipping much faster, but without the right guardrails, the entire system actually moves slower and fails more often: fear of committing breaking changes leads to larger, less-frequent deployments that carry more risk and slow down your time-to-market.

The Solution: ICC Skew Protection

Platformatic’s new skew protection feature, built into the Intelligent Command Center, makes sure users stay on the version they started their session with, even when new versions are deployed. If a user starts a session on version N, all their requests during that session go to version N.

How It Works

Skew protection uses the Kubernetes Gateway API for version-aware routing, with ICC acting as the control plane. Each application version runs as a separate, immutable Kubernetes Deployment that users create themselves using standard Kubernetes workflows.

When applications run, ICC automatically detects new versions via label-based discovery and manages routing rules. ICC creates and maintains HTTPRoute resources that route requests based on session cookies, using a  __plt_dpl  cookie to pinusers to their deployment version.

When a new version is deployed, the previous version transitions to “draining” mode: existing sessions continue to work, while new sessions go to the active version. ICC monitors traffic activity and automatically cleans up old versions after configured grace periods.

Key Platformatic Components

Platformatic Watt is the Node.js application server that runs your application as a worker thread inside of Kubernetes . This allows for improved performance, resiliency, and compute efficiency, as well as providing out-of-the-box features such as hot reloading, health checks, and metrics collection.

watt-extra is an extension layer that sits on top of Platformatic Watt and serves as the bridge between your application and ICC. On startup, watt-extra connects to ICC and registers the application with its metadata (pod ID, app name, version). This registration enables ICC to:

• Discover the application’s Kubernetes labels (app.kubernetes.io/name, plt.dev/version)

• Manage autoscaling using real-time, Node.js-specific metrics

• Implement version-aware routing for skew protection

• Monitor health and performance,

System Architecture

The skew protection system consists of four layers. Each application version is a completely separate K8s Deployment, and the Kubernetes Gateway API handles routing at the ingress level based on HTTPRoute rules managed by ICC.

Component Breakdown

Client Layer

• Browser Session A (cookie: __plt_dpl=dep-v42): A user who started their session on version 42. The __plt_dpl cookie pins their requests to that version, making sure the requests are routed to the correct backend even after newer versions are deployed.

• Browser Session B (cookie: __plt_dpl=dep-v43): A user who started their session on version 43. Their requests are routed to the active version based on their cookie.

• New Visitor (no deployment cookie): A first-time user or someone without a version cookie. Their first request is routed to the current active version, and they receive a cookie that pins them to that version.

Gateway API Layer

• GatewayClass: Defines a template or class of gateways (e.g., Envoy Gateway, Contour, or Cilium) that can process Gateway API resources. Each cluster operator configures this with their preferred controller.

• Gateway Resource: The actual gateway instance that listens on HTTP/HTTPS ports and processes incoming traffic. It contains listener configurations for TLS termination and routing.

• HTTPRoute: Managed by ICC, this is the key routing rule that implements version-aware routing. It contains multiple rules: cookie-based matches for draining versions and a default rule that sets a cookie for new visitors and routes to the active version.

ICC (Intelligent Command Center) - Namespace: platformatic

• Control Plane Service: The core component responsible for version detection, HTTPRoute management, and lifecycle decisions. When watt-extra registers a new pod, the control plane discovers the application name and version. It holds the version registry and creates/updates/deletes HTTPRoute resources as needed.

• PostgreSQL: Stores the persistent state for skew protection, including the version registry with full metadata about each deployment (version string, timestamps, K8s resources), deployment history for audit trails, and per-application skew protection policies.

App Versions - Namespace: myapp

• Deployment: myapp-v42 (draining): A Kubernetes Deployment for the previous version (42) that is being phased out. It has its own Service and pods running Watt with watt-extra. Traffic only routes here for users whose cookies match this version.

• Deployment: myapp-v43 (active): The current active version deployment. It has multiple replicas for high availability. New visitors and users without matching cookies are routed here. ICC’s autoscaler works across all deployed versions, provisioning the correct amount of resources for each version based on actual traffic.

• Service: Each version has its own Kubernetes Service that selects pods with the corresponding plt.dev/version label. These Services are referenced by the HTTPRoute’s backendRefs.

• Pods (Watt + watt-extra): Each pod runs the application container (Platformatic Watt runtime) plus watt-extra. watt-extra is the ICC agent that connects to ICC on startup and registers the pod. It sends the pod ID, and ICC discovers the version and deployment metadata through Kubernetes APIs. watt-extra also reports metrics to ICC for autoscaling and health monitoring.

Observability Layer

Prometheus: Collects metrics from all pods and services. ICC queries Prometheus to monitor traffic patterns for each version, track request rates for draining versions, and uses that data to determine when versions should be transitioned to Expired status (meaning services that received no traffic for the pre-configured grace period).

How It All Works Together

When a new application version is deployed:

1. You deploy a new version of your app with the same app.kubernetes.io/name label and a new plt.dev/version label.

2. watt-extra registers the new pods with ICC, which detects the new version from the labels.

3. ICC makes the new version Active and moves the previous one to Draining. It updates the Gateway routing rules so that new sessions go to the active version, while existing sessions with a version cookie keep going to the draining version.

4. ICC monitors traffic on draining versions. Once there is no traffic, or the grace period elapses, ICC expires the old version — removing its routing rules and scaling it to zero, and optionally deleting the old Deployment and Service.

The Deployment Lifecycle in Detail

When managing multiple versions, skew protection uses a well-defined state machine to guarantee flawless transitions:

• Active → The current version serving new sessions. Exactly one version per application is Active at a time. The HTTPRoute’s default rule points to the Active version’s Service, and new visitors receive a cookie pinning them to this version.

• Draining → When a newer version is detected and becomes Active, the previous version transitions to Draining. No new sessions are assigned to it, but existing sessions with version-pinning cookies continue to be served. ICC monitors traffic activity for draining versions to determine when they can be safely retired.

• Expired → A version transitions to Expired when it has zero traffic over the traffic window (default: 30 minutes) or when the grace period elapses (default: 24 hours), whichever comes first. ICC then removes the version’s matching rules from the HTTPRoute, scales the Deployment to zero replicas via the autoscaler, and optionally deletes the Deployment and Service (if auto-cleanup is enabled).

The ICC uses Version Labels to determine state. Version labels are opaque strings andcan be numbers, semver, git SHAs, or any identifier that fits your workflow. ICC does not parse or compare them; it just treats the most recently detected version as Active.

How users deploy a new version:

1. Build a new container image with the updated application code (e.g., myapp:v43)

2. Create a new K8s Deployment and Service with:

   • Same app.kubernetes.io/name label (e.g., myapp) — this tells ICC it’s the same application

   • New plt.dev/version label (e.g., 43) — this tells ICC it’s a new version

   • New Deployment name (e.g., myapp-v43) and matching Service name

3. Apply the manifest: kubectl apply -f myapp-v43.yaml

4. ICC automatically detects the new version when pods start and watt-extra registers with ICC. The new version becomes Active, and the previous version begins draining.

Getting Started with ICC

Platformatic’s skew protection is built into the Intelligent Command Center (ICC), a complete control plane for managing Node.js applications or agents running in Kubernetes,with autoscaling, monitoring, and version-aware routing.

To get started with ICC:

• Install ICC on your Kubernetes cluster. Follow our Installation Guide for step-by-step instructions, covering infrastructure requirements (Kubernetes, PostgreSQL, Valkey, Prometheus) and installation options.

• Deploy your first application using the standard ICC workflow:

  • Add @platformatic/watt-extra to your app

  • Set PLT_ICC_URL so your app can register with ICC

  • Deploy with kubectl apply or your existing CI/CD pipeline

• Enable Skew Protection:

  • Enable PLT_FEATURE_SKEW_PROTECTION

  • Ensure Gateway API CRDs are installed (Kubernetes 1.27+)

  • Deploy a Gateway API-compatible controller (Envoy Gateway, Contour, Cilium, Traefik, NGINX Gateway Fabric or Kong). See the Compatible Gateways in ICC documentation

  • Configure deployment labels:

labels:
  app.kubernetes.io/name: myapp
   plt.dev/version: "43"
   # Optional: custom path prefix (default: /myapp)
   # plt.dev/path: "/api/leads"
   # Optional: hostname for HTTPRoute
   # plt.dev/hostname: "myapp.example.com"

Bring Vercel-Grade Deployment Safety to Your Kubernetes Environment

Platformatic’s skew protection is now available in ICC. It provides zero-downtime deployments and version-aware routing that keep each user session consistent.

If your team wants to try it in a real enterprise setup, send a message to Luca Maraschi or Matteo Collina via DMs on LinkedIn, or contact info@platformatic.dev.