← Back to Dashboard

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.

Deploying to staging doesn't require verification, so you can build and test your full configuration on staging before your domain is verified — only the production deploy target is gated on it.

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:

FieldWhat it does
Redirect TargetScheme 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 Code301 (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.

On Pro, redirect-only domains count against the same domain limit as full origin domains — they aren't free to run, since each still needs a real SSL certificate and a slot on the edge. Basic gets one full origin domain plus one dedicated redirect-only domain, as separate allowances, so your one real site and an apex-to-www redirect (e.g. 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.

Switching to redirect-only permanently removes that domain's backend servers and every IP/geo/path/rate-limit/bot-challenge rule. Switching back to a full origin domain later starts that configuration from scratch — this direction can't be undone.

🚀 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.
There's no "undo deploy" button — to roll back, deploy an earlier saved revision to the environment you want reverted.

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.

FieldWhat it does
Address / PortWhere this server lives.
Weight1–256 (default 100) — higher weight gets proportionally more traffic under weighted balancing.
Max connectionsOptional cap on concurrent connections to this server.
BackupOnly receives traffic if every non-backup server is down. Your primary server can't be marked backup.
TLS to originPer-server HTTPS toggle to this specific backend.
LabelOptional friendly name shown in the UI.
Health check typeSNI (full TLS/HTTP check) or Port (raw TCP reachability only).
Health pathURL path checked for a healthy response, default /health.

Load balancing

Once a domain has 2+ servers, you can configure how traffic is split:

FieldWhat it does
Algorithmroundrobin, leastconn, source (sticky by client IP), or random.
Connect / server / queue timeoutsDefaults: 5000ms / 30000ms / 30000ms.
RetriesHow many times to retry a failed connection to a server (default 3).
RedispatchIf a retry happens, allow it to land on a different server rather than retrying the same one.
Session persistenceCookie-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.

FieldWhat it does
WAF enabledMaster on/off switch for inspection on this domain.
ModeBlock — actively rejects malicious requests (HTTP 403). Detection Only — logs matches without blocking, useful for tuning before you turn blocking on.
Paranoia level1 (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 protectionOn by default.
XSS protectionOn by default.
Custom rulesFree-text field for your own Coraza SecRule syntax, evaluated alongside the standard rule set.
Recommended rollout: enable in Detection Only mode first, review WAF Events in Analytics for a few days to make sure nothing legitimate is being flagged, then switch to Block.

🚫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.
  • ModeBlock the listed countries (everyone else allowed), or Allow only the listed countries (everyone else blocked).
  • Countries — one or more ISO country codes.

↪️Redirects & Rewrites

FieldWhat it does
TypeRedirect 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 / typeAn exact path or a path prefix to match.
TargetFor rewrites: a relative path on your own site. For redirects: a relative path, or a full https://… URL to send visitors elsewhere entirely.
Redirect code301 (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.
  • Window10, 60, or 300 seconds (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.
  • ModeHeuristic 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.

FieldWhat it does
Match path / typeWhich part of the domain is affected — exact or prefix match, defaults to the whole domain (/).
ModeMessage shows visitors a maintenance page with your custom text (up to 500 characters). Redirect sends them to another URL instead.
EnabledInstant 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

BasicPro
Domains1 (+1 redirect-only, see below)10
Rules per type, per domain
(IP / geo / path / rate-limit / bot-challenge, each counted separately)
1050
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.