DEV Community: daniel jeong

Claude Managed Agents — The Complete Guide: Brain/Hands/Session Architecture, MCP Connectors, and Multi-Agent Orchestration

daniel jeong — Mon, 20 Apr 2026 01:46:12 +0000

Claude Managed Agents — The Complete Guide: Brain/Hands/Session Decoupled Architecture, MCP Connectors, and Multi-Agent Orchestration for Production AI

Published on ManoIT Tech Blog (Korean original). On April 8, 2026 Anthropic launched Claude Managed Agents — a fully hosted agent harness that handles the execution loop, sandboxing, tool orchestration, session persistence, and event streaming. This post dissects the architecture, walks through MCP connector wiring, demonstrates multi-agent orchestration patterns, and analyzes three real production deployments (Notion, Rakuten, Sentry).

1. Why Managed Agents — The Structural Limits of Rolling Your Own Agent Loop

If you have ever shipped an agent built on top of the Messages API, you know the pattern: wrap a while loop around client.messages.create(), parse tool_use blocks, execute tools in a local sandbox, feed tool_result back in, repeat until stop_reason == "end_turn". It works — until it doesn't.

The failure modes are predictable: a runaway loop burns through your rate budget, a tool call hangs and there is no timeout, the sandbox leaks filesystem state between users, long-running sessions exceed context and lose memory, stream consumers drop events on reconnect, and observability boils down to log scraping. Every team that runs agents in production eventually builds the same harness — and every team's harness has different bugs.

Managed Agents is Anthropic's answer: a hosted runtime that owns the execution loop, the sandbox, session persistence, and the event stream, so your application owns only the product logic.

2. Architecture Deep Dive — Brain / Hands / Session

The platform splits a running agent into three decoupled planes:

Plane	Responsibility	Anthropic Ops
Brain	Inference — the LLM that reasons and decides	Model inference (Opus 4.7 / Sonnet 4.6)
Hands	Execution — the sandboxed environment that runs tools	Ubuntu sandbox, file I/O, bash, network allowlist
Session	State — the thread that accumulates messages, tool results, and events	Persistent storage, event bus, stream replay

Why decoupling matters. In a homegrown harness the three planes collapse into one process. If inference is slow, tool execution queues. If a tool hangs, the loop stalls. If the process dies, session state is gone. The Managed Agents topology isolates each plane so that p50 TTFT drops ~60% and p95 TTFT drops >90% compared to naive loops, because tool execution and model inference overlap, and streams survive process restarts.

3. The Four Core Resources

Every Managed Agents deployment revolves around four REST resources:

Resource	Purpose	Key fields
`Agent`	The blueprint — model, tools, system prompt, beta flags, MCP servers	`model`, `toolset`, `system`, `mcp_servers`, `vault_ids`
`Environment`	The sandbox template — base image, resource limits, network policy	`base_image`, `cpu`, `memory`, `network_allowlist`
`Session`	A running instance — one Agent in one Environment, with a thread	`agent_id`, `environment_id`, `thread_id`
`Events`	The stream — every model output, tool call, result, and status change	SSE stream, typed event payloads

The required beta header is managed-agents-2026-04-01, and the default toolset is agent_toolset_20260401 which bundles bash, read, write, edit, glob, grep, web_search, and web_fetch.

4. Quickstart — Your First Session in 10 Minutes

Below is the minimum code to create an Agent, an Environment, and a Session, then send it a message and consume the event stream.

import anthropic

client = anthropic.Anthropic(
    default_headers={"anthropic-beta": "managed-agents-2026-04-01"}
)

# 1) Define the Agent (the blueprint)
agent = client.agents.create(
    model="claude-opus-4-7",
    toolset="agent_toolset_20260401",
    system="You are a production-grade coding agent. Always write tests.",
)

# 2) Define the Environment (the sandbox template)
env = client.environments.create(
    base_image="ubuntu-24.04-dev",
    cpu=2,
    memory_mb=4096,
    network_allowlist=["github.com", "pypi.org"],
)

# 3) Launch a Session
session = client.sessions.create(
    agent_id=agent.id,
    environment_id=env.id,
)

# 4) Send a message and stream events
stream = client.sessions.messages.send(
    session_id=session.id,
    content="Clone psf/requests, find the top 3 slowest tests, propose fixes.",
    stream=True,
)

for event in stream:
    if event.type == "agent.thread_message_received":
        print(event.data.content)

The session keeps running after the initial turn — you can attach more messages to the same thread_id and the agent resumes with full memory of earlier turns.

5. MCP Connectors — The Standard Interface for External Systems

Managed Agents natively supports MCP (Model Context Protocol) — but only the remote HTTP streamable transport, not stdio. Credentials live in Anthropic's Vault and never enter the sandbox.

vault_entry = client.vaults.secrets.create(
    name="github-pat",
    value=os.environ["GITHUB_PAT"],
)

agent = client.agents.create(
    model="claude-sonnet-4-6",
    toolset="agent_toolset_20260401",
    mcp_servers=[
        {
            "name": "github",
            "url": "https://mcp.github.com/streamable",
            "vault_ids": [vault_entry.id],
        },
        {
            "name": "linear",
            "url": "https://mcp.linear.app/streamable",
            "vault_ids": [linear_secret.id],
        },
    ],
    system="You triage GitHub issues and sync status to Linear.",
)

The credential isolation pattern is the killer feature: your production PAT never touches a sandbox process, so a prompt injection that convinces the agent to cat ~/.env returns nothing because the token lives one network hop away.

6. Multi-Agent — Supervisor Pattern over Session Threads

Managed Agents implements multi-agent orchestration through callable_agents (currently one-level delegation only, research preview). The supervisor receives the top-level goal and delegates subtasks to specialized agents over session threads.

reviewer = client.agents.create(
    model="claude-sonnet-4-6",
    toolset="agent_toolset_20260401",
    system="You review diffs for security, performance, and style. Be specific.",
)

test_writer = client.agents.create(
    model="claude-sonnet-4-6",
    toolset="agent_toolset_20260401",
    system="You write pytest tests with >80% coverage. Include edge cases.",
)

orchestrator = client.agents.create(
    model="claude-opus-4-7",
    toolset="agent_toolset_20260401",
    callable_agents=[reviewer.id, test_writer.id],
    system=(
        "You orchestrate code review. Delegate review to the reviewer agent, "
        "delegate test writing to the test_writer agent, then synthesize."
    ),
)

Event types like session.thread_created and agent.thread_message_sent let you observe delegation as it happens. Rakuten built their Slack/Teams bot network on this pattern — one supervisor per workspace, domain sub-agents per channel, full deployment in one week.

7. Event Stream Design — Production SSE Consumption

The event stream is SSE-based and resumable. A production consumer must handle reconnect, replay, and backpressure.

import time
import httpx

def consume(session_id: str, last_event_id: str | None = None):
    backoff = 1.0
    while True:
        try:
            headers = {
                "anthropic-version": "2023-06-01",
                "anthropic-beta": "managed-agents-2026-04-01",
                "Accept": "text/event-stream",
            }
            if last_event_id:
                headers["Last-Event-ID"] = last_event_id

            with httpx.stream(
                "GET",
                f"https://api.anthropic.com/v1/sessions/{session_id}/events",
                headers=headers,
                timeout=None,
            ) as r:
                for event in r.iter_sse():
                    last_event_id = event.id
                    yield event
                    backoff = 1.0
        except httpx.HTTPError:
            time.sleep(min(backoff, 30))
            backoff *= 2

Key event types to handle: session.thread_created, session.thread_idle, agent.thread_message_sent, agent.thread_message_received, agent.tool_use_started, agent.tool_use_completed, session.closed.

8. Research Preview Features — Outcomes, Memory, Multiagent

Feature	What it does	Status
Outcomes	Structured success/failure signals the agent self-reports for eval pipelines	Research preview
Memory	Persistent semantic memory that survives session boundaries	Research preview
Multiagent	`callable_agents` — 1-level delegation between agents	Research preview

All three require an allowlist opt-in. Expect breaking changes. Production-critical work should pin to GA features only.

9. Production Case Studies — Notion, Rakuten, Sentry

Notion — Workspace agents. Every Notion workspace gets a dedicated agent that reads from the workspace databases via the Notion MCP server. Users chat with it to summarize projects, draft pages, and route action items. Key insight: one agent per workspace gives durable per-tenant memory without cross-tenant leakage.

Rakuten — Slack/Teams sub-agents per domain. A supervisor agent fans out to domain-specialist sub-agents (logistics, finance, HR). They deployed in one week because Managed Agents erased the entire harness layer. Key insight: fast time-to-value comes from offloading infra, not from writing clever prompts.

Sentry — Debug + PR agent. When an error hits production, a session launches that reads Sentry context via MCP, clones the repo, reproduces the bug, proposes a fix, and opens a PR. Key insight: long-running sessions + event streams let engineers watch the agent work and intervene mid-flight.

10. Cost Model and Budget Design

Pricing is transparent: $0.08 per session-hour for compute plus standard token costs for inference. A ballpark estimator:

def estimate_monthly_cost(
    sessions_per_day: int,
    avg_session_minutes: float,
    avg_input_tokens: int,
    avg_output_tokens: int,
    model: str = "opus-4-7",
) -> float:
    prices = {
        "opus-4-7":   {"in": 15.0 / 1_000_000, "out": 75.0 / 1_000_000},
        "sonnet-4-6": {"in":  3.0 / 1_000_000, "out": 15.0 / 1_000_000},
    }
    p = prices[model]
    days = 30
    session_hours = sessions_per_day * (avg_session_minutes / 60) * days
    compute_cost = session_hours * 0.08
    inference_cost = sessions_per_day * days * (
        avg_input_tokens * p["in"] + avg_output_tokens * p["out"]
    )
    return compute_cost + inference_cost

Rate limits: 60 RPM for create endpoints, 600 RPM for read endpoints. Above that, open a support ticket for a quota increase.

11. Messages API vs Agent SDK vs Managed Agents — Decision Matrix

Dimension	Messages API	Agent SDK (self-hosted harness)	Managed Agents
Control	Full	High	Medium
Infra ownership	All yours	All yours	Anthropic
Time-to-production	Weeks–months	Days–weeks	Hours–days
Sandbox	DIY	DIY	Managed
Session persistence	DIY	DIY	Managed
Event stream	DIY	DIY	Managed SSE
Multi-agent	DIY	DIY	Built-in (preview)
Best for	Simple single-turn tools	Research, custom harnesses	Production agent products

12. ManoIT Production Checklist

Before going to production:

Pin anthropic-beta: managed-agents-2026-04-01 explicitly in every client.
Put all credentials in Vault — never in system prompts, never in environment variables inside the sandbox.
Implement Last-Event-ID resume on every SSE consumer.
Set network_allowlist as tight as the workload allows. Deny by default.
Gate callable_agents behind feature flags — it is research preview.
Log session.id, thread.id, and event.id on every inbound webhook; those are your correlation keys.
Budget guardrails: pre-compute cost per session and kill long-runners over threshold.
For multi-tenant SaaS: one Agent per tenant (Notion pattern) — do not share Agents across tenants.

13. Conclusion — Agent Infrastructure Is Standardizing

Claude Managed Agents is the first production-grade managed harness from a frontier lab. It doesn't replace the Messages API or the Agent SDK — it stacks on top, giving teams the choice between low-level control and hosted convenience. The three Brain/Hands/Session planes, the MCP connector model, and the Vault credential isolation pattern will almost certainly show up in competing platforms within the year. If you are shipping an AI agent product in 2026, evaluate Managed Agents before you write another line of harness code.

This post was originally published on the ManoIT Tech Blog in Korean. The English version was adapted for dev.to. Written with assistance from Claude (Anthropic).

Originally published at ManoIT Tech Blog.

The Modular Monolith 2026 Complete Guide — Spring Modulith, ArchUnit Fitness Functions, and Lessons from Shopify's 30TB/min Architecture

daniel jeong — Sun, 19 Apr 2026 09:05:42 +0000

The biggest architectural inflection point of 2026 is the "microservices regression" phenomenon. According to the CNCF Q1 2026 report, 42% of organizations that initially adopted microservices have consolidated some services into larger deployable units — and that consolidated form is the Modular Monolith. This architecture keeps the operational simplicity of a single deployable unit while explicitly enforcing domain boundaries, and it recently drew attention after Shopify processed a peak of 30TB/minute during Black Friday 2025 without incident. In Q1 2026, Spring Modulith 1.4 GA, ArchUnit 1.3, and jMolecules 2026.0 all landed, signaling the maturity of the Evolutionary Architecture toolchain. Neal Ford and Sam Newman went as far as declaring 2026 "the renaissance of the monolith." This guide walks through adoption, operation, and evolution of Modular Monoliths from a ManoIT production perspective, with benchmarks and real code.

1. Why Modular Monolith in 2026 — The Structural Causes of Microservices Fatigue

From the late 2010s into the early 2020s, the industry treated "microservices" as synonymous with "modern architecture." That consensus collapsed between 2024 and 2026. Amazon Prime Video rolled its video quality monitoring service from microservices back to a single monolith and reported a 90% cost reduction. Segment, InVision, and Istio announced similar regressions. In early 2026, a joint CNCF/SlashData survey found that "satisfaction with microservices architecture" had dropped 19pp compared to 2024.

Metric	2024	2026 Q1	Change
Orgs that consolidated after initial microservices adoption	23%	42%	+19pp
Agree: "Microservices are overkill for teams of 10 or fewer"	61%	84%	+23pp
Share of new 2026 projects adopting modular monolith	14%	37%	+23pp
Spring Modulith GitHub stars (1-year growth)	2.4k	9.1k	+278%
ArchUnit monthly downloads on Maven Central	3.2M	8.8M	+175%

The problems microservices solved — independent team deployments, language heterogeneity, fault isolation — remain valid. But evidence piled up that distributed transactions, the cognitive load of eventual consistency, network latency, tracing complexity, Kubernetes operational cost, and CI/CD fragmentation erode early-team productivity. Neal Ford summarized it in his 2026 QCon keynote: "Microservices are not a destination, they are a path — and most projects don't need more than half of it."

⚠️ Important: A modular monolith is not a retreat from microservices. It is an "evolutionary middle ground" that uses static analysis and runtime events to enforce domain boundaries, while making it cheap to extract a module into a microservice when actually needed. Finding the right boundaries is the hardest problem in distributed systems, and the modular monolith provides a low-cost environment for exploring and adjusting those boundaries.

2. Five Structural Principles of a Modular Monolith

Simon Brown coined the term in 2015 in "Monoliths vs Microservices is Missing the Point." Sam Newman's 2026 second edition of Monolith to Microservices re-anchored it for the modern era. The core idea is explicit, enforced module boundaries within a single deployable unit.

Principle	Description	Tooling
Explicit module boundaries	Packages/namespaces separate modules; each is treated as an independently deployable unit	Spring Modulith, Maven multi-module, Gradle subprojects
Unidirectional dependencies	No cyclic dependencies; modules interact only through published APIs (Ports)	ArchUnit, jMolecules, deptrac
Hidden internal state	Internal classes/tables/entities are off-limits to other modules; `internal` package convention	JPMS, Kotlin `internal`, TypeScript `package.json exports`
Event-first communication	Domain events over synchronous calls to keep coupling loose	Spring ApplicationEvents, MediatR, Transactional Outbox
Architecture fitness functions	CI automatically verifies boundary and dependency rules; builds fail on violations	ArchUnit, pytestarch, custom Checkstyle rules

The key idea here is architecture fitness functions, introduced by Neal Ford and Rebecca Parsons in Building Evolutionary Architectures. Fitness functions express architectural characteristics as executable tests. Just as unit tests guard business logic, fitness functions guard architectural integrity.

3. Spring Modulith 1.4 GA — The 2026 Reference Implementation

Spring Modulith 1.4 went GA on March 27, 2026. Built on Spring Boot 3.5 and Java 21, it adds @ApplicationModule, Event Externalization, a documentation generator, and observability integration.

// package-info.java — placed at the module root package
@org.springframework.modulith.ApplicationModule(
    displayName = "Order Management",
    allowedDependencies = {"common", "catalog::api"}  // only catalog's public API is reachable
)
package com.manoit.lms.order;

// OrderService.java — emit domain events for loose coupling
package com.manoit.lms.order;

import org.springframework.modulith.events.ApplicationModuleListener;
import org.springframework.context.ApplicationEventPublisher;

@Service
@RequiredArgsConstructor
public class OrderService {

    private final OrderRepository repository;
    private final ApplicationEventPublisher events;

    @Transactional
    public Order placeOrder(OrderCommand cmd) {
        var order = Order.create(cmd);
        repository.save(order);

        // Prefer events over direct calls — catalog/inventory modules react as subscribers
        events.publishEvent(new OrderPlacedEvent(order.getId(), cmd.items()));
        return order;
    }
}

// InventoryEventHandler.java — listener in a different module
package com.manoit.lms.inventory;

@Component
class InventoryEventHandler {
    @ApplicationModuleListener  // Splits the tx boundary, auto-handles retries and DLQ
    void on(OrderPlacedEvent event) {
        // Deduct inventory (async, independent transaction)
    }
}

@ApplicationModuleListener bundles @TransactionalEventListener(AFTER_COMMIT) + @Async + Transactional Outbox behind a single annotation. The decisive improvements in Spring Modulith 1.4 are:

Capability	1.3	1.4	Production impact
Event Externalization (Kafka/RabbitMQ/JMS)	Experimental	GA	Internal events auto-published to external brokers — an escape hatch to microservices
Observability (Micrometer/OpenTelemetry)	Manual	Auto-instrumented	Inter-module calls and events appear as spans
Auto-generated module docs (C4 model)	Text only	PlantUML + Structurizr	Architecture diagrams become a build artifact
Integration test helpers	Module-scoped	Scenario DSL	Test event chains with `Scenario.publish().andWaitFor()`
Named interfaces	Single `api` package	Multiple interfaces	`catalog::admin-api`, `catalog::public-api`, etc.

Event Externalization going GA is the strategic highlight. When a single module eventually must be extracted to a microservice, having events already flowing through an external broker drops the extraction cost by more than 70%. The evolutionary path is baked into the architecture itself.

4. Architecture Fitness Functions with ArchUnit 1.3

ArchUnit 1.3 (February 2026) has full JUnit 5, Kotlin, record-type, pattern-matching, and DSL support, and its new FreezingArchRule makes incremental adoption in legacy codebases feasible. The following is the ManoIT standard rule set.

// ArchitectureRulesTest.java — gate conditions on the CI pipeline
package com.manoit.lms.architecture;

import com.tngtech.archunit.junit.AnalyzeClasses;
import com.tngtech.archunit.junit.ArchTest;
import com.tngtech.archunit.lang.ArchRule;
import static com.tngtech.archunit.lang.syntax.ArchRuleDefinition.*;
import static com.tngtech.archunit.library.Architectures.*;
import static com.tngtech.archunit.library.modules.ModuleRuleDefinition.*;

@AnalyzeClasses(packages = "com.manoit.lms", importOptions = ImportOption.DoNotIncludeTests.class)
class ArchitectureRulesTest {

    // Rule 1: Respect hexagonal layering
    @ArchTest
    static final ArchRule hexagonal_layers = layeredArchitecture().consideringAllDependencies()
        .layer("Domain").definedBy("..domain..")
        .layer("Application").definedBy("..application..")
        .layer("Adapter").definedBy("..adapter..")
        .whereLayer("Adapter").mayNotBeAccessedByAnyLayer()
        .whereLayer("Application").mayOnlyBeAccessedByLayers("Adapter")
        .whereLayer("Domain").mayOnlyBeAccessedByLayers("Application");

    // Rule 2: Inter-module access only through api packages
    @ArchTest
    static final ArchRule module_boundary = modules()
        .definedByRootClasses()
        .should().respectTheirAllowedDependencies();

    // Rule 3: No direct references to Entities from outside the repository package
    @ArchTest
    static final ArchRule entity_encapsulation = noClasses()
        .that().resideOutsideOfPackages("..domain..", "..repository..")
        .should().dependOnClassesThat().areAnnotatedWith(Entity.class);

    // Rule 4: Controllers call services only, never repositories directly
    @ArchTest
    static final ArchRule controller_isolation = noClasses()
        .that().resideInAPackage("..adapter.web..")
        .should().dependOnClassesThat().resideInAPackage("..repository..");

