What's new in the v1beta2 release

Breaking Changes

Change to all existing VMs to have IPv6 globally routable addresses

The stackType field is added in v1beta2. Before v1beta2, all VMs were effectively IPv4-only — there was no stack type to configure.

New VMs: You must now choose a stack type when creating a VM. The supported options are dual-stack and ipv6-only. ipv4-only is not a valid option for new VMs. See Create a virtual machine for the updated procedure.

Existing VMs: VMs created before v1beta2 remain as-is at rollout (they will have a stack type of ipv4-only). You have until 31st July 2026 to convert them to dual-stack (or ipv6-only) before evroc automatically upgrades them. To migrate a VM:

  1. Stop the VM.
  2. Update the VM to set its stack type to dual-stack (if IPv4 networking is desired) or ipv6-only.
  3. Start the VM again.

After the migration window ends, any remaining IPv4-only VMs will be automatically changed to dual-stack. The VM will receive a globally routable IPv6 Global Unicast Address (GUA) in addition to its existing IPv4 address.

You can check a VM's stack type and addresses using:

evroc compute virtualmachine get myvm

Look for the stackType, privateIPv4Address, and ipv6Address fields in the output.

Changes to VM default Security Group behaviour

VMs without explicitly assigned security groups now have no network connectivity (implicit deny on all traffic).

Previously, if you didn't specify security groups when creating a VM, the VM was automatically added to the default-allow-egress security group. This is no longer the case. You must now explicitly assign at least one security group to every VM.

For example, to create a VM with outbound internet access and SSH access:

evroc compute virtualmachine create myvm \
  --zone=a \
  --subnet=default-se-sto-a \
  --security-group=default-allow-egress \
  --security-group=default-allow-ssh \
  ...

Warning: If you don't specify any security groups, the VM's firewall drops all traffic. This includes outbound internet access, SSH, and traffic from other VMs.

For more information, see Security groups and Configure security groups.

New Features

Configurable Networking

You can now create and manage your own Virtual Private Clouds (VPCs) and subnets instead of using only the default networking resources.

VPCs:

  • Create VPCs with custom IPv4 CIDR blocks or use the default 10.0.0.0/16.
  • Choose between dual-stack (default) and ipv6-only stack types.
  • Each project can have up to 5 VPCs.

Subnets:

  • Create subnets within your VPCs with specific IPv4 CIDR ranges.
  • Subnet sizes can be between /16 and /29.
  • Subnet CIDRs must be within the parent VPC's range and can't overlap with other subnets in the same VPC.
  • Each project can have up to 50 subnets.

VM subnet selection:

  • VMs must explicitly reference a subnet at creation time.

For step-by-step instructions, see Configure VPCs and Configure subnets.

Ipv6

IPv6 support is now available across VPCs, subnets, VMs and security groups.

  • Stack types: Choose dual-stack or ipv6-only when creating VPCs, subnets, and VMs.
  • Automatic allocation: The service allocates a /56 IPv6 CIDR block to each VPC and carves /64 blocks for subnets automatically. You don't need to specify IPv6 ranges.
  • Globally routable addresses: VMs on dual-stack or IPv6-only subnets receive globally routable IPv6 GUA addresses.
  • Security group rules: Rules now support IPv6 CIDR ranges. You must create separate rules for IPv4 and IPv6 traffic. For example, to allow SSH from anywhere for both protocols, create two rules:
evroc networking securitygroup addrule my-sg \
  --name=allow-ssh-ipv4 \
  --direction=Ingress \
  --remote-ip-or-cidr=0.0.0.0/0 \
  --port=22 \
  --protocol=TCP

evroc networking securitygroup addrule my-sg \
  --name=allow-ssh-ipv6 \
  --direction=Ingress \
  --remote-ip-or-cidr=::/0 \
  --port=22 \
  --protocol=TCP

The default VPC and subnets are dual-stack, so IPv6 is present in projects from the start.

For more information, see IPv6 networking.

Disk Snapshots

The v1beta2 API adds support for disk snapshots, allowing you to create point-in-time copies of your disks.

  • Create a snapshot from any existing disk.
  • Create new disks from snapshots to restore data or provision identical disks.
  • Snapshots are zonal resources and exist in the same zone as their source disk.

Snapshot operations are available in the v1beta2 API at:

POST   /compute/v1beta2/projects/{projectID}/regions/{regionName}/snapshots
GET    /compute/v1beta2/projects/{projectID}/regions/{regionName}/snapshots/{snapshotID}
DELETE /compute/v1beta2/projects/{projectID}/regions/{regionName}/snapshots/{snapshotID}

Note: When creating a disk from a snapshot, the disk is created in the same zone as the snapshot. If you don't specify a size, the new disk uses the snapshot's restore size.