DevOps Daily

Per-Branch AI Endpoints: Isolating Model Spend Across Prod, Preview, and CI

DevOps Daily Team — Thu, 16 Jul 2026 09:00:00 GMT

AI spend is hard to see. In most setups the same gateway credential is used by production, every preview environment, CI, and whatever load test someone ran on Friday. All of that lands in one undifferentiated number. You cannot answer "what did that preview cost," you cannot cap a specific environment, and you find out a CI job went into a retry loop against an expensive model when the monthly invoice arrives, not when it happens.

The reason is that spend is attributed to a key, and the key is shared. Neon changes what is shared: each branch is its own deployment, and if you log usage to Postgres, that ledger lives on the branch too. So a preview or CI branch records its own spend in its own ledger, and none of it moves production's numbers. I tested it by running calls on a CI branch and watching production's ledger stay flat. The repo is at the end.

TL;DR

One shared gateway key means one undifferentiated bill: no per-environment attribution, no per-environment cap, and no early warning when a preview or CI job spends a lot.
On Neon, each branch is its own deployment (its own function endpoint), and the usage log you keep in Postgres lives on the branch. Calls on a branch record against the branch's ledger.
I tested it: two model calls on a ci-run branch raised the branch's token count while production's ledger stayed exactly where it was.
Copy-on-write means a branch inherits production's ledger snapshot at branch time; the isolation is in what happens after, new spend on a branch never touches production.

Prerequisites

A Neon project with the AI gateway enabled (us-east-2)
A usage table in Postgres (the demo logs every call), and branches for your environments

The shared-key problem

When production and every ephemeral environment authenticate with the same credential, the provider's dashboard shows you one line. That has real consequences:

No attribution. You cannot say what fraction of last month's tokens came from previews, from CI, or from real users.
No isolation. A preview running a batch job, or a CI test that loops, spends against the same budget production draws on, and can exhaust a rate limit everyone shares.
No early signal. The first time you learn a non-production environment burned money is the invoice.

Tagging requests helps a little, but it is bookkeeping bolted on after the fact, and it still shares one budget and one rate limit.

The Neon model: spend rides the branch

On Neon each branch is its own deployment with its own function URL, and because you log usage to Postgres and Postgres branches, the usage ledger is per branch too. A call made against a branch's function URL writes to that branch's usage_log, and that ledger is what makes spend attributable per environment: production's ledger is a different table on a different branch. The isolation demonstrated here is that per-branch ledger in Postgres, not a claim that Neon meters the gateway credential itself separately per branch. That distinction matters: the attribution you can rely on is the one you record yourself, in the branch's database.

The usage view is an ordinary query over that branch's log:

// GET /usage: tokens grouped by model, from THIS branch's log
const rows = await db
  .select({
    model: usageLog.model,
    calls: sql`count(*)::int`,
    totalTokens: sql`sum(${usageLog.totalTokens})::int`,
  })
  .from(usageLog)
  .groupBy(usageLog.model);

The proof: a CI branch spends, production does not move

I read production's usage, branched a ci-run environment, made two model calls against the branch, and read both ledgers.

The branch's gpt-5-nano total went from 25 to 71 as its two calls landed, while production stayed at 25. The CI run's spend was recorded against the CI branch and nowhere else, and deleting the branch takes its ledger with it.

Note

Because storage is copy-on-write, a new branch inherits production's ledger as it was at branch time (that is why the branch started at 25, not 0). The isolation is in the delta: everything spent on the branch after it is created stays on the branch, and nothing the branch does changes production's numbers. For clean per-run attribution, read the branch's growth, or keep CI branches short-lived so their ledger is just that run.

What this buys you

Attribution. Each environment's spend is a query against its own ledger, so "what did this preview cost" has an answer.
Containment. A runaway CI job or a preview load test spends against its branch, not production's budget or rate limit.
Cleanup. Delete the branch and its spend record goes with it; there is no separate accounting resource to prune.
Governance. Because each environment records against its own branch ledger, you can reason about and bound non-production usage separately from the real thing.

The repo

The gateway function with the per-branch usage log is here:

Wrapping up

Model spend is only invisible because it is attributed to a shared key. Move the usage ledger onto the branch and the picture inverts: every environment keeps its own record, a preview or CI run spends against itself, and production's numbers are unaffected by anything a branch does. You get per-environment attribution and containment for free, and cleanup is the same delete a branch that already tears down the rest of the preview.

Stop Prompting, Start Looping: Agentic Loops Explained

