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 an 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!

The terminal has moved way beyond local dev. It’s where applications get deployed, infrastructure gets automated, CI pipelines run, and, increasingly, where agents take action on your behalf. That raises the bar for what a CLI has to be. A thin wrapper around an API isn't enough. It needs to be predictable, scriptable, discoverable, and easy for both people and agents.

That's been the focus of the bunny.net CLI since it launched. The first release shipped with full Database support, letting you create databases and query them without leaving the terminal. A few weeks later, Edge Scripting landed, so you could scaffold, deploy, and manage serverless functions the same way. Since then, we've kept folding more of the platform into the same workflow.

Today, Bunny DNS joins it.

Bunny DNS is our authoritative DNS hosting, and the routing engine behind our global CDN. It hosts your zones and records like any DNS provider, but it's also scriptable, so you can run your own code at query time to decide how a name answers, instead of just returning static records. The CLI can now manage both your records and the scripts that answer them.

A two-minute tour

The goal we set ourselves for this release was simple: take a domain from nothing to live on bunny.net, pointed at something real, without opening the dashboard. Here's the whole arc.

# Create the zone
bunny dns zones add example.com
✓ Created DNS zone example.com (ID: 819216).

Now update your nameservers at <your registrar> to:

 kiki.bunny.net
 coco.bunny.net

# Verify nameservers are detected
bunny dns zones ns example.com
✓ Nameservers detected and pointing to Bunny DNS for example.com.

# Point the apex at your origin, and www straight at a pull zone
bunny dns records add example.com '@' A 198.51.100.1
bunny dns records add example.com www PULLZONE my-site

Once your registrar picks up the new nameservers, the domain is live: the apex resolved directly, and www served from your pull zone across the bunny.net network. Your DNS and CDN are configured together in four commands.

That's the scripted path. When you'd rather explore, run bunny dns records add example.com with no type and the CLI walks you through it, including presets that set up a whole group of records at once:

✔ What would you like to add? › A preset (email providers, verification, security)
? Choose a preset: › - Use arrow-keys. Return to submit.
❯   Google Workspace  Email
    Gmail-hosted email: MX, SPF, optional DKIM and DMARC.
    Microsoft 365 (Outlook)  Email
    Zoho Mail  Email
    Mailgun  Email
    Resend  Email
    Proton Mail  Email
    Bluesky handle  Verification
    DMARC policy  Email security
    CAA (restrict certificate issuance)  Email security
    No email (anti-spoofing)  Email security
✔ Google DKIM TXT value (Admin console) (blank to skip) …
✔ DMARC report email (blank to skip) …
This will add 2 record(s) to <yourdomain>:

 Type   Name   Value                                 Priority
 MX     @      smtp.google.com                       1
 TXT    @      v=spf1 include:_spf.google.com ~all

? Add these 2 record(s)? › (Y/n)
✓ Applied Google Workspace to <yourdomain>: 2 record(s) added.

Choosing Google Workspace fills in the MX and SPF records for you, then asks for the two things it can't infer: an optional DKIM value from your Google admin console, and an optional DMARC report address. DKIM and DMARC are the parts of email security people most often skip, because they're easy to get wrong when configured by hand, so folding them into the preset means new domains start with sender authentication already in place.

The CLI shows exactly which records it will create and waits for a yes before writing any of them. Presets cover the other major mail providers too, including Microsoft 365, Zoho, Mailgun, Resend, and Proton Mail, alongside domain verification and standalone security records like DMARC and CAA.

Presets are the kind of thing a human reaches for while setting a domain up. An agent can skip straight past them with explicit flags.

DNS was always meant to be automated

DNS sits at the start of almost every project. Before a request reaches your application, your CDN, your edge script, or your origin, DNS decides where it goes. That makes it one of the most important parts of your infrastructure, and one of the most useful things to automate.

Creating a zone for a new project, adding records as part of a deployment, pointing a hostname at a script to route requests, exporting a zone before you change it, tearing down temporary records when a preview environment is destroyed. Each is part of a workflow rather than a one-off dashboard task, and now they're all commands you can script, run in CI, or hand to an agent.

And automating it doesn't run up a usage bill. Since Bunny DNS dropped per-query pricing, DNS hosting is now included for up to 500 domains per account, with no per-query charges and no query limits. No matter how often your pipelines and agents hit it, the queries are free.

Here are the DNS commands the CLI now supports.

Zones

You've already seen zones add, which creates a zone and prints the bunny.net nameservers to set at your registrar. The rest of the lifecycle is where you'd expect:

bunny dns zones list
bunny dns zones show example.com
bunny dns zones remove example.com

A zone is identified by its domain name or its numeric ID, so example.com and the zone ID are interchangeable wherever a command takes one.

Link a directory to a zone

Passing the domain on every command gets repetitive. Link the working directory to a zone once and the rest of the dns commands know which zone you mean:

bunny dns zones link example.com

This writes a small .bunny/dns.json manifest into your project. From then on, zone and record commands run against the linked zone without naming it. It's the same pattern as bunny db link, bunny scripts link, and soon bunny storage link, and as with those, the manifest is per-developer state, so add .bunny/ to your .gitignore. When a command falls back to the interactive picker, it offers to link the directory for you.

Records

Records live inside a zone. records add takes the name, type, and value, with the zone apex written as '@':

bunny dns records add example.com api A 198.51.100.1
bunny dns records add example.com '@' MX mail.example.com 10
bunny dns records list example.com

Run bunny dns records add with the type left off and it walks you through an interactive wizard instead. Bunny DNS supports the record types you'd expect alongside a few bunny-specific ones, including PULLZONE to point a name straight at a pull zone and SCRIPT to answer it with Scriptable DNS.

Updating and removing records works by record ID, which you can read from records list, or you can leave the ID off and pick from a list. Only the fields you pass are changed:

bunny dns records update example.com 123 --value 198.51.100.2
bunny dns records remove example.com 123

Migrate a zone with BIND files

Moving a domain onto Bunny DNS, or taking a backup before a big change, comes down to two commands. Export writes a standard BIND zone file, and import reads one back in:

bunny dns records export example.com --save
bunny dns records import example.com ./example.com.zone

--save writes example.com.zone alongside you. Omit it to print the zone to stdout and pipe it wherever you like.

DNSSEC and zone settings

Turn on DNSSEC and the CLI prints the DS record to hand to your registrar:

bunny dns zones dnssec enable example.com

Bunny DNS implements DNSSEC without exposing your zone's structure, so this is one you can switch on without the usual hesitation. Query logging and per-zone statistics are a command away too, with bunny dns zones logging and bunny dns zones stats.

Scriptable DNS from the CLI

Scriptable DNS runs your code at query time to decide how a name should answer, which is how you build geo routing, weighted answers, failover, and closest-region selection. It's a separate runtime from Edge Scripts, so it has its own command group under bunny dns scripts.

The flow mirrors Edge Scripting. Scaffold a project from an example, deploy the script, and attach it to a hostname:

