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.

Back in January, we welcomed the first group of founders into HopStart, our program designed to take infrastructure off the plate of early-stage teams so they can pour their energy into the products they're building.

Since then, applications for the second round have rolled in, and the bar has only gone up. As a reminder, each cohort runs quarterly and supports three startups with up to $50,000 USD in credits for bunny.net, regular touchpoints with our team, and early access to features and products before they launch more broadly.

Picking just three was genuinely hard. There were plenty of products we'd have loved to back. Ultimately, we look for teams solving real problems for their users, especially when bunny.net is a natural fit for the infrastructure behind their product.

Here are the three startups joining HopStart cohort #2.

1st place: Sublimly

Founder: Patrick Faust

Year founded: 2025

URL: https://www.sublimly.com/

Credits received: $50,000 for one year

In the founder's words: "Sublimly is a SaaS platform that empowers real estate agents, luxury brands, travel companies, and UGC creators to produce professional-quality videos and photos in minutes — without any design or video editing skills. Users upload their raw photos, and our AI-powered pipeline handles the heavy lifting: intelligent photo enhancement, automated background removal, smart cropping, and AI-generated copy tailored to each industry context. Users then select a template adapted to their vertical, and Sublimly programmatically generates polished, branded video content ready for social media."

2nd place: Writizzy

Founder: Hugo Lassiège and Thomas Sanlis

Year founded: 2025

URL: https://writizzy.com/

Credits received: $25,000 for one year

In the founders' words: "Writizzy is a European publishing platform designed as an open alternative to Substack or Medium. The goal isn't just to provide another CMS, but to give creators back control over their digital real estate. In an era of platform lock-in and centralized moderation, we provide a space where authors truly own their content and audience."

3rd place: ScratchUpload

Founder: Nathaniel Sturtz

Year founded: 2025

URL: https://scratchupload.org/

Credits received: $10,000 for one year

In the founder's words: "ScratchUpload is leading the way in privacy- and accessibility-focused image hosting for an underserved community: users of SimplyPlural and Pluralkit."

Apply for HopStart cohort #3

The window for the next round is open now. If you're building something with real ambition behind it, and you can see bunny.net playing a role in helping you get there, we'd love to hear from you. Submit your application via the short form before May 31.

If you applied previously and didn't make it through, please don't take that as a ‘no’ for good. Fit shifts from one round to the next, and what didn't land before could be exactly the right fit this time.

We'll share the cohort #3 lineup in July.

We can't wait to see what you've been working on!

Whether you're a creator sharing your work through Vimeo or a developer integrating video into an app or platform, this guide walks you through how to migrate your video content to Bunny Stream.

What we’ll cover:

• Choosing the right migration path for your situation
• How to move your video content manually with direct upload or URL import
• How to automate the process with CLI-based bulk migration

Why migrate from Vimeo to Bunny Stream

Vimeo is an all-in-one SaaS platform for hosting, managing, and sharing video content. As of May 2026, it offers four paid tiers (Starter, Standard, Advanced, and Enterprise) billed either monthly or annually. Each tier comes with fixed storage and bandwidth limits, and more advanced features are only available in the higher subscription plans.

Bunny Stream is a feature-rich video hosting solution that is part of the bunny.net web infrastructure platform. Instead of subscription tiers, Bunny Stream uses a usage-based pricing model, where you’re charged only for the storage you use and the traffic your videos receive.

With the exception of some enterprise-grade add-on features, Bunny Stream offers most of its functionality to all users, regardless of how much they pay. By default, Bunny Stream is prepaid, meaning you purchase credits to use it, which ensures you’re never hit with runaway costs (though postpaid is available on request).

Despite being part of an API-first web infrastructure platform, Bunny Stream has an intuitive user interface, that makes it accessible to non-technical users. With its attractive, usage-based pricing, it’s very cost-effective for small creators and growing businesses alike.

Planning your migration from Vimeo to Bunny Stream

The right migration path depends mostly on the size of your video library and how you want to handle the process. In general, you have three options:

• Manual upload → best for small libraries; requires access to your original video files
• URL fetch → also practical for smaller libraries; lets you import videos using a direct file URL from Vimeo without downloading them locally
• Bulk migration using the Vimeo2Bunny CLI tool → best for larger libraries; automates the migration process

Pick the option that works best for you, then follow the instructions below.

Migrate via manual upload

Before you begin, sign up for a bunny.net account and make sure you have all the videos you need saved on your computer.

• Step 1: In your bunny.net dashboard, go to Stream.
• Step 2: Click Add Video Library, then enter a name.
• Step 3: Once the library is created, select Upload a Video. You can upload multiple videos at once.
• Step 4: After the upload is complete, your video(s) will appear in the library. Selecting a video will take you to a screen like the one below, where you can edit its title, description, etc., as well as grab its URL or embed code.

And that’s it: your videos are now ready to be shared.

• If you’re sharing videos privately (e.g., sending a link to a client), just copy the Direct Play URL from the video’s page in the dashboard.
• If you’re hosting videos on your website, replace your existing Vimeo embeds with Bunny Stream embed codes. You can adjust embed settings and copy the embed code from the video’s page under Embed.

Migrate via URL fetch

Instead of uploading files from your computer, you can import videos using a direct file URL from Vimeo.

• Step 1: In your bunny.net dashboard, go to Stream.
• Step 2: Click Add Video Library, then enter a name.
• Step 3: Now go to your Vimeo account and navigate to your video library.
• Step 4: Choose a video you’d like to move to Bunny Stream and click the Share dropdown ("More sharing options") in the top-right corner.
• Step 5: Select Download — you’ll get a pop-up menu with available resolutions to download.
• Step 6: Right-click the download icon for the resolution you’d like to upload and select Copy link address.
• Step 7: Now go back to your bunny.net video library, click the dropdown next to Upload a Video, and select Upload Video from URL.

• Step 8: Paste the Vimeo URL from your clipboard into the URL field of the pop-up menu and click Upload Video.

Note that, depending on your Vimeo video settings, you may need to add request headers and key values under Advanced if they are needed to authenticate the HTTP/HTTPS request to download your video.

As with manual uploads, if you're hosting videos on a website, you'll need to replace your existing Vimeo embeds with Bunny Stream embed codes. You can adjust embed settings and copy the embed code from the selected video’s page under Embed.

