Sovereign Cloud Stack (SCS): Cloud in a Box Installation and Deployment Guide
Sovereign Cloud Stack (SCS): Cloud in a Box Installation Guide
The Sovereign Cloud Stack (SCS) is Europe's open-source cloud infrastructure framework — a standards-compliant platform that puts digital sovereignty into practice. This guide covers what SCS is and how to deploy your own Cloud in a Box (CIAB), a single-node OpenStack+Kubernetes environment that installs in about two hours with near-full automation.
What Is Sovereign Cloud Stack?
SCS is a project under the Open Source Business Alliance (OSB Alliance), funded by the German Federal Ministry for Economic Affairs and Climate Action (BMWK). It holds Gaia-X lighthouse project status — a recognition that SCS advances the Gaia-X vision of federated, sovereign data infrastructure — and is recognized as a European Digital Infrastructure Consortium (EDIC) candidate.
The project addresses a core tension in modern cloud infrastructure: the dominance of non-European cloud providers and the lock-in risks associated with proprietary APIs. SCS solves this by defining three pillars:
- Open Standards — Certification programs (SCS-OpenStack, SCS-K8s) that ensure workload portability between any compliant provider
- Modular Software Stack — A fully open-source integration of OpenStack, Ceph, and Kubernetes managed by the OSISM deployment framework
- Knowledge Transfer — Training programs, community operations guides, and a certification ecosystem
Any provider running a standards-compliant SCS environment can offer interoperable cloud services. This is the infrastructure equivalent of container images building on OCI standards — you can move workloads between SCS-compliant providers without platform-specific rewriting.
SCS Architecture
The SCS software stack follows a layered architecture, from bare metal hardware up to the user-facing access layer:
Component Breakdown
| Layer | Components | Responsibility |
|---|---|---|
| Hardware & OS | x86_64 server, Ubuntu 24.04 LTS | Physical foundation, networking (DHCP), storage (SATA/NVMe) |
| OSISM | Ansible playbooks, containerized control plane | Deployment, lifecycle management, rolling upgrades, backup/restore |
| OpenStack | Nova, Neutron, Cinder, Glance, Keystone, Designate | Virtual compute, networking, block storage, image registry, identity, DNS |
| Ceph | RADOS, RBD (block), RGW (S3 object), CephFS | Distributed storage — unified block, object, and file |
| Kubernetes | Gardener, Cluster API, Calico/OVN | Container orchestration and cluster lifecycle |
| SCS Standards | SCS-OpenStack, SCS-K8s, IAM (Keycloak) | Compliance verification, identity federation, audit |
| Access | Horizon dashboard, OpenStack CLI, REST API, Terraform | User-facing interfaces for cloud management |
OSISM — The Deployment Engine
OSISM is the deployment and operations framework that manages the full lifecycle of the SCS stack:
- Ansible playbooks for idempotent configuration management
- Containerized control plane for service isolation and easy upgrades
- Release lifecycle tied to OpenStack upstream (twice-yearly cadence)
The R9 release (September 2025) introduced OSISM 10.x with OpenStack Epoxy, Kubernetes 1.33, and switched the default container engine from Docker to containerd.
Cloud in a Box (CIAB)
Cloud in a Box is a single-node OSISM deployment designed for teams that need a complete SCS environment without the complexity of a multi-node cluster.
Use Cases
- Evaluation and testing — Validate SCS compatibility before committing to production infrastructure
- Edge computing — Local cloud capacity at remote sites or branch offices
- Training and workshops — Hands-on OpenStack and Kubernetes labs without shared resources
- CI/CD pipelines — Isolated cloud environments for automated testing at the infrastructure level
CIAB Variants
| Type | Components | Ideal For |
|---|---|---|
| sandbox | Full OpenStack + Ceph + K8s | Complete cloud evaluation on a single node |
| edge | OpenStack (reduced Ceph), central logging | Remote sites with limited storage needs |
| kubernetes | K8s-only, no OpenStack | Teams focused solely on container orchestration |
The sandbox variant is the most common starting point and is the focus of this guide.
Hardware Requirements
| Component | Minimum | Recommended |
|---|---|---|
| CPU | 8 cores (x86_64) | 16+ cores for concurrent workloads |
| RAM | 64 GB | 128 GB (Ceph requires significant memory) |
| Boot Storage | 500 GB SATA SSD | 2+ TB NVMe for VM and Ceph OSD capacity |
| Network | 1 Gbit | 10 Gbit for storage replication performance |
A Supermicro server with 128 GB RAM, a 2 TB NVMe drive, and dual 1 Gbit NICs is a typical community lab setup. The CIAB ISO has separate builds for SATA and NVMe boot drives — selecting the wrong variant will prevent the automated installer from detecting your disk.
Installation Walkthrough
The CIAB installation follows five steps. The total wall-clock time is approximately two hours, but only about five minutes of hands-on work is required.
Step 1: Download the CIAB ISO
Download the appropriate ISO from the SCS CIAB Releases page:
| Variant | Boot Storage | Use Case |
|---|---|---|
ciab-sandbox-sata.iso | SATA SSD | Traditional servers with SATA-connected drives |
ciab-sandbox-nvme.iso | NVMe | Modern servers with NVMe M.2 or U.2 drives |
The ISO (approximately 8–10 GB) contains an Ubuntu 24.04 base system, the OSISM deployment framework, and all required container images.
Step 2: Create a Bootable USB Drive
You need a USB drive with at least 16 GB capacity. Write the ISO using dd on Linux, or use balenaEtcher/Rufus on Windows:
# Identify your USB device
lsblk
# ⚠️ This erases ALL data on /dev/sdX
sudo dd if=ciab-sandbox-nvme.iso of=/dev/sdX bs=4M status=progress conv=fsync
The conv=fsync flag ensures the write buffer is flushed before the command returns, preventing incomplete writes.
Step 3: Boot and Install the Base System
- Insert the USB drive and boot the target server
- Configure boot order to USB (typically F11, F12, or Del during POST)
- The installer runs fully automatically — Ubuntu 24.04 is installed with default partitioning
- After approximately 10 minutes, the system reboots
- Remove the USB drive when the boot menu appears to avoid re-entering the installer
Step 4: Automated OSISM Deployment
After the first reboot, the system starts the automated OSISM deployment. This is the only long wait — roughly 90–120 minutes depending on hardware and network speed.
Prerequisites before deployment begins:
- The primary NIC must receive an IP via DHCP
- The hostname must be resolvable via DNS (forward and reverse)
- Internet access is required for pulling container images
The deployment process:
- OSISM pulls container images for all OpenStack services, Ceph, and Kubernetes
- Ansible playbooks configure each service with CIAB-appropriate defaults
- A WireGuard VPN is set up for secure administrative access
- The Horizon dashboard and OpenStack CLI are configured with test credentials
- Clouds.yaml and test credentials are written to
/home/dragon/
You can monitor progress via the local console or SSH:
# Watch real-time deployment logs
journalctl -fu osism-deployment -n 100
# Check OSISM container status
osism container status
# View Ansible playbook output
tail -f /opt/osism/ansible.log
Step 5: Access Your Cloud
Once deployment completes, you have two access paths:
Horizon Dashboard (Web UI):
http://ciab.fritz.box:8080
Or use the server's IP address on port 8080. Credentials are displayed on the console at the end of deployment and saved to /home/dragon/secure/.
OpenStack CLI (via WireGuard VPN): The CIAB deploys a WireGuard VPN endpoint for secure API access:
# Install WireGuard on your client
sudo apt install wireguard
# Import the CIAB client configuration
sudo wg-quick up /path/to/ciab-client.conf
# Authenticate (uses CIAB's built-in clouds.yaml)
export OS_CLOUD=test
# Verify the cloud is operational
openstack compute service list
openstack network agent list
openstack image list
The OS_CLOUD=test environment variable selects the CIAB's pre-configured clouds.yaml section, which points to the local Keystone endpoint with admin credentials.
Post-Installation: First Workload
With the cloud running, deploy your first virtual machine:
# Create a network and subnet
openstack network create demo-net
openstack subnet create --network demo-net \
--subnet-range 10.1.0.0/24 \
--dns-nameserver 8.8.8.8 demo-subnet
# Create a router and connect to the external network
openstack router create demo-router
openstack router add subnet demo-router demo-subnet
openstack router set --external-gateway public demo-router
# Create a security group allowing SSH
openstack security group create demo-ssh
openstack security group rule create --proto tcp --dst-port 22 demo-ssh
# Boot a test VM
openstack server create \
--image ubuntu-24.04 \
--flavor m1.small \
--network demo-net \
--security-group demo-ssh \
--key-name my-key \
demo-vm
# Assign a floating IP
openstack floating ip create public
openstack server add floating ip demo-vm <IP>
# SSH into the instance
ssh ubuntu@<FLOATING_IP>
Attach persistent block storage:
openstack volume create --size 20 demo-volume
openstack server add volume demo-vm demo-volume
# Inside the VM:
# sudo mkfs.ext4 /dev/vdb
# sudo mount /dev/vdb /mnt/data
SCS Release Cycle
SCS follows a predictable twice-yearly release cadence:
| Release | Date | OSISM | OpenStack | Kubernetes | Highlights |
|---|---|---|---|---|---|
| R8 | March 2025 | 9.x | Zed | 1.30 | Initial CIAB stabilization |
| R9 | September 2025 | 10.x | Epoxy | 1.33 | containerd default, enhanced CIAB |
| R10 | March 2026 | 11.x | Next | 1.35+ | TBD |
This cadence aligns with OpenStack upstream releases (spring/autumn), allowing operators to plan upgrades on a fixed schedule similar to Ubuntu LTS.
When to Choose CIAB vs. Full Cluster
| Scenario | CIAB | Full Cluster |
|---|---|---|
| Dev/test environment | ✅ Ideal | ❌ Overkill |
| Edge/pop-up cloud | ✅ Perfect | ❌ Too complex |
| Training/workshops | ✅ Great | ⚠️ Possible |
| Production workloads | ❌ No HA | ✅ Required |
| Multi-tenant SaaS | ❌ No isolation | ✅ Full multi-node |
| High availability | ❌ Single point of failure | ✅ HA with Ceph replication |
CIAB is a single-node setup with no built-in redundancy. For production, use the full OSISM cluster deployment with at least three control nodes and three Ceph nodes.
Community and Support
SCS has an active community where you can get help:
- Matrix Chat:
#scs:matrix.org— Community discussions and real-time support - SCS Community Forum: scs.community/discuss
- GitHub Issues: github.com/SovereignCloudStack — Bug reports and feature requests
- OSISM Documentation: docs.osism.tech — Detailed deployment and operations reference
Cost Estimate
A CIAB-capable server costs roughly €2,000–5,000 depending on configuration:
| Component | Budget | Recommended |
|---|---|---|
| Server | Supermicro SYS-510 (€800) | Supermicro SYS-110 (€1,500) |
| RAM | 64 GB (€400) | 128 GB (€800) |
| Storage | 1 TB NVMe (€150) | 2 TB NVMe (€300) |
| Total | ~€2,000 | ~€3,500–5,000 |
These are one-time hardware costs. There are no license fees — the entire SCS stack is open source.
Upgrading CIAB
SCS follows a twice-yearly release cadence. CIAB upgrades follow the standard OSISM upgrade path:
# Update OSISM to the latest release
osism update --release R10
# Run upgrade playbooks
osism apply upgrade
# Verify all services
site-services status
Conclusion
Sovereign Cloud Stack's Cloud in a Box delivers a production-grade OpenStack and Kubernetes environment on a single server, deployable in under two hours with minimal operator intervention. It serves as an entry point into European sovereign cloud infrastructure and a practical tool for evaluating SCS as a platform.
Workloads developed and tested on a CIAB will run without modification on any SCS-compliant provider — turning sovereign cloud infrastructure from a concept into a deployable reality.
Links: