Cloud & infrastructure teams / Begin with one service dependency
Your infrastructure. Across clouds and beyond.
Connect workloads across providers and keep administration private. Deliver public addresses to supported infrastructure you control.
Available with assisted setup. Confirm the supported devices, locations and connection scope before deployment.
01 / Follow the actual service call
One worker.
One service.
Two environments.
A worker runs with one provider. Its database stays with another. Connect that dependency privately before planning the wider network, a public allocation or a migration.
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 →These are three different connection jobs. Private workload access, routed public delivery and an external API’s source allowlist each need their own scope, permissions and acceptance checks.
02 / Keep the operating boundaries visible
The path crosses clouds.
Ownership stays clear.
Keep the database, worker or storage server where it belongs. The first deployment needs agreement between the people who own the hosts, network routes and application.
Source environment
The worker starts the call.
Identify the enrolled host, destination address, service port and application credentials. Check overlapping private ranges and the source host’s firewall before approving the path.
Your cloud and workload administrators own host configuration, security groups and the application’s credentials.
Connection and return path
Both directions need a route.
Networks can connect supported enrolled hosts privately. Reaching a wider subnet needs a supported gateway, explicit approved routes and a return path; joining one VM does not automatically route its VPC.
Agree the permitted destinations in backend policy. Your administrators configure the cloud routes, supported gateway and local firewalls required by the deployment.
Destination environment
The service decides what to accept.
Keep the private listener, application login and data permissions under the service owner’s control. A permitted network path does not authorise a database operation or make neighbouring resources reachable.
The service owner configures the application, validates its responses and operates its data, replication and recovery tools.
A joined host is the starting point.
Enrolling a VM does not automatically connect its VPC or edit a provider’s route tables. Confirm gateway forwarding, cloud security groups, host firewalls and the return path for every approved subnet.
Explore private connections with Networks →Understand identity, routing and policy →03 / Choose the scope
A private dependency.
A public allocation.
A known source.
Choose the job the workload needs. A private connection, an incoming public address and an outgoing identity are separate decisions.
Compare the connection options →Approved workload and administration paths
Connect the private service.
Use Networks through supported enrolled hosts or gateways. Keep application authentication, permitted destinations and provider firewall rules in place.
Explore private workload connections →Internet-facing infrastructure you control
Deliver an address or routed block.
A supported server can receive a public IP; a supported gateway can receive a routed block for downstream workloads. Choose incoming exposure and outgoing traffic policy separately.
Routed Subnets is an invitation-led managed service. IPv4 and IPv6 are separate allocations; IPv6 sizes span /48 through /64. Confirm stock, location, delivery and quoted terms for the deployment.
Explore routed public allocations →An external service checks the caller
Verify the source it observes.
Public IPs can supply the source under a supported traffic mode. A suitable Outbound exit is an alternative for eligible internet traffic. Outbound currently uses a full-tunnel profile with one active organisation-wide profile; do not assume automatic per-workload exits.
Plan external API source identity →An allocation has a different lifecycle from its workload. Reassignment needs supported, verified delivery and routing; it does not establish automatic floating between clouds, failover or surviving sessions.
04 / 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.
Explore hybrid cloud connections →Keep a record of what actually worked.
A configured tunnel or an accepted API record is one part of the deployment. The service call and its operating checks establish whether the path is useful.
- 01A useful service response
- Make the actual worker call the intended service across the two environments. Verify the application response and credentials, with the cloud firewall and return route in place.
- 02A deliberate access boundary
- Test an authorised connection, then a neighbouring resource or port that should stay inaccessible. For public delivery, check incoming rules separately from the outgoing traffic policy.
- 03A measured workload
- Record latency, throughput and provider transfer costs using representative work. For an external API, check the source address observed by the destination and test both address families.
- 04A recoverable change
- Retain administration and rollback access. During a migration, the application owner verifies data consistency before clients change destination or a public allocation is released.
When the dependency is part of a move
Change the workload in stages.
Keep the old and new environments reachable while your own tools copy data, test the replacement and prepare the cutover. Connectivity does not provide database replication, backups, data reconciliation or disaster recovery orchestration.
Plan infrastructure you control →05 / A practical first deployment
Map the dependency.
Prove the path.
Begin with two environments and one useful call between them. Keep the operating owners, measurements and rollback method in the same deployment plan.
- 01
Map one dependency.
Bring the source host, destination address, service port, application credentials and owners of both environments. Check address overlap, security groups and host firewalls before changing routes.
- 02
Commission the approved path.
Choose supported hosts or a gateway that can reach the service. Confirm WireGuard traffic is permitted and that the runtime has the required privileges to configure its tunnel and routes. Plan the return path and both address families.
- 03
Measure, then decide what moves.
Run the real workload and record behavior, latency, throughput and transfer costs. Keep a rollback route during migration and verify application data consistency before changing clients or releasing an allocation.
For IPv6-only delivery, explicitly choose how IPv4 traffic is blocked, uses separately supported translation or follows a clearly identified ISP bypass. Do not assume an IPv6-only tunnel carries every internet request.
06 / Before production
The infrastructure
questions.
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. It does not automatically configure cloud-provider route tables. 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.