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

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

That approach no longer holds up.

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

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

Looking at what clients can’t easily fake

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

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

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

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

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

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

JA4 addresses this directly by removing those inconsistencies.

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

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

A more stable way to fingerprint clients

A JA4 fingerprint is a compact string like this:

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

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

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

That structure is what makes it practical.

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

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

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

JA4, built into bunny.net

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

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

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

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

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

Putting JA4 to work with Bunny Shield

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

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

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

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

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

A better signal for a noisier internet

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

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

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

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

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

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

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

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

Using pattern matching in Edge Rules

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

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

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

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

For example:

This pattern matches URLs such as:

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

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

Pattern matching in action

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

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

Matching streaming manifests

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

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

Targeting versioned assets

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

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

Blocking suspicious requests

Pattern matching is also useful for security rules.

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

Pattern matching cheat sheet

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

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

Common classes:

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

Repeaters:

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

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

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

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

Why Lua pattern matching?

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

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

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

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

Try pattern matching in Edge Rules

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

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

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

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

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

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

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

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

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

Connect and query

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

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

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

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

Dot-commands for database introspection

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

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

For data operations:

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

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

Saved views

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

Next session, next machine, same query:

The following commands cover the full lifecycle:

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

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

Personal and shared views

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

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

Five output modes

Switch formats on the fly with .mode:

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

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

Automatic sensitive column masking

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

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

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

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

Non-interactive mode

For scripting or quick lookups, skip the REPL entirely:

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

Thank you libsql-shell-go

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

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

Why rewrite in TypeScript?

Three reasons:

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

Get started

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

Or use the database-shell directly via npx:

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

What's next

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

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

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

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

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

Who is UpCloud?

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

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

What this partnership unlocks

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

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

Coming to a burrow near you in summer 2026

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

Join the mission for a better internet

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

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

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

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

The new player offers:

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

In this post, we’ll cover:

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

Let’s get into it.

How the new player rolls out

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

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

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

How to upgrade to the new player

If you’re not using custom CSS or JavaScript

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

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

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

If you’re using custom CSS or JavaScript

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

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

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

What you’ll need to do:

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

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

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

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

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

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

This HTML-first approach offers a few advantages:

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

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

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

Try the new Bunny Stream player

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

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

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

References

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

You already know what you want to build. Finding the Docker image isn’t the problem… it’s everything after: the database, the volumes, the environment variables, and the networking. That’s what turns an afternoon into a weekend.

Templates for Magic Containers wire all of that up before you start. The setup shouldn't slow you down, and bunny.net shouldn’t just be the CDN you bolt on at the end; it should be where you build from the start.

Introducing templates for Magic Containers

The templates directory is a collection of pre-built full-stack configurations for Magic Containers. Each template comes with everything already configured:

• Application container
• Database sidecar
• Persistent volume
• Environment variables
• Internal networking
• CDN endpoints

You choose a template, review the configuration, adjust any settings, and deploy. If you’ve been meaning to try Magic Containers but aren’t sure how to configure everything, templates make it easier to see how it all fits together.

Whether you’re shipping a workflow backend, a content platform, or a data API, the directory covers the stacks developers actually reach for:

• n8n with Postgres for workflow automation
• Umami Analytics with Postgres for privacy-focused web analytics
• WordPress with MariaDB
• Next.js with Postgres
• Rails, Laravel, Django, Flask, Go with databases
• Hono with DuckDB
• Vite + React with Nginx

We are adding more regularly. If there is a stack you would like to see or one you want to contribute, join us on Discord.

What a template gives you

Setting up from scratch means creating the application, pulling containers from a registry, wiring up a database, attaching volumes, configuring environment variables, and exposing endpoints. It's not hard; it’s just friction.

A template removes that friction. The containers are already wired together, storage is attached, environment variables are set, and the database is reachable over localhost. Review the config, adjust what you need, and deploy. The whole stack comes up together.

Eject to GitHub

Templates are a starting point, not a commitment. If you want full control over the code, eject the project to your own GitHub repository and take it from there.

Once ejected, the repo is yours. You can modify the Dockerfile, change the stack, and control the code.

Push a change, and your image builds through GitHub Container Registry. Magic Containers redeploys the updated image automatically with the GitHub Action that’s preconfigured in each template.

You get the same CI/CD workflow you would configure yourself, without the initial boilerplate.

Where we’re heading

Templates solve the setup problem, but the bigger goal is making bunny.net a platform you can build on, share from, and automate.

We’re building the Magic Deploy button, a one-click deploy button that lets you add to any repository README or project page. Anyone can click it and deploy the stack directly to bunny.net, even without an account. The full configuration is prewired and deploys directly from source code.

We’re also building a CLI for the bunny.net developer toolkit. It's one of many developer tools designed to help you manage databases, edge scripts, storage buckets, and Magic Containers apps from the terminal.

