Article by Aenix Team

Public Cloud Platform — what it actually takes to launch a sovereign cloud product at scale

What a multi-year, multi-million-euro sovereign cloud build covers for telcos, banks, and operators.

CozystackMulti TenancySovereigntyCloudPlatform Engineering

The Public Cloud Platform conversation is different from every other Ænix engagement. It’s not “should we use Cozystack?” — that’s already decided. It’s “we are launching a cloud product at national or tier-1-customer scale; what does the partnership with Ænix look like across the 18-36 months it takes to ship?”

What Public Cloud Platform is built for

Five buyer profiles dominate Public Cloud Platform engagements:

  1. Tier-1 telcos / national operators — incumbent telecom operators launching or scaling a public cloud as part of their product portfolio. Often paired with sovereignty positioning (“our sovereign cloud”, “national cloud”).
  2. Big banks operating their own cloud — the bank consumes its own cloud product for internal workloads and, sometimes, sells capacity to its customer base.
  3. Sovereign cloud initiatives — government-mandated cloud products, sometimes with public-private-partnership structure, with explicit sovereignty requirements and regulator alignment.
  4. Hosting providers at large scale — providers above ~5,000 customers where the Public Cloud Platform operational model needs scaling into multi-region with multi-DC active/active.
  5. National AI/GPU operators — sustained inference + training capacity for sectoral customers (banks, healthcare, public sector, defence) where AI sovereignty is a national-level requirement.

All five share the same operational reality: multi-region or multi-DC active/active; multi-million-euro infrastructure investment; customer-facing SLAs that map to national regulator expectations; and a partnership model with Ænix that lasts years, not months.

What Public Cloud Platform includes that the other products don’t

Multi-region / multi-DC active/active

Single-DC deployments are Public Cloud Platform or Private Cloud Platform territory. Public Cloud Platform assumes from day one that the customer needs active/active across regions or datacentres with cross-DC replication tuned for RTO/RPO targets. The platform’s control plane, observability, identity, and storage layers all design for multi-region from the foundation rather than retrofitting.

Service-catalog depth

A provider-scale build exposes ~20 managed services. An operator-scale build typically targets 30-50+ services across compute, storage, networking, managed databases, observability, AI/GPU, message queues, search, content delivery, security tooling. Cozystack’s package architecture (Package + PackageSource + ApplicationDefinition resources, as of v1.x) supports the catalog expansion.

Operations team at scale

10-30+ engineers running the platform, depending on customer count and SLA. Public Cloud Platform engagement includes operations team hiring and training as a substantial workstream — not “you find people, we’ll train them” but “we design the org structure with you, participate in interviews, do hands-on training, and run Tier-3 for the first 12-18 months while your team builds confidence.”

Regulator and sovereignty alignment

Whatever the sovereignty framework is in the customer’s market — SecNumCloud, BSI C5, EUCS, sectoral overlays, national procurement mandates — the architecture is designed to satisfy it substantively, not just contractually. Compliance evidence catalogue is a deliverable.

Customer-facing brand engineering

Beyond Cozystack Dashboard customisation, Public Cloud Platform includes brand-engineering work: customer portal that looks like a top-tier cloud product, not a customised Cozystack instance. UX flows tuned to how customer’s customers think about ordering, configuring, paying. Designer-led, not engineering-led.

How an 18-36 month engagement phases

Phase 0 — Discovery and partnership formation (1-3 months)

Before engineering, agreement on:

  • Strategic objectives (what cloud product, what customer base, what competitive positioning)
  • Regulatory scope (which frameworks bind the platform)
  • Org structure (who owns what; how Ænix and customer teams interact)
  • Commercial structure (engagement model, IP, support model post-go-live)
  • Roadmap (phasing of services, geographic expansion, SLA tiers)

Output: signed engagement plan with named workstream leads on both sides.

Phase 1 — Foundation (3-6 months)

