Security Groups
Introduction
A security group is a named set of firewall rules you attach to a VM. Each rule says "allow this traffic" — for example allow SSH from my office IP or allow TCP 8000 from my VPC. Anything a rule doesn't allow is blocked.
By default a Jarvislabs VM has no security group, which means every port on its public IP is reachable from the internet. Security groups are how you narrow that down.
Use them when you want to:
- Lock SSH and your app ports to your own IP, your office, or your VPN.
- Expose exactly one port publicly (an inference endpoint, say) and nothing else.
- Reuse the same policy across several VMs, and change it in one place.
- Restrict what your VM is allowed to reach on the way out.
Editing a rule takes effect immediately. No reboot, no reconnect — even an open SSH session survives the change.
Availability
| Workspace type | VMs only — GPU VMs and CPU VMs. Not available for container instances. |
| Regions | IN1 and IN2. |
| Traffic covered | Your VM's public interface (eth0). Private VPC traffic on eth1 is not filtered by security groups — a VPC is already sealed off from everyone else. |
| IP version | IPv4. |
Container instances don't appear in this feature at all — the Security tab is simply absent for them. Their notebook and IDE URLs are served through the Jarvislabs proxy rather than directly off a public IP, so port rules wouldn't describe what they actually expose.
How a security group works
A security group filters traffic on your VM's public interface. Each packet is checked against the group's rules: if a rule allows it, it passes; otherwise it is dropped.
Rules are allow-only
There is no deny rule. Anything not explicitly allowed is blocked. To close a port, delete or narrow the rule that opened it.
Inbound and outbound
- Inbound — traffic arriving at the VM.
Sourceis where it may come from. - Outbound — traffic the VM sends.
Destinationis where it may go.
Inbound starts closed: once a group with inbound rules is attached, only the listed sources
and ports can reach the VM. Outbound starts open: every new group has an
All traffic → Anywhere outbound rule. Edit or delete it to restrict outbound.
No inbound rules means unrestricted
A VM is fully reachable from the internet when it has no group attached, when the attached group has no rules, or when it has no inbound rule. Protection comes from inbound rules, not from attaching a group. Detaching every group is never a lockout.
Always allowed
- Return traffic for any allowed connection, in both directions.
- DNS (53) and NTP (123) outbound, regardless of your outbound rules.
Changes apply immediately
Rules are enforced on the VM's network port, not inside the VM. Edits take effect at once with no reboot or reconnect.
Anatomy of a rule
| Field | Meaning |
|---|---|
| Direction | Inbound or Outbound. |
| Type | SSH (TCP 22), Custom TCP, Custom UDP, Ping (ICMP), or All traffic. |
| Port | Custom TCP/UDP only. A single port (22) or a range (8000-8010), 1–65535. |
| Source (inbound) / Destination (outbound) | My IP (inbound only), Anywhere (0.0.0.0/0), or a custom CIDR such as 203.0.113.4/32 or 10.0.0.0/8. |
- A bare address means
/32. - Host bits are ignored:
10.1.2.9/24is10.1.2.0/24. - IPv4 only. IPv6 CIDRs are rejected; inbound IPv6 is denied once a group with inbound rules is attached.
- The API additionally accepts
sctp,gre,esp,ah, any IP protocol number0–255, and ICMP type/code.
Creating a security group
Go to Security Groups in the dashboard sidebar (jarvislabs.ai/dashboard/security-groups).
- Click Create security group.
- Give it a name. A suggestion like
crabby-relayis pre-filled; replace it with something you'll recognise, e.g.office-onlyorpublic-inference. - Pick the region. A group belongs to one region and can only be attached to VMs in that same region. If you work in both, create the group twice.
- Add rules — or take the shortcut below.
- Click Create.
The "Recommended" starting point
The create dialog offers a one-click recommended rule set:
- SSH (TCP 22) from your current IP
- Ping (ICMP) from your current IP
That's a large security improvement over the default for almost no thought: you can still reach and diagnose your box, and nobody else can knock on its SSH port.
Wherever a Source is asked for, there's a My current IP button. It fills in the public
address you're browsing from, as a /32. This is resolved by Jarvislabs — your browser can't
see your own public address — so it's the address the VM will actually see.
If your ISP gives you a dynamic address, or you connect from more than one place, prefer your
office/VPN range (e.g. 203.0.113.0/24) over a single /32, or you'll be editing this rule
often.
Notebook and IDE ports
Jupyter, VS Code and similar template URLs are served through the Jarvislabs proxy, not straight off your VM's public IP. Adding an inbound rule for port 8888 is therefore not what keeps your notebook working — and removing it won't break it. Write rules for the ports you serve on the public IP.
Attaching a group to a VM
- Open the VM from Instances and go to its Security tab.
- Under Effective access, click Add group and pick a group.
- It applies immediately.
A VM can hold up to 5 groups. Only groups in the VM's own region are offered.
The Effective access view
This is the most useful thing on the page. It flattens every rule from every attached group into a single inbound table and a single outbound table, deduplicated — which is exactly what is enforced. Because groups combine as a union, no individual group's rule list tells you what actually applies; this table does.
It also raises two warnings you should take seriously:
- "Not restricted — all inbound traffic is allowed" — the VM is open to the internet. See No inbound rules means unrestricted.
- "Your outbound rules are not being applied" — at least one attached group has rules but no outbound rules, which keeps outbound wide open for the whole VM and overrides the outbound rules in your other groups. Either add matching outbound rules to that group, or detach it.
Detaching
Remove a group from the VM with the × on its row. If it was the last one, the VM returns to the platform default: fully reachable. Detaching is never a lockout.
Editing rules
Open a group on the Security Groups page and edit its rules inline. Changes are saved as a set and pushed to every VM the group is attached to, immediately.
The editor validates as you type and flags things that are legal but probably not what you meant:
| The editor says | What it means |
|---|---|
| Already allowed by inbound rule 1 …, so this rule changes nothing | A wider rule above already covers this one. In an allow-only model, adding a narrow rule under a wide one changes nothing — the classic "I restricted it and nothing happened". |
| Same as inbound rule 2 — delete one | An exact duplicate. |
| Opens every TCP port | You left the port field empty on a TCP/UDP rule. |
| Reachable from the entire internet | An inbound rule for SSH, a notebook port, or all traffic, with source Anywhere. |
| Host bits are ignored — this covers 10.1.2.0/24 | Your CIDR isn't a network address. Harmless, but not what the text says. |
| A /0 prefix matches the entire internet, whatever address you typed | 1.2.3.4/0 is 0.0.0.0/0. |
These are warnings, not blockers — you can save anyway.
Deleting a group
Deleting a group removes it from every VM it was attached to. Those VMs keep whatever other groups they hold; a VM left with none returns to being fully reachable.
Worked examples
Lock a VM down to your office
One group, attached to the VM:
| Direction | Type | Port | Source / Destination | Description |
|---|---|---|---|---|
| Inbound | SSH | 22 | 203.0.113.0/24 | Office |
| Inbound | Ping (ICMP) | — | 203.0.113.0/24 | Office |
| Outbound | All traffic | — | Anywhere | Allow all outbound |
Everything else arriving from the internet is dropped.
Publish one inference endpoint, keep SSH private
| Direction | Type | Port | Source / Destination | Description |
|---|---|---|---|---|
| Inbound | SSH | 22 | 203.0.113.0/24 | Office |
| Inbound | Custom TCP | 8000 | Anywhere | Public inference API |
| Outbound | All traffic | — | Anywhere | Allow all outbound |
You could also split this into two groups — office-ssh and public-api — and attach both.
The result is identical, and the second group is then reusable on other VMs.
Restrict outbound traffic
Replace the default outbound rule rather than adding to it:
| Direction | Type | Port | Destination | Description |
|---|---|---|---|---|
| Outbound | HTTPS | 443 | Anywhere | Package installs, model downloads |
| Outbound | Custom TCP | 5432 | 10.20.0.0/20 | Database on the VPC |
DNS and NTP keep working regardless. Remember the union rule: if any other group attached to this VM has rules but no outbound rules, outbound stays wide open and the table above does nothing. The Security tab warns you when that happens.
Limits
| Limit | Value |
|---|---|
| Security groups per account | 20 |
| Rules per group | 50 (inbound and outbound combined) |
| Groups per VM | 5 |
Troubleshooting
I attached a group and nothing is blocked. Check the Security tab for the "pause and resume" banner — a VM whose current session predates the feature can't enforce rules until it has been cycled once. Otherwise, check that the group actually has an inbound rule: a group with none leaves inbound open.
I locked myself out of SSH. You can't be locked out permanently. Go to the Security tab and detach the group, or edit the rule from the Security Groups page — changes apply immediately and you don't need access to the VM to make them. Adding your current IP with My current IP is usually the fastest fix; a changed home/ISP address is the most common cause.
My outbound rules aren't doing anything. Another attached group has rules but no outbound rules, which keeps outbound open for the whole VM. The Security tab names the group. Add outbound rules to it, or detach it.
I narrowed a rule and nothing changed. A wider rule elsewhere — in the same group, or in another attached group — still allows the traffic. Read the Effective access table, not the individual group.
Attaching returns "Workspace is still starting". The VM hasn't finished provisioning. Wait for it to reach Running and try again.
Attaching says the group is in the wrong region. Groups are region-scoped. Create an equivalent group in the VM's region.
FAQ
Does this cover my private VPC traffic? No. Security groups filter the public interface. Traffic inside a VPC is already private to you and isn't filtered.
Do I need a rule for return traffic? No. Replies to allowed connections are admitted automatically, in both directions.
Do rules survive pause and resume? Yes. Group membership belongs to the workspace, not to a particular session, so a paused VM still shows its groups and comes back with them applied. There's nothing to re-apply.
Do rules survive a public IP change? Yes. The VM's public IP can change on resume; its security groups follow the workspace, not the address. (If you need the address itself to be stable, see Reserved IP.)
Can I write a deny rule? No. The model is allow-only. To deny something, don't allow it — and make sure no other attached group allows it either.
Can I allow traffic "from my other VMs" by naming a group? Not yet. Sources and destinations are CIDRs. For VM-to-VM traffic, put the VMs in a VPC and use their private range.
Are containers supported? No, and there's no plan to add them on this path. Security groups are for VMs.
Is IPv6 supported? No. Rules are IPv4, and once a group with inbound rules is attached, inbound IPv6 is denied.