How rules work
Rules let you attach ordered, conditional behavior to a CDN property. The Paradarum edge (OpenResty) evaluates each rule against incoming requests and applies the matching ones to the request or response.
The two shipped rule types
Today the rules engine ships exactly two rule types:
| Rule type | RuleType value | What it does |
|---|---|---|
| Cache rule | 0 | Controls cache TTL and per-URL cache features for matching URLs. See Cache rules. |
| Header rule | 1 | Adds, sets, or deletes an HTTP header on the request or response. See Header rules. |
Both rule types share the same matching mechanism — a single URL match operator — and the same lifecycle controls described below.
Some scaffolding exists internally (and in the frontend) for redirect, reverse-proxy, static-response, and rewrite rule types. None of these are wired into the product and they cannot be created or edited. Treat them as roadmap only — do not rely on them. The only usable rule types are Cache rule and Header rule.
Where rules live
Rules attach to a single property. In the Paradarum panel, open Properties → (select a property) → Detail → Rules. The Rules tab gives you a list view, a create flow, and an edit flow per rule.
When you create a rule, a Select Rule Type dialog offers two cards — Cache Rule and Header Rule — and your choice determines which configuration form you see.
Ordering
Every rule carries an integer order. Lower order runs first, and rules are evaluated top to bottom.
Evaluation does not stop at the first match. The last matching cache rule — the one with the highest order — is the one that governs the request, and it supplies both its TTL and its location features (bypass cookies, cache key, minification).
Put your broad defaults at the top and your specific overrides underneath: the override is evaluated later, so it wins. This is why the seeded Default — cache static assets rule sits at order 0 — anything you add afterwards supersedes it.
Header rules are unaffected by this: every matching header rule is applied.
In the panel you reorder rules by drag-and-drop, and the panel renumbers them 0, 1, 2 … so two rules never share the same position. Each drag persists the changed rows and shows a confirmation snackbar.
Each rule's new position is saved individually, so a partial failure is possible — if it happens, the panel shows a "Some rule order updates failed" message and you can simply drag again.
Enable and disable
Each rule has an isEnabled toggle. Disabling a rule stops it from being applied without deleting it, so you can keep a rule's configuration around and switch it back on later.
System rules
Rules also carry an IsSystem flag. System rules are managed by the platform — for example, the rules that back a live-stream property — and are:
- read-only — you cannot edit or delete them from the panel, and
- hidden by default — they are filtered out of the list unless you explicitly include them.
For managed properties (such as one backing a live stream), the panel shows system rules read-only with a one-line summary, for example cache 3600s · /hls/ or response header · Access-Control-Allow-Origin: *.
How changes reach the edge
Changes are near-real-time, not instant. The edge polls configuration rather than receiving a synchronous push — creating, editing, deleting, or reordering a rule updates the stored configuration, and the OpenResty edge picks it up on its next poll.
Because propagation is poll-based, allow a short delay after saving before validating behavior at the edge.
Next steps
- URL match operators — the five ways a rule can match a request URL.
- Cache rules — TTL and per-URL cache features.
- Header rules — add, set, or delete request/response headers.
- CMS presets — ready-made rule sets for common platforms.