The goal is to make bunny.net easier to build on. Templates when you want a head start, eject when you want control, one-click deploys when you want to share, and a CLI to tie it all together.

Try it

Templates are available now in the bunny.net dashboard. Choose a template, deploy a full-stack app in seconds, and eject to GitHub when you’re ready to take it further. This is what building on bunny.net looks like, and we’re just getting started.

If there is a template you would like to see added or one you want to contribute, join the discussion in our Discord.

I’ve been a huge fan of Heroku since the early days. They were true pioneers of platform as a service, git push heroku master was magic when it first appeared, and they made building scalable web apps and services genuinely easy at a time when the alternative was wrestling with EC2 instances and shell scripts.

A lot of us built our first production apps on Heroku, and the developer experience they created shaped how an entire generation thinks about deployment.

On February 6, 2026, Heroku announced that it is entering a sustaining engineering model. No new features, no new enterprise contracts. If you’re starting to think about what comes next, Magic Containers offers a straightforward migration path.

If you’ve been building twelve-factor apps on Heroku environment-based config, stateless processes, and backing services as attached resources, you’ll find that most of those principles translate directly to containers. The deployment model is different, but the thinking is the same.

How Heroku concepts map to Magic Containers

If you're familiar with Heroku, here's how the terminology translates:

Key differences

• No buildpacks, just Docker images: Heroku uses buildpacks to detect your language and build your app automatically. Magic Containers runs standard Docker images, giving you full control over your runtime, dependencies, and build process. You can deploy any public or private image from Docker Hub or GitHub Container Registry in any language or framework.
• Multi-container composition with persistent storage: Heroku apps typically run as a single dyno, with databases provided as separate add-ons connected over the network. Magic Containers allows multiple containers within the same application that communicate over localhost. This lets you run your app alongside its database without an external hosted database service. Persistent volumes provide durable storage so database files, uploads, and application state survive redeployments and restarts.
• Low-level networking: Heroku primarily provides HTTP routing in the US or the EU. Magic Containers supports TCP and UDP via global Anycast in addition to HTTP, enabling workloads such as DNS servers, game servers, VPN endpoints, or custom protocols.
• No git push deploys: Instead of pushing code directly, you build a Docker image locally or in CI, push it to a registry, and select it in the Magic Containers dashboard. This fits naturally into GitHub Actions or any CI/CD pipeline.
• Flexible autoscaling and provisioning: Heroku restricts autoscaling mainly to web dynos and higher-tier plans. Magic Containers autoscales by default and allows customization of scaling behavior and replica counts.

Migration steps

1. Containerize your app

If you already have a Dockerfile, you're ready. If not, create one for your app. Most frameworks have well-documented Docker setups.

Here's a minimal example for a Node.js app:

On Heroku, your Procfile might define multiple process types like web and worker. With Docker, each process type becomes its own image (or the same image with a different command). For example, a worker that processes background jobs:

It’s also possible to use a single Dockerfile and override the command per container (common with Go), if that’s your thing. On Magic Containers, you'd add both as separate containers in the same application: the web container with a CDN endpoint, and the worker container with no endpoint. They share localhost, so your worker can connect to the same database and Redis instance as your web process.

2. Push your image to a registry

Build and push your image to Docker Hub or GitHub Container Registry:

Then connect your registry in the Magic Containers dashboard under Image Registries.

3. Create your application

In the Magic Containers dashboard, click Add App and choose your deployment strategy. For stateful apps with a database, choose Single Region. For stateless apps, Magic deployment will distribute your app globally.

4. Add your containers

Add your app container, selecting the image you just pushed. Set your environment variables. These are the same config vars you had in Heroku, such as DATABASE_URL, SECRET_KEY, and PORT.

If you were using Heroku Postgres, add a PostgreSQL container in the same application. Since containers in the same app share localhost, update your database connection to point to localhost instead of the Heroku Postgres hostname.

5. Expose your app

Add a CDN endpoint pointing to your app's container port. This gives you a public URL with automatic HTTPS, no need to configure SSL certificates. You can also use Anycast for non-HTTP protocols like TCP or WebSocket traffic.

6. Export and import your data

Export your Heroku Postgres database:

Then restore it into your new PostgreSQL container. If your new Postgres is accessible via an Anycast endpoint, you can connect directly with pg_restore or psql.

Example deployments

We have step-by-step guides for deploying popular languages, frameworks, and databases on Magic Containers. These include guides for building APIs with:

• Go
• Node.js (Express and Hono)
• Python (FastAPI)
• PHP (Slim)

If you’re looking to get started with a popular web framework, you can host those too:

• Astro
• Next.js
• Nuxt
• Ruby on Rails

And databases, standalone or as sidecars to your container apps:

• ClickHouse
• MariaDB
• Postgres
• Redis

Each guide shows how to configure multi-container apps with databases, persistent volumes, and CDN endpoints.

You might not need a container

Not every Heroku app needs to become a container. bunny.net offers two other products that can replace parts of your stack with less overhead.

