Segal VPC
Separate private service traffic from public access through project-scoped networks and subnets.
The supported upstream service is Private Networks. Segal supplies the branded application and support boundary; activation depends on the approved customer configuration and applicable provider terms.
Request and resource flow
- Define the regional network and address ranges.
- Attach instances and supported managed services.
- Add only the required routing and public ingress.
Configuration responsibilities
- Address ranges and routing are recorded as infrastructure configuration.
- Private connectivity is separate from application authorization.
- Firewall policy follows the workload’s trust boundaries.
Supported scope
Project-scoped private networks and subnets. Connectivity is subject to regional service support.
- Overlapping address ranges complicate peering and migration.
- A private network alone does not encrypt every connection.
- Connectivity and supported service integration vary by region.
Read your organization’s inventory
Open the VPC workspace after signing in. The server resolves your active organization and its allowed OVHcloud resources. It does not accept a provider project ID from the browser.
The authenticated endpoint is GET /api/infrastructure/vpc. Supply an allowed region where needed, and a zero-based page for inventory pagination. Each response reports the requested region and the next page when one exists. Project-wide inventories may contain resources from more than one region; an unreported resource region is not inferred from a seed catalog.
The endpoint uses the Segal browser session. Demonstration sk_segal_ keys do not grant production access. Provider credentials stay server-side. A missing connection returns an explicit error rather than sample resources.
Submit a configuration
POST /api/infrastructure/vpc accepts requestId (UUID), operation: "create", acknowledgeCharges: true and a parameters object containing name, region.
An organization owner or administrator must submit the operation from the same origin. The operator must first activate provisioning and confirm reseller terms. An atomic database operation record claims the request ID before the upstream mutation. Reusing that ID does not submit a second mutation; a conflicting payload is rejected.
An accepted response means the provider accepted the request, not that the resource is ready. If a response is lost, use GET /api/infrastructure/operations/REQUEST_UUID and ask engineering to reconcile the state. Do not issue a new request ID as an automatic retry.
Activation and service evidence
Follow provider setup before enabling live access. Demo resources, website imagery and documentation examples do not verify capacity, certification, latency or delivery. Confirm regional availability, contract scope, recovery ownership and final customer pricing before production use.
Read the product architecture. Upstream technical reference: Private Networks (reviewed 24 October 2026).