Fluence VPC (Virtual Private Cloud) enables private networking on Fluence, giving multi-VM deployments an isolated path for internal traffic. You can keep databases, APIs, workers, and other services on private addresses, expose only the VMs that need a public endpoint, and control traffic between them with security groups.
VPCs, subnets, optional public IPs, managed egress, and cloud-init are now live. Here’s what shipped and how it works.
Fluence VPC Networks
A VPC is an isolated network around a group of VMs. It has no address range of its own — it’s a container for subnets and security groups. You create one by picking a region and a name. Networks of different users are fully isolated from each other, so use whatever private ranges you like; overlapping with someone else’s account doesn’t matter.
Subnets
A subnet is an address range inside a VPC — IPv4, IPv6, or dual-stack, chosen at creation. Subnets in the same Fluence VPC can’t overlap with each other, and they all see each other by default. If some machines shouldn’t talk to others, that’s a security group’s job, not a subnet boundary.
Private and public IPs
A VM in a VPC gets a private IP — assigned automatically, or pinned to a specific address when a workload needs predictable internal addressing (a VM can carry multiple private interfaces if you need them). Address and MAC are bound to the interface — they can’t be changed from inside the machine.
A public IPv4 address is a separate, optional resource. You allocate it and attach it as an additional interface; the address lives directly on the machine, no port-forwarding layer. Unattached addresses stay reserved for you. So a typical setup is one gateway VM with a public IP and everything else — backend, database, workers — on private addresses only. Billing follows the same logic: you pay for compute and storage, and a VM without a public IP simply doesn’t include the public IPv4 charge.
A VM without a public IP cannot be reached directly from the internet. For private remote access, you can use cloud-init to connect it to an overlay network such as Tailscale — this requires egress enabled on the subnet and your own Tailscale account and authentication key.
Egress Traffic
Enabling the egress flag lets IPv4 machines in that subnet initiate outbound connections — apt, container pulls, external APIs — through a shared platform address. This doesn’t give them a public IP and doesn’t make them reachable from outside.
One thing to know: DNS settings are issued to a VM once, at creation. If you enable egress on a subnet later, VMs that already exist won’t get DNS — they need to be recreated. Decide on egress before you spin up the fleet.
Security groups
Security groups are allow-lists attached to VM interfaces, for inbound and outbound traffic separately. The semantics are explicit: no rules means everything is allowed, an empty list means everything is denied, a list of rules means only what matches passes. A rule specifies IP version, protocol (all/icmp/tcp/udp), port range, and source — a CIDR or another security group in the same Fluence VPC.
Referencing groups by group is what makes layering clean: the web server allows inbound 443 from anywhere, the backend allows traffic only from the web server’s group, internal services accept nothing from outside and keep whatever outbound they need.
Also in this release: cloud-init
VMs now take custom cloud-init config, applied on first boot: packages, users, services, arbitrary commands. Define the setup once instead of configuring every instance by hand after deployment. (It’s also how you’d drop Tailscale onto a private VM.)
Getting started
Login or create a Fluence account to get started today. Everything above is live in the Fluence Console.
