DEV Community: Nino

The End of kubernetes/ingress-nginx: Your March 2026 Migration Playbook

Nino — Tue, 24 Feb 2026 08:32:34 +0000

In March 2026, the community-maintained kubernetes/ingress-nginx controller will reach End-of-Life (EOL). While your existing clusters will not break overnight and the core Kubernetes Ingress API remains fully supported, the controller's repository will become read-only. This means no new features and, critically, no future CVE patches. Engineering teams must plan their migrations now to avoid compounding security risks and compliance violations.

It’s common to leave functioning infrastructure untouched, but running deprecated software in your cluster’s critical path introduces unnecessary risk. With a public and immovable deadline, engineering teams have a clear window to plan a structured migration rather than reacting hastily to a future vulnerability.

What’s Actually Happening with ingress-nginx March 2026 Retirement

Let’s be crystal clear on terminology, because confusion here is costing teams weeks.

The Kubernetes Ingress API resource remains GA, feature-frozen, and fully supported. Nothing changes there. What is retiring is the community-maintained ingress-nginx controller (kubernetes/ingress-nginx).

From the official November 11, 2025 Kubernetes blog post by Tabitha Sable (Security Response Committee):

“Best-effort maintenance will continue until March 2026. Afterward, there will be no further releases, no bugfixes, and no updates to resolve any security vulnerabilities that may be discovered. Existing deployments of Ingress NGINX will continue to function and installation artifacts will remain available.”

The January 29, 2026 joint Steering + SRC statement by Kat Cosgrove made the urgency unmistakable:

“In March 2026, Kubernetes will retire Ingress NGINX, a piece of critical infrastructure for about half of cloud native environments… Half of you will be affected. You have two months left to prepare… We cannot overstate the severity of this situation or the importance of beginning migration… immediately.”

Post-March, the repositories move to the kubernetes-retired organization and become read-only. That’s the end of the road.

Note for managed Kubernetes users: Services like Azure AKS Application Routing or certain GKE ingress configurations have vendor-extended support until November 2026 for critical patches. Always check your cloud provider’s SLA before assuming you’re immediately exposed.

Why ingress-nginx EOL Is a Much Bigger Deal Than Most Teams Realize

Security & Compliance: The CVE-2025–1974 vulnerability in March 2025 (an unauthenticated RCE via exposed admission webhooks) demonstrated the potential blast radius of controller flaws. After March 2026, the absence of patches means any newly discovered vulnerabilities will remain unmitigated.
Audit Blockers: "EOL software in the L7 data path" triggers automatic findings in SOC 2, PCI-DSS, ISO 27001, and HIPAA. Compliance teams are already flagging this, blocking production promotions, and delaying customer deployments.
Talent Attrition: The strongest SREs and platform engineers explicitly ask in interviews: “What’s your long-term ingress strategy?” No one wants to own an abandoned controller in 2027 while peers ship Gateway API features.
Compounding Operational Debt: Every new service adds another Ingress object tied to dead code. Migration effort scales linearly with ingress count, but exponentially with annotation sprawl.

How to Check if You’re Affected

Run these commands today. Any positive result means you’re affected—and you need to start planning your replace project now.

Standard controller & Helm detection:

# Standard controller detection
kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx

# Helm releases
helm list -A --filter ingress-nginx

# Any deployment method
kubectl get deployments,daemonsets --all-namespaces -l app.kubernetes.io/name=ingress-nginx

Checking for the IngressNightmare signature (CVE-2025–1974):
Thousands of clusters still have this lingering signature. Check admission webhook TLS certs for Issuer Organization = “nil1”, Subject Organization = “nil2”, or DNS names containing ingress-nginx-controller-admission or nginx.

One-liner inside the cluster:

kubectl get secret -n ingress-nginx ingress-nginx-admission -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text -noout | grep -E "Issuer:|Subject:|DNS:"

External scanners (Censys, Shodan, etc.) still surface matches with:

tls.certificate.parsed.issuer.organization:"nil1" AND tls.certificate.parsed.subject.organization:"nil2" AND tls.certificate.parsed.names:nginx

Also inspect the webhook config:

kubectl get validatingwebhookconfigurations ingress-nginx-admission -o yaml

If you see any of the above, you now have a documented production risk with a hard deadline.

Migration Options Ranked by Realism for Production Teams (February 2026)

The ecosystem has shifted heavily toward the Gateway API. Here is a breakdown of the most viable targets based on your infrastructure and long-term strategy:

Option	Migration Effort (1-5)	Annotation Compatibility	Gateway API Readiness	Commercial Support	Zero-Downtime Feasibility	Best For
Gateway API (any implementation)	4	None (full translation)	Native v1.2+	Varies	High (dual-run)	Future-proof teams
Traefik (nginx-ingress provider)	1-2	~80% of common nginx.*	Full v1.4	OSS + Enterprise	Very high	Brownfield with heavy annotations
F5 / NGINX Inc Controller	2-3	High (official NGINX)	Growing	Strong (F5)	High	NGINX veterans
Cilium (eBPF Gateway)	3	Low	Native	OSS + Enterprise	High	Existing Cilium users
Envoy Gateway	3-4	Low	Native	OSS	High	Modern Envoy stacks
HAProxy Ingress	3	Medium	Partial	OSS + Enterprise	High	HAProxy preference
Kong	3	Medium	Native	OSS + Enterprise	High	API-gateway heavy workloads

Special callout for brownfield teams: Traefik’s experimental nginx-ingress provider stands out as the brownfield hero. It reuses ~80% of your existing nginx.ingress.kubernetes.io/* annotations out of the box, letting you keep most of your Ingress objects unchanged while immediately getting full Gateway API underneath. In every migration I’ve seen with 50–300 ingresses, this cut the effort almost in half.

As of February 2026, Gateway API v1.2+ is battle-tested. 2026 is actually the perfect time to migrate—the ecosystem has stabilized, the documentation is excellent, and the talent that already knows Gateway API is still rare and highly sought after.

Practical Migration Playbook (Zero-Fluff, Production-Tested)

Inventory (Day 1): Audit your current state.

kubectl get ingress -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.metadata.annotations}{"\n"}{end}'

Convert automatically: Utilize translation tools to kickstart the process.

ingress2gateway print --providers=nginx --input-file=ingresses.yaml

Deploy side-by-side: Deploy the new controller using a different ingressClassName.
Validate rigorously: Reuse your existing test suite, utilize traffic shadowing/mirroring, and use kubeconform + custom Rego policies for annotation translation.
Cutover safely (with a rollback path): Use Blue/green deployments via Gateway HTTPRoute weights. Isolate the blast radius by updating namespace-by-namespace. Define explicit rollback triggers (e.g., 5xx error rate > 1% or latency > 200ms) and pre-document the exact kubectl apply commands needed to instantly revert.
Post-Cutover Observation: Maintain a 72-hour monitoring window to catch delayed edge cases like renewed cert-manager failures or long-lived connection drops.

Estimate timelines (Add a 20–30% buffer for true zero-downtime):

Small (<50 services): 1–2 engineer-weeks
Medium (50–200 services): 3–6 engineer-weeks
Large (200+ ingresses, multi-cluster): 8–16 engineer-weeks

Common Pitfalls & Real War Stories from the Field

Rewrite-target annotation hell: One team with 47 clusters spent 120 engineer-hours writing custom Traefik middleware to handle their old rewrite-target annotations before they could cut over.
Default backend surprises: Three services 404’d on cutover because fallback behavior differs across controllers.
cert-manager webhook cert rotation: The infamous nil1/nil2 certs refused to rotate cleanly on one migration until we pinned the new controller’s policy.
Legacy vs new ingressClassName: Old kubernetes.io/ingress.class annotations are silently ignored by modern controllers.
Dual-controller TLS cert conflicts: Sporadic 503s occurred during cutover until we pinned the new controller’s admission secret rotation policy.
Canary / auth / rate-limit sprawl: Teams that tried "weekend heroics" regretted it heavily.

30-Day Action Checklist to Beat the March 2026 Deadline

Copy-paste this into your runbook—it’s the exact checklist I use with every client:

Run audit commands and screenshot results today.
Build a central inventory of every Ingress + annotation count.
Spin up a PoC with your chosen replacement controller this week.
Run ingress2gateway on a non-prod namespace.
Complete staging dual-controller cutover by Day 15.
Document every custom annotation and its replacement.
Update runbooks, golden images, and CI pipelines.
Brief security & compliance with official Kubernetes quotes.
Schedule a full dry-run cutover weekend.
Reach out for help if blocked.

Final Word

The March 2026 deadline is firm. Teams that allocate time in their roadmaps now will transition smoothly to modern, fully supported networking architectures. Proactive planning ensures your team controls the timeline, rather than being forced into a rushed emergency swap later. By auditing early, utilizing tools like ingress2gateway, and performing an incremental dual-stack cutover, you can modernize your cluster routing safely and systematically.

About the Author: Nino Skopac

GitHub: @NinoSkopac
LinkedIn: Nino Skopac
X (Twitter): @NinoSkopac

Finally, let me leave you with this valuable resource from The Linux Foundation:

One OpenClaw Gateway Multiple Isolated AI Assistants (One Telegram Bot Per Worker)

Nino — Sun, 22 Feb 2026 08:30:06 +0000

tldr;

Give every team member their own private AI employee on a single machine. Full isolation, zero extra servers, Telegram-only setup in minutes.

Abstract

Tired of spinning up separate servers or cloud instances for every AI assistant in your company?

OpenClaw lets you run dozens of completely separate, fully isolated agents on one single machine — and Telegram makes the UX feel magical.

Each worker gets their own dedicated bot (@AliceSalesClawBot, @BobSupportClawBot, etc.). They chat privately with “their” AI, have their own memory, files, tools, and personality — and they never see anyone else’s stuff.

Here’s exactly how I set it up.

Why this works so well

One Gateway process handles everything
Each agent gets its own workspace folder (~/.openclaw/agents/alice-sales/)
Separate SOUL.md, AGENTS.md, history, allowed tools, LLM keys, everything
Telegram routing is dead simple and rock-solid

From the worker’s perspective it’s just “my personal AI in Telegram”. They have no idea it’s all running on the same Mac Mini / VPS.

Step 1: Create one agent per worker

openclaw agents add alice-sales
openclaw agents add bob-support
openclaw agents add carol-finance
# ... one for every person

Step 2: Create a Telegram bot for each agent

Talk to @botfather
/newbot → give it a clean name
Copy the token

Do this once per worker.

Step 3: Configure everything in one file

Run openclaw configure or edit ~/.openclaw/openclaw.json directly.
Here’s a ready-to-paste example for a 3-person team:

{
  "agents": {
    "list": [
      { "id": "alice-sales", "workspace": "~/.openclaw/agents/alice-sales" },
      { "id": "bob-support", "workspace": "~/.openclaw/agents/bob-support" },
      { "id": "carol-finance", "workspace": "~/.openclaw/agents/carol-finance" }
    ]
  },
  "bindings": [
    { "agentId": "alice-sales", "match": { "channel": "telegram", "accountId": "alice" } },
    { "agentId": "bob-support", "match": { "channel": "telegram", "accountId": "bob" } },
    { "agentId": "carol-finance", "match": { "channel": "telegram", "accountId": "carol" } }
  ],
  "channels": {
    "telegram": {
      "enabled": true,
      "accounts": {
        "alice": {
          "botToken": "7123456789:AAFxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
          "dmPolicy": "pairing"
        },
        "bob": {
          "botToken": "7987654321:AAFyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
          "dmPolicy": "pairing"
        },
        "carol": {
          "botToken": "7843210987:AAFzzzzzzzzzzzzzzzzzzzzzzzzzzzzz",
          "dmPolicy": "pairing"
        }
      }
    }
  }
}

Security tip (do this immediately):

After the worker sends their first message, change dmPolicy to "allowlist" and add their Telegram numeric ID:

"allowFrom": ["tg:1234567890"]

(Get the ID by having them message @userinfobot)

Step 4: Restart & test

openclaw gateway restart
openclaw agents list --bindings

Send each worker their bot link. Done.

What you get automatically

Full isolation (memory, files, tools, history)
Different models or permissions per person (Claude for leadership, cheaper model for interns)
Agents can still talk to each other internally when needed
Works on anything: old Mac Mini, cheap VPS, even a Raspberry Pi with some tweaks

Official docs I used

Security hardening

If you want tighter control over your Openclaw, consider installing via my open source Openclaw hardening kit: https://github.com/NinoSkopac/openclaw-secure-kit

It is a turnkey solution - secure-by-default OpenClaw, with a verifiable security report.

How to Use Playwright MCP with a Proxy

Nino — Sun, 04 May 2025 15:11:20 +0000

Playwright MCP (@playwright/mcp) provides a powerful way for developers to integrate Playwright-driven browser automation into LLM-driven workflows through the Model Context Protocol (MCP). Often, you'll need to use a proxy with your automation tasks—whether to access region-restricted content, secure internal networks, or for debugging purposes. This guide explains clearly how you can configure and run Playwright MCP with a proxy.

🤔 What Exactly is Playwright MCP?

Before diving into the proxy setup, let's briefly discuss what MCP (Model Context Protocol) is:

MCP is an open-source, HTTP-like protocol designed to standardize two-way communication between LLM-powered assistants and external tools like browsers, databases, APIs, CRMs, and messaging services. MCP defines discovery, request/response schemas, and robust security mechanisms to simplify integrations, allowing your AI-driven workflow to perform data fetching or trigger actions without building bespoke integrations from scratch.

Playwright MCP integrates Playwright, a popular browser automation tool, into your MCP-based workflows—unlocking powerful browser automation capabilities directly within your LLM-driven applications.

🔐 Why Use a Proxy with Playwright MCP?

You might want proxy integration for several reasons, such as:

Accessing geo-specific content: Proxy servers enable IP-based geo-location changes.
Security & Privacy: Proxies can avoid exposing your real IP address.
Debugging & testing network scenarios: Simulate certain network constraints or behaviors through proxies.
Security compliance: Certain enterprise setups require mandatory proxy usage.
Setting up a proxy with Playwright MCP is straightforward—you just specify proxy options within the MCP's built-in configuration.

🛠 Minimal Configuration: Use a Proxy with MCP

Below is a minimal config.json example for configuring MCP to use Playwright with a proxy:

{
  "browser": {
    "browserName": "chromium",
    "launchOptions": {
      "proxy": {
        "server": "https://random.instill.network:8080",
        "username": "user",
        "password": "pass"
      },
      "headless": true
    }
  },
  "server": {
    "port": 8931,
    "host": "0.0.0.0"
  }
}

You can add this to your project and run MCP to use Playwright automation with your specified proxy setup.

✅ Advanced Example (Full-Featured Configuration)

Here's a more elaborate example illustrating additional useful settings, like the ability to bypass proxies for certain sites (internal sites) and browser viewport fine-tuning:

proxy-mcp.config.json

{
  "browser": {
    "launchOptions": {
      "proxy": {
        "server": "https://random.instill.network:8080",
        "bypass": "*.internal.example.com",
        "username": "user",
        "password": "pass"
      },
      "headless": true
    },
    "contextOptions": {
      "viewport": { "width": 1280, "height": 720 }
    }
  },
  "server": {
    "host": "0.0.0.0",
    "port": 8931
  },
  "capabilities": [ "core", "tabs", "pdf", "wait" ]
}

🏃 Running The MCP Server With Your Proxy Configuration

After creating your configuration file, simply start Playwright MCP:

npx @playwright/mcp@latest --config=proxy-mcp.config.json

The MCP server will now use your defined proxy settings during all Playwright browser automation tasks—super convenient!

🚀 Programmatic Usage (Node.js)

You might want to integrate MCP server proxy configuration directly into your Node.js workflow for custom integrations. Playwright MCP supports this seamlessly:

import http from 'http';
import { createServer } from '@playwright/mcp';
import { SSEServerTransport } from '@modelcontextprotocol/sdk/server/sse.js';

(async () => {
  const mcpServer = await createServer({
    browser: {
      launchOptions: {
        proxy: {
          server: 'https://random.instill.network:8080',
          bypass: '*.internal.example.com',
          username: 'user',
          password: 'pass'
        },
        headless: true
      },
      contextOptions: {
        viewport: { width: 1280, height: 720 }
      }
    },
    server: {
      host: '0.0.0.0',
      port: 8931
    },
    capabilities: [ 'core', 'tabs', 'pdf', 'wait' ]
  });

  const server = http.createServer((req, res) => {
    if (req.url === '/messages') {
      const transport = new SSEServerTransport('/messages', res);
      transport.bind(res);
    } else {
      res.writeHead(404);
      res.end();
    }
  });

  server.listen(8931, () => console.log('🚀 MCP server running at http://0.0.0.0:8931'));
})();

🧑‍💻 VSCode Integration Example (Optional)

If you're working directly within Visual Studio Code, you might find it handy to configure MCP integration directly through VSCode settings:

// settings.json snippet
{
  "mcpServers": {
    "playwright": {
      "name": "playwright",
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--config=proxy-mcp.config.json"
      ]
    }
  }
}

Now, simply run or integrate MCP from within VSCode for convenient browser-fueled workflows.

🌟 Wrapping Up & Next Steps

Configuring Playwright MCP to use a proxy is simple and blends neatly into existing workflows. Utilize the provided examples to streamline your browser automation tasks with ease.

🔥 Ready to Build Powerful AI-Powered Workflows?

Bring your ideas to life and supercharge your AI-driven workflows with Instill AI. Instill provides robust tooling for AI integration, allowing you to seamlessly orchestrate automation tasks, interact with LLM-powered agents, and build next-gen AI infrastructure.

🚀 Explore Instill Network →