Bulk migration using Vimeo2Bunny CLI

Both manual upload and URL fetch methods are impractical for larger libraries, so we built a CLI tool that automates the video migration using URLs.

Vimeo2Bunny is able to fetch all (or selected) videos and folders from your Vimeo account and create bunny.net collections matching your Vimeo folder structure.

For each video, the tool gets a download URL from Vimeo and sends it to bunny.net’s fetch endpoint. Bunny Stream downloads directly from Vimeo and copies title, description, and tags. The tool also saves progress to ~/.vimeo2bunny/migration-state.json so migrations can be resumed if needed.

You can run Vimeo2Bunny without installation using npx. If you don’t have npx installed, follow this official installation guide.

To use the tool, you’ll need to first get the API credentials from both Vimeo and bunny.net.

How to get the Vimeo Access Token

• Step 1: Log in to the Vimeo Developer Portal and click Create an app.
• Step 2: Enter a name for the app and add a brief description. Avoid including “Vimeo” in the name as it will be rejected.
• Step 3: Select No for “Will people besides you be able to access your app?”, then accept the terms and click Create App.
• Step 4: On your app’s page, go to the Authentication section in the left sidebar.
• Step 5: Under Generate an access token, select Authenticated (you) and check the following scopes:

• Step 6: Click Generate. Your personal access token will appear under Personal Access Tokens. Copy and store the token immediately, as it won’t be shown again.

How to get your Bunny Stream credentials

• Step 1: Log in to bunny.net.
• Step 2: Go to Stream and select a video library.
• Step 3: Go to API and copy the Video Library ID and the API key.

How to use the Vimeo2Bunny CLI

If you’re using npx (recommended), remember to prefix all commands with npx. Alternatively, you can install from npm or clone the repo, as described here.

To get started, run:

You’ll be prompted to enter your Vimeo Access Token, Bunny Stream Library ID, and Bunny Stream API key. Alternatively, you can set environment variables (or use an .env file):

Once configured, the tool lets you list your Vimeo content and migrate all or selected videos:

Here’s what gets mapped during bulk migration and how:

After migrating your videos to Bunny Stream, don’t forget to replace your existing Vimeo embeds with Bunny Stream embed codes. You can find more details about embedding videos in the docs.

Wrapping up

Migrating from Vimeo to Bunny Stream is straightforward once you’ve chosen the approach that fits your setup.

• For smaller libraries, manual upload or URL fetch will get you up and running quickly.
• For larger libraries, the Vimeo2Bunny CLI tool handles the migration efficiently and lets you resume progress if needed.

Once your videos are in Bunny Stream, the final step is updating your embeds so your content continues to play on your website or app.

A quick note: this guide and the Vimeo2Bunny tool are intended for migrating content you own or have permission to use. You're responsible for making sure your usage complies with Vimeo's terms.

Additional resources

• Bunny Stream quickstart
• Managing videos in the dashboard
• Uploading videos from a remote URL
• Vimeo2Bunny CLI tool documentation
• Embedding videos

The best developer tools don't ask you to context-switch. They meet you where you already are.

For most developers, that's the terminal. Not because it's retro or minimal, but because it's the one surface that works everywhere—your local machine, your CI pipeline, your AI coding assistant. The commands you type are the same commands your automation runs. A good CLI isn't just a power-user shortcut. It's the most composable interface a platform can offer.

Today we're releasing the bunny.net CLI, a single command-line tool for building and managing your entire bunny.net stack. This first release ships with full Database support, including the interactive SQL shell we introduced a few weeks ago. Support for Edge Scripting, Storage, Magic Containers, and more is coming soon.

The CLI is currently in public preview, and we’re building it in the open. We’d love your feedback, bug reports, and pull requests as we shape what comes next.

Up and running in three commands

Install with npm:

npm install -g @bunny.net/cli

# or
# curl -fsSL https://cli.bunny.net/install.sh | sh

Log in:

This opens your browser, authenticates with your bunny.net account, and saves a profile locally. Note that it currently fetches your API key from your account once signed in.

Confirm it worked:

bunny whoami
Logged in as Jamie Barton (jamie@bunny.net) 🐇

Database management without the dashboard detour

The usual flow after creating a database is to open a dashboard, hunt for the connection string, copy it, paste it somewhere, hope you got the right one.

The CLI replaces all of that with a few commands.

Create a database

Run bunny db create with no arguments and the CLI walks you through it interactively — name, region, options:

Already know what you want? Pass the flags directly:

Both paths produce the same result. Interactive mode is great for exploring. Flags-first is what you'll reach for in scripts, pipelines, or when your AI assistant is driving.

After creation, the CLI offers to link the database to your current directory, generate an auth token, and write credentials to .env so you can go straight from create to querying in the same shell session.

Inspect what you just created:

bunny db show

 Key               Value
 ID                db_01KP8D0MKHB7HWEYYE6VX8CTG7
 Name              my-app-db
 URL               libsql://01KP8D0MGVG0PEWR9SCTND02PH-my-app-db.lite.bunnydb.net/
 Status            Active
 Size              4.1 KB / 1024.0 MB  ░░░░░░░░░░░░░░░░░░░░  0%
 Storage Region    eu-west-1
 Primary Region    London (UK)
 Replica Regions   None

Linking a directory to a database

Most db commands need to know which database you're targeting. Passing an ID every time gets old fast, so the CLI resolves the target database automatically in this order:

• An explicit <database-id> argument
• A .bunny/database.json manifest created by bunny db link
• BUNNY_DATABASE_URL from a .env file (walked up from the current directory)
• An interactive picker if none of the above match

The recommended flow is bunny db link:

This writes a small .bunny/database.json manifest to your project. Every db command run from that directory ( show, shell, studio, usage, tokens create) now knows which database to target. No flags, no env var lookups, no connection strings in your shell history.

Add .bunny/ to your .gitignore. The manifest is a per-developer convenience, not something to commit. Each contributor links their own environment.

If you'd rather drive things from .env (handy when the same BUNNY_DATABASE_URL is already wired into your app), the CLI picks that up automatically. And when you need to run a one-off command against a different database without changing context, pass the ID as an argument:

List, monitor, and clean up

Multi-region replication

Bring data closer to your users with read replicas:

Token management

Generate and revoke database tokens without touching the dashboard:

Drop into the interactive shell

The CLI embeds the same @bunny.net/database-shell we released as a standalone package, so you get the full interactive experience (dot-commands, saved views, output modes, sensitive column masking) with zero extra setup:

No connection strings. No token flags. Your authenticated profile handles it. Just bunny db shell and you're querying.

Run a one-off query without entering the REPL:

A read-only view with bunny db studio

Sometimes you don't want a REPL. You want to click through tables and see what's actually in there. bunny db studio spins up a local server and opens a read-only table viewer in your browser:

It uses the same resolution order as every other db command, so if you've run bunny db link it picks up the right database automatically. A short-lived auth token is generated for the session and discarded when you close it.

Studio is currently experimental and read-only by design, inspect, don't mutate. For schema changes and data edits, reach for bunny db shell.

Raw API access with bunny api

Purpose-built commands cover the most common workflows, but sometimes you need to reach an endpoint that doesn’t have a dedicated command yet, or you just want to poke at the API directly. That’s what bunny api is for.

It’s a raw, authenticated HTTP client for the entire bunny.net API. Pick a method, pass a path, and go:

Every request is automatically authenticated with your current profile, and every response is pretty-printed JSON by default. Pair it with --output json and jq to build quick one-liners:

You can also pipe request bodies from stdin, which makes it easy to compose with other tools or feed in generated payloads:

Think of bunny api as the escape hatch. If the bunny.net API supports it, you can call it from your terminal right now — no wrapper command needed, no dashboard required. It’s especially useful for AI agents that need to access endpoints beyond the built-in commands.

Built like the CLIs you already trust

We followed the Command Line Interface Guidelines closely. The conventions that make git, docker, and kubectl feel predictable - we wanted bunny to feel that way from the start.

Interactive or scriptable - your call. Prompts and spinners are TTY-aware. They show up in your terminal but stay out of the way in CI or when piping output.

Structured output everywhere. Every command supports --output json. Primary output goes to stdout, messages go to stderr, so piping always works cleanly:

Clear, helpful errors. Errors are written in plain language with hints on how to fix them. Exit codes are meaningful: 1 for fixable problems, 2 for internal errors. With --output json, errors come back as structured JSON too.

Respects your environment. The CLI honors NO_COLOR, supports named profiles for switching between accounts, and reads BUNNYNET_API_KEY from your environment when you'd rather skip interactive login:

Your AI agent already knows how to use it

There's a growing question in the developer tools space: do AI agents need custom protocols, or are the CLI tools developers already use enough?

Increasingly, the answer is that CLIs win.

AI models have been trained on billions of lines of terminal interactions. When an agent reaches for a CLI, it's drawing on deeply learned patterns, not adapting to a bespoke integration. Every bunny CLI command that returns structured JSON is a command an AI agent can already use, with zero extra setup.

If you're working with Claude Code, Cursor, or Windsurf, your assistant can already create databases, manage tokens, and query data through the bunny CLI, the same way it uses git or npm today. No MCP server to configure. No schema tokens eating your context window. The CLI you use is the same interface your agent uses.

The CLI comes with agent skills for databases and scripts so your agent knows how to get started. Below we can see Claude Code discovered the tool, skills, and created a database and schema for a new project.

What's coming next

Database support is the starting point. Here's where we're headed.

Edge Scripting

Scaffold a project, deploy serverless functions to the edge, and manage secrets, all from the terminal. Deployment history and rollbacks are on the roadmap too.

Storage

Create buckets, list and sync files, and manage access to S3-compatible storage. The same operations you'd do in the dashboard or with a third-party client, built directly into the CLI with your existing auth.

Magic Containers Apps

If you've ever wanted to go from a Dockerfile to a running, globally distributed application in a single command, that's what we’re adding next.

The bigger picture

Our goal is a workflow where you go from an empty directory to a fully deployed application without leaving the terminal. Database provisioned, edge functions live, storage configured, containers scaled. Whether you're typing the commands or your AI assistant is running them, it's the same tool, the same output, the same interface.

Every bunny.net product, one CLI.

Built in the open, built in TypeScript

The bunny CLI is open source, and we’re developing it in public. This isn’t a finished product we’re handing to developers. It’s an active project we want to build with you.

The bunny.net developer platform is JavaScript-native. Edge Scripts run with Deno and Node.js compatibility. The developers building on bunny.net write JavaScript and TypeScript. By keeping the CLI in the same language, we can share code between the CLI and the scripts developers write. Use exports, generated clients, and utilities written for the CLI inside Edge Scripts.

One language for the CLI, the API client, the config schemas, and the edge runtime means fewer switches and a codebase that any JS developer can read, debug, or contribute to.

If something is broken, open an issue. If you want a feature, tell us. If you want to contribute, pull requests are welcome. The CLI is built with TypeScript, Yargs, and a lot of packages that should feel very familiar.

Get started

Star the repo on GitHub, join us on Discord, and let’s build this together.

APIs sit at the center of almost everything you build today.

They handle authentication, power your frontend, connect your services, and move data between them. Requests are syntactically valid, responses return as expected, and systems stay online. Yet requests still reach your application that don’t belong there.

When something goes wrong, it’s rarely a dramatic outage, but something more subtle. A request your API doesn’t define still slips through, a payload doesn’t match what your application expects, or an endpoint gets called in a way that technically works but was never intended.

The problem is that most security systems are designed to detect what looks malicious. APIs don’t always fail that way. Requests can be completely valid from an HTTP perspective and still violate how your application is supposed to behave.

That gap between what is valid and what is correct is where API abuse happens. We see it constantly at the edge, where traffic looks valid on the surface but doesn’t make sense for the API it’s targeting.

Today, we’re introducing API Guardian, a new layer of Bunny Shield that brings schema-aware protection to your APIs by turning your OpenAPI definition into enforceable validation at the edge.

It builds on everything we’ve shipped with Bunny Shield since launch. WAF, Global Rate Limiting, Bot Detection, and Access Lists control how traffic reaches your application, while Upload Scanning inspects what gets through. API Guardian delivers the final piece we set out to build. It validates requests against what your API is defined to accept and enforces it in real time.

Instead of asking whether a request looks suspicious, API Guardian asks whether it makes sense according to your API contract.

Validate requests at the edge using your schema

API Guardian starts with something you already have: your OpenAPI schema.

