Edge Settings
Every app service can be fronted by the FoundryDB edge gateway. The Domains & Edge tab on an app exposes the full per-app edge configuration, grouped the same way this page is: Routing, Headers, CORS, Access control, Performance, Limits, and Security. This page is a reference for each setting: what it does, when to reach for it, and the gotchas worth knowing before you save.
For background on what the edge is and where it runs, see Edge Overview. For how the fleet stays available and scales, see Resilience and Autoscaling.
How settings are applied
A few rules hold for every setting on this page:
- Saving is a wholesale replace, per field. When you submit a field (say, the redirect list or the header rules), the value you send becomes the complete new value for that field. The edge does not merge your change into what was there before. To add one redirect, submit the full list including the existing entries. The settings form hydrates from the current values so you always start from the live configuration.
- Changes converge asynchronously. A save bumps a configuration version and the edge fleet converges on it across all points of presence. The new settings are live everywhere within a short window, not the instant the call returns.
- Settings apply across all PoPs. There is one configuration per app, served identically from every point of presence.
Routing
Redirects
A redirect maps an incoming request path to a destination URL and returns an HTTP redirect status instead of forwarding to your origin. Each rule has a from_path, a to_url, and a status code (301, 302, 307, or 308).
Use redirects for moved pages, canonical hosts, vanity short links, or sending a retired path somewhere useful. Choose 301/308 for permanent moves (clients and search engines cache them) and 302/307 for temporary ones. The 307 and 308 codes preserve the request method and body, which matters if you ever redirect a non-GET request.
Redirects are evaluated at the edge before the request reaches your origin, so a redirected request never touches your container.
Headers
Header rules
Header rules set or remove headers on requests going to your origin and on responses going back to the client. Use them to add a header your origin expects, strip a header you do not want exposed, or inject a static value without changing application code.
HSTS
HTTP Strict Transport Security tells browsers to only ever reach your domain over HTTPS. You configure max-age (how long, in seconds, the browser should remember the rule), include_subdomains, and preload.
Turn HSTS on once you are confident every path on the domain serves over HTTPS, because the browser will refuse plain HTTP for the full max-age. The preload flag opts your domain into browser preload lists.
preload requires include_subdomains to be set and max-age to be at least one year (31536000 seconds). The platform enforces this, because that is what the browser preload programs require.
Request ID injection
Enable request-id injection and the edge attaches a unique identifier to each request before forwarding it to your origin, and echoes it back on the response. Use it to correlate a single request across edge analytics, your origin logs, and any downstream service.
CORS
Cross-Origin Resource Sharing controls which web origins (other than your own) are allowed to call your app from a browser. You configure allowed origins, allowed methods, allowed request headers, exposed response headers, whether credentials (cookies and authorization headers) are allowed, and a max-age for how long browsers cache the preflight result.
Allowed origins can be a wildcard (*) or a concrete list of origins. Two rules constrain the wildcard:
- Wildcard cannot combine with credentials. A
*origin with credentials allowed is rejected, because browsers themselves forbid that combination. If you need credentials, list concrete origins. - Wildcard cannot mix with concrete origins. Either you allow everything (
*) or you allow a specific list. You cannot do both in one configuration.
Reach for CORS when a browser front end hosted on a different domain needs to call your app's API. If requests only ever come from the same origin, you do not need it.
Access control
IP allow list
The allow list names the client IP ranges permitted to reach your origin.
When the allow list is non-empty, it becomes default-deny: any IP not on the list is blocked. An empty allow list means no allow-list restriction (everyone is allowed, subject to the other access controls). Add your own address before you save a restrictive list, or you can lock yourself out.
IP deny list
The deny list names client IP ranges that are always blocked, regardless of the allow list. Use it to drop known-bad sources without switching to a default-deny posture.
Allowed HTTP methods
Restrict which HTTP methods reach your origin. If your app only serves GET and HEAD, allowing only those methods turns away writes and probes at the edge.
Blocked path prefixes
Block requests whose path starts with a prefix you specify. Useful for hiding an admin path, a metrics endpoint, or any route that should never be reachable from the public internet.
HTTP Basic Auth
Protect the whole app behind a username and password challenge at the edge. Useful for staging environments, internal tools, or anything that should not be publicly readable but does not justify a full auth integration.
You set passwords when you save the configuration, but they are never echoed back. When the settings form hydrates from current values, configured passwords are not returned. To change a password, set a new one. To keep an existing one, leave it unchanged in the form rather than blanking it.
Maintenance mode
Maintenance mode serves a fixed response (a status code and a body you choose) to every visitor instead of forwarding to your origin, with an optional list of bypass IPs that still reach the real app. Use it during a deploy or an incident: visitors see your maintenance page while your own team, on the bypass list, can verify the app behind it.
Performance
Response compression
Enable gzip compression and the edge compresses eligible responses before sending them to the client, reducing bytes over the wire for text, JSON, HTML, and similar content. Turn it on for any app that serves sizable text responses.
Cache rules
Cache rules let cacheable responses be served from the point of presence instead of your origin. You define which path prefixes are cacheable and the time-to-live for each. Repeat requests for a cached path are answered at the edge, so they never reach your container.
Cache static assets and read-heavy public pages. Writes and authenticated requests bypass the cache by design, so you do not have to carve them out manually.
Limits
Max request body size
Cap the size of a request body the edge will accept. Requests larger than the limit are rejected at the edge before reaching your origin, which protects your app from oversized uploads.
Rate limiting
Rate limiting caps how many requests a client can make in a window, protecting your origin from a single noisy or abusive source. It uses a token-bucket model with a configurable rate and burst.
The limiter is exact per point of presence: each PoP enforces the limit against the traffic it serves. When a PoP grows to more than one node, the limit can be backed by a Valkey store so the nodes in that PoP share one counter rather than each enforcing the limit independently.
Security
WAF mode
The web application firewall inspects requests for common malicious patterns, such as SQL-injection and cross-site-scripting shapes, and has three modes:
| Mode | Behavior |
|---|---|
off | The WAF does not inspect requests. |
detect | Matching requests are logged and counted but still forwarded to your origin. |
block | Matching requests are rejected at the edge. |
Start in detect mode. Detect-mode matches show up in analytics under the rule that matched, so you can measure how much traffic blocking would reject before you ever turn it on. Move to block once you are confident the rules are catching what you expect and nothing legitimate.
Edge analytics
The analytics tab on the same app gives you per-request visibility into how the edge is treating your traffic, over selectable 15-minute, 1-hour, 6-hour, and 24-hour windows. It shows:
- Latency percentiles (p50, p95, and p99), so you can see typical and tail response times.
- Requests by status class, so you can spot a rise in errors.
- Cache hit ratio, to see how much traffic the edge absorbs before it reaches your origin.
- Rate-limited requests per second, to see when the limiter is engaging.
- WAF detections by rule, to size the impact of moving the WAF to
block. - Top paths, the busiest routes through the edge.
Next steps
- Edge Overview: what the edge provides and where it runs.
- Resilience and Autoscaling: how points of presence stay available and scale with traffic.