bunny dns scripts init geo-router --example geo --deploy
cd geo-router
bunny dns scripts deploy handleQuery.js
bunny dns scripts attach example.com geo --script <id>

init drops a handleQuery entry file. The starters cover the common routing shapes (geo, closest, weighted, failover, and pullzone), plus an empty one to begin from scratch:

/// <reference types="@bunny.net/scriptable-dns-types" />

/** @param {DnsRequest} query */
export default function handleQuery(query) {
  const { geoLocation, serverZone } = query.request;

  return new TxtRecord(
    `country=${geoLocation.country} zone=${serverZone} asn=${geoLocation.asn}`,
    30,
  );
}

That reference line at the top is new too: @bunny.net/scriptable-dns-types ships ambient types for the Scriptable DNS runtime, so your editor autocompletes queries, records, and helpers even in plain JavaScript. No more guessing, no docs tab.

A script does nothing to your DNS until it backs a record, which is what attach handles: it adds a SCRIPT record so geo.example.com is answered by your code.

Because that record changes how a name resolves, attach always asks before it writes, and attaching at the apex prints a louder warning and lists anything already there first. In a pipeline, where there's no one to confirm, it refuses to write unless you pass --force.

That turns DNS into something you build with. Records in a table become routing logic that lives alongside the rest of your infrastructure.

Works with your agent and CI

An agent driving a tool needs three things: to discover what it can do, to call it and get a predictable result, and to recover when something goes wrong. The DNS commands are built for all three, the same way the rest of the CLI is.

Discovery comes from a consistent command structure and the skill files we ship alongside the CLI. An agent doesn't have to reverse-engineer the dashboard. It reads the skill, finds that zones, records, and scripts each follow the same shape, and knows that bunny dns <command> --help will spell out the flags.

Reliable calls come from being flags-first and deterministic. Pass the domain, the record, and the values and you get the same result every time, with no prompt waiting in the way. Linked manifests mean an agent isn't juggling zone IDs in its context, and --output json turns any command into something it can parse rather than scrape.

Recovery comes from how the CLI fails. Errors are written in plain language with a hint at the fix, exit codes are meaningful, and under --output json the error comes back as structured JSON too. An agent can tell a fixable mistake from an internal one and respond, instead of retrying blindly. Prompts and pickers are TTY-aware so they step out of the way in CI, and destructive commands like records remove and scripts attach take --force for the same reason.

The result is that the commands you run are the commands your automation runs, and the commands your agent runs. No separate integration to maintain, no protocol to configure.

One CLI for the platform

Every release brings another part of bunny.net into the workflow developers already use:

• Databases
• Edge Scripts
• DNS and Scriptable DNS
• Agentic workflows across all of them

Coming up next are Magic Containers and Storage.

Get started:

npm install -g @bunny.net/cli
bunny login
bunny dns zones add example.com

The CLI is open source and built in public. If something's broken, open an issue. If you've built something with it, come and tell us about it in Discord.

Hundreds of billions of requests pass through the bunny.net edge network every day from websites and applications around the world. That gives us a unique view into how attacks are evolving, what malicious traffic really looks like, and the techniques attackers continue to rely on.

To share those insights, we've published the bunny.net 2026 Edge Security Report.

Built from 149 days of production telemetry across our global edge network, the report explores the attack trends, traffic patterns, and architectural lessons we've observed while helping protect applications at internet scale.

Hop into the 2026 Edge Security Report →

What you'll learn

Rather than relying on surveys or industry estimates, every finding is backed by real production traffic observed across the bunny.net edge network.

The report covers:

• The biggest edge security trends shaping 2026.
• The attack techniques we see most often in production.
• How automated traffic is changing, and what that means for modern security.
• Common architectural pitfalls that can leave applications exposed.
• Real-world attack case studies and the lessons they reveal.

Whether you're responsible for infrastructure, security, or platform engineering, the report gives you a data-backed view of how today’s attacks behave in production, so you can stay one hop ahead.

Download the full Edge Security Report and explore the findings for yourself.

At bunny.net, our mission has always been ambitious but focused: help make the internet hop faster.

To do that, we’ve built a massive global network spanning 119 locations and counting. Today, this network powers over 1.5 million websites and consistently delivers some of the fastest content delivery around the globe. But while deploying thousands of servers globally is an impressive feat on its own, the hardware itself does not explain how bunny.net is able to deliver such an impressive level of performance.

The real secret hides under the hood, embedded in the routing engine that directs every request, every user, and sends traffic exactly where it needs to go. That engine is Bunny DNS.

From internal engine to 200 billion customer queries per month

Originally, Bunny DNS was built with one simple goal: to build the most advanced routing engine possible, capable of analyzing every DNS query and directing it to the optimal destination for serving your content. Even to this day, it’s what makes Bunny CDN achieve it’s exceptional performance.

Four years ago, we took everything we had learned from designing and running this system and turned it into a product our users could use themselves. With Bunny DNS, we’ve upgraded DNS from being a basic record lookup table into a globally distributed, smart routing engine. Instead of just returning static records, it allows developers to use latency data, health checks, and even JavaScript to dynamically determine exactly where requests should go.

We applied our traditional mantra. We made it affordable, scalable, and added a generous free tier. The response was incredible, and today, Bunny DNS powers over 300,000 domains and handles nearly 200 billion queries every single month.

But as we looked closer at our mission, we realized something needed to change.

Why DNS shouldn't cost extra

Dealing with infrastructure costs is already notoriously complex. You shouldn't have to stress about pricing tiers or whether a sudden spike of a million queries is going to result in an unpredictable bill.

If we truly believe in our mission to help make the internet hop faster, then the fundamental system that sits between your users and your services shouldn't be a premium add-on. It should be accessible to everyone.

So, we’ve eliminated DNS query fees entirely.

Bunny DNS no longer charges for DNS queries and includes free DNS hosting for up to 500 domains per account. There are no query limits, no per-request billing, and no critical features hidden behind enterprise plans. (Yes, that includes smart records and health monitoring too.)

As with all bunny.net services, accounts using the platform are subject to our standard $1/month minimum spend, but DNS itself no longer incurs any usage-based charges.

The entry point for everything else

Making Bunny DNS free doesn't mean we're losing interest in it. Quite the opposite. More than ever, we view DNS as the core product that glues our entire platform together. It’s the starting line for everything else your application does.

Getting that starting line set up is now easier than ever. If you're migrating from somewhere else, our new automatic zone scanning checks your domain's most common record names and types, reconstructing your zone so you only have to make a few tweaks instead of starting from scratch. (You can also just upload a BIND file if you prefer.)

Once your records are in place, the real magic happens. With 1-Click Acceleration, you can enable the CDN directly from your DNS records. We’ll spin up a Pull Zone behind the scenes and instantly start routing requests through our edge network. Once traffic is flowing, 1-Click Security lets you enable Bunny Shield instantly to filter traffic at the edge, blocking common exploits and absorbing DDoS attacks before they ever touch your origin server.

