Skip to main content
← Back to scs

Sovereign Cloud Stack (SCS): Cloud in a Box Installation and Deployment 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:

  1. Open Standards — Certification programs (SCS-OpenStack, SCS-K8s) that ensure workload portability between any compliant provider
  2. Modular Software Stack — A fully open-source integration of OpenStack, Ceph, and Kubernetes managed by the OSISM deployment framework
  3. 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:

SCS Sovereign Cloud Stack Architecture SCS layered architecture: OSISM orchestrates OpenStack, Ceph, and Kubernetes under SCS compliance standards.

Component Breakdown

LayerComponentsResponsibility
Hardware & OSx86_64 server, Ubuntu 24.04 LTSPhysical foundation, networking (DHCP), storage (SATA/NVMe)
OSISMAnsible playbooks, containerized control planeDeployment, lifecycle management, rolling upgrades, backup/restore
OpenStackNova, Neutron, Cinder, Glance, Keystone, DesignateVirtual compute, networking, block storage, image registry, identity, DNS
CephRADOS, RBD (block), RGW (S3 object), CephFSDistributed storage — unified block, object, and file
KubernetesGardener, Cluster API, Calico/OVNContainer orchestration and cluster lifecycle
SCS StandardsSCS-OpenStack, SCS-K8s, IAM (Keycloak)Compliance verification, identity federation, audit
AccessHorizon dashboard, OpenStack CLI, REST API, TerraformUser-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 OpenStack Epoxy (2025.1) and Kubernetes 1.33.


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

TypeComponentsIdeal For
sandboxFull OpenStack + Ceph + K8sComplete cloud evaluation on a single node
edgeOpenStack (reduced Ceph), central loggingRemote sites with limited storage needs
kubernetesK8s-only, no OpenStackTeams focused solely on container orchestration

The sandbox variant is the most common starting point and is the focus of this guide.

Hardware Requirements

ComponentMinimumRecommended
CPU8 cores (x86_64)16+ cores for concurrent workloads
RAM64 GB128 GB (Ceph requires significant memory)
Boot Storage500 GB SATA SSD2+ TB NVMe for VM and Ceph OSD capacity
Network1 Gbit10 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.

CIAB Installation Flow CIAB installation in five steps: most of the time is the automated deployment phase.

Step 1: Download the CIAB ISO

Download the appropriate ISO from the OSISM CIAB documentation:

ISO FileBoot StorageUse Case
ubuntu-autoinstall-cloud-in-a-box-1.isoSATA/SAS (first block device /dev/sda)Traditional servers with SATA-connected drives
ubuntu-autoinstall-cloud-in-a-box-2.isoNVMe (first block device /dev/nvme0n1)Modern servers with NVMe M.2 or U.2 drives

Each ISO (approximately 8–10 GB) contains an Ubuntu 24.04 base system, the OSISM deployment framework, and all required container images. The CIAB install scripts are also available at the OSISM CIAB repository for inspection or custom deployments.

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

  1. Insert the USB drive and boot the target server
  2. Configure boot order to USB (typically F11, F12, or Del during POST)
  3. The installer runs fully automatically — Ubuntu 24.04 is installed with default partitioning
  4. After approximately 10 minutes, the system reboots
  5. 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:

  1. OSISM pulls container images for all OpenStack services, Ceph, and Kubernetes
  2. Ansible playbooks configure each service with CIAB-appropriate defaults
  3. A WireGuard VPN is set up for secure administrative access
  4. The Horizon dashboard and OpenStack CLI are configured with test credentials
  5. 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. The default SSH user is dragon with password password — change these immediately for any internet-connected deployment.

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:

ReleaseDateOSISMOpenStackKubernetesHighlights
R8March 20259.xZed1.30Initial CIAB stabilization
R9September 202510.xEpoxy1.33K8s 1.33, improved CIAB
R10March 202611.xNext1.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

ScenarioCIABFull 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:

Cost Estimate

A CIAB-capable server costs roughly €2,000–5,000 depending on configuration:

ComponentBudgetRecommended
ServerSupermicro SYS-510 (€800)Supermicro SYS-110 (€1,500)
RAM64 GB (€400)128 GB (€800)
Storage1 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: