Skip to content
CivoCloudManager

Open a Civo firewall for your IP, then close it again.

The manual procedure, the dynamic-IP trap it leaves behind, and a free menu-bar path that closes the rule on a deadline.

You need to reach a Civo instance or a cluster API from where you are sitting right now. The answer is one firewall rule: find your public IPv4, then allow the port from that single address by writing the CIDR as /32. Civo makes the first half easy and the second half dangerous, because a rule you add by hand stays there until somebody deletes it. This page shows the manual procedure in full, then the part almost nobody handles: closing it again.

The same rule, opened from the menu bar

  1. 01

    Tell the app which firewalls you manage

    On first launch the menu bar shield runs onboarding: enter the Civo API key, which goes into the macOS Keychain, choose a region, and select the firewalls you want to control. Each selected firewall gets a port, and that field starts at 6443.

  2. 02

    Let it find your public IPv4

    Detection runs against api.ipify.org first, then ifconfig.me/ip, then icanhazip.com, and stops at the first provider that answers with a valid public address. An IPv6 answer or a private address is rejected with a message instead of being written into a rule, because Civo firewall rules need an IPv4 CIDR.

  3. 03

    One click writes the rule

    The app creates an ingress rule on the chosen port with the CIDR set to your detected address plus /32, labelled civo-cloud-<hostname>-<firewall-name>. Civo returns the exact rule ID in the create response, so the app never has to guess later which rule was its own.

  4. 04

    Pick how long it stays open

    Timed access offers 15 minutes, 30 minutes, one hour and two hours. There is also Unlimited, which opens the rule and schedules no closure at all, so choose it only when you intend to close the rule yourself.

  5. 05

    The deadline is written to disk

    Each closure job holds the firewall ID, rule ID, region and deadline, and is written atomically to firewall-closures.json in the app's Application Support directory. Quit the app and the deadline is still there: on the next launch overdue jobs are closed without the popover ever opening. The honest limit is that the app has to be running and able to reach Civo to delete a rule. Quitting or sleeping does not schedule a server-side deletion.

  6. 06

    Save the address as a named preset

    Store the current IP under a name such as Home or Office and open a firewall for that preset later without re-detecting. Useful when you want to open access for a static office address while sitting somewhere else.

What a new Civo firewall actually does

Civo's API documentation is explicit: there is no allow or deny choice when you create a rule, because the default for a new firewall is to deny everything, so you only open the ports you need. A firewall you create yourself therefore starts closed and every rule you add is an allow rule. The trap is the other one. Every region ships a firewall literally named Default (all open), and Civo's own docs say it has all ports open and recommend you customise it. So the correct answer to the question people keep asking is: your own firewall denies by default, the region's Default firewall does not.

The manual procedure, in full

First, get your public IPv4: curl -s https://api.ipify.org. Second, add the rule. With the Civo CLI that is civo firewall rule create <firewall_id> --protocol=TCP --startport=6443 --endport=6443 --cidr=203.0.113.42/32 --direction=ingress --label='laptop'. Third, and this is the part people skip, note the rule ID that comes back so you can delete it afterwards. Watch the defaults: leave --cidr out and the CLI applies 0.0.0.0/0, which opens the port to the entire internet rather than to you. The dashboard route is the same shape: Actions, then Rules, then a single port or a range, protocol, direction and the CIDR.

The rule outlives the reason you added it

A Civo firewall rule has no expiry. It stays until a human or an API call removes it. On a business line with a static address that is merely untidy. On a home connection it is a real exposure, because most consumer ISPs rotate the address on reconnect or on a nightly lease renewal. The /32 you allowed is then handed to someone else's router, and your rule is now allowing a stranger through to port 6443 while you are locked out and writing a second rule. Every hand-written rule is a small piece of debt, and the debt is only paid when you remember to delete it.

Why the app can never delete a rule you wrote

Ownership is decided by the label, not by the port or the address. The app only creates rules labelled civo-cloud-<hostname>-<firewall-name>, and rules opened for a Kubernetes API connection carry the k8s-api suffix instead. Bulk Close All lists the rules on each managed firewall and removes only those whose label starts with that prefix for this machine. A hand-written production rule has no such label, so it is never a candidate. One caveat worth stating: a failed status lookup still renders as closed or unknown in the menu bar, so the display is not proof of server-side closure. Check the Civo dashboard when it matters.

Port 6443 and why it keeps coming up

6443 is the Kubernetes API server port. A Civo k3s cluster publishes its endpoint as https://<master-ip>:6443, which is what kubectl, a kubeconfig and any Kubernetes client talk to. If the cluster firewall does not allow 6443 from your address, every command times out, which is why that number dominates Civo firewall searches. In the app, 6443 is the default port in onboarding, and connecting to a cluster checks API access and opens the rule for you if it is missing. That Kubernetes path tracks its rule in memory and cleans up on disconnect; it does not inherit the persistence and retry behaviour of the timed menu bar queue.

Questions people actually ask

How do I open a Civo firewall for just my IP?
Get your public IPv4 with curl -s https://api.ipify.org, then create an ingress rule on the target firewall with that address written as a /32 CIDR. With the Civo CLI: civo firewall rule create <firewall_id> --protocol=TCP --startport=6443 --endport=6443 --cidr=203.0.113.42/32 --direction=ingress. There is no allow or deny choice in the API, because a firewall you create denies everything until you open a port. Keep the returned rule ID so you can delete the rule afterwards.
What does /32 mean in a Civo firewall rule?
In CIDR notation the number after the slash is how many leading bits of the address are fixed. An IPv4 address is 32 bits, so /32 fixes all of them and the rule matches exactly one address. 203.0.113.42/32 is that host and nothing else. For contrast, /24 would cover 256 addresses and 0.0.0.0/0 covers the whole internet, which is what Civo applies when you create a rule without a CIDR.
What happens if my IP address changes?
The rule does not change with you. It keeps allowing the old address, so you lose access and have to add a second rule, while whoever the ISP hands that address to next inherits your opening. This is the normal case on home connections, where the address usually rotates on reconnect or on a nightly lease renewal. The fix is not a better IP, it is a rule that closes itself: open the port for a fixed window and let the deadline remove it.
Will CivoCloudManager touch my existing firewall rules?
No. It only deletes rules it created itself, identified by the label civo-cloud-<hostname>-<firewall-name>, with the k8s-api suffix for Kubernetes API access. Bulk Close All filters every managed firewall's rule list by that prefix before deleting anything, so a rule you wrote by hand in the Civo dashboard, the CLI or Terraform has no matching label and is never removed.
Does the auto-close timer survive quitting the app?
The deadline does. Each job stores the firewall ID, rule ID, region and closing time in an atomically written JSON file under Application Support, and overdue jobs are closed on the next launch. What does not survive is unattended closure: the deletion is an API call from your Mac, so the app has to be running and able to reach Civo. Quitting or sleeping past the deadline delays the closure until you launch the app again, it does not schedule anything server side.

Guides

Step by step, and honest comparisons.

Deep dives

Targeted reads for each Civo product.

Every Civo surface CivoCloudManager touches has its own page with the specifics, the trade-offs, and the architecture details. Pick the one closest to what you do today.

Firewall control is the free tier.

Menu bar open and close for your current IP, named presets and the auto-close deadline stay free after the seven-day full-access trial ends, so this page costs you nothing to act on.

Download on the Mac App Store

Requires macOS 15 (Sequoia) or newer.

Back to the CivoCloudManager overview