Performance, security, and routing are now unified in one place, rather than stitched together after the fact. Our goal is to keep evolving this with even more advanced record types.

Beyond making it free, we’re also making it better

Saving on costs is great, but ultimately, what drives us at bunny.net is building incredible products. While all of that was happening, we’ve also been making steady changes to DNS itself. There haven’t been many major releases, but rather a lot of smaller improvements over time.

IPv6 is no longer optional

More and more networks default to IPv6 now, especially on mobile. So we made sure everything on our side just works in a dual-stack world.

If you’re using Bunny DNS, your nameserver records already resolve over both IPv4 and IPv6. There’s nothing to configure, nothing to migrate. It just works the way it probably should have a while ago.

We’ve added DNSSEC, without the usual trade-offs

DNSSEC is one of those things people want in theory but hesitate to adopt in practice.

Part of that is the complexity, but part of it is also that traditional DNSSEC can expose information about your zone that you might not want to share.

We implemented DNSSEC with NSEC Black Lies to get around that. You still get the validation and protection against tampering, but without making it easy for someone to walk your entire domain structure.

It’s one of those details most people won’t notice directly, but it does change how comfortable you can be with turning DNSSEC on.

We’ve modernized record types

DNS has moved far beyond simple address records. Modern applications increasingly rely on DNS not just to point a name at an IP address, but to describe how clients should connect, how certificates should be validated, and how security settings should be managed over time.

That’s why we’ve been expanding Bunny DNS with support for more advanced record types.

We’ve added support for HTTPS and SVCB records, which let you hint how clients should connect to your services. TLSA records are there if you’re using DANE and want tighter control over certificate validation. And CDS and CDNSKEY help automate DNSSEC key management so you’re not rotating things by hand.

None of this is particularly flashy, but it’s the kind of stuff you end up needing once you move past a basic setup.

Helping you build faster

We take our mission seriously, and the “help” part of it is perhaps the most important. By dropping usage charges for DNS and integrating it deeply with the rest of our stack, starting with CDN and Shield, we want to help you build faster, safer, and more resilient applications without worrying about arbitrary limits.

In a world where everyone simply wants to ship as many features as fast as possible, we’re focused on something else: making Bunny DNS incredible to use and seamlessly integrated into everything else we do, so you can build faster, sleep easier, and ultimately create build better user experiences for everyone.

If you haven’t tried Bunny DNS in a while, now’s a good time to take another look. You can add your zones, point your domains, and leave it at that, or start layering on CDN and Shield when you need them.

It’s free now, so you can log in or sign up and start using it straight away.

Picking the right asset shouldn't mean juggling two dashboards.

Until recently, using Bunny Storage with DatoCMS looked something like this:

• Log into Storage
• Find the file
• Copy the path
• Switch to DatoCMS
• Paste it into a JSON field and hope you got the URL structure right
• Repeat for every asset

It worked. It just didn't feel like it should. Content editors deserve better.

The setup came out of a conversation with a customer who'd built their own version using Edge Scripting and manual JSON fields. The pieces were all there, but the day-to-day experience of choosing a file was rough on editors and even rougher to maintain across projects. We kept thinking about it and decided to build something better for everyone using Bunny Storage with DatoCMS.

The result is the bunny.net Picker, a DatoCMS plugin that turns asset selection into a single, native step inside your content editor.

Once installed, editors get a proper file picker right where they need it. Browse folders in your Storage Zone. Search the current folder. Drag files in to upload. Preview images and media before selecting. Open the selected file in a new tab when you want to double-check it. Everything happens inside DatoCMS against your live Storage Zone.

When you set up your DatoCMS schema, you choose how each field should behave. Add a JSON field, then pick the presentation that fits the content:

• bunny.net Asset for fields that hold a single file
• bunny.net Assets for fields that hold several

Either presentation accepts any file type your Storage Zone permits, so the same picker works for hero images, product photography, PDFs, video, audio, fonts, or anything else you keep in bunny.net.

For developers, the plugin stores a clean, predictable JSON value in the field. A single asset looks like this after parsing:

{
  "path": "folder/image.jpg",
  "filename": "image.jpg",
  "size": 153240,
  "contentType": "image/jpeg",
  "url": "https://my-zone.b-cdn.net/folder/image.jpg",
  "guid": "8e3b3b4e-1f6a-4b2a-9b8a-2f1e6d7c8a9b",
  "lastChanged": "2025-04-30T10:21:00.000"
}

Multi-asset fields return an array of the same shape:

[
  {
    "path": "folder/image.jpg",
    "filename": "image.jpg",
    "size": 153240,
    "contentType": "image/jpeg",
    "url": "https://my-zone.b-cdn.net/folder/image.jpg",
    "guid": "8e3b3b4e-1f6a-4b2a-9b8a-2f1e6d7c8a9b",
    "lastChanged": "2025-04-30T10:21:00.000"
  }
]

The same value comes through the DatoCMS GraphQL API, so you can query the field like any other piece of content:

That's the whole integration. No edge script required, no per-project duplication, no URL stitching in the CMS.

Configuration is equally lightweight. Point the plugin at your Storage Zone name, API key, Pull Zone hostname, and region, and you're done.

All Bunny Storage regions are supported, including Frankfurt, London, New York, Los Angeles, Singapore, Stockholm, São Paulo, Johannesburg, and Sydney. Localized JSON fields work out of the box, and existing fields using the older single-asset editor keep the same stored value format, so nothing breaks when you upgrade.

Image transformations with Bunny Optimizer

If your Pull Zone has Bunny Optimizer enabled, you can transform images on the fly by appending query parameters to the stored url.

const asset = JSON.parse(record.bunnyAsset)
const thumbnail = `${asset.url}?width=400&height=300&aspect_ratio=4:3`
const webp = `${asset.url}?format=webp&quality=80`

Common parameters:

• width, height to resize images
• aspect_ratio to crop to a ratio, for example 16:9
• format to convert to webp, avif, jpg, or png
• quality for compression quality from 0 to 100

See the Bunny Optimizer docs for the full list of options. Optimizer must be enabled on your Pull Zone for these parameters to take effect.

Building this also turned out to be a genuinely good developer experience. The DatoCMS Plugin SDK lets you develop with React and Vite while connected locally to your project, which made iterating on the picker feel closer to building a normal app than wrestling with a CMS extension. If you want to extend the plugin or build your own, their Plugin SDK docs are a good place to start. All of the code is open source on GitHub, and available on NPM.

The bunny.net Picker is available now in the DatoCMS plugin directory. Install it, point it at your Storage Zone, and give your editors the picker they should have had all along.

Bunny Shield makes identifying and blocking bots trivial. However, if you aren’t using it and have noticed anomalies in your bandwidth, we’ve prepped this guide to help you determine whether the reason is a pop star tweeting about your website or, unfortunately, a surge in bot traffic that's now costing you real money.

Not all bots are the bad guys

Before you start blocking things, it's worth understanding what's actually out there. The term "bot" covers everything from the crawler that helps get your content in Google to the script copying your entire product catalog to sell to a competitor. Treating them all the same is how you accidentally remove your site from search results.

Here's the roughly sorted landscape.

Search engine crawlers

Googlebot, Bingbot, and, yeah, mostly Googlebot. They crawl and index your content and then serve it for relevant queries in the search engine results page (SERP). For the most part, you want these, and blocking them might harm your site unless you don’t need traffic coming from search engines at all. One caveat here is that Bingbot increasingly feeds Copilot, Applebot feeds Apple Intelligence, and Google's crawl feeds Gemini. So they are being used for other things as well, and if those use cases aren't an issue, this is actually a good thing. Your site is crawled once (periodically) for multiple purposes. It become an issue when you want one, but don’t want the other.

AI search bots

OAI-SearchBot, ChatGPT-User, PerplexityBot, Claude-SearchBot, and others. These fetch your page in real time to answer a user's current question, often with a citation back to you. They're more like search crawlers than training crawlers because they can send real visitors your way.

AI training crawlers

GPTBot, ClaudeBot, Meta-ExternalAgent, and the rest. They collect content to train large language models. They can use real bandwidth and generally don't send traffic back the way a search crawler does, though that may be changing as AI assistants increasingly cite and link their sources. Whether that's worth the bandwidth depends on how you value having your content represented in the models.

Agentic and assistant bots

These are bots completing a task on behalf of a specific user, such as booking, buying, comparing, summarizing, and more. These often represent a real person with real intent, so blocking them can mean blocking a customer. The category is immature and hard to identify cleanly.

Marketing intelligence crawlers

AhrefsBot, SemrushBot, and similar. They crawl your site to build the commercial SEO datasets behind tools marketers use to track rankings, find backlinks, and size up competitors. The value to you is indirect and slightly circular. These crawlers help build the same SEO datasets you might use to analyze competitors. Whether that’s worth the crawl is a judgment call.

Social / link-preview bots

FacebookExternalHit, Twitterbot, LinkedInBot, Slackbot, Discordbot, etc. They fetch a page to build the preview card when someone shares your link. These are triggered by real people sharing your content. If you block them, your links may render as ugly bare URLs everywhere. They're generally low volume but potentially high value.

Commercial / vertical scrapers

Price-comparison engines, job aggregators, review aggregators. Whether you want them depends entirely on your business. A price comparison bot is great if you want to be compared and a problem if a competitor is using it to undercut you.

Research / archival crawlers

The Internet Archive's crawler, academic datasets, and preservation projects. Usually benign and often a public good. Common Crawl is the one that complicates the picture a little bit because it's a long-running open dataset used widely in research, but it's also been a common source of training data for language models. This means that site owners who want to limit AI training sometimes block its crawler (CCBot) too, even though its purpose is broader than that.

Monitoring bots

Uptime checkers (Pingdom, UptimeRobot), performance monitors (Catchpoint, Datadog) and your own health checks. You want the ones you recognize, especially your own. However, those are usually low volume and mostly harmless.

Malicious bots

Content thieves, hostile price and data scrapers, credential-stuffing, and brute-force bots, vulnerability scanners, spam bots, and inventory-hoarding scalpers. This is usually what you want to identify, and the only hard part is detecting them because they actively try to look like everything else on this list.

So the most important thing is that any of these can be faked**.** A request claiming to be Googlebot might be a scraper wearing a sheep’s skin.

How to diagnose it from your logs

Everything below runs against standard access logs. Just adjust field positions for your log format. Also, all of these are artificially generated examples, so real logs will have a little bit more nuance.

Growth (or lack of) in analytics sessions and conversions

Before you dig into the logs, you can just look at your bandwidth compared to analytics sessions. For example:

Bandwidth is up 81% while sessions remain roughly flat. Most analytics tools run via JavaScript, and most bots don't execute JavaScript, so they're invisible to your analytics but still consume bandwidth.

Request rate per client

Find out who's making the most requests:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

  84213 47.128.44.19
  61887 47.128.44.20
  58122 47.128.44.21
   9043 66.249.66.1
   2287 81.150.12.4
    412 81.150.12.4
    389 92.40.177.22
    301 213.205.241.9
    288 51.171.38.4
    274 78.149.203.11

The top three IPs sit in one tight block, 47.128.44.x, and each is making 50,000-80,000 requests, while your actual visitors trail off into the low hundreds. The 9,043 requests from 66.249.66.1 are from Googlebot (we’ll go through its legitimacy later). The three at the top are a coordinated scrape from a single subnet.

One thing worth doing prior to actually eyeballing this is calculating the median requests per IP first, as this will give you a baseline for what traffic normally looks like on your website. You want to identify clients making 10 or 100 times the median.

The asset-loading signature

This is one of the cleanest tells you have. When a real browser loads a page, it fetches the HTML and then everything the page references, such as CSS, JavaScript, fonts, and images. A scraper usually grabs only the HTML.

Pull everything requested by a suspect IP:

grep "^47.128.44.19" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -10

For the scraper, it's all pages, no assets:

   2104 /products/12841
   2103 /products/12842
   2101 /products/12843
   2099 /products/12844

Now run the same command against a real visitor, and the shape is completely different:

     14 /products/12841
      9 /css/main.a3f9.css
      9 /js/app.8c21.js
      7 /fonts/inter.woff2
     22 /images/product-12841-thumb.webp
      6 /api/cart/count

The real browser pulls the page plus its stylesheet, scripts, fonts, images, and a cart API call, so practically everything needed to actually render and use the page. The scraper pulls pages and nothing else. That ratio, HTML-only versus HTML-plus-assets, is hard to fake convincingly because faking it means doing real rendering work, which defeats the point of scraping cheaply.

No JavaScript execution

This is closely related, but it's worth confirming separately. Most scrapers don't run JavaScript at all, so they never hit the endpoints your frontend fires after the page loads, such as analytics scripts, lazy-loaded API calls, and tracking pixels.

Count the client-side instrumentation hits from your suspect:

grep "^47.128.44.19" access.log | grep -E "/api/|/track|/analytics|/beacon" | wc -l

For a scraper, this comes back as 0. A real browser session fires these constantly, so anything above zero, often well into the dozens per session, is a strong signal of real browser activity.

Sequential / systematic URL patterns

Humans browse associatively. They follow what interests them, jump around, double back, and so on. Scrapers walk in straight lines.

Look at a suspect's requests in time order:

grep "^47.128.44.19" access.log | awk '{print $4, $7}' | head -12

The scraper sweeps through IDs in perfect order, about two per second, with no pauses:

[10:42:01] /products/12841
[10:42:01] /products/12842
[10:42:02] /products/12843
[10:42:02] /products/12844
[10:42:03] /products/12845
[10:42:03] /products/12846
[10:42:04] /products/12847
[10:42:04] /products/12848
[10:42:05] /products/12849
[10:42:05] /products/12850
[10:42:06] /products/12851
[10:42:06] /products/12852

