The PHP security team has announced an emergency release to address two critical vulnerabilities, each rated 9.2 under CVSS v4.0. Researchers are tracking the reported issues as CVE-2026-109618 and CVE-2026-109619. PHP plans to publish its security release on October 21, 2026 at 14:00 UTC and has urged users to prepare to update promptly. Read PHP's security announcement and its advisories for CVE-2026-109618 and CVE-2026-109619.

Bunny Shield has expanded its managed WAF coverage with two additional multipart rules, alongside the upload-progress rule we activated ahead of the release. These rules target specific request patterns described in PHP's advisories while customers update their PHP installations. They block matching requests only when your Shield Zone's WAF is in blocking mode.

Understanding the vulnerabilities

CVE-2026-109618 - RCE via OOM corruption

PHP's out-of-memory handling can interrupt a request while internal data is only partly initialized. Cleanup can then use that invalid data. PHP has demonstrated unauthenticated code execution against mod_php before application code runs. Its advisory describes several ways multipart requests can drive memory exhaustion, including requests without a usable declared length and deeply nested field names.

CVE-2026-109619 - RCE via stale global state

Request-owned state can remain accessible after its memory is freed. A later request handled by the same worker may encounter that stale state before PHP resets it. PHP confirms a session upload-progress path, as well as other paths involving fatal errors and early initialization. Blocking the default upload-progress field addresses one request pattern; it does not cover every path to this vulnerability.

Fixed PHP versions

How Bunny Shield protects your site

Three managed WAF rules now address request patterns associated with the confirmed paths:

What you should do now

• Identify every PHP origin and version serving your websites, including sites behind content management systems and custom applications.
• Prepare to install PHP's fixed releases when the official advisory is published. Confirm the effective runtime version after updating; a WAF is an additional layer, not a substitute for the software fix.
• Check whether your application uses session upload progress. If it does not, consider disabling session.upload_progress.enabled in the effective PHP configuration. PHP documents this setting; turning it off prevents that feature from recording progress, but does not disable multipart upload parsing or establish a fix for either CVE.
• Keep Bunny Shield enabled and review security events for blocked requests. If your application relies on PHP session upload progress, test that workflow and contact support if it is affected.

Protection while you update

Security releases can take time to reach every server, especially across large fleets and managed hosting environments. Bunny Shield is already blocking the public request pattern before it reaches an origin while teams complete their PHP update rollout. We will keep monitoring the official advisory and new exploit research, then refine our protections as verified details become available.

To get started with Bunny Shield, log in to your bunny.net account or sign up. Keep PHP updated even when your site is protected at the edge.When your Shield Zone's WAF is in blocking mode, Bunny Shield blocks matching requests before they reach your origin. In log-only mode, these rules do not block requests. We respect the mode configured for your zone.

These rules reduce exposure to the request patterns they match; they are not complete mitigations for either CVE. Other routes to memory exhaustion or stale state are possible, and a customized upload-progress field name will not match the default-field rule. Applications using PHP session upload progress or unusually deep form fields may have legitimate requests matched by these rules. Review affected workflows and your Shield security events.

What you should do now

• Patch PHP immediately to the fixed release for your branch, or install your distribution's verified backport. Check every PHP origin and restart workers as required by your deployment.
• Check your Bunny Shield WAF mode. Use blocking mode if you want these managed rules to stop matching requests. Log-only mode will not block them.
• Review upload workflows and security events, particularly if your application uses session upload progress or deeply nested fields.
• Follow PHP's temporary guidance if you cannot update at once. Its advisory covers administrative memory and request-size limits, and disabling session.upload_progress.enabled with a worker restart for the confirmed session path. These measures reduce exposure to particular paths; PHP says updating is the only complete solution.

Protection while you update

Bunny Shield can block the two identified request patterns at the edge for customers using WAF blocking mode. We'll continue reviewing PHP's advisories and emerging attack techniques and refine our managed rules as needed. Install the PHP security release even if Bunny Shield is blocking traffic: the vulnerabilities have paths outside these WAF matches.

To get started with Bunny Shield, log in to your bunny.net account or sign up.

Building a mobile app with React Native helps you move quickly. Adding video should feel just as straightforward. But between playback, uploads, device cameras, even a simple idea can turn into a long list of integrations.

When we introduced the Bunny Stream Mobile iOS and Android SDKs, we made it easier to bring video to native iOS and Android applications. Today, we're bringing that experience to more developers with the official Bunny Stream React Native SDK!

Built on our iOS and Android SDKs, it brings native playback, resumable uploads, camera capture, and live streaming together behind one TypeScript API. You build your app with familiar React components. Bunny Stream handles video encoding, storage, and delivery through our global CDN. We’ve also bundled in an Expo config plugin for faster integration with Expo React Native apps.

One integration for iOS and Android

The Bunny Stream React Native SDK connects your shared application code to the native Bunny players and media tools on each device, so you don’t need to build separate integrations for every platform.

Resumable uploads for unreliable mobile connections

Mobile connections don't always cooperate. With TUS resumable uploads, an interrupted transfer can pick up where it left off instead of sending the whole video again. Progress events and pause, resume, and cancel controls make it easy to build an upload experience that keeps people informed.

Select TUS when starting an upload to enable resumable transfers. See the upload notes for recovery and platform-specific background behavior.

Familiar components, native playback

Add on-demand or live video with BunnyStreamPlayer. Playback runs through the native media engines on iOS and Android, while typed props, events, and React hooks help you connect the player to the rest of your app.

Player settings from your Bunny Stream dashboard carry through to the native experience, helping you keep your videos consistent with your brand. Captions, audio track selection, and adaptive playback give your audience the controls they expect.

From camera to content

Let your users create as well as watch. Capture video directly from the device camera for your video library, or use BunnyStreamBroadcaster to go live from your app. Camera switching and microphone controls put the essentials within reach.

More ways to watch

Give viewers more room to enjoy their content with fullscreen playback, picture-in-picture, AirPlay on iOS, and Chromecast on Android through the native player controls. For protected content, the SDK brings support for Apple FairPlay and Google Widevine. VAST/IMA ad support also connects your app to Bunny Stream's video monetization features.

For Android TV, an optional native TV player integration brings playback to the big screen with an additional SDK dependency.

Broadcast live, replay later

Live streaming support is built right into the SDK. Use BunnyStreamBroadcaster to broadcast straight from your users’ phones via RTMP, with camera switching and microphone controls, then show the stream to viewers with the same BunnyStreamPlayer component you use for on-demand video.

Features like DVR let viewers rewind a live event, while recordings keep it available for replay afterward.

Our Live streaming feature is currently in closed preview and being tested by fellow bunny.net users. If you’d like to try it, you can request access through the banner in the dashboard (in any of your video libraries).

Using Expo? You're invited too.

Using Expo requires Expo SDK 52+. The included Expo config plugin applies the native project configuration needed by the library during pre-build. Add it to your app configuration and create a development build locally or with EAS Build. Expo Go is not supported because the SDK uses native modules.

The SDK targets iOS and Android and uses React Native's New Architecture. Android requires API 26+; the setup guide covers the remaining native build requirements.

Install the package:

npm install @bunny.net/stream-react-native

For Expo projects, add the plugin to your existing app configuration:

{
  "expo": {
    "plugins": ["@bunny.net/stream-react-native"]
  }
}

The repository's setup guide covers native setup, initialization, and camera and microphone permissions. The plugin supplies default iOS permission messages; customize them through the cameraPermission and microphonePermission plugin options. Example apps for React Native and Expo give you a starting point to explore.

Let’s get to the code

Once you've completed setup and initialized the SDK with your library configuration, adding a video looks like this:

import { BunnyStreamPlayer } from '@bunny.net/stream-react-native';

export function VideoScreen() {
  return (
    <BunnyStreamPlayer source={{ type: 'vod', videoId: 'YOUR_VIDEO_ID' }} style={{ flex: 1 }} />
  );
}

Showing a live stream uses the same component. Change the source:

source={{
  type: 'live',
  streamId: 'YOUR_STREAM_ID',
}}

libraryId falls back to the library passed to initialize() for both VOD and live sources. Provide it explicitly on a source to override the initialized library.

The SDK also gives you typed APIs for managing videos, collections, live streams, captions, reencoding, and AI transcription, so your integration can grow beyond the player as your app grows. Alongside these APIs, BunnyImage helps display thumbnails and other Bunny-hosted images with support for CDN hotlink protection. See the platform notes for links to operation-specific limitations.

What will you build?

• Streaming and subscription apps: Bring your video catalog into one mobile experience, with protected playback and big-screen viewing options. Great for microdramas.
• Social and creator platforms: Let your community capture, upload, and broadcast from their phones, then keep recorded events available for anyone who missed them.
• Education and e-learning: Combine on-demand lessons with scheduled live classes. DVR helps learners revisit a tricky explanation, while recordings let them catch up later.

Ready to hop in?

Adding video shouldn’t take away from building the experience your audience comes for. With Bunny Stream for React Native and Expo, native video tools are now part of your React workflow.

Explore the official Bunny Stream React Native mobile SDK on GitHub, try the example apps, and bring your next video idea to life.

Built with expertise from Lighthouse Growth

The Bunny Stream React Native SDK was developed with support from Lighthouse Growth, a software development company with deep expertise in OTT, video streaming, and media technologies.

Their team brings hands-on experience building video platforms, mobile applications, and SDKs across iOS, Android, and React Native, and helped us make native-grade video capabilities more accessible to the React Native and Expo community. If you're building in this space, feel free to get in touch with them on LinkedIn.

If you've hosted a static site on bunny.net, you've probably built your own deploy pipeline to do it. That means creating a storage zone, putting a pull zone in front of it, pointing your domain at it, and writing something to upload each build and purge the cache. There's even a community GitHub Action that handles the upload part.

Today we're introducing bunny sites, a set of commands in the bunny.net CLI that takes care of all of that for you. Run bunny sites deploy in your project, and it puts your build live, creating the storage zone and pull zone on the first deploy. It also detects common frameworks and offers to run the build for you. bunny sites domains add connects your own domain, setting up the DNS record for you if it's on Bunny DNS. And if a release goes wrong, rolling back is one command.

Deploy with one command and connect to GitHub

bunny sites deploy takes the folder your framework builds and ships it on the bunny.net global network:

bunny sites deploy

That one command uploads your build and puts it live. There is no separate publish step and no flag to remember: if the deploy succeeded, your site is serving it. A brand-new site gets a working HTTPS address on b-cdn.net immediately, so there are no DNS records or certificates to sort out before you can look at it.

If you’d prefer not to run the command manually for each deploy, you can connect GitHub with a new GitHub Action. bunny sites ci init scaffolds the workflow using the detected framework conventions, including the output folder and build command. Review the generated workflow and adjust it to fit your setup.