When you upload a spec, it becomes an enforceable contract at the edge. Each endpoint is translated into validation rules that run directly inside Bunny Shield’s request security pipeline, so invalid requests can be filtered before they ever reach your origin.

Under the hood, the spec is normalized, schemas are extracted, and references are resolved (internal only) before being compiled into native WAF rules.

API Guardian enforces safety limits at upload time, including a maximum spec size of 2 MB. These limits cover nesting depth, total schema complexity, and regex usage. These guardrails ensure predictable performance and prevent excessively complex schemas from impacting validation at the edge.

Validation covers the full request surface: path parameters, query parameters, headers, cookies, and JSON request bodies (application/json and *+json).

You can log, block, or ignore requests that don’t match, depending on how strictly you want to enforce your API surface.

Validation events that result in logging or blocking are recorded in your Bunny Shield event logs, so you can see what is being flagged and why.

Keep responses aligned with your contract

APIs define both the inputs your system accepts and the outputs it produces.

When requests are malformed or deliberately crafted, responses can behave in unintended ways. Error paths, edge cases, or inconsistent handling can expose fields or data that were never meant to be returned.

API Guardian can validate responses against your schema on a per-endpoint basis. When enabled, responses are checked before they leave your system, helping prevent unexpected or unsafe output from reaching clients.

Enforce authentication at the edge

APIs are harder to protect than traditional web traffic because requests often look valid at the protocol level, even when they’re not meaningful for the application.

Most unwanted traffic still fails basic authentication checks. Bot traffic, scanners, and volumetric attacks rarely include correctly formed credentials, and almost never include valid tokens.

API Guardian enforces authentication requirements defined in your schema before requests reach your origin. It supports API keys (headers, query parameters, or cookies), HTTP authentication (Bearer and Basic), OAuth2, and OpenID Connect.

Requests missing required credentials are rejected immediately at the edge, reducing unnecessary load and filtering out a large portion of low-effort attack traffic.

For Bearer tokens defined with bearerFormat: jwt, API Guardian performs basic checks such as validating structure and expiration. This allows you to filter out malformed or clearly invalid tokens before forwarding the request, while leaving full authentication and authorization to your application.

For OpenID Connect schemes that use public-key signing, API Guardian can also verify token signatures at the edge. It retrieves the provider’s configuration, resolves the advertised JWKS, and keeps keys updated as they rotate.

Tokens are validated against the expected issuer and signing algorithm before being forwarded. Invalid, expired, unsigned, or tampered tokens are rejected at the edge, ensuring only properly signed requests reach your origin.

Apply rate limits where they matter

Not every endpoint behaves the same way, so protection shouldn’t be uniform.

Some routes are public and inexpensive. Others are sensitive or resource-intensive. Applying a single rate limit across an entire API rarely reflects how real systems behave.

API Guardian allows you to define rate limits per endpoint, aligned directly with your API structure.

Path templates such as /users/{id} work out of the box, so you don’t need to define rules for every variation. Rate limits are applied at the template level, meaning all variations of a route share the same counter by default.

You can define limits globally per endpoint or per IP address, with time windows ranging from one second to one hour. Versioned endpoints such as /v1 and /v2 are treated independently, allowing you to tune protection as your API evolves.

Combine structure with targeted protection

Schema validation ensures requests are structurally correct, based on your API schema. Some behaviors still fall outside structure alone.

API Guardian allows you to apply targeted injection detection to specific parameters. You can choose which query, path, header, or cookie values should be inspected for patterns like XSS or SQL injection.

This combines schema validation with traditional WAF protection, giving you precise control over where deeper inspection is applied.

Built into the edge, not added on top

API Guardian runs directly within the bunny.net edge as part of the existing request pipeline.

Validation happens in the same path as the rest of Bunny Shield, so requests don’t take an extra hop. This keeps latency low while filtering invalid traffic before it reaches your origin, acting as a first layer of protection for APIs that would otherwise need to handle this traffic themselves.

Availability and limits

API Guardian is currently in public preview on Bunny Shield Advanced plans and above.

We designed a simple, tiered structure to match the needs of different teams: Advanced and Business plans include clear endpoint limits, while Enterprise offers full customization. This keeps things straightforward and focused.

Endpoint limits scale by plan:

• Advanced: up to 10 endpoints
• Business: up to 50 endpoints
• Enterprise: customizable based on your needs

We set these limits intentionally. Rather than encouraging blanket protection across every single endpoint (which often leads to noise and maintenance overhead), we want to help teams focus on securing their highest-traffic, most sensitive, and business-critical endpoints.

API Guardian currently supports OpenAPI 3.0.x specifications.

You can re-upload and evolve your schema at any time. Existing endpoints retain their configuration, while removed endpoints are automatically cleaned up.

What’s next for Bunny Shield

API Guardian completes the initial vision for Bunny Shield, bringing structure and intent into how traffic is evaluated at the edge.

From here, the focus shifts to refining and expanding what’s already there. That includes improving existing protections, advancing bot detection to better handle modern traffic patterns, and continuing to evolve the platform based on real-world usage and feedback.

Because bunny.net sits at the edge, our global network acts as your first and strongest line of defense. We designed Bunny Shield to secure all your workloads, from website traffic and APIs to AI models, stopping attacks before they ever hit your servers. We have an exciting roadmap ahead.

Start protecting your API contract

Getting started is straightforward.

Upload your OpenAPI schema, refine validation, and apply authentication and rate limits per endpoint.

Start in log mode, observe what your API actually receives, then switch to blocking once you're confident.

Security shouldn’t require complex rules or constant tuning. With API Guardian, your API contract becomes the source of truth.

Log in or sign up to upload your schema and start protecting your API.

When integrating Bunny Stream into an Expo app, the easiest way to get started is to use Bunny Player.

Drop it into a WebView and you get adaptive playback, built-in analytics, captions, chapters, and branding out of the box. It is quick to set up, and for many apps, that is exactly what you want.

If your Expo app needs Picture-in-Picture, background audio, lock screen controls, or tighter playback control, the limitation is no longer the player; it is WebView. Unfortunately, the mobile OS will not float it for PiP or keep it alive like a native media session, and it will not treat it like a real platform media player.

That is where expo-video becomes useful.

By playing the videos HLS URLs directly through the native video stack, AVPlayer on iOS and ExoPlayer on Android, you can keep your Bunny Stream as your video backend while unlocking the native playback features a WebView cannot.

