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 | India-01 and India-02. |
| 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. |
A security group is enforced on the network port your VM gets when it starts. A VM that has been running since before security groups shipped in its region doesn't have that port yet, so attaching a group to it would appear to work and quietly do nothing.
The dashboard detects this and shows a banner on the VM's Security tab telling you to pause and resume the VM once. After that, groups attach and enforce normally, and you never have to do it again. Newly created VMs are ready from the start.
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.
The mental model
Three properties explain almost every question people have. They match AWS security groups, so if you know those, you already know these.
1. Rules are allow-only
There is no "deny" rule. You list what's permitted; everything else is denied by the implicit default. To close something, you delete or narrow the rule that opened it.
2. Groups add together — they never subtract
A VM can hold up to 5 groups, and the policy that applies is the union of all of them.
Attaching a group can therefore only ever widen access. There is no such thing as a "lockdown" group that overrides a permissive one — attach a permissive group alongside a strict one and the result is permissive. If you want to close something down, remove the group or the rule that opens it.
3. No rules means unrestricted, not protected
Three situations look different but behave identically — the VM is fully reachable:
- The VM has no groups attached (the platform default).
- Every attached group has no rules at all (an empty group is treated as "no opinion", not "deny everything").
- No attached group defines an inbound rule.
This matters because it's the opposite of the intuition. Creating a group and attaching it is not itself protection — the protection comes from the group containing at least one inbound rule. The dashboard says so explicitly rather than showing you a reassuring green tick, and detaching every group is never a lockout.
Inbound and outbound
Rules run in both directions:
- Inbound — traffic arriving at your VM.
Sourceis where it comes from. - Outbound — traffic your VM sends.
Destinationis where it goes.
Inbound starts closed the moment a group with inbound rules is attached. Outbound
starts open: every group you create arrives with a visible All traffic → Anywhere outbound
rule. Narrowing outbound means editing or deleting that rule — deliberately, so the feature
can never silently cut a working VM off from the internet.
What's always allowed, whatever you write
- Return traffic. Replies to a connection you allowed are always admitted, in both directions. You never write a rule for the reply.
- DNS and NTP. Name resolution (port 53) and time sync (port 123) survive any outbound policy you write. A hand-written egress rule set that forgot DNS is the single most common self-inflicted outage, so the platform keeps those open for you.
Anatomy of a rule
| Field | Meaning |
|---|---|
| Direction | Inbound or Outbound. |
| Type / protocol | A preset (SSH, Jupyter, HTTP, HTTPS, Ping) or Custom TCP / Custom UDP / All traffic. |
| Port | A single port (22) or a range (8000-8010). Left empty means every port. Not applicable to Ping (ICMP) or All traffic. |
| Source (inbound) / Destination (outbound) | A CIDR — 203.0.113.4/32 for one address, 10.0.0.0/8 for a range, or Anywhere (0.0.0.0/0). |
| Description | Free text, for your own benefit. Strongly recommended: in six months TCP 7860 ← 198.51.100.0/24 means nothing without it. |
A few details worth knowing:
- A bare address is treated as
/32— a single host. - Host bits are ignored:
10.1.2.9/24covers10.1.2.0/24. The editor tells you when you've done this. - The dashboard offers TCP, UDP, ICMP and "All traffic". The API additionally accepts
sctp,gre,esp,ahand any raw IP protocol number0–255— useful if you terminate an IPSec tunnel on the VM. - Rules are IPv4. Once a group with inbound rules is attached, inbound IPv6 is denied.
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 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.