Platform architecture

Segal Compute presents a branded cloud-service experience over a narrowed OVHcloud service catalog. This is an application and operations boundary, not a claim that Segal owns the upstream datacenters or has an activated reseller contract.

Control plane

1. The customer signs in to Segal and selects an organization.
2. The server verifies current membership and resolves the organization’s provider binding.
3. The OVHcloud client signs the exact request URL, HTTP method, timestamp and serialized body.
4. Provider responses are normalized into resource identifiers, names, state and reported region. Provider credentials and arbitrary raw responses are not returned to the browser.

The provider clock is checked before signed requests. Network operations have bounded timeouts; submitted mutations are never automatically retried.

Customer isolation

Each organization must have a distinct OVHcloud Public Cloud project. Domains, hosting plans, Email Pro services and dedicated servers use explicit allowlists. Overlapping bindings are rejected. Browsers cannot supply an upstream project ID or a free-form provider API path.

Inventory queries use the authenticated organization. Owners and administrators can submit supported operations after operator activation. Other members retain read access. The legacy demonstration API-key resolver does not authenticate production requests.

Bindings are currently operator-managed environment configuration. Move them to a separately audited tenant-binding database before the environment configuration becomes too large or needs customer self-service changes; never replace them with one shared account-wide project.

Data plane

GPU workloads, training containers, model-serving applications and databases execute upstream, not inside the Segal marketing application on Vercel. S3 object traffic uses separately scoped storage credentials and the bucket’s assigned endpoint. Mailbox traffic uses the mail service’s documented protocols. CDN and SSL configuration attach to eligible hosting plans.

Operation records

The provider_operations table claims a customer request UUID before a mutation. The claim is atomic and the operation payload is hashed. Reusing a request with a different payload is rejected; an accepted request is replayed from its stored response. Pending, rejected or uncertain requests require reconciliation rather than blind resubmission.

A provider acceptance is separate from resource readiness, application health, usage reconciliation and customer billing. If the provider response or final database update is lost, inspect the operation record and upstream resources before deciding whether to act again.

Commercial and service boundaries

The active catalog excludes transactional email, managed WireGuard VPN, arbitrary edge functions, unverified dedicated NVLink fabrics and physical rack sales. Domain registration, dedicated-server orders and several managed-service configuration changes remain engineering-assisted. The customer quote is separate from the provider’s wholesale price.

Browse the service architecture or prepare the provider connection.