In this guide, we will build a simple but real Expo app that does exactly that… fetch your videos from Bunny Stream library, render a video list, and open a detail screen that plays videos natively with chapters, captions, and playback progress tracking.

Before you start

You’ll need:

• An Expo project (SDK 52+) with Expo Router and Expo SDK 52 or later
• A Bunny Stream video library with at least one uploaded and processed video
• Your Pull Zone hostname, vz-abc123-456.b-cdn.net, found under Stream > API in the bunny.net dashboard
• Your Bunny Stream API key, used only in the edge script

Setting up

Install expo-video and expo-image:

To enable Picture-in-Picture and background playback, add the expo-video config plugin to app.json:

expo-video requires a development build. It won't work in Expo Go. Run npx expo run:ios or npx expo run:android, or create a build with EAS.

Next, copy .env and fill in your Bunny Stream credentials:

Add your Bunny Stream values:

Your API key is a secret. In a production app, proxy these calls through your backend or an API route so the key never reaches the client.

Then run:

How Bunny Stream URLs work

Once a video has finished processing, Bunny Stream exposes it through predictable URLs built from your Pull Zone hostname and the video GUID.

The most important URL here is the HLS playlist. That is what expo-video plays. Because it is adaptive, the player can automatically choose the best quality for the current network conditions.

Using an edge script for secure API access

In this example, we do not call the Bunny Stream API directly from the app to fetch videos that we want to list in our app. Instead, we route all requests through a Bunny Edge Script.

Bunny Stream’s authentication model is designed around this pattern. The client requests access, your backend (or edge script) decides if it’s allowed, and returns the data needed for playback.

Example edge script

Below is an example of how you could create an edge script that proxies Bunny Stream:

Talking to the Bunny Stream API

Now your Expo app talks to your edge script instead of bunny.net directly.

Root layout

We only need two screens: a list screen and a detail screen.

Building the video list

The home screen fetches your Bunny Stream library and displays a scrollable list of videos. Each row renders a thumbnail, a title, and a small metadata line. Tapping a card opens the native player screen for that video.

This keeps the list simple, but it already feels like a real app: fast thumbnails, clean navigation, and no custom backend needed beyond the Bunny Stream API.

Playing a video natively

Now for the part that makes this approach worth using.

On the detail screen, we fetch the video metadata from Bunny Stream and hand the HLS URL to expo-video. Because playback is native, the player can integrate with the OS in ways a WebView cannot.

We also use useWindowDimensions for explicit sizing, useEvent for reactive playback state, and useEventListener to track progress while the video is playing.

This is the tradeoff in practice.

You lose some of the convenience Bunny Player gives you automatically, but you gain real native playback behavior and full control over the experience.

Adding chapter navigation

Bunny Stream returns chapter data as an array of objects with title, start, and end values in seconds. Because expo-video exposes a writable currentTime, chapter jumping is easy to implement.

The same pattern also works for Bunny Stream moments, using moment.timestamp instead of chapter.start.

Wiring up captions

Bunny Stream includes subtitle tracks in the HLS manifest. After the player source loads, expo-video exposes availableSubtitleTracks and lets you set subtitleTrack directly.

That means you can build a simple caption selector with native track switching and no WebView bridge in the middle.

Project structure

Here is the final structure for the example app:

It is a small project, but it covers the pieces most real apps need: browse videos, open a detail page, play natively, expose captions, jump between chapters, and track playback progress.

You can find the full source code of the demo app on GitHub.

Choosing the right playback approach

bunny.net gives you a few different ways to play Bunny Stream videos, and the right choice depends on how much control you need.

Bunny Player is still the fastest path. If you want to ship quickly and do not need deep native media integration, embedding it in a WebView lets you drop in a complete player without building controls or playback logic.

Bunny Stream iOS SDK and Bunny Stream Android SDK are the native-first option. They include built-in analytics, dashboard-controlled branding, TUS upload support, and camera capture, but they are designed for Swift and Kotlin apps rather than Expo’s managed workflow.

expo-video + Bunny Stream API sits in the middle. You keep Expo compatibility, gain access to native playback behavior, and build your own UI around Bunny Stream’s HLS playback and metadata APIs.

Which one should you use?

If all you need is reliable video playback inside an Expo app, start with Bunny Player.

It is faster to integrate, easier to maintain, and for many use cases, it is more than enough.

But when your app needs to behave like a real native media app, with Picture-in-Picture, background playback, lock screen controls, and tighter control over the playback experience, native playback is the better fit.

That is where expo-video and Bunny Stream work well together.

Bunny Stream gives you the delivery, metadata, captions, chapters, and adaptive HLS playback. expo-video gives you native player access inside Expo. Together, they let you build a video experience that feels fully at home on the platform instead of living inside a WebView.

There was a time when identifying traffic on the internet was relatively straightforward.

An IP address and a User-Agent were usually enough to make a decision. If something looked wrong, you blocked it. Otherwise, you let it through.

That approach no longer holds up.

Today, a single automated client can appear as thousands of different users, rotating IPs, mutating headers, and mimicking real browsers with surprising accuracy. Botnets operate at scale across large networks, while headless frameworks and AI-driven agents make it even easier to blend in.

At that point, what a client claims to be is no longer something you can rely on. You need a signal that is much harder to fake.

Looking at what clients can’t easily fake

Every HTTPS connection starts with a TLS handshake. Before any request is sent, the client introduces itself through a ClientHello message that reflects its underlying TLS stack, including supported versions, cipher suites, extensions, and protocol preferences.

Unlike headers, which are trivially manipulated, the TLS handshake reflects the client’s underlying implementation and is far harder to replicate.

JA3 was one of the first widely adopted approaches here. It takes values from the TLS handshake and hashes them into a fingerprint, giving you a way to group similar clients together.

For a while, it worked well. However, it relies heavily on the exact ordering of fields in the handshake, which introduces a key limitation.

Modern browsers and privacy-focused clients often shuffle TLS extensions specifically to avoid being tracked. From a functionality point of view, nothing has changed, but to JA3 it looks like a completely different client.

The same browser can produce multiple fingerprints, making it harder to reason about. At the same time, attackers can exploit this by slightly tweaking the ordering or configuration to avoid matching known fingerprints.

