--- title: Uncloud created: 2026-06-07 updated: 2026-06-07 type: app tags: [catalogue, deployment, docker-swarm, cluster, go] confidence: high contested: false sources: [https://selfh.st/apps/?tag=Deployment, https://github.com/psviderski/uncloud] --- # 🚀 Uncloud > **L'orchestrateur Docker multi-host** — cluster Docker Swarm simplifiĂ©, CLI puissante, machine images dĂ©ployables en quelques secondes, idĂ©al pour gĂ©rer un parc de serveurs hĂ©tĂ©rogĂšnes. ## 📋 Informations GĂ©nĂ©rales | Champ | Valeur | | :--- | :--- | | **Site web** | [uncloud.run](https://uncloud.run/) | | **GitHub** | [psviderski/uncloud](https://github.com/psviderski/uncloud) | | **License** | Apache-2.0 | | **Langage** | **Go** (⚠ binaire statique) | | **Étoiles GitHub** | 5 204 ⭐ | | **CatĂ©gorie** | [[cat-deployment\|Deployment & PaaS]] | ## 📝 Description **Uncloud** est un **orchestrateur de cluster Docker** rĂ©cent (2024) créé par Pavlo Shvidersky (un dĂ©veloppeur Go rĂ©putĂ©). Sa promesse : **rendre Docker Swarm aussi simple Ă  utiliser que Docker Compose**, mais avec les bĂ©nĂ©fices d'un vrai cluster multi-host (haute disponibilitĂ©, scaling, rolling updates). La **CLI `unc`** est le cƓur de l'expĂ©rience : un seul binaire Go, statique, qui se connecte Ă  un **control plane** auto-hĂ©bergĂ© (un seul conteneur Docker). Avec `unc deploy `, on dĂ©clare un service (rĂ©plicas, ressources, ports, healthcheck) et Uncloud le **planifie sur le cluster Swarm** automatiquement, en rĂ©partissant la charge. Les `unc machine` permettent de provisionner des **machines distantes** (VPS, Hetzner, Scaleway, DigitalOcean, Vultr) depuis la CLI. L'**innovation** est la **machine image** : un format dĂ©claratif (YAML) qui dĂ©crit un service complet (image, env, volumes, healthcheck, scaling, rĂ©seau). On peut **versionner ces dĂ©finitions dans Git** et les **redeployer** sur n'importe quel cluster Uncloud. C'est **GitOps pour Docker Swarm**. **DiffĂ©rences avec les PaaS classiques** : Uncloud **n'a pas d'UI web** (CLI + Ă©ventuellement TUI), il **ne cache pas Docker Swarm** (il s'appuie dessus), il est **orientĂ© SRE/dev** qui veulent un **workflow `compose.yml → cluster`** sans Kubernetes. C'est **plus bas niveau** que Coolify mais **plus puissant** qu'un docker-compose manuel. **Public cible** : **devs Go / SRE** qui aiment la CLI, **Ă©quipes** qui veulent industrialiser un cluster Swarm, **homelabbers avancĂ©s** qui sortent du mono-serveur. Pour un PaaS avec UI, [[app-coolify]] / [[app-dokploy]] ; pour Swarm "PaaS-y", [[app-caprover]]. ## 🚀 Installation ### Installation de la CLI (Linux/macOS) ```bash # Via le binaire prĂ©-compilĂ© curl -fsSL https://github.com/psviderski/uncloud/releases/latest/download/unc-linux-amd64 -o /usr/local/bin/unc chmod +x /usr/local/bin/unc unc version # vĂ©rif ``` ### Initialisation d'un cluster ```bash # Sur le premier host (control plane) unc init # Cette commande : # - initialise Docker Swarm # - dĂ©marre le control plane Uncloud # - configure le contexte CLI local # Sur chaque host additionnel (worker) unc machine create ssh://user@host2.example.com # Uncloud provisionne Swarm + joint le cluster automatiquement ``` ### docker-compose.yml du control plane (auto-installĂ©) ```yaml # GĂ©nĂ©rĂ© par `unc init`, pas besoin de l'Ă©crire manuellement services: uncloud-api: image: ghcr.io/psviderski/uncloud:latest container_name: uncloud-api restart: unless-stopped ports: - "8080:8080" # API volumes: - /var/run/docker.sock:/var/run/docker.sock - ./data:/data network_mode: host ``` > ⚠ **L'API Uncloud a besoin d'accĂ©der au socket Docker** de l'hĂŽte. Isoler sur un hĂŽte de confiance. ## ⚙ Configuration 1. **Initialiser le cluster** : `unc init` sur le host principal 2. **Ajouter des machines** : `unc machine create ssh://user@host` (Hetzner, Scaleway, VPS perso, etc.) 3. **DĂ©ployer un service** : `unc deploy -i nginx:latest --replicas 3 --port 80:80 nginx` 4. **Machine image (GitOps)** : crĂ©er un `nginx.yml` avec `image`, `replicas`, `healthcheck`, `ports` ; `unc apply -f nginx.yml` 5. **Scaler** : `unc scale nginx=5` (rolling update sur le cluster) 6. **Load balancing** : Uncloud crĂ©e un **service mesh** Swarm interne, les services se dĂ©couvrent par DNS 7. **TLS** : provisionner un reverse proxy (Traefik, Caddy) devant, ou activer le `unc proxy` intĂ©grĂ© 8. **Logs centralisĂ©s** : `unc logs nginx -f` agrĂšge les logs des 3 replicas ## 🔗 Alternatives - **Docker Swarm natif** — sous-jacent Ă  Uncloud, plus bas niveau - **Coolify** — PaaS UI web, plus user-friendly, pas Swarm-first - **Dokploy** — concurrent de Coolify, UI Next.js - **CapRover** — PaaS Swarm avec UI web, plus ĂągĂ© - **Kubernetes (K3s)** — orchestrateur plus puissant mais beaucoup plus complexe - **Nomad** — alternative Ă  K8s par HashiCorp, plus simple - **Pulumi / Ansible + Compose** — DIY, plus de contrĂŽle, plus verbeux - **Fly.io** — PaaS managĂ© multi-rĂ©gion, Ă©quivalent cloud ## 🔒 SĂ©curitĂ© - **SSH key auth** : Uncloud utilise SSH pour provisionner les machines, **dĂ©sactiver le password auth** - **mTLS Swarm** : activer `--listen-addr` avec un cert sur le control plane - **Compte Uncloud** : un premier compte créé Ă  `unc init`, **2FA recommandĂ©e** - **Volumes chiffrĂ©s** : utiliser des **drivers de volumes chiffrĂ©s** (LUKS, ZFS crypt) sur les hosts - **Limiter l'accĂšs au socket Docker** : isoler le control plane sur un hĂŽte dĂ©diĂ© - **Mettre Ă  jour** : `unc update` rĂ©guliĂšrement (CLI + control plane) ## 📚 Ressources - [Site officiel](https://uncloud.run/) - [Documentation](https://uncloud.run/docs) - [DĂ©pĂŽt GitHub psviderski/uncloud](https://github.com/psviderski/uncloud) - [Exemples de machine images](https://github.com/psviderski/uncloud/tree/main/examples) - [Uncloud vs Kubernetes (blog)](https://uncloud.run/blog) ## 🔗 Pages LiĂ©es - [[cat-deployment]] - [[app-coolify]] - [[app-dokploy]] - [[app-caprover]] - [[app-portainer]] - [[cat-docker]] - [[securisation-home-lab]] - [[recettes-docker-compose]]