Drei Plattformen auf einer Engine, dazu zwei Produkte darum herum. Die Plattformen sind keine Stufen und keine Alternativen — sie sind unterschiedliche Oberflächen auf demselben Cozystack-Fundament, und sie lassen sich kombinieren.
Die Wahl richtet sich danach, wer die Kapazität verbraucht
| Geht die Kapazität an … | brauchen Sie | Plattform |
|---|---|---|
| Kunden, die nicht Sie selbst sind | Billing, Payments, Kundenportal, Mandantensperre, Wiederverkauf | Public Cloud Platform |
| die eigenen Fachbereiche, unter Regulierung | DORA-/NIS2-Architektur, kundenverwaltete Schlüssel, revisionsfeste Protokollierung | Private Cloud Platform |
| Inferenz, Fine-Tuning, RAG auf eigenen GPUs | GPU-Mandantenfähigkeit, fraktionales GPU-Sharing, Model Serving, Vektordatenbanken | AI Platform |
Sie kombinieren sich — das ist die Konstruktion, kein Zugeständnis
Unter allen dreien liegen eine Control Plane, eine API, ein Betriebsteam und ein Upgrade-Pfad. Die ehrliche Antwort auf die Frage, welche es denn nun sein soll, lautet deshalb oft: zwei davon — und das kostet Sie eine Konfigurationsänderung statt eines zweiten Programms. In der Praxis:
- AI Platform mit Private-Cloud-Kontrollen. Die übliche Kombination im regulierten Umfeld. Kundenverwaltete Schlüssel erstrecken sich auf Modellgewichte im Ruhezustand; GPU-Workloads liegen innerhalb derselben Tenant-CRD-Grenze, die der Prüfer bereits begutachtet hat. Sie bauen keine zweite Compliance-Argumentation für den KI-Bestand.
- Public Cloud mit GPU-as-a-Service. Ein Anbieter, der VMs und Managed Databases betreibt, schaltet GPU-Mandantenfähigkeit zu und verkauft sie — gemessen und abgerechnet über die Oberfläche, die er ohnehin hat, auf Hardware, die ihm bereits gehört.
- Public und Private gemeinsam. Ein Telco oder eine Bank, die ein souveränes Cloud-Produkt verkauft und daneben den eigenen regulierten Bestand betreibt, führt beides auf einer Plattform mit einem Team — statt zwei Stacks zu pflegen, die sich nur zufällig ähneln.
Nichts in dieser Linie ist eine Sackgasse. Auf Provider-Größe in die Preisliste einzusteigen und zu einem nationalen Multi-Region-Aufbau zu wachsen, ist ein Umschalten, kein Replatforming.
Ænix Public Cloud Platform
Für alle, die Cloud verkaufen — Hosting-Anbieter, MSPs und regionale Clouds auf der einen Seite; Telcos, nationale Betreiber und Banken mit kommerziellem Cloud-Angebot auf der anderen.
Schlüsselfertige Cloud-in-a-Box: vollständiges Billing im Front- und Backend, WHMCS-Integration, White-Label-Kundenportal, Zahlungsabwicklung, Sperren und Suspendieren von Mandanten sowie geführte Assistenten für VMs, Kubernetes, Managed Databases, S3 und GPU. Multi-Region- und Multi-Hypervisor-fähig, sodass ein bestehender VMware- oder OpenStack-Bestand erweitert statt ersetzt wird.
Ab 1.250 USD pro Monat auf Provider-Größe; Multi-Region-Programme für Betreiber nach RFP.
Ænix Private Cloud Platform
Für regulierte Organisationen, die Cloud für sich selbst betreiben — Banken, Versicherer, öffentliche Verwaltung, Telco, Gesundheitswesen und regulierte Industrie.
Eine Kubernetes-native Control Plane, die neben VMware, OpenNebula und OpenShift bestehen bleibt, statt einen Komplettaustausch zu erzwingen. Vorvalidierte DORA- und NIS2-Architektur, kundenkontrollierte Verschlüsselung auf jeder Schicht, unveränderliche Audit-Protokollierung, Multi-DC-Betrieb mit getestetem Failover, Unterstützung bei der Ausrichtung an ISO 27001 und SOC 2. Die Developer-Self-Service-Schicht — Golden Paths, GitLab CI/CD, Argo-CD-GitOps, Self-Service-APIs — gehört zu dieser Plattform und ist kein eigenes Produkt.
Mehrjährige Vorhaben: 3-6 Monate Pilot, 9-18 Monate bis zur vollständigen Multi-DC-Produktion.
Ænix AI Platform
Für Teams, die KI auf eigener Hardware betreiben — KI-native Organisationen im Maßstab, regulierte KI-Deployments, GPU-lastige Produktunternehmen und Anbieter, die GPU-as-a-Service verkaufen.
Mandantenfähiges GPU-Scheduling mit Kenntnis der GPU-Klassen, vorintegriertes Model Serving, Vektordatenbanken, Objektspeicher, einsatzfertige Open-Weight-Modelle und Service-APIs. Souveränitätskontrollen inklusive: kundenkontrollierte Schlüssel, die auch Modellgewichte abdecken, und Air-Gapped-Betrieb. NVIDIA H100, H200, A100, L40S und Blackwell-Klassen, dazu AMD- und Intel-Beschleuniger.
3-6 Monate für eine typische Inferenz-Flotte; 6-12 Monate für Inferenz plus Fine-Tuning plus RAG.
Enterprise-Support für Cozystack
Für Teams, die Open-Source-Cozystack selbst betreiben und die Engineers, die es pflegen, erreichbar haben wollen — ohne die kommerzielle Portal- und Billing-Schicht.
SLA-gestützter Support mit direktem Zugang zu den Maintainern, eigene Kanäle, Upgrade-Begleitung und Compliance-Unterstützung. Der übliche Einstiegspunkt für Produktteams auf Hetzner, OVH oder gemieteter Bare-Metal-Hardware.
Enterprise-Support für Cozystack →
WHMCS-Integration
Für Hoster, die bereits WHMCS betreiben. Ein proprietäres Ænix-Modul, das Cozystack-Services — Kubernetes-Cluster, Managed Databases, VMs, Message Broker, Objektspeicher und GPU — in das Panel bringt, das Sie ohnehin bedienen, samt Verbrauchsmessung und angebundener Abrechnung.
Die Engine darunter
All das läuft auf Cozystack — der Open-Source-Cloud-Plattform, die Ænix entwickelt und pflegt, und einem CNCF-Projekt (Sandbox seit Februar 2025; Incubating erwartet für Spätsommer 2026). Apache 2.0, keine Gebühren pro CPU oder pro Core.
Das ist nicht nur eine Haltungsfrage, sondern ein kommerzielles Argument: Die Engine steht uns nicht zum Zurückziehen zur Verfügung. Endet die Geschäftsbeziehung, betreiben Sie die Plattform auf derselben Hardware weiter, und der Ausstiegspfad ist dokumentiert statt hypothetisch.
Wer den Stack selbst beherrschen will, findet ihn im Kubernetes Deep Dive Kurs — Talos, LINSTOR, Cilium, KubeVirt, Cluster API und Flux für Plattform-Engineers.