Skip to main content

CompanyGPT Sovereign: A Sovereign AI Platform on STACKIT

Tobias Jonas Tobias Jonas 5 min read
CompanyGPT Sovereign: A Sovereign AI Platform on STACKIT

When Azure is not enough

For many companies the Azure variant of CompanyGPT is the right choice: deep Microsoft 365 integration, Entra ID, AKS, done. But there are industries and public sector organizations where the word “cloud” immediately raises questions about jurisdiction, ownership, and data residency. Public sector, research, critical infrastructure, healthcare: a European Azure region is often not enough. CompanyGPT Sovereign is built exactly for this case.

Sovereignty as an architectural principle

Sovereignty is not a property you bolt on later. It is an architectural decision that touches every component. With CompanyGPT Sovereign we followed that through: the entire application platform runs on STACKIT, the cloud of the Schwarz Group with data centers in Germany and an operating entity that is fully subject to German law.

That means no US holding, no CLOUD Act, no jurisdiction outside the EU. For customers with real sovereignty requirements, this is the decisive difference compared to any hyperscaler region.

The architecture at a glance

The platform differs from the Azure variant in several clear ways:

  • STACKIT Kubernetes Engine (SKE) as the runtime
  • PostgreSQL Flex as the relational database
  • MongoDB Flex for document-oriented workloads
  • STACKIT Model Serving for sovereign AI models
  • Keycloak as a self-hosted identity and SSO solution
  • Longhorn for persistent cluster storage with RWO and RWX
  • nginx-ingress with cert-manager and Let’s Encrypt for TLS
  • Optional Azure AI Foundry and Google Vertex AI for additional models

All components are provisioned via Terraform. There is no click deployment, no manual configuration. Each tenant environment is exactly reproducible.

STACKIT SKE as the runtime

SKE provides managed Kubernetes with German data residency. We use it for the same workloads as AKS in the Azure variant: frontend, API, workers, RAG connectors, MCP servers, and search index run as containers side by side. On the platform layer we rely on Kubernetes standards: Helm charts for releases, NetworkPolicies for traffic isolation, RBAC for cluster permissions.

Persistent storage uses Longhorn, running inside the cluster and providing RWX volumes via NFS. Workloads that need shared volumes work identically to Azure Files in the Azure variant. All data stays physically inside the STACKIT data center.

PostgresFlex and MongoDB Flex behind private networks

The database layer is deliberately split into two engines:

  • PostgreSQL Flex holds structured data like identities, sessions, audit logs, and configuration
  • MongoDB Flex stores conversations, memory entries, and document-oriented content

Both databases are reachable through the STACKIT network only, not through the public internet. Backup, high availability, and patch management are handled by STACKIT as a managed service. From a security perspective this is functionally equivalent to the private endpoint setup in Azure, just inside the STACKIT world.

Models: sovereign first, hybrid when needed

The model layer is the most interesting part of the architecture. The order is clear:

  • Sovereign first: STACKIT Model Serving provides Mistral, Llama, and Gemma directly in Germany. For many use cases this is fully sufficient
  • EU as a second choice: Azure AI Foundry exposes OpenAI models like GPT-4.1 and GPT-5.1 in EU regions such as Sweden Central
  • Specialty models from EU GCP: Google Vertex AI offers Anthropic Claude and Gemini in europe-west1

This order is intentional. Standard requests run on sovereign models. Only when a model is strictly required that is not yet available in Germany do we enable EU hyperscaler models. The user sees the routing, the data protection officer has clear rules, the CISO has a defensible default position.

Embeddings for RAG come from Azure AI Foundry because quality and language coverage in the EU context are currently the strongest there. This too is a reasoned decision rather than an out-of-the-box assumption.

Identity without Entra ID

In the Azure variant Microsoft Entra ID is the backbone for SSO and token propagation. In the sovereign setup we replace it with a self-hosted Keycloak. Keycloak runs as a pod in the SKE cluster, uses PostgresFlex as its database, and provides OpenID Connect to the application.

The benefit: identities and sessions never leave the STACKIT environment. Federation to existing identity providers (Entra ID, AD FS, Active Directory, academic IdPs like DFN-AAI) is possible but optional. For customers without their own IdP landscape, Keycloak covers the full spectrum: user management, groups, MFA, passkeys.

TLS, DNS, and networking

The application is reachable through nginx-ingress. cert-manager handles certificates from Let’s Encrypt via the HTTP-01 challenge automatically. There is no manual certificate management and no dependency on a proprietary cert service.

DNS and network segmentation follow the same principle as everywhere else: STACKIT networks isolate workloads, NetworkPolicies govern pod-to-pod communication, external access goes through the ingress only. Audit logs from the cluster and databases land in central monitoring.

Infrastructure as code is mandatory

As with the Azure variant, everything is code. Terraform modules describe SKE, databases, networks, Keycloak, the application, and all optional model backends. Tenant configuration lives in dedicated value overrides, versioned separately from the platform code.

For public sector customers this is more than DevOps comfort. It is a compliance argument: every platform change is documented in a pull request, every approval is traceable, every state is reproducible. This significantly simplifies ISO 27001, BSI IT-Grundschutz, and C5 audits.

When Sovereign, when Azure?

The honest answer: not every customer needs the sovereign variant. Our recommendation:

  • CompanyGPT on Azure, when Microsoft 365 and Entra ID are the central universe and a European hyperscaler region is sufficient
  • CompanyGPT Sovereign, when German data residency, BSI or C5 conformity, public sector requirements, or research funding conditions are explicitly required

Both variants share the application layer. A later switch is possible if requirements change. Database migrations between variants are well-rehearsed.

Conclusion

Sovereignty is not the opposite of cloud. It is a deliberate cloud decision. CompanyGPT Sovereign shows that an enterprise-grade AI stack can run entirely on German infrastructure without compromising on functionality, model variety, or operational quality. The combination of STACKIT as the foundation, optional EU model extensions, and infrastructure as code as the delivery path produces a platform that satisfies even the strictest auditors.

If you are unsure whether you need Azure or Sovereign, talk to us. A short workshop is usually enough to identify the right variant.

Request a demo or jump directly to our STACKIT services.

Tobias Jonas
Written by Tobias Jonas CEO

M.Sc. Informatik, Schwerpunkt KI & Cloud. Vertritt die innFactory nach außen und entwickelt die Strategie. Begleitet als technischer Lead viele Projekte operativ.

LinkedIn