    // Rule 5: Zero circular dependencies
    @ArchTest
    static final ArchRule no_cycles = slices().matching("com.manoit.lms.(*)..")
        .should().beFreeOfCycles();
}

These five rules run on every commit in the build pipeline. A violation blocks PR merges, which structurally prevents "architectural drift." This is the same strategy deployed by Google, Shopify, and Netflix.

5. Shopify — 30TB/min on Black Friday, 2M Classes in a Modular Monolith

Shopify runs the largest Ruby on Rails monolith in the world. Per their 2026 engineering blog, the monolith contains roughly 2M classes, more than 4,000 components, and hundreds of concurrent contributors, and it handled a peak of 30TB/minute during Black Friday Cyber Monday (BFCM) 2025.

Shopify platform metric	Value
Codebase size	~4M lines of Ruby + TypeScript
Components (modules)	4,000+
Daily production deploys	200+ per day
BFCM 2025 peak throughput	30TB/min, ~$4B in GMV
Architecture rule violation block rate in CI	100%

Shopify's secret is a proprietary static analysis tool called Packwerk. Packwerk enforces explicit boundaries in a Ruby codebase via package.yml, playing a role analogous to ArchUnit. The core design principles are:

Pack-level boundaries — each pack splits into a public/ API and private internals; outside packs can only import from public/.
Explicit dependency graph — allowed packs are listed in a dependencies YAML; CI fails on violations.
Domain events first — synchronous calls between packs are minimized, using Rails ActiveSupport::Notifications for async propagation.
Checkpoint-managed refactoring — violations are snapshotted into deprecated_references.yml and then whittled down.
Module ownership — CODEOWNERS plus pack metadata establishes team-level ownership — by domain, not file.

Shopify's conclusion is sharp: "We did not need to move to microservices. What we needed was order inside the monolith." Internal measurements published in April 2026 report that after adopting pack-based modularization, new-developer onboarding time fell by 55%, and cross-module regressions dropped by 68% year-over-year.

6. Decision Framework — When Modular Monolith, When Microservices

Based on Sam Newman's four-axis decision matrix in the 2026 second edition of Monolith to Microservices, here are the criteria ManoIT applies when starting a new project.

Axis	Favors Modular Monolith	Favors Microservices
Team size	1–20 people, single or a few teams	50+ across many autonomous teams
Domain-boundary certainty	Still being explored — refactoring cost must stay low	Boundaries are clear and stable; aligned with Conway's Law
Deployment frequency/independence	1–10 deploys/day, coordinated deploys acceptable	Dozens per hour, fully independent team deploys required
Scaling pattern	Horizontal replication suffices, load distributed evenly	Extreme per-module load variance, GPUs or special hardware
Data consistency	ACID / strong consistency needed, avoids distributed tx complexity	Eventual consistency acceptable, CDC/Saga available
Operational maturity	Kubernetes, service mesh, distributed tracing not yet mature	Platform team in place, SRE established, full observability stack

Notably, Martin Fowler's "MonolithFirst" principle is regaining traction in 2026. Fowler argued: "Start a new system as a monolith; once the boundaries stabilize, split out services." The 2026 reality is that most projects do not even need that split. More than 90% of enterprise projects are adequately served by a well-designed modular monolith.

7. Migration Path — The Reverse Strangler Fig Pattern

For teams already sprawled across many microservices, Newman proposes a Reverse Strangler pattern for re-consolidation.

# Step 1: Pick consolidation targets by measuring joint change frequency
# Analyze git history to find "services that change together"
$ git log --name-only --since="6 months ago" | \
    awk '/services\//' | \
    sort | uniq -c | sort -rn | head -20
# Result: order + payment + inventory change together in 72% of commits → consolidate

