Infrastructure
How QIOI runsyour workloads.
QIOI is an operations layer, not a hosting company. Workloads run on proven infrastructure providers behind a single adapter interface — so capacity can move without your service noticing.
Provider abstraction
Not locked to one provider.
Every provider QIOI uses implements the same adapter interface. Provisioning, resizing, snapshots, and metrics go through one contract — which means migrations between providers are operational tasks, not rebuilds.
The interface below is the actual contract from the QIOI platform handoff. Instance lifecycle, snapshots, and metrics are defined once and implemented per provider.
interface InfrastructureProvider {
createInstance(spec: InstanceSpec): Promise<Instance>;
getInstance(id: string): Promise<Instance>;
resizeInstance(id: string, plan: ResourcePlan): Promise<Instance>;
stopInstance(id: string): Promise<void>;
startInstance(id: string): Promise<void>;
restartInstance(id: string): Promise<void>;
deleteInstance(id: string): Promise<void>;
createSnapshot(id: string): Promise<Snapshot>;
restoreSnapshot(id: string, snapshotId: string): Promise<void>;
getMetrics(id: string): Promise<InstanceMetrics>;
}Current providers
Capacity from established providers.
QIOI deploys on providers with a track record, selected per region and workload. The set of providers can change; the service contract does not.
Hetzner
Primary capacity for EU deployments
OVHcloud
Canadian and European capacity
AWS
Available for dedicated and regional requirements
Vultr
Additional regional coverage
DigitalOcean
Additional regional coverage
Provider credentials are scoped to the minimum permissions required, and are never exposed to application instances.
SpaceOne capacity
A preferred source, never a dependency.
QIOI runs on SpaceOne capacity when it is available and appropriate for the workload. It never depends on SpaceOne exclusively — external providers carry production workloads today, and the adapter interface keeps that portable.
Capacity policy
- →SpaceOne capacity used when available and suitable
- →External providers carry production today
- →No exclusive dependency on any single provider
- →Workloads can migrate between providers
Regions
Choose where your instance runs.
Supported deployment regions, rendered from the platform configuration. Region availability can vary by provider and plan.
Canada (Central)
ca-central
Canadian data residency
US East
us-east
EU Central
eu-central
Deployment pipeline
Deployment is a state machine, not a spinner.
Every deployment moves through explicit, observable states. You can see exactly where an instance is in the pipeline, and a failed state rolls back instead of leaving a half-configured server.
- 01
Payment confirmed
payment_confirmed
- 02
Queued
queued
- 03
Provisioning server
provisioning_server
- 04
Configuring network
configuring_network
- 05
Installing application
installing_application
- 06
Configuring domain
configuring_domain
- 07
Issuing SSL
issuing_ssl
- 08
Running health checks
running_health_checks
- 09
Service ready
ready
States are defined in the platform deployment sequence and surfaced in the dashboard as they happen — including failed, rolling-back, and cancelled states.