Introducing pattern matching for Edge Rules

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.