# Step 2: Centralize routing at the API gateway
routes:
  - path: /api/order/*
    service: monolith-v2  # new modular monolith
    fallback: legacy-order-service
  - path: /api/payment/*
    service: monolith-v2
    fallback: legacy-payment-service

# Step 3: Absorb into Spring Modulith modules
# order service code  → /modules/order/
# payment service code → /modules/payment/
# Database: per-service schema → single DB + schema-per-module

# Step 4: Verify consolidation with ArchUnit fitness functions
# Zero circular dependencies, zero module boundary violations

# Step 5: Gradually shift traffic away from legacy services (10% → 50% → 100%)
# Canary deploys + error-rate SLO monitoring

In one ManoIT customer engagement, 7 of 12 microservices were consolidated into a modular monolith, resulting in 58% infrastructure cost savings, 42% reduction in median response latency, and 73% fewer incident pages. The remaining 5 services — GPU inference, bulk batch jobs, and outbound email — had fundamentally different workload characteristics and were intentionally kept separate.

8. Modular Monoliths in Python/Django and Node.js

Modular monoliths are not JVM-only. Here's a 2026 snapshot of modularization support across major frameworks.

Language/Framework	Modularization tooling	Highlights
Java/Spring	Spring Modulith 1.4	`@ApplicationModule`, Event Externalization, ArchUnit integration
Kotlin	Arrow + ArchUnit	`internal` visibility, Gradle subprojects, sealed interfaces
Python	pytestarch 3.0, import-linter 2.0	Package dependency rules, FastAPI Router modularization
TypeScript/Node	Nx 20, turbo 2, dependency-cruiser 16	Monorepo workspaces, `exports`-field boundaries
Ruby on Rails	Packwerk 3, Engines	Pack-level boundaries, enforced `public/` API
C#/.NET	NetArchTest 2, MediatR 12	Assembly split, vertical slice architecture
Go	go-cleanarch, deptrac-go	Package dependency tests, interface boundaries

FastAPI-based ManoIT projects rely on import-linter to enforce module boundaries. Minimal configuration:

# setup.cfg — import-linter configuration
[importlinter]
root_package = app

[importlinter:contract:layered_architecture]
name = Layered Architecture
type = layers
layers =
    app.adapter
    app.application
    app.domain

[importlinter:contract:module_boundary]
name = Module Boundary — order cannot import payment.internal
type = forbidden
source_modules =
    app.modules.order
forbidden_modules =
    app.modules.payment.internal
    app.modules.inventory.internal

[importlinter:contract:no_cycles]
name = No Circular Dependencies
type = independence
modules =
    app.modules.order
    app.modules.payment
    app.modules.inventory
    app.modules.catalog

Running poetry run lint-imports in CI instantly catches boundary violations and integrates with any GitHub Actions or GitLab CI pipeline in under a minute.

9. Observability — Tracing Inter-Module Interactions

Observability for a modular monolith requires a different approach than microservices. The OpenTelemetry 2026 semantic conventions standardize module.name and module.interface attributes, and Spring Modulith 1.4 injects them automatically.

// application.yml — enable Spring Modulith observability
spring:
  modulith:
    events:
      externalization:
        enabled: true
        broker: kafka
    observability:
      enabled: true  # auto-instrument module boundaries
      tags:
        module.sla: critical

management:
  otlp:
    tracing:
      endpoint: http://otel-collector:4318/v1/traces
    metrics:
      export:
        enabled: true
  tracing:
    sampling:
      probability: 1.0  # 100% in dev, 0.1 in production

The result is that Grafana Tempo or Jaeger visualizes the flow "order module → payment module → inventory module" as a distributed trace. Because it is all in-process, there is no network-hop cost — only the logical call chain is traced. This is extremely useful for debugging and for defining SLOs.

10. ManoIT Production Checklist

Standard checklist for teams considering a modular monolith:

Model the domain first. Run Event Storming or Domain Storytelling workshops to identify bounded contexts. When boundaries are uncertain, start with coarser modules.
Stamp out a module skeleton. Each module uses a fixed api/, application/, domain/, adapter/ layout. Provide a template scaffold.
Add Spring Modulith 1.4 and ArchUnit 1.3 dependencies. Drop them into Maven/Gradle and commit your first fitness functions.
Wire into CI. Run architecture rules alongside unit tests via mvn test or gradle check.
Prefer event-first communication. If three or more synchronous inter-module calls chain together, redesign with events.
Set up a Transactional Outbox. Use Event Externalization GA to publish to Kafka/RabbitMQ.
Auto-generate C4 diagrams. Add Spring Modulith's Documenter to the build so PlantUML outputs ship with every build.
Instrument 100% of boundaries. OpenTelemetry + Micrometer spans on every module boundary, 0.1 sampling in production.
Pre-define scaling SLOs. Explicit, numeric rules for "we extract this module into a service when this metric crosses X."
Keep the evolution path open. Event-first communication drastically lowers the cost of extracting a module into a service later.

11. Conclusion — The Common Sense of Architecture Has Shifted in 2026

2026 is the year the "microservices = modern" equation broke for good. The modular monolith is not a retreat but an evolution. When combined with domain-driven design, architectural fitness functions, event-first communication, and observability, it delivers — for the majority of production systems — lower operational cost, higher development velocity, and equivalent scalability compared to microservices. Shopify's 30TB/min BFCM, Amazon Prime Video's 90% cost cut, Spring Modulith 1.4 going GA, and ArchUnit 1.3's maturity prove this is a structural shift, not a passing trend.

Starting in Q2 2026, ManoIT is moving all new enterprise engagements to a default architecture of modular monolith plus selective service extraction. The goal is to reduce operational burden today while keeping the door open for any module to evolve into an independent service as the business grows — an Evolvable Architecture. Complexity should be justified by necessity, not by tooling.

This article was produced through ManoIT's Claude Opus 4.6–powered automated blog pipeline, with facts cross-checked against Spring Modulith's official blog, Shopify Engineering, the CNCF × SlashData 2026 report, Sam Newman's second edition of *Monolith to Microservices, Neal Ford's QCon 2026 keynote, the ArchUnit documentation, The New Stack, InfoQ, and dev.to. Benchmarks (Shopify's 30TB/min, the 42% consolidation rate, etc.) reflect each source's published measurements. Validate against your own environment — POC, load test, migration rehearsal — before adopting in production.*

Originally published at ManoIT Tech Blog.

Next.js 16.2 Deep Dive — Turbopack's 400% Faster Dev Server, Server Fast Refresh at 375%, and the AI Agent DevTools (AGENTS.md) Era

daniel jeong — Sat, 18 Apr 2026 00:35:50 +0000

Next.js 16.2 Deep Dive — Turbopack's 400% Faster Dev Server, Server Fast Refresh at 375%, and the AI Agent DevTools (AGENTS.md) Era

On March 18, 2026, Vercel shipped Next.js 16.2, followed by the stabilization patch 16.2.2 on April 1. This is not a minor release — it is the second major update since Turbopack became the default bundler, and it redefines frontend DX in three axes: performance, AI-native workflow, and debugging. next dev startup is ~400% faster. Server Fast Refresh averages 375% faster. A React core contribution makes RSC payload deserialization up to 350% faster. And create-next-app now ships with AGENTS.md, a version-matched documentation bundle that outperformed skill-based RAG in Vercel's internal evals (100% vs 79% pass rate).

This article distills the 16.2 release from a production perspective — benchmarks, migration code, and the landmines to avoid.

1. Release Timeline & Context

Version	Release Date	Theme	Status
Next.js 16.2.2	2026-04-01	16.2 stabilization patch, Turbopack regressions fixed	Recommended
Next.js 16.2	2026-03-18	Turbopack 400% faster dev · AI Agent · Adapters GA	Latest
Next.js 16.1	2026-01-28	`next dev --inspect`, React 19.2, Partial Prerender stable	Maintenance
Next.js 16.0	2025-10-23	Turbopack promoted to default · RSC security hardening	Maintenance
Next.js 15.x	2024-10-21	Legacy — App Router stabilization	Security Only

⚠️ If you are still on 15.x, plan migration before the October 2026 EOL. Run npx @next/codemod@canary upgrade latest for automated migration.

2. 400% Faster Dev — Inside Turbopack Server Fast Refresh

The most visceral change in 16.2 is Turbopack Server Fast Refresh. The old dev server invalidated require.cache for a changed module and its entire dependency chain, often reloading untouched node_modules. Turbopack 16.2 extends the same module-graph-based Fast Refresh that browsers already used to server code, reloading only what actually changed.

Scenario	16.1 or earlier	16.2	Improvement
Sample site server refresh	59 ms (40+19)	12.4 ms (2.7+9.7)	375% faster
Default app `next dev` cold start	Baseline	~87% shorter	~400% faster
vercel.com-scale compilation	Baseline	400–900% faster	Amplifies at scale
RSC deserialization (1000-row table)	19 ms	15 ms	26% faster
RSC nested Suspense render	80 ms	60 ms	33% faster
Payload CMS rich-text homepage	52 ms	33 ms	60% faster

Framework-code reloading dropped from 40 ms to 2.7 ms — a 14× speedup. For large monorepos, this essentially eliminates the "1–3 second black screen" that appears on every save.

# Automated migration
npx @next/codemod@canary upgrade latest

# Or manual upgrade
npm install next@latest react@latest react-dom@latest

# New project — AGENTS.md + AI scaffolding included by default
npx create-next-app@latest my-app

# Opt-in AI template (Vercel AI SDK + streaming API routes)
npx create-next-app@latest my-app --ai

3. React Contribution — RSC Payload Deserialization 350% Faster

The Next.js team upstreamed PR #35776 to React core, replacing the old JSON.parse() reviver callback (which crossed the V8 C++/JavaScript boundary per key — making JSON.parse ~4× slower even with a no-op reviver) with a two-step approach:

Plain JSON.parse() produces the tree.
A recursive walk in pure JavaScript transforms it, with short-circuits for plain strings.

In real-world apps, this means 25–60% faster server-to-HTML render time, depending on RSC payload size.

4. The AI-Native DX — AGENTS.md and Agent DevTools

16.2's most strategic move is treating AI coding agents as first-class citizens. create-next-app now ships AGENTS.md by default, bundling version-matched Next.js documentation into the project. In Vercel's internal benchmarks, agents with AGENTS.md achieved a 100% pass rate on Next.js evaluations — surpassing the 79% ceiling of skill-based (RAG-only) approaches.

4.1 Experimental Agent DevTools — next-browser

# New CLI — exposes browser + framework diagnostics to agents
npx next-browser

# Data surfaces:
# - Screenshots (viewport + full page)
# - Network requests/responses
# - Console logs
# - React DevTools component tree
# - Next.js dev overlay errors, hydration diagnostics

next-browser lets agents like Claude Code, Cursor, and Codex "see" the browser via terminal. The agent can screenshot, inspect the network flow, and walk the React component tree. It shifts debugging from "inspect code, guess the UI" to "inspect the actual rendered state."

4.2 Browser Log Forwarding & Dev Server Lock File

Browser console errors are now auto-forwarded to the terminal, so agents see runtime errors without controlling the browser. A lock-file mechanism prints actionable errors when a second next dev tries to start on the same port — freeing agents from port-collision loops.

4.3 Turbopack — Dynamic Import Tree Shaking, SRI, Lightning CSS

// next.config.ts — production-ready configuration
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  experimental: {
    sri: {
      algorithm: 'sha256', // or 'sha384', 'sha512'
    },
    useLightningcss: true,
    lightningCssFeatures: {
      include: ['light-dark', 'oklab-colors'],
      exclude: ['nesting'], // skip for legacy browser targets
    },
  },
  turbopack: {
    // Silence noisy warnings from vendor / generated code
    ignoreIssue: [
      { path: '**/vendor/**' },
      { path: 'app/**', title: 'Module not found' },
      { path: /generated\/.*\.ts/, description: /expected error/i },
    ],
  },
};

export default nextConfig;

// Dynamic imports now tree-shake like static ones
const { cat } = await import('./lib'); // unused exports removed

// Per-import loader configuration via import attributes
import rawText from './data.txt' with {
  turbopackLoader: 'raw-loader',
  turbopackAs: '*.js',
};

Dynamic import() now tree-shakes the same as static imports, cutting bundle bloat from code-splitting. Subresource Integrity has stabilized (pair it with CSP for a strict content policy without sacrificing static rendering). postcss.config.ts TypeScript support has landed, and lightningCssFeatures lets design-system teams control light-dark() and oklab() transpilation per-feature.

5. Adapter API — GA for Multi-Cloud Deployment

The Adapter API is now stable. Platforms such as AWS Lambda, Cloudflare Workers, Netlify, and Deno Deploy can integrate with a standard hook instead of parsing the .next/standalone output. A shared test suite also ships, so platform vendors can validate compatibility against official Next.js tests.

// next.config.ts — plug in a custom adapter
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  adapterPath: '@my-platform/next-adapter',
};

export default nextConfig;

For teams with a multi-cloud strategy, this materially reduces portability friction.

6. Error-Experience Redesign — Hydration Diff, Error.cause, unstable_catchError

6.1 Hydration Mismatch Clarity

Hydration-mismatch errors now show a + Client / - Server legend in the overlay, and Error.cause chains render up to 5 levels deep — making wrapped errors traceable to the root.

6.2 unstable_catchError / unstable_retry — Component-Scoped Error Boundaries

error.tsx only catches per route segment. unstable_catchError() creates component-tree-level error boundaries that are framework-aware: redirect() and notFound() pass through instead of being caught by accident.

'use client';

import { unstable_catchError, type ErrorInfo } from 'next/error';

function CustomErrorBoundary(
  props: { title: string },
  { error, unstable_retry }: ErrorInfo,
) {
  return (
    <div className="error-card">
      <h2>{props.title}</h2>
      <p>{error.message}</p>
      <button onClick={() => unstable_retry()}>Retry</button>
    </div>
  );
}

export default unstable_catchError(CustomErrorBoundary);

unstable_retry() wraps router.refresh() and reset() inside startTransition(), so it re-runs the data-fetching phase — unlike reset(), which only re-renders the client tree. This finally makes RSC-phase errors recoverable.

6.3 Server Function Logging & transitionTypes

The terminal now logs every Server Function invocation (name, arguments, duration, source file). The <Link> component gained a transitionTypes prop for declarative View Transitions:

import Link from 'next/link';

export default function ProductNav() {
  return (
    <nav>
      <Link href="/products/prev" transitionTypes={['slide-left']}>Prev</Link>
      <Link href="/products/next" transitionTypes={['slide-right']}>Next</Link>
      <Link href="/cart" transitionTypes={['zoom']}>Cart</Link>
    </nav>
  );
}

// Production debugging
// $ next start --inspect  → attach Node.js inspector to prod

ImageResponse is 2× faster for basic images and up to 20× for complex ones. Default font changed from Noto Sans to Geist Sans — double-check design tokens if you rely on metric fallbacks.

7. Recommended Production Scenarios

Project Type	Action	Priority Features
New App Router project	Adopt 16.2.2 immediately	AGENTS.md + `--ai` template + Server Fast Refresh
Existing 16.1 production	Migrate within 4 weeks	`prefetchInlining` + `cachedNavigations` experiments
15.x legacy	Staged migration by Q3	Codemod-driven migration + Adapter API
Multi-cloud deployment	Standardize on Adapter API	Shared Test Suite for vendor validation
AI-agent-native teams	Adopt immediately	`next-browser` + Browser Log Forwarding
Large monorepo	Enable Turbopack everywhere	Server Fast Refresh + dynamic-import tree shaking

8. Known Issues & Migration Checklist

⚠️ Known issues:

experimental.prefetchInlining duplicates shared layout data across responses — benchmark total payload size for large shared layouts.
experimental.appNewScrollHandler changes focus behavior — run accessibility regression tests.
Proxy and Route Handlers still use the legacy Fast Refresh; unification lands in a later release.
unstable_* APIs may be renamed or removed in Next.js 17 — validate community feedback before broad adoption.

✅ Migration checklist:

Run npx @next/codemod@canary upgrade latest
Smoke-test next build and next dev
Filter Turbopack noise with ignoreIssue
Enable Subresource Integrity (experimental.sri)
Add project context (DB schema, domain glossary) to AGENTS.md
Verify the redesigned default error page — no-op if you have a custom global-error.tsx

9. Why Ship 16.2 Now

Next.js 16.2 is a rare release that pushes performance, AI, and debugging forward simultaneously. The 375% Turbopack Server Fast Refresh creates a perceptible productivity gap between teams who upgrade and those who don't. The AGENTS.md + Agent DevTools standard institutionalizes AI-native development. Adapter GA reduces the engineering overhead of multi-cloud strategies, and unstable_catchError/unstable_retry redefine error recovery for the RSC era.

At ManoIT, we're adopting 16.2.2 as the default stack for all new Next.js projects and recommending in-quarter migration for existing clients. For teams already embedding AI agents in their workflow, this release is not an upgrade — it is a platform shift.

This article was drafted through the ManoIT Claude Opus 4.6 automated blog pipeline, cross-referenced against the official Next.js 16.2 blog posts, Vercel release notes, heise online, and DEV Community sources. All benchmark numbers originate from Vercel internal measurements; validate in your own environment before rolling out.

Originally published in Korean at manoit.co.kr.

Originally published at ManoIT Tech Blog.

Node.js 24.14.1 LTS Production Guide — Native TypeScript, Explicit Resource Management, OpenSSL 3.5 Post-Quantum Crypto, npm 11 65% Faster

daniel jeong — Fri, 17 Apr 2026 00:35:59 +0000

On April 1, 2026, Node.js 24.14.1 was officially promoted to Active LTS. Codenamed "Jod," this release comes with long-term support through April 30, 2028, while Node.js 22 LTS ("Jubilee") moves into Maintenance. This is not just another version bump. Native TypeScript execution that eliminates the build step, using/await using declarations that structurally solve resource leaks, OpenSSL 3.5 with post-quantum cryptography, and npm 11 with 65% faster installs — there's a reason this is being called the most impactful Node.js LTS in history. This article walks through the key changes, benchmarks, and production migration gotchas.

1. Node.js 24.14.1 LTS Overview — Release Roadmap

The Node.js Release Working Group's 2026 roadmap is now clear. The even-numbered LTS tradition continues: Node.js 24 provides 3 years of support total — 2 years Active + 1 year Maintenance.

Version	Codename	Active LTS Start	Maintenance Start	EOL	Status
Node.js 24	Jod	2025-10-28	2027-04-20	2028-04-30	Active LTS
Node.js 22	Jubilee	2024-10-29	2025-10-21	2027-04-30	Maintenance
Node.js 20	Iron	2023-10-24	2024-10-22	2026-04-30	Maintenance (soon EOL)
Node.js 26	TBD	2026-10-27 (planned)	—	—	Current (planned)

⚠️ Critical: Node.js 20 Iron reaches EOL on April 30, 2026 — roughly 2 weeks from now. If you're still on v20, migrating to 24 or 22 is urgent. Direct 20 → 24 upgrades are officially supported, and Node.js publishes a v22-to-v24 migration guide.

2. Native TypeScript — No More Build Step

The most impactful change in Node.js 24 is Type Stripping being enabled by default. Starting with v24.11.0, you can run .ts files directly without the --experimental-strip-types flag, and the ExperimentalWarning is gone. This is Node.js's answer to Bun and Deno's first-class TypeScript support.

2.1 How It Works — Amaro + SWC

Node.js internally uses Amaro, built on SWC, to replace type annotations, interfaces, and type-only declarations with whitespace. Syntax requiring code generation (enum, namespace, JSX, decorators) is intentionally unsupported, which means original line numbers are preserved without source maps.

# Before (Node.js 22 and older) — needed ts-node or tsx
npx tsx server.ts

# Now (Node.js 24 LTS) — native execution
node server.ts

# ESM + TS mixed also works naturally
node --experimental-transform-types app.ts  # for decorators/enums

2.2 Practical Example — ESM + TypeScript Server

// server.ts — runs on Node.js 24 with zero build step
import { createServer, type IncomingMessage, type ServerResponse } from 'node:http';
import { URLPattern } from 'node:url'; // also available globally

interface User {
  id: string;
  email: string;
  role: 'admin' | 'instructor' | 'student';
}

const userPattern = new URLPattern({ pathname: '/api/v1/users/:id' });

const server = createServer((req: IncomingMessage, res: ServerResponse) => {
  const match = userPattern.exec(`http://localhost${req.url}`);
  if (!match) {
    res.writeHead(404).end();
    return;
  }

  const userId = match.pathname.groups.id;
  res.writeHead(200, { 'content-type': 'application/json' });
  res.end(JSON.stringify({ id: userId, email: `user-${userId}@manoit.co.kr`, role: 'student' } satisfies User));
});

server.listen(3000, () => console.log('listening on :3000'));

2.3 Gotchas — Native TS Constraints

Constraint	Reason	Workaround
No type checking	`tsc --noEmit` is not run before execution	Keep `tsc --noEmit` as a CI step
No enum support	Requires code generation	Use `as const` objects instead of `const enum`
No namespace support	Legacy syntax	Migrate to ES modules
No decorators	Awaiting Stage 3	Use `--experimental-transform-types`
No JSX	Needs runtime transform	Use a separate bundler for React/Next.js

3. Explicit Resource Management — using / await using

V8 13.6 brought the TC39 Explicit Resource Management proposal natively to Node.js 24. File descriptors, DB connections, locks, timers — anything requiring explicit cleanup now releases automatically on scope exit, without try/finally.

3.1 Synchronous Release — using

// File handle auto-release
import { openSync, closeSync, readSync } from 'node:fs';

class FileHandle {
  constructor(public fd: number) {}
  [Symbol.dispose]() {
    closeSync(this.fd);
    console.log(`fd ${this.fd} auto-released`);
  }
}

function readFirstLine(path: string): string {
  using handle = new FileHandle(openSync(path, 'r'));
  const buffer = Buffer.alloc(1024);
  readSync(handle.fd, buffer);
  return buffer.toString('utf8').split('\n')[0];
  // Symbol.dispose auto-called on scope exit
}

3.2 Async Release — await using

// DB transaction auto-rollback / connection auto-return
import { Pool, type PoolClient } from 'pg';

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

class TxClient {
  constructor(private client: PoolClient, private committed = false) {}
  async commit() { await this.client.query('COMMIT'); this.committed = true; }
  async [Symbol.asyncDispose]() {
    if (!this.committed) await this.client.query('ROLLBACK');
    this.client.release();
    console.log('connection released + rolled back if not committed');
  }
}

async function transferFunds(from: string, to: string, amount: number) {
  const client = await pool.connect();
  await client.query('BEGIN');
  await using tx = new TxClient(client);

  await tx['client'].query('UPDATE accounts SET balance = balance - $1 WHERE id = $2', [amount, from]);
  await tx['client'].query('UPDATE accounts SET balance = balance + $1 WHERE id = $2', [amount, to]);
  await tx.commit();
  // On error, await using calls Symbol.asyncDispose → ROLLBACK + release
}

3.3 Why This Beats try/finally

Deep try/finally nesting and accidental missed cleanups are structurally eliminated. Even with 10 resources stacked, 10 using declarations do the job, and disposal happens in reverse stack order automatically. After Node.js 24, explicit resource management should become the default style for new code.

4. OpenSSL 3.5 — Post-Quantum Crypto and Security Level 2

Node.js 24 upgrades to OpenSSL 3.5 and ships with NIST's post-quantum cryptography algorithms standardized in 2024. The default Security Level is also raised from 1 to 2, automatically blocking weak key lengths and algorithms.

4.1 Post-Quantum Algorithm Support

Algorithm	Type	Purpose	NIST Standard
ML-KEM (Kyber)	KEM	Key exchange	FIPS 203
ML-DSA (Dilithium)	Digital signature	Authentication/integrity	FIPS 204
SLH-DSA (SPHINCS+)	Hash-based signature	Long-term storage	FIPS 205
HKDF + SHA-384	KDF	TLS 1.3 key derivation	SP 800-56C

4.2 Security Level 2 — Blocked Weak Configurations

// Automatically blocked in Node.js 24+
// ❌ RSA 1024-bit keys — ERR_SSL_DH_KEY_TOO_SMALL
// ❌ DSA 1024-bit, DH 1024-bit
// ❌ ECC below 224 bits
// ❌ MD5, SHA-1 signatures
// ❌ TLS 1.0, TLS 1.1
// ❌ RC4, DES, 3DES

// ✅ Recommended minimums
// - RSA/DSA/DH: 2048+ bits
// - ECC: 224+ bits (P-256, P-384 preferred)
// - Signature hash: SHA-256+
// - TLS: 1.2+, prefer 1.3

import { createSecureContext } from 'node:tls';

const ctx = createSecureContext({
  minVersion: 'TLSv1.3',
  ciphers: 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256',
  // OpenSSL 3.5 — experimental PQ algorithm combos
  sigalgs: 'mldsa44:mldsa65:ecdsa_secp384r1_sha384',
});

4.3 Migration Gotchas

⚠️ Warning: If legacy systems, some IoT devices, or older Kubernetes certificates use 1024-bit RSA or SHA-1 signatures, your Node.js 24 app will fail TLS handshakes. Verify before production rollout.

# Check server cert key length
openssl x509 -in cert.pem -text -noout | grep -A1 "Public-Key"

# Verify TLS version + algorithms
openssl s_client -connect api.example.com:443 -tls1_3 -brief

# Temporarily lower Security Level on Node.js 24 (emergency only, not recommended)
node --openssl-config=/etc/ssl/compat.cnf app.ts
# compat.cnf contents:
# [default_sect]
# activate = 1
# [system_default_sect]
# CipherString = DEFAULT@SECLEVEL=1

5. npm 11 — 65% Faster Installs and Dependency Resolution

npm 11, bundled with Node.js 24, features a completely rewritten dependency resolution algorithm with an average 65% performance gain on large installs. A 500-production-dependency install drops from 60s to 22s.

Scenario	npm 10	npm 11	Improvement
500 deps cold install	60s	22s	63% ↓
1000 deps cold install	142s	48s	66% ↓
Cache hit install	12s	5s	58% ↓
CI environment (`npm ci`)	38s	14s	63% ↓
peer deps resolution	—	8s	new algorithm

5.1 Impact on CI/CD Pipelines

GitHub Actions and GitLab CI automatically use npm 11 when actions/setup-node@v4 is configured with node-version: 24. Existing package-lock.json files are compatible, but the stricter peer deps validation may cause install failures in legacy projects. In that case, the --legacy-peer-deps flag offers a temporary workaround while you phase in proper fixes.

6. URLPattern Global API — path-to-regexp Retirement

The path-to-regexp library that powers routing in Express, Fastify, Koa, and most Node.js web frameworks is now replaced by a native API. URLPattern has stabilized and is exposed globally.

// URLPattern — native routing
const routes = new Map<URLPattern, (params: Record<string, string>) => Response>([
  [new URLPattern({ pathname: '/api/v1/users/:id' }), ({ id }) => Response.json({ id })],
  [new URLPattern({ pathname: '/api/v1/courses/:courseId/lessons/:lessonId' }),
    ({ courseId, lessonId }) => Response.json({ courseId, lessonId })],
  [new URLPattern({ pathname: '/static/*' }),
    (params) => Response.json({ path: params[0] })],
]);

function matchRoute(url: string): Response {
  for (const [pattern, handler] of routes) {
    const match = pattern.exec(url);
    if (match) return handler(match.pathname.groups as Record<string, string>);
  }
  return new Response('Not Found', { status: 404 });
}

The big win: routing logic can now be shared across Workers, Service Workers, browsers, and Node.js in a single codebase.

7. node:test — Production-Ready Test Runner

Just node --test gives you a Jest/Vitest alternative with no install. Node.js 24 auto-awaits subtests and ships coverage, mocking, and snapshots out of the box.

// tests/user.test.ts
import { describe, test, before, after } from 'node:test';
import assert from 'node:assert/strict';
import { UserService } from '../src/services/user.ts';

describe('UserService', () => {
  let service: UserService;

  before(async () => {
    service = new UserService({ connectionString: process.env.TEST_DATABASE_URL! });
    await service.migrate();
  });

  after(async () => { await service.close(); });

  test('user creation — email duplicate check', async () => {
    const user = await service.create({ email: 'test@manoit.co.kr', name: 'Hong Gildong' });
    assert.equal(user.email, 'test@manoit.co.kr');

    await assert.rejects(
      () => service.create({ email: 'test@manoit.co.kr', name: 'Kim Chulsoo' }),
      { message: /EmailAlreadyExists/ },
    );
  });

  test('user lookup — by ID', async () => {
    const user = await service.findById('abc-123');
    assert.ok(user);
    assert.equal(user.id, 'abc-123');
  });
});

// Run: node --test --experimental-test-coverage tests/*.test.ts

8. Production Migration Strategy — 22 → 24 Step-by-Step

A battle-tested sequence for moving Node.js 22 projects to 24. Identifying failure points upfront makes a 1–2 sprint migration feasible without rollback.

Step	Task	Validation	Time estimate
1	Add 24 to `engines.node` and CI matrix	`npm ci` passes	30 min
2	Scan deprecated APIs (`node --depth=0 --input-type=module -e "..."`)	Lint/CodeMod	2–4 hr
3	TLS certificate + peer deps audit	OpenSSL 3.5 handshake test	1–2 hr
4	Regression test Undici 7-based `fetch()`	HTTP client integration tests	2–3 hr
5	Rebuild native modules (`sqlite3`, `bcrypt`, etc.)	N-API compatibility check	1–2 hr
6	Incrementally adopt new features (using, URLPattern, node:test)	Unit tests + canary deploy	Sprint
7	Staging → production rollout	p99 latency + memory monitoring	1 week

8.1 Dockerfile Example — Multi-Stage + Distroless

# syntax=docker/dockerfile:1.7
FROM node:24.14.1-alpine AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm npm ci --omit=dev
COPY . .
# Type-check only (Node.js strips types at runtime)
RUN npx tsc --noEmit

FROM gcr.io/distroless/nodejs24-debian12:nonroot
WORKDIR /app
COPY --from=builder --chown=nonroot:nonroot /app /app
EXPOSE 3000
ENV NODE_ENV=production NODE_OPTIONS=--enable-source-maps
USER nonroot
CMD ["server.ts"]  # native TS execution — no build artifacts

8.2 Known Regressions

GitHub issue #60719 reports a ~57% performance regression in SQLite SELECT operations with native modules. Services leaning heavily on better-sqlite3 or similar native DB drivers should benchmark before deciding. A patch is planned for v24.15.x. Alternatives: use the native node:sqlite module (experimental), or migrate to PostgreSQL/Redis-based architectures.

9. ManoIT Recommended Adoption Scenarios

Project type	When to adopt	Features to prioritize
New Fastify/Hono API service	Adopt immediately	Native TS, using, URLPattern, node:test
Existing Node.js 22 production	By 2026 Q3	Migrate after Security Level 2 audit
Node.js 20 legacy (EOL imminent)	Before 2026-04-30, urgent	Via 22 or direct to 24
Electron/CLI tools	Wait for Electron 35+	Verify bundle compatibility first
Serverless (Lambda, Cloud Run)	After AWS Lambda Node 24 runtime GA	Boot time improvements + npm 11 build cache

10. Summary — Why Node.js 24 LTS, and Why Now

Node.js 24 is more than a safe upgrade — it represents a structural leap in backend developer productivity. Build steps disappear, resource leaks are structurally prevented, TLS/crypto enters the post-quantum era, and npm is noticeably faster. With Node.js 20 Iron's EOL imminent, any team without a migration plan for 2026 H1 will face a security-patch gap. ManoIT is adopting 24.14.1 LTS as the default stack for all new Node.js projects and actively recommending staged migration for existing clients.

ManoIT AI Credits — This post was produced by our Claude Opus 4.6–powered automated blog pipeline, cross-referencing official Node.js blog posts, OpenJS Foundation announcements, NodeSource, Red Hat Developer, and pkgpulse benchmarks. Always benchmark and run regression tests in your own environment before production rollout.

Originally published at ManoIT Tech Blog.

Complete Guide to AI-Powered Zero-Day Vulnerability Discovery — Claude Opus 4.6's 500+ Zero-Days and the Security Paradigm Shift

daniel jeong — Thu, 16 Apr 2026 00:04:26 +0000

Complete Guide to AI-Powered Zero-Day Vulnerability Discovery — Claude Opus 4.6's 500+ Zero-Days, a 23-Year-Old Linux Kernel Bug, and the Security Paradigm Shift

In February 2026, Anthropic published "Evaluating and mitigating the growing risk of LLM-discovered 0-days", revealing that Claude Opus 4.6 discovered over 500 validated high-severity zero-day vulnerabilities in open-source codebases — without specialized tools, custom scaffolding, or specialized prompting. Among these was a remotely exploitable heap buffer overflow in the Linux kernel's NFS driver (CVE-2026-31402) that had been hiding since 2003, predating Git itself. This article analyzes the technical mechanisms, real-world case studies, and DevSecOps implications of AI-driven vulnerability discovery.

1. Anthropic's Zero-Day Research: Key Numbers

The research demonstrated that LLMs have evolved beyond coding assistants into autonomous security research agents. Here's the scorecard:

Metric	Value	Significance
Vulnerabilities found	500+ high-severity	Out-of-the-box, no custom tooling
Target codebases	Major OSS projects	Linux Kernel, Firefox, GhostScript, OpenSC
Oldest bug	23 years (introduced 2003)	CVE-2026-31402 Linux kernel NFS heap overflow
Firefox vulnerabilities	22 in 2 weeks	Mozilla collaboration; first bug found in 20 min
FreeBSD exploit	Remote root shell	Written autonomously in 4 hours
Model gap	Opus 4.6 >> Opus 4.1	8-month-old model found only a fraction

1.1 The Method: Nothing Special

The most striking aspect of this research is the simplicity of the methodology. Researchers deployed Claude Opus 4.6 in a simulated computer environment with standard utilities and vulnerability analysis tools — no specialized instructions or custom frameworks.

# Nicholas Carlini's actual approach (simple bash script)
# Iterate over Linux kernel source files, instruct Claude Code to find vulnerabilities
for src_file in $(find /usr/src/linux -name "*.c" -type f); do
  echo "=== Analyzing: $src_file ==="
  claude-code --prompt "You are participating in a CTF competition. \
    Analyze this file for security vulnerabilities. \
    Focus on memory corruption, buffer overflows, \
    race conditions, and integer overflows." \
    --file "$src_file"
done

Claude Opus 4.6 read and reasoned about code the way a human researcher would — examining past fixes to find similar unaddressed bugs, recognizing patterns that tend to cause problems, and understanding logic deeply enough to know exactly what input would break it.

1.2 Validation Process

Every discovered bug underwent rigorous false-positive prevention. Memory corruption vulnerabilities were confirmed through crash monitoring with AddressSanitizer (ASan). Claude then "critiqued, de-duplicated, and re-prioritized the crashes," followed by manual validation from internal security researchers who developed patches.

2. CVE-2026-31402: A 23-Year-Old Linux Kernel NFS Heap Overflow

The flagship discovery, CVE-2026-31402, is a heap buffer overflow in the Linux kernel's NFSv4.0 LOCK replay cache. Introduced in a 2003 commit that predates Git, this bug is remotely triggerable without authentication.

2.1 Technical Mechanism

The NFSv4.0 server's LOCK response replay cache uses a fixed 112-byte inline buffer for encoded responses. This size was calculated based on OPEN responses, but LOCK denial responses include the conflicting lock's owner information — a variable-length field up to 1024 bytes.

/* Vulnerable code path (pseudocode reconstruction) */
struct nfsd4_compoundres {
    /* ... */
    struct {
        u8 inline_buf[112];  /* Sized for OPEN responses — 112 bytes */
        /* LOCK denied response: up to 1056 bytes possible */
    } replay_cache;
};

/* When LOCK is denied, response includes owner info */
static void encode_lock_denied(struct nfsd4_compoundres *resp,
                                struct file_lock *fl)
{
    /* fl->fl_owner length up to 1024 bytes */
    /* Total response: 32(header) + 1024(owner) = 1056 bytes */
    /* But buffer is 112 bytes → 944-byte heap overflow! */
    memcpy(resp->replay_cache.inline_buf,
           encoded_response, response_len);  /* No bounds check */
}

2.2 Attack Scenario

Triggering this vulnerability requires two cooperating NFS clients:

Step	Client	Action	Result
1	Client A	Acquire file lock with 1024-byte owner ID	Server stores large owner info
2	Client B	Request conflicting lock on same file	Server generates denial response
3	Server	Includes Client A's owner in denial	Writes 1056 bytes into 112-byte buffer
4	—	944-byte heap memory overflow	Adjacent slab objects corrupted → kernel memory manipulation

