Private networks

Every workload Plany runs for you — a game server, an Agones Autopilot game server — is on a private network (a VPC). Sandboxes are the one difference: they run on a network Plany manages for them, and can be connected to one of yours — see Sandboxes and networks. Workloads on the same network reach each other on private addresses as though they were plugged into one switch, wherever in the region they happen to be running. Workloads on different networks cannot reach each other at all.

The default network

Every project gets one network in every region, named default, the moment the project is created. Anything you create without naming a network goes on it, which is why most projects never need to think about networking.

The default network cannot be deleted, and it does not count against your quota.

More networks

Create another network when some workloads should not be able to reach others: a database you only want one fleet to see, a staging environment beside production.

Networking → New network → name it and choose its range → Create network

Two networks of the same project are as separate as two different customers' networks: there is no path between them.

Putting a workload on a network

A workload joins a network when it is created, and stays on it for as long as it exists. Leave the network out and it goes on the project's default network in that region. Name one and it must be in the same project and region, and you need vpc.vpcs.use on it — editors and above hold that.

A workload's network cannot be changed afterwards. Moving it would change its address under whatever is connected to it, so in Terraform changing vpc replaces the resource, and no update call or console edit offers it.

Players connect exactly as before. Nothing about a server's player address depends on which network it is on.

Game servers

plany playpute servers create survival --game games/minecraft-java --vpc fleet

The CLI takes a network's id and resolves it in the project and region the command is acting in; it also accepts the full name. Terraform takes the full name — plany_vpc.<name>.name, or data.plany_vpc.<name>.name for one somebody else manages. In the console, choose it under Network when creating the server.

Autoscaling groups

A group's network is where every member goes, and the free warm-up server Plany prepares first goes there too, so the saved disk members start from was built on the same network they run on.

plany playpute groups create lobby --game games/minecraft-java --max-size 8 --vpc fleet

Agones Autopilot

Pass the network when you apply manifests. It applies to fleets that apply creates; a fleet that already exists keeps the network it was created on, which plany agones autopilot fleets get shows. To move a fleet, delete it and apply it again with the new network.

plany agones autopilot apply -f fleet.yaml --vpc fleet

In Terraform, changing vpc on that resource replaces it: its fleets are deleted and applied again on the new network.

Sandboxes and networks

A sandbox is not on one of your networks. Its instances run on a network Plany manages for Sandbox, one per project per region, which nothing else is on. It is listed beside your own — as sandbox, marked Managed by Sandbox in the console and in the CLI's MANAGED BY column — so nothing running in your project is hidden from you.

Connecting a sandbox to a network

When a sandbox's code needs to reach something on one of your networks — a database, a game server's admin port — connect it to that network:

plany sandbox sandboxes deploy api --vpc database     # connect
plany sandbox sandboxes deploy api --no-vpc           # disconnect

In the console it is Connect to a network when creating a sandbox or deploying a new revision. It defaults to None.

The connection is outbound only:

• Each instance gets an address on the network, and can open connections to anything on it.
• Nothing on the network can open a connection to the sandbox, whatever the network's firewall rules say. A sandbox can call your database; your database cannot call it back.
• There is no default route through the network. Only traffic for the network's own range goes that way; the internet is reached exactly as before.

The network's own firewall still applies to what the sandbox sends: the instance's address is inside the network's range, so a rule admitting that range (or the sandbox's traffic specifically) is what lets it through to a workload there.

The network is part of the sandbox's template, so it belongs to a revision. Connecting, changing or disconnecting it deploys a new revision — the one serving keeps serving until it is ready — and a rollback to an earlier revision restores the network that revision had. In Terraform, changing vpc deploys rather than replacing the sandbox.

The network must be in the sandbox's own project and region, and you need vpc.vpcs.use on it. A network Plany manages cannot be chosen.

Why it never overlaps

Your networks are numbered from private (RFC 1918) space, and overlapping is allowed. The network Sandbox runs on is numbered from 100.64.0.0/16, inside the shared address space 100.64.0.0/10 — a range no network of yours can use. So whichever network a sandbox is connected to, its two addresses can never collide, and a reply always has exactly one way back.

Managed networks are read-only

A network with a MANAGED BY is kept by that product for its own workloads:

• It cannot be renamed, edited or deleted; the service refuses with FAILED_PRECONDITION and reason MANAGED_NETWORK.
• It cannot be given firewall rules, for the same reason.
• No workload can be put on it by naming it — only the product that owns it places anything there.
• It does not count against your network quota.

plany vpcs update and delete say so before sending anything, the console shows it as read-only, and Terraform refuses to import one; data "plany_vpc" exposes managed_by if you need to read it.

Address ranges

You choose the range, and it is yours:

• It must be private (RFC 1918 — inside 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16), between a /8 and a /30. The default is 10.0.0.0/16.
• Overlapping is fine. Two of your networks — or yours and somebody else's — can both be 10.0.0.0/16. They never meet, so the numbers never collide.
• It cannot be changed after the network is created. Changing a range under a running workload would leave it on a link that is up and carries nothing.

The first address in the range is the network's gateway and is never handed to a workload.

Firewall rules

A network's firewall decides which inbound traffic reaches the workloads on it.