DevOps Daily Team — Wed, 08 Jul 2026 09:00:00 GMT

The people who build coding agents have quietly changed how they work. They do not sit and type one prompt, read the reply, and type the next one. They write a loop, hand it a goal, and walk away while the agent works. Boris Cherny, who built Claude Code, has said he does not really prompt anymore. He has loops running that prompt the model and decide what to do next, sometimes hundreds of agents at once, overnight.

That sounds like a productivity hack. It is actually a different mental model, and it is worth understanding whether or not you ever run an agent unattended. This post explains what an agentic loop is, the three-agent pattern that makes it reliable, and why the single most important piece is the one most people skip. There is an interactive simulator at the end so you can watch it happen step by step.

TLDR

An agentic loop is a cycle: gather context, take an action, check the result against the goal, then repeat until the goal is met. The loop, not the model, is what lets an agent finish multi-step work on its own.
The reliable version uses three roles: a planner picks the next step, a builder does it, and a judge grades the result. It cycles until the judge approves.
The judge should be a separate agent. An agent grading its own work is too lenient and will stop the moment the tests go green, even when the goal is not actually met.
Cost compounds because the whole context is re-sent every loop. Long loops get expensive fast, which is why you set stop conditions.

Prerequisites

You have used an AI coding tool at least once (Claude Code, Cursor, Copilot, or similar).
You are comfortable with the idea of tests and a spec as a definition of done.
No agent framework required. The point is the pattern, not any one tool.

What an agentic loop is

A plain language model answers once and stops. You ask, it replies, the interaction is over. An agentic loop wraps that single call in a cycle so the agent can keep going:

Gather context. Pull together the goal, the relevant files, and the result of the last action.
Take an action. Call one tool: read a file, edit code, run a command, run the tests.
Verify. Check whether that action moved closer to the goal. If yes, stop. If no, loop.

Most real tasks finish in three to eight of these iterations. Simple lookups take one or two. A gnarly multi-step change can take fifteen or more. The important shift is that the model is no longer the whole system. It is one step inside a loop that carries state forward and decides when the work is done.

That one-liner is a real, if crude, agentic loop. The shell provides the loop and the stop condition (npm test passing), and the agent provides the step. Everything past this is about making the loop smarter and safer.

The pattern that actually works: plan, build, judge

The version that engineering teams are settling on splits the work across three roles instead of one agent doing everything:

Plan. A planner decides the single next step toward the goal.
Build. A builder carries it out with tools, reading and editing files and running commands.
Judge. A separate judge grades the result against the goal and the spec, then decides whether to loop or stop.

The Claude Code team demoed building a full app this way: three agents, one to plan, one to build, one to judge, cycling until the app actually worked. The loop is the same gather-act-verify cycle, but giving each phase its own agent makes the hand-offs explicit and, crucially, keeps the judge honest.

Note

This is why the industry language shifted from "prompt engineering" to "loop engineering." The skill is no longer phrasing one perfect request. It is designing the loop: what the goal is, what each agent does, and what condition ends it.

The part everyone skips: the judge has to be separate

Here is the failure that separates a demo from a system. If the agent that wrote the code also decides whether the code is good, it will be too easy on itself. It sees the tests pass and declares victory, even when "tests pass" is not the same as "goal met."

Picture a task: add a signup endpoint that hashes the password and returns a 201. A self-checking agent adds the hashing, runs the tests, sees green, and stops. But the endpoint returns 200, not the 201 the spec asked for. Nobody checked the spec. The loop finished confident and wrong.

A separate judge, ideally a different model with its own instructions, catches exactly this. It is not grading its own homework, so it reads the spec and rejects the 200. The loop goes back to the planner, the status code gets fixed, and only then does it stop.

Warning

An unattended loop without a real verifier is a machine that ships bugs with confidence. The most common and most expensive mistake in loop engineering is letting the builder judge itself. Make the judge a separate agent, and give it the spec, not just the tests.

Why cost compounds

Loops are not free, and the cost does not grow linearly. Every iteration re-sends the whole context: the goal, the files, and everything the agent has learned so far. As the context window grows loop over loop, each turn costs more than the last. A loop that runs for hours can burn through tokens faster than almost anyone expects.

That is not a reason to avoid loops. It is the reason you always give a loop a stop condition and a budget: a goal that can be checked, a maximum number of turns, or both. A loop that cannot end is not autonomy. It is an open tab.

Split the model: a cheap executor, an expert on call