2.3 The Patch

/* Fixed code — bounds check before cache copy */
static void nfsd4_store_cache_entry(struct nfsd4_compoundres *resp)
{
    size_t encoded_len = resp->cstate.current_response_len;

    /* Patch: skip cache payload if response exceeds buffer */
    if (encoded_len > sizeof(resp->replay_cache.inline_buf)) {
        /* Cache status but skip payload */
        /* Client already received correct response on original request */
        resp->replay_cache.has_payload = false;
        return;
    }

    memcpy(resp->replay_cache.inline_buf,
           encoded_response, encoded_len);
    resp->replay_cache.has_payload = true;
}

The fix is simple but effective: if the encoded response exceeds the buffer size, skip the replay cache payload. Since the client already received the correct response on the original request, the replay cache isn't strictly necessary.

3. Model Generation Gap: Non-Linear Capability Growth

Another critical finding is the dramatic capability gap between model generations:

Model	Release	Vulnerabilities Found	Linux Kernel NFS	Firefox
Claude Opus 4.6	Dec 2025	500+	Found	22 in 2 weeks
Claude Opus 4.1	Apr 2025	Very few	Not found	Very few
Claude Sonnet 4.5	Jun 2025	Very few	Not found	Very few

This reveals two key insights. First, LLM security research capabilities are improving non-linearly — capabilities jumped by orders of magnitude in just 8 months. Second, current security processes may not keep pace with AI discovery speed. The industry-standard 90-day disclosure window may be inadequate when LLMs can mass-discover vulnerabilities in hours to days.

4. Impact on the Linux Kernel Security Ecosystem

Since Claude Opus 4.6's emergence, Linux kernel maintainers have experienced a dramatic increase in vulnerability reports:

Period	Weekly Reports	Valid Report Rate	Notes
Pre-2025	2-3	40-60%	Manual audit-based
Post-Feb 2026	35-70 (5-10/day)	80%+	LLM-driven automated discovery

Greg Kroah-Hartman (Linux kernel stable branch maintainer) noted "conditions changed about a month ago," and Willy Tarreau confirmed reports escalated from 2-3/week to 5-10/day, "with most of them being correct." Carlini himself has hundreds of unvalidated crashes awaiting human verification.

4.1 Confirmed Linux Kernel Vulnerabilities

Subsystem	Vulnerability Type	Severity	Age
NFS (CVE-2026-31402)	Heap buffer overflow	Critical	23 years (2003~)
io_uring	Memory corruption	High	Several years
futex	Race condition	High	Several years
ksmbd	Memory corruption	High	Several years
Other	Undisclosed	Medium-High	Under verification

5. Anthropic's Safeguards: Cyber-Specific Probe System

With great capability comes the need for abuse prevention. Anthropic introduced a new cyber security detection layer alongside Opus 4.6:

# Anthropic Cyber Probe Architecture (conceptual)
detection_layer:
  probes:
    - type: activation_probe
      description: "Measures internal activation patterns during response generation"
      scope: "Detect exploit code generation"
    - type: cyber_specific_probe
      description: "Domain-specific probes for cybersecurity"
      scope: "Detect malicious vulnerability research patterns"
  enforcement:
    - real_time_intervention: true
    - traffic_blocking: true
  limitations:
    - note: "May create friction for legitimate security research"

The core mechanism uses activation probes that measure internal activation patterns as the model generates responses, detecting malicious vulnerability research patterns in real-time.

6. DevSecOps Response Strategy

6.1 Integrating AI Security Audits into CI/CD

# .github/workflows/ai-security-audit.yml
name: AI Security Audit
on:
  pull_request:
    paths:
      - 'src/**/*.c'
      - 'src/**/*.go'
      - 'src/**/*.py'

jobs:
  llm-security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get changed files
        id: changed
        run: |
          echo "files=$(git diff --name-only origin/main...HEAD \
            | grep -E '\.(c|go|py|rs)$' | tr '\n' ' ')" >> $GITHUB_OUTPUT

      - name: AI-powered vulnerability scan
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          for file in ${{ steps.changed.outputs.files }}; do
            echo "=== Scanning: $file ==="
            python scripts/ai-security-scan.py \
              --file "$file" \
              --model claude-sonnet-4-6 \
              --focus "memory-safety,injection,race-condition" \
              --output reports/security-${{ github.sha }}.json
          done

6.2 Defensive Code Patterns

The key lesson from CVE-2026-31402 is the importance of bounds checking — especially when copying variable-length data into fixed-size buffers:

/* Safe buffer copy patterns */

/* BAD: No bounds check */
void unsafe_copy(char *dst, const char *src, size_t src_len) {
    memcpy(dst, src, src_len);  /* Overflow possible */
}

/* GOOD: Bounds check included */
int safe_copy(char *dst, size_t dst_size,
              const char *src, size_t src_len) {
    if (src_len > dst_size) {
        pr_warn("buffer overflow prevented: %zu > %zu\n",
                src_len, dst_size);
        return -EOVERFLOW;
    }
    memcpy(dst, src, src_len);
    return 0;
}

In Rust, the ownership system prevents buffer overflows at compile time:

fn safe_encode(buffer: &mut [u8; 112], data: &[u8]) -> Result<(), Error> {
    if data.len() > buffer.len() {
        return Err(Error::BufferTooSmall {
            needed: data.len(),
            available: buffer.len(),
        });
    }
    buffer[..data.len()].copy_from_slice(data);
    Ok(())
}

6.3 Immediate Action Checklist

Priority	Action	Tool/Method	Timeline
P0	Check NFS service exposure and patch kernel	`cat /proc/fs/nfsd/versions`	Immediately
P0	Test with ASan/MSan-enabled kernel builds	KASAN, KMSAN	Within 1 week
P1	Add static analysis tools to CI/CD	CodeQL, Semgrep, Coverity	Within 2 weeks
P1	Evaluate memory-safe language (Rust) adoption	Rust for Linux project	Quarterly plan
P2	Build AI-powered security scan pipeline	Claude API + CI integration	Within quarter
P2	Review vulnerability disclosure process (90-day)	Org security policy	Within quarter

7. Industry Implications and What's Next

7.1 The 90-Day Disclosure Window Under Pressure

Anthropic's paper questions whether the industry-standard 90-day responsible disclosure period is adequate in the LLM era. If Claude Opus 4.6 can mass-discover vulnerabilities in hours, attackers can too. The entire patch cycle and disclosure timeline needs industry-wide reconsideration.

7.2 Concurrent Vulnerabilities: CrackArmor and Kyverno SSRF

April 2026 has seen multiple critical vulnerabilities surface simultaneously. CrackArmor (9 AppArmor flaws since 2017) enables root access and container escape on 12M+ Linux systems. Kyverno SSRF (CVE-2026-4789) allows namespace administrators to bypass RBAC via SSRF to Kyverno's pod network stack.

7.3 Memory-Safe Language Transition Accelerating

Vulnerabilities like CVE-2026-31402 — a classic C memory management bug — strengthen the case for Rust for Linux. Fixed-size buffer overflows from variable-length data would be caught at compile time with Rust's ownership system.

8. Conclusion: The New Role of Security Teams

AI-driven vulnerability discovery is no longer theoretical — it's production-ready. The security team's role is shifting from "finding vulnerabilities" to "validating, prioritizing, and patching vulnerabilities found by AI."

Three immediate actions: First, check NFS service exposure and patch your kernels. Second, add static analysis and memory safety checks to your CI/CD pipelines. Third, review whether your organization's vulnerability disclosure and response processes can keep pace with AI discovery speed. In an era where LLMs find zero-days in hours, the 90-day disclosure window and monthly patch cycles deserve fundamental re-examination.

This article was written with AI assistance (Claude Opus 4.6, Anthropic). Technical facts were cross-verified against original sources. | ManoIT Tech Blog

Originally published at ManoIT Tech Blog.

Complete Guide to Kubernetes 1.36: DRA GA, OCI VolumeSource, MutatingAdmissionPolicy, and Production Upgrade Checklist

daniel jeong — Wed, 15 Apr 2026 00:24:51 +0000

Complete Guide to Kubernetes 1.36 — DRA GA, OCI VolumeSource, and MutatingAdmissionPolicy Usher in a New Era for AI Workloads and Security

Kubernetes v1.36 ships on April 22, 2026. This release brings Dynamic Resource Allocation (DRA) to GA, OCI VolumeSource to Stable, and MutatingAdmissionPolicy to GA — major stabilizations that directly impact production environments. DRA's graduation in particular transforms how GPU and FPGA resources are natively scheduled, fundamentally changing the paradigm for AI/ML workload operations. At the same time, bold security cleanups like the permanent removal of gitRepo volumes and Portworx in-tree driver deletion tighten the cluster attack surface. This guide covers every key change in 1.36 with production-ready code examples and an upgrade checklist.

1. Release Overview and Change Matrix

v1.36 includes over 60 enhancements, with more than 10 graduating to GA. Workload-aware scheduling, introduced in 1.35 Timbernetes, has matured further, and meaningful progress spans security, storage, and networking.

Category	Feature	Status	Key Change
AI/GPU	Dynamic Resource Allocation (DRA)	GA	Native GPU/FPGA scheduling, 50% perf improvement
Storage	OCI VolumeSource	GA	Mount OCI registry artifacts directly as volumes
Security/Policy	MutatingAdmissionPolicy (MAP)	GA	Declarative CEL-based mutation, no webhook server
Security	Fine-grained kubelet API Authorization	GA	Per-endpoint RBAC on kubelet access
Storage	Volume Group Snapshot	GA	Atomic multi-volume snapshots via CSI drivers
Storage	SELinux Mount Relabeling	GA	Mount-time labeling replaces recursive relabeling
DX	kubectl kuberc	Beta	Separate user preferences and aliases into a dedicated file
Removal	gitRepo Volume	Removed	Permanent disable — root code execution vulnerability
Removal	Portworx In-tree Driver	Removed	Must migrate to CSI driver
Deprecation	Service .spec.externalIPs	Deprecated	CVE-2020-8554 MITM risk, full removal in v1.43

2. Dynamic Resource Allocation (DRA) GA — A Game Changer for AI Workload Scheduling

DRA was first introduced as alpha in Kubernetes 1.26, underwent a complete redesign in 1.31, and has now graduated to GA in 1.36. It goes beyond the limitations of the existing Device Plugin interface, enabling declarative, attribute-based scheduling of hardware resources like GPUs, FPGAs, and network adapters through native Kubernetes APIs.

2.1 Core DRA Architecture

DRA uses three key API resources: ResourceClaim declares the resources a Pod needs, ResourceSlice advertises resources available on a node, and DeviceClass defines the type and attributes of resources. In 1.36, the scheduler plugin now splits ResourceSlice entries into shared and per-node categories, reducing Filter stage latency by approximately 50%.

# ResourceClaim — Request 2 GPUs
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata:
  name: gpu-claim
  namespace: ml-training
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: nvidia-gpu
      count: 2
      selectors:
      - cel:
          expression: "device.attributes['gpu.nvidia.com'].memory.isGreaterThan(quantity('40Gi'))"

# DeviceClass — NVIDIA GPU class definition
apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: nvidia-gpu
spec:
  selectors:
  - cel:
      expression: "device.driver == 'gpu.nvidia.com'"
  config:
  - opaque:
      driver: gpu.nvidia.com
      parameters:
        apiVersion: gpu.nvidia.com/v1
        kind: GpuConfig
        sharing:
          strategy: TimeSlicing
          timeSlicingConfig:
            replicas: 4

2.2 Using DRA in Pods

# AI inference Pod using DRA
apiVersion: v1
kind: Pod
metadata:
  name: llm-inference
  namespace: ml-training
spec:
  containers:
  - name: inference
    image: vllm/vllm-openai:latest
    command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]
    args: ["--model", "meta-llama/Llama-3.3-70B-Instruct"]
    resources:
      claims:
      - name: gpu
        request: gpu
  resourceClaims:
  - name: gpu
    resourceClaimName: gpu-claim

2.3 New DRA Features in 1.36

Beyond DRA GA, several related improvements ship in 1.36. Device Taints and Tolerations (Beta) lets you taint specific devices to exclude GPUs under maintenance from scheduling. ResourcePoolStatusRequest API (Alpha) is a new API that queries available devices per pool before submitting workloads. DRA Admin Access also graduates to GA, enabling cluster administrators to manage ResourceClaims centrally.

3. OCI VolumeSource GA — Beyond Container Images to OCI Artifacts as Volumes

OCI VolumeSource was introduced as alpha in 1.31 and has graduated to GA in 1.36. This feature mounts artifacts stored in OCI registries (config files, ML model weights, static data) directly as Pod volumes. Previously, such data had to be baked into container images or downloaded via initContainers — now it can be declaratively mounted.

# Mounting OCI artifacts as volumes
apiVersion: v1
kind: Pod
metadata:
  name: ml-model-server
spec:
  containers:
  - name: server
    image: myregistry.io/inference-server:v2.1
    volumeMounts:
    - name: model-weights
      mountPath: /models/llama-3.3
      readOnly: true
    - name: config
      mountPath: /etc/app-config
      readOnly: true
  volumes:
  - name: model-weights
    image:
      reference: myregistry.io/ml-models/llama-3.3-70b:latest
      pullPolicy: IfNotPresent
  - name: config
    image:
      reference: myregistry.io/configs/inference-config:v1.2
      pullPolicy: Always

This is especially powerful for AI/ML workloads. Managing model weights as OCI artifacts means model updates no longer require rebuilding the entire container image — just swap the model artifact. The existing OCI registry infrastructure (caching, mirroring, access control) can be leveraged as-is.

4. MutatingAdmissionPolicy GA — Declarative Resource Mutation Without Webhooks

MutatingAdmissionPolicy (MAP) is the mutation counterpart to ValidatingAdmissionPolicy. It modifies resources using CEL (Common Expression Language) expressions without external webhook servers. Existing MutatingWebhookConfiguration required maintaining separate servers and could impact cluster operations during network failures. MAP runs inside kube-apiserver, eliminating these issues entirely.

# MutatingAdmissionPolicy — Inject default resource limits on all Pods
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: inject-default-resources
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      resources: ["pods"]
      operations: ["CREATE"]
  mutations:
  - patchType: ApplyConfiguration
    applyConfiguration:
      expression: |
        Object{
          spec: Object.spec{
            containers: object.spec.containers.map(c,
              Object.spec.containers{
                resources: Object.spec.containers.resources{
                  limits: c.resources.?limits.orValue({}).merge({
                    "memory": c.resources.?limits.orValue({}).?memory.orValue("512Mi"),
                    "cpu": c.resources.?limits.orValue({}).?cpu.orValue("500m")
                  })
                }
              }
            )
          }
        }

MAP supports two mutation modes: Server-Side Apply merge strategy and JSON Patch. With Server-Side Apply, mutations merge naturally with existing fields without overwriting user-specified values. Simple mutation logic previously handled by external solutions like OPA Gatekeeper or Kyverno can now be moved to native Kubernetes.

5. Security Hardening — gitRepo Removal, kubelet Authorization, SELinux Mount

5.1 gitRepo Volume Permanent Removal (KEP-5040)

The gitRepo volume, deprecated since v1.11, has been permanently disabled in 1.36. This volume type cloned Git repositories into Pods but carried a critical security vulnerability that allowed arbitrary code execution as root on nodes. It can no longer be re-enabled via Feature Gate — any workloads using it must be migrated before upgrading.

# gitRepo replacement — initContainer + git-sync pattern
apiVersion: v1
kind: Pod
metadata:
  name: app-with-git
spec:
  initContainers:
  - name: git-clone
    image: alpine/git:latest
    command: ['git', 'clone', '--depth=1', 'https://github.com/org/repo.git', '/repo']
    volumeMounts:
    - name: git-data
      mountPath: /repo
  containers:
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: git-data
      mountPath: /app/data
      readOnly: true
  volumes:
  - name: git-data
    emptyDir: {}

5.2 Fine-grained kubelet API Authorization (GA)

Fine-grained kubelet API authorization has graduated to GA. Previously, a compromised kubelet credential granted full access to the kubelet API on that node. Starting in 1.36, endpoint-level RBAC can be applied to prevent a compromised node credential from escalating to full kubelet access.

5.3 SELinux Mount Relabeling (GA)

Volume security labeling on SELinux-enforcing systems has been dramatically improved. Instead of recursively traversing every file on a volume to change labels, 1.36 applies them all at once at mount time via mount -o context=XYZ. Pod startup times that previously took minutes on large volumes are now reduced to milliseconds.

# SELinux labeling policy configuration
apiVersion: v1
kind: Pod
metadata:
  name: selinux-optimized
spec:
  securityContext:
    seLinuxOptions:
      level: "s0:c123,c456"
    seLinuxChangePolicy: MountBased
  containers:
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: my-pvc

6. Developer Experience and Notable Features

6.1 kubectl kuberc (Beta)

kuberc separates kubectl user preferences and aliases into a dedicated file. Custom aliases, default output formats, and column settings can now be managed independently in ~/.kube/kuberc.

# ~/.kube/kuberc — kubectl user preferences
apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
aliases:
- name: get-pods-wide
  command: get
  args: ["pods", "-o", "wide"]
  flags:
    all-namespaces: "true"
- name: logs-tail
  command: logs
  flags:
    tail: "100"
    follow: "true"

6.2 ARCH Column Added

kubectl get node -o wide now includes an ARCH column, making it easy to identify node architectures in mixed ARM64/AMD64 clusters at a glance.

# kubectl get node -o wide output in 1.36
kubectl get nodes -o wide

NAME          STATUS   ROLES    AGE   VERSION   INTERNAL-IP    OS-IMAGE       KERNEL         ARCH
node-arm-01   Ready    worker   45d   v1.36.0   10.0.1.10     Bottlerocket    6.1.94         arm64
node-amd-01   Ready    worker   45d   v1.36.0   10.0.1.20     Bottlerocket    6.1.94         amd64
node-gpu-01   Ready    gpu      10d   v1.36.0   10.0.1.30     Ubuntu 22.04    6.5.0-44       amd64

6.3 Service .spec.externalIPs Deprecation (KEP-5707)

Service.spec.externalIPs has been officially deprecated in v1.36. This field posed a security risk due to CVE-2020-8554, which enabled man-in-the-middle attacks on cluster traffic. Full removal is planned for v1.43 — if you're currently using it, plan migration to LoadBalancer Service, NodePort, or Gateway API.

7. v1.36 Upgrade Checklist — Production Migration Guide

Before upgrading production clusters to 1.36, verify the following items:

#	Check Item	Command / Method	Risk
1	gitRepo volume usage	`kubectl get pods -A -o json \	jq '.items[].spec.volumes[]? \
2	Portworx in-tree driver usage	{% raw %}`kubectl get pv -o json \	jq '.items[] \
3	externalIPs Services	{% raw %}`kubectl get svc -A -o json \	jq '.items[] \
4	Non-canonical IP/CIDR formats	Audit IaC tool IP generation logic	Warning
5	Audit log configuration review	Check {% raw %}`--audit-log-maxsize`, `--audit-log-maxage` flags	Low
6	Flex Volume usage (kubeadm)	`find /usr/libexec/kubernetes/kubelet-plugins -type f`	Warning
7	SELinux policy compatibility	Verify `seLinuxChangePolicy` in mixed privileged/unprivileged Pod environments	Medium

# Scan all major risk factors at once
echo "=== gitRepo Volume Scan ==="
kubectl get pods -A -o json | jq -r '
  .items[] |
  select(.spec.volumes[]?.gitRepo != null) |
  "\(.metadata.namespace)/\(.metadata.name)"
' 2>/dev/null || echo "No gitRepo volumes found ✅"

echo ""
echo "=== Portworx In-tree PV Scan ==="
kubectl get pv -o json | jq -r '
  .items[] |
  select(.spec.portworxVolume != null) |
  .metadata.name
' 2>/dev/null || echo "No Portworx in-tree PVs found ✅"

echo ""
echo "=== externalIPs Service Scan ==="
kubectl get svc -A -o json | jq -r '
  .items[] |
  select(.spec.externalIPs != null and (.spec.externalIPs | length > 0)) |
  "\(.metadata.namespace)/\(.metadata.name): \(.spec.externalIPs)"
' 2>/dev/null || echo "No externalIPs Services found ✅"