With this workflow, pushes to the main branch go live, and you can trigger a redeploy manually whenever you need one.

name: Deploy site
on:
  push:
    branches: [main]
  workflow_dispatch:

concurrency:
  group: bunny-sites
  cancel-in-progress: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      deployments: write # records the deploy in the repo's Environments
    steps:
      - uses: actions/checkout@v4
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - run: bun run build
      - uses: BunnyWay/actions/deploy-site@deploy-site_0.1.1
        with:
          site: my-site
          directory: dist
          api_key: ${{ secrets.BUNNYNET_API_KEY }}

Atomic deploys and instant rollback

Deploys are immutable. Each one is identified by your Git commit or a hash of its contents, so deploying the same output twice does nothing, and publishing never overwrites files in place. Publishing is a pointer flip and a cache purge, which means the site switches over atomically, with no window where visitors see half of one deploy and half of another.

It also means rolling back is instant. Every deploy you've shipped is still there, so undoing a bad release is one command:

bunny sites deployments list
bunny sites deployments publish --previous

No rebuild, no re-upload. The previous deploy is live again in seconds.

Bring your own framework

Developer tooling changes. Frameworks come and go, and we don't believe you should have to rebuild your project around a platform to deploy it.

If your framework generates static files, it works with bunny sites. Astro, Hugo, Jekyll, Gatsby, Eleventy, Docusaurus, Gridsome, or any other static site generator: we deploy the output. The CLI also detects common frameworks and offers to run the build for you.

Single-page apps work too. When the CLI recognizes a client-routed framework such as Vite, Angular, or React Router, or spots a build that looks like one, it configures the site to serve index.html for unknown paths, so a deep link survives a refresh. A 404.html in your build output becomes the not-found page for everything else.

How it works

bunny sites is glue around Storage, CDN, and DNS. There's no new hosting platform underneath, just the primitives developers have been stitching together themselves, wired up so you don't have to.

Creating a site provisions two things:

• a storage zone to hold your deploys,
• and a pull zone in front of it, with a handful of edge rules that decide which deploy answers each request.

Every deploy is uploaded to its own folder in the storage zone, named after your Git commit or a hash of its contents. Nothing in that folder is ever overwritten. One edge rule on the pull zone rewrites the incoming path into the live deploy's folder, so your site is always served from the root exactly as your framework built it. The CDN caches and serves the files directly from there, and a second rule blocks anyone from reaching a deploy folder by its internal path.

Publishing retargets that one rule and purges the cache, which is why going live and rolling back both take effect everywhere at once without a file moving.

Attach a custom domain with bunny sites domains add yourdomain.com to give production a proper address. If the domain is on Bunny DNS, the CLI offers to point the record at your site and issues the free SSL certificate; otherwise it prints the exact CNAME to set. Your site's b-cdn.net address keeps working either way.

Because deploys are never deleted automatically, deploy history accumulates over time. When you want to tidy up, bunny sites deployments prune clears out old deploys, always keeps your most recent ones, and never touches the deploy that's live or the one before it, so rollback always works.

Framework detection works much the same way you would do it by hand. When you run a deploy in a project the CLI hasn't seen before, it inspects the project to work out which framework you're using and where its build output lands, then offers to run the build and deploy the result.

We don't build your site, we deliver it

We stick to our platform primitives and give developers the resources to build and deploy in whatever way suits them.

You control the build in whatever CI provider and toolchain you already use, whether that's npm, pnpm, Bun, Cargo, or a Makefile, and bunny sites deploy puts the files you give it in the right place across our global edge network.

Because it's built on the same infrastructure developers already trust, nothing is hidden behind an abstraction. You can enable and tune any feature of Bunny CDN, DNS, and Storage, and add products like Stream and Edge Scripting alongside your site as it grows.

Pay as you serve

Deploying withbunny sites doesn't introduce a new pricing model. You pay for the underlying bunny.net primitives:

• Storage: $0.01 per GB per month (standard tier, single region). Deploys are static files, so most sites cost fractions of a cent to store, even with previous deploys kept around for instant rollback.
• CDN: from $0.01 per GB of bandwidth (Europe & North America; other regions range up to $0.06/GB), with no per-request fees. Traffic between Storage and the CDN is free.
• DNS: free. Custom domains run on Bunny DNS at no cost, with unlimited queries.

Because everything is pay-as-you-go, your costs track actual traffic. A small site serving a few GB each month typically costs only a few cents. There's no idle charge for a site nobody visits beyond the $1 monthly account minimum. Delete a site and its zones, and it stops costing you anything.

Get started

Install the bunny.net CLI and log in:

npm install -g @bunny.net/cli
bunny login

Here's a real blog going onto the edge, using Astro's blog template. If Jekyll, Hugo, or Eleventy is more your thing, the steps are identical: build, deploy, done.

Scaffold the blog:

npm create astro@latest my-blog -- --template blog
cd my-blog

That gives you a complete blog with a few example posts, RSS, and a sitemap. Run npm run dev to have a look around, write a post if you like, then deploy it:

bunny sites deploy --build

Your first deploy creates the site and provisions the storage zone and pull zone. The CLI detects Astro, runs the build, uploads the output, and puts the site live. With no custom domain at this point, it offers to attach one before it finishes.

Every later deploy is the same command. Deploy the same output again and nothing is re-uploaded at all, because the deploy is identified by its contents.

When you want production on your own domain:

bunny sites domains add yourdomain.com

You can then run bunny sites ci init to wire up GitHub. Every merge to main ships to production, and you can trigger a redeploy by hand whenever you need one.

Faster images with Bunny Optimizer

Static builds are usually stuck with whatever image sizes the build produced. Because every site sits on a regular pull zone, you can turn on Bunny Optimizer and resize images at the edge instead. Point your framework's image loader at it, and each srcset width becomes a URL like /images/hero.png?width=640.

Next.js, Astro, Angular, and Nuxt all have a loader hook for this, and our static site examples include a small helper for 21 frameworks, off by default:

bunny sites deploy --build --env VITE_BUNNY_OPTIMIZER=true

Optimizer is an optional add-on at $9.50 a month per site.

What's next for bunny sites

For now, deploying static sites is CLI only, but we're experimenting with bringing it to the dashboard.

We're also actively working on deploying Edge Scripts automatically when you run bunny sites deploy, so when your site needs a form handler or other server-side code, it's right there alongside it. And for full server-side rendering, we're experimenting with support for SSR frameworks on Edge Scripting.

If any of this sounds interesting, let us know on Discord.

Putting the bunny.net stack in your terminal

bunny sites joins a growing set of CLI capabilities that let you and your agent use our platform from the terminal:

• Manage and query Bunny Database, plus handle database migrations
• Build and deploy edge functions
• Manage Bunny DNS
• Manage Bunny Storage
• Run code and agents in Bunny Sandbox

Support for Bunny Stream and Magic Containers Apps is coming next.

The CLI is open source and built in public. If you've deployed something with bunny sites, come and tell us about it in Discord.

Say your application runs in two regions, with a third held in reserve. You want the first two to share everyday traffic, and the standby region to step in when they cannot serve it. When an origin fails, those priorities should still determine where the request goes next.

At bunny.net, we want you to be able to express that plan once and have the CDN carry it through from normal traffic distribution to failover.

Today, we’re introducing Bunny CDN Load Balancer, available now in Public Preview. It distributes HTTP(S) requests from your Pull Zones across the origins you configure, using your routing preferences alongside origin health and performance.

Set priorities across your origin pool

A Load Balancer is a routing policy in your bunny.net account. Attach it to one Pull Zone or reuse it across several. Requests that need an origin follow that policy; cached responses continue to be served directly from the CDN edge.

Origin groups let you organize backends by region, provider, capacity, or purpose. In our example, the two primary regions would sit in the first priority tier, with the standby region in a later tier. Traffic can be shared across primary groups while backup capacity waits behind them.

You can spread traffic evenly, assign weights, or favor nearby or lower-latency groups. The pool can combine standard HTTP(S) servers, Bunny Storage, Edge Scripting, and Magic Containers, so your primary and standby capacity can use different types of backend.

Keep your priorities intact during failover

For each request that needs an origin, the edge builds an ordered list of eligible destinations before contacting the first one. It orders the origin groups, then the origins within them, according to your priority tiers and balancing settings.

When another attempt is safe, the next candidate is already known. In our example, eligible primary capacity stays ahead of the standby region throughout failover.

Retries also take account of what a request can do. After an origin returns a 5xx response, only requests that are safe to replay are tried again. Requests with a body, or a method that may create or change data, are not blindly repeated after that response. This reduces the risk of turning a failed request into a duplicate order, upload, or payment.

The failover chain has a time limit, so one request cannot keep working through slow origins indefinitely.

Respond to health at each edge

An origin can be reachable from the Frankfurt edge while a network problem prevents the São Paulo edge from reaching it. Load Balancer combines a network-wide health view with what each edge sees in live traffic.

Optional health checks monitor origins in a group from across the bunny.net network. A degraded origin is excluded from normal rotation globally until it passes a health check again. Each edge also reacts to failures it encounters locally, even when active checks are disabled, so it can respond to a problem affecting its own requests.

If no healthy origin remains, Load Balancer can attempt an unhealthy origin as a last resort. Origins and groups you explicitly disable stay excluded.

For applications that need repeat requests to reach the same origin, optional sticky sessions use an encrypted edge cookie to maintain that choice. Health takes precedence: if the chosen origin becomes unhealthy or unavailable, the visitor is assigned another origin.

Balance speed and capacity

Repeatedly sending traffic to the origin with the lowest measured latency can make it the busiest, eroding the speed advantage that put it first. That’s why latency-based origin balancing also considers requests already in flight. As an origin becomes busier, it grows less attractive for new requests, helping the rest of the pool share the load.

Stale and newly added origins are re-tested automatically. Probing backs off when they remain slow or unavailable, while recovered origins can be considered for traffic again.

Start balancing your origin traffic

Public Preview is available now for $9.50 per month per Load Balancer, including 50 million origin-bound requests each month. Additional requests are billed at $0.65 per million.

Requests served from the CDN cache do not count. Sharing a Load Balancer across multiple Pull Zones uses one monthly fee and one shared request allowance.

To get started:

• Create a Load Balancer and choose how traffic should be distributed between origin groups.
• Add your origin groups and the origins each should contain, setting priorities to reflect your primary and standby capacity.
• Set your Pull Zone’s origin type to Load Balancer and select the configuration you created.

Once traffic is flowing, use the dashboard or API statistics to see how requests are distributed, how each origin is performing, and where failover is happening. The Load Balancer documentation covers the routing, health-check, sticky-session, and API options in detail.