There is one more lever, and it is about cost. You do not have to run the whole loop on your most capable model. A pattern that keeps showing up is to run the loop on a fast, cheaper model, the executor, and have it consult a stronger, pricier model, the advisor, only when it hits something hard: a plan, a tricky review, an architectural call.

The executor runs every turn and does the bulk of the work, so most of your tokens are billed at the lower rate. The advisor is a tool the executor calls on demand, a handful of times, for the decisions that actually need the extra capability. Advice comes back, the executor keeps going. You get expert-level judgement on the few steps that need it without paying expert rates for the whole run.

It is the same instinct as splitting the builder from the judge, applied to cost: put the expensive thinking where it earns its keep, and let a cheaper model carry the routine.

Loops come in more than one shape

Plan, build, judge is the general shape, but you will meet it wearing different clothes. A few worth knowing:

The fix-until-green loop. The simplest useful loop. The goal is a passing test suite, the action is an edit, the verifier is the test runner, and it ends when the suite is green. This is the loop most people meet first, and the one-liner above is exactly it.

The experiment loop. When the goal is "make this better" instead of "make this pass," the verifier becomes a metric instead of a test. Read the current code, propose one change, run a short measurement, and keep the change only if the number improved, otherwise roll it back. Andrej Karpathy has described tuning models this way: many small, cheap experiments running overnight, keeping the handful that help and throwing the rest away. The pattern generalizes to anything you can score, from query latency to bundle size.

The overnight triage loop. The autonomous version starts with a discovery step: read the CI failures, the open issues, and the recent commits to find the work. Then, for each item, it plans a fix, makes it in an isolated git worktree so parallel agents cannot collide, verifies against tests, and opens a PR. You wake up to a queue of reviewed changes instead of a blank editor.

The research loop. Loops are not only for code. Give an agent a question and it can loop too: gather sources, read one, ask "do I have enough to answer confidently," and either search for more or write the answer. Same cycle, no compiler in sight.

Note

One mechanic ties all of these together: the agent forgets. Each turn starts fresh, so a loop needs somewhere outside the model to remember what it has learned. In practice that is a state file, a markdown scratchpad, or an issue tracker that the loop reads at the start of every iteration and writes back to at the end. The loop is the engine. The state file is the memory.

Try it: watch a loop run

Reading about a loop only gets you so far. We built an interactive simulator that runs one task through the full plan-build-judge loop, slowly, one phase at a time, so you can see the hand-offs, the decision to loop or stop, the context window growing, and the token cost climbing.

The most useful control is the "separate judge" toggle. Turn it off and watch the same loop finish with the wrong status code, the confident bug a real judge would have caught.

Tip

Open the Agentic Loop Simulator and press Play. Then flip the judge off and run it again. The difference is the whole lesson.

How this maps to Claude Code

If you want to build this for real rather than watch it:

Plan and Judge are work you hand to a subagent, often a different model, so the judge is independent of the builder.
Build is the main agent using its Read, Edit, and Bash tools to change the code.
The loop runs until a goal condition or a turn limit, the same way a harness keeps an agent going until the work is genuinely done.
Isolation matters once you run more than one loop at a time. Give each agent its own git worktree so parallel edits cannot collide.

Where this is heading

The people closest to this are not subtle about it. NVIDIA's Jensen Huang put it as "nobody writes prompts anymore, the new job is to write and handle loops." Andrew Ng has said essentially all of his own tasks now run through agents. Boris Cherny frames overnight fleets of looping agents as simply how engineering is done now.

You do not have to accept the strongest version of that to take the useful part. Whether you run one loop by hand or a hundred unattended, the same rules hold: give the loop a checkable goal, split the builder from the judge, and put a limit on it. Get those three right and a loop stops being a party trick and starts being a reliable way to get work done.

Summary

An agentic loop is the cycle that turns a model that answers once into an agent that finishes the job: plan, build, judge, repeat until the goal is met. The reliable version keeps the judge as a separate agent so the loop cannot pass its own bad work, and it always carries a stop condition because cost compounds as the context grows. Prompting is not dead, but it is no longer the whole skill. The new skill is designing the loop around it. Go watch one run, then build your own.

The Docker AuthZ Bypass Is Back: CVE-2026-34040

DevOps Daily Team — Tue, 07 Jul 2026 09:00:00 GMT

If you run an authorization plugin in front of the Docker daemon to decide who can do what, there is a good chance you assumed the plugin sees every request in full before it says yes or no. CVE-2026-34040 breaks that assumption. A specially crafted API request reaches the plugin stripped of its body, so the plugin approves a call it would otherwise deny.