Hardware procurement and racking. Talos / Cozystack platform deployment in the first datacentre. Storage layer (LINSTOR/DRBD at scale). Networking foundation. Identity integration with customer’s existing workforce identity (Keycloak / Okta / Active Directory / sovereign IdP). Initial observability stack.

End state: working platform, single region, internal access only. Not yet customer-ready.

Phase 2 — Multi-region foundation (3-6 months)

Second datacentre stood up. Cross-DC replication validated. Federated identity. Multi-region storage replication (LINSTOR async or Ceph cross-region). Disaster recovery patterns tested. Compliance documentation foundation built.

End state: multi-DC platform, internal access, RTO/RPO validated against targets.

Phase 3 — Service catalog buildout (4-12 months)

Service-by-service rollout. Start with foundational services (compute, storage, basic networking, managed PostgreSQL). Layer in managed service families (databases, queues, caches, search, observability). Add product-specific services (GPU, AI inference, sectoral compliance tooling).

Each service goes through: deployment → internal testing → friendly- customer pilot → production GA. Cohort-based rollout, not big-bang.

Phase 4 — Customer onboarding and limited GA (3-6 months)

Customer-facing portal launched (brand-engineered). Billing integration validated end-to-end. Support runbooks documented. First 10-50 friendly customers onboarded. SLA monitoring operationalised.

End state: cloud product live with first customer cohort, billing and support workflows proven.

Phase 5 — General availability and scale (ongoing)

Open market launch. Marketing and sales activated. Operations team scales to support customer growth. Ænix Tier-3 retainer continues until customer team is ready to absorb Tier-3 (typically 12-24 months post-GA).

Subsequent phases are roadmap-driven: new services, new regions, new sectoral SKUs.

Where multi-million-euro cloud projects fail

Three failure patterns we’ve seen across the industry:

1. Under-investing in brand engineering

Engineering-led platform with engineering-grade UX. Customers click around, find it functional but unappealing, sign up for hyperscaler instead. Public Cloud Platform engagement includes design partnership explicitly to avoid this.

2. Operations team sized for go-live, not 18-month-out volume

Cloud products grow exponentially during the first year of GA if positioning is right. Operations teams sized for go-live customer count get overwhelmed at month 6-12. Plan operations capacity for 18-month-out volume; hire ahead.

3. Regulator dialog deferred

Sovereignty positioning depends on regulator endorsement (explicit or implicit). Projects that defer the regulator conversation until late-phase find themselves rebuilding architecture to satisfy expectations they could have designed for at the start. Engage regulators in Phase 0-1, not Phase 4.

When Public Cloud Platform is the right answer

Strong fit:

  • Tier-1 telco / national operator / large bank / sovereign cloud initiative
  • Multi-region or multi-DC operational reality
  • 5,000+ target customer count or strategic customer base
  • Multi-million-euro budget envelope across 18-36 months
  • Sovereignty / regulator positioning is core to value proposition
  • Senior executive sponsorship (CIO or CTO level minimum)

Marginal fit:

  • Large hosting providers above the Public Cloud Platform ceiling but below tier-1 telco scale — may fit the Public Cloud Platform or an extended engagement depending on growth profile
  • AI/GPU-focused operators where the AI workload dominates — the Ænix AI Platform may fit better, with selective Public Cloud Platform components

Poor fit:

  • Smaller hosting providers — Public Cloud Platform fits substantially better on economics and operational model
  • Regulated enterprises consuming cloud rather than producing it — Private Cloud Platform is the right answer

Engagement structure

  • Discovery call (executive level, 60-90 min) — strategic fit assessment
  • Strategic engagement plan (4-8 weeks, fixed-price) — partnership formation, output is signed engagement plan
  • Phase 1-5 build (18-36 months) — phased build per above
  • Managed Tier-3 (ongoing) — Ænix retainer until customer team is ready to absorb

Engagement size: multi-year programme, quoted per RFP.

Where to dig deeper

Test yourself: Public Cloud Platform

5 questions · ~2 min