Log in or sign up today to join the Public Preview and start balancing your origin traffic with automatic failover.

In the traffic we analyzed for our 2026 Edge Security Report, AI crawlers were already matching search-engine bots by request volume.

Alongside those crawlers are assistants visiting websites to answer people’s questions. Sometimes, the agentic web is simply someone asking when their tea will ship. The shop has already published its shipping policy, but an assistant receives it wrapped in the HTML for navigation, layout, and everything else that makes the page work in a browser.

At bunny.net, we think making the internet hop faster includes helping these requests do less unnecessary work. An assistant can read HTML; a text-first version can give it the information with less presentation markup to process. We want that improvement to be something you can turn on for the website you already run, without a second publishing project to maintain.

Today, we’re launching Agent Readability in Bunny Optimizer in Public Preview. It automatically converts eligible HTML pages into Markdown and generates an llms.txt guide to help agents find them.

One page, optimized for different audiences

Take the sample About page below, for a tea company called Alder & Vine. Its shipping note survives the conversion intact: orders placed after noon Pacific ship the next business day. So do the headings, numbered list, and staff table. The site navigation and presentation markup are gone.

The company’s story comes through, too. You can still read about the trip that inspired it and the farms it works with today. Markdown keeps that context alongside the practical details an assistant might need. A person browsing the site continues to see the original design, while Optimizer creates the text version from the published HTML.

An agent can request the page with Accept: text/markdown or use its Markdown URL directly, for example https://bunny.net/docs/index.md on our documentation site.

Help agents find the right page

An assistant arriving at a documentation homepage still needs to work out where to go next. A setup guide, an account FAQ, and a changelog answer very different questions.

Optimizer also builds llms.txt automatically from the converted pages. Compatible agents can use the descriptions in this file to find relevant pages, then follow the links to retrieve those pages as Markdown.

The bunny.net documentation excerpt below shows how this helps with a specific task. An assistant helping someone get started can follow the quickstart entry, while one looking for recent changes can head to the changelog.

https://bunny.net/docs/llms.txt

Give it a try on your own site

Agent Readability is included with Optimizer at no additional cost. Optimizer is $9.50/month, and Public Preview for Agent Readability is available now.

Open your Pull Zone, go to Optimizer, and enable Agent Readability. Then turn on Markdown and llms.txt for your site.

If you haven’t enabled Optimizer yet, the Optimizer quickstart walks you through initial setup.

Start with a page customers regularly ask you about. Open its Markdown version and compare it with the original, just as we’ve done above. You can see the text an agent can retrieve, then use llms.txt to explore the other converted pages. Whether the question is about setting up a service or shipping a tin of tea, the answer can start with the content you already maintain.

Log in or sign up today and make the content you’ve already published easier for AI agents to find and use.

A shopper has loaded your site, filled their basket, and clicked checkout. The images are already on screen. Now they’re waiting for a request that has to reach your origin.

The route to your origin can be the difference between a smooth checkout and a customer left staring at a loading spinner. Uncached API calls and personalized responses depend on it too. At bunny.net, we want our network to help accelerate the parts of your application that need a fresh response from the origin.

That was the goal when we introduced Burrow Smart Routing last October. When the direct origin path is slow, Burrow can carry requests across our backbone and reach the origin through another bunny.net region with a faster route.

Today, Burrow Smart Routing is Generally Available within Bunny Optimizer. During Public Preview, we rebuilt the routing engine to discover useful paths sooner, respond faster to changing conditions, and be more selective about when rerouting is worthwhile.

Bringing a customer back online through Los Angeles

For one customer, congestion from a transatlantic fiber cut pushed latency between our Taipei region and their origin to around three seconds. The network incident was disrupting access to their site.

Burrow automatically rerouted that origin traffic through Los Angeles. Latency dropped to below one second, bringing the site back online for affected visitors while the underlying incident was still ongoing.

Discover faster origin routes with Active Origin Probing

The original Burrow learned from requests already traveling through the bunny.net network. A region could have a useful path to an origin and still be absent from the routing decision because it had never handled traffic for that site. Smaller sites, or those with visitors concentrated in one region, could wait longer for Burrow to gather enough evidence.

Active Origin Probing helps fill that gap. When enabled, it lets Burrow ask suitable regions near the origin to measure alternative paths when a direct connection is slow enough to benefit from a change.

The checks use the same request pipeline as real origin traffic, and their results are shared across the bunny.net network. A site can therefore discover useful routes within minutes, even without a large, globally distributed audience.

These measurements run in the background. Probing stops when Burrow has enough information and backs off when checks fail.

Reroute when the improvement is worthwhile

Sending a request through another region adds backbone traffic. A small fluctuation in latency should not be enough to justify that extra routing.

Burrow now leaves fast direct connections alone and requires a meaningful measured improvement before choosing an alternative. This helps keep your Burrow bandwidth allowance focused on requests that benefit from the extra route.

After switching, Burrow measures the full journey through the additional edge. The actual result replaces the earlier estimate, giving subsequent routing decisions evidence from the path your traffic is using.

Adapt as network conditions change

Burrow continues measuring the direct path after traffic moves to an alternative. When conditions recover, it can move requests back. Recent measurements now carry more weight, helping it respond sooner when a route improves or deteriorates while retaining useful context for quieter workloads.

Routing plans are refreshed in the background. If there is not enough evidence to choose an alternative, requests continue directly to the origin while Burrow gathers more information.

Give your dynamic traffic a faster path

Burrow Smart Routing is now Generally Available with Bunny Optimizer. Each Optimizer subscription includes 50 GB of Burrow-routed uncached traffic per month. Additional Burrow-routed traffic is billed at $0.06/GB. Cached responses served from the edge do not use Burrow or count toward that allowance.

Billing for additional Burrow-routed traffic begins on October 17, 2026. Until then, it's free for everyone, so you can try Burrow without any surprise charges.

To get started:

• Open your Pull Zone, go to Optimizer, and enable Optimizer if it is not already active.
• Open the Burrow tab and turn on Burrow Smart Routing.
• To use Active Origin Probing, first configure your origin to return a successful response at /.well-known/bunny-burrow-probe.txt, then enable the Active Origin Probing toggle in the same Burrow area.

Optimizer statistics show how many requests Burrow has optimized and an estimate of the time saved for your Pull Zone, so you can see what the routing is contributing to your application’s delivery.

Thank you to everyone who ran Burrow during Public Preview and helped us improve it.

Log in or sign up today and let Burrow find a faster route for your dynamic traffic.

Database migrations start simple. You need a users table, so you write some SQL. A week later you add an index, someone else adds a column, production needs another change, and staging is one migration ahead. Before long the SQL lives in a mix of folders, Slack messages, deployment scripts, and someone's Downloads directory.

Writing the SQL is the easy part. The part that gets messy is keeping track of what ran, where, and in what order.

bunny db now has a migration workflow built in. It's there for when you're using Bunny Database for the first time, starting a new project, or still haven'tsettled on a way to manage schema changes. Keep the migration workflow you already have if you like it.

Your first migration

Say we're building a small application backed by Bunny Database. We need somewhere to store users, so we create the first migration:

bunny db migrations create create_users

The CLI creates an empty, numbered SQL file:

migrations/
└── 0001_create_users.sql

Leave the name out and the CLI will ask you for one:

bunny db migrations create

Then open the file and write the schema change:

CREATE TABLE users (
  id INTEGER PRIMARY KEY,
  email TEXT NOT NULL UNIQUE,
  created_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP
);

The filename matters as much as the SQL inside it. It identifies the migration, and the numeric prefix decides the order things run in. As the application grows, the directory becomes a record of how the schema got to where it is:

migrations/
├── 0001_create_users.sql
├── 0002_add_display_name.sql
└── 0003_add_email_index.sql

Those files live alongside the code that depends on them, so they get committed to your repository and shared with everyone else on the team. The order is written into the filenames, and nothing important ends up sitting in a Downloads folder.

See what's waiting

Before you change anything, you can check where things stand:

bunny db migrations list

The CLI compares the migration files in your project against the migrations already applied to the database, then shows which are applied and which are still pending.

That's especially useful when others are involved. A teammate adds a migration for avatars, commits it with the application code that needs it, and pushes. You pull their branch and now have:

migrations/
├── 0001_create_users.sql
├── 0002_add_display_name.sql
├── 0003_add_email_index.sql
└── 0004_add_avatar_url.sql

Run list and you'll see that the first three applied and the fourth still waiting, so nobody has to ask whether they already ran this one.

You can also preview the run without touching anything:

bunny db migrations apply --dry-run

A dry run really is dry: it won't create the migration tracking table or change your database.

If it all looks right, apply the pending migrations:

bunny db migrations apply

The CLI runs them in order and records each successful migration in the database, so running apply again won't replay anything that has already gone through.

Each migration is applied together with the record that tracks it, as a single atomic operation. Either the migration succeeds and gets recorded, or neither happens. If one fails, the CLI stops there and leaves the remaining files alone. Fix the problem and run apply again; the failed migration is still pending.

The upshot is that a migration travels with the code that needs it. Nobody has to maintain a shared document reminding the team to run add-avatar-final-v2.sql, and nobody has to guess whether the SQL file in that folder ever made it to production.

Catching migration drift

There's a version of the scattered-migration problem that's harder to spot: someone changes an old migration after it has already run. Maybe 0002_add_display_name.sql gets edited during a refactor, or an old migration disappears from the repository entirely.

The CLI stores a checksum when it applies a migration, so bunny db migrations list can tell when the files on disk no longer match what the database remembers. Along with applied and pending migrations, it flags any that have been modified or are missing.

It won't guess what you meant, and it won't rewrite your database history to make the mismatch go away. The fix is usually the same one: leave the applied migration alone and write a new migration on top of it.

bunny db migrations create fix_display_name

Already using a migration tool

The best migration tool is often the one your project already has, and the built-in workflow isn't a requirement for using Bunny Database. If your application manages its schema with Drizzle, a Go migration tool, or your framework's own migration system, point it at your Database and carry on as usual. Your migrations can stay exactly where they are.

bunny db migrations is there for projects starting from an empty schema.

Generate with Drizzle, apply with the CLI

There's a middle ground for ORMs that generate plain SQL. Drizzle owns the schema and writes each migration file, and the bunny.net CLI applies that SQL to your Database and records what has run.

drizzle-kit generate
bunny db migrations apply

When there's no migrations/ folder, the CLI picks up drizzle/ on its own, splits each file at Drizzle's statement breakpoints, and leaves the meta/ journal alone. If you keep both folders, name the one you mean:

bunny db migrations apply --dir drizzle