A real visitor's path looks nothing like that:

[10:41:55] /
[10:42:03] /products/winter-jacket
[10:42:31] /products/winter-jacket?color=navy
[10:42:58] /cart
[10:43:12] /products/wool-scarf
[10:44:40] /products/winter-jacket

Homepage, a product, a variant of that product, a different product, the cart, and then back to the first one, with irregular gaps of eight to forty seconds where a person was actually reading.

User-agent distribution

Now look at what everything is claiming to be:

awk -F'"' '{print $6}' access.log | sort | uniq -c | sort -rn | head -12

 204417 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36
 184992 python-requests/2.31.0
  61003 Mozilla/5.0 (compatible; GPTBot/1.2; +https://openai.com/gptbot)
  44781 Mozilla/5.0 (compatible; ClaudeBot/1.0; +mailto:claudebot@anthropic.com)
  29550 Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://ahrefs.com/robot/)
  18204 Go-http-client/2.0
  12876 Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)
   9043 Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
   3001 Scrapy/2.11 (+https://scrapy.org)
   2422 curl/8.4.0
    880 (empty)

Reading down the list:

• The 204k "Chrome" entries look human, but this line almost certainly hides spoofed bots because impersonating Chrome is the easiest disguise there is.
• 184k python-requests. That's a scripting library, and having a Python HTTP client as the second-busiest "user" is a lot.
• GPTBot, ClaudeBot, and AhrefsBot: bots that honestly declare themselves. You can decide what to do with each by name.
• Go-http-client, Scrapy, curl, and the blank entry are almost all automation. A lot of curl requests could be individual people looking to pull something from the terminal.

The honest bots label themselves, and the lazy scrapers don't bother to hide. The tricky ones might be hiding inside that first "Chrome" line, which is why user agent header is just one of the things to check.

Verifying identity with a DNS lookup

When a request claims to be a known crawler, you can verify its identity. The standard method is a reverse-then-forward DNS check.

For a request claiming to be Googlebot:

$ host 66.249.66.1
1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

$ host crawl-66-249-66-1.googlebot.com
crawl-66-249-66-1.googlebot.com has address 66.249.66.1

The IP reverse-resolves to a googlebot.com hostname, and that hostname forward-resolves back to the same IP. The round trip matches, and the domain is correct, so it’s a verified Googlebot.

Now here's a request that also claimed to be Googlebot, from one of our scraper IPs:

$ host 47.128.44.19
19.44.128.47.in-addr.arpa domain name pointer ec2-47-128-44-19.ap-southeast-1.compute.amazonaws.com.

It claimed to be Googlebot, but the IP reverse-resolves to an AWS EC2 instance in Singapore, not googlebot.com. Google does not crawl from EC2 instances. The user-agent was identical to the real Googlebot's, but it’s not actually Google’s.

Published IP ranges

Most major crawlers publish the IP ranges they operate from, which gives you a faster check than a DNS round trip at scale. OpenAI publishes theirs as a JSON file:

$ curl -s <https://openai.com/gptbot.json> | head
{
  "creationTime": "2025-10-30T11:00:00.000000",
  "prefixes": [
    {
      "ipv4Prefix": "132.196.86.0/24"
    },
    {
      "ipv4Prefix": "172.182.202.0/25"
    },
    {
      "ipv4Prefix": "172.182.204.0/24"
    ...
  ]
}

If a request claims to be GPTBot but its source IP isn't in OpenAI's published ranges, then it isn't GPTBot. The same approach works for Anthropic, Perplexity, Microsoft, and Google. The only maintenance cost is keeping the lists current, since they change.

ASN lookup

Look at where traffic originates by network, not just by individual IP:

awk '{print $1}' access.log | sort -u | asn-lookup | sort | uniq -c | sort -rn | head

  189442  AS16509  Amazon-AES
   72103  AS14061  DigitalOcean
   41996  AS24940  Hetzner
   38201  AS5089   Virgin Media
   31774  AS2856   BT
   22018  AS5607   Sky UK

The top three sources by volume are all data centers while real consumer audiences come from residential and mobile ISPs like Virgin, BT, and Sky. So if you are seeing the most requests from AWS and Hetzner, these are likely not real users. One important thing to mention is that legitimate crawlers like Googlebot also run from data centers, so this signal isn't conclusive on its own. However, you can identify legit crawlers in different ways.

Geographic and timing anomalies

Requests by country:

  142883  SG
   38201  GB
   12009  US
    8841  DE

This one depends entirely on your situation, but the logic is simple: if you're a UK e-commerce store and your single largest source of traffic is Singapore, by a wide margin, you're almost certainly looking at bots rather than a sudden surge of overseas customers.

Timing tells the same kind of story. Here's a suspect's requests per hour across a day:

00:00  ████████████████████  5,012
01:00  ████████████████████  4,998
02:00  ████████████████████  5,031
03:00  ████████████████████  4,987
...
13:00  ████████████████████  5,004
...
23:00  ████████████████████  5,019

An almost flat line with roughly 5,000 requests an hour at 3 a.m. and 1 p.m. alike. Human behavior has some daily rhythm that makes traffic quieter overnight, build through the morning, and reach its peak in the afternoon and evening. A perfectly flat 24-hour line is a machine crawling at a constant rate. Real human traffic would look more like this:

00:00  ████  890
03:00  ██  410
08:00  ████████████  3,100
13:00  ████████████████████  5,200
20:00  ██████████████████  4,600
23:00  ████████  2,000

The issue with this approach

Every check above happened after the fact, on traffic you've already paid for. The scraper in these examples may have run 200,000+ requests before you grepped your way to it. IPs rotate, published ranges change, new crawlers appear, and the ones trying to hide adapt to whatever you're filtering on. So it’s a lot of work, and most of it is reactive.

So the real goal here is to understand your traffic well enough to make deliberate calls: which bots you want, which you don't, and where to draw the line. Once you can see clearly what's hitting your site, you're in a position to do something about it.

A few weeks ago we introduced the bunny.net CLI, one command-line tool for managing your entire bunny.net stack. That first release shipped with full Database support, and we promised more would follow.

Today, Edge Scripting lands in the CLI.

You can scaffold a new script from a template, develop and test it locally with Node or Deno, deploy a built bundle to the global network, manage environment variables, and step through deployment history from your terminal.

A two-minute tour

If you've already got the CLI installed and you're logged in, three commands will get you to a deployed function:

bunny scripts init --name my-edge-app --type standalone --template "Return JSON" --deploy
cd my-edge-app
npm run build
bunny scripts deploy dist/index.js

If you haven't installed the CLI yet, do that first:

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

Scaffold a project from a template

bunny scripts init creates a new edge script project on your machine. Run it with no flags and the CLI walks you through it interactively, asking you to pick a template, name the project, and choose whether to install dependencies:

You can also pass everything as flags, which is handy when you're in a hurry or when an agent is driving:

bunny scripts init \
  --name my-edge-app \
  --type standalone \
  --template "Return JSON"

Add --deploy to also create the remote script on bunny.net and link the directory in the same step. Without it, init only scaffolds the local project, and you create the remote script later with bunny scripts create.

The built-in templates are Empty, Return JSON, and Simple Middleware. Each one comes with a working project layout and sensible defaults so you can build and deploy straight away.

You can also bring your own template from a Git repo:

Custom templates always prompt before installing dependencies, since a template's install scripts run on your machine. Review the repo before you let it install.

Run it locally

Edge Scripts are JavaScript and TypeScript projects built on Web-standard APIs. You develop them locally with your own editor and the debugging tools you already use.

The CLI auto-detects your package manager from the template's lockfile (bun, npm, pnpm, or yarn) and uses the template's own dev and build scripts:

cd my-edge-app
npm install
npm run dev

The CLI doesn't yet ship a custom runtime emulator. It wraps the tools you'd reach for anyway, so local development stays fast and predictable.

Link a directory to a script

Once you've got something you want to deploy, connect the working directory to a script on bunny.net:

Run it once, and it writes a small .bunny/script.json manifest into your project that records which script on bunny.net this directory belongs to. From that point on, every other scripts command knows what you're targeting:

• bunny scripts deploy deploys this project
• bunny scripts env set API_KEY=... writes to this script's environment
• bunny scripts deployments list shows this script's history

The script ID stays out of your shell history, and you don't pass it on every command. Run bunny scripts link with no flags to choose from a list, or bunny scripts link --id 12345 to link directly.

The manifest holds per-developer state, so it shouldn't be committed. bunny scripts init adds .bunny/ to your .gitignore automatically. If you ran bunny scripts link or bunny scripts create in an existing repo, add .bunny/ to .gitignore yourself, then anyone who clones the repo links their own script.

For those deploying scripts in CI, you can skip the project linking by passing the Edge Script ID when you deploy:

Build and deploy

Edge Scripts deploy as a single built bundle. The CLI doesn't build for you, so run the template's own build step first, then point deploy at the output:

npm run build
bunny scripts deploy dist/index.js

deploy uploads the file as a new release and publishes it live by default. On success it prints the script's live hostname:

✓ Published my-edge-app
  https://my-edge-app.bunny.run

If you want to upload a release without publishing it, stage it with --skip-publish and publish later.

Put it on your own domain

Every script gets a bunny.run URL, but you can also bring your own domain. We've made it super easy with a new command:

bunny scripts domains add sets up HTTPS on your own domain. bunny.net issues SSL certificates for free and can do so as soon as your DNS points to the network, so the command prints the exact CNAME record to create, along with the follow-up command to run. Once DNS has propagated, request your certificate:

HTTPS is enforced by default, so anyone arriving over http:// is redirected.

List a script's domains any time to check their SSL status:

Manage environment variables and secrets

Most edge functions need configuration values like API tokens, feature flags, or region hints. The CLI handles two kinds. Plain variables are stored on bunny.net and can be read back. Secrets are encrypted, and their values can never be read back once set:

bunny scripts env set DATABASE_URL "libsql://..."
bunny scripts env set API_KEY "sk_..." --secret
bunny scripts env list
bunny scripts env remove API_KEY

Names are uppercased automatically, and a name can be a variable or a secret but not both. env list shows secret values as blank, since the API never returns them.

To pull plain variables into a local file for development, use env pull. It writes NAME=VALUE lines to .bunny/.env. Secrets are never included, so keep their source values somewhere safe:

Listing supports --output json, useful for diffing or syncing with another tool:

Deployment history

Every release is recorded, and the CLI gives you a view into that history:

ID       Status      Author   Released   Published
14021    ● Live      jamie    2m ago     yes
14008    ○ Archived  jamie    1h ago     yes
13990    ○ Archived  jamie    1d ago     yes

The live release is marked with a filled dot, and archived releases are marked with an open one. If a release is live and the script has a linked pull zone, the hostname is printed at the end.

Need to roll back? You don't have to rebuild anything. The bundle for every past release is already on bunny.net, so grab the ID of a known-good one from that list and republish it:

This flips which release is live without re-uploading anything, so a bad deploy can be undone in seconds. deploy ships new code. publish re-promotes a release that has already shipped.

See how it's doing

Once a script is serving traffic, you'll want to know how much traffic it's handling and what it's costing. bunny scripts stats pulls request, CPU, and cost totals for the script and draws a per-day bar chart of requests served right in your terminal:

bunny scripts stats

Key                   Value
Script                bunny-cards
Period                last 30 days
Total Requests        1,455
Total CPU             43,336ms
Avg CPU / Execution   29.78ms
Total Cost            $0.00

Requests served
May 18, 2026  ░░░░░░░░░░░░░░░░░░░░░░░░    0
May 19, 2026  ████████████████████████  504
May 20, 2026  ██████████████████░░░░░░  383
May 21, 2026  ░░░░░░░░░░░░░░░░░░░░░░░░    0
May 22, 2026  ░░░░░░░░░░░░░░░░░░░░░░░░    0
May 23, 2026  ░░░░░░░░░░░░░░░░░░░░░░░░    0
May 24, 2026  ░░░░░░░░░░░░░░░░░░░░░░░░    0
May 25, 2026  █░░░░░░░░░░░░░░░░░░░░░░░    4
May 26, 2026  ░░░░░░░░░░░░░░░░░░░░░░░░    0
May 27, 2026  █░░░░░░░░░░░░░░░░░░░░░░░    5
May 28, 2026  ██░░░░░░░░░░░░░░░░░░░░░░   37
May 29, 2026  ████░░░░░░░░░░░░░░░░░░░░   90
May 30, 2026  ░░░░░░░░░░░░░░░░░░░░░░░░    0
May 31, 2026  ░░░░░░░░░░░░░░░░░░░░░░░░    0
Jun 1, 2026   ░░░░░░░░░░░░░░░░░░░░░░░░    0
Jun 2, 2026   ░░░░░░░░░░░░░░░░░░░░░░░░    0
Jun 3, 2026   ░░░░░░░░░░░░░░░░░░░░░░░░    0
Jun 4, 2026   ███████████░░░░░░░░░░░░░  223
Jun 5, 2026   █████████░░░░░░░░░░░░░░░  191
Jun 6, 2026   █░░░░░░░░░░░░░░░░░░░░░░░   11
Jun 7, 2026   █░░░░░░░░░░░░░░░░░░░░░░░    5
Jun 8, 2026   █░░░░░░░░░░░░░░░░░░░░░░░    2

By default, it covers the last 30 days. Narrow the window with --from and --to, or switch to an hourly breakdown when you're chasing a spike:

bunny scripts stats --from 2026-05-01 --to 2026-05-31
bunny scripts stats --hourly

Like everything else, it uses your linked script when you don't pass an ID, and --output json gives you the data to pipe into whatever you use to track usage.

Works with your agent and CI

Prompts and spinners are TTY-aware, so they disappear in CI. Commands support --output json, and destructive commands like delete and env remove take --force so they don't block on a confirmation prompt in a pipeline.

In CI you can skip the global install and run the CLI through npx:

# .github/workflows/deploy.yml
- run: npm ci
- run: npm run build
- run: npx @bunny.net/cli scripts deploy dist/index.js ${{ secrets.SCRIPT_ID }}
  env:
    BUNNYNET_API_KEY: ${{ secrets.BUNNYNET_API_KEY }}

When you scaffold with bunny scripts init --deploy, the command prints the SCRIPT_ID to add as a repo secret, so CI deploys to the right script without committing the link manifest.

AI coding assistants use the CLI directly, either from a global install or through npx @bunny.net/cli. We ship Edge Scripting skills alongside it, so Claude Code, Cursor, Windsurf, or any agent that runs shell commands can scaffold a project, link it, set environment variables, and deploy.

What's next

Edge Scripting joins Bunny Database in the CLI today. Storage, Magic Containers, and the rest of the bunny.net stack are coming next.

Get started and create your first Edge Script with the bunny.net CLI:

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

The CLI is open source and developed in public. If something's broken, open an issue. If you want to share what you've built, find us in Discord.

We pay attention to what people build on bunny.net. Some of it genuinely impresses us, and all of it deserves a shoutout. So, here's the first edition of a monthly roundup highlighting the projects, packages, and writeups we've spotted across the community. If you're planning your own setup, there’s plenty here worth exploring. It’s also our way of saying thanks to the people building with bunny.net.

If you've shipped, written, or open-sourced something, tag us or send us a message. We'd love to take a look for next month's roundup.

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

Shipped on bunny.net

kaku.so

A statically rendered Japanese dictionary with 290k entries translated into 11 languages, plus built-in spaced repetition for practice. The scale of the project is genuinely impressive: more than 10 million files, 400 GB+ of data, and a 12-hour build process. The entire stack moved from Azure PostgreSQL to bunny.net after Bunny Database launched.

yaan.ch

A drop-in replacement for hCaptcha, reCAPTCHA and Friendly Captcha. Invisible, GDPR-compliant, not proof-of-work. The marketing pages and backend run on Bunny Storage and Edge Scripting. The Rust anti-bot engine runs on Magic Containers, and the database will move to Bunny DB once it exits public preview.

Convex self-hosted on Magic Containers

Patrick Faust got the Convex self-hosted runtime running on bunny.net Magic Containers and documented the process in two LinkedIn posts: one when it was approved, and another when it went live.

Nitro.film

Apple TV app built by a solo founder on Bunny Stream, with much of the development process shared publicly on LinkedIn as part of a ‘build in public journey’.

Kraken

Robin Dost has been building Kraken, a CTI platform that tracks adversary infrastructure, including domains, IPs, and dead drops, over time so analysts don’t lose visibility after initial discovery. It’s currently running live in evaluation and hosted in Europe on bunny.net.

The Imago Platform

Magnus Helander is building the Imago Platform on Bunny CDN, sitting at 99.995% uptime since launch. He also built and shipped a Claude skill for writing Edge Scripts on bunny.net.

Moving to bunny.net

Three writeups from the past month, all worth reading if you're thinking about your own setup.

• Johanna Larsson - moved a Phoenix/Elixir blog to bunny.net with a full walkthrough and code examples.
• Alec Armbruster - built a tunnels-style setup running on bunny.net.
• David Drugeon-Hamon - documented a GitHub-to-Codeberg switch with bunny.net in the stack.

Shipped for bunny.net

CDN

A community-built API client I recently came across:

• bunny-cdn-sdk - typed Python SDK and CLI covering Bunny CDN and Bunny Storage.

Stream and video

• bunnycdn-stream - TypeScript library for the Bunny Stream API.
• playstack - React video player that supports Bunny Stream.
• sanity-plugin-bunny-input - input component for Sanity Studio.

Storage

• payload-storage-bunny - Payload CMS adapter for Bunny Storage and Bunny Stream with auto-purging and resumable uploads via tus.
• bunny-transfer - rsync-style CLI for moving files in and out of storage zones.
• upload-to-bunny - directory uploader aimed at CI pipelines.

Shield and security

• octorules-bunny - Shield WAF rules as code, built and used in production by Doctena, an EU healthcare scheduling company.

Working with AI agents

• bunnycdn-mcp - MCP server for bunny.net.
• bunny-edge Claude plugin - Magnus Helander’s Claude skill for writing Edge Scripts on bunny.net. Install with /plugin install bunny-edge@mheland.

That’s it for May. 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.

Magic Containers became programmable with the introduction of the Public API. The next step was making it react in real time.

In practice, operations like deploys and updates could take tens of seconds to complete. Not because anything was failing, but because of how control loops work.

Each part of the system waits for the next reconciliation cycle, and those delays stack up across components.

As workloads become more short-lived and automated, lifecycle speed becomes an increasingly important part of the developer experience. Spinning up a container, scaling it, or tearing it down should feel immediate.

This is the problem we set out to solve.

The problem: control loops introduce latency

Magic Containers is built around a control loop architecture.

Each component continuously reconciles desired state → actual state:

• Application Provisioner → selects regions for deployment
• Controller Manager → ensures the desired number of replicas
• Scheduler → assigns pods to nodes
• Local Container Manager (LCM) → ensures containers run on the assigned node

Each of these components runs independently in a loop:

while True:
	observe_state()
  diff = desired_state - actual_state
  if diff:
	  reconcile(diff)
  sleep(interval)

This model is extremely reliable and forms the backbone of many distributed systems, including Kubernetes.

But it comes with a tradeoff.

Latency compounds across loops.

Each loop runs on an interval of ~5 to 10 seconds.

That means a single operation doesn’t execute immediately. Instead, it waits for the next loop iteration.

Now chain multiple components together:

User action
	→ waits for Provisioner loop (up to 10s)
	→ waits for Controller loop (up to 10s)
	→ waits for Scheduler loop (up to 10s)
  → waits for LCM loop (up to 10s)

In the worst case, this stacks up to tens of seconds before a container is fully running.

Even under typical conditions, deploys and updates felt noticeably delayed.

Nothing was technically incorrect. The system always converged to the correct state, but the experience lagged behind what modern workflows expect.

What we considered (and rejected)

We explored several approaches before settling on the final solution.

1. Decreasing loop intervals

Reducing intervals from ~10 seconds to sub-second.

Why we rejected it:

• Significant increase in CPU usage across all control plane components
• Higher pressure on state storage and coordination systems
• Still fundamentally polling-based, meaning latency never reaches zero

2. Removing loops entirely

Moving to a purely event-driven system.

Why we rejected it:

• Loops are critical as a safety mechanism
• They continuously verify and correct drift between desired and actual state
• Without them, missed events could lead to permanent inconsistencies

3. Hybrid model (chosen)

Keep loops for correctness and safety, but introduce events for immediacy.

The solution: event-driven acceleration

We introduced a message broker with event queues between components.

The key idea: Loops ensure consistency. Events provide speed.

Instead of waiting for the next loop iteration, components now react immediately when something changes.

Before: loop-driven propagation

[User Action]
↓
(wait for Provisioner loop)
↓
(wait for Controller loop)
↓
(wait for Scheduler loop)
↓
(wait for LCM loop)
↓
[Container Running]

After: event-accelerated flow

[User Action]
↓
[Event: Application Created] → Queue
↓
[Provisioner triggered immediately]
↓
[Event: Provisioning Complete]
↓
[Controller Manager triggered]
↓
[Event: Pods Created]
↓
[Scheduler triggered]
↓
[Event: Pod Scheduled]
↓
[LCM triggered]
↓
[Container Running]

How It Works

Each component now listens for specific events and reacts instantly.

Example event

{
    "type": "application.created",
    "app_id": "app_123",
    "regions": ["eu-central", "us-east"],
    "timestamp": 1713949200
}

Provisioner

func handleApplicationCreated(event Event) {
    regions := selectRegions(event)
    publish("provisioning.completed", regions)
}

Controller Manager

func handleProvisioningComplete(event Event) {
    createReplicas(event.app_id, desiredReplicas)
    publish("replicas.created", event.app_id)
}

Scheduler

func handleReplicasCreated(event Event) {
    node := selectNode(event)
    publish("pod.scheduled", node)
}

Local Container Manager (LCM)

func handlePodScheduled(event Event) {  
		startContainer(event.node, event.pod)
}

Important: loops still exist

The control loops were not removed.

They still run continuously to:

• Detect drift (e.g., crashed containers or missing replicas)
• Reconcile inconsistencies
• Act as a fallback if events are delayed or lost

// simplified reconciliation loop
for {
    diff := computeDiff(desiredState, actualState)
    if diff != nil {
        reconcile(diff)
    }
    sleep(5 * time.Second)
}

This hybrid design gives us:

• Fast reaction time (events)
• Strong consistency guarantees (loops)

These events don’t just drive internal components, they also power real-time updates across the platform, including the Dashboard.

From control plane to user experience

Reducing backend latency is only part of the story.

Before this change, even when operations completed, the Dashboard still relied on polling to fetch updates. This introduced an additional delay between something happening in the system and the user actually seeing it.

In practice, this meant:

• Deploy finishes → UI updates a few seconds later
• Scaling event happens → user sees it after the next refresh cycle

To solve this, we extended the same event-driven model all the way to the frontend.

Real-time updates via WebSockets

We introduced WebSocket-based event streaming between the control plane and the Dashboard.

Instead of polling for state changes, the UI now subscribes to live updates:

Client → opens WebSocket connection
→ subscribes to application events

Whenever something changes:

[Control Plane Event]
↓
[Message Broker]
↓
[WebSocket Gateway]
↓
[Dashboard UI updates instantly]

What this changes

This removes the final layer of perceived latency.

Before

• Backend finishes → UI polls → user sees update later

After

• Backend finishes → event emitted → UI updates instantly

Result

• Deploy progress updates feel real time
• Scaling actions are visible immediately
• State transitions (creating → running → scaling) feel continuous

Why this matters

Without this step, the platform would be technically fast but still feel slow.

By pushing events all the way to the UI, we aligned:

• System speed
• User perception

The impact

By eliminating waiting between steps, we removed the largest source of latency.

Before vs. after

What changed technically

• Removed dependency on loop timing for forward progress
• Reduced end-to-end latency by an order of magnitude
• Maintained correctness via continuous reconciliation

Why this matters

This fundamentally changes how Magic Containers behaves.

• CI/CD pipelines speed up. Infrastructure is no longer the slowest step
• Ephemeral workloads become practical. Create → run → destroy flows now complete in seconds
• Event-driven systems feel natural. Infrastructure now reacts at the same speed as application logic

Tradeoffs and challenges

1. Event ordering

Ensuring correct sequencing across distributed components.

Solution:

• Idempotent handlers

2. Reliability

Events can fail or be delayed.

Solution:

• Retry mechanisms
• Dead-letter queues
• Control loops as fallback

3. Observability

Async systems are harder to debug.

Solution:

• Correlation IDs
• Event tracing across components

What’s next

We’re already exploring:

• Optimizing image download times to reduce startup time
• Automated build and updates directly from your GitHub repository
• Access to recent log history alongside live logs for easier troubleshooting

Final thoughts

Magic Containers started as a loop-driven control plane designed for correctness.

With the introduction of event-driven acceleration, it now reacts immediately to changes, without relying on the next reconciliation cycle.

The result is a system that converges just as reliably, but gets there much faster.

European infrastructure teams are facing a massive challenge.

With regulations like GDPR, NIS2, and the EU Data Act tightening across the continent, compliance is no longer a checkbox. It dictates your entire architecture. Historically, the industry narrative held that guaranteeing data sovereignty meant sacrificing raw edge performance.

We weren’t willing to trade performance for sovereignty. Now, you don’t have to either.

bunny.net teamed up with STACKIT, the cloud provider of Schwarz Digits, to deliver a high-performance, regulation-ready, EU-sovereign content delivery network (CDN) and edge security ecosystem built specifically for European businesses.

Uncompromising performance under European law

This partnership brings together two teams obsessed with digital independence. If you aren't familiar with STACKIT, it is the cloud backbone of Schwarz Digits, the IT organization behind Schwarz Group. Operating out of its German headquarters, it has built an enterprise-grade cloud ecosystem focused entirely on data privacy and sovereign control.

By combining STACKIT’s cloud infrastructure with bunny.net’s global edge network, we are launching an integrated ecosystem that meets the needs of both your legal team and your DevOps leads.

When you route your traffic through STACKIT CDN, your data remains fully within EU jurisdiction. No hidden tracking cookies, no data monetization, and no third-party analytics processing your users' information.

Engineering edge security and scale

We built this ecosystem to handle demanding, enterprise-scale workloads optimized for compliance.

Here is what this sovereign architecture delivers out of the box:

• Global edge performance: Connect your STACKIT-hosted applications directly to a global edge network backed by 250 Tbps+ of backbone capacity, ensuring consistent sub-30 ms latency across Europe and beyond.
• Integrated edge protection: Mitigate risks before traffic hits your infrastructure. The platform injects robust security tools right at the edge, including a web application firewall (WAF), Distributed Denial-of-Service (DDoS) mitigation, and global rate limiting.
• Transparent cost infrastructure: Scale your application without worrying about complex pricing tiers or vendor lock-in. Keep track of your carrots with a predictable, transparent, pay-as-you-go cost model.

Building an independent digital future

Your company’s growth shouldn’t be punished for protecting user privacy. By anchoring your traffic in a trust-first ecosystem like Stackit CDN, you can optimize your delivery pipeline, satisfy strict regulatory requirements, and maintain absolute control over your data.

Ready to see how the new sovereign edge can transform your stack? Hop on over to the STACKIT platform to learn more, or connect with our team to find out how to hop ahead securely.