Edge Scripting is a serverless runtime for JavaScript and TypeScript that runs across bunny.net’s network. If your Heroku app is a lightweight API, a webhook handler, or middleware layer, Edge Scripting can replace it without a container at all. It also works as DNS middleware, letting you intercept and modify requests at the edge before they reach your origin. There’s no infrastructure to manage, or Dynos to scale.

Bunny Database is a globally distributed, SQLite-compatible database. If you were using Heroku Postgres through a third-party add-on, or your app doesn’t need the full power of PostgreSQL, Bunny Database is a simpler alternative that runs close to your code across bunny.net’s network.

Getting started

Magic Containers is designed to be the kind of platform Heroku was at its best: simple to deploy to, with none of the complexity you don’t need. Full flexibility of Docker and a global edge network.

You bring a container image, set your environment variables, attach storage where you need it, and you’re running. No buildpack debugging, no add-on marketplace, no dyno sleep.

We’d love to see what you’re building. If you’re mid-migration, just getting started, or want to swap notes with others making the same move, come join us on Discord.

After bringing Bunny Database into public preview last month, we’re continuing to build out the bunny.net developer toolkit with a new release for Magic Containers, our simple but powerful app hosting service.

Let’s hop right into the details.

Persistent volumes without the wiring

While autoscaling compute is largely a solved problem in modern PaaS, persistent storage often still means provisioning volumes manually, mounting them to specific machines, and ensuring they stay attached as your app scales or restarts.

Even having to think about that isn't any fun when you just want to build things, so we took great care to ship persistent storage that actually gets out of your way.

Rather than forcing you to reason in terms of machines, Magic Containers opts for a Docker Compose-style mental model, where your app lives in a pod. A pod may consist of multiple containers that share networking and resources, now including persistent volumes.

Here’s everything you need to know about this new capability:

• Auto-attach and detach: When your app scales and new replicas are started, new volumes are provisioned and attached automatically. When replicas scale down, their volumes detach but persist so they’re ready to reattach when needed, keeping all data intact.
• No data duplication between replicas: Each pod gets its own dedicated volume. When your app is replicated across regions, every replica runs with its own storage.
• Encryption: Every volume is AES-encrypted by default to keep all data safe.
• Limits: Up to 100 GB per volume, with up to two volumes per app (pod).
• Cost: $0.10 per GB per month, based on the allocated (provisioned) volume size.
  

So the idea is that persistent volumes in Magic Containers are set-and-forget. You just add a volume to your app and it’s automatically provisioned and managed, without you having to worry about volume behavior or any wiring.

In this demo, we set up a single-replica Redis instance and a Go API on Magic Containers using a persistent volume:

When to use persistent volumes

Magic Containers works best for apps and services you want running 24/7, such as:

• Web apps: always-on APIs, backends, and server-rendered apps
• Workers and automation: long-running jobs and internal services
• Real-time and TCP/UDP apps: game servers and services with persistent connections

Now that Magic Containers supports persistent volumes, you can have durable data right next to your code. This is useful for a number of things:

• Caches and generated assets: image caches, build caches, template compilation, model files
• Background processing and workers: file processing, PDF generation, media transcoding, temporary spooling before uploading to object storage
• Stateful single-instance services: DBs such as Redis and Postgres, or internal tools

For databases and caches that expect a single writable disk, run with 1 replica per volume. This is because each replica gets its own volume, so running multiple replicas of a stateful service could lead to state inconsistency. If you need your data replicated or distributed across regions, use Bunny Storage or Bunny Database instead.

What will you build?

We can’t wait to see what stateful apps you’ll build with Magic Containers. Log in or sign up to the dashboard to try out persistent volumes and let us know what you think on Discord.

This release is another addition to the bunny.net developer toolkit, and we don’t stop shipping. Stay tuned for more updates later this month.

Happy building!

Don’t want to babysit your app database on a VM but not willing to pay the DBaaS tax either? We're building a third way.

Today, we’re launching Bunny Database as a public preview: a SQLite-compatible managed service that spins down when idle, keeps latency low wherever your users are, and doesn’t cost a fortune.

So what’s the deal with database services in 2026?

It’s become clear by now that the DBaaS platforms that garnered the love of so many devs are all going upmarket. Removing or dumbing down free tiers, charging for unused capacity, charging extra for small features, or bundling them in higher tiers — you already know the drill.

Hard to blame anyone for growing their business, but it doesn’t feel right when these services stop making sense for the very people who helped popularize them in the first place.

So where does that leave you?

Like SQLite, but for the web

Not every project needs Postgres, and that’s okay. Sometimes you just want a simple, reliable database that you can spin up quickly and build on, without worrying it’ll hit your wallet like an EC2.

That’s what we built Bunny Database for.

What you get:

• One-click deployment: just name your database and go, no config needed
• Language-specific tooling: SDKs for TS/JS, Go, Rust, and .NET help you handle the boring bits
• Low latency anywhere: replication regions let you serve reads close to your users
• 41 regions worldwide: choose between automatic, single-region, and multi-region deployment
• Works over HTTP: wire up anything you’d like
• Database editor: insert data or run queries on the spot
• Metrics: instant visibility into reads, writes, storage, and latency
• Affordable, pay-as-you-go pricing: only pay for what you use, but without the serverless tax

Get the full tour including how to connect Bunny Database to your app in this quick demo from our DX Engineer, Jamie Barton:

Why care about database latency anyway?

You probably optimize the heck out of your frontend, APIs, and caching layers, all for the sake of delivering an experience that feels instant to your users. But when your database is far away from them, round-trip time starts to add noticeable latency.

The usual fix is to introduce more caching layers, denormalized reads, or other workarounds. That’s obviously no fun.

And when you think about it, devs end up doing this because the popular DBaaS platforms are usually either limited, complex, or too costly when it comes to multi-region deployments. So what looks like a caching problem is actually a data locality issue.

OK, but how bad can it really be?

To find out, we ran a read latency benchmark and measured p95 latency in Bunny Database.

We picked a number of regions across the world and compared round-trip time for client locations ever farther away from the database in:

• a single-region setup,
• with replication regions enabled.

Turns out serving reads close to clients reduced latency by up to 99%.

Check out the full write-up on the benchmark setup and results here.

While this definitely matters most to apps with global users, data locality does apply to everyone. With Bunny Database, you don’t have to stick to major data center locations and compensate with caching workarounds any more. Instead, you get a lot of flexibility to set up regions in an intuitive interface and it’s easy to switch things up as your requirements change.

Choose between 3 deployment types when creating a database:

• Automatic region selection gives you one-click deployment with minimal latency. Bunny Database will select regions for you based on your IP address (you can check and tweak the selection in settings later).
• Single-region deployment lets you pick one of 41 regions available worldwide (check the full list here).
• Manual region selection gives you custom multi-region setup, where you can freely pick regions that make the most sense for your audience.

All of this lets you start wherever you’d like and add regions as needed, without re-architecting your app.

Usage-based pricing, but without the serverless tax

In the database world, capacity-based pricing gives you some predictability. But no one likes to pay for unused capacity, right?

Serverless, on the other hand, is supposed to be cost-efficient, yet can rack up bills quickly, especially when the DBaaS charges significant markups on top of already pricey compute.

We don’t do hyperscalers, though, so we can charge a fair price for Bunny Database in a usage-based model.

• Reads: $0.30 per billion rows
• Writes: $0.30 per million rows
• Storage: $0.10 per GB per active region (monthly)
• When not getting requests, Bunny Database only incurs storage costs. One primary region is charged continuously, while read replicas only add storage costs when serving traffic (metered by the hour)
• Your usage is charged continuously (pay-as-you-go) and invoiced monthly

During the public preview phase, Bunny Database is free.

Wait, what does “SQLite-compatible” actually mean?

Bunny Database wouldn’t be possible without libSQL, the open-source, open-contribution fork of SQLite created by Turso.

We run Bunny Database on our own fork of libSQL, which gives us the freedom to integrate it tightly with the bunny.net platform and handle the infrastructure and orchestration needed to run it as a managed, multi-region service.

What does this mean for Bunny Database’s upstream feature parity with libSQL and SQLite, respectively?

The short answer is that we don’t currently promise automatic or complete feature parity with either upstream libSQL or the latest SQLite releases.

While libSQL aims to stay compatible with SQLite’s API and file format, it doesn’t move in lockstep with upstream SQLite. We wouldn’t expect otherwise, especially as Turso has shifted focus from libSQL toward a long-term rewrite of SQLite in Rust.

For Bunny Database, this means that compatibility today is defined by the libSQL version we’re built on, rather than by chasing every upstream SQLite or libSQL change as it lands. We haven’t pulled in any upstream changes yet, and we don’t currently treat upstream parity as an automatic goal.

That’s intentional. Our focus so far has been on making Bunny Database reliable and easy to operate as a service. We think bringing in upstream changes only makes sense when they clearly improve real-world use cases, not just to tick a parity checkbox.

If there are specific libSQL features you’d like to see exposed in Bunny Database, or recent SQLite features you’d want us to pull in, we’d love to hear about it. Join our Discord to discuss your use cases and help shape the roadmap!

What’s ahead for Bunny Database

Speaking of the roadmap, we don’t stop cooking. Here’s what’s coming up next:

• Automatic backups
• Database file import/export
• Auto-generated, schema-aware API with type-safe SDKs

There’s even more to come, but it’s too soon to spill the beans yet, especially while we’re in public preview. We’d love to hear your feedback, so we can shape what ships next together.

More tools to build with

Bunny Database works standalone and fits right into your stack via the SDKs (or you can hook up anything using the HTTP API). But it also plays nicely with Bunny Edge Scripting and Bunny Magic Containers.