• Inbound is denied unless a rule allows it.
• Replies are always allowed. A connection a workload opened itself — to a database, an API, a download mirror — gets its answers back without a rule.
• Plany's own traffic to a workload is always allowed — handing it its address and checking its health. No rule can cut a workload off from those.
• Outbound is not filtered.

Changes take effect within seconds. Nothing restarts.

What a rule says

source_ranges is required on purpose. A rule naming no source would read as "nobody" to one person and "everybody" to another.

How rules are evaluated

Rules are checked lowest priority number first, and the first that matches decides. At equal priority a deny wins over an allow. If nothing matches, the traffic is dropped.

So a narrow deny at priority 500 carves a hole out of a broad allow at 1000, and an allow at 900 beats a deny at 1000. Leave gaps between priorities so there is room to put something in between later.

The rules a network starts with

• A project's default network starts with default-allow-internal: everything from the network's own range, to every workload on it. That is what keeps "workloads on the same network reach each other" true out of the box. It is yours — narrow it, disable it or delete it.
• A network you create starts with no rules at all. Nothing reaches anything on it until you allow it, apart from what the platform opens for its own workloads (below).
• A network that existed before firewalls was given allow-all-inbound-before-firewalls: every protocol, from 0.0.0.0/0, at priority 65535. It exists so that turning firewalls on changed nothing about what could already reach your workloads. Because it sits at the very bottom, any rule you add is evaluated before it — but while it is there, anything your own rules do not deny is still allowed. Once you have added the rules your workloads need, delete it. The console shows a notice on any network that still has it.

Rules the platform manages

When a product runs a workload, it opens what that workload needs as a rule of its own:

These rules are visible — they are listed with your own, with managed_by set to the service that owns them — because nothing that can reach a workload should be hidden. They cannot be edited or deleted: a change is refused with FAILED_PRECONDITION and the reason MANAGED_RULE. Each one goes away when the workload it was opened for is deleted, so starting a game server never needs you to remember a firewall rule, and deleting one never leaves a port open behind it.

They are not counted against your quota, so a project at its rule limit can still start a game server.

A managed rule is still just a rule. Your own deny at a lower priority number overrides it, which is the escape hatch if you need to shut something off immediately — at the cost of whatever the workload needed that traffic for.

Network tags

A tag is a label on a workload's network interface that a rule's target_tags can name. Tags are set when a workload is created and cannot be changed afterwards:

plany playpute servers create survival --game games/minecraft-java --vpc fleet --network-tag minecraft
plany playpute groups create lobby --game games/minecraft-java --max-size 8 --vpc fleet --network-tag lobby

In Terraform, changing network_tags replaces the resource. A group's tags are on every member and on its warm-up server.

A tag is lowercase letters, digits and hyphens, starts with a letter and is at most 63 characters; a workload may carry up to 16. Tags beginning plany-, playpute- or agones- are reserved for the platform.

Tags select targets, not sources: a rule's source is always a range of addresses. To let only some workloads reach something, put them on a network of their own — the network's range is then that set of workloads.

Example: opening a Minecraft port to a tagged server

Players connecting through Plany are already covered by the server's managed rule. You need a rule of your own when something else should reach it — here, a Velocity proxy you run yourself on the same network, forwarding players to backend servers tagged minecraft:

Networking → open the network → Add rule → Allow, TCP 25565, from the network's range, to tag minecraft

Example: a database only one fleet can reach

Put the database and the fleet that uses it on a network of their own, so the network's range is exactly that fleet. A network you create starts with no rules, so nothing reaches the database until you allow it — then allow the database's port, and nothing else, to the workloads tagged db:

plany vpcs create database --cidr 10.20.0.0/16
plany vpcs firewall-rules create allow-postgres --vpc database \
  --allow tcp:5432 --source 10.20.0.0/16 --target-tag db

No other network can reach it at all — networks never route to each other — and on this one, nothing but port 5432 is open to it.

Managing rules

1plany vpcs firewall-rules list --vpc fleet        # alias: plany vpcs fw
2plany vpcs firewall-rules get allow-minecraft --vpc fleet
3plany vpcs firewall-rules update allow-minecraft --vpc fleet --priority 900
4plany vpcs firewall-rules update allow-minecraft --vpc fleet --disabled        # --disabled=false to re-enable
5plany vpcs firewall-rules delete allow-minecraft --vpc fleet

list marks the platform's rules in its MANAGED BY column. --vpc takes a network's id in the command's project and region, or its full name.

Limits

Ask for more in the console or with CreateQuotaIncreaseRequest on vpc.plany.cloud/vpcs or vpc.plany.cloud/firewall_rules. Networks up to 10 (Hobby) or 100 (Pro), and firewall rules up to 100 (Hobby) or 1,000 (Pro), are granted immediately. Rules the platform manages are not counted. See Quotas and limits.

Deleting a network

A network can be deleted once nothing is on it — including sandboxes connected to it, which hold an address there too. While any workload still holds an address there, the delete is refused with NETWORK_IN_USE; plany vpcs leases <vpc> shows what is.

Permissions

vpc.vpcs.use is separate from reading on purpose. A network walled off for a database is exactly the one somebody who can merely see the project should not be able to drop a workload onto, and it can be bound on that one network alone.