The uncomfortable part is that this is not new. It is an incomplete fix of CVE-2024-41110, the maximum-severity AuthZ bypass patched back in July 2024. The same empty-body trick that was supposed to be closed is exploitable again in Docker Engine (Moby) before version 29.3.1.

TLDR

What: CVE-2026-34040, an authorization plugin (AuthZ) bypass in Docker Engine / Moby, CVSS 8.8. Classified as CWE-288, authentication bypass through an alternate channel.
How: A crafted request is forwarded to the AuthZ plugin without its body. The plugin evaluates an incomplete request and allows what it should block.
Why it matters: It re-opens CVE-2024-41110. If an AuthZ plugin is your access-control boundary for the daemon, that boundary has a hole.
Fix: Upgrade to Docker Engine / Moby 29.3.1 or later. Then stop treating an AuthZ plugin as your only guardrail.

Prerequisites

A host running Docker Engine (Moby) where you can check the version and upgrade.
You use, or are considering, an authorization plugin (OPA-based, Casbin-based, Twistlock/Prisma, or a homegrown one) to gate access to the daemon.
Basic familiarity with how the Docker daemon exposes its API over a socket.

How the bypass works

Docker authorization plugins sit between the daemon and every API call. When a request comes in, the daemon forwards it to the plugin, the plugin returns allow or deny, and only then does the daemon act. Plugins routinely make decisions based on the request body, for example blocking POST /containers/create when the body asks for Privileged: true or a host path bind mount.

The bug is that under specific conditions the daemon forwards the request to the plugin without the body. The plugin sees the method and the path but not the payload it needs to judge. A rule like "deny privileged containers" never fires, because from the plugin's point of view there is no Privileged field to object to. The daemon then executes the full request, body and all.

   attacker                dockerd                 AuthZ plugin
      |  POST /containers/create |                      |
      |  {Privileged: true}      |                      |
      |------------------------->|  forward (no body)   |
      |                          |--------------------->|
      |                          |     allow (nothing   |
      |                          |<---------------------|  to deny)
      |                          |                      |
      |        201 Created (privileged container runs)  |
      |<-------------------------|                      |

This is the same class of flaw as CVE-2024-41110, which scored a perfect 10.0 and was patched in Docker Engine 23.0.14 and 27.1.0 in July 2024. The 2024 fix did not fully close the path, so the bypass is reachable again. CVE-2026-34040 is fixed in Moby 29.3.1.

Warning

This is an exploit against your access-control layer, not a remote code execution in the daemon itself. The risk is that a caller who is supposed to be restricted, for example a CI job or a tenant limited by policy, can escalate to actions the plugin was meant to forbid. Anyone who can reach the daemon API is in scope.

Are you affected?

You are exposed if both of these are true:

Your Docker Engine / Moby version is older than 29.3.1.
You rely on an authorization plugin to enforce what callers may do.

Check the running version:

If Server.Version is below 29.3.1 and Plugins.Authorization is not empty, patch.

If you do not run an AuthZ plugin at all, this specific CVE does not apply to you, but read the last section anyway, because it explains why an AuthZ plugin alone was never enough.

Fix it

The direct fix is the upgrade. Do the daemon, not just the client.

# Debian/Ubuntu, using Docker's apt repo
sudo apt-get update
sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.io

# confirm the server is now 29.3.1 or later
docker version --format '{{.Server.Version}}'

# restarting the daemon is disruptive to running containers on that host;
# drain the node first if it is part of a Swarm or an orchestrated pool
sudo systemctl restart docker

On managed platforms you usually do not control the engine version directly. For a Swarm or a self-managed fleet, roll the upgrade node by node behind a drain. On a hosted container service, check the provider's engine version and security bulletins, since they patch on their own schedule.

Defense in depth: stop leaning on the plugin alone

The real lesson of a bug that comes back is that a single authorization plugin is a fragile boundary. Harden the layers around it.

Lock down the socket. The Docker daemon socket is root-equivalent. Do not mount /var/run/docker.sock into containers, and do not expose the API over TCP without mutual TLS. Most AuthZ-bypass paths stop mattering if untrusted callers cannot reach the API in the first place.
Least privilege at the edges. Give CI runners and tenants the narrowest access they need. Prefer rootless Docker or a brokered build service over handing out daemon access and hoping the plugin holds.
Do not pass privileged flags by default. Policy at the plugin is a backstop, not the primary control. Bake safe defaults into the platform, for example templates that never set --privileged or bind-mount the host root.
Watch for the tell. Log AuthZ plugin decisions. A spike in allowed create calls with unusually small request sizes, or allows where you would expect denies, is worth an alert.

