Openship

Du dépôt GitHub au domaine en Let's Encrypt

Openship est une plateforme de déploiement auto-hébergée, écrite en TypeScript. On lui confie un dépôt GitHub, un dossier local ou un artefact déjà construit : elle construit l'application, la lance en conteneur ou en processus supervisé, puis la publie sur un domaine avec un certificat Let's Encrypt. Elle se pilote depuis une application de bureau, un tableau de bord web ou une CLI.

Openship déploie des applications ; administrer des sites web à la manière de cPanel relève d'un panneau d'hébergement comme OpenPanel.

Le comparatif des PaaS auto-hébergés met en regard ce que chaque outil installe sur le serveur et ce qu'il exige.

Configuration déduite du code, rollbacks à l'identique

• Aucun fichier de configuration à écrire : Openship lit package.json, la configuration du framework et les lockfiles pour en déduire les commandes de build et de démarrage, ainsi que le port. Un openship.json versionné avec le code prend le pas sur ces déductions.
• Des retours arrière exacts : chaque déploiement fige sa configuration dans un instantané, et un rollback relance exactement ce qui avait été livré.
• Un certificat raté ne fait pas tomber l'application : le routage et le TLS passent après le démarrage, et une erreur de DNS s'affiche en « action requise » sans bloquer le déploiement.
• Push-to-deploy adapté aux monorepos : le webhook GitHub ne reconstruit que les services touchés par le push.
• Les services autour de l'application : Postgres, MySQL, MongoDB, Redis, sauvegardes planifiées des bases et des volumes, serveur mail avec DKIM, SPF et DMARC.
• Plusieurs serveurs depuis la v0.8.0 : Openship installe k3s sur des serveurs joints en SSH et répartit une application sur 1 à 100 répliques.

Projet en 0.x, moteur mail embarqué sous GPL v3

Le mode serveur complet exige Linux, Docker et les ports 80 et 443. Sur un Linux avec Docker, openship up lance Postgres, Redis, l'API, le tableau de bord et un edge OpenResty. L'API monte le socket Docker de l'hôte, ce que la documentation d'installation assimile à un accès root : le README demande un hôte de confiance. Ailleurs, Openship tourne en mode « bare » : un seul processus à base embarquée, qui déploie vers d'autres serveurs en SSH. La page d'installation ne fixe aucun minimum de mémoire ni de processeur.

L'application de bureau vise le développeur seul. Le plan de contrôle y tourne sans compte, et seulement tant que l'application est ouverte. Faute d'adresse publique, elle ne reçoit pas les webhooks : le push-to-deploy et le travail en équipe demandent une instance serveur allumée en permanence, avec connexion obligatoire.

Openship se mesure à Coolify, Dokploy et Dokku. Sa page d'accueil revendique deux écarts avec Coolify et ses voisins : aucun plan de contrôle à garder allumé avec l'application de bureau, et la reprise d'un serveur déjà en service, dont Openship adopterait les conteneurs sans les reconstruire.

Apache-2.0 pour le code d'Openship, GPL v3 pour le moteur mail. Le moteur iRedMail, sous GPL v3, est copié dans l'image Docker de l'API, le paquet CLI et l'application de bureau, même quand le mail ne sert pas. La provenance du webmail Zero Email reste à établir (ticket #610).

L'auto-hébergement est gratuit, Openship Cloud est payant. Une instance auto-hébergée n'a pas de facturation, dit le README. Depuis la v0.8.1, Openship Cloud loue des serveurs gérés au mois, de 5 $ (1 vCPU, 4 Gio de RAM) à 99 $ (8 vCPU, 32 Gio).

Une version 0.x, un développeur principal. Le dépôt date de mars 2026. Vingt-trois versions sont sorties du 13 juillet au 6 octobre, et un même développeur signe 1 251 des 1 684 commits de la branche principale. Le README annonce un « cœur prêt pour la production », mais range encore parmi les fonctions à venir les clusters multi-nœuds, livrés par la v0.8.0 le 27 septembre. La v0.8.2 de l'application de bureau doit s'installer à la main sur les postes restés en 0.8.0 ou 0.8.1 : leur mise à jour intégrée peut échouer.