How it works

Project firewall: allow and deny by IP and port

The person who registered the account is the owner and already has full access. The site starts open: HTTP 80 and HTTPS 443 accept any visitor. You do not need a support ticket to “unlock the site”. In the dashboard, under Project → Firewall, close ports or restrict IPs whenever you want.

The firewall decides who reaches your app from the internet. It works like a server firewall: each rule has an action (Allow or Deny), a source (IP or range), a protocol (TCP), a port and a free label so you remember why it exists. It is not a WAF: it does not inspect request bodies.

The ports that reach the app are 443 (HTTPS) and 80 (HTTP). Every other container port is already closed to the internet and needs no rule. Customers have no SSH access to the servers, and it is not controlled here.

1. Before opening a ticket

   If the site does not open for some IP, or you want to restrict who can reach it, open the project → Firewall. Default rules already allow 80 and 443. Close a port or limit the source yourself; support does not need to do this for you.

2. Default rules

   Every project starts with two rules: Allow 443 (HTTPS) and Allow 80 (HTTP) from 0.0.0.0/0 and ::/0, that is, any IP. That is the minimum for the site to load. From there you add Deny rules or change the source to restrict. If you delete a port’s rule, that port stays open: the site never goes offline for lack of a rule.

3. Allow closes everything else

   Once a port has at least one Allow rule, only the allowed sources get in; everyone else gets 403 (Forbidden). To open to everyone, allow 0.0.0.0/0 (any IPv4) and ::/0 (any IPv6).

4. Deny always wins

   A Deny rule removes that source even if another rule allows it. Example: Allow 0.0.0.0/0 and ::/0 on 443 plus Deny 45.10.20.0/24 keeps the site open to everyone except that range.

5. Port 80 and 443

   Choose 443 (HTTPS), 80 (HTTP) or both. Port 80 only redirects to 443, so restricting 443 is enough to restrict the site. Automatic certificate renewal keeps working with any rule.

6. Applied in seconds

   When you save, the rule is applied to the router in front of the app within seconds, without a new deploy. The top of the screen shows whether and when it was applied. Pausing a rule turns it off without deleting it.

7. The visitor’s IP is what counts

   Traffic crosses Devora’s internal network before the app. The firewall skips those internal hops and reads the real IP of the visitor. A forged X-Forwarded-For header does not fool the rule. The My IP button adds the address you are using the dashboard from right now.

• Accepted sources: IPv4 (200.10.20.30), IPv4 range (200.10.20.0/24), IPv6 (2001:db8::1) and IPv6 range (2001:db8::/32). Up to 50 sources per rule and 50 rules per project.
• Who can change it: Developer, Admin and Owner roles, or a custom role with the Manage firewall permission. View firewall only reads.
• Every rule created, changed or removed goes to the organization’s Audit log with who did it, when and from which IP.
• Careful when allowing only the office: anyone outside that network (phone on 4G, travelling) cannot open the site. Add those IPs or restrict only the path of people who need it.
• The public port of the database is not controlled by this screen yet; external database access is turned on under Databases and stays private-network only until enabled.
• When opening a ticket about the firewall, include the rule label, the IP that cannot connect and the message at the top of the Firewall screen.
• The registrant already has the site online: default Allow 80 and 443 from any IP already apply. Restrictions are optional and set in the dashboard.