The appeal is what you don't have to set up. The CLI finds the database from your .env and signs in with your bunny.net API key, so your app carries no database URL or long-lived token for migrations and you write no migrate script. You also get --dry-run, bunny db migrations list, and drift detection over the generated files.

Two rules keep this tidy. Generate every migration with Drizzle so it lands in Drizzle's journal, and skip bunny db migrations create in this setup. Pick one applier.

A default for your first database

If this is your first Bunny Database, you probably don't want to pick a migration framework before you've created your first table. The built-in workflow gives you something to use in the meantime, with no extra tool to install and no framework-specific schema format to learn. You write plain SQL, keep it with your application, and let the CLI handle ordering and tracking.

Four commands cover it:

# Create a migration
bunny db migrations create add_users

# Check migration state
bunny db migrations list

# Preview what will run
bunny db migrations apply --dry-run

# Apply pending migrations
bunny db migrations apply

If your application eventually grows into a framework with its own migration system, use that one. When you create your first Bunny Database and wonder how you're meant to manage schema changes, there's an answer already sitting in the CLI.

Local development and CI

The same workflow works when nobody is sitting at the terminal. Interactively, apply asks for confirmation before it changes the database. In a non-interactive environment such as CI it skips the prompt, so your deployment isn't stuck waiting for someone to answer it. You can skip confirmation explicitly too:

bunny db migrations apply --force

Once the migration files are committed alongside your application, your deployment pipeline can apply whatever migrations came with a release:

bunny db migrations apply

The same files you used in development travel through the pipeline with the code that depends on them, so there's no separate pile of production SQL scripts to maintain.

Get started

If you already have a migration tool you love, keep using it. If you don't, getting started takes a few commands:

npm install -g @bunny.net/cli

bunny login

bunny db migrations create my_first_migration

Write some SQL, check what's waiting, and apply it:

bunny db migrations list
bunny db migrations apply

Your schema changes stay next to the code that depends on them, your database remembers what it has already applied, and that folder of mystery SQL files turns into something you can read as a history.

The bunny.net CLI is open source and built in public. If something's broken, or you've got an idea for making migrations better, come talk to us on GitHub or Discord.

We just shipped @bunny.net/database-client, a small SQL client for Bunny Database. It uses fetch with no external dependencies, and is built for Bunny Edge Scripting.

The same code runs in Deno, Bun, Node, or any TypeScript function or API where you want to use Bunny Database without extra runtime dependencies.

import * as BunnySDK from "npm:@bunny.net/edgescript-sdk@0.12.1";
import { connect } from "npm:@bunny.net/database-client";

const db = connect();

With no arguments, connect() reads BUNNY_DATABASE_URL and BUNNY_DATABASE_AUTH_TOKEN from the environment, which is what bunny db link and Edge Scripting already set.

There are working examples for Bun, Node, Hono, Edge Scripting, Next.js, Astro, and SvelteKit if you want to read code before you read the rest of this post.

The library is experimental, a work-in-progress, and open to contribution.

Queries

Statements are prepared, bound, and then executed with whichever method fits the shape you want back:

const rows = await db.prepare("SELECT id, name FROM users").all();
// [{ id: 1, name: "Alice" }, { id: 2, name: "Bob" }]

const user = await db.prepare("SELECT * FROM users WHERE id = ?").bind(1).first();
// { id: 1, name: "Alice" }  or  null

const name = await db.prepare("SELECT name FROM users WHERE id = ?").bind(1).first("name");
// "Alice"  or  null

run() adds write metadata:

const result = await db
  .prepare("INSERT INTO users (name) VALUES (?) RETURNING id")
  .bind("Carol")
  .run();
// { rows: [{ id: 3 }], columns: ["id"], rowsAffected: 1, lastInsertRowid: 3 }

Statements are immutable, so you can prepare once and bind as often as you like:

const byId = db.prepare("SELECT id, name FROM users WHERE id = ?");

const alice = await byId.bind(1).first();
const bob = await byId.bind(2).first();

SQLite's named parameters work too. Pass a single object instead of positional values, with or without the sigil:

const team = await db
  .prepare("SELECT id, name FROM users WHERE team = :team AND active = :active")
  .bind({ team: "platform", active: true })
  .all();

Rows are typed as Record<string, SqlValue> by default, so you can pass your own shape to skip the cast:

interface User {
  id: number;
  name: string;
}

const users = await db.prepare("SELECT id, name FROM users").all<User>();

That type is an assertion for now. Nothing checks the rows against it at runtime, so it’s only ever as accurate as your SQL.

Transactions in one round trip

batch() runs every statement in a single transaction and a single HTTP request. All of them commit or none do:

const [inserted, count] = await db.batch([
  db.prepare("INSERT INTO users (name) VALUES (?)").bind("Dan"),
  db.prepare("SELECT COUNT(*) AS c FROM users"),
]);

inserted.rowsAffected; // 1
count.rows[0].c; // 4

You get one result per statement you passed, in order. If any statement fails, the transaction rolls back and batch() throws that statement's error, so there is no half-applied state to reason about.

For schema setup, there is db.exec(), which runs a multi-statement script:

await db.exec(`
  CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT NOT NULL);
  CREATE INDEX IF NOT EXISTS users_name ON users (name);
`);

It takes no parameters and returns no rows. For a schema you expect to keep changing, reach for bunny db migrations.

bunny db migrations create add_users_table  # migrations/0001_add_users_table.sql
bunny db migrations apply
bunny db migrations list

bunny db migrations apply --dry-run lists what would run without touching the database. The migration commands are still marked experimental and could change based on your feedback.

Errors carry the SQLite code

Errors are DatabaseError with the SQLite code attached, so you can catch a SQLITE_CONSTRAINT without string-matching a message.

import { DatabaseError } from "@bunny.net/database-client";

try {
  await db.prepare("INSERT INTO users (email) VALUES (?)").bind(email).run();
} catch (error) {
  // Prefix match, so this catches SQLITE_CONSTRAINT and its extended forms alike.
  if (error instanceof DatabaseError && error.code?.startsWith("SQLITE_CONSTRAINT")) {
    return Response.json({ error: "That email is taken." }, { status: 409 });
  }

  throw error;
}

Failures that happen before any SQL runs are wrapped the same way, with codes NETWORK, TIMEOUT, and ABORTED, so one instanceof DatabaseError covers the whole surface and no TypeError slips past it.

Keep it on the server

A database token authorizes the connection, and anything holding it can run whatever SQL the token allows. This client belongs in server-side code only. Never ship it, or a token, to a browser.

The pattern we typically see from users is an Edge Script sitting in front of Bunny Database. The token stays on the server, and the browser only sees the responses you choose to return:

import * as BunnySDK from "npm:@bunny.net/edgescript-sdk@0.12.1";
import { connect, DatabaseError } from "npm:@bunny.net/database-client";

const db = connect({ timeout: 2000 });

BunnySDK.net.http.serve(async (request: Request): Promise<Response> => {
  const { pathname } = new URL(request.url);
  if (pathname !== "/notes") return new Response("Not found", { status: 404 });

  try {
    if (request.method === "POST") {
      const payload = await request.json().catch(() => null);
      const title = typeof payload?.title === "string" ? payload.title.trim() : "";
      if (!title) {
        return Response.json({ error: "A title is required." }, { status: 400 });
      }

      const note = await db
        .prepare("INSERT INTO notes (title) VALUES (?) RETURNING id, title")
        .bind(title)
        .first();

      return Response.json(note, { status: 201 });
    }

    // Parameterized, and scoped to the columns and rows the caller may see.
    const notes = await db
      .prepare("SELECT id, title FROM notes WHERE published = 1 ORDER BY id LIMIT 50")
      .all();

    return Response.json(notes);
  } catch (error) {
    // The server's message and SQLite code stay in your logs, not in the response.
    console.error(error instanceof DatabaseError ? `${error.code}: ${error.message}` : error);

    return Response.json({ error: "Something went wrong." }, { status: 500 });
  }
});

The browser calls your endpoint, and your endpoint decides what SQL runs. Narrow the token while you are at it using the bunny.net CLI:

bunny db tokens create --read-only --expiry 30d

A narrowed token still exposes every row of every table to whatever holds it, because it authorizes the connection and not the individual query. It limits the damage without removing it, which is why the token stays on your side of the wire.

It works with your framework too

@bunny.net/database-client works with the frameworks you already use. Each one keeps its environment variables somewhere slightly different, so that's the only part of the setup that changes:

// Next.js, where .env is already on process.env
const db = () => connect();

// Astro, where it is on import.meta.env
const db = () =>
  connect({
    url: import.meta.env.BUNNY_DATABASE_URL,
    authToken: import.meta.env.BUNNY_DATABASE_AUTH_TOKEN,
  });

// SvelteKit, where $env/dynamic/private keeps it out of the client bundle
const db = () =>
  connect({
    url: env.BUNNY_DATABASE_URL,
    authToken: env.BUNNY_DATABASE_AUTH_TOKEN,
  });

Once db() is wired up, the query code looks the same wherever you call it from:

export const GET: RequestHandler = async () =>
  Response.json(
    await db().prepare("SELECT id, title FROM notes ORDER BY id").all(),
  );

export const POST: RequestHandler = async ({ request }) => {
  const { title } = (await request.json()) as { title?: string };
  if (!title?.trim()) {
    return Response.json({ error: "A title is required." }, { status: 400 });
  }

  return Response.json(
    await db()
      .prepare("INSERT INTO notes (title) VALUES (?) RETURNING id, title")
      .bind(title.trim())
      .first(),
    { status: 201 },
  );
};

React Server Components can call db() directly too:

export default async function Page() {
  const notes = await db()
    .prepare("SELECT id, title FROM notes ORDER BY id")
    .all<{ id: number; title: string }>();

  async function create(formData: FormData) {
    "use server";
    const title = String(formData.get("title") ?? "").trim();
    if (!title) return;

    await db().prepare("INSERT INTO notes (title) VALUES (?)").bind(title).run();
    revalidatePath("/");
  }

  return (
    <main>
      <form action={create}>
        <input name="title" placeholder="Note title" />
        <button type="submit">Add</button>
      </form>
      <ul>
        {notes.map((note) => (
          <li key={note.id}>{note.title}</li>
        ))}
      </ul>
    </main>
  );
}

Try it

This is an early release, and designed to be small. Create a Bunny Database using the Dashboard or the bunny.net CLI:

npm install -g @bunny.net/cli
bunny login
bunny db create

Then pick an example to get you started:

When you're ready to deploy, push an Edge Script with the CLI, or deploy a framework app to Magic Containers.

If you've already got a project you want to add Bunny Database to, install the client with your package manager of choice:

npm install @bunny.net/database-client
# pnpm add @bunny.net/database-client
# bun add @bunny.net/database-client

