WZ-IT supports this through the relevant service: Proxmox for public authorities.
Digital sovereignty requires practical control. ZenDiS addresses critical dependencies and exit and migration strategies. For virtualization this leads to a concrete question: can you retain control over data, administration and operations when changing providers?
As of October 2026. The technical statements follow the linked primary sources.
Contents
- What Proxmox contributes
- Assess sovereignty through evidence
- Inventory the dependencies
- Distinguish Germany and operator control
- Accept exit paths and operational knowledge
What Proxmox contributes
Proxmox VE is an open-source virtualization platform using KVM and LXC (product overview). The feature overview also describes the REST API for administrative tasks. Open code and documented interfaces can support integration; they do not remove dependencies on hardware, storage design or operational skills.
A licence alone does not complete a provider exit. This checklist assesses technical and organisational control, not the legal classification of a cloud product.
Assess sovereignty through evidence
| Control area | Required evidence | Warning sign |
|---|---|---|
| Location | Locations for production data and backups | Only the VM location is known |
| Administration | Named roles and documented revocation | Shared third-party accounts only |
| Keys | Ownership and recovery access documented separately | Keys held only by the operator |
| Interfaces | Documented API, configuration and export path | Undocumented proprietary extra layer |
| Skills | Runbook and traceable changes | Verbal handover only |
| Exit | Recovery checked on an independent target | Backup without a usable recovery path |
These are proposed acceptance criteria, not automatic properties of every Proxmox service.
Inventory the dependencies
Sovereignty depends on the layers below and beside the hypervisor. An inventory assigns each layer a degree of replaceability:
| Layer | Typical dependency | Exit question |
|---|---|---|
| Hardware | Server model, firmware, supplier | Does the system run on other standard hardware? |
| Hypervisor | Proxmox VE, guest formats | Can guests be exported to open formats (qcow2, raw)? |
| Storage | ZFS, Ceph, shared storage | Which data lives where, how is it backed up externally? |
| Network | Provider VLAN, public IPs | Are addresses and routes transferable? |
| Backup | PBS, keys, offsite target | Is recovery possible without the current operator? |
| Identity | Realms, directory service, tokens | Who can revoke and reissue access? |
| Operational knowledge | Documentation, scripts, runbooks | Can a second administrator take over operations? |
Distinguish Germany and operator control
A location in Germany answers the location question, not every question about administrative access or dependency. Inventory providers and key ownership. For PBS, client-side encryption is one technical component; it requires separately available keys and does not prevent deletion.
For infrastructure in Germany WZ-IT provides Proxmox on STACKIT. Deployment, backup locations and access must be specified in the proposal; this does not establish a blanket sovereignty or compliance guarantee.
Accept exit paths and operational knowledge
Proposed acceptance: export configuration and inventory, recover a selected guest on an independent target, check networking and the application, and hand documentation to a second administrator. Record remaining dependencies.
Example: export an exit inventory. The following commands save configuration and inventory read-only as text files (adjust paths; the files contain network and permission information and must be stored protected):
pvesh get /cluster/resources --output-format json > cluster-inventory.json
pvecm status > cluster-status.txt
pvesm status > storage-status.txt
pveum user list > users.txt
pveum acl list > permissions.txt
for id in $(qm list | awk 'NR>1 {print $1}'); do qm config $id > vm-$id.conf; done
for id in $(pct list | awk 'NR>1 {print $1}'); do pct config $id > ct-$id.conf; done
cp /etc/network/interfaces network-interfaces.txt
Together with the backups these files form the basis for reconstructing the setup on other infrastructure. For the actual recovery on an independent target see restore a Proxmox host with PBS.
For administrative environments contact Proxmox services for authorities; for ongoing operations see Managed Proxmox. Documented public deployments provide context but do not replace acceptance of your environment.
Further reading
Relevant service: Proxmox for public authorities.