To connect your database to an Edge Script or a Magic Containers app, simply go to the Access tab of the chosen database and click Generate Tokens to create new access credentials for it.

Once they’re generated, you’ll get two paths to choose from:

• Click Add Secrets to an Edge Script and select the one you’d like to connect from the list. You’ll also need to import the libSQL TypeScript client and use the provided code snippet to connect it to your database.
• Click Add Secrets to Magic Container App and select the one you’d like to connect from the list. You’ll also need to connect to the database from your app using one of the client libraries or the HTTP API.

After you complete the setup, the database URL and access token will be available as environment variables in your script or app. Use them to connect to your database:

You can find more detailed, step-by-step integration instructions in the docs:

• Connecting an Edge Script to Bunny Database
• Connecting a Magic Containers app to Bunny Database

Hop on board

We can’t wait to see what you’ll build with Bunny Database and what you think of it. During the public preview phase, you get 50 databases per user account, each capped at 1 GB, but we hope this should be more than enough for lots of fun projects.

Just sign in to the bunny.net dashboard to get started. Happy building!

You can spend a lot of time squeezing milliseconds out of your frontend, APIs, and caching layers. But if your database sits far away from your users, every request still pays the cost of a long round trip.

When that happens, devs usually reach for workarounds: more caching, denormalized reads, background sync jobs, or other techniques to hide the latency. These approaches work, but they add complexity quickly.

The underlying issue is simpler. For most applications, database reads are still centralized in a single region, and distance is unavoidable. This isn’t really a caching problem — it’s a data locality problem.

So the obvious question is: how bad does it actually get as users move farther away from the database?

To find out, we measured p95 latency in Bunny Database across increasing distances between the database and client locations. We then measured p95 latency for the same set of locations with read replication enabled, allowing reads to be served from regions local to the user, and compared the results.

Benchmark setup

Since Bunny Database is based on SQLite, we chose the Chinook dataset, a commonly used sample SQLite database with a realistic transactional schema.

While the database engine itself is very fast, making query execution time negligible compared to network latency, we still opted for a realistic read query rather than a trivial SELECT 1, to better reflect how applications actually access data:

Bunny Database is available in 41 regions worldwide, but to keep the benchmark focused, we limited the experiment to a smaller, representative set of locations:

• Ashburn, Frankfurt, and Singapore as primary regions: these are commonly offered anchor regions across database providers and serve as practical reference points for North America, Europe, and Asia-Pacific.
• Palo Alto, London, Milan, São Paulo, Tel Aviv, Tokyo, Cape Town, and Sydney as client locations and read replica regions: this set spans the globe and represents increasing geographic distance from Ashburn.

As for technical implementation, we used Grafana k6 to conduct p95 latency measurements. Since the benchmark needed to run from the selected client locations, we ran k6 on Magic Containers, the bunny.net managed container service that shares the same regions with Bunny Database.

This setup allowed us to simulate the round-trip latency experienced by users in different parts of the world when accessing a centralized database.

Benchmark results

The tables below show p95 read latency measured from each client location, first with a single-region database setup and then with read replication enabled, where queries are served from replicas deployed in the same regions as the clients, rather than always being routed to the primary region.

Client locations are ordered by increasing distance from Ashburn, and the same ordering is reused for Frankfurt and Singapore for consistency.

Read latency by client location

Primary region: Ashburn

Primary region: Frankfurt

Primary region: Singapore

Notes on methodology

Each data point represents the p95 latency observed within a single benchmark run consisting of hundreds of requests from a given client location. We didn’t average results across multiple runs, which means transient network effects are preserved rather than smoothed out.

This reflects real-world conditions, where user requests experience the network as it is, not as an average.

Read replicas were deployed in the same regions as the client workloads, making this a best-case scenario for read locality. As a result, the “with replication” measurements represent the upper bound of what can be achieved when reads are served locally.

In practice, results will vary depending on region coverage, routing, and workload patterns — but the underlying trend remains the same.

What these results mean in practice

• Distance dominates latency in single-region setups: without replication, read latency increases sharply as client locations move farther away from the primary region, often reaching hundreds of milliseconds for intercontinental access.
• Read replication consistently collapses read latency across regions: with replication enabled, p95 read latency drops to single- or low double-digit milliseconds in nearly all locations, regardless of distance from the primary region.
• The biggest gains appear for far-away users: intercontinental client locations see latency reductions of up to 99%, turning multi-hundred-millisecond round trips into near-local reads.
• Replication doesn’t eliminate all variability: some locations still show higher p95s than others, reflecting real-world network conditions and routing differences rather than database performance.
• The pattern holds across all primary regions tested: whether the primary region is Ashburn, Frankfurt, or Singapore, the overall trend remains the same: distance hurts without replication, and replication largely neutralizes it.

The takeaway

Our benchmark shows that database placement has a first-order impact on user experience for global applications. A single-region database may perform well for nearby users, but quickly becomes a bottleneck as traffic spreads geographically.