If something you need is missing, tell us on Discord, or open a pull request on GitHub. The CLI is open to contributions from the community.

When we introduced the bunny.net CLI, it shipped with full Database support, and we said more of the stack would follow. Since then, we’ve added support for Edge Scripting, DNS, and Sandboxes.

Today, we’re bringing Bunny Storage to the CLI in Public Preview.

You can now create Storage Zones, connect them to Pull Zones, upload and download files, configure custom domains, and retrieve S3-compatible credentials, all without leaving your terminal.

None of these steps is particularly difficult on its own; they're just spread across different parts of the platform. The CLI brings everything together into a single workflow.

Two zones, one job

Bunny Storage is built around two services that work together: a Storage Zone holds your files, and a Pull Zone serves them over HTTP through the bunny.net CDN.

Files in a Storage Zone aren't publicly reachable on their own. The Pull Zone sits in front, treats storage as its origin, caches the result across the network, and serves it to your users.

The CLI knows this, so it can do both at once:

bunny storage zones add

That creates the Storage Zone, offers to create a Pull Zone alongside it, connects the two, and offers to attach a custom domain. One command, and you end up with a URL that resolves.

Create your storage

Everything starts with a Storage Zone. Pick a name, choose a tier, choose a main region, optionally add replication, and you can start uploading.

Run it with no arguments and it asks:

bunny storage zones add

Every one of those prompts has a matching flag, so the same command works in CI:

bunny storage zones add my-storage --region DE

Two of those choices are permanent, so it's worth knowing about them before you answer.

The tier is either Standard (HDD) or Edge (SSD). --tier ssd is faster and always lives in Frankfurt, which is why it won't let you pass a different main region.

S3 compatibility is switched on at creation with --s3 and cannot be added later while S3 is in Public Preview. If you think you might want the S3 API, turn it on now.

If you're not sure which region code you need, the CLI will tell you:

bunny storage regions --tier ssd

Replicate where it matters

Storage doesn't have to live in one place. When you create a Storage Zone, you can pick extra regions to replicate into:

bunny storage zones add my-storage --region DE --replicate NY,SG

Replicas are permanent. There's no API to remove one once it exists, so the CLI confirms before adding any, and zones update --replication only ever adds to the set.

Work with your files

Once the zone exists, you can list, upload, download, and delete files:

bunny storage files list
bunny storage files upload ./photo.png --to images/
bunny storage files download images/photo.png
bunny storage files remove images/photo.png

Notice what's missing from those commands: the zone. Link your project’s directory once, and every file command defaults to it.

bunny storage link my-storage

You’ll end up with a .bunny metadata folder the CLI can reference when you run commands without flags, so other developers can clone your code and run their own storage zones in development too. The CLI already knows which regional endpoint and which password belong to that zone, so there’s no hostname to look up and no SDK to configure first.

S3-compatible credentials

Not every tool speaks the bunny.net Storage API, which is why developers have been asking for S3-compatible Bunny Storage for years. It’s currently in Public Preview, and since most tools already speak S3, it’s a perfect fit for the CLI.

If your zone was created with --s3, the CLI can hand its credentials to those tools in the format each one expects: the AWS CLI, rclone, s3cmd, shell environment variables, or JSON.

Export them into your current shell:

eval "$(bunny storage zones credentials my-storage --format env)"

Now anything that speaks S3 can use them:

aws s3 sync ./dist s3://my-storage/assets

Or write an rclone remote straight into your config:

bunny storage zones credentials my-storage \
  --format rclone \
  >> ~/.config/rclone/rclone.conf

There are no extra keys to create or rotate. These are your existing Storage Zone credentials, reshaped. Pass --read-only if the tool on the other end only needs to read.

Secrets are masked by default, including under --output json. You get the real value when you ask for it with --show-secret, or when you ask for a tool config, because a config with a masked password in it is no use to anyone.

If you already have S3 tooling, nothing in your workflow has to change. S3 support is in Public Preview, so check the full compatibility details before you point production at it.

Built for automation

Like everything else in the bunny.net CLI, Storage works the same in a script as it does in a terminal.

Every prompt has a flag. Every command has --output json. Nothing waits on an answer that isn't coming: run without a TTY, or pass --force, and anything that would have prompted either takes the flag value or tells you which flag it needed.

The commands you run on your laptop are the commands you run in CI.

What's next?

Bunny Storage joins Bunny Database, Edge Scripting, DNS, and Sandboxes in the CLI today.

Magic Containers are next. The goal hasn't changed:

• Start with an empty terminal.
• Provision your infrastructure.
• Deploy your application.
• Upload your assets.
• Manage your services.

All without leaving the command line.

It's been a busy couple of months. We made Bunny DNS free, crossed 100,000 paying customers, and throughout all of that, you kept building genuinely cool things on top of bunny.net. Here's a fresh batch of projects, migrations, and community tools we spotted.

As always, if you've built something on bunny.net and want it featured, let us know.

The community packages below are built by people working 
with bunny.net, but they aren't officially maintained by us.

Shipped on bunny.net

Airpult - privacy-first weather, running on most of the platform

Airpult is an independent, EU-based weather service with its own forecasting pipeline, API, and apps, plus a genuine privacy stance to go with it. Alerts use blind-signed tokens so notifications can't be tied back to you, there are no ad SDKs or data brokers, and everything runs on EU infrastructure.

Airpult runs all its traffic through our CDN, uses Bunny Optimizer to keep things fast, recently added Bunny Shield in front of its API traffic, and just started using Bunny Storage with our new S3-compatible API to power part of its map product.

Jens Schmidt Hansen - a board-game side project that runs on "3 banana splits a month"

I really like seeing side-project cost breakdowns across socials. Jens shared one for his side project, a niche tool for organizing board-game nights that handles 1.5 million board games for around 15,000 collectors and is used in board-game cafés across a dozen countries. Total monthly bill: netcup €20.19, bunny.net ~€1.77, Scaleway €0.03. Roughly three banana splits.

The architecture is also worth taking a look. Clients upload directly to S3-compatible storage via a presigned URL, a third-party vendor compresses each file to WebP and scans it for malware, then deletes the original. Jens then lets Bunny Storage replicate the compressed file across 10 regions at $0.20/GB. At ~50–70 KB per file, that's 14,000–20,000 uploads per GB, or as he puts it, "$1 = 70,000-100,000 user uploads."

Tina Mrak - a PrestaShop crawl-trap, and the fix

Tina Mrak wrote up a great debugging story that hit close to home, as I’ve run into the same faceted-search problem in the past. PrestaShop's filters generated 500,000+ crawlable URLs, and bots crawled all of them.The origin's Plesk/Fail2Ban then ended up banning Bunny's CDN IPs, leading to Googlebot 500s and deindexed pages.

Shipped for bunny.net

The community tooling around bunny.net has had a great couple of months across a bunch of ecosystems.

PHP & Symfony

• flysystem-bunny-storage - an actively maintained Flysystem adapter for Bunny Storage, now with v3 support and an async upload interface.
• survos/bunny-bundle - a Symfony bundle for working with Bunny CDN.

Ruby

• bunnycdn-rails - unofficial Rails helpers for Bunny CDN and Bunny Storage. Good to see more Ruby love.

DNS & infrastructure

• qdm12/ddns-updater added bunny.net as a DNS provider - it's a hugely popular self-hosted tool, so this one reaches a lot of people.
• The OPNsense plugins project added a native bunny.net dynamic DNS provider.
• caddy-dns/bunny and the underlying libdns provider kept improving, including adding DNSSEC support.

Analytics

• matomo-log-analytics added a bunny.net log format
• PostHog added a bunny.net import source to its data warehouse and now allows you to pull data from pull zones, storage zones, DNS zones and Stream video libraries.

Security tooling

• octorules-bunny, the manage-your-Shield-WAF-rules-as-code tool we featured back in May, is still shipping, withseveral releases since then.

Working with AI agents & the edge

• Shroud-email, the privacy-focused email service, is using a Bunny Edge Script for geolocalized pricing, serving different prices by region right at the edge.
• SnapSync moved its device-facing runtime onto Bunny Edge Scripting (built by the same developer behind a full Scaleway-to-Bunny migration).
• hookdeck/webhook-skills shipped a Bunny Stream webhooks skill for AI agents.

That’s it for July. We’ll be back next month with more projects, tools, and experiments from across the bunny.net community. If you’d like to be featured, tag us on social media or share your project in our Discord community. Join our Discord here.

(This post is co-authored with Rishi Raj Jain)

The more closely an attack resembles your normal traffic, the harder it is to stop. A spoofed packet flood is easy to drop precisely because nothing legitimate resembles it. When attack traffic uses valid requests, real IP addresses, and standard protocol behavior, your filters face a harder problem: you cannot block what you cannot distinguish.

This post explores where that split happens in the network stack and how it should shape the defenses you build. We'll compare two broad categories of attacks: those that expose clear signals at L3/4 and those that hide behind valid application traffic at L7. We'll also look at four real incidents that show the difference: Slowloris in 2009, Mēris in 2021, HTTP/2 Rapid Reset in 2023, and a lesser-known attack that can crash a server while leaving nothing in your access logs, the kind of attack you cannot even see, let alone block.

Layer numbers are shorthand for filter cost

At L3/4, spoofed SYN floods, memcached reflection bursts, and UDP amplification patterns all leave measurable signals: bandwidth spikes, impossible source behavior, and protocol states with no benign equivalent. Those signals appear before application code runs, which means you can make a drop decision at the edge cheaply before spending anything on TLS termination or HTTP parsing.

At L7, a botnet request and a customer request during a flash sale can be byte-for-byte identical on the wire. The signal you need is intent, and reading intent requires decrypting traffic, parsing requests, and comparing behavior against a baseline, all of which costs CPU before you can confidently block anything. That cost asymmetry is what makes L7 harder, and it grows as bots get better at mimicking real browsers.

Attack size is a poor measure of difficulty

When someone quotes an attack in terabits per second, the instinct is to reach for bandwidth planning and scrubbing capacity. That works for volumetric floods, but size is a weak proxy for mitigation difficulty once traffic looks application-shaped.

What signals look like at each layer

Knowing which layer an attack targets tells you where in the stack you need to act. The more important question is what signal you have available at that point, because its quality determines whether you can make a fast, cheap drop decision or whether you are stuck doing expensive inspection work before you can act at all.

L3 and L4: measurable signals

Volumetric and protocol attacks expose signals you can measure before application code runs, before you incur the cost of TLS termination and HTTP parsing. Common examples include sudden bandwidth spikes, spoofed or implausible source addresses, SYN packets that never complete a handshake, and fragmented or repetitive protocol patterns with no real client equivalent. These signals are visible early, which is why provider-scale scrubbing, anycast distribution, and stateless mitigations like SYN cookies remain effective against floods that would overwhelm an origin if they arrived unfiltered.