Tip

Treat the AuthZ plugin as one control in a chain, socket access, network policy, least privilege, safe defaults, and audit logging. When any single link fails, as this CVE shows it can, the others should still hold.

Summary

CVE-2026-34040 is a reminder that "patched" is not the same as "closed." An incomplete fix of the 2024 Docker AuthZ bypass means a crafted request can once again reach your authorization plugin without its body and get waved through. Upgrade Docker Engine / Moby to 29.3.1, confirm the server version rather than the client, and use the outage as a prompt to make sure the plugin was never the only thing standing between an untrusted caller and a privileged container.

PostgreSQL 18.2 Broke Standbys: The 18.x Upgrade Footguns

DevOps Daily Team — Tue, 07 Jul 2026 09:00:00 GMT

Minor PostgreSQL releases are supposed to be the boring ones. You read a short list of bug fixes, restart during a quiet window, and move on. PostgreSQL 18.2, shipped on February 12, 2026, was not boring. Its fixes over-corrected in a way that halted standby servers, made substring() throw on perfectly valid data, and crashed pg_trgm. The problems were serious enough that the project shipped an out-of-cycle 18.3 two weeks later, on February 26, to undo the damage.

If you run Postgres 18 in production, or you are about to upgrade to it, this is worth ten minutes. The regressions are real, and the quieter Postgres 18 upgrade footguns around them catch teams every week.

TLDR

18.2 broke three things: standbys halting with could not access status of transaction, a substring() encoding error on non-ASCII data, and a pg_trgm crash in strict_word_similarity().
The cause: two of them were security fixes that were too aggressive. The substring() regression came from the CVE-2026-2006 fix, the pg_trgm crash from the CVE-2026-2007 fix. The standby failure was a separate multixid wraparound bug.
The fix: upgrade to 18.3 (out-of-cycle, February 26) or later. No dump and restore is needed between 18.x versions.
Watch the quieter traps too: Postgres 18 turns data checksums on by default, which trips up pg_upgrade, plus the usual extension and replication checks.

Prerequisites

A PostgreSQL 18 deployment, or a plan to move to it from 17.
Access to run minor upgrades and restart the server in a maintenance window.
If you replicate, the ability to coordinate the upgrade across primary and standbys.

What 18.2 actually broke

Standbys halting on WAL replay

The headline failure: a standby replaying WAL that involved multixid truncation from an older minor version would stop with:

FATAL:  could not access status of transaction 1234567
DETAIL:  Could not open file "pg_multixact/offsets/....": No such file or directory

The bug was in the logic that handles multixid wraparound coming from a previous version. The typical trigger is a standby on the latest minor version consuming WAL from an older primary, exactly the mixed-version state you pass through during a rolling minor upgrade. A halted standby means no read replica and no failover target until you fix it.

substring() throwing on valid text

The CVE-2026-2006 fix tightened multibyte character validation to prevent a buffer over-read. It was too strict. On TOASTed (compressed) values containing non-ASCII characters, substring() and friends began raising spurious errors about incomplete characters on data that was completely valid:

ERROR:  invalid byte sequence for encoding "UTF8": 0x..

Any query slicing text out of a column with, say, accented names or emoji could start failing. The 18.3 fix refined the validation so it stops crying wolf.

pg_trgm crashing outright

The CVE-2026-2007 fix introduced a worse failure. In strict_word_similarity() and related pg_trgm functions, an internal bounds array that needed to grow did not return the updated pointer, so the function read freed memory. The result was a crash or garbage output, most reliably on input strings with more trigrams than first estimated, especially lowercased text under ICU locales with single-byte encodings. For anyone using pg_trgm for fuzzy search, that is a query that can take the backend down.

Warning

Two of these regressions were themselves security fixes. That is the trap with minor releases: the same update that closes a CVE can open a functional regression. Read the release notes for the version you are jumping to, not just the one you are on.

Fix it: get to 18.3 or later

The fix is the upgrade. Minor PostgreSQL releases do not require a dump and restore, so it is an install plus a restart.

If you replicate, upgrade the standbys first, then the primary, so you never run a standby that is older than its primary. Because the standby regression triggered on mixed versions, the goal is to spend as little time as possible in a split-version state, and to land everything on 18.3 or newer (18.4 is out too).

The quieter Postgres 18 upgrade footguns

Most of the pain around Postgres 18 is not the 18.2 regressions, it is the major-version jump from 17. Three traps show up again and again.

