wiki/Catalogue-Self-Hosted/apps/app-uncloud.md

---
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 <image>`, 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]]