JA4 addresses this directly by removing those inconsistencies.

Instead of hashing the raw handshake as-is, it normalizes the data first. It focuses on the parts that actually describe the client and removes noise like ordering differences.

The result is a fingerprint that stays consistent for the same client, even with those small variations, and is much harder to manipulate without actually changing the underlying TLS stack.

A more stable way to fingerprint clients

A JA4 fingerprint is a compact string like this:

At first glance it looks cryptic, but it is not random.

It is made up of multiple parts, each describing a different aspect of the TLS handshake.

Once you break it down, it becomes much easier to reason about. You are not just looking at a hash; you are looking at a structured summary of how that client speaks TLS.

That structure is what makes it practical.

Instead of treating the fingerprint as a single opaque value, you can match on parts of it, group similar clients together, or spot outliers that do not fit expected patterns.

And because those parts are derived from the client’s actual implementation, they tend to stay stable even when everything around them changes.

JA4 is not meant to uniquely identify individual users. It is a signal that helps group similar clients and works best when combined with other data like IP addresses, request headers, and behavior.

JA4, built into bunny.net

We've incorporated JA4 into our Layer 7 DDoS mitigation and bot detection systems to group related activity and make more accurate decisions without relying on easily spoofed signals.

And since JA4 fingerprinting is now computed automatically for every HTTPS request passing through bunny.net, each request is assigned a fingerprint at the edge and forwarded to your origin via the CDN-JA4 header.

That gives you direct access to the same signal we use internally, with full details available in the JA4 fingerprinting documentation.

Because the fingerprint reflects the client’s actual TLS implementation, it stays consistent even when other identifiers change. That makes it particularly useful for tracking automated traffic that rotates IPs or mutates headers between requests.

For example, traffic coming from hundreds or thousands of different IP addresses may still share the same JA4 fingerprint, letting you group and act on it as a single source.

Putting JA4 to work with Bunny Shield

JA4 is most useful when you can act on it directly.

We have integrated JA4 deeply into Bunny Shield so you can use it to improve your security posture at the edge.

You can create rate limits based on JA4, or combine it with IP addresses for tighter control. You can write custom WAF rules that match a full fingerprint or even specific parts of it. You can also build access lists around known JA4 identities to block, allow, or challenge specific clients.

This is especially useful when dealing with distributed traffic. Even if requests are spread across many IPs, they often still share the same underlying fingerprint. Instead of chasing individual requests, you can act on the source implementation itself.

The end result is simple. You are no longer limited to what a client claims to be. You can make decisions based on how it is actually built.

A better signal for a noisier internet

Relying on IPs and headers is becoming less effective as traffic becomes more distributed and easier to disguise.

JA4 gives you a more stable way to understand what is behind each request. Instead of chasing constantly changing surface-level signals, you can start grouping and acting on traffic based on how it is implemented.

It’s already available on every request passing through bunny.net and fully integrated into Bunny Shield, so you can put it to use immediately.

If you want a clearer view of your traffic or tighter control over how it behaves, this is a good place to start.

Log in to explore JA4, or sign up to get started in minutes.

Edge Rules allow you to define logic that runs directly on bunny.net’s edge servers before a request reaches your origin. They can modify caching behavior, redirect traffic, route requests to different origins, apply security actions, and much more based on conditions like the request URL, headers, query string, or hostname.

A common part of writing Edge Rules is matching requests based on these values. In many cases, a simple string or wildcard match is enough, but modern applications often generate URLs that follow predictable patterns rather than exact values. Streaming manifests, versioned build assets, and dynamically generated API routes are all good examples.

To make these scenarios easier to handle, we’ve added pattern matching support to Edge Rule conditions.

Using pattern matching in Edge Rules

Pattern matching can be used in any Edge Rule condition that evaluates a value, such as the request URL, headers, or query string.

To indicate that a condition should use pattern matching, write the value using the following format:

The pattern: prefix tells the Edge Rule engine to evaluate the value using Lua’s pattern matching instead of a normal string comparison. Lua patterns are a lightweight pattern-matching system similar to regular expressions, but intentionally simpler and faster.

The pattern itself should be wrapped with ^ and $ so the entire value is matched. If the prefix is not present, the condition behaves as a normal string comparison.

For example:

This pattern matches URLs such as:

Internally, the match is evaluated using Lua’s string.find function, which performs pattern matching without requiring a full regular expression engine while still supporting useful pattern features such as character classes, repetition operators, and escaped characters.

If you're already familiar with Lua patterns, everything behaves exactly as you would expect. If not, the examples below should give you a good feel for how they can be used in practice.

Pattern matching in action

With pattern matching available, many common CDN scenarios become easier to express with a single condition.

Below are a few examples where this simplifies Edge Rules while adding a great deal of flexibility.

Matching streaming manifests

Streaming platforms often generate manifest files that include region identifiers, channel names, or session information in the filename, such as:

A single condition can match these requests and, for example, apply custom cache control:

Targeting versioned assets

Many build systems generate static assets with version numbers in the filename.

A single condition can match them and apply actions such as rate limiting:

Blocking suspicious requests

Pattern matching is also useful for security rules.

For example, you might want to block requests targeting administrative PHP endpoints when the expected session cookie is missing:

Pattern matching cheat sheet

Format: Condition values must start with pattern:^ and end with $ (e.g., pattern:^...$). Edge Rules evaluate the expression with Lua’s string.find.

Anchors: Always use ^ and $ to match the entire value.

Common classes:

• %d digit
• %a letter
• %w alnum + underscore
• . any character
• [abc] match any listed character
• [^abc] match any character not listed

Repeaters:

• + = 1 or more
• * = 0 or more (greedy)
• - = 0 or more (non-greedy)

Escape: Use % to escape special chars, for example %. for a literal dot and %- for a hyphen.

Limitations: No | alternation, no lookaheads/lookbehinds, and no full PCRE. Patterns are intentionally small and fast.

Full reference and examples: https://docs.bunny.net/cdn/edge-rules/pattern-matching

Why Lua pattern matching?

Lua patterns provide a good balance between expressive matching and predictable performance.

Unlike full regular expressions, Lua patterns are intentionally simpler and implemented directly in Lua’s standard library. This avoids the overhead of a full regex engine while still supporting the most commonly needed matching features such as character classes, repetition operators, and captures.