By serving reads from regions close to users, read replication shifts latency from being distance-bound to being dominated by local network conditions without requiring application-level caching or architectural workarounds.

Last quarter we launched HopStart, our startup program to help founders worry less about infrastructure and focus more on their products, so they can build their dreams.

HopStart runs in quarterly cohorts. For each round, we select three winners and support them with up to $50,000 USD in credits for use on bunny.net, alongside regular check-ins and feedback, as well as early access to upcoming features and products.

We’ve been overwhelmed by the response to the program and received many strong applications. That said, narrowing it down to just three startups for this cohort wasn’t easy. We looked at how each product could make a real difference for its users or industry, and at whether our platform could meaningfully support their growth.

Without further ado, meet HopStart cohort #1.

1st place: Phare

Founder: Nicolas Beauvais

Year founded: 2022

URL: https://phare.io/

Credits received: $50,000 for one year

In the founder’s words: “Phare currently serves over 500 companies with uptime monitoring, incident management, and custom status pages, with a strong focus on EU-based providers, privacy, and user experience.”

2nd place: Split Hero

Founder: Adam Lacey

Year founded: 2019

URL: https://splithero.com/

Credits received: $25,000 for one year

In the founder’s words: “We want to be the number one privacy-first, edge-native experimentation platform for agencies and product teams. It turns ‘should we test?’ into a default ‘yes’ by removing friction (no heavy scripts, no cookies, no PII), delivering variant decisions in under 30 ms, and keeping return visitors consistent via anonymous, deterministic IDs. A real-time event pipeline and warehouse-grade analytics (aggregated, de-identified) turn noise into decisions, not dashboards.”

3rd place: uDocz

Founder: Carlos Effio

Year founded: 2020

URL: https://www.udocz.com/

Credits received: $10,000 for one year

In the founder’s words: “uDocz is the AI operating system for higher education, improving student retention, staff productivity, and overall efficiency. Currently, we serve 4 million students every month. Our AI-powered learning platform helps universities provide better academic support to their students and faculty. We have managed to improve students' course performance (a 30% boost in grades) and reduce dropout rates, enhance career readiness, and graduate profile. In addition, we have a direct-to-consumer model, where we currently serve millions of students every month with supplementary classroom help (class materials and AI tools).”

Apply for the next HopStart cohort

Applications for cohort #2 are already open. To be considered for the next round, all you need to do is fill in this short form before February 28.

We’re looking for bold ideas with meaningful impact and a clear fit for bunny.net’s support. If you applied before but weren’t selected, you’re encouraged to apply again — a different cohort can mean a better fit.

Three teams will be selected for the second cohort and announced no later than April 2026.

We’re looking forward to seeing what you’re building!

Great developer experiences start with great documentation. That's why we just launched new bunny.net developer docs, rebuilt from the ground up to better support how developers actually build, explore, and integrate with bunny.net.

Our previous documentation lived on an outdated platform that didn't scale with bunny.net's growth, nor with the expectations developers now have for modern dev tools.

As our product offering grew, the docs became increasingly flat and unstructured. Everything lived at the same level, which made it hard for people to stay focused and find the right docs quickly.

Listening to your feedback, one theme kept coming up: the experience felt overwhelming. Finding the right information often meant losing context, jumping between pages, or second-guessing whether you were even in the right place.

At the same time, the bar for developer documentation has risen. Devs expect modern, clean, and structured docs, AI-friendly content structures, copyable pages for LLMs and tools, and interactive API references with code snippets.

So we decided it was time for a complete rethink.

The solution: documentation built around products

The biggest change is structure. Instead of a single, flat documentation space, each bunny.net product now has its own dedicated area. This allows developers to fully immerse themselves in one product at a time, without distractions.

The new documentation contains spaces for each product:

• Magic Containers: Docker-based container deployment close to users
• Edge Scripting: Serverless functions with TypeScript
• Database: Serverless SQLite over HTTP
• CDN: Content delivery, acceleration, and edge rules
• Shield: WAF, DDoS protection, rate limiting, and bot detection
• Stream: Video streaming, encoding, and DRM
• Storage: Global object storage
• Optimizer: Automatic image and web optimization
• DNS: Ultra-fast, scriptable DNS with DNSSEC

Within each product, you'll find clearly organized sections: Quickstarts to get up and running fast, Feature documentation that goes deep when you need it, Practical examples to see real-world usage, and Guides that stay relevant to the product you're working on.

The goal is simple: when you're working with a bunny.net product, everything you need should be right there, in context.

A complete API overhaul

We've significantly upgraded our API reference across all products. Our API documentation is now fully OpenAPI-spec-driven, which unlocks a much richer experience:

• Make real API requests directly from the browser
• Explore accurate request and response examples
• See up-to-date schemas generated from the source of truth
• Understand endpoints faster with consistent, structured layouts