8. Conclusion — What 1.36 Means and How to Prepare

Kubernetes 1.36 delivers the most meaningful progress across two axes: native AI workload support and security streamlining. DRA's GA graduation moves GPU resource scheduling from Device Plugin's integer-based constraints to attribute-based declarative scheduling. OCI VolumeSource GA decouples ML model weight deployment from container image builds, improving operational agility. MutatingAdmissionPolicy GA removes the operational burden of webhook servers, enabling policy management through declarations rather than code.

Ahead of the April 22 official release, we recommend testing the RC (Release Candidate) in staging environments first and using the upgrade checklist above to pre-audit gitRepo, Portworx, and externalIPs usage. If you're running AI/ML workloads, consider piloting DRA and OCI VolumeSource together.

References: Kubernetes v1.36 Sneak Peek (Official Blog), CHANGELOG-1.36.md (GitHub), Kubernetes 1.36: GA Features, Removals & Upgrade Guide (Kloia)

Originally published at ManoIT Tech Blog.

Complete Guide to Dagger v0.20 — Beyond YAML Pipelines with CI/CD as Code, Dang Scripting, and Production Deployment

daniel jeong — Tue, 14 Apr 2026 00:16:00 +0000

Complete Guide to Dagger v0.20 — Beyond YAML Pipelines with CI/CD as Code: Dang Scripting, Daggerverse Modules, and Production Deployment Strategies

In 2026, CI/CD pipelines are still trapped in YAML hell. GitHub Actions' .github/workflows/*.yml, GitLab CI's .gitlab-ci.yml, Jenkins' Jenkinsfile — different syntax per platform, no local testing, and vendor lock-in. Dagger, created by Docker founder Solomon Hykes, is a container-native automation engine that lets you write CI/CD pipelines in programming languages and run them identically anywhere inside containers.

v0.20, released in February 2026, introduced the dedicated Dang scripting language, a completely redesigned terminal UI, and a logs-based progress mode. In OpenMeter's real-world case, a pipeline that took 25 minutes on GitHub Actions alone was reduced to 5 minutes (5x faster, 50% cost reduction) with Dagger Cloud caching. This guide covers Dagger's architecture, SDK ecosystem, Daggerverse modules, CI integration patterns, Kubernetes production deployment, and comparison with existing CI/CD tools.

Dagger Architecture — DAG-Based Container Execution Engine

Core Structure: Engine → GraphQL API → SDK

Understanding Dagger's architecture requires distinguishing three layers. The Dagger Engine is a core runtime combining an execution engine, universal type system, data layer, and module system. It runs on any OCI-compatible system. Each language SDK (Go, Python, TypeScript, etc.) doesn't execute pipelines directly — instead, it sends pipeline definitions to the Dagger GraphQL API, which triggers the Engine.

┌─────────────────────────────────────────────────────────────┐
│  Your Code (Go / Python / TypeScript / Dang)                │
│  └── SDK: Converts pipeline definitions to GraphQL requests │
├─────────────────────────────────────────────────────────────┤
│  Dagger GraphQL API                                         │
│  └── Parses pipeline definitions into a DAG                 │
├─────────────────────────────────────────────────────────────┤
│  Dagger Engine                                              │
│  ├── Executes DAG operations concurrently                   │
│  ├── Intermediate artifacts: JIT build + incremental cache  │
│  ├── Container sandbox: all ops run inside containers       │
│  └── Auto-generates OpenTelemetry traces                    │
└─────────────────────────────────────────────────────────────┘

When the Engine receives an API request, it computes a DAG (Directed Acyclic Graph) of low-level operations and processes them concurrently. Intermediate artifacts are built just-in-time, and every operation is incremental by default. Once all operations resolve, the Engine returns results to your program.

CI-Agnostic Design — "Write Once, Run Anywhere"

Dagger's core design principle is CI-agnostic. Your pipelines aren't tied to any platform or provider. GitHub Actions, GitLab CI, Jenkins, CircleCI, Azure Pipelines, or your local terminal — the same pipeline logic works everywhere.

Key Value: This fundamentally solves "works on my machine" problems. A pipeline tested locally with dagger call build runs identically on CI runners. Local debugging — impossible with YAML-based CI — is now a reality.

v0.20 Key Features — Dang, Native TUI, Cache Management

Dang: Dagger's Dedicated Scripting Language

Introduced in v0.20.2, Dang is a scripting language designed specifically for Dagger. It runs on a native runtime built into the Engine and introspects the Engine schema at runtime, making every Dagger type a native language type. No codegen, near-instant startup, and concise syntax optimized for AI-assisted development.

# Build pipeline in Dang — much more concise than Go SDK
container |
  from "golang:1.22-alpine" |
  with-exec ["apk", "add", "git"] |
  with-directory "/src" (host | directory ".") |
  with-workdir "/src" |
  with-exec ["go", "test", "./..."] |
  with-exec ["go", "build", "-o", "/app", "."]

Dang modules run directly inside the Engine, eliminating the usual module loading overhead (container startup, process coordination). This is particularly valuable for workflows where AI agents generate and modify pipelines.

Redesigned Native TUI

v0.20.2 completely rebuilt the interactive TUI. Instead of the previous fixed viewport, it uses the terminal's native scrollback — free scrolling, link clicking, and text selection. A separate logs-based progress mode (--progress=logs) was also added for easier CI log scanning.

Improved Manual Cache Management

For teams with automatic GC disabled, explicit space threshold-based cache pruning was introduced. Per-call overrides are available for max used space, reserved space, minimum free space, and target space.

# Cache pruning options
dagger call build \
  --cache-max-used-space=20GB \
  --cache-reserved-space=5GB \
  --cache-min-free-space=10GB

SDK Ecosystem — Write Pipelines in 8 Languages

Dagger auto-generates SDKs from its API schema, providing full type safety and editor support (autocomplete, linting) for each language.

SDK	Maturity	Latest Version	Highlights
Go	GA	v0.20.3	Most mature, official reference implementation
Python	GA	v0.20.3	async/await, typing support
TypeScript	GA	v0.20.3	Deno/Bun support, ESM default
Rust	GA	v0.20.3	Ideal for system-level pipelines
PHP	Beta	-	Laravel/Symfony ecosystem integration
Java	Beta	-	For Maven/Gradle projects
.NET	Beta	-	C# pipeline authoring
Elixir	Beta	-	For Phoenix projects

TypeScript SDK Example — Build → Test → Publish

// dagger/src/index.ts — Full-stack CI pipeline with TypeScript SDK
import { dag, Container, Directory, object, func } from "@dagger.io/dagger"

@object()
class CiPipeline {

  @func()
  async build(source: Directory): Promise<Container> {
    return dag
      .container()
      .from("node:22-alpine")
      .withDirectory("/app", source)
      .withWorkdir("/app")
      .withExec(["npm", "ci"])
      .withExec(["npm", "run", "build"])
  }

  @func()
  async test(source: Directory): Promise<string> {
    const ctr = await this.build(source)
    return ctr
      .withExec(["npm", "run", "test", "--", "--coverage"])
      .stdout()
  }

  @func()
  async publish(
    source: Directory,
    registry: string,
    tag: string
  ): Promise<string> {
    const built = await this.build(source)
    return built
      .withEntrypoint(["node", "dist/main.js"])
      .publish(`${registry}:${tag}`)
  }
}

# Run locally — identical results to CI
dagger call test --source=.

# Run in GitHub Actions — same command
dagger call publish --source=. --registry=ghcr.io/myorg/myapp --tag=v1.2.3

Go SDK Example — Multi-Architecture Build

// dagger/main.go — Multi-arch container build with Go SDK
package main

import (
    "context"
    "dagger/ci/internal/dagger"
)

type Ci struct{}

func (m *Ci) BuildMultiArch(
    ctx context.Context,
    source *dagger.Directory,
) (*dagger.Container, error) {
    platforms := []dagger.Platform{
        "linux/amd64",
        "linux/arm64",
    }

    platformVariants := make([]*dagger.Container, len(platforms))
    for i, platform := range platforms {
        platformVariants[i] = dag.Container(dagger.ContainerOpts{
            Platform: platform,
        }).
            From("golang:1.22-alpine").
            WithDirectory("/src", source).
            WithWorkdir("/src").
            WithExec([]string{"go", "build", "-o", "/app", "."})
    }

    return dag.Container().
        Publish(ctx, "ghcr.io/myorg/app:latest",
            dagger.ContainerPublishOpts{
                PlatformVariants: platformVariants,
            })
}

Daggerverse — 1,500+ Reusable Modules

Daggerverse serves as the central index for Dagger modules, similar to DockerHub's role for container images. Over 1,500 public modules are registered, hosted on GitHub public repositories. Dagger indexes modules — it doesn't host the code.

Category	Key Modules	Purpose
Build	golang, node, python, rust	Standardized language build steps
Test	pytest, vitest, go-test	Test runner integration
Security	trivy, grype, cosign	Image scanning + signing
Deploy	helm, kubectl, terraform	Infrastructure provisioning
AI	daggie, openai, ollama	AI agent pipelines
Notifications	slack, discord, github-comment	Pipeline result notifications

# Using Daggerverse modules — direct remote module calls
dagger call -m github.com/purpleclay/daggerverse/trivy@v0.5.0 \
  scan --source=. --severity=HIGH,CRITICAL

# Production tip: Always pin versions for remote modules
# ✅ github.com/user/module@v1.2.3
# ❌ github.com/user/module (latest auto — not recommended)

Production Warning: Always pin specific versions when using Daggerverse modules in production to prevent unexpected changes. Manage internal modules in a monorepo subdirectory.

CI Integration Patterns — GitHub Actions, GitLab CI, Jenkins

GitHub Actions + Dagger

Dagger replaces GitHub Actions' YAML definitions while keeping the runner infrastructure. YAML serves only as a minimal wrapper for Dagger calls.

# .github/workflows/ci.yml — Dagger + GitHub Actions
name: CI
on:
  push:
    branches: [main]
  pull_request:

jobs:
  dagger:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Dagger Pipeline
        uses: dagger/dagger-for-github@v8
        with:
          version: "0.20.3"
          verb: call
          args: test --source=.
      - name: Build and Push
        if: github.ref == 'refs/heads/main'
        uses: dagger/dagger-for-github@v8
        with:
          version: "0.20.3"
          verb: call
          args: publish --source=. --registry=ghcr.io/${{ github.repository }} --tag=${{ github.sha }}

GitLab CI + Dagger

# .gitlab-ci.yml — Dagger + GitLab CI
stages:
  - ci

dagger:
  stage: ci
  image: alpine:latest
  services:
    - docker:dind
  variables:
    DOCKER_HOST: tcp://docker:2376
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - apk add --no-cache curl
    - curl -fsSL https://dl.dagger.io/dagger/install.sh | sh
    - export PATH=$HOME/.dagger/bin:$PATH
  script:
    - dagger call test --source=.
    - dagger call publish --source=. --registry=$CI_REGISTRY_IMAGE --tag=$CI_COMMIT_SHA

Dagger Cloud Checks — Managed CI

Dagger Cloud connects to your Git provider and automatically runs dagger check on every change. Auto-scaled on cloud engines — no YAML, no vendor syntax, no orchestration layer. Through a partnership with Depot, managed Dagger Powered GitHub Actions runners are also available with pre-installed Dagger, automatic persistent layer caching, and multi-architecture support.

Kubernetes Production Deployment

DaemonSet Pattern

In Kubernetes, the Dagger Engine deploys as a DaemonSet — one Engine instance per node for maximum resource efficiency and local cache reuse.

# dagger-engine-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dagger-engine
  namespace: ci
spec:
  selector:
    matchLabels:
      app: dagger-engine
  template:
    metadata:
      labels:
        app: dagger-engine
    spec:
      containers:
        - name: dagger-engine
          image: registry.dagger.io/engine:v0.20.3
          securityContext:
            privileged: true
          ports:
            - containerPort: 8080
              name: api
          volumeMounts:
            - name: dagger-cache
              mountPath: /var/lib/dagger
          resources:
            requests:
              cpu: "2"
              memory: "4Gi"
            limits:
              cpu: "4"
              memory: "8Gi"
      volumes:
        - name: dagger-cache
          hostPath:
            path: /var/lib/dagger
            type: DirectoryOrCreate

Actions Runner Controller (ARC) Integration

For GitHub Actions with Kubernetes runners, combine ARC with Dagger. ARC usage grew 45% year-over-year in 2026, making it the standard for ephemeral, auto-scaling runners.

Comparison with Existing CI/CD Tools

Aspect	Dagger	GitHub Actions	Jenkins	GitLab CI
Pipeline Definition	Code (Go/TS/Py)	YAML	Groovy DSL	YAML
Local Execution	Full support	act (limited)	No	No
Vendor Lock-in	None	GitHub	None	GitLab
Caching	Auto incremental	Manual config	Plugins	Manual config
Debugging	OTel traces	Logs only	Blue Ocean	Logs only
Module Ecosystem	1,500+	20K+ Marketplace	1,800+ plugins	Limited built-in
K8s Native	DaemonSet	ARC	Agent Pod	Runner
AI Integration	Dang + Daggie	Copilot	Limited	Duo

Important: Dagger is not a replacement for GitHub Actions — it's complementary. Keep your CI runner infrastructure (GitHub Actions, GitLab CI, etc.) and replace the YAML logic with Dagger functions. "Dagger replaces YAML, not your CI."

OpenTelemetry Integration — Pipeline Observability

Every Dagger operation automatically generates OpenTelemetry traces with granular logs and metrics, viewable in terminal or web interfaces.

# Configure OpenTelemetry export
export OTEL_EXPORTER_OTLP_ENDPOINT=http://jaeger:4318

# Run pipeline — traces sent automatically
dagger call build --source=.

# Visualize every pipeline step in Jaeger UI
# See execution time, cache hits/misses, dependency graphs

Combined with Prometheus + Grafana, you can monitor pipeline execution time trends, cache hit rates, and failure rates on dashboards — deep trace-based analysis that was impossible with log-only YAML CI.

Performance Benchmarks — Real-World Data

OpenMeter Case Study (Published Data)

Configuration	Build Time	Cost	Improvement
GitHub Actions alone	25 min	Baseline	-
Dagger + Cloud caching	10 min	-30%	2.5x
Dagger + Cloud + Fast Runner	5 min	-50%	5x

The key factor is incremental caching. The Dagger Engine caches each DAG node independently, re-executing only changed portions — fundamentally different from traditional CI that runs entire workflows from scratch.

GitHub Actions Runner Price Reduction

In January 2026, GitHub reduced runner pricing by up to 39%. The new 4-vCPU "Standard" runner costs the same as the 2024 2-vCPU runner. Combining these runners with Dagger enables 5x performance at half the cost.

Production Adoption Checklist

Phase	Check Item	Recommendation
1. Pilot	Apply Dagger to a single project	Run parallel with existing YAML, compare results
2. SDK Selection	Use your team's primary language SDK	Recommend GA SDKs: Go/TS/Python
3. Module Management	Pin external module versions, monorepo for internal	Supply chain security: Cosign signature verification
4. Caching	Dagger Cloud caching or self-hosted cache	Per-node hostPath or PVC
5. Observability	Configure OTel trace collection	Jaeger/Tempo + Grafana dashboard
6. Security	Minimize privileged containers	Evaluate Sysbox or rootless mode
7. Rollout	Team-wide adoption after pilot success	Build internal module library

Conclusion — The Next Step for CI/CD

Dagger's proposition is clear: write CI/CD pipelines in code (not YAML), run them identically locally and in CI, and maximize speed with container-based incremental caching. At cdCon 2026, AI-powered pipeline optimization, platform engineering, and software supply chain security are key themes — and Dagger shows strength in all three areas.

The emergence of the Dang scripting language signals a future where AI agents create and modify pipelines. Its design — introspecting the Engine schema without codegen — is an interface optimized for LLMs to understand and manipulate pipelines. In the evolution from "humans writing YAML" to "AI agents orchestrating pipelines as code," Dagger is the most compelling runtime candidate.

You don't need to abandon GitHub Actions or GitLab CI today. Keep the YAML wrapper and gradually migrate pipeline logic to Dagger functions — that's the most practical adoption strategy. Start with a pilot on one project, and share the build time reduction and local debugging experience with your team. Once "works on my machine" problems disappear, going back to YAML becomes very difficult.

This article was written with AI assistance (Claude Opus 4.6). Technical accuracy was cross-verified against official documentation, release notes, and published case study data. For the latest version changes, check the Dagger Official Changelog.

Originally published at ManoIT Tech Blog.

Complete Guide to Google Gemma 4 — Apache 2.0 Open Model Benchmark: PLE Architecture to Ollama Local Deployment

daniel jeong — Mon, 13 Apr 2026 00:35:41 +0000

Complete Guide to Google Gemma 4 — The New Open Model Benchmark Under Apache 2.0, from PLE Architecture to Ollama Local Deployment

In April 2026, Google DeepMind released Gemma 4 — a family of open-weight models built on Gemini 3 research and distributed under the Apache 2.0 license. No MAU limits, no commercial restrictions. The 31B Dense model scores 89.2% on AIME 2026 math, 80.0% on LiveCodeBench v6 coding, and 84.3% on GPQA Diamond science — competing with 400B-class proprietary models on a parameter-efficiency basis.

Four key innovations stand out. First, Per-Layer Embeddings (PLE) architecture enables the E2B edge model to achieve 5.1B-class quality with only 2.3B active parameters. Second, all models support native multimodal input (vision + audio). Third, Function Calling is trained into the model from the ground up, optimized for multi-turn agentic workflows. Fourth, up to 256K context window handles entire codebases and long documents in a single prompt.

This guide covers Gemma 4's architectural innovations (PLE, MoE, alternating attention), model specifications and benchmark comparisons, the competitive landscape against Llama 4 and Qwen 3.5, practical local deployment with Ollama/vLLM, and fine-tuning strategies for production use.

The Gemma 4 Model Family — Four Models, Three Architectures

Full Specification Overview

Gemma 4 isn't a single model but a family of four models with distinct hardware targets and architectures. All share Gemini 3's training data and techniques but employ different strategies for inference efficiency.

Model	Total Params	Active Params	Architecture	Context	Multimodal
Gemma 4 31B	31B	31B	Dense	256K	Vision
Gemma 4 26B MoE	25.2B	3.8B	MoE (128E/8A+1S)	256K	Vision
Gemma 4 E4B	~5B	~4B	Dense + PLE	128K	Vision + Audio
Gemma 4 E2B	~5.1B	~2.3B	Dense + PLE	128K	Vision + Audio

The 26B MoE model uses 128 small experts with 8 active per token plus one always-on shared expert. Despite 25.2B total parameters, only 3.8B are activated during inference — achieving 97% of 31B Dense quality at roughly 8x less compute. This contrasts sharply with Llama 4 Scout's 16 large expert approach.

Apache 2.0 — Why the License Matters

The license change from Google's proprietary license to Apache 2.0 is as significant as the technical innovations. This means no MAU limits, full commercial freedom, fine-tuning with redistribution, and embedding in cloud services. While Llama 4's community license restricts apps with 700M+ monthly users, Gemma 4 can be adopted without constraints from startups to hyperscalers.

Architecture Deep Dive — PLE, MoE, and Alternating Attention

Per-Layer Embeddings (PLE) — The Edge Model Innovation

PLE is the novel architecture powering Gemma 4's E2B and E4B edge models. Traditional transformers generate a token vector once at the input embedding layer, then pass it identically through all decoder layers. PLE inverts this paradigm by providing dedicated embedding vectors for each decoder layer.

Specifically, PLE adds a parallel, lower-dimensional conditioning pathway alongside the main residual stream. For each token, it combines a token-identity component (from an embedding lookup) and a context-aware component (a learned projection of the main embeddings) to generate per-layer vectors. Each decoder layer then modulates hidden states via a lightweight residual block after attention and feed-forward.

Because the PLE dimension is much smaller than the main hidden size, parameter cost is modest while layer-specific specialization improves dramatically. The E2B model achieves the representational depth of its full 5.1B parameter count with only 2.3B active parameters — enabling execution under 1.5GB RAM on mobile devices via LiteRT-LM.

