ShieldIngress Help & Documentation
Everything you can configure from your dashboard — how domains go live, and what every setting on the Edit Configuration screen actually does.
🚀 Getting Started
Getting a domain live on ShieldIngress has three parts: add the domain, prove you own it, and point its DNS here. SSL certificates are issued automatically once those are done — you don't request one yourself.
Adding a domain
From Quick Actions → ➕ Register Domain, start by choosing a Domain Type: Full origin domain (below) routes traffic to your own backend with WAF and rules available. Redirect only just forwards a hostname to another URL, with almost nothing else to configure — see Redirect-Only Domains. Everything below this point describes a full origin domain.
- Hostname — the domain you're protecting, e.g.
www.example.com. - Backend IP — where your actual website/app lives (your origin server). This is the only required field beyond hostname.
- Backend port — defaults to
443. - TLS to origin — whether ShieldIngress connects to your backend over HTTPS. Leave this on unless your origin only serves plain HTTP.
- SNI override — the hostname ShieldIngress presents in the TLS handshake to your origin, if it differs from your public hostname (e.g. a shared hosting box that needs a specific SNI to route correctly). Defaults to your hostname.
- Security & WAF Settings (collapsible) — see WAF & Security below; you can also leave these at the defaults and adjust later.
- Advanced Health Settings (collapsible) — health check path (default
/health) and check interval (default 30s), used to monitor your origin's uptime.
Creating a domain doesn't touch live traffic by itself — it opens a draft revision (see Revisions & Deploy) that you configure and then explicitly deploy when ready.
Pointing DNS at ShieldIngress
The Register Domain form shows a DNS Setup box with a CNAME record to create at your DNS provider, even before you save the domain:
Type: CNAME Name: <your hostname> Value: <your ShieldIngress edge target>
The same instructions are always available from the domain's Edit Configuration → 🌐 DNS tab, along with a live check that tells you whether your current DNS already resolves to ShieldIngress. This check is purely informational — it never blocks anything, so you can configure everything else first and switch DNS over whenever you're ready.
Domain ownership verification
Before a domain can go live in production or receive an SSL certificate, you need to prove you control it — this stops someone else from registering a domain they don't own. Use either method (you only need one):
- DNS TXT record — create a TXT record named
_shieldingress-challenge.<your hostname>with the token value shown in the DNS tab. - HTTP file — serve the exact token text at
http://<your hostname>/.well-known/shieldingress-verification/<token>on your existing site.
Click Check Now once the record/file is in place, or just wait — the platform also checks automatically in the background. Verification only has to happen once; it doesn't need to be maintained afterward.
SSL / TLS certificates
Once a domain is verified, ShieldIngress automatically requests a certificate from Let's Encrypt the first time you deploy to production — there's no separate "issue a certificate" step, and no cost or manual renewal to think about. Certificates auto-renew before they expire (~90-day lifetime).
This is the certificate that protects the connection between your visitors and ShieldIngress. It's separate from the TLS to origin toggle mentioned above, which controls the connection between ShieldIngress and your own backend.
🔀Redirect-Only Domains
For a domain that only needs to forward visitors elsewhere — the classic test.com → www.test.com case — a redirect-only domain skips the backend server, WAF, and every rule type entirely. It still gets its own DNS setup, ownership verification, and SSL certificate exactly like a full domain, and still goes through Revisions & Deploy — there's just far less to configure.
Not to be confused with Redirects & Rewrites, which sends specific paths on a full origin domain elsewhere while the rest of the domain keeps serving normally. A redirect-only domain instead is the redirect — every request to it forwards, with no origin behind it at all.
Setting one up
On Quick Actions → ➕ Register Domain, set Domain Type to Redirect only, then fill in:
| Field | What it does |
|---|---|
Redirect Target | Scheme and host only, e.g. https://www.example.com — no path, trailing slash, or query string. The visitor's original request path and query string are appended automatically, so test.com/blog?x=1 becomes https://www.example.com/blog?x=1. |
Redirect Code | 301 (permanent), 302, 303, 307, or 308. |
After creating it, its Edit Configuration screen shows just two tabs — Redirect (target/code) and DNS — in place of the usual Origin/WAF/rules tabs.
example.com → www.example.com) can coexist without needing to upgrade just for that.Switching a domain's type
You don't have to decide forever at creation time. From a domain's Edit Configuration screen, use Switch to redirect-only domain (Origin & Health tab) or Switch to full origin domain (Redirect tab) to convert it in place — the domain keeps its hostname, verification status, and revision history either way. This needs an open draft revision, same as any other edit.
🚀 Revisions & Deploy
Every change you make — a new rule, a WAF setting, a backend server edit — happens inside an open draft revision, not live traffic directly. Nothing reaches staging or production until you explicitly deploy that revision.
Drafts, saved revisions, and deploying
- A new domain automatically opens Revision #1 as a draft, so you can start configuring right away.
- While a revision is a draft, you can keep editing it freely — add rules, change WAF settings, adjust backends, anything on the Edit Configuration screen.
- A revision becomes saved (frozen) the moment you deploy it anywhere for the first time — after that it's a permanent snapshot and can't be edited further.
- To make further changes after that, open a new revision from Quick Actions → 🚀 Revisions & Deploy — it starts as a copy of whichever saved revision you base it on.
- Deploying a saved revision sends it to one or both targets:
- Staging — an isolated test environment. Requires the Pro plan. No real traffic, no SSL certificate issuance.
- Production — your live domain, seen by real visitors. Requires the domain to be verified first.
- Staging and production can be running different revisions at the same time — nothing forces them to match. Deploying an older saved revision to an environment rolls that environment back to that point.
Change Log vs. Revisions — what's the difference?
Quick Actions → 🕐 View Change Log is a separate, finer-grained history: it automatically snapshots your currently open draft after every single edit (last 30 changes), so you can undo your last few edits without discarding the whole draft. It never deploys anything anywhere — it only affects the draft you're actively working on.
🌐Origin & Health
This tab controls where traffic actually goes once it passes inspection.
Backend servers
Every domain has one primary backend server (set when you created the domain). You can add more from this tab — useful for redundancy or spreading load across multiple origins. Adding a second server requires the Pro plan.
| Field | What it does |
|---|---|
Address / Port | Where this server lives. |
Weight | 1–256 (default 100) — higher weight gets proportionally more traffic under weighted balancing. |
Max connections | Optional cap on concurrent connections to this server. |
Backup | Only receives traffic if every non-backup server is down. Your primary server can't be marked backup. |
TLS to origin | Per-server HTTPS toggle to this specific backend. |
Label | Optional friendly name shown in the UI. |
Health check type | SNI (full TLS/HTTP check) or Port (raw TCP reachability only). |
Health path | URL path checked for a healthy response, default /health. |
Load balancing
Once a domain has 2+ servers, you can configure how traffic is split:
| Field | What it does |
|---|---|
Algorithm | roundrobin, leastconn, source (sticky by client IP), or random. |
Connect / server / queue timeouts | Defaults: 5000ms / 30000ms / 30000ms. |
Retries | How many times to retry a failed connection to a server (default 3). |
Redispatch | If a retry happens, allow it to land on a different server rather than retrying the same one. |
Session persistence | Cookie-based "sticky sessions," so a given visitor keeps hitting the same server. Configurable cookie name (default SRVID). |
Path-based server routing
For finer control than "balance across all servers everywhere," you can define routing groups: one or more URL paths routed to a specific server (or subset of servers), optionally with their own load-balancing settings that override the domain-wide ones. Useful for e.g. sending /api/* to a different server than everything else.
By default, any path not covered by a routing group still falls through to normal domain-wide balancing. Turning on "Restrict to defined paths" changes that: any path outside your defined groups is rejected instead — use this only once you're confident every path you need is actually covered.
🛡️WAF & Security
The Web Application Firewall inspects requests before they reach your origin, based on the OWASP Core Rule Set.
| Field | What it does |
|---|---|
WAF enabled | Master on/off switch for inspection on this domain. |
Mode | Block — actively rejects malicious requests (HTTP 403). Detection Only — logs matches without blocking, useful for tuning before you turn blocking on. |
Paranoia level | 1 (least strict) – 4 (most strict). Higher levels catch more attacks but raise the chance of flagging legitimate traffic. Start at 1 and raise it only if you need to, checking WAF Events in Analytics for false positives as you go. |
SQL injection protection | On by default. |
XSS protection | On by default. |
Custom rules | Free-text field for your own Coraza SecRule syntax, evaluated alongside the standard rule set. |
🚫IP Access Rules
Block specific IP addresses or CIDR ranges from reaching a given path on your domain.
- CIDR / IP — a single address or a range, e.g.
203.0.113.0/24. - Path prefix — must start with
/. A single*wildcard is supported for glob-style matching. Use/to block that IP from the entire domain.
IP rules are always block-only, and take priority over redirect/rewrite rules on the same path.
🌍Geo Blocking
Allow or block traffic by country, per path.
- Path prefix — which part of your site the rule applies to.
- Mode — Block the listed countries (everyone else allowed), or Allow only the listed countries (everyone else blocked).
- Countries — one or more ISO country codes.
↪️Redirects & Rewrites
| Field | What it does |
|---|---|
Type | Redirect sends the visitor's browser to a new URL (a real HTTP redirect). Rewrite serves different content at the same URL the visitor requested, transparently. |
Match path / type | An exact path or a path prefix to match. |
Target | For rewrites: a relative path on your own site. For redirects: a relative path, or a full https://… URL to send visitors elsewhere entirely. |
Redirect code | 301 (permanent), 302/303/307/308 — redirects only. |
⏱️Rate Limiting
Caps how many requests a single client can make to a path in a given time window. Clients over the limit get HTTP 429 until the window resets.
- Path prefix — which part of your site this rule protects.
- Window —
10,60, or300seconds (these are the only supported windows). - Max requests — 1 to 100,000, per client, within that window.
A common pattern: a tight limit on a login or search endpoint, left wide open (or unset) elsewhere.
🤖Bot Challenge
Presents an automated JavaScript challenge to suspicious visitors before letting the request through — helps filter out scripted/bot traffic without a CAPTCHA.
- Path prefix — which part of your site to protect.
- Mode — Heuristic only challenges requests missing basic browser signals (e.g. no User-Agent or Accept-Language header); Always challenges every single visitor to that path, regardless of how legitimate they look — best reserved for sensitive endpoints like a login page, since it adds friction for every real visitor too.
🚧Maintenance Mode
Temporarily take a domain (or a specific path on it) offline for visitors, without touching your actual configuration.
| Field | What it does |
|---|---|
Match path / type | Which part of the domain is affected — exact or prefix match, defaults to the whole domain (/). |
Mode | Message shows visitors a maintenance page with your custom text (up to 500 characters). Redirect sends them to another URL instead. |
Enabled | Instant manual on/off switch. |
Schedule (optional) | A start/end time window that turns maintenance mode on and off automatically, independent of the manual switch. |
Reach this from Quick Actions → 🚧 Maintenance Mode, or the toggle on the domain's Edit Configuration screen.
Plans & Limits
| Basic | Pro | |
|---|---|---|
| Domains | 1 (+1 redirect-only, see below) | 10 |
| Rules per type, per domain (IP / geo / path / rate-limit / bot-challenge, each counted separately) | 10 | 50 |
| Additional backend servers | — | ✓ |
| Staging deploys | — | ✓ |
| Real-time alerts | — | ✓ |
On Pro, the Domains limit counts every domain on your account, including redirect-only ones. On Basic, redirect-only domains have their own separate allowance instead — see Redirect-Only Domains.
Your platform administrator can also set a lower global rule cap that applies to everyone regardless of plan — if you're hitting a rule limit below your plan's normal number, that's why.
Manage your subscription any time from Quick Actions → 💳 Billing.
Team & Roles
Invite teammates from Quick Actions → 👥 Manage Team. Three roles:
- Owner — full access, including managing the team itself and billing.
- Admin — full access to domains and configuration, but can't manage team members.
- Viewer — read-only access to everything, can't make changes.
Analytics & Logs
Quick Actions → 📊 View Analytics gives you, per domain, over 1h/6h/24h windows: request volume, response codes, bandwidth, and top client IPs, plus two searchable/filterable sections:
- WAF Events — every request the WAF flagged or blocked, useful for tuning paranoia level and confirming rules aren't over-blocking real traffic.
- Traffic Logs — raw request logs, retained 14 days.
Quick Actions → 📜 Audit Log shows a read-only trail of account activity (who changed what, and when).
Troubleshooting
My changes aren't showing up on my live site
Check that you actually deployed the revision containing your changes to production (see Revisions & Deploy) — editing a draft never touches live traffic by itself.
I can't deploy to production
Production deploys require the domain to be verified first. Check the DNS tab for your verification status.
I can't deploy to staging / add a second backend server
Both require the Pro plan — see Plans & Limits.
I'm being blocked by "No open draft revision"
Your last revision was already deployed and is now frozen. Open a new one from Quick Actions → 🚀 Revisions & Deploy before making further changes.
Legitimate visitors are being blocked
Check Analytics → WAF Events for what matched. Consider lowering the paranoia level, or running in Detection Only mode temporarily while you investigate.
I don't see Origin, WAF, or rules tabs for one of my domains
That domain is set up as redirect-only, which has nothing to configure there. Its Edit Configuration screen only shows Redirect and DNS tabs. You can convert it to a full origin domain from the Redirect tab if you need those features.