For edge environments where rules are evaluated on every request, this simplicity is important. Pattern evaluation remains fast, deterministic, and lightweight, even under very high request volumes across the network.

Using Lua’s native pattern matching also keeps the implementation compact and reliable across all edge nodes while still giving developers enough flexibility to match structured URLs, headers, and request values in practical scenarios.

Try pattern matching in Edge Rules

Pattern matching is now available in Edge Rule conditions and can be used anywhere a request value is evaluated, including URLs, headers, cookies, and query strings.

This makes it possible to express much more precise request logic without creating multiple rules or pushing filtering back to the origin. In many cases, complex matching can now be handled with a single condition running directly at the edge.

If you're already using Edge Rules, try replacing some of your existing conditions with pattern matching and see how much simpler your rules can become.

If you haven't explored Edge Rules yet, this is a great place to start.

Log in or sign up for a bunny.net account to create your first pattern matching Edge Rule.

When we started building Bunny Database, we needed a shell-like experience. Naturally, we reached for libsql-shell-go, the official Go-based shell from the libSQL project. It's a solid tool, and it served us well in early development.

But as we began building the upcoming bunny.net CLI in TypeScript, maintaining a separate Go binary for just the shell felt like carrying two toolchains for one job. We wanted a shell that could be embedded directly into our CLI, share the same authentication flow, and ship as a single binary. So we rewrote it from scratch in TypeScript.

The result is @bunny.net/database-shell — a standalone, interactive SQL shell for libSQL databases that also powers bunny db shell inside the upcoming bunny.net CLI.

The interactive Bunny Database shell is currently in public preview. While fully functional, we recommend exercising caution with production workloads as we continue refining the experience.

Connect and query

You will need Node.js 18 or later installed and an existing database to continue. If you don't have one, create one.

Navigate to Dashboard > Edge Platform > Database > [Select Database] > Access to find your database URL and generate an access token.

Once you’re ready, execute the npx command to connect to your database:

You get a readline-powered REPL with multi-line SQL support, persistent command history, and query timing:

Dot-commands for database introspection

If you've used SQLite or libSQL’s shell, these will feel familiar. Dot-commands give you quick access to your schema without writing SELECT queries against sqlite_master:

• .tables list all tables
• .schema [table] shows CREATE statements
• .describe table column names, types, nullability, defaults, and primary keys
• .indexes [table] list indexes with their target columns
• .fk table show foreign key relationships
• .er display a text-based entity-relationship overview of your entire schema, which is useful for getting to grips in an unfamiliar database without jumping through .describe calls

For data operations:

• .count table row count
• .size table storage size estimate
• .dump [table] export as SQL INSERT statements
• .read file.sql execute a SQL file

Bunny Database charges against a read quota based on rows scanned. Commands that scan full tables (.count, .size, .dump) warn you before running and ask for confirmation. So an accidental query on a large table doesn’t burn through your quota unexpectedly.

Saved views

Dot-commands are great for introspection, but some queries you run over and over. Saved views let you name and persist any query so you can re-run it without retyping.

Next session, next machine, same query:

The following commands cover the full lifecycle:

• .save NAME saves the last executed query as a named view
• .view NAME executes a saved view
• .views lists all saved views for this database
• .unsave NAME deletes a saved view

Names follow the same rules as filenames: alphanumeric, hyphens, and underscores only. No dots, slashes, or spaces.

Personal and shared views

Views are stored as plain .sql files, scoped per database. They live in your global config directory ~/.config/bunny/views/<database-id>/, personal to you and available across every project.

You can override the storage location with the --views-dir flag to point to any directory, for example, a folder inside your repo. Because views are just .sql files, you can commit them and share them with your team: common reporting queries, debugging helpers, and onboarding examples. Everyone gets the same set.

Five output modes

Switch formats on the fly with .mode:

• default clean, borderless columns
• table bordered ASCII table
• json array of objects, ready for piping to jq
• csv proper RFC-compliant CSV with escaped fields
• markdown GitHub-flavored pipe tables, useful for pasting into issues or docs

You can also set the mode at launch with --mode json for scripting.

Automatic sensitive column masking

Most of the time, you don’t actually need to see the raw value of a password_hash or api_key column; you just need to know it’s there. The shell masks sensitive column names automatically, keeping raw secrets out of your terminal, your scrollback buffer, and anything you pipe or paste.

Detected patterns include password, secret, api_key, auth_token, ssn, and similar names. Emails get a partial mask a****e@example.com; secrets are fully redacted ********.

This works across all output modes, not just the interactive terminal. If you're exporting to CSV or JSON, masked columns stay masked.

Toggle it off with .unmask when you actually need the raw values, or launch with --unmask.

Non-interactive mode

For scripting or quick lookups, skip the REPL entirely:

File execution splits on semicolons (properly handling quoted strings and comments) and stops on the first error.

Thank you libsql-shell-go

We want to acknowledge the libsql-shell-go project. It set the standard for what a libSQL shell should feel like: the dot-commands, the output modes, and the overall interaction model.

We released an early look at a wrapper on top of libsql-shell-go, but it was clear that we could do more to improve the experience for Bunny Database users. Our implementation follows the same spirit while adapting it to the TypeScript ecosystem and the bunny.net developer experience.

Why rewrite in TypeScript?

Three reasons:

• Single dependency chain — The upcoming bunny.net CLI is TypeScript. Embedding the shell directly means no sidecar binary, no version drift, and no separate release pipeline.
• Shared auth and config — When you run bunny db shell, the CLI resolves your database credentials from your project's .env, your authenticated profile, or explicit flags. The same way every other upcoming bunny db command works. A separate Go binary can't participate in that flow without shelling out or duplicating logic.
• Standalone when you want it — Despite being built for the bunny.net CLI, bsql is published as its own package (@bunny.net/database-shell) with zero CLI dependencies. You can use it as a library.

Get started

Install the bunny.net CLI and connect to your first database:

Or use the database-shell directly via npx:

Make sure to join us on Discord to share your experience and any feedback.

What's next

A platform is only as good as its developer experience, and that experience increasingly lives in the terminal. Our goal with the bunny.net CLI is to give you a single tool for everything on the bunny.net stack. No tab-switching, no copy-pasting tokens between dashboards. The interactive Database shell is the first piece of that vision.

