Swirl.SWIRL CLOUD
How Swirl Cloud works. From bare servers to applications in production.
A setup hub prepares your servers, installs every layer of the platform and verifies the result. From then on, Git describes the desired state, and the platform and your applications continuously converge on it.
Installation
Prepare
Ubuntu servers, rented or owned, and a domain name. A first server needs at least 8 cores, 32 GB of memory and 500 GB NVMe.
Answer the hub
The hub, in English or French, checks the server, asks only what an express installation needs (or everything in advanced mode) and tests your tokens before installing.
Install and verify
Kubernetes, storage, ingress, Vault, data services, single sign-on, GitLab, Argo CD and Odoo are installed in order, then checked.
Grow
The same hub adds servers and imports your application repositories. Saved answers let you rerun the installation unattended.
Architecture
- Access
- Visitors and teamsBrowser, Git, APIs
- Edge
- CloudflareDNS, TLS, web firewall, administration access
- Entry
- TraefikRoutes every address
- KeycloakSingle sign-on
- Services
- PlatformGitLab · Argo CD · Grafana · Kibana · Trivy · SonarQube
- Your applicationsint · uat · prod
- OdooERP · CRM · chat
- Data
- Databases and messagingPostgreSQL · MongoDB · Redis · Kafka
- VaultSecrets, delivered by External Secrets
- Foundation
- KubernetesOn Ubuntu servers
- LonghornReplicated storage
- Private networkvRack · Tailscale · LAN
From commit to production
Push
A commit lands in the application’s GitLab project.
Build
CI tests the code and publishes an immutable image to the platform registry.
Promote
CI records the image digest in Git for the target environment: int, uat or prod.
Deploy
Argo CD applies the release, then CI checks the revision, health and public address.
High availability and recovery
One server, then several
Everything runs on a single server. Added servers join the cluster over a private network and take workloads and storage replicas.
High availability when you need it
A profile for three or more control-plane servers: embedded etcd, ingress on every server, replicated PostgreSQL, Kafka and Redis, and a readiness check before activation. The three-server failover drill is still to come.
Recovery archive
Every night: the Kubernetes state, a Vault snapshot, PostgreSQL and MongoDB dumps, Odoo’s files and the restore procedure. Seven local copies; optionally an encrypted off-site copy kept for 7 days, 5 weeks and 12 months.
Failure drills
Outside production, a drill deletes one pod of each service, measures how long each takes to come back and probes the environment’s addresses; the result goes into the monthly report.
Measured, not promised
Measured on our own single-server installation in October 2026.
- Reserved by platform services
- about 5.4 cores and 16 GiB
- Peak CPU use, applications included
- 3 cores
- Public addresses probed (99.5% objective)
- 25
- Service back after losing a pod
- 7 to 47 seconds
- Recovery point of the nightly archive
- up to 24 hours