# PLE Architecture Concept (Pseudocode)
class PLEDecoderLayer:
    def forward(self, hidden_states, ple_vectors):
        # 1. Standard attention + FFN (same as vanilla transformer)
        attn_out = self.attention(hidden_states)
        ffn_out = self.feed_forward(attn_out)

        # 2. PLE conditional modulation (novel addition)
        ple_signal = self.ple_residual_block(ple_vectors[self.layer_idx])

        # 3. Inject PLE signal into main stream
        output = ffn_out + ple_signal  # lightweight residual connection
        return output

class PLEEmbedding:
    def generate_per_layer_vectors(self, token_ids, main_embeddings):
        identity = self.token_embed_lookup(token_ids)      # fixed per-token
        context = self.context_projection(main_embeddings)  # context-dependent
        per_layer = self.layer_projection(identity + context)
        return per_layer  # [num_layers, low_dim]

Mixture of Experts (MoE) — The 128 Small Experts Strategy

The 26B MoE model's expert structure differs dramatically from other MoE models. While Llama 4 Scout uses 16 large experts, Gemma 4 employs 128 small experts + 1 shared expert, activating 8 per token with the shared expert always on.

Metric	Gemma 4 26B MoE	Llama 4 Scout
Expert count	128 + 1 shared	16
Active experts/token	8 + 1	1
Total parameters	25.2B	109B
Active parameters	3.8B	17B
Context length	256K	10M

The 128 small expert strategy enables finer-grained specialization — each expert covers a narrower knowledge domain, improving routing accuracy and maintaining high quality with fewer active parameters.

Alternating Attention — Balancing Efficiency and Long-Range Understanding

All Gemma 4 models use alternating attention, where decoder layers alternate between local sliding-window attention (512–1024 tokens) and global full-context attention. Sliding-window layers use standard RoPE, while global layers use Proportional RoPE to enable the 256K context window.

This design bypasses the O(n²) complexity of full attention. Most layers process only local windows quickly, while periodic global layers maintain long-range dependencies — keeping memory manageable even at 256K tokens.

Benchmark Deep Dive — Gemma 4 vs Llama 4 vs Qwen 3.5

Core Benchmark Results

Benchmark	Gemma 4 31B	Gemma 4 26B MoE	Gemma 4 E4B	Gemma 3 27B
Arena AI (text)	1452	1441	—	1365
AIME 2026 (math)	89.2%	88.3%	42.5%	—
LiveCodeBench v6	80.0%	77.1%	—	—
GPQA Diamond (science)	84.3%	82.3%	—	42.4%
Codeforces ELO	2150	—	—	110

The most striking number is the Codeforces ELO jump from 110 to 2150 — corresponding to an Expert-rated competitive programmer. GPQA Diamond nearly doubled from 42.4% to 84.3%, demonstrating massive improvements in graduate-level science reasoning.

Competitive Comparison

Metric	Gemma 4 31B	Llama 4 Scout	Qwen 3.5 27B
License	Apache 2.0	Community (700M MAU limit)	Apache 2.0
AIME 2026 math	89.2%	—	~49%
MMLU Pro	85.2%	—	86.1%
Context length	256K	10M	—
Multilingual	140+	—	201
Native audio	E2B/E4B	No	No
Native function calling	All models	Yes	Yes

Gemma 4 dominates in math/coding reasoning, Qwen 3.5 edges ahead in general knowledge (MMLU Pro) and multilingual, and Llama 4 Scout remains unmatched in ultra-long context (10M tokens).

Native Function Calling and Agent Workflows

Gemma 4's function calling isn't prompt engineering — it's built on FunctionGemma research and trained into the model, optimized for multi-turn agentic flows with multiple tools.

from google.adk import Agent, ToolDeclaration
import google.generativeai as genai

model = genai.GenerativeModel("gemma-4-31b-it")

tools = [
    genai.Tool(function_declarations=[
        genai.FunctionDeclaration(
            name="search_database",
            description="Search the user database for information",
            parameters={
                "type": "object",
                "properties": {
                    "query": {"type": "string", "description": "Search query"},
                    "limit": {"type": "integer", "description": "Result limit"}
                },
                "required": ["query"]
            }
        ),
        genai.FunctionDeclaration(
            name="send_notification",
            description="Send a notification to a user",
            parameters={
                "type": "object",
                "properties": {
                    "user_id": {"type": "string"},
                    "message": {"type": "string"},
                    "channel": {"type": "string", "enum": ["email", "slack", "sms"]}
                },
                "required": ["user_id", "message"]
            }
        )
    ])
]

chat = model.start_chat()
response = chat.send_message(
    "Find the 5 most recently registered users and send them a welcome message on Slack",
    tools=tools
)
# Gemma 4 automatically chains:
# 1. search_database(query="recent_users", limit=5)
# 2. Parses results, then for each user:
# 3. send_notification(user_id=..., message=..., channel="slack")

The synergy with MCP (Model Context Protocol) is particularly powerful — map MCP server tools to Gemma 4 Function Declarations and a locally-running agent seamlessly interacts with external services. Under Apache 2.0, you can embed such agents in commercial services without restrictions.

Local Deployment Guide — Ollama and vLLM

Getting Started with Ollama in 5 Minutes

Ollama is currently the simplest way to run Gemma 4 locally.

# 1. Install Ollama (macOS/Linux)
curl -fsSL https://ollama.com/install.sh | sh

# 2. Choose and run your model
ollama run gemma4:e2b    # Edge — mobile/laptop (8GB RAM enough)
ollama run gemma4:e4b    # Mid — desktop (16GB+ RAM recommended)
ollama run gemma4:26b    # MoE — workstation (18GB+ VRAM)
ollama run gemma4:31b    # Dense — server-class (24GB+ VRAM)

# 3. Use as OpenAI-compatible API server
ollama serve  # http://localhost:11434

# 4. Test with curl
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4:26b",
    "messages": [
      {"role": "user", "content": "Explain the difference between Kubernetes HPA and VPA"}
    ]
  }'

Production Serving with vLLM

For multi-user environments and production pipelines, vLLM provides continuous batching and paged attention for maximum throughput.

# Install vLLM (uv recommended — 10x faster than pip)
uv pip install vllm

# Single GPU (E4B)
vllm serve google/gemma-4-E4B-it \
  --host 0.0.0.0 --port 8000 --max-model-len 32768

# Multi-GPU tensor parallel (31B)
vllm serve google/gemma-4-31B-it \
  --tensor-parallel-size 2 --host 0.0.0.0 --port 8000

⚠️ Note: As of April 2026, a known vLLM bug drops Gemma 4 to ~9 tok/s on RTX 4090, while Ollama achieves 40–60 tok/s on the same hardware. Ollama is recommended for single-user setups; use vLLM only when multi-user serving is required.

Hardware Requirements

Model	Min VRAM/RAM	Recommended Hardware	Expected Speed
E2B	1.5GB RAM	Smartphone, Raspberry Pi	Mobile-optimized
E4B	8GB VRAM	Laptop, Apple Silicon	40-60 tok/s (Ollama)
26B MoE	18GB+ VRAM	RTX 4090, A6000	30-50 tok/s (Ollama)
31B Dense	24GB+ VRAM	RTX 4090, A100, H100	20-35 tok/s (Ollama)

Kubernetes Deployment Architecture

For production Gemma 4 deployment on Kubernetes, the vLLM + OpenAI-compatible API + LiteLLM router combination is effective.

# gemma4-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gemma4-moe-serving
  namespace: ai-inference
spec:
  replicas: 2
  selector:
    matchLabels:
      app: gemma4-moe
  template:
    metadata:
      labels:
        app: gemma4-moe
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest
        args:
        - --model=google/gemma-4-26B-MoE-it
        - --max-model-len=65536
        - --gpu-memory-utilization=0.9
        - --enable-chunked-prefill
        ports:
        - containerPort: 8000
        resources:
          limits:
            nvidia.com/gpu: 1
            memory: "40Gi"
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 120
          periodSeconds: 10
      nodeSelector:
        gpu-type: a100

Fine-Tuning and Customization

Apache 2.0 permits free redistribution of fine-tuned models. With LoRA/QLoRA, you can create domain-specific models on consumer GPUs.

from unsloth import FastLanguageModel

# Load with 4-bit quantization (saves VRAM)
model, tokenizer = FastLanguageModel.from_pretrained(
    model_name="google/gemma-4-E4B-it",
    max_seq_length=4096,
    load_in_4bit=True,  # QLoRA — works on RTX 3090
)

# Add LoRA adapter
model = FastLanguageModel.get_peft_model(
    model,
    r=16,
    target_modules=["q_proj", "k_proj", "v_proj", "o_proj",
                     "gate_proj", "up_proj", "down_proj"],
    lora_alpha=32,
    lora_dropout=0.05,
)

# Run SFT
from trl import SFTTrainer
trainer = SFTTrainer(
    model=model,
    tokenizer=tokenizer,
    train_dataset=your_dataset,
    dataset_text_field="text",
    max_seq_length=4096,
    args=TrainingArguments(
        per_device_train_batch_size=2,
        gradient_accumulation_steps=4,
        num_train_epochs=3,
        learning_rate=2e-4,
        fp16=True,
        output_dir="gemma4-finetuned",
    ),
)
trainer.train()

# Convert to GGUF for Ollama
model.save_pretrained_gguf("gemma4-custom", tokenizer, quantization_method="q4_k_m")

Practical Recommendations

Gemma 4 sets a new benchmark for open models. Here are key production recommendations:

Quick start: Run E4B locally with Ollama for code review, document analysis, and architecture queries. 8GB VRAM is sufficient, and the OpenAI-compatible API integrates with existing toolchains instantly.

Cost optimization: The 26B MoE model delivers 31B-class quality with 3.8B active parameters — 8x compute savings with only 3% quality trade-off. Ideal for RAG pipelines and agent backends.

Edge AI strategy: E2B's PLE architecture runs under 1.5GB RAM, making it a game-changer for embedding AI in mobile apps or IoT devices. LiteRT-LM integration simplifies native Android/iOS deployment.

Caution: Monitor the vLLM performance issue, use Ollama for single-user environments. When using 256K context, monitor memory and consider limiting via --max-model-len.

The 2026 open model landscape has shifted decisively. Gemma 4's combination of "Apache 2.0 + PLE + native multimodal + Function Calling" provides a realistic alternative for reducing proprietary model dependency in enterprise AI infrastructure.

This article was written with the assistance of AI (Claude Opus 4.6). Technical facts were verified against official documentation and benchmark data. For the latest information, refer to the official Google Gemma documentation, DeepMind Gemma 4 page, and HuggingFace Gemma 4 blog.

Originally published at ManoIT Tech Blog.

Complete Guide to Valkey 8.1 vs Redis 8.0 — The 2026 In-Memory Datastore Fork War and Production Migration Strategy

daniel jeong — Mon, 13 Apr 2026 00:24:45 +0000

Complete Guide to Valkey 8.1 vs Redis 8.0 — The 2026 In-Memory Datastore Fork War Winner and Production Migration Strategy

In March 2024, Redis Ltd. switched its open-source license from BSD-3-Clause to SSPL/RSALv2 dual licensing, sending shockwaves through the open-source community. The Linux Foundation immediately launched the Valkey project, with approximately 50 companies — including AWS, Google Cloud, Oracle, Alibaba, and Ericsson — joining as contributors. As of April 2026, Valkey 8.1 delivers 37% higher throughput and 28% lower memory usage compared to Redis, while AWS ElastiCache and GCP Memorystore have made Valkey their default engine.

Meanwhile, Redis added AGPLv3 as a third licensing option in version 8.0, attempting an open-source reconciliation, and counterattacked with Vector Set — a new data type for the AI era. This guide provides a comprehensive, production-focused comparison of both sides: architecture differences, performance benchmarks, licensing strategies, cloud ecosystem landscape, and migration strategies.

Background — Why Valkey Was Born

The Redis License Change and Community Split

Redis operated under BSD-3-Clause for 15 years, becoming the de facto standard for in-memory datastores. In March 2024, Redis Ltd. switched to SSPLv1/RSALv2 dual licensing, citing insufficient contributions from cloud providers who offered Redis as a managed service. Neither license is OSI-approved, effectively restricting managed service offerings.

The Linux Foundation launched Valkey in late March 2024, forking from Redis 7.2.4. AWS, Google Cloud, Oracle, Snap, and Ericsson joined as initial contributors, with former Redis core developers forming the technical leadership committee. The name "Valkey" combines "value" and "key" — the fundamental concepts of a datastore.

Redis AGPLv3 Retreat — A Reconciliation Gesture Too Late?

In May 2025, alongside Redis 8.0 GA, Redis added AGPLv3 as a third licensing option. Users can now choose from SSPLv1, RSALv2, or the OSI-approved AGPLv3. However, by this point the Valkey ecosystem was already firmly established. AGPLv3 requires source disclosure for all modifications when providing network services, creating higher adoption barriers for enterprises compared to Valkey's BSD-3-Clause.

Deep Architecture Comparison — I/O Threading and Memory Optimization

Valkey 8.1's I/O Threading Innovation

The enhanced async I/O threading introduced in Valkey 8.0 represents the biggest architectural change since the fork. While maintaining the single-threaded command processing model for atomicity, network reads/writes are offloaded to an I/O thread pool. Valkey intelligently distributes I/O tasks across multiple cores based on real-time usage analysis, maximizing hardware utilization.

Valkey 8.1 takes this further. TLS negotiation offloading moved to I/O threads, improving new connection acceptance speed by approximately 300% in TLS-enabled environments. Replication stream writes on primary nodes are also offloaded to the I/O thread pool, making diskless replication with TLS up to 18% faster. Memory prefetching techniques preload hashtable buckets and elements into CPU cache during key iteration, significantly improving SCAN command family performance.

Memory Efficiency — Hashtable Redesign

Valkey 8.x's hashtable redesign significantly reduces per-key-value-pair memory overhead: approximately 20 bytes for keys without TTL, and up to 30 bytes for keys with TTL. At hyperscale, the difference is dramatic:

Key Count	Valkey 8.1	Redis 8.0	Difference
1M	~80 MB	~100 MB	-20%
10M	~760 MB	~980 MB	-22%
50M	3.77 GB	4.83 GB	-28% (1.06 GB)

At 50 million keys, Valkey saves 1.06 GB compared to Redis. For environments running hundreds of replicas, the infrastructure cost savings are substantial.

Redis 8.0's Vector Set — The AI Era Differentiator

Redis 8.0's most powerful differentiator is the Vector Set data type. Inspired by Sorted Sets, it natively supports high-dimensional vector embedding storage and similarity search. This enables semantic search, recommendation systems, and RAG (Retrieval-Augmented Generation) pipelines without a separate vector database.

Key Vector Set capabilities:

Feature	Description
Auto Quantization	Default 8-bit quantization, with no-quantization and binary quantization options
Dimension Reduction	Automatic dimension reduction via random projection
Attribute Filtering	JSON blob metadata association for filtered searches
HNSW Index	High-performance approximate nearest neighbor search

Note that Vector Set is currently in beta, and its API may change. Unless your use case specifically requires combining caching with vector similarity search in a single infrastructure, dedicated vector databases (Weaviate, Milvus, etc.) remain the more mature choice.

Performance Benchmarks — The Gap in Numbers

Independent benchmarks conducted by Momento on AWS c8g.2xlarge (8 vCPU) instances clearly demonstrate the performance gap:

Metric	Valkey 8.1.1	Redis 8.0	Valkey Advantage
SET RPS	999,800	729,400	+37%
SET p99 Latency	0.80 ms	0.99 ms	-19%
GET RPS	~1,050,000	~860,000	+22%
Memory (50M keys)	3.77 GB	4.83 GB	-28%
TLS Connection Accept	(Valkey 8.1 baseline)	—	+300%

Valkey's I/O threading architecture shows a clear advantage in multi-core environments. The 300% TLS connection acceptance improvement makes a real difference in production environments with TLS enabled. Pipeline workloads also see an additional 10% throughput improvement in Valkey 8.1 over 8.0.

Licensing Strategy and Governance — Who Is True Open Source?

Aspect	Valkey	Redis
License	BSD-3-Clause	SSPLv1 / RSALv2 / AGPLv3 (triple)
OSI Approved	BSD-3 is OSI-approved	Only AGPLv3 is OSI-approved
Governance	Linux Foundation (neutral)	Redis Ltd. (commercial entity)
Contributors	~50 companies (AWS, GCP, Oracle, etc.)	Redis Ltd.-centric
GitHub Stars	19,800+	68,000+ (15 years accumulated)
Managed Service	No restrictions	AGPLv3 requires source disclosure

From an enterprise perspective, the most critical difference is license risk. Valkey's BSD-3-Clause has virtually no commercial use restrictions. Redis's AGPLv3, while OSI-approved, requires modified source disclosure for network services, necessitating legal review. Choosing SSPL/RSALv2 means you're using source-available, not open-source, licenses.

Cloud Ecosystem Landscape — Big Three Choices

As of April 2026, major cloud providers' in-memory datastore strategies have clearly diverged:

Cloud	Service	Default Engine	Notes
AWS	ElastiCache / MemoryDB	Valkey	Serverless 33% cheaper, node-based 20% cheaper
GCP	Memorystore	Valkey	Up to 14.5 TB, multi-zone clusters
Azure	Azure Managed Redis	Redis	Azure Cache for Redis retiring
Akamai	Managed Valkey	Valkey	Switched in 2024
Oracle	OCI Cache	Valkey	Linux Foundation contributor

AWS's Valkey-based ElastiCache Serverless is 33% cheaper than Redis OSS, with node-based options 20% cheaper. Excluding Azure, Valkey has become the de facto standard engine for multi-cloud strategies.

Feature Comparison — Where They Diverge

Feature	Valkey 8.1	Redis 8.0+
I/O Threading	Enhanced async I/O	Basic I/O threading
Vector Search	Not supported (external)	Vector Set (native)
Full-text Search	Not supported	Redis Query Engine
Time Series	Not supported	RedisTimeSeries
JSON Support	Basic support	RedisJSON (native)
Probabilistic Data Structures	Basic support	RedisBloom (integrated)
Client Compatibility	100% Redis client compatible	Native

Redis's strength lies in its unified data platform strategy — caching + vector search + full-text search + time series in a single infrastructure. Valkey focuses on pure caching/session/message queue workloads, delegating vector and full-text search to dedicated solutions (Weaviate, Elasticsearch, etc.).

Production Migration Guide

Redis to Valkey Migration

Valkey maintains full API compatibility with Redis OSS 7.2. Existing Redis clients (ioredis, redis-py, Jedis, StackExchange.Redis) work without code changes. Migration follows three steps:

Step 1: Compatibility Verification

# Check current Redis version
redis-cli INFO server | grep redis_version

# Test compatibility with Valkey container
docker run -d --name valkey-test -p 6380:6379 valkey/valkey:8.1

# Test existing client against Valkey
redis-cli -p 6380 PING
# Response: PONG

# Run existing application integration tests
REDIS_URL=redis://localhost:6380 npm test

Step 2: Data Migration

# RDB snapshot migration (with downtime)
redis-cli -h source-redis BGSAVE
# Copy RDB file to Valkey data directory and restart

# Live migration (minimal downtime)
# Set Valkey as Redis replica
valkey-cli -h valkey-new REPLICAOF source-redis 6379

# Verify sync completion
valkey-cli -h valkey-new INFO replication
# Confirm: master_link_status:up, master_sync_in_progress:0

# Execute failover
valkey-cli -h valkey-new REPLICAOF NO ONE

Step 3: AWS ElastiCache Migration (Managed)

# Change ElastiCache engine via AWS CLI
aws elasticache modify-replication-group \
  --replication-group-id my-redis-cluster \
  --engine valkey \
  --engine-version 8.0 \
  --apply-immediately

# Or create new Valkey cluster with data migration
aws elasticache create-serverless-cache \
  --serverless-cache-name my-valkey-cache \
  --engine valkey \
  --major-engine-version 8

Decision Framework

Scenario	Recommendation	Reason
Pure caching/session/queue	Valkey	Higher throughput, lower memory, permissive license
Caching + vector search integration	Redis	Vector Set simplifies infrastructure
AWS/GCP managed services	Valkey	Default engine, 20-33% cost savings
Azure environment	Redis	Azure Managed Redis native support
Full-text search + time series needed	Redis	RedisSearch, RedisTimeSeries integrated
Minimize license risk	Valkey	BSD-3, no managed service restrictions
High-traffic (1M+ RPS)	Valkey	I/O threading maximizes multi-core utilization

