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

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

Here are the three startups joining HopStart cohort #3.

1st place: Screenity

Founder: Alyssa X

Year founded: 2025

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

Credits received: $50,000 for one year

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

2nd place: Ciphera

Founder: Usman Baig

Year founded: 2024

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

Credits received: $25,000 for one year

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

3rd place: orkestr

Founder: Stefan Iancu

Year founded: 2026

URL: https://orkestr.eu/

Credits received: $10,000 for one year

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

Applying for cohort #4

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

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

We'll announce cohort #4 in October.

Looking forward to seeing what you’re building!

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

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

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

Affected versions

WordPress has released fixes in the following versions:

• 7.0.2
• 6.9.5
• 6.8.6
• 7.1 Beta 2

Versions earlier than 6.8 are not affected.

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

Understanding the vulnerabilities

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

CVE-2026-60137 - SQL Injection

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

Severity: High

CVE-2026-63030 - Unauthenticated Remote Code Execution

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

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

Severity: Critical

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

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

How Bunny Shield protects your site

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

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

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

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

Protection while you update

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

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

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

What you should do

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

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

Staying ahead of new attack techniques

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

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

Protect your sites with Bunny Shield

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

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

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

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

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

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

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

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

We have been building rooms like this for a long time

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

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

Meet Bunny Sandbox

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

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

Spin one up from your terminal

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

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

# Log in
bunny login

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

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

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

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

Now put it to work.

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

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

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

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

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

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

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

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

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

You can drive it from code too

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

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

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

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

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

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

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

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

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

Isolation you do not have to think about

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

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

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

From idea to public URL without the detour

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

Pay for the room while you are in it

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

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

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

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

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

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

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

We are just getting started

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

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

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

Try it

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

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

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

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

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

Today, Bunny DNS joins it.

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

A two-minute tour

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

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

Now update your nameservers at <your registrar> to:

 kiki.bunny.net
 coco.bunny.net

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

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

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

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

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

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

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

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

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

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

DNS was always meant to be automated

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

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

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

Here are the DNS commands the CLI now supports.

Zones

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

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

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

Link a directory to a zone

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

bunny dns zones link example.com

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

Records

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

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

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

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

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

Migrate a zone with BIND files

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

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

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

DNSSEC and zone settings

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

bunny dns zones dnssec enable example.com

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

Scriptable DNS from the CLI

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

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

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

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

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

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

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

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

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

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

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

Works with your agent and CI

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

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

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

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

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

One CLI for the platform

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

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

Coming up next are Magic Containers and Storage.

Get started:

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

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

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

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

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

Hop into the 2026 Edge Security Report →

What you'll learn

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

The report covers:

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

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

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

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

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

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

From internal engine to 200 billion customer queries per month

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

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

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

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

Why DNS shouldn't cost extra

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

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

So, we’ve eliminated DNS query fees entirely.

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

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

The entry point for everything else

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

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

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

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

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

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

IPv6 is no longer optional

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

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

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

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

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

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

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

We’ve modernized record types

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

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

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

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

Helping you build faster

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Image transformations with Bunny Optimizer

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

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

Common parameters:

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

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

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

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

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

Not all bots are the bad guys

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

Here's the roughly sorted landscape.

Search engine crawlers

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

AI search bots

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

AI training crawlers

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

Agentic and assistant bots

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

Marketing intelligence crawlers

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

Social / link-preview bots

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

Commercial / vertical scrapers

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

Research / archival crawlers

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

Monitoring bots

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

Malicious bots

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

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

How to diagnose it from your logs

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

Growth (or lack of) in analytics sessions and conversions

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

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

Request rate per client

Find out who's making the most requests:

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

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

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

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

The asset-loading signature

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

Pull everything requested by a suspect IP:

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

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

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

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

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

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

No JavaScript execution

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

Count the client-side instrumentation hits from your suspect:

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

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

Sequential / systematic URL patterns

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

Look at a suspect's requests in time order:

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

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

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

A real visitor's path looks nothing like that:

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

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

User-agent distribution

Now look at what everything is claiming to be:

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

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

Reading down the list:

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

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

Verifying identity with a DNS lookup

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

For a request claiming to be Googlebot:

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

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

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

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

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

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

Published IP ranges

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

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

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

ASN lookup

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

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

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

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

Geographic and timing anomalies

Requests by country:

  142883  SG
   38201  GB
   12009  US
    8841  DE

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

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

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

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

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

The issue with this approach

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

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

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

Today, Edge Scripting lands in the CLI.

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

A two-minute tour

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

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

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

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

Scaffold a project from a template

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

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

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

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

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

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

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

Run it locally

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

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

cd my-edge-app
npm install
npm run dev

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

Link a directory to a script

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

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

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

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

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

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

Build and deploy

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

npm run build
bunny scripts deploy dist/index.js

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

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

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

Put it on your own domain

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

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

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

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

Manage environment variables and secrets

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

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

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

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

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

Deployment history

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

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

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

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

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

See how it's doing

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

bunny scripts stats

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

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

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

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

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

Works with your agent and CI

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

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

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

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

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

What's next

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

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

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

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

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

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

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

Shipped on bunny.net

kaku.so

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

yaan.ch

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

Convex self-hosted on Magic Containers

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

Nitro.film

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

Kraken

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

The Imago Platform

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

Moving to bunny.net

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

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

Shipped for bunny.net

CDN

A community-built API client I recently came across:

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

Stream and video

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

Storage

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

Shield and security

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

Working with AI agents

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

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

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

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

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

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

This is the problem we set out to solve.

The problem: control loops introduce latency

Magic Containers is built around a control loop architecture.

Each component continuously reconciles desired state → actual state:

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

Each of these components runs independently in a loop:

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

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

But it comes with a tradeoff.

Latency compounds across loops.

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

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

Now chain multiple components together:

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

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

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

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

What we considered (and rejected)

We explored several approaches before settling on the final solution.

1. Decreasing loop intervals

Reducing intervals from ~10 seconds to sub-second.

Why we rejected it:

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

2. Removing loops entirely

Moving to a purely event-driven system.

Why we rejected it:

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

3. Hybrid model (chosen)

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

The solution: event-driven acceleration

We introduced a message broker with event queues between components.

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

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

Before: loop-driven propagation

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

After: event-accelerated flow

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

How It Works

Each component now listens for specific events and reacts instantly.

Example event

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

Provisioner

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

Controller Manager

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

Scheduler

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

Local Container Manager (LCM)

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

Important: loops still exist

The control loops were not removed.

They still run continuously to:

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

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

This hybrid design gives us:

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

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

From control plane to user experience

Reducing backend latency is only part of the story.

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

In practice, this meant:

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

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

Real-time updates via WebSockets

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

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

Client → opens WebSocket connection
→ subscribes to application events

Whenever something changes:

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

What this changes

This removes the final layer of perceived latency.

Before

• Backend finishes → UI polls → user sees update later

After

• Backend finishes → event emitted → UI updates instantly

Result

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

Why this matters

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

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

• System speed
• User perception

The impact

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

Before vs. after

What changed technically

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

Why this matters

This fundamentally changes how Magic Containers behaves.

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

Tradeoffs and challenges

1. Event ordering

Ensuring correct sequencing across distributed components.

Solution:

• Idempotent handlers

2. Reliability

Events can fail or be delayed.

Solution:

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

3. Observability

Async systems are harder to debug.

Solution:

• Correlation IDs
• Event tracing across components

What’s next

We’re already exploring:

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

Final thoughts

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

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

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

European infrastructure teams are facing a massive challenge.

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

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

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

Uncompromising performance under European law

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

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

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

Engineering edge security and scale

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

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

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

Building an independent digital future

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

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

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.