The Cloud Instance Firewall

Every cloud instance has its own firewall, a packet filter that sits in front of the instance and decides what traffic reaches it. You write rules by protocol, port and source, turn the firewall on, and only what you allow gets through. It is separate from anything running inside the instance, so a rule here holds even if the guest's own firewall is off.

How a rule works

A rule has a direction (inbound or outbound) and an action: accept, drop (discard silently) or reject (refuse and say so). You narrow what it matches with three optional filters:

• A protocol: tcp, udp or icmp.
• A port or port range, such as 443 or 8000:8100. A port only makes sense with a protocol, so set the protocol too.
• A source, a single IP address or a CIDR range, to limit who the rule applies to.

Rules are evaluated in order, and each carries an optional comment so you remember why it is there.

Turning it on without locking yourself out

The moment a firewall is enabled, anything not allowed is blocked, and the classic mistake is to enable a filter that drops your own SSH. To prevent that, the first time you enable the firewall we add one rule for you: inbound, accept, TCP port 22. It keeps SSH reachable so you cannot lock yourself out while you build your rule set. Once your own rules are in place and you have confirmed access, you can remove that keep-alive rule.

In the portal

Open the instance from Cloud, go to Network, and find the Firewall panel. Add rules with direction, action, protocol, port and source; each rule lists with a position and a remove control. A switch enables or disables the whole firewall. Build your rules, confirm you still have access, then enable.

With the API

Reading needs read; changing rules needs the VMs scope (vms.write). Read the current state, add a rule, remove one by its position, and toggle the firewall:

curl -s https://api.amoni.app/v1/vms/990204/411/firewall \
  -H "Authorization: Bearer nr_live_..."
# { "success": true, "data": {
#   "enabled": true,
#   "rules": [ { "pos": 0, "direction": "in", "action": "ACCEPT",
#                "proto": "tcp", "port": "22", "source": null, "comment": "SSH" } ] } }

# allow HTTPS from anywhere
curl -s -X POST https://api.amoni.app/v1/vms/990204/411/firewall \
  -H "Authorization: Bearer nr_live_..." -H "Content-Type: application/json" \
  -d '{"direction": "in", "action": "ACCEPT", "proto": "tcp", "port": "443", "comment": "web"}'
# { "success": true, "data": { "message": "Rule added." } }

# restrict SSH to your office range
curl -s -X POST https://api.amoni.app/v1/vms/990204/411/firewall \
  -H "Authorization: Bearer nr_live_..." -H "Content-Type: application/json" \
  -d '{"direction": "in", "action": "ACCEPT", "proto": "tcp", "port": "22", "source": "203.0.113.0/24", "comment": "office SSH"}'

# remove the rule at position 0
curl -s -X DELETE https://api.amoni.app/v1/vms/990204/411/firewall/0 \
  -H "Authorization: Bearer nr_live_..."

# turn the firewall on (or off with false)
curl -s -X PUT https://api.amoni.app/v1/vms/990204/411/firewall/enable \
  -H "Authorization: Bearer nr_live_..." -H "Content-Type: application/json" \
  -d '{"enabled": true}'

Two rules are enforced on what you send. A port without a proto answers 422 with code port_needs_proto, because a port means nothing to the filter without a protocol. A source that is not an IP or CIDR answers 422 invalid_source. Enabling the firewall for the first time adds the SSH keep-alive rule described above before it turns on.

A safe starting set

For a typical web instance: allow inbound TCP 22 from your own address, allow inbound TCP 80 and 443 from anywhere, and leave everything else to be dropped by default once the firewall is on. Confirm SSH still works, then remove the automatic keep-alive rule if your own SSH rule covers it.

Questions we get

• Drop or reject? Drop discards the packet with no reply, so a scanner sees nothing. Reject sends a refusal, which is friendlier for your own clients. Use drop for the internet, reject where a quick failure helps.
• Why is there an SSH rule I did not add? It is the keep-alive added on first enable so you cannot lock yourself out. Remove it once your own rules cover access.
• Does this replace the firewall inside my instance? No, it sits in front of it. You can run both; this one holds even if the guest's is off.
• Can I filter outbound traffic? Yes. Set direction to out. Most setups only filter inbound, but the option is there.
• Do bare-metal servers have this? This is a cloud-instance feature. For bare metal under attack, see DDoS protection and blackholing.

Still stuck?

Open a support ticket with the instance and the rule you are trying to add, and we can see what the filter accepted.