Kubernetes Deployment — Helm Chart Comparison

# Valkey Helm deployment (Bitnami)
# values-valkey.yaml
architecture: replication
auth:
  enabled: true
  password: "your-secure-password"
master:
  resources:
    requests:
      cpu: 500m
      memory: 1Gi
    limits:
      cpu: 2000m
      memory: 4Gi
  persistence:
    enabled: true
    size: 10Gi
replica:
  replicaCount: 3
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
metrics:
  enabled: true
  serviceMonitor:
    enabled: true  # Prometheus integration

# Install Valkey
helm install my-valkey oci://registry-1.docker.io/bitnamicharts/valkey \
  -f values-valkey.yaml -n datastore

# Install Redis (for comparison)
helm install my-redis oci://registry-1.docker.io/bitnamicharts/redis \
  -f values-redis.yaml -n datastore

2026 and Beyond — Valkey 9.0 and Redis 8.6 Directions

The Valkey community has already released Valkey 9.0, demonstrating aggressive development velocity. The Keyspace Amsterdam event shows an independent community ecosystem taking shape. Redis has released 8.4 and 8.6 in quick succession, focusing on performance improvements and memory reduction, with Redis 8.6 achieving "substantial performance improvements and memory reduction."

The codebase divergence deepens over time. Valkey focuses on core performance and memory efficiency, while Redis differentiates through data platform integration (vector, search, time series, JSON). Starting from the same code in 2024, by 2026 each has developed a distinct identity.

Conclusion — A Practical Selection Guide

Choosing an in-memory datastore in 2026 is no longer "just use Redis." For most caching, session management, and message queue workloads, Valkey is the rational choice across performance, cost, and licensing dimensions. If you're on AWS or GCP, managed service cost savings alone justify the switch.

However, for AI-centric architectures requiring vector similarity search, full-text search, and time series data integrated with a cache layer, Redis's unified data platform strategy reduces infrastructure complexity. If Azure is your primary environment, Redis is the natural choice.

The key takeaway: existing Redis client code works with Valkey without modification. Migration cost is extremely low, so if you're currently running Redis, we strongly recommend testing Valkey 8.1 in your staging environment.

This article was generated by the **ManoIT Tech Blog Automation Pipeline. AI-powered trend analysis, technical research, content generation, and quality verification. For technical corrections or suggestions, contact ManoIT.

Originally published at ManoIT Tech Blog.

CVE-2026-33105 AKS CVSS 10.0 Emergency Analysis and Complete Guide to Managed Kubernetes Zero Trust Security

daniel jeong — Thu, 09 Apr 2026 02:17:30 +0000

CVE-2026-33105 AKS CVSS 10.0 Emergency Analysis and Complete Guide to Managed Kubernetes Zero Trust Security — EKS/AKS/GKE Multi-Cloud Defense Strategy

On April 3, 2026, Microsoft disclosed CVE-2026-33105 — a CVSS 10.0 (Critical) privilege escalation vulnerability in Azure Kubernetes Service (AKS). An unauthenticated attacker can escalate privileges over the network, potentially gaining full cluster control from a single compromised workload. With 89% of organizations experiencing at least one Kubernetes security incident in the last 12 months and Kubernetes token theft attacks surging 282% year-over-year, managed Kubernetes security can no longer be delegated solely to cloud providers.

This article analyzes the CVE-2026-33105 attack mechanism and immediate remediation steps, then provides a comprehensive guide to building a Zero Trust security framework across EKS/AKS/GKE multi-cloud environments — covering Workload Identity, least-privilege RBAC, network policies, and runtime security.

CVE-2026-33105 — The Worst AKS Privilege Escalation Ever

Vulnerability Overview and Attack Vector

The core of CVE-2026-33105 is Improper Authorization (CWE-285). AKS fails to correctly validate authorization checks for certain resources, allowing an unauthenticated attacker to interact with a network-accessible AKS component and gain higher-level permissions than intended.

Field	Details
CVE ID	CVE-2026-33105
CVSS Score	10.0 (Critical) — Maximum severity
Vulnerability Type	CWE-285: Improper Authorization
Attack Vector	Network (No authentication required, No user interaction)
Impact Scope	AKS cluster privilege escalation → Full cluster control
Disclosed	April 3, 2026
Patch	Security update deployed via Azure Update Manager

Attack Scenario and Blast Radius

The key risk lies in authorization bypass through the nodes/proxy path. Once an attacker tricks a network-accessible AKS component into granting elevated permissions, limited workload access can escalate to full cluster or Azure tenant-level control.

Attack Phase	Action	Severity
1. Initial Access	Unauthenticated request to network-accessible AKS endpoint	Critical
2. Authorization Bypass	Bypass authorization checks via nodes/proxy path	Critical
3. Privilege Escalation	Obtain cluster-admin level privileges	Critical
4. Lateral Movement	Harvest kubeconfig, node metadata, service credentials	Critical
5. Tenant Infiltration	Pivot to other resources within the Azure tenant	Critical

Immediate Response Checklist

Every organization running AKS must execute these 5 steps immediately:

# Step 1: Identify affected AKS clusters
az aks list --query "[].{Name:name, RG:resourceGroup, Version:kubernetesVersion, State:provisioningState}" -o table

# Step 2: Apply security patch (Azure Update Manager)
az aks upgrade --resource-group <RG> --name <CLUSTER> --kubernetes-version <PATCHED_VERSION>

# Step 3: Audit over-privileged RBAC bindings
kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects[]'

# Step 4: Check nodes/proxy access permissions
kubectl auth can-i create nodes/proxy --all-namespaces --list

# Step 5: Review suspicious role binding creation history
kubectl get events --field-selector reason=RoleBinding -A --sort-by='.lastTimestamp' | tail -20

Microsoft's patch applies a deny-by-default authorization policy for nodes/proxy, with only approved system users, groups, and kube-system service accounts exempted.

Managed Kubernetes Attack Surface — EKS vs AKS vs GKE

While CVE-2026-33105 is AKS-specific, each managed Kubernetes service has structurally different attack surfaces. Multi-cloud organizations must understand each platform's unique risks.

Security Domain	EKS (AWS)	AKS (Azure)	GKE (Google Cloud)
Identity	IRSA → EKS Pod Identity	Entra ID + Workload Identity Federation	Workload Identity + Google Cloud IAM
Policy Engine	OPA Gatekeeper / Kyverno (self-managed)	Azure Policy (OPA Gatekeeper-based)	Policy Controller + Binary Authorization
Runtime Security	GuardDuty EKS Runtime + Bottlerocket	Defender for Containers	GKE Sandbox (gVisor) + Security Posture Dashboard
Network Isolation	VPC CNI + Security Groups for Pods	Azure CNI + NSG + Azure Firewall	Dataplane V2 (Cilium) + Private Cluster
Secrets Management	Secrets Manager + CSI Driver	Key Vault + CSI Driver	Secret Manager + CSI Driver
Image Signing	ECR Image Scanning + Cosign	ACR + Notation (ORAS)	Binary Authorization (native signing)
Zero Trust	Zero Operator Access (independently audited)	Entra ID Conditional Access	BeyondCorp Enterprise integration
Unique Risk	IMDSv1 metadata exposure	CVE-2026-33105 (nodes/proxy bypass)	Sys:All risk (any Google account = authenticated)

Notably, GKE's Sys:All issue treats any valid Google account as an authenticated entity through OpenID Connect. In clusters where the system:authenticated group has excessive permissions, any attacker with a Google account can take over the cluster.

Zero Trust Kubernetes — 5-Layer Defense Architecture

Layer 1: Workload Identity — Cryptographic Workload Authentication

The first Zero Trust principle is assigning a verifiable identity to every workload. Sharing default ServiceAccounts maximizes the blast radius of vulnerabilities like CVE-2026-33105. Map a dedicated ServiceAccount 1:1 to each Deployment/StatefulSet and federate with cloud IAM.

# EKS Pod Identity
apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service              # 1 Deployment = 1 ServiceAccount
  namespace: production
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/order-service-role
---
# AKS Workload Identity
apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service
  namespace: production
  annotations:
    azure.workload.identity/client-id: <MANAGED_IDENTITY_CLIENT_ID>
  labels:
    azure.workload.identity/use: "true"
---
# GKE Workload Identity
apiVersion: v1
kind: ServiceAccount
metadata:
  name: order-service
  namespace: production
  annotations:
    iam.gke.io/gcp-service-account: order-service@project-id.iam.gserviceaccount.com

Adding SPIFFE/SPIRE enables cloud-agnostic cryptographic workload IDs (X.509 SVIDs) for consistent identity across multi-cloud environments.

Layer 2: Least-Privilege RBAC — Eliminating cluster-admin

The biggest lesson from CVE-2026-33105 is that excessive RBAC bindings determine the blast radius. Organizations with properly configured RBAC reduced security incidents by 64% and achieved 47% faster incident remediation.

# ❌ Anti-pattern: cluster-admin for developers
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dev-team-admin
roleRef:
  kind: ClusterRole
  name: cluster-admin      # Never do this

---
# ✅ Best Practice: namespace-scoped least privilege
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-developer
  namespace: team-alpha