L7: interpreted signals

Application-layer attacks require you to decrypt traffic, parse requests, and compare behavior against a baseline for your specific service. That inspection costs you resources before you can confidently drop anything, while the attacker may have spent very little to generate each request.

Volumetric floods are measured in bits per second, protocol floods in packets per second, and application floods in the ratio between request cost at the client and request cost at your origin. A single search, login, or checkout can cost the server orders of magnitude more than it cost to send, which makes L7 abuse as much an economics problem as a networking problem.

L3/4 mitigation is largely a solved problem at the edge

“Solved” does not mean attacks have gotten smaller, and it does not mean the supply of attack infrastructure is shrinking: every newly misconfigured server exposed to the internet becomes another reflector that an attacker can bounce amplified traffic through. What is solved, if you sit behind serious network protection, is the classification problem. This traffic looks nothing like a legitimate user session, so you can drop it on cheap signals alone without ever reasoning about intent.

GitHub’s February 2018 memcached incident shows that clarity at extreme scale. The attack peaked at 1.35 Tbps and 126.9 million packets per second, generated by tens of thousands of reflectors. The service recovered within minutes after GitHub routed traffic through Akamai scrubbing. The signal was obvious: a 15-byte UDP request to an exposed memcached instance could produce responses up to 51,000 times the request size. Nothing in normal application traffic resembles that pattern.

L3/4 attacks fall into two families. Volumetric attacks fill bandwidth through reflection across UDP-based services (DNS, NTP, memcached, ICMP) and are measured in bits per second. Protocol attacks exhaust state in firewalls, load balancers, and servers through SYN floods, ACK floods, and fragment abuse, and are measured in packets per second. Neither family tries to impersonate a legitimate browser traffic.

Spoofed sources, half-open handshakes, and reflection floods have no legitimate twin in production traffic, so dropping them rarely harms real users when rules are scoped correctly.

If you run bare metal directly on the public internet without scrubbing in front of it, even well-understood attack classes can overwhelm you because the classification and absorption work has nowhere else to happen.

L7 is a different problem entirely.

L7 mitigation is harder in production

A single HTTP request can appear completely normal while still being part of an attack campaign. The same GET /products/12841 from a distributed botnet and one from a customer during a promotion can be identical on the wire. Packet signatures are useless here. Behavioral context and baselines are what separate the two.

Several structural factors make that harder in practice:

• Inspection cost: TLS termination and HTTP parsing consume defender CPU before a confident block decision is possible, while attackers generate requests cheaply at scale.
• Moving baseline: Real audiences are bursty. Launches and viral links can reproduce the shape of an attack without any malicious intent.
• Uneven endpoint cost: Applying the same rate limit to a static page and to a login or checkout flow can block humans on cheap routes while leaving expensive routes exposed.
• Realistic bots: Headless browsers, residential proxies, and realistic TLS client behavior mean simple header checks are no longer a durable strategy.

Let’s look at four attacks that worked in different ways but bypassed the cheap filters for the same reason, which is that none of them looked like an attack at the layer those filters watch.

1. HTTP/2 CONTINUATION Flood and the invisible request

HTTP/2 lets a client split request headers across several frames: an opening HEADERS frame followed by one or more CONTINUATION frames, with an END_HEADERS flag marking the end of the block. The CONTINUATION Flood, disclosed in April 2024 by researcher Bartek Nowotarski, abuses this by sending an unbounded stream of CONTINUATION frames and never setting END_HEADERS. The server keeps reading and buffering the header block, waiting for an end that never comes, and a single connection can drive memory to an out-of-memory crash.

Because the request never completes, most servers never write it to the access log, so the server can go down while your dashboards and logs see nothing. There is no slow client to flag, no malformed frame to match, and no finished request to rate-limit. The fix is to cap the number of CONTINUATION frames per stream and the total header size, then close connections that exceed those limits.

2. Slowloris and low-bandwidth exhaustion

Robert Hansen (RSnake) released Slowloris in June 2009 to show that application availability could be destroyed without a volumetric flood. The technique uses one machine to open many connections, send partial HTTP headers, and drip additional header lines slowly enough to prevent timeouts while never completing a request. The server holds each connection open while waiting for completion. Once the pool is full, legitimate clients cannot establish new connections.

The attack uses almost no bandwidth, so volume-based defenses see nothing alarming. Each connection looks like a slow mobile client on a poor network rather than a flood. Effective mitigation is behavioral: connection and header timeouts, per-IP connection limits, and reverse proxies that buffer and terminate incomplete requests before they tie up application threads.

Slowloris separates attack impact from attack size. When your dashboards only watch bandwidth, this class of abuse can look healthy right up until the connection pool is gone.

3. Mēris and valid requests at record scale

In September 2021, the Mēris botnet (named after the Latvian word for plague) struck Yandex at 21.8 million requests per second, a record at the time. The ramp was gradual rather than a sudden cliff, and each increase could be mistaken for organic growth until source and behavior context made the pattern clear.

Mēris was built from compromised MikroTik routers exploited through CVE-2018-14847, a vulnerability patched in 2018 that remained present on many devices in the wild. Research from Yandex and Qrator Labs estimated the full compromised population at around 250,000 hosts, while individual attacks used only a fraction of those hosts at a time. The attack traffic consisted of complete valid HTTP requests sent at enormous volume. Bots used HTTP pipelining to send multiple requests down a single connection without waiting for responses, and SOCKS proxies obscured origin behavior. Because the sources were real network devices on residential and business networks, each host looked like an ordinary client, and each request looked like legitimate HTTP.

When every request is syntactically valid, you rely on rate control, fingerprinting, reputation, and behavioral baselines. You also need a clear picture of what normal growth looks like for your service because a botnet spike and a successful launch can look similar in raw request rate.

4. HTTP/2 Rapid Reset and protocol-valid abuse

HTTP/2 Rapid Reset (CVE-2023-44487) was disclosed on October 10, 2023, through coordinated publication by Google, Cloudflare, and AWS after exploitation in the wild between August and October of that year. Google reported a peak of 398 million requests per second: roughly 7.5 times the previous record. Cloudflare observed about 201 million requests per second, generated by a botnet of approximately 20,000 machines.

HTTP/2 multiplexes many streams over one TCP connection and lets clients cancel individual streams with RST_STREAM frames: a legitimate feature real browsers use, for example, when aborting image loads after scrolling. Attackers repeatedly opened a stream, canceled it immediately, and repeated the cycle. The attacker incurred very little cost while the server paid the setup and teardown cost for each cycle. Every frame was valid HTTP/2, so there was no malformed packet to match and no simple signature beyond resource accounting behavior.

Concurrent stream limits alone do not solve the problem because abusive clients can churn cancellations faster than servers reclaim state in some architectures. Mitigation focused on protocol accounting changes: reset counting per connection, tighter stream limits, and earlier connection closure for abusive patterns. The fix was resource accounting: counting resets per connection, tightening stream limits, and closing connections earlier when abuse patterns appear.

Taken together, all four attacks follow the same playbook.

The shared pattern across all four attacks

These attacks differ in speed, bandwidth profile, and protocol details, but they all become hard to stop at the same point: when the cheapest filters cannot tell them apart from normal traffic, or cannot see them at all.

This pattern explains why raw capacity stops helping once attacks resemble normal traffic. Peak volumes may keep climbing, but defense now depends on behavior profiling, rate control, and protocol limits rather than more bandwidth.

Practical strategies for L7 defense

No single WAF rule or rate limit covers every L7 attack pattern. Most teams stack several controls and accept that each one can misclassify some traffic. The goal is to block abuse efficiently without breaking legitimate spikes.

Some common mitigations that handle most of the work:

• Tier your rate limits: Set a blanket per-IP limit on a rolling window, then tighten it on compute-heavy routes such as login, search, checkout, and signup.
• Order rules cheapest first: Run IP reputation, geo constraints, and coarse heuristics before bot inspection and application logic, so most unwanted traffic is dropped before it reaches a costly control. Bunny Shield’s bot detection layers checks in this order: cheap request-integrity, IP, and ASN reputation checks run first, and you can escalate to header-anomaly and full fingerprint validation by moving from the Low to the High sensitivity profile or by toggling individual checks in Custom mode.
• Add an adaptive baseline: Track what your normal traffic looks like over time and filter what does not fit. For the challenge layer, Bunny Shield’s DDoS protection provides a JavaScript proof-of-work challenge you can scope to specific endpoints or run in Always-On Mode. Challenges raise attacker cost but add user friction and become less effective as automation improves. The open-source Anubis proxy gates bots behind a SHA-256 puzzle and is used by groups like UNESCO and GNOME, yet researchers note the compute cost is negligible for a well-funded scraper, so it works best as one added layer.
• Harden the application and protocol: Set request, header, and absolute connection timeouts, enforce minimum ingress data rates to defeat slow-send attacks, and cap HTTP/2 streams with reset counting. See OWASP’s Denial of Service Cheat Sheet for the full list. Many of these gaps are invisible to firewall signatures.

Where this is heading

How difficult an attack is to stop depends on how different it looks from your legitimate users. L3/4 remains tractable at the edge because benign production traffic rarely shares the shape of floods and reflection abuse. L7 remains difficult because benign and malicious traffic can share the same protocol, the same endpoints, and the same request structure.

As bots continue to improve at impersonating real clients through residential IP diversity, realistic TLS stacks, and more complete page interaction patterns, the right question shifts from how many requests arrived to who is sending them and whether that pattern fits your service.

No single layer solves the whole problem, so a complete defense needs both. Network-level DDoS protection absorbs and drops obvious floods at the edge, while application-aware controls inspect traffic that looks like real users. As you design your own setup, the rule that holds up over time is to filter on clear signals as early and as cheaply as you can, then fall back on behavior and baselines only for the requests that look fine on their own.

Until now, Edge Scripting has had an opinionated default: your code runs after the CDN cache. That's great for efficiency because fully cached traffic never executes your script. But it also means that the moment a response gets cached, your code is out of the loop.

Today, that's becoming a choice instead of a rule. Edge Scripting can now also run before the cache, giving your code control over every single request. And with the new Cache API, your scripts can read, write, and delete entries in a separate cache at the edge.

Let's hop into the details.

Why run before the cache

Running after the cache is a feature, not a bug. When a response is cached, the CDN serves it directly and your script never runs. Cached traffic adds zero script execution, which keeps costs low and latency predictable. For delivery-heavy workloads, that's exactly the behavior you want.

The tradeoff shows up when your workload is dynamic. As soon as a response is cached, you lose per-request control. No auth checks, no personalization, no routing logic; nothing runs until the cache entry expires. The usual workaround is to disable caching for dynamic routes, which solves the problem by throwing away the benefit.

That means you've had to choose between caching and control. Now you can have both.

How pre-cache execution works

Edge Scripts get two new hooks that run on the client side of the cache:

• onClientRequest fires on every incoming request, before the cache lookup. You can modify the request or return a response directly and short-circuit everything behind it.
• onClientResponse fires just before a cache or origin response is sent back to the client. If onClientRequest returns a response directly, the request is short-circuited there.

Together with the existing onOriginRequest and onOriginResponse hooks, the request lifecycle now looks like this:

On a hit, the CDN cache answers and your client-side hooks run around it. On a miss, the request continues to the origin hooks and back, writing to the cache on the way if it's cacheable. Either way, your code sits before the cache lookup and just before the response goes out, so you get control around the cache without bypassing it.

Meet the Cache API

Running before the cache is one half of the story. The other half is a cache your script controls directly, separate from the CDN cache that serves requests automatically. That's where the Cache API comes in.

Modeled after the browser’s Cache interface, it lets scripts match, put, and delete request/response pairs. Entry lifetimes follow the Cache-Control headers you set on the responses you write, and expired entries are purged automatically.

Here’s a pattern for taking ownership of a cache entry’s lifecycle: serve a cached value on GET, refresh it on POST, and purge the exact entry on DELETE. The key detail is that all three handlers build the same URL-based key, so reads, writes, and deletes all target the same entry.

import * as BunnySDK from "@bunny.net/edgescript-sdk";

// GET serves the cached entry, POST refreshes it, DELETE purges it.
// (Error handling omitted: match, put, and delete can all throw.)
BunnySDK.net.http.serve(async (request: Request): Promise<Response> => {
  const cache = await caches.open("demo:v1");
  const key = new URL(request.url).toString(); // one key for all three

  if (request.method === "POST") {
    const fresh = Response.json(
      { refreshedAt: new Date().toISOString() },
      { headers: { "Cache-Control": "max-age=60" } },
    );
    await cache.put(key, fresh.clone());
    return new Response("Refreshed.", { headers: { "Cache-Control": "no-cache" } });
  }

  if (request.method === "DELETE") {
    const deleted = await cache.delete(key);
    return new Response(deleted ? "Purged." : "Nothing to purge.", {
      headers: { "Cache-Control": "no-cache" },
    });
  }

  const cached = await cache.match(key);
  return cached ?? new Response("No cached value yet.", {
    status: 404,
    headers: { "Cache-Control": "no-cache" },
  });
});

That same pattern scales up to tenant-aware keys, microcaching, manual refresh hooks, and exact-entry purges. It's a script-controlled cache at the edge, separate from the automatic CDN cache: you decide how entries are created, found, and removed.

A few things to know before you design around it:

• Cache contents are regional. Entries live in the region where they were created and don't replicate globally. A page cached in Frankfurt gets cached again in Singapore on the first request there.
• Cache keys are yours to design. An entry's key is exactly the URL or Request you pass, nothing more. There's no automatic normalization, so /page and /page?utm_source=x are two different entries unless your code makes them one. We recommend building keys from the current request URL. That discipline pays off when it’s time to delete an entry: you can only purge it if you can rebuild its exact key.
• Pull Zone domains share cache instances. Cache instances are shared across all domains associated with your Pull Zone, but they need to be accessed through the incoming request's hostname. For multi-domain Pull Zones, build keys from the current request host or request URL.
• Limits: match, put, and delete are the supported operations on Cache instances, with a 100 MB limit per cache file.

Pre-cache execution and the Cache API are two separate features, but they're better together. Running before the cache gives you control on every request, and the Cache API is how you put caching back in on your terms.

This unlocks two major use cases:

Multi-tenant delivery on your caching rules

When every hostname, path, or account maps to a different tenant, one-size-fits-all cache rules stop being enough. With scripts in front of the cache, your delivery logic can:

• Key cache entries per tenant, using tenant-aware prefixes inside versioned named caches, with TTLs controlled by the Cache-Control headers on the responses you write.
• Invalidate exact entries surgically, as long as your application can reconstruct the keys it wrote. This is exact-key deletion, not wildcard purge or tenant-wide key listing.
• Decorate cache or origin responses per tenant in onClientResponse, adding headers or security policies without waking up the origin.
• Build dynamic caching patterns the CDN doesn't offer out of the box, like microcaching rendered pages or using explicit POST / DELETE handlers to refresh and purge known cache entries.

If you run a platform where your customers' content flows through your zones, this lets you turn edge caching from a fixed behavior into part of your product logic.

Serverless CRUD apps at the edge

Until now, a dynamic multi-user app didn't really fit the after-cache model. Sessions, per-user responses, and cache decisions all need code on every request, so you'd end up disabling caching and losing the main benefit of running at the edge.

With pre-cache execution, the pieces fall into place:

• Auth and sessions run in onClientRequest, on every request
• You decide what's cacheable, using the Cache API to cache rendered pages or API responses for seconds or minutes, and serving everything else dynamically
• Compute stays request-based, so a side project that gets no traffic costs nothing in compute, and a production app scales with traffic
• Pair Edge Scripting with Bunny Database for state, so you can build full-stack serverless apps, with read replication to serve reads close to your users

And since both Edge Scripting and Bunny Database are supported by the bunny.net CLI, you (and your agent) can go from local to prod without leaving the terminal.

You choose where your code runs

Post-cache execution stays the default, and it's still the most cost-effective way to run delivery logic: when cached traffic doesn't need script logic, the CDN can serve it directly without invoking your code. Pre-cache execution is the opt-in mode for the routes and Pull Zones where you need per-request control.

Other platforms typically put compute in front of the cache by default, so even cache hits can pass through your code path. With bunny.net you can now choose to keep compute out of the hot path when the cache is enough, or move it in front of the cache when your application needs control.

Getting started

Both pre-cache execution and the Cache API are now available in public preview.

The Cache API works in any Edge Script today. There's nothing to enable. Pre-cache execution is a toggle in the dashboard:

• Middleware scripts: in your Pull Zone, under General → Origin → Run script before cache.
• Standalone scripts: the same toggle in the Pull Zone, or enable it directly in the script's settings.

For more details, check out the docs:

• Pre-cache execution
• Cache API reference

Happy building and let us know what you think on Discord!

HopStart is our startup program with a straightforward goal: let early-stage founders get on with building, without infrastructure eating into their time and budget. Two rounds in, we're back with a third cohort.

As always, each cohort has three winners. Each team receives up to $50,000 USD in credits to spend on bunny.net, plus hands-on time with our team and an early look at features before we release them. Choosing only three is never easy. What ultimately tips the scale for us is whether a team is solving a real problem for its users, and whether bunny.net is a genuine fit for how they build.

Here are the three startups joining HopStart cohort #3.

1st place: Screenity

Founder: Alyssa X

Year founded: 2025

URL: https://www.screenity.io/

Credits received: $50,000 for one year

In the founder's words: "Screenity is the European alternative to Loom that goes well beyond recording a clip and sending a link. It's a screen recorder and video editor all in one, working almost like a deck. It's privacy-friendly all the way down, and is hosted entirely in Europe (unheard of in this space!), all built independently by one person."

2nd place: Ciphera

Founder: Usman Baig

Year founded: 2024

URL: https://www.ciphera.net/

Credits received: $25,000 for one year

In the founder's words: "Ciphera is a privacy-first analytics and identity platform built for website owners who refuse to compromise between actionable data and user privacy. Our flagship product, Pulse, is a cookie-free web analytics tool that gives site owners the metrics they need — pageviews, referrers, geolocation, and device breakdowns — without collecting personal data or requiring consent banners. The impact is straightforward: we're making it economically viable for small and mid-sized websites to stop feeding the ad-tech surveillance pipeline."

3rd place: orkestr

Founder: Stefan Iancu

Year founded: 2026

URL: https://orkestr.eu/

Credits received: $10,000 for one year

In the founder's words: "orkestr is a platform-as-a-service that removes DevOps overhead for developers, freelancers, and small teams. Push to Git, and we handle builds, deploys, databases, SSL, and scaling. No Kubernetes, no infrastructure engineer required. Teams that need real data sovereignty are forced to choose between developer experience and compliance, and usually end up self-hosting, which means hiring DevOps talent they cannot afford. We close that gap: orkestr runs entirely on EU infrastructure with a fully EU sub-processor chain, so customers get Heroku-grade simplicity without legal exposure to non-EU jurisdiction."

Applying for cohort #4

Applications for the next cohort are open. If you're building something you're proud of and can see bunny.net fitting into it, submit your application using the short form before August 31.

If you applied before and didn't make it, it's worth trying again. Every application round is different, and yours may be a stronger fit this time.

We'll announce cohort #4 in October.

Looking forward to seeing what you’re building!

Two recently disclosed vulnerabilities have drawn significant attention across the security community, including a critical unauthenticated remote code execution (RCE) vulnerability and a related SQL injection vulnerability.

To help protect customers while they update their WordPress installations, Bunny Shield now includes new WAF protections for both CVEs, blocking known exploitation attempts before they reach your origin.

These protections help reduce your exposure, but they are not a substitute for patching. WordPress has released security updates for the affected versions, and updating your installation should remain your highest priority.

Affected versions

WordPress has released fixes in the following versions:

• 7.0.2
• 6.9.5
• 6.8.6
• 7.1 Beta 2

Versions earlier than 6.8 are not affected.

The WordPress project is treating these vulnerabilities with the highest priority and is automatically deploying updates to supported installations wherever possible. Even so, it's worth confirming that your sites have successfully updated and are running a patched release.

Understanding the vulnerabilities

The advisory includes two related vulnerabilities affecting different parts of WordPress.

CVE-2026-60137 - SQL Injection

This vulnerability affects WordPress 6.8 and later and allows specially crafted input to manipulate database queries.

Severity: High

CVE-2026-63030 - Unauthenticated Remote Code Execution

This vulnerability affects WordPress 6.9 and later. Under specific conditions, if a persistent object cache is not enabled, an attacker can execute arbitrary code through the WordPress REST API batch endpoint without authentication.

No login or user interaction is required to exploit this vulnerability.

Severity: Critical

Because the RCE vulnerability builds on the SQL injection vulnerability, the available fixes differ slightly between versions:

• 6.8.6 fixes the SQL injection vulnerability
• 6.9.5, 7.0.2, and 7.1 Beta 2 address both vulnerabilities

How Bunny Shield protects your site

Bunny Shield now includes dedicated managed WAF rules for both CVEs.