Over the coming weeks, we’ll be rolling out commands for Database CRUD, Magic Containers, Edge Scripting, and Storage. The goal is a workflow where you can go from an empty project to a deployed, queryable application without ever leaving your terminal.

We have some "ear-resistible" news to share! bunny.net and UpCloud are officially teaming up to offer a unified, high-performance, and digitally sovereign cloud-to-edge ecosystem.

In today’s fast-paced world, you shouldn't have to choose between innovation and privacy. This strategic partnership enables organizations across both public and private sectors to access a European sovereign cloud and edge infrastructure through a seamless, integrated experience.

Together with UpCloud, we're providing you with a powerful solution to deploy, scale, protect, and deliver applications with total confidence.

Who is UpCloud?

Sometimes partnerships just make sense. That is exactly what we saw in the team at UpCloud, a reflection of what we hold sacred at bunny.net.

For those new to our Finnish partner, they are a performance-obsessed European cloud services provider renowned for their commitment to transparency, cloud sovereignty, and delivering amazing developer experiences to over 10 thousand developers and enterprises alike.

What this partnership unlocks

This collaboration is about more than just speed and security. It's about providing a European single-point-of-purchase environment that maintains data sovereignty at its core. Whether you're an independent developer or part of a large enterprise, this partnership focuses on how you can grow without boundaries.

• Digital sovereignty as standard: Pair a high-performing European cloud platform with a global edge network, built and operated in the EU and available everywhere.
• Unified performance: Accelerate and secure your UpCloud-hosted websites and applications for a worldwide audience instantly, using UpCloud’s enterprise-grade infrastructure with bunny.net’s 250 Tbps+ network capacity.
• Seamless integration: Manage your stack efficiently with Bunny CDN and Shield integrated directly within the UpCloud Hub and API.

Coming to a burrow near you in summer 2026

While our teams are already busy working to bring these services to your fingertips, please note that the integrated solution is currently in development and will be available starting in summer 2026. We're extremely excited to offer a massive hop forward for businesses looking to stay secure without compromising end-user data sovereignty.

Join the mission for a better internet

bunny.net is a European company on a mission to make the internet hop faster! Headquartered in Slovenia, we power millions of websites worldwide. By joining forces with Finland-based UpCloud, we’re doubling down on our commitment to building better, more secure internet experiences for everyone.

Don’t let compliance hurdles or privacy concerns limit your global reach. If you’d like to discover more about how our joint solution can help your business hop ahead of the competition, reach out to hello@upcloud.com to learn more!

When you’re building video capabilities, the player component is the part of your video stack that’s experienced directly by your users.

Today, we’re glad to help improve their experience with the new Bunny Stream video player becoming generally available.

The new player offers:

• Improved user interface
• Faster, smoother playback
• Consistency across all major browsers
• Accessibility improvements

In this post, we’ll cover:

• What this release means for new and existing video libraries
• How to upgrade to the new player
• What’s under the hood and where the ecosystem is heading

Let’s get into it.

How the new player rolls out

• New libraries use the new player by default. New video libraries created in Bunny Stream will automatically use the new player. If needed, you can switch a library back to the legacy player after it’s created via a toggle in the dashboard or using the 'update video library' API endpoint.
• Existing libraries stay on the legacy player until you migrate them. Your existing libraries and embed URLs will continue to use the legacy player until you choose to migrate them to the new one.

From this point onward, new capabilities and features added to Bunny Stream will only be supported by the new player. At the same time, we don’t currently have plans to sunset the legacy player, so you won’t be forced to migrate. Your current embed URLs will continue to work.

That said, migration is straightforward and your users will surely feel the difference, so we recommend you take one of the paths described below.

How to upgrade to the new player

If you’re not using custom CSS or JavaScript

• Log in to bunny.net
• Navigate to Stream from the sidebar
• Select the Video Library you’d like to use the new player on
• Open Player Settings
• Toggle off Enable Legacy Player
• Update your embed URLs to use the new player endpoint: replace
  iframe.mediadelivery.net/embed/ with player.mediadelivery.net/embed/

Alternatively, you can also upgrade your video library to the new player using the API by setting "PlayerVersion": 2, like in the following example:

Note: Updating the video library via the dashboard or API does not automatically update your existing embed URLs. To use the new player endpoint, update your embed URLs to player.mediadelivery.net/embed/ instead of iframe.mediadelivery.net/embed/

If you’re using custom CSS or JavaScript

If your player uses custom CSS or JavaScript via the Custom HTML head feature, you’ll need to migrate the <head> markup to work with the new player.

The new player uses a different structure and control elements, meaning CSS selectors or scripts targeting the legacy player may no longer work as expected.

We’ve prepared a migration guide that explains how to update common customizations and map legacy selectors to the new player components.

What you’ll need to do:

• Search your custom snippet for plyr, .plyr__, and data-plyr
• Replace selectors using the mapping table in the migration guide
• Search for jQuery usage ($(, jQuery) and rewrite to vanilla JavaScript
• Verify on desktop and mobile, especially controls and captions

For detailed instructions and selector mappings, follow the complete migration guide here.

What’s under the hood and where the ecosystem is heading

The new Bunny Stream player is built using Web Components and the open-source Media Chrome project.

Media Chrome provides a set of composable HTML elements that represent common media controls. Elements such as media-controller, media-play-button, and media-time-range can be combined to build a player interface directly in the DOM.

Playback itself still relies on the native <video> element. Media Chrome components are layered on top of it to provide the user interface.

This HTML-first approach offers a few advantages:

• More flexible customization using standard HTML and CSS
• Improved accessibility through semantic control elements
• More predictable control structure for styling and scripting

This direction also reflects a broader shift happening across the web video ecosystem, with player architectures increasingly moving toward composable, HTML-first approaches.

By building the Bunny Stream player on Media Chrome, we’re aligning with this evolution while keeping the player flexible and easier to extend over time.

Try the new Bunny Stream player

The new Bunny Stream player is now available to everyone and will be used by default for all newly created video libraries.

If you’re already using Bunny Stream, upgrading existing libraries is straightforward. Most libraries can switch to the new player with a single toggle or API call, while customized players can be migrated by following the guide linked above.

We recommend upgrading when convenient, so you can take advantage of the improvements in the new player and upcoming features.

References

• Stream player docs
• API reference
• Custom head HTML migration guide