---
title: xyOps
created: 2026-06-07
updated: 2026-06-07
type: app
tags: [catalogue, monitoring, automation, orchestration, php, server-management, homelab, msp]
confidence: high
contested: false
sources: [https://selfh.st/apps/?tag=Monitoring, https://github.com/pixlcore/xyops]
---

# 📊 xyOps

> **L'alternative légère à Ansible, Puppet et Nagios combinés** : xyOps orchestre vos serveurs, exécute vos jobs planifiés, surveille vos services et envoie vos alertes — le tout dans une interface web unique écrite en PHP, sans la complexité d'une stack d'entreprise.

## 📋 Informations Générales

| Champ | Valeur |
| :--- | :--- |
| **Site web** | [pixlcore.com/xyops](https://www.pixlcore.com/xyops) |
| **GitHub** | [pixlcore/xyops](https://github.com/pixlcore/xyops) |
| **License** | MIT |
| **Langage** | PHP |
| **Étoiles GitHub** | 4 313 ⭐ |
| **Dernière MAJ** | 2026-06-05 |
| **Catégorie** | [[cat-monitoring\|Monitoring]] |

## 📝 Description

**xyOps** est une **suite d'automatisation et de monitoring de serveurs** écrite en PHP par PixlCore (la même équipe derrière PixlDashboard et WebTools). Son parti pris : remplacer la triplette « Ansible pour la config, Puppet/Chef pour l'état, Nagios/Zabbix pour le monitoring » par **une seule plateforme web**, accessible depuis un navigateur, qui pousse des scripts et des checks sur les agents installés sur vos machines.

L'architecture est simple : un **serveur central xyOps** héberge l'UI, planifie les jobs, collecte les métriques et déclenche les alertes ; des **agents xyOps** (Windows, macOS, Linux) s'enregistrent auprès du serveur via une clé d'API unique, reçoivent des **jobs** (commandes shell, scripts PowerShell/Bash, PlayJobs xyOps) et renvoient leur sortie + statut. Les agents peuvent aussi remonter des **checks de monitoring** (CPU, RAM, disk, services, processus, URLs) et **déclencher des alertes** en cas de dépassement de seuils.

Le format « **PlayJob** » est l'ingrédient magique : ce sont des jobs structurés en sections (`info`, `init`, `run`, `done`, `error`, `cleanup`) qui peuvent être enchaînés, parallélisés, conditionnés sur le résultat d'un autre job. Pour un homelabber qui veut provisionner un nouveau serveur, déployer une stack Docker, sauvegarder un dossier, puis vérifier que le service répond, c'est un workflow déclaratif et re-jouable.

- ✅ **Multi-plateforme** : agents pour **Linux, Windows, macOS** (binaires natifs + scripts)
- ✅ **Push-based** : pas de port à ouvrir, l'agent initie les connexions sortantes
- ✅ **Exécution de jobs** : shell, PowerShell, scripts arbitraires, PlayJobs structurés
- ✅ **Planification riche** : cron, déclencheurs (autre job terminé), manuel, webhooks
- ✅ **Monitoring intégré** : CPU/RAM/disk, services, processus, ports, URLs HTTP, certificats SSL
- ✅ **Alertes multi-canaux** : Email, Slack, Discord, Telegram, Ntfy, Gotify, Pushover, webhook
- ✅ **UI web moderne** : dashboard, vue des jobs en temps réel, historique, logs
- ✅ **Multi-tenants** : plusieurs organisations / équipes dans la même instance
- ✅ **API REST** complète pour intégration / automation
- ✅ **Packages** : Docker (non officiel mais classique), binaires PHP auto-hébergés

**Public cible** : **homelabbers, MSP, petites équipes DevOps** qui veulent automatiser 5-50 serveurs sans se former à Ansible + AWX + Prometheus + Alertmanager. Pour 200+ nœuds, des outils comme Ansible AWX, Rundeck ou SaltStack restent plus adaptés.

**Limites à connaître** : le projet est **mono-mainteneur** (PixlCore, très actif mais équipe réduite), la documentation est moins étoffée que celle d'Ansible, et l'écosystème de modules communautaires est limité (on écrit ses propres jobs). L'**agent doit être installé** sur chaque machine surveillée (à la différence de [[app-pulse]] qui n'a besoin que d'un accès API).

## 🚀 Installation

### Option 1 : Docker Compose

```yaml
# docker-compose.yml
version: '3.8'

services:
  xyops:
    image: ghcr.io/pixlcore/xyops:latest
    container_name: xyops
    restart: unless-stopped
    ports:
      - "8888:80"   # Web UI
    environment:
      - XYOX_VERSION=latest
      - XYOX_HOSTNAME=xyops.example.com
    volumes:
      - xyops-data:/var/www/html/data
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.xyops.rule=Host(`xyops.example.com`)"
      - "traefik.http.routers.xyops.entrypoints=websecure"
      - "traefik.http.routers.xyops.tls.certresolver=letsencrypt"

volumes:
  xyops-data:
```

### Option 2 : Installation native (PHP 8.x + Nginx)

```bash
# Prérequis : PHP 8.1+ avec extensions curl, mbstring, mysqli, pdo, openssl
sudo apt install -y php-fpm php-curl php-mbstring php-mysql php-sqlite3 nginx

# Télécharger la dernière release
wget https://github.com/pixlcore/xyops/releases/latest/download/xyops.tar.gz
sudo mkdir -p /var/www/xyops
sudo tar -xzf xyops.tar.gz -C /var/www/xyops
sudo chown -R www-data:www-data /var/www/xyops

# Configurer Nginx (virtual host pointant sur /var/www/xyops)
# Voir https://github.com/pixlcore/xyops/blob/main/INSTALL.txt
```

xyOps utilise par défaut **SQLite** (zéro config), ce qui est parfait pour un homelab. Pour de la production à fort volume, basculer sur **MySQL/MariaDB** est supporté nativement.

### Installation d'un agent

```bash
# Sur le serveur à superviser (Linux)
curl -s https://xyops.example.com/api/install/linux | bash

# Windows : télécharger l'installateur depuis l'UI xyOps > Agents > New
# macOS : équivalent, pkg ou commande curl
```

L'agent s'enregistre automatiquement, récupère ses jobs planifiés, et établit un **WebSocket** persistant vers le serveur (push, pas de port à ouvrir côté agent).

## ⚙️ Configuration Initiale

1. **Accéder à l'UI** : `https://xyops.example.com` (ou `http://IP:8888`)
2. **Créer le compte admin** au premier lancement (formulaire web)
3. **Créer un premier serveur** : Servers → Add Server
   - Hostname, IP, OS, tags (ex : `prod`, `web`, `db`)
   - xyOps génère une **clé d'enregistrement** que l'agent utilisera
4. **Installer l'agent** sur le serveur (cf. bloc ci-dessus) et vérifier la connexion (badge vert dans Servers)
5. **Créer un PlayJob** : Jobs → New PlayJob
   - Sections `init` (préparation) et `run` (commande principale)
   - Exemple `run` : `systemctl status nginx | head -5`
6. **Planifier le job** : Cron `*/5 * * * *` ou « on server check failure »
7. **Configurer un check monitoring** : Monitors → New Monitor
   - Type « HTTP » : URL `https://example.com`, code attendu `200`, intervalle 60 s
   - Lier au canal de notification (Telegram/Discord)
8. **Tester** : arrêter Nginx sur un serveur et vérifier que l'alerte arrive en moins d'une minute

## 🔄 Alternatives

### Open Source

- **Ansible** + AWX — la référence configuration management, mais sans UI de monitoring intégrée
- **Puppet** / **Chef** / **SaltStack** — enterprise, plus lourds à apprendre
- **Rundeck** — orchestration de jobs avec UI web, plus connu en entreprise
- **Foreman** — provisionning + config management, orienté datacenters
- **Cockpit** — UI web système pour Linux, plus simple mais moins puissant
- [[app-uptime-kuma]] — pour l'uptime check uniquement
- [[app-netdata]] — monitoring système sans orchestration
- [[app-prometheus]] + Alertmanager — alerting pro, mais sans jobs d'automatisation

### Comparaison xyOps vs solutions d'orchestration

| Critère | xyOps | Ansible AWX | Rundeck | Puppet Enterprise |
| :--- | :--- | :--- | :--- |
| **Langage** | PHP | Python (playbooks YAML) | Java | Ruby |
| **Push vs Pull** | Push (agent) | Push (SSH) | Push (SSH/agent) | Pull (agent) |
| **UI web** | ✅ intégrée | ✅ AWX | ✅ intégrée | ✅ (Enterprise) |
| **Monitoring intégré** | ✅ natif | ❌ (à ajouter) | ⚠️ basique | ⚠️ via PuppetDB |
| **Alertes intégrées** | ✅ multi-canal | ❌ (à ajouter) | ⚠️ plugins | ⚠️ |
| **Multi-OS** | ✅ Linux/Win/macOS | ✅ (SSH) | ✅ (SSH) | ✅ (agent) |
| **Courbe d'apprentissage** | Faible | Moyenne | Moyenne | Élevée |
| **Scalabilité** | 5-50 serveurs | Centaines | Centaines | Milliers |
| **License** | MIT | Apache-2.0 | Apache-2.0 | Propriétaire (CE GPL) |
| **Communauté** | Petite | Énorme | Grande | Grande |

**Verdict** : xyOps est **la bonne pioche** pour qui veut **un seul outil** pour orchestrer, surveiller et alerter un parc modeste sans empiler 5 produits. Pour un grand parc avec des playbooks complexes, Ansible AWX reste incontournable. Pour un monitoring pur, [[app-uptime-kuma]] ou [[app-netdata]] sont plus spécialisés.

### Propriétaires (ce que xyOps remplace)

- **TeamCity** (JetBrains) — orchestration CI/CD, cher en enterprise
- **Octopus Deploy** — releases multi-environnements
- **StackStorm** — event-driven automation, plus complexe
- **Puppet Enterprise** — paywall sur les fonctionnalités avancées
- **JFrog Platform** — DevOps enterprise complet

## 🔐 Sécurité

- **Activer HTTPS** via [[app-traefik]] — xyOps expose des credentials et des sorties de commandes sensibles (l'UI peut montrer des logs contenant des mots de passe)
- **Utiliser des secrets xyOps** : ne jamais écrire un mot de passe en clair dans un PlayJob ; utiliser le store de secrets natif (chiffré au repos)
- **Restreindre l'accès à l'UI** : auth locale + IP allowlist ; limiter les **rôles** (Admin, Operator, Viewer) au strict nécessaire
- **Agents** : la clé d'enregistrement se saisit une seule fois ; si compromise, révoquer depuis l'UI. Activer le **chiffrement TLS** pour le WebSocket agent → serveur (par défaut)
- **Auditer les jobs** : qui peut créer un PlayJob ? qui peut l'exécuter sur quel serveur ? xyOps log tout, mais il faut le lire (UI > Audit Log)

## 📚 Ressources

- [GitHub pixlcore/xyops](https://github.com/pixlcore/xyops)
- [Site officiel](https://www.pixlcore.com/xyops)
- [Documentation](https://github.com/pixlcore/xyops/blob/main/README.md)
- [INSTALL.txt](https://github.com/pixlcore/xyops/blob/main/INSTALL.txt)

## Pages Liées

- [[cat-monitoring]] — Catégorie Monitoring
- [[app-uptime-kuma]] — Pour l'uptime check
- [[app-netdata]] — Métriques système temps réel
- [[app-prometheus]] — Stack cloud-native
- [[app-glances]] — Monitoring terminal
- [[app-traefik]] — Reverse proxy HTTPS
- [[observabilite]] — Concepts monitoring/alerting
- [[checklist-monitoring-minimal]] — Checklist de déploiement