While our existing WAF engine already detected many exploit attempts targeting these CVEs, we've added dedicated managed rules to improve detection accuracy and provide more precise protection against the disclosed attack paths.

These rules inspect incoming requests before they reach your WordPress installation, identifying and blocking known exploit attempts targeting both vulnerabilities.

If your website is already protected by Bunny Shield, no additional configuration is required.

Protection while you update

Security updates are always the permanent fix, but deploying them isn't always instantaneous. Large WordPress fleets, maintenance windows, compatibility testing, and operational requirements can all delay updates, leaving a window of opportunity for attackers.

Bunny Shield helps close that gap by identifying and blocking malicious requests at the edge before they ever reach your application. This provides an additional layer of protection against publicly known exploit techniques while you complete your update rollout.

This approach, often referred to as virtual patching, reduces the risk of exploitation during the period between a vulnerability being disclosed and every affected system being updated. It complements software updates, but never replaces them.

What you should do

If you manage WordPress sites, we recommend taking the following steps:

• Update to a patched version of WordPress as soon as possible.
• Verify that Bunny Shield is enabled for your website.
• Review your security logs for blocked requests related to these vulnerabilities
• Continue monitoring WordPress security advisories for any additional guidance.

Staying ahead of new attack techniques

Public vulnerability disclosures are often followed by new proof-of-concept exploits and variations that attempt to bypass existing detections. As those techniques evolve, so do our protections.

We'll continue monitoring these vulnerabilities and updating Bunny Shield's managed protections as new attack techniques emerge, helping keep your applications protected as the threat landscape evolves.

Protect your sites with Bunny Shield

While keeping WordPress up to date is your best defense, Bunny Shield adds an extra layer of protection by blocking known exploit attempts before they reach your origin.

If you're already using Bunny Shield, these managed protections are available automatically. If you're not, you can get started in minutes and protect your applications against WordPress vulnerabilities, bots, DDoS attacks, and a wide range of web threats.

Enable Bunny Shield today to protect your WordPress sites against emerging threats, bots, DDoS attacks, and other common web attacks. Log in to your bunny.net account, or sign up today to start shielding your websites.

In 2026, AI agents do not just suggest code. They run it. They install packages, execute shell commands, edit files, clone repos, and reach out across the network, all on their own. That autonomy is the entire point. An agent that has to stop and ask permission before every command is not saving you much time.

But to be useful, an agent needs real access. And nobody is reading every command it runs. Most of the time, that is fine. The agent does exactly what you asked and moves on. The problem is what happens the rest of the time. Every so often an agent deletes the wrong directory, leaks a key it should never have seen, pulls a package that turns out to be malicious, or gets talked into something by a poisoned web page it read halfway through a task.

Here is the pragmatic way to think about it. The odds of any single run going wrong are low. But you are not doing a single run. You are doing hundreds or thousands, and the cost when one goes wrong is not small. It is your laptop, your production credentials, or your customers' data. A low chance of an unbounded loss is still a real, recurring risk. You do not want to bet your environment on it every time.

So people improvise. They run the agent on their own machine and hope for the best. They hand-roll a throwaway VM and wire up the isolation by hand every time. Or they clamp the agent down so tightly it can no longer do the thing they hired it for. None of these is a good answer.

The good answer is old and boring: give the code its own room. Let the agent do whatever it needs in there. If it makes a mess, the mess stops at the walls. A sandbox is a disposable room where AI can do real work, and if it wrecks the place, you throw the room away.

We have been building rooms like this for a long time

Running other people's code, somewhere in the world, quickly and cheaply, is not a new problem for us. It is a problem bunny.net has worked on from the start. Our Magic Containers already deploy your apps across a global network of servers spanning six continents, from Ashburn to Tokyo to São Paulo to Sydney, and they distribute those apps automatically based on where your traffic actually is.

A sandbox, it turns out, is that same capability with two additions: an AI agent already sitting inside, and a room you can throw away when you're done. So we built it.

Meet Bunny Sandbox

Bunny Sandbox uses Magic Containers underneath. In one command, you spin up a fully isolated cloud environment with an AI coding agent like Claude Code already installed, and more agents on the way. The agent does real work inside the box, and you can put that work on the internet just as easily. Same isolation and edge power as Magic Containers, none of the setup.

Every sandbox is a clean Ubuntu container with Node.js, Bun, Python, and Claude Code ready to go, plus a 10 GB persistent workspace so your files survive a restart. You do not manage a server. You do not wire up isolation. You do not clean up afterwards. You get a room, the agent gets to work, and when you are done, the room goes away.

Spin one up from your terminal

Here is the whole loop, from nothing to a live URL, in the bunny.net CLI.

# Install the CLI
curl -fsSL <https://cli.bunny.net/install.sh> | sh

# Log in
bunny login

# Create an isolated sandbox (Claude Code is already inside)
bunny sandbox create my-sandbox

That gives you a fresh, isolated environment on our edge in seconds. You get back an SSH address and a public hostname that goes live once you expose a port. The CLI remembers your sandboxes locally, so you can reconnect any time without re-creating.

Claude Code needs one thing before it can get to work: your own Anthropic credentials. Either bake your API key in at create time, or just run claude inside the box and log in once. Both stick around across restarts.

# .env holds ANTHROPIC_API_KEY
bunny sandbox create my-sandbox --env-file .env

Now put it to work.

# Drop into the box and let the agent build
bunny sandbox ssh my-sandbox

# Or fire off a one-off command without opening a session
bunny sandbox exec my-sandbox -- npm test

Need to move files? One path is local, the other points at the sandbox:

# Copy a file into the sandbox
bunny sandbox cp ./app.js my-sandbox:/workplace/app.js

# And pull one back out
bunny sandbox cp my-sandbox:/workplace/out.log ./out.log

When the agent builds something worth showing, expose a port as a public HTTPS URL. When you are finished, destroy the whole thing.

# Put the dev server on port 3000 online
bunny sandbox url add my-sandbox 3000

# Done? Throw the room away.
bunny sandbox delete my-sandbox

No control plane to babysit, no separate platform to wire up. When you delete a sandbox, it's gone, and the Magic Containers app underneath goes with it. One thing to keep in mind: a sandbox keeps running, and keeps costing you, until you delete it, so tear down the ones you're finished with.

You can drive it from code too

The same operations (and more) are available as a library. Install @bunny.net/sandbox, and you can create a sandbox, write files into it, run commands, expose a port, and tear it down, all from your own program. That is how you go from spinning up one sandbox by hand to orchestrating many of them: a test matrix, a fleet of agent workers, a sandbox per user.

import { Sandbox } from "@bunny.net/sandbox";

const sandbox = await Sandbox.create({
  apiKey: process.env.BUNNYNET_API_KEY,
  name: "hi-server",
  region: "AMS",
});

await sandbox.writeFiles([
  {
    path: "server.js",
    content: Buffer.from(`
      const http = require("http");
      http.createServer((req, res) => {
        res.writeHead(200, { "Content-Type": "text/plain" });
        res.end("hi");
      }).listen(3000, () => console.log("listening on 3000"));
    `),
  },
]);

// Start the server detached so it runs in the background.
const server = await sandbox.runCommand({
  cmd: "node",
  args: ["server.js"],
  detached: true,
});

// Expose port 3000 as a public CDN URL.
const url = await sandbox.exposePort(3000);
console.log(`Open: ${url}`);

// Kill the server after 60 seconds.
setTimeout(() => server.kill(), 60_000);

// Blocks until the server process exits (via the kill above).
const finished = await server.wait();
console.log(finished.exitCode);

// Tear down the sandbox now that the server is done.
await sandbox.delete();

Isolation you do not have to think about

This is the part that lets you stop babysitting the agent.

Every Bunny Sandbox runs on gVisor. In plain terms, gVisor slips a user-space kernel between the code and the real host. To anything running inside, the sandbox looks and behaves like an ordinary Linux machine. But that code never talks directly to our kernel. It talks to gVisor, which decides what is allowed. This is a real boundary, not a normal container with the lights dimmed.

Every sandbox is walled off from every other one and from the host underneath it. An agent that goes off the rails is trapped in a room it cannot escape. That is the whole promise: the blast radius of a bad command is the sandbox, and only the sandbox.

From idea to public URL without the detour

Because Bunny Sandbox uses Magic Containers and runs on the same global edge, whatever the agent builds can go live on the same network that already serves traffic worldwide. There is no export step, no second platform, no repackaging. One command turns a port inside the box into a real, shareable HTTPS URL. Build it and ship it in the same room.

Pay for the room while you are in it

Sandboxes are disposable by design: spin up, let the agent work, tear down. A sandbox is billed at standard Magic Containers pricing:

• Compute: $0.02 per CPU core per hour, billed per second, up to 8 cores
• Memory: $0.005 per GB per hour, billed in 64 MB increments
• Workspace: $0.10 per GB per month on the allocated 10 GB
• Anycast IP: $2 per month, billed per minute (every sandbox gets one, for SSH and public URLs)

Because it's per-second and per-use, cost tracks what the agent actually does. A couple of active hours of coding work run on the order of cents of compute and memory, plus a little IP time. Heavier workloads cost more, idle ones less. Delete a sandbox and it stops costing you anything.

When you actually need this (and when you do not)

We will be straight with you, because a sandbox is a tool, not a religion.

You probably do not need a sandbox to run code you wrote and trust on your own laptop. Carry on. Sandboxes earn their keep in three situations: when the code is untrusted or agent-generated, when you are running many of these at once, or when you want to hand a running environment to your own users without handing them your infrastructure.

And one honest caveat. Isolation is a boundary, not a force field. It contains what runs inside. It does not turn bad code into good code or a leaked secret back into a safe one. Give each sandbox only the credentials the task genuinely requires. The room keeps the mess in. It is still on you not to put your crown jewels in the room.

We are just getting started

Bunny Sandbox is live today, and this is the first version. Here is what is coming:

• More agents. Claude Code is where we started, not where we stop. We are expanding to more coding agents so you can pick the one that fits the job.
• Deeper integration with the rest of bunny.net, so a sandbox can reach for the services you already use without extra plumbing.
• More code syncing, so moving work between your machine and the box stops being a chore.
• A built-in gateway, so putting your work online no longer means paying for a separate IP address.
• More SDKs. Python and Rust are on the way, so you can drive sandboxes from those languages too.

Tell us what you want to build in a box, and we will help build the box.

Try it

Want to let an agent run without watching every command it types? Give it a room. Create your first Bunny Sandbox in a couple of commands. The docs have the rest.

The CLI is open source, and the code's on GitHub — thanks to everyone who's contributed so far. Come tell us what you're building in Discord.

AI needs a safe place to build. Now it has one on a network built to make the internet hop faster. Happy building!