Whether you're exploring an API for the first time or debugging an integration, the new API Reference is designed to be both powerful and approachable.

SDKs, examples, and integrations

We've added SDK documentation for Storage across multiple languages: TypeScript, PHP, .NET, and Java. Each SDK comes with installation instructions, authentication setup, and practical examples for common operations.

Documentation isn't just about explaining features. It's about showing how to use them. Each product includes practical, copy-paste-ready examples. Edge Scripting, for instance, comes with examples for common patterns like modifying response headers, handling redirects, and returning structured JSON and connecting to a database, all in TypeScript.

We've also started to migrate some useful integration guides from our support knowledge base, covering popular platforms like WordPress, Shopware, Drupal, and Magento on the CMS side, plus cloud storage providers like Amazon S3, Azure Blob, Backblaze, and DigitalOcean Spaces.

What's next: hopping forward

This new documentation platform gives us the flexibility to keep improving: adding more guides, tutorials, embedding videos, embracing AI-assisted workflows, and evolving alongside the wider developer ecosystem.

The new documentation includes nearly 300 new pages of content organized across quickstarts, feature guides, API references, SDK documentation, and real-world examples. And we're just getting started.

Most importantly, it gives us a solid foundation to continue listening to your feedback and iterating quickly.

Explore the new docs

We're excited to share this with the community and would love to hear what you think. Dive in, explore your favorite bunny.net products, and let us know how the new experience works for you.

Start exploring the new bunny.net developer documentation

Video viewers love having chapters with clear titles they can hop between, even in shorter videos. But setting those up manually takes time and effort. You have to choose the right timestamps, name each section, and make sure it all makes sense.

We just fixed that for Bunny Stream users with smart chapters, a new feature that automatically generates chapters for your videos!

How smart chapters work

Smart chapters extend the Bunny Stream transcribing feature, which is powered by Whisper, the popular automatic speech recognition (ASR) model from OpenAI. Smart chapters use the video transcription to automatically generate chapter timestamps and titles. Because of this, videos need to be transcribed or have a caption track already available before chapters can be created.

How to enable smart chapters

To automatically generate chapters for newly uploaded videos, choose a video library and go to Transcribing to toggle Smart chapters on.

Alternatively, you can enable smart chapters programmatically via the API:

Once enabled, all newly uploaded videos will have chapters automatically generated as part of the transcription process — at no additional cost.

Additionally, instead of enabling smart chapters globally, you can generate them on a per-video basis via the Trigger Smart actions endpoint. This new endpoint also supports generating smart titles, descriptions, and moments.

For more info on programmatic access, refer to the smart chapters docs and API reference.

How to generate chapters for previously uploaded videos

Once you’ve enabled smart chapters and want to generate chapters for a previously uploaded video, open the video in the library and go to the Chapters tab, then click Generate Smart Chapters.

Note: If the video you want to generate chapters for doesn’t yet have a transcription, it will need to be transcribed first.

How to edit the auto-generated chapters

If you’re not fully satisfied with your video’s automatically generated chapters, you can edit them under the Chapters tab. Adjust timestamps, change titles, or add new chapters as needed.

How to track transcription costs

Generating chapters comes at no extra cost other than the cost of video transcription, which is charged at $0.10 per minute of video per language.

You can view your current usage in the dashboard under Balance → Billing → Stream add-ons.

You can also track your transcription stats, including cost, via the Get Video Library Transcribing Statistics endpoint we added recently.

Smart chapters now available in Bunny Stream

The new feature has now been rolled out to all Stream users!

No matter what kind of video content you’re hosting, chapters add a bit of extra polish to your audience’s experience. And now that you can generate them automatically when transcribing content, it’s an absolute no-brainer.

Give smart chapters a try, and happy hosting!

References

• Smart chapters docs
• API reference

Six months ago, we launched Bunny Shield in Preview with one goal: to make serious, scalable security something anyone could use. No enterprise contracts. No hidden pricing. Just strong protection that was easy to turn on.

It was the next step in a bigger journey, evolving bunny.net from a content delivery network into a global platform that can power and protect your entire website or application. Performance and security, working hand in hand at the edge.

Since that day, Bunny Shield has quietly guarded tens of thousands of websites and APIs around the world. It’s blocked exploits before they reached production and absorbed floods that would have brought whole services down. Most of the time, no one even noticed, and that’s exactly how it should be.

Now, Bunny Shield is ready to move forward. Today, we’re graduating from Preview and officially moving into General Availability. After trillions of requests, months of testing, and continuous tuning, Bunny Shield has matured into a complete, reliable layer of defense built directly into the bunny.net edge.

The journey from preview to proven

When Bunny Shield launched, it started as an idea: security that worked as smoothly as delivery. What followed was six months of learning in production. We saw everything from quiet credential stuffing to coordinated botnets and sudden floods. Each event helped us refine how Shield reacts, adapts, and protects without slowing you down.

It wasn’t about adding features for the sake of it, but about shaping something that felt effortless to use and powerful when it mattered. Today, Bunny Shield stands as a proven part of the stack. Fast, consistent, and built for real traffic.

Built for the real world

Bunny Shield now protects against the full range of threats across the network. DDoS mitigation absorbs attacks at the edge so they never reach your origin. The WAF inspects every request with flexible, customizable rules while staying focused on accuracy. Rate limiting helps you keep abusive traffic in check globally. Bot detection identifies and stops automated traffic that tries to blend in. Access lists give full control over who gets through. Upload scanning keeps malicious files out before they cause harm.

And coming soon, API Guardian will extend that same protection to APIs and AI-driven applications, adding deeper inspection and schema-aware validation. All of it runs natively at the edge, quietly, with almost no latency.

Transparent by design

Transparency has always been at the core of Bunny Shield. Every plan is built to be clear and predictable, with straightforward usage limits and simple overage pricing that scales with you. Whether you’re running a personal project or a global platform, you know exactly what you’re getting and what it costs.

Only clean requests count toward your plan, and our clean-request model makes it easy to understand how traffic is counted, with only legitimate requests billed. Anything blocked by Shield, whether through DDoS mitigation, the WAF, access lists, bot detection, or upload scanning, is excluded from your usage.

The result is a plan structure that grows fairly with your traffic without hidden costs or surprises.

What the numbers show

Six months on, Bunny Shield has quietly processed over 51.9 trillion requests, filtering out 16.4 billion malicious ones before they could cause harm. Across tens of thousands of websites, it’s kept performance steady and traffic secure without missing a beat.

Bunny Shield mitigating a large-scale attack. Challenging more than 142 million abusive requests and blocking nearly 100 million in a single day with zero impact to performance.

Across the edge, Bunny Shield’s layered defenses work in concert. Here’s what that looks like in numbers:

• DDoS Attacks
  • 3.6 billion challenged before reaching origins
  • 42.9 million threat sources blocked
  • 2.1 billion logged for anomaly detection
• Bot Detection
  • 986 million challenges issued
  • 1.16 billion logged for behavioral analysis
• Rule Engine
  • 177 million blocked by custom or managed WAF rules
  • 2.2 billion logged for tuning and insights
• Access Lists
  • 188 million challenged
  • 133 million blocked by access rules
  • 360 million logged for visibility
• Rate Limiting
  • 3.6 billion challenged globally
  • 1.7 billion blocked for exceeding thresholds
  • 37 million logged for visibility and refinement
• Upload Scanning
  • 1.55 million files scanned for malware and unsafe content

Monthly malicious request volume, April–October. A massive DDoS surge in September pushed malicious traffic to 7.9 billion. A vivid example of how unpredictable the threat landscape can be before settling back to normal levels in October.

Behind each of those numbers is a request that stayed online, a user who never saw an error page, and a builder who could keep focusing on what mattered instead of firefighting.

The road ahead

Security never stands still and neither does Bunny Shield. The next stage is all about depth. Smarter detection, better visibility, and even greater trust.

API Guardian leads the way, adding schema-aware inspection, stronger authorization validation, and early AI protections for APIs and intelligent applications. It understands context, not just traffic, helping stop abuse before it reaches your logic layer.

Upload scanning continues to evolve, catching malware, spam, and harmful content continuously before it ever reaches your origin.

Bot detection is growing more intelligent through new behavioral models and anomaly analysis that identify subtle automation patterns while reducing friction for legitimate users.

As the landscape shifts, automated scraping and AI-powered bots are driving up bandwidth costs and putting more pressure on infrastructure. Bunny Shield is evolving to give you greater control over these threats, helping you defend your content, manage costs, and maintain performance without constant intervention.

Observability is expanding across the platform. Soon, Bunny Shield will provide clearer insights into live attacks and overall traffic behavior, making it easier to understand what’s happening at the edge in real time. Richer analytics and deeper visibility will turn defense into something measurable and transparent.

DDoS alerts are also coming soon, giving you instant visibility when large-scale attacks are detected and mitigated. You’ll be able to see when and how Bunny Shield steps in to protect your traffic, with real-time updates and clear summaries that bring peace of mind without adding noise.

Together, these improvements are shaping Bunny Shield into more than a security product. It’s becoming the intelligence layer of the bunny.net platform. A foundation that powers, protects, and accelerates everything built on it.

Ready for whatever comes next

As Bunny Shield moves into General Availability, it carries six months of lessons, testing, and real-world proof. It’s faster, smarter, and easier to use than ever, built for anyone, from first projects to global platforms.

Thank you to everyone who helped shape it during Preview. Your feedback, ideas, and patience made this release what it is.

Bunny Shield is now generally available.

Turn it on. Let it run. Stay protected.

This is just the beginning of what bunny.net is becoming. A platform built to power and protect the internet, one hop at a time.

Explore the Advanced, Business, and Enterprise plans to find your perfect level of protection and hop into stronger security today.