Follow the paths
Connect the environments your workloads depend on.
A worker in one cloud reaches a service in another.
- Cloud A workerSupported enrolled host→WireGuard
- Fibmesh routing nodePermitted private connection→WireGuard
- Cloud B serverPrivate application listener
Networks can provide the private path while both workloads stay with their existing providers. Application credentials and cloud firewall rules still apply.
This shows node-routed connectivity over the existing internet. Direct P2P is planned; a dedicated cloud interconnect is not part of this example.
Explore the private workload example →Give downstream workloads addresses from your allocation.
- Internet clientDestination in your public block→Public route
- Fibmesh public deliveryRoute the assigned prefix→WireGuard
- Your supported gatewayTunnel endpoint and downstream routes→Routed delivery
- Workload subnetAddresses from the allocation
The gateway receives a routed allocation and forwards traffic to the downstream workloads you configure. Return routing and service firewalls are part of the deployment.
Routed Subnets is invitation-available. IPv4 and IPv6 allocations are separate; IPv6 /48–/64. This does not establish BYOIP, BGP, provider route-table automation or automatic failover.
Explore Routed Subnets →Let a provider recognise the worker’s outgoing address.
- WorkloadStarts an external API request→WireGuard
- Fibmesh public sourceAssigned address or suitable exit→HTTPS
- External serviceSource allowlist + API authentication
Public IPs can supply the source under the chosen traffic mode. Outbound is an alternative when the requirement is routing eligible internet traffic through an exit.
Verify the source observed by the destination, including address-family behavior. Outbound currently uses a full-tunnel profile; do not assume automatic per-workload exits.
Compare source-identity options →Clouds, sites and servers
Put each workload where it belongs.
A database stays in one cloud. A worker runs with another provider. A storage server sits in your office. Connect the parts that need to work together without making every service public or moving the whole stack into one environment.
Connect across providers
Use Networks through supported enrolled hosts or gateways for private application and administration paths. A VM can join on its own; connecting a wider subnet needs approved routes and a gateway.
Private workload connections →Address your own infrastructure
Deliver a public IP to a supported server, or a routed block to a gateway serving downstream workloads. Choose where incoming services and outgoing requests use that allocation.
Routed public allocations →Move a workload in stages
Keep a controlled path between old and new environments while you copy data, test the replacement and plan the cutover. Connectivity is one part of the migration, alongside replication and application configuration.
Infrastructure you control →Routed Subnets is an invitation-led service: IPv4 and IPv6 are separate allocations, with IPv6 sizes from /48 through /64. A public allocation has a different lifecycle from its workload; reassignment needs supported delivery and routing. Do not assume automatic floating between clouds or surviving sessions. Compare the connection options →
Your first working result
One dependency, across two environments.
Connect the workloads that need to exchange data. Evaluate the actual service call, cloud firewall rules and return routing before planning a larger migration.
- Test a real service call between the environments
- Measure workload latency and transfer costs
- Retain rollback access during any migration
A practical first deployment
Start with a dependency map, then connect one path.
Map the actual service calls
List source hosts, destination addresses, ports and application credentials. Check overlapping private ranges, cloud security groups and host firewalls before approving routes.
Choose the gateway and traffic policy
Place supported software where it can reach the target. Confirm WireGuard is permitted, plan both address families and provide a return path. A joined VM does not automatically route its VPC.
Measure before moving production
Test the real workload, transfer costs, latency and throughput. During a migration, retain rollback access and verify data consistency in the application before changing clients or releasing an allocation.
For public delivery, check incoming firewall rules separately from the outgoing route. For private services, test both an authorised connection and a neighbouring resource that should remain inaccessible. Understand identity, routing and policy →
Before production
The questions an infrastructure team will ask.
Is this a dedicated cloud connection?
No. These deployments run over supported existing internet connections. They do not establish a dedicated circuit, cloud-provider partnership or private interconnect. Provider egress charges, local restrictions and the chosen service location still affect the deployment.
Can a routed subnet move between clouds?
The service can be designed around an allocation separate from a provider’s local addressing, but destination changes need a supported, verified delivery procedure. Automatic floating-subnet orchestration, multicloud failover and uninterrupted session migration are not current promises.
Can we use our own IP space or BGP?
Do not infer BYOIP or customer BGP support from Routed Subnets. The described service delivers a Fibmesh-provided allocation to your supported gateway. Discuss other routing requirements separately.
Does Networks handle replication, backups or disaster recovery?
It can provide a connection used by your own tools. It does not replicate databases, schedule backups, reconcile data or orchestrate disaster recovery. Test those tools and their failure behavior independently.
What should we know about IPv6-only deployments?
Check whether the clients and destinations support IPv6, and decide explicitly what happens to IPv4 traffic. Do not assume automatic translation or that an IPv6-only tunnel carries every internet request. Read the addressing guide.
Can we automate the deployment?
The development CLI and API contracts cover parts of the platform, not a finished universal provisioning workflow. Networks CLI & API and Public IPs CLI & API explain current operations. An accepted API record is not evidence that routes and traffic are working.
Bring two environments, the dependency between them and the route you need. Build the first connection before planning a wider migration.
Plan an infrastructure deployment →