Announcement by Aenix Team

Launch a customer-facing cloud product — playbook for hosting providers, telcos, and regional operators

The six layers of a customer-facing cloud product, the architectural decisions specific to public cloud, and where launches stumble commercially.

VmwareKubernetesSovereigntyAi MlMulti TenancyHosting

Regional and specialty cloud is having a moment in 2026. Hyperscaler economics, sovereignty pressure, and post-Broadcom market dynamics have all opened space for non-hyperscaler cloud products that didn’t make sense to launch 5 years ago. Regional telco sovereign cloud product launches (Central Asia, MENA, EU member states), QazCloud + Clever Cloud’s sovereign AI ecosystem, and various EU-member-state-specific sovereign cloud products are visible examples. Many more are in stealth or early stages.

Why now

Three independent dynamics support new cloud product launches:

Hyperscaler economics breakdown for some workloads. Sustained inference, high-egress workloads, and regulated workloads are increasingly expensive on hyperscalers relative to dedicated infrastructure. A regional cloud serving these workloads has unit-economic advantages.

Sovereignty as competitive advantage. EU-member-state, Kazakhstan, several APAC jurisdictions have explicit sovereign-cloud mandates. Regional providers serving these mandates have regulatory moat that hyperscalers cannot access.

Post-Broadcom virtualization market disruption. VMware-exit-driven workloads have to land somewhere; regional providers can absorb a portion if they ship the right product.

Six layers of a cloud product

A working customer-facing cloud product has six layers, all of which need engineering:

1. Hardware

Compute servers, storage, network fabric, datacenter / colocation. Sized for initial customer cohort plus growth headroom.

2. Platform

Multi-tenant Kubernetes-native platform with KubeVirt for VMs, Cilium and Kube-OVN for networking, LINSTOR (DRBD-replicated block) for storage. Cozystack is the open-source default for this pattern.

3. Service catalog

What customers can self-provision: VMs, K8s clusters, managed databases (PostgreSQL, MariaDB, MongoDB, Redis, Valkey, Kafka, ClickHouse, OpenSearch, etc.), S3 buckets, GPU instances, networking primitives.

4. Customer-facing portal

Self-service UI (Cozystack Dashboard or custom). Catalog browsing, provisioning, monitoring, billing visibility.

5. Billing

WHMCS production-ready integration in two modes — shipped by Ænix as the WHMCS integration rather than as part of open-source Cozystack. Custom billing for specific markets.

6. Operations

24×7 NOC, customer support, SLA management, observability per tenant, incident response.

Architectural decisions specific to public cloud products

A public cloud product differs architecturally from an internal platform in several ways:

Multi-tenant isolation must be hard. Customers don’t trust each other; regulatory audits are real. Tenant CRD pattern with strong isolation is necessary, not optional.

Self-service must be polished. Internal platforms can have “ask the platform team” as escape hatch. Customer-facing products can’t.

Billing must be accurate from day one. Customers will dispute the first bill; the system has to support that conversation.

Observability for customers, not just for ops. Customers want their own metrics, not just SLA data.

Compliance posture is the product. Sovereignty, data residency, audit-readiness are differentiation features, not afterthoughts.

Go-to-market sequencing

Launch in cohorts:

  1. Beta with 3-5 friendly customers — fix the rough edges before paying customers see them.
  2. Limited GA with 10-50 customers — learn billing and support patterns at small scale.
  3. General availability — open to general market.
  4. Specialty expansion — add specific services (more GPU classes, AI services, etc.) based on observed demand.

Total elapsed: 12-24 months from project start to general availability.

Where launches stumble

Stumble 1: under-engineered multi-tenancy

“We’ll add proper isolation in v2.” Customer #1 finds the gap; reputation damage is hard to recover from.

Stumble 2: billing as afterthought

Billing integration in the last month before launch. Doesn’t work; customers don’t pay; revenue collection is a multi-quarter project.

Stumble 3: operational under-investment

Platform built; ops team sized for 50 customers; they sign 200 in first quarter. Service quality collapses.

Stumble 4: copying hyperscaler architecture wholesale

Designed at hyperscaler scale; over-engineered for actual customer count. Operational complexity exceeds revenue.

Stumble 5: undifferentiated commodity offering

Generic cloud product with no differentiation from hyperscaler. Customers default to AWS / Azure / GCP. Specialty / sovereignty / regional matters as differentiator.

Ænix engagement

Ænix has built customer-facing cloud products end-to-end on Cozystack, including for regional telecom operators. The engagement structure:

  • Discovery + product-readiness assessment (4-8 weeks)
  • Phase 2 build (6-18 months) — platform + portal + billing + operations workflows + first cohort onboarding
  • Phase 3 (optional) — managed-services during ramp

For details see public cloud builder services page.