Checksums are on by default now

Postgres 18 flips data checksums on by default at initdb. That is a good default, but pg_upgrade refuses to run when the old and new clusters disagree on checksums. If your 17 cluster was created with the old default (checksums off) and you initdb an 18 cluster with the new default (on), the upgrade stops cold.

# check the old cluster
psql -tAc 'show data_checksums'    # -> off

# option A: enable checksums on the old cluster first (offline; can be slow)
pg_checksums --enable -D /var/lib/postgresql/17/main

# option B: create the new cluster without checksums to match
initdb --no-data-checksums -D /var/lib/postgresql/18/main

Pick one before you run pg_upgrade, not after it fails halfway.

Extensions, especially pgvector

pg_upgrade will happily migrate the catalog and leave you with an extension the new binaries cannot load. Confirm that every extension you use, pgvector above all given how many teams now depend on it, has a build for Postgres 18 installed on the new cluster before you cut over. Check pg_extension on the old cluster and match every entry.

Test replication and failover, not just the primary

A major upgrade is exactly when replication edge cases surface, from conflict handling to slot state. Do a full rehearsal on a copy: upgrade, reconnect the standby, force a failover, and read from the promoted node. Finding a broken replica in staging is a Tuesday. Finding it during a real incident is not.

Tip

Before any Postgres upgrade, write down your rollback. For a minor release that is "reinstall the previous package and restart." For a major one it is your pre-upgrade backup plus the old data directory, which pg_upgrade preserves unless you pass --link. Know which one you are relying on.

Summary

PostgreSQL 18.2 is a case study in why minor upgrades still deserve a read of the release notes: two security fixes over-corrected into a substring() error and a pg_trgm crash, and a separate multixid bug halted standbys mid-upgrade. The out-of-cycle 18.3 fixes all three, so get there or later. And when you make the bigger jump from 17 to 18, clear the quieter traps first, checksums now default on, every extension rebuilt, and replication rehearsed, so the boring upgrade stays boring.

Presigned-URL Uploads From a Serverless Function

DevOps Daily Team — Mon, 06 Jul 2026 09:00:00 GMT

The naive way to accept file uploads is to POST them to your API, let the server read the bytes, and write them to object storage. It works until the files get large or the traffic gets real. Now every upload crosses your infrastructure twice, once from the client to your server and once from your server to storage, and your server holds the whole file in memory or on disk while it does. On a serverless function it is worse, because functions have request-size and duration limits that a big upload runs straight into.

Presigned URLs are the standard fix, and they predate serverless by a decade. Your server does not move the bytes; it hands the client a short-lived, pre-authorized URL and the client uploads directly to object storage. The server only issues permission and records metadata. On a Neon Function this is the same AWS S3 SDK you already use, pointed at the branch's storage endpoint. This post builds it and tests the whole round trip. The repo is at the end.

TL;DR

Proxying uploads through a function sends the bytes across it, burning bandwidth and memory and hitting request-size limits.
A presigned URL is a time-limited, pre-authorized link to one object key. The client PUTs the bytes straight to storage; the function never touches them.
On Neon Functions you generate it with getSignedUrl from @aws-sdk/s3-request-presigner, the same code as any S3-compatible store.
I tested the full flow: presign, the client PUT straight to storage returned 200, a metadata record was saved, and downloading the object returned the exact bytes.
One gotcha to pin: the injected AWS_REGION is the storage-cell host, not a region, so set region: 'us-east-2' on the client.

Prerequisites

A Neon project on the platform preview with a declared bucket (object storage, us-east-2)
The AWS SDK: @aws-sdk/client-s3 and @aws-sdk/s3-request-presigner
Familiarity with S3-style object storage and HTTP PUT

Why not just proxy the upload

Sending the file through the function has three costs that all get worse with size:

Bandwidth doubles. The bytes travel client → function → storage. You pay for both hops.
The function holds the file. It buffers the body to forward it, so memory scales with upload size and concurrency.
Limits bite. Serverless request-body caps and duration limits turn a large upload into a failed request, not a slow one.

The presigned pattern removes all three, because the large transfer never involves the function.

The flow

Hover the browser to see it in action: it talks to the function for a presigned URL and to write metadata, but the large transfer goes straight to object storage. Those function round trips are tiny JSON requests. The only large transfer, the bytes themselves, never touches your code.

The code

Issuing the URL is one call. getSignedUrl signs a PutObjectCommand with an expiry; the client then uses that URL as a plain HTTP PUT.

import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
import { getSignedUrl } from '@aws-sdk/s3-request-presigner';
import { randomUUID } from 'node:crypto';

// The runtime injects the storage endpoint and credentials. Pin the region:
// the injected AWS_REGION is the storage-cell host, not a usable region.
const s3 = new S3Client({
  region: 'us-east-2',
  endpoint: process.env.AWS_ENDPOINT_URL_S3,
  forcePathStyle: true,
});

// POST /files/presign  ->  { key, uploadUrl }
app.post('/files/presign', async (c) => {
  const { filename, contentType } = await c.req.json();
  const key = `uploads/${randomUUID()}-${filename}`;
  const uploadUrl = await getSignedUrl(
    s3,
    new PutObjectCommand({ Bucket: 'files', Key: key, ContentType: contentType }),
    { expiresIn: 3600 }, // one hour
  );
  return c.json({ key, uploadUrl });
});

After the client uploads, it tells the function to record the file. That is an ordinary insert; the bytes are already in storage.

// POST /files/confirm  ->  saved row
app.post('/files/confirm', async (c) => {
  const { key, filename, contentType, bytes } = await c.req.json();
  const [row] = await db.insert(files).values({ key, filename, contentType, bytes }).returning();
  return c.json(row, 201);
});

The three moving parts, from the browser's side, look like this:

The tested round trip

I ran the whole sequence against the deployed function. The key line is the direct PUT to storage returning 200 without the function in the path, and the downloaded object matching what was uploaded.

Downloads work the same way

The reverse direction is identical: presign a GetObjectCommand and either redirect the client to it or return it. The bytes stream from storage to the client, not through the function, and the URL expires. The demo's GET /files/:id does exactly that.

Warning

Presigned URLs are capability tokens. Two things to get right: keep expiresIn short (minutes, not days) so a leaked URL is not useful for long, and never presign a key taken raw from user input. Generate the key server-side (the demo uses a UUID prefix) so a caller cannot request a URL for someone else's object. If you need to cap upload size, presign with a content-length condition.

The repo

The full files API, direct upload plus this presigned flow, is here:

Wrapping up

Presigned URLs are one of those patterns that stay correct no matter where the code runs, and serverless is exactly where they pay off most, because the function's request limits make proxying large uploads a non-starter. On Neon Functions it is the same S3 SDK you already know, pointed at the branch's storage endpoint, with one config line to pin the region. The function hands out permission, the bytes go straight to storage, and your metadata stays in Postgres next to everything else.

DevOps Weekly Digest - Week 28, 2026

Mon, 06 Jul 2026 00:00:00 GMT

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

⚓ Kubernetes

📄 CloudNativePG 1.30.0 Released!

The CloudNativePG Community is excited to announce the immediate availability of CloudNativePG 1.30.0! This minor release introduces the new DatabaseRole CRD for declarative, GitOps-friendly PostgreSQ

📅 Jul 6, 2026 • 📰 PostgreSQL News

	One shared bucket	Bucket on the branch
A branch's files	The real production objects	A copy-on-write copy
Preview can corrupt prod files	Yes	No
Point-in-time snapshot of rows + files	No	Yes
Per-branch setup	Prefix convention + copy script	None; declared once in `neon.ts`
Cleanup	Manual object deletion	Delete the branch

	Dedicated websocket service	LISTEN/NOTIFY + SSE on a function
Extra infrastructure	A service to run, scale, secure	None; uses Postgres + the function
Direction	Bidirectional	Server to client (SSE)
Fan-out bus	The service	Postgres `NOTIFY`
Delivery	Often buffered / retried	Best-effort; dropped if no listener
Best for	Chat, cursors, games, huge fan-out	Live counters, feeds, notifications, presence

If your top priority is...	Start with	Why
Closest Firebase-like DX, but relational	Supabase	Postgres + familiar SDK, RLS, realtime
Database + a branch-per-PR workflow	Neon	Serverless Postgres with branching; platform preview adding functions/storage/auth
Owning and self-hosting everything	Appwrite	Full BaaS surface on your own infra
Dead-simple, single-server, cheap	PocketBase	One Go binary, SQLite, zero ops
Realtime reactivity as the core	Convex	Reactive TS queries, now self-hostable
GraphQL-first team	Nhost	Postgres + Hasura GraphQL
Committed to AWS	Amplify Gen 2	TS-first on-ramp to AWS services
Edge-first, compose-your-own	Cloudflare	Workers + D1 + R2 + Durable Objects
Just one missing piece	Clerk / WorkOS / Ably	Best-in-class single slice

	Shared staging backend	Branch per PR