rules:
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
  - apiGroups: [""]
    resources: ["pods", "pods/log", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
  # No nodes/proxy, no secrets direct access
  # delete requires separate approval process

Layer 3: Network Microsegmentation

The core of Zero Trust networking is a Default Deny policy. Only explicitly allowed traffic passes; everything else is blocked.

# Default Deny — block all traffic in namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}             # Apply to all Pods
  policyTypes:
    - Ingress
    - Egress
---
# Explicit Allow — only order-service → payment-service
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-order-to-payment
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: payment-service
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: order-service
      ports:
        - protocol: TCP
          port: 8080

Layer 4: Runtime Security — eBPF-Based Detection

While RBAC and network policies are prevention layers, zero-days like CVE-2026-33105 can be exploited before patches. Runtime security is the detection and response layer.

Tool	Technology	Strength	Use Case
Tetragon	eBPF kernel-level observation	Real-time process execution, file access, network flow monitoring	Runtime policy violation detection
Falco	eBPF + rule engine	Community rules ecosystem, CNCF graduated	Anomaly detection and alerting
KubeArmor	LSM + eBPF	Fine-grained file/process/network policy enforcement	Container runtime behavior restriction
Trivy Operator	Vulnerability scanning	Continuous image/config/RBAC scanning	Pre-emptive vulnerability detection

Layer 5: Supply Chain Security — Image Signing and Admission Control

With Kubernetes token theft surging 282%, supply chain attacks deploying malicious container images are also increasing. Validate image signatures at admission webhooks and block unsigned deployments.

# Kyverno policy — block unsigned image deployment
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-cosign-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "registry.company.io/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
                      -----END PUBLIC KEY-----

Production Implementation — Multi-Cloud Security Automation Pipeline

# CI/CD Security Automation Pipeline (GitHub Actions)

# Step 1: Image build + vulnerability scan
docker build -t registry.company.io/app:$SHA .
trivy image --severity HIGH,CRITICAL --exit-code 1 registry.company.io/app:$SHA

# Step 2: Image signing (Cosign + Sigstore)
cosign sign --key cosign.key registry.company.io/app:$SHA

# Step 3: SBOM generation + attestation
syft registry.company.io/app:$SHA -o spdx-json > sbom.json
cosign attest --predicate sbom.json --type spdxjson --key cosign.key registry.company.io/app:$SHA

# Step 4: K8s manifest security scan (RBAC/NetworkPolicy validation)
kubescape scan k8s-manifests/ --framework nsa,mitre --fail-threshold 50

# Step 5: Deploy (ArgoCD sync — Kyverno auto-verifies signatures)
argocd app sync production-app --prune

2026 Managed K8s Threat Landscape

Threat Category	Key Examples	Mitigation Strategy
Authorization Bypass / Privilege Escalation	CVE-2026-33105 (AKS), Sys:All (GKE)	Least-privilege RBAC + Workload Identity + Regular audits
Supply Chain Attacks	Malicious Helm charts, Infected operators/CRDs	Image signing (Cosign) + Binary Authorization + SBOM
Credential Harvesting	TeamPCP worm, K8s token theft (282% increase)	Short-lived tokens + External secret stores (Vault) + IMDSv2 enforcement

The TeamPCP worm is a 2026 threat that automatically detects Kubernetes clusters and drops specialized payloads to harvest cluster credentials. Counter this by minimizing token lifetimes, managing all secrets through external stores like HashiCorp Vault, and enforcing IMDSv2 on AWS.

Security Maturity Self-Assessment Checklist

Layer	Required Items	Verification Method
Identity	Workload Identity 1:1 mapping, OIDC/SSO	`kubectl get sa -A` → Check Pods using default SA
RBAC	No human cluster-admin bindings, namespace-scoped roles	`kubectl auth can-i --list` → Identify over-privileges
Network	Default Deny policies, explicit allow only	`kubectl get netpol -A` → Find namespaces without policies
Runtime	eBPF-based detection (Tetragon/Falco) operational	Monitor Falco rule hit rates + response times
Supply Chain	Image signature verification, SBOM, admission blocking	Attempt unsigned image deployment → Verify block

Conclusion: Security Beyond Patching

CVE-2026-33105 isn't simply solved by applying a patch. It received a CVSS 10.0 rating because when excessive RBAC bindings + absent network isolation + inadequate runtime monitoring combine, a single authorization bypass leads to full infrastructure compromise.

Managed Kubernetes security is a shared responsibility between cloud providers and customers. Microsoft fixing the AKS nodes/proxy authorization logic is the provider's responsibility, but applying least-privilege RBAC, network microsegmentation, and runtime security detection falls on the customer. Implement the 5-layer Zero Trust framework — Workload Identity, least-privilege RBAC, Default Deny network policies, eBPF runtime security, and supply chain signature verification — to build proactive defenses before the next CVE is disclosed.

AI Disclosure: This article was written and reviewed by the ManoIT engineering team with research assistance from AI (Claude Opus 4.6, Anthropic). Technical accuracy was cross-verified against official documentation and CVE databases. Always test in your own environment before applying in production.

Originally published at ManoIT Tech Blog.

Complete Guide to GitHub Actions 2026 Security Roadmap — Dependency Locking, Native Egress Firewall, and Scoped Secrets

daniel jeong — Tue, 07 Apr 2026 00:20:29 +0000

Complete Guide to GitHub Actions 2026 Security Roadmap — Dependency Locking, Native Egress Firewall, and Scoped Secrets to Block Supply Chain Attacks

In March 2025, the tj-actions/changed-files supply chain attack compromised over 23,000 repositories. Attackers stole a PAT from reviewdog/action-setup, repointed all tj-actions version tags to malicious code, and exfiltrated CI/CD secrets — including credentials from Coinbase — through workflow logs. This incident exposed the structural vulnerabilities of the GitHub Actions ecosystem: mutable references causing non-deterministic execution, unrestricted network egress, and excessive secret inheritance.

In response, GitHub published its 2026 Security Roadmap — introducing workflow dependency locking, a Layer 7 native egress firewall, scoped secrets, policy-driven execution controls, Actions Data Stream, and OIDC custom property claims (GA as of April 2026). This guide provides a deep dive into each feature's architecture, practical implementation, and migration strategy.

The Structural Vulnerabilities Exposed by tj-actions

Understanding the 2026 security roadmap requires examining why such a large-scale supply chain attack was possible. The tj-actions attack chain progressed through five stages:

Stage	Attack Action	Exploited Vulnerability
1. Initial Compromise	spotbugs/sonar-findbugs vulnerability exposed a contributor's PAT	Long-lived tokens
2. Lateral Movement	Stolen PAT used to access spotbugs/spotbugs repository	Excessive token scope
3. Credential Theft	Malicious workflows leaked additional PATs	Unrestricted egress + secret exposure
4. Dependency Poisoning	reviewdog/action-setup → tj-actions/eslint-changed-files cascading infection	Mutable tag references + opaque transitive dependencies
5. Mass Propagation	All tj-actions version tags repointed to malicious commit	Runtime mutable tag resolution, 23,000+ repos affected

GitHub's security team summarized the pattern: "Vulnerabilities allow untrusted code execution, malicious workflows run without observability or control, compromised dependencies spread across thousands of repositories, over-permissioned credentials get exfiltrated via unrestricted network access." The 2026 roadmap is designed to break each link in this attack chain.

Workflow Dependency Locking — Deterministic Execution Like go.mod

The biggest security gap in GitHub Actions today is that dependencies are resolved at runtime using mutable references (tags, branches). Writing uses: actions/checkout@v4 means the commit pointed to by the v4 tag can change at any time. The tj-actions attack exploited exactly this vulnerability.

The New dependencies Section

GitHub introduces a dependencies: section in workflow YAML — the same concept as Go's go.mod + go.sum — that locks both direct and transitive dependencies using commit SHAs.

# .github/workflows/ci.yml — Dependency locking example
name: CI Pipeline
on: [push, pull_request]

# New dependencies section: all Actions locked to commit SHAs
dependencies:
  actions/checkout:
    version: v4.2.2
    sha: 11bd71901bbe5b1630ceea73d27597364c9af683
  actions/setup-node:
    version: v4.1.0
    sha: 39370e3970a6d050c480ffad4ff0ed4d3fdee5af
  # Transitive dependencies also automatically locked
  actions/cache:
    version: v4.2.0
    sha: d4323d4df104b026c6a166049fb557cb5d0bedfc

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4  # SHA auto-resolved from dependencies
      - uses: actions/setup-node@v4
        with:
          node-version: 22

Three key characteristics define this feature. First, deterministic execution ensures every workflow runs the exact code that was reviewed. Second, dependency changes automatically appear in PR diffs, enabling reviewable updates. Third, hash mismatches halt execution before jobs run through preemptive blocking. The system transitively tracks nested dependencies inside composite actions, providing full visibility into previously opaque dependency chains.

Comparison	Current (Tag References)	New (Dependency Locking)
Reference method	`@v4` (mutable tag)	Commit SHA pinned (immutable)
Transitive deps	Opaque (runtime resolution)	Full tree visibility
Change detection	Impossible	Auto-shown in PR diffs
Hash mismatch	Runs without detection	Halts before execution
Management tool	Manual SHA pinning	GitHub CLI auto-resolution/update

Timeline: Public preview within 3-6 months, GA within 6 months. Future plans include deprecating mutable references entirely in favor of immutable releases, creating a central enforcement point for detecting and blocking malicious code.

Native Egress Firewall — Blocking Data Exfiltration at Layer 7

In the tj-actions attack, stolen secrets were transmitted to attacker servers through unrestricted outbound network access. Currently, GitHub-hosted runners allow network access to all external destinations by default — once an attacker gains root, any data can be exfiltrated.

Layer 7 Firewall Outside the Runner VM

GitHub's native egress firewall operates outside the runner VM at Layer 7. This means even if an attacker gains root access inside the runner, the firewall cannot be bypassed. This is fundamentally different from third-party solutions (like StepSecurity Harden-Runner) that operate inside the runner.

# Egress firewall policy example (expected configuration)
egress-policy:
  mode: enforce  # monitor | enforce
  allowed-domains:
    - github.com
    - "*.githubusercontent.com"
    - registry.npmjs.org
    - pypi.org
    - files.pythonhosted.org
    - docker.io
    - "*.docker.io"
  blocked: all  # Block all traffic outside allowlist
  log-level: detailed  # Auto-correlate with workflow/job/step context

The firewall operates in two modes. Monitor mode audits all outbound traffic, automatically correlating it with workflow run/job/step context and initiating commands. Enforce mode blocks traffic not explicitly permitted, with fine-grained control over domains/IP ranges, HTTP methods, and TLS/protocol requirements.

GitHub's recommended adoption path: Start with Monitor mode to observe real traffic patterns → Build allowlists from real data → Switch to Enforce mode with confidence.

Timeline: Public preview within 6-9 months. Future plans include process-level visibility, file system monitoring, and near real-time enforcement.

Scoped Secrets and Policy-Driven Execution Controls

Scoped Secrets — Applying the Principle of Least Privilege

Currently, GitHub Actions secrets inherit implicitly through repository/organization scope. In reusable workflows, secrets: inherit is the default, meaning all caller secrets flow into called workflows. This maximizes the blast radius in supply chain attacks like tj-actions.

Scoped secrets bind credentials to explicit execution contexts:

Scope Criteria	Description	Example
Repository/Organization	Allow access only in specific repos/orgs	Bind AWS keys to prod repo only
Branch/Environment	Usable only in specific branches or Environments	Production secrets on main branch only
Workflow ID/Path	Access only from specific workflow files	Only deploy.yml accesses cloud credentials
Trusted reusable workflows	Only explicitly designated reusable workflows	Only internal org deploy workflows allowed

A critical change: secrets no longer automatically inherit in reusable workflows. Instead of callers implicitly passing credentials, only explicitly scoped secrets are accessible. Additionally, write permission no longer includes secret management capability — this is separated into a dedicated custom role.

Policy-Driven Execution Controls — Ruleset Framework

GitHub extends its existing repository Rulesets framework to provide centralized policy-driven execution control over workflows themselves.

# Workflow execution policy example (Ruleset-based)
workflow-rules:
  # Actor Rules: who can trigger workflows
  actor-rules:
    workflow_dispatch:
      allowed: [maintainers, admin]  # Contributors can't manually trigger
    pull_request:
      allowed: [all]  # PR events allowed from all contributors

  # Event Rules: which events can execute workflows
  event-rules:
    blocked-events:
      - pull_request_target  # Block dangerous events
    trusted-automation:
      - github-actions[bot]
      - dependabot[bot]
      - copilot[bot]

Actor Rules define who can trigger workflows, and Event Rules define which GitHub Actions events are allowed to execute. For example, blocking pull_request_target prevents external code from running in the base repo context with secret access. An Evaluate mode lets you monitor policy violations before enforcement.

OIDC Custom Claims GA and Artifact Attestations

OIDC Repository Custom Properties — GA April 2026

As of April 2, 2026, repository custom property claims in GitHub Actions OIDC tokens are generally available. Previously, cloud provider trust policies (AWS, Azure, GCP) could only be set based on repository names. Now, organization-level custom property values can be used as OIDC claims.

# AWS IAM trust policy — Using OIDC custom properties
# Group-based control instead of per-repository configuration
Statement:
  - Effect: Allow
    Action: sts:AssumeRoleWithWebIdentity
    Condition:
      StringEquals:
        # New: Category-based control via custom properties
        token.actions.githubusercontent.com:repository_properties.environment: production
        token.actions.githubusercontent.com:repository_properties.team: platform
        token.actions.githubusercontent.com:repository_properties.compliance_tier: sox

The practical benefit: trust policies can be aligned with organizational governance models — environment type (production/staging/dev), team ownership, compliance tier — drastically reducing per-repository configuration overhead.

Artifact Attestations — SLSA Build Level 3

GitHub Artifact Attestations cryptographically bind build artifacts (container images, binaries) to source repositories and build workflows, achieving SLSA Build Level 3 security — providing unfalsifiable proof of software provenance and integrity.

# Artifact Attestation workflow
name: Build and Attest
on:
  push:
    tags: ['v*']

permissions:
  id-token: write       # OIDC token issuance
  attestations: write   # Attestation creation
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build container image
        run: docker build -t myapp:${{ github.ref_name }} .

      - name: Generate SLSA provenance attestation
        uses: actions/attest-build-provenance@v2
        with:
          subject-name: ghcr.io/${{ github.repository }}/myapp
          subject-digest: sha256:${{ steps.build.outputs.digest }}
          push-to-registry: true

Combined with the Code-to-Cloud Traceability feature (GA January 2026), you can trace an artifact's entire lifecycle — build → store → deploy → production — and filter security alerts by production exposure context.

Actions Data Stream — Centralized Telemetry

Individual workflow logs aren't enough to assess organization-wide CI/CD security posture. Actions Data Stream streams near real-time workflow execution data from all repositories/organizations to centralized destinations.

Item	Details
Supported destinations	Amazon S3, Azure Event Hub, Azure Data Explorer
Streamed data	Workflow/job execution, dependency resolution, Action usage patterns, network activity (future)
Delivery guarantee	At-least-once, batched events, standardized schema
Use cases	SIEM integration, anomaly detection, compliance auditing, cost analysis
Timeline	Public preview 3-6 months, GA 6-9 months

Security Hardening Checklist — Apply Today

Even before the 2026 roadmap features reach GA, here are immediately actionable security measures:

# Hardened CI workflow template — apply now
name: Hardened CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

# 1. Global least privilege
permissions: {}  # Remove all default permissions

jobs:
  build:
    runs-on: ubuntu-latest
    # 2. Job-level minimum permissions
    permissions:
      contents: read
      id-token: write  # For OIDC
    steps:
      # 3. Pin Actions to commit SHA (not tags)
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2
        with:
          persist-credentials: false  # 4. Don't leave credentials in .git/config

      # 5. OIDC short-lived tokens for cloud auth (not long-lived keys)
      - uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions
          aws-region: us-east-1

      # 6. Pass secrets individually at step level
      - name: Deploy
        env:
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
        run: ./deploy.sh

Priority	Action	Attack Blocked
P0	Global `permissions: {}` + job-level minimum	Excessive permission abuse
P0	Third-party Action commit SHA pinning	Tag repointing attacks (tj-actions type)
P0	Switch to OIDC short-lived tokens for cloud auth	Long-lived credential theft
P1	Set `persist-credentials: false`	.git/config credential exposure
P1	Organization-level default permissions read-only	Default read-write abuse
P1	Enable Artifact Attestations	Artifact tampering/provenance forgery
P2	Remove `secrets: inherit`, switch to explicit passing	Excessive secret exposure
P2	Scan workflows with CodeQL	Script injection, dangerous patterns
P2	Add zizmor static analysis	Common Actions misconfigurations

Roadmap Timeline and Migration Strategy

Feature	Public Preview	Expected GA	Impact
Workflow dependency locking	Q2-Q3 2026	Q3-Q4 2026	High — workflow YAML changes
Policy-driven execution controls	Q2-Q3 2026	Q3-Q4 2026	Medium — admin settings
Scoped secrets	Q2-Q3 2026	Q3-Q4 2026	High — secret architecture redesign
Actions Data Stream	Q2-Q3 2026	Q4 2026-Q1 2027	Low — observation only
Native egress firewall	Q3-Q4 2026	H1 2027	High — network access review

Migration strategy: All features offer Evaluate/Monitor modes first, enabling gradual adoption. Start by enabling Actions Data Stream for visibility into current pipelines, apply dependency locking to critical repos first, then begin egress firewall in Monitor mode to understand traffic patterns before switching to Enforce mode.

Conclusion: The Era of Secure-by-Default CI/CD

The GitHub Actions 2026 Security Roadmap isn't just a feature update — it's a paradigm shift in CI/CD security. Until now, CI/CD security depended on individual workflow authors' diligence. The new roadmap implements secure-by-default at the platform level: dependency locking ensures deterministic execution, the egress firewall blocks data exfiltration at its source, and scoped secrets enforce the principle of least privilege.

Most importantly, all these features can be adopted gradually without redesigning existing architectures. Start today with SHA pinning, OIDC migration, and minimum permission settings. As roadmap features reach preview, apply them in Evaluate/Monitor mode. When the next supply chain attack hits, your pipeline will be ready.

AI Disclosure: This article was written by ManoIT's automated tech blog system using Claude (Anthropic) for research, writing, and verification. All facts were cross-referenced with official documentation.

Sources: GitHub Blog — Actions 2026 Security Roadmap · GitHub Changelog — April 2026 Updates · GitHub — SLSA Build Level 3 · Wiz — GitHub Actions Security Guide · Unit 42 — tj-actions Supply Chain Attack

Originally published at ManoIT Tech Blog.

Complete Guide to MCP (Model Context Protocol) in 2026 — Architecture, Implementation, and Enterprise Roadmap

daniel jeong — Sun, 05 Apr 2026 21:09:08 +0000

Complete Guide to MCP (Model Context Protocol) in 2026 — Architecture, Implementation, and Enterprise Roadmap for AI Agent Integration

In November 2024, Anthropic open-sourced the Model Context Protocol (MCP), and in just 18 months it has become the de facto standard for AI agent integration. As of March 2026, MCP has surpassed 97 million monthly SDK downloads, earned over 81,000 GitHub stars, and is supported by every major AI vendor — Anthropic, OpenAI, Google, Microsoft, and AWS. MCP standardizes how AI models interact with external tools, data sources, and systems, earning the nickname "the USB-C of the AI world."

This guide covers everything you need to deploy MCP in production: core architecture, Streamable HTTP transport, OAuth 2.1 authentication, FastMCP server implementation, A2A protocol comparison, and the 2026 enterprise roadmap.

MCP Core Architecture — Host, Client, Server Three-Layer Model

MCP uses a client-server architecture built on JSON-RPC 2.0. A single host application (Claude Desktop, Claude Code, Cursor, etc.) creates multiple isolated MCP client sessions, each maintaining a stateful JSON-RPC channel with its own MCP server.

Component	Role	Examples
MCP Host	AI application providing LLM integration	Claude Desktop, Claude Code, Cursor, Cline
MCP Client	Connector created by the host, managing 1:1 sessions with servers	Internal process (not exposed to users)
MCP Server	Service providing external context and capabilities	GitHub, Slack, PostgreSQL, Notion MCP servers

Three Server Primitives

MCP servers expose external capabilities through three core primitives. Tools are functions the model can invoke (e.g., file search, DB queries, API calls). Resources are data sources the model can read (e.g., file contents, database records). Prompts are pre-defined templates that guide user workflows.

# MCP Server Three Primitives — FastMCP Example
from fastmcp import FastMCP

mcp = FastMCP("my-service")

# 1. Tool — Functions the model can call
@mcp.tool()
def search_database(query: str, limit: int = 10) -> list[dict]:
    """Search the database by keyword."""
    return db.search(query, limit=limit)

# 2. Resource — Data the model can read
@mcp.resource("config://app-settings")
def get_settings() -> str:
    """Return application settings."""
    return json.dumps(current_settings)

# 3. Prompt — Pre-defined workflow templates
@mcp.prompt()
def analyze_data(dataset_name: str) -> str:
    """Guide data analysis workflow."""
    return f"Please analyze the following dataset: {dataset_name}"

Transport Layer — Evolution from stdio to Streamable HTTP

MCP supports two transport modes. stdio handles local inter-process communication and is the default for running local MCP servers in Claude Desktop or Claude Code. Streamable HTTP, introduced in the November 2025 spec, replaces the legacy SSE (Server-Sent Events) transport and enables MCP servers to run as remote services.

Aspect	stdio	Streamable HTTP
Deployment	Local process (same machine as host)	Remote service (cloud-deployable)
Scalability	Single instance	Horizontal scaling with load balancers
Authentication	OS-level process isolation	OAuth 2.1 + PKCE
Use Cases	Developer tools, local file access	SaaS integrations, enterprise services
2026 Status	Stable (default in most IDEs)	SSE officially deprecated, migrating to Streamable HTTP

The key evolution on the 2026 roadmap is stateless operation. Current MCP servers must maintain session state, which limits horizontal scaling behind load balancers. The new spec standardizes session creation, resumption, and migration so server restarts and scale-out events are transparent to connected clients.

OAuth 2.1 Authentication and Enterprise Security

Remote MCP servers adopted OAuth 2.1 as the authentication standard starting with the June 2025 spec. MCP servers are classified as OAuth Resource Servers and advertise their authorization server location through .well-known endpoints. Clients must implement RFC 8707 Resource Indicators to prevent token misuse attacks.

# MCP Server OAuth 2.1 Authentication Flow Configuration
# .well-known/mcp-server-metadata.json
authorization_endpoint: "https://auth.example.com/authorize"
token_endpoint: "https://auth.example.com/token"
registration_endpoint: "https://auth.example.com/register"

# OAuth 2.1 Client Requirements
grant_types_supported:
  - authorization_code   # PKCE required
code_challenge_methods_supported:
  - S256                  # SHA-256 hash (plain forbidden)
token_endpoint_auth_methods_supported:
  - none                  # Public client (browser-based agents)
  - client_secret_post    # Confidential client (server-side)

# Resource Indicator (RFC 8707) — Token scope restriction
resource: "https://mcp.example.com/v1"
scope: "tools:read tools:execute resources:read"

The Q2 2026 enterprise authentication roadmap adds PKCE flows for browser-based agents and SAML/OIDC integration for enterprise identity providers. Q4 brings the MCP Registry — a curated, verified server directory with security audits, usage statistics, and SLA commitments.

Building Production MCP Servers with FastMCP

FastMCP dramatically simplifies Python-based MCP server development. FastMCP 3.0, released January 2026, handles schema generation, validation, and documentation with a single decorator. For TypeScript, combine @modelcontextprotocol/sdk with Zod for type-safe server construction.

# FastMCP 3.0 — Production MCP Server Example (Python)
from fastmcp import FastMCP
from pydantic import BaseModel, Field
import httpx

mcp = FastMCP(
    "weather-service",
    description="MCP server providing real-time weather information",
)

class WeatherResult(BaseModel):
    city: str = Field(description="City name")
    temperature: float = Field(description="Current temperature (Celsius)")
    condition: str = Field(description="Weather condition")
    humidity: int = Field(description="Humidity (%)")

@mcp.tool()
async def get_weather(city: str) -> WeatherResult:
    """Query current weather for a specified city.

    Args:
        city: City name to query (e.g., Seoul, Tokyo)
    """
    async with httpx.AsyncClient() as client:
        resp = await client.get(
            f"https://api.weather.example/v1/current?city={city}"
        )
        data = resp.json()
    return WeatherResult(
        city=data["city"],
        temperature=data["temp_c"],
        condition=data["condition"],
        humidity=data["humidity"],
    )

# Resource — Supported city list
@mcp.resource("weather://supported-cities")
def supported_cities() -> str:
    """Return list of supported cities."""
    return "Seoul, Tokyo, New York, London, Paris, Berlin"

if __name__ == "__main__":
    mcp.run()  # stdio mode (default) or --transport http for remote mode

// TypeScript MCP Server — @modelcontextprotocol/sdk + Zod
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "weather-service",
  version: "1.0.0",
});

// Tool registration — Type-safe schema with Zod
server.tool(
  "get_weather",
  "Query current weather for a specified city",
  { city: z.string().describe("City name") },
  async ({ city }) => {
    const data = await fetchWeather(city);
    return { content: [{ type: "text", text: JSON.stringify(data) }] };
  }
);

const transport = new StdioServerTransport();
await server.connect(transport);

Connecting MCP Servers in Claude Desktop/Code

// claude_desktop_config.json — MCP Server Connection Settings
{
  "mcpServers": {
    "weather": {
      "command": "python",
      "args": ["-m", "weather_service"],
      "env": {
        "WEATHER_API_KEY": "your-api-key"
      }
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..."
      }
    },
    "remote-service": {
      "url": "https://mcp.example.com/v1"
      // Streamable HTTP — remote MCP server (OAuth handled automatically)
    }
  }
}

MCP Ecosystem Status — 200+ Servers and Key Integrations

As of March 2026, the MCP ecosystem includes over 200 server implementations. Most major SaaS platforms and developer tools provide MCP servers, including GitHub, Slack, Google Drive, PostgreSQL, Notion, Jira, and Salesforce.

Category	Major MCP Servers	Capabilities
Dev Tools	GitHub, GitLab, Sentry	Issue/PR management, code search, error tracking
Collaboration	Slack, Notion, Google Drive	Message search, document read/write, file management
Databases	PostgreSQL, MongoDB, Redis	Schema exploration, query execution, data analysis
Cloud/Infra	AWS, Kubernetes, Terraform	Resource inspection, cluster management, IaC validation
CRM/Business	Salesforce, Jira, HubSpot	Lead management, ticket handling, pipeline analysis
IDE Integration	Claude Code, Cursor, Cline, Windsurf	Code editing, terminal execution, filesystem access

MCP vs A2A — AI Agent Protocol Comparison

A frequently discussed companion to MCP is A2A (Agent-to-Agent), released by Google in April 2025. The two protocols are complementary, not competing. MCP defines "how agents interact with tools," while A2A defines "how agents collaborate with each other." In December 2025, Anthropic, Block (Square), and OpenAI established the Agentic AI Foundation under the Linux Foundation, contributing both MCP and A2A.

Comparison	MCP (Model Context Protocol)	A2A (Agent-to-Agent)
Purpose	Agent ↔ Tool/data connection	Agent ↔ Agent collaboration
Protocol Base	JSON-RPC 2.0	JSON-RPC 2.0 + gRPC (v1.0)
Discovery	MCP Server Cards (.well-known)	Agent Cards (signed)
Authentication	OAuth 2.1 + PKCE	OAuth 2.1 + multi-tenancy
Governance	Agentic AI Foundation (Linux Foundation)	Agentic AI Foundation (Linux Foundation)
2026 Adoption	97M+ monthly downloads, 200+ servers	v1.0 released, gRPC support added
Analogy	"USB-C" — device connection standard	"TCP/IP" — device communication standard

In practice, MCP and A2A are used together. Individual agents access their tools and data via MCP, while task delegation and result sharing between agents happens through A2A. For example, a customer support agent queries CRM and knowledge bases via MCP, then delegates complex technical issues to a technical support agent through A2A.

2026 MCP Roadmap — Enterprise Production Ready

MCP's 2026 roadmap prioritizes enterprise production readiness. Key working group milestones:

Timeline	Area	Key Deliverables
Q1-Q2 2026	Transport Evolution	Streamable HTTP stateless operation, session migration, horizontal scaling
Q2 2026	Enterprise Auth	OAuth 2.1 + PKCE GA, SAML/OIDC IdP integration
Q2-Q3 2026	Server Discovery	MCP Server Cards (.well-known URL), standard metadata format
Q3 2026	Agent Communication	Agent-to-agent coordination primitives (A2A integration)
Q4 2026	MCP Registry	Verified server directory, security audits, SLA commitments

Elicitation and Sampling — Bidirectional Agent Interaction

One of MCP's powerful features is that servers can send reverse requests to clients (LLMs). Sampling lets MCP servers ask the LLM to generate text — used when an agent needs additional reasoning mid-task. Elicitation lets servers request direct input from users — used for human confirmation in long-running tasks or when additional information is needed.

These two features enable recursive agentic behavior. For example, a database migration server can detect schema changes, use Sampling to ask the LLM for impact analysis, and if deemed high-risk, use Elicitation to get final approval from the user — implementing a Human-in-the-Loop workflow. This is a key design pattern for balancing AI agent autonomy with human control.

Production MCP Adoption Checklist

For enterprise MCP adoption, consider this practical checklist organized around security, governance, and monitoring:

Phase	Area	Details
1. Security	Auth/AuthZ	Remote servers: OAuth 2.1 + PKCE required. No hardcoded API keys — use Vault
2. Security	Input Validation	Prompt injection defense, PII detection, minimum-privilege token scopes
3. Governance	Server Evaluation	Source code audit, version pinning, supply chain security verification
4. Governance	Rate Limiting	Per-user/agent request limits, cost tracking (per-request token logging)
5. Monitoring	Observability	OpenTelemetry tracing, request/response logging, error rate dashboards
6. Monitoring	Health Checks	MCP server availability monitoring, session state tracking, auto-recovery

Conclusion — MCP Defines the Future of AI Agent Integration

MCP is the first successful open protocol to standardize how AI agents interact with the external world. Built on the proven JSON-RPC 2.0 foundation, it cleanly abstracts three primitives — Tools, Resources, and Prompts — and extends to enterprise environments with Streamable HTTP transport and OAuth 2.1 authentication.

In H2 2026, stateless server operation, automatic discovery through MCP Server Cards, and agent-to-agent coordination with A2A will mature, evolving MCP from single tool connections into the foundational infrastructure for multi-agent orchestration. Organizations adopting AI agents should establish MCP as their default integration layer and design security and governance from day one — the most practical strategy for 2026.

AI Disclosure: This article was planned by the ManoIT technical research team, drafted by an AI assistant (Claude), and technically reviewed and edited by professional engineers.

Sources: Model Context Protocol Official Specification, MCP 2026 Roadmap Blog, FastMCP GitHub, Auth0 MCP OAuth Guide, WorkOS MCP Enterprise Roadmap, The New Stack MCP Production Guide

Last Updated: 2026-04-06 | Author: ManoIT Tech Blog

Originally published at ManoIT Tech Blog.