Deployment modes

Davion supports four deployment postures. Each ships the same platform image; the differences are network topology and the signed-update channel. This page describes each posture and how to choose between them. The conceptual framing is on Sovereignty postures.

Air-gapped

The platform runs on a network with no external egress. Updates arrive on signed physical media or via an air-gap data diode; nothing initiated outside the perimeter can reach the platform.

Use this posture when:

• The institution’s threat model rules out any outbound connection
• A classification authority forbids commodity-cloud or networked-update channels
• The decision class is operational and the data is sensitive enough that the air-gap is not negotiable

Typical operators: defence and intelligence, tactical-edge deployments, classified workflows in financial-crime units.

On-prem

The platform runs in the institution’s own data centre, networked. Updates arrive over a signed channel the institution controls. The platform may reach external services for explicitly allow-listed purposes (vulnerability feeds, time, certificate revocation), or none.

Use this posture when:

• The institution has an existing on-prem footprint and wants AlpOS alongside it
• Regulators require data to remain inside national infrastructure
• The institution is willing to operate the underlying hardware but does not require full air-gap

Typical operators: major banks, ministries, critical-infrastructure operators.

Sovereign cloud

The platform runs in a sovereign cloud of the institution’s choosing — Open Telekom, IONOS, Exoscale, OVHcloud Sovereign, Bleu, S3NS, GovTech. The cloud operator’s residency, jurisdiction, and personnel commitments are part of the engagement record.

Use this posture when:

• The institution has accepted a specific sovereign-cloud provider as a national or sectoral standard
• The institution does not want to operate physical hardware
• The decision class allows networked operation as long as the operator and the data are in a defined sovereign jurisdiction

Typical operators: public-sector buyers under national cloud strategies, regulated enterprises in jurisdictions where a sovereign cloud is the procurement default.

Private cloud

The platform runs in a customer-controlled VPC inside a hyperscaler. The customer holds the keys and controls the network; the hyperscaler is the underlying infrastructure but is not in the data path on its own authority.

Use this posture when:

• The institution needs speed of stand-up more than full air-gap
• The procurement reality is hyperscaler-by-default, with sovereignty layered on top via customer-managed keys and a customer-controlled network
• The deployment is a pilot that will migrate to sovereign cloud or on-prem on a published timeline

Typical operators: enterprise teams running a pilot before a production deployment, deployments in jurisdictions without a mature sovereign-cloud option.

What is the same across all four

• One platform image, one update channel format
• Customer-managed keys via external KMS
• Signed binaries with a published verification procedure
• The full ontology, governance, and audit model

What differs across the four

• The network topology
• The mechanism by which signed updates reach the platform
• The set of allow-listed outbound connections (typically zero in air-gapped, a small allow-list in on-prem, broader in cloud postures)
• The operator of the underlying hardware