Who can open your app (IPs, password)

By default, anyone on the internet can open your app. That is right for a public website, and wrong for an internal tool, a staging site, or an admin area. Who can open this app on your project's Dashboard lets you limit it, without touching your code and without taking the app offline.

What you can choose

For the app as a whole, or for one address of it, you pick one of:

• Anyone: open to the whole internet, as it is by default.
• Only approved people, using either or both of these ways in:
  • Approved networks: addresses or ranges (IPv4 or IPv6) such as your office, a VPN, or a contractor's address. Anyone coming from somewhere else is turned away.
  • A password: one shared user name and password, asked for by the browser.

If you turn on both, choose what a visitor needs: either one (people on an approved network walk straight in, everyone else enters the password) or both (an approved network and the password).

Saved IP groups

If several apps share the same office or VPN addresses, save them once as a group (for example "Office") and tick it on each app. When an address changes, update the group and every live app that uses it is updated for you. Owners and admins manage groups; anyone allowed to change an app's access can use them.

Pages that stay open

By default your app's health check stays reachable by everyone, so uptime monitoring and deployment checks can see your app rather than just the access rule. You can keep other pages open too, such as a webhook (/webhooks/stripe) or a public API (/api). A page only counts as open when its address is plain: an address with %, ;, \ or .. in its path is never treated as open, because some servers read those differently from the web server in front of them.

You can also protect only some pages (such as /admin) and leave the rest open. That is weaker: a server may read an unusual-looking address in a way the web server did not expect. When you can, protect the whole site and keep a few pages open instead.

What a blocked visitor sees

Choose a Forbidden page (the default), a Not found page, or nothing at all (the connection is closed). A visitor who is asked for a password sees the browser's sign-in box.

Setting it up

• When you set up your domain, the Who can open it? card sits under your domains. Rules you save there are used by the first deployment.
• After you are live, open Who can open this app on the Dashboard and choose Restrict access. Every address your project serves is listed with the rule it follows. A domain you add later follows the rule for every address, so a new address is never public by accident.
• Your dashboards and tools (Grafana and the others) have a login of their own, so the rule for every address does not cover them. You can limit one of them to approved networks from the same screen.

Before saving, the screen shows you what the rule means in plain words and lets you try an address to see whether it would get in. If the rule would not let you in from the address you are using now, you are asked to confirm first. You can always change the rule back from the Dashboard: it is never behind the rule itself.

How it is put on your server

The rule is written to the web server on your server, checked by the web server itself before it replaces the old one, switched in without a restart, and then tested from the server the way an outsider would reach it. If any check fails, the previous rule stays in place and the card says why. It runs as a short job you can follow in Deployments, and it never counts against your deployment limit.

If a deployment writes the rules and cannot prove them, the app is closed (403 on every address) until you save them again, rather than left running with rules that may not work.

Because the rule lives in the web server, your HTTPS certificates keep renewing normally.

Good to know

• Behind a CDN or proxy, the web server sees the proxy's address, not the visitor's, so an address rule would block everyone. The screen warns you if your domain does not lead straight to your server. A password still works there.
• A load balancer in front of your servers has the same effect, and its own health checks would be turned away by a password too, so limiting access is not offered for those plans yet.
• No domain yet means plain HTTP, so a password travels in the clear. Connect a domain first, or use approved networks.
• Closing the connection for blocked visitors gives your deployment and uptime checks nothing to read; keep the health check open or show a Forbidden page.
• If a domain you set a rule for is removed, that rule applies to every address until you set another, so a new address is never public by accident.
• A password uses the browser's sign-in header, so API calls that send their own Authorization header are refused unless you keep their path open.
• Apps on a managed service (serverless containers, a CDN, Kubernetes) cannot be limited yet, and the screen says so instead of pretending. Choose a server plan to use this.
• "Private network only" (reachable only from inside your cloud network or VPN) is not available yet.
• Passwords are stored scrambled and can never be shown again. Keep the one you set somewhere safe, or set a new one.