Isolation	One database for all PRs	Own database + data + URL per PR
Migrations	Collide across PRs	Run only against that branch
Data realism	Thin seed fixtures	Copy-on-write copy of real data
Teardown	Manual, scary, shared	Delete the branch, everything goes
Idle cost	An always-on staging box	Copy-on-write storage + scale-to-zero compute

You are using...	SSH comes from	Affected by CVE-2026-55200?
`ssh`, `scp` (OpenSSH), `sshd`	OpenSSH's own code	No
The plain `git` CLI over SSH	Shells out to the OpenSSH `ssh` binary	No
`curl scp://` / `sftp://`	libssh2 (if built with it)	Yes, if libssh2 ≤ 1.11.1
`pygit2` / `nodegit` / libgit2 tools	libgit2's SSH backend	Yes, if built against libssh2 ≤ 1.11.1
PHP `ssh2`, `ssh2-python`	libssh2	Yes, if libssh2 ≤ 1.11.1

	bigint sequence	uuidv4 (random)	uuidv7 (time-ordered)
Size	8 bytes	16 bytes	16 bytes
Insert locality	Sequential (best)	Random (worst)	Sequential
Generate without the DB	No	Yes	Yes
Reveals row count or order	Yes	No	Partially (creation time)
Leaks creation time	No	No	Yes

Server	Before	After	Change
CAX11 (ARM, DE/FI)	€4.49/mo	€5.99/mo	+33%
CCX13 (dedicated vCPU, DE/FI)	€15.99/mo	€42.99/mo	+169%
CPX41 (US region)	€38.99/mo	€120.49/mo	+209%

Stage	Compute (avg)	Active time	DB size	MAU	Branches/mo	Egress
Launch month	0.25 CU	20%	1 GB	500	10	5 GB
First customers	0.25 CU	45%	5 GB	5k	30	25 GB
Product-market fit	0.5 CU	75%	20 GB	30k	60	100 GB
Growth	1 CU	95%	60 GB	120k	120	400 GB
Scale	2 CU	100%	200 GB	400k	200	1.5 TB

Platform	Median	p95	Range
Neon	5.7 s	8.8 s	3.5 s to 13.6 s
Supabase	7.4 s	11.8 s	6.5 s to 11.9 s

	Neon free	Supabase free
Database storage	0.5 GB per project	500 MB
Projects	up to 100	2 active
Compute	100 CU-hours/project/month, autoscaling to 2 CU	dedicated Nano instance, always on
Idle behavior	scales to zero after 5 min, auto-wakes in ~570 ms	project pauses after 7 days, manual restore
Branching	10 branches/project, data included, ~2.2 s	not available
Restore window	6 hours	none (daily backups start on Pro)
Extras		Auth (50K MAU), storage (1 GB), edge functions (500K), realtime
Direct connection	IPv4 + IPv6	IPv6 only (pooler for IPv4)

Algorithm	Allows bursts	Memory per client	Accuracy	Use when
Fixed window	At the boundary (bad)	1 integer	Low	Rough internal limits
Sliding window log	No	1 entry per request	Exact	Low-volume, precise rules
Sliding window counter	Smoothed	2 integers	High	General-purpose default
Token bucket	Yes, up to capacity	small hash	High	Public APIs, most cases
Leaky bucket	No	queue	High	Protecting a fixed-rate downstream

Date	Hetzner communication	What changed
February 2, 2026	Statement on the adjustment of setup fees	Hetzner said dedicated server setup fees were changing because RAM and NVMe SSD procurement costs had risen.
February 23, 2026	Statement on price adjustment as of April 1st 2026	Hetzner announced price changes for existing products and new orders effective April 1.
April 29, 2026	Statement on the latest adjustment to setup fees	Hetzner adjusted dedicated server setup fees again.
May 27, 2026	Standardization and price adjustment effective June 15, 2026	Hetzner announced the new product structure and monthly price increases for new orders and rescales.

DevOps Daily

Per-Branch AI Endpoints: Isolating Model Spend Across Prod, Preview, and CI

Stop Prompting, Start Looping: Agentic Loops Explained

The Docker AuthZ Bypass Is Back: CVE-2026-34040

PostgreSQL 18.2 Broke Standbys: The 18.x Upgrade Footguns

Presigned-URL Uploads From a Serverless Function

DevOps Weekly Digest - Week 28, 2026

Object Storage That Branches With Your Database