Path Rules
Path rules apply basic authentication, rate limiting, and IP allow / deny lists to specific URL paths on the same container. Use them when different parts of your application need different protection — for example, an /api/admin path that needs basic auth and an IP allow-list, while the rest of /api only needs rate limiting.
Path rules apply basic authentication, rate limiting, and IP allow / deny lists to specific URL paths on the same container. Use them when different parts of your application need different protection — for example, an /api/admin path that needs basic auth and an IP allow-list, while the rest of /api only needs rate limiting.
Path rules are only available on HTTP containers. Worker containers don't accept inbound traffic and the setting has no effect on them.
How matching works
For every request, Bahriya picks the rule whose path is the longest match for the request URL. A rule on /api/admin/users takes precedence over a rule on /api/admin for any request that starts with /api/admin/users. If two rules tie on path length, the rule with the higher priority wins.
When no path rule matches, the container's top-level controls (configured on the main edit form) apply instead.
A path rule's controls fully replace the container-wide controls for the same control type on that path — there is no merge. If your container has rate limiting at 1,000 requests per minute and a path rule for /api/admin has rate limiting at 10 requests per minute, requests under /api/admin are capped at 10 per minute (not 1,000, not 1,010).
Configuration
You manage path rules from the Path Rules accordion on the container's edit page, just below the Security accordion. Click New rule to create one, or pencil-edit an existing row to modify it. The accordion only appears once the container exists — when creating a brand-new container, save it first, then open the edit page to add path rules.
| Field | Description |
|---|---|
| Handle | Short identifier for the rule. Lowercase letters, numbers and hyphens only. Used in URLs and logs. Cannot be changed once the rule is created. |
| Path | URL path prefix the rule applies to. Must start with /. |
| Priority | Tiebreaker for equal-length prefix matches. Higher values win. Defaults to 0. |
| Basic authentication | Toggle on to require a username/password to access this path. Add up to 10 credential pairs. |
| Rate limiting | Toggle on to throttle requests per IP. Set per-second, per-minute, or per-hour windows (combine as needed). |
| IP allow-list | Toggle on to restrict access to specific IPs or CIDR ranges. Other traffic is rejected. |
| IP deny-list | Toggle on to block specific IPs or CIDR ranges. |
At least one control must be enabled for a rule to be saved.
Overlap advisory
When you enter a path that is a prefix of (or shares a prefix with) an existing rule, the form shows a non-blocking notice naming the other rule. Overlap is allowed — Bahriya's routing engine picks the longest match per request — but the notice gives you a chance to double-check the intent before saving.
Editing a rule
You can update everything except the handle. To replace the handle, delete the rule and create a new one. Updating a path rule triggers a redeploy of the container so the ingress picks up the change; deployments are rolling and have no downtime.
Deleting a rule
Use the trash icon in the Path Rules accordion and confirm. The rule is removed at the next deploy.
Combining with container-wide controls
Path rules are additional to the container-wide controls — they apply to a specific path; the container-wide controls apply everywhere else. You can have both:
- Container-wide rate limiting at 1,000 / minute.
- A path rule on
/webhookwith rate limiting at 60 / minute. - A path rule on
/api/adminwith basic authentication.
Requests to /webhook hit the per-path rate limiter (60 / minute), requests to /api/admin need basic auth, and all other requests fall back to the container-wide 1,000 / minute limit.
Pricing
Each enabled control on each rule bills at the same per-region rate as the matching container-wide control — no new SKUs are involved. If your container has rate limiting enabled and you add 3 path rules with rate limiting, you pay for 4 instances of rate limiting per region per hour (1 container-wide + 3 path-scoped).
The pricing calculator has dedicated inputs for path rules so you can estimate the cost before you ship.