Access controls and maintenance
Restrict public requests by IP address or temporarily serve a maintenance page without stopping the application.
Web services and static sites have public routing settings for IP restrictions and maintenance responses. These settings apply to their public HTTP and HTTPS hostnames, including the generated Openstead address and attached custom domains.
Restrict requests by IP address
Open the service's Settings → Networking → Allowed IP addresses. Enter one IP address or CIDR range per line, then save.
For example, 203.0.113.10/32 represents one IPv4 address and 203.0.113.0/24 represents a range. These are documentation examples: use the actual public egress addresses of your office, VPN, or intended client.
An empty list allows public access. A nonempty list permits requests only from matching sources. Confirm your own source address is included before applying a restrictive list, and test from both an allowed and a disallowed connection.
The routing layer evaluates the source address it sees. If traffic arrives through another proxy, its outgoing IP ranges may be the visible source. A forwarded header supplied by an arbitrary client is not a reason to trust that client's claimed address.
IP restrictions complement application authentication. They do not grant logged-in application access or replace password, token, and permission checks. Domain verification still follows the direct-DNS requirements in Custom domains.
Wait for routing confirmation
Saving an IP restriction or maintenance change queues a routing update. You do not need to rebuild the application for these settings.
Wait for Routing settings applied before assuming a policy is active. If the update cannot be confirmed, inspect the displayed message and use Retry routing update. A saved form value alone is not evidence that the proxy applied it.
For an undeployed service, routing settings apply when the service first deploys.
Turn on maintenance mode
On an eligible paid instance, open Settings → Maintenance Mode and enable the switch. Once routing is applied, visitors receive a maintenance page with HTTP 503.
The application keeps running. Maintenance mode changes public routing; it does not suspend compute, stop workers, pause cron jobs, or prevent private-network access. If you need to stop all writes for a database migration, coordinate every writer separately.
Disable maintenance mode and wait for the routing confirmation to restore normal public requests. Test a representative request afterward.
Supply a custom maintenance page
Set Custom Maintenance Page to a public HTTPS URL that returns 200 with Content-Type: text/html. The page must fit within 256 KiB and be accessible without login.
Use a self-contained document with inline styles. Scripts are disabled in the served maintenance page. The responder permits inline styling and images from HTTPS or data URLs; do not depend on a frontend bundle, remote stylesheet, or the unavailable application's asset routes.
Openstead fetches the page when applying routing and serves it with HTTP 503, not as a redirect to the external URL. If the custom page cannot be loaded, Openstead uses its default maintenance page and reports the fallback.
Keep the page on a location that remains available during maintenance. Do not use a URL that depends on the same unavailable application to deliver its content.
Troubleshoot access
If a legitimate request is denied, check its actual source IP, the CIDR syntax, any proxy in the path, and whether the latest routing update succeeded. For a page that remains in maintenance, check the switch and the applied status separately.
Private database ports are not exposed by these settings. Use private networking and the database's own credentials for internal connections.