Openship : la plateforme de déploiement qui sort le build de votre serveur

Le build qui sature le serveur de production pendant qu'il sert les utilisateurs, c'est une scène familière pour les équipes qui déploient sur leur propre infrastructure. Openship, plateforme de déploiement open source apparue en mars 2026, prend le problème par l'autre bout : l'image se construit sur votre machine, pas sur le serveur qui tourne. Le projet publie à un rythme soutenu, dix-sept versions de son CLI en quatre semaines, et embarque au passage un serveur mail complet et un point d'entrée pour les agents de code IA. Voilà ce qu'il y a dedans, et ce que ça vaut aujourd'hui.

Openship, une plateforme de déploiement auto-hébergeable sous Apache 2.0

Ses mainteneurs décrivent Openship comme une « self-hosted deployment platform », soit une plateforme de déploiement que vous installez sur vos propres serveurs. Le code est publié sur la forge GitHub, dans le dépôt oblien/openship, sous licence Apache 2.0, et le produit est édité par la société Oblien LLC. Au 17 août 2026, ce dépôt affiche plus de 10 900 étoiles et 937 forks.

Un piège avant même de chercher la documentation : un second projet porte exactement le même nom sur GitHub. Le dépôt openshiporg/openship (openship.org, licence AGPL-3.0) se décrit lui-même comme une solution de traitement de commandes multi-canal, sans aucun rapport avec le sujet de cet article. Le bon dépôt est celui dont la fiche GitHub renvoie vers openship.io.

L'installation passe par le registre officiel npm (npm i -g openship), le paquet déclarant Node 22 ou supérieur en prérequis. Trois interfaces cohabitent ensuite : une application desktop Mac et Windows qui pousse depuis le poste et affiche les logs nativement, un dashboard web pour les déploiements, les métriques et les accès de l'équipe, et un CLI présenté comme un binaire unique couvrant déploiement, logs, secrets, domaines et rollbacks. L'auto-hébergement complet est annoncé gratuit, sans limite de sièges et sans télémétrie dans la FAQ officielle du produit. Une offre managée, Openship Cloud, existe à côté, avec un palier gratuit puis des formules à 10, 39 et 99 dollars par mois et un palier Enterprise sur devis.

Le build tourne chez vous, l'image voyage en SSH

C'est le mécanisme que le projet met le plus en avant, et il mérite qu'on s'y arrête. La page officielle le formule ainsi : « l'image se construit sur votre machine, pas sur votre serveur de production. Chaque build produit un artefact immuable et versionné. Il est streamé vers la cible en SSH et démarre comme un conteneur neuf. » La cible, c'est au choix Openship Cloud, un VPS à vous ou un homelab. Sur le serveur, les services managés (Postgres, Redis, mail, stockage objet) rejoignent l'application sur un réseau privé, joignable par l'application et jamais depuis internet. Le certificat TLS est pris en charge via Let's Encrypt, le routage en frontal par OpenResty, et le remplacement du conteneur est annoncé sans coupure, la version précédente restant disponible pour un rollback en un clic. Une nuance que la page pose elle-même un peu plus bas : le build tourne « sur votre machine (ou dans le cloud) », la variante cloud valant pour l'offre managée. Sur un serveur à vous, c'est bien votre poste qui construit.

Trois conséquences pratiques pour une équipe. La chaîne de build (compilateurs, dépendances, caches) n'a plus à vivre sur la machine qui sert vos utilisateurs, donc un build lourd ne vient plus disputer la mémoire et le CPU au trafic réel. L'artefact qui part en production est exactement celui qui a été construit et testé, pas une reconstruction faite sur place avec un environnement légèrement différent. Et le retour arrière ne consiste plus à rejouer un build, mais à redémarrer une version déjà présente. La contrepartie se cadre en amont : ce qui part en ligne dépend désormais de l'environnement du poste qui a lancé le build, donc une équipe où plusieurs personnes déploient a intérêt à figer cet environnement plutôt qu'à le laisser diverger d'une machine à l'autre.

Openship assume ce positionnement sans détour : sa page d'accueil affiche un tableau comparatif intitulé « Where Openship is genuinely different », qui l'oppose d'un côté aux plateformes managées Vercel et Netlify, de l'autre aux solutions d'auto-hébergement qu'il nomme, Coolify, Dokploy et Dokku. La bonne question à se poser n'est pas de savoir qui gagne le comparatif d'un éditeur, mais où tourne réellement votre build aujourd'hui, et ce qu'il consomme sur la machine qui répond à vos clients.

Un serveur mail transactionnel dans le même socle

C'est la brique qu'on n'attend pas dans une plateforme de déploiement. Openship annonce un vrai serveur mail intégré : boîtes aux lettres, webmail, et surtout la chaîne SPF, DKIM et DMARC « vérifiée et configurée », reverse DNS compris, mise en place en un clic avec les domaines et les certificats. Ces trois enregistrements DNS sont ce qui prouve aux messageries destinataires qu'un message envoyé en votre nom vient bien de chez vous ; mal réglés, les mails de réinitialisation de mot de passe et les factures finissent en indésirables.

Le reste suit la même logique : nombre de domaines illimité, envoi via Amazon SES ou votre propre serveur SMTP, API SMTP et REST ouverte, et des webhooks sur les ouvertures, les clics et les rebonds. Pour une application métier qui envoie des notifications, c'est le genre de dépendance externe qu'on ne pense à cadrer que le jour où la délivrabilité s'effondre.

Un endpoint MCP pour déployer depuis un agent de code

Openship expose un serveur MCP, le protocole standard qui permet à un assistant de code de piloter des outils extérieurs. La page produit est explicite : « Drive deploys from AI agents, Claude, Cursor, any MCP client. Standard tools, authenticated. » Autrement dit, déclencher un déploiement devient une action disponible pour un agent IA, au même titre qu'une commande CLI ou qu'un appel à l'API REST.

L'intérêt est réel sur les tâches répétitives : demander à l'agent qui vient de corriger un bug de pousser la correction en préproduction, relire les logs, revenir en arrière si besoin. La prudence l'est tout autant. Un outil qui déploie n'est pas un outil qui lit du code : les droits accordés à l'agent, les environnements qu'il peut atteindre et la trace de ce qu'il a déclenché se décident avant de brancher le connecteur, pas après le premier déploiement surprise un vendredi soir.

Ce qui n'est pas encore là

La page d'accueil affiche une large vitrine de technologies sous l'intitulé « Designed for your favorite stack » : Next.js, Node, Python, Go, Rust, Docker, Postgres, Redis, Rails, Laravel, Django, Bun. La feuille de route officielle est nettement plus précise, et c'est elle qu'il faut lire : seuls Node.js et Docker se déploient nativement aujourd'hui, avec détection automatique, build et exécution sans configuration. Toutes les autres piles (Go, Rust, Python, Ruby, PHP, Java et Kotlin, .NET, Elixir) passent par un pipeline universel où vous fournissez vos commandes d'installation, de build et de démarrage, ou un Dockerfile. Ce n'est pas un défaut en soi, c'est simplement une charge de configuration à anticiper si votre application n'est ni du Node ni un conteneur déjà prêt.

Autre point à connaître avant d'y poser une production sérieuse : la même feuille de route classe le clustering multi-noeuds et la répartition de charge en statut « in progress ». Grouper plusieurs serveurs et distribuer le trafic entre des noeuds sains sont annoncés, pas livrés. Le décalage mérite d'être signalé : la page d'accueil range de son côté la répartition de charge parmi les capacités du produit. Là encore, c'est la feuille de route qui décrit l'état réel. Pour une application qui tient sur une machine, c'est sans conséquence. Pour une architecture qui doit encaisser des pics ou survivre à la perte d'un serveur, c'est bloquant à ce stade.

Reste la question de la maturité, et là aussi les chiffres sont publics. Le dépôt GitHub et le paquet npm ont été créés le 5 mars 2026, soit environ cinq mois et demi d'existence. Le numéro de version en dit long : 0.6.6 au 17 août 2026, toujours en pré-1.0 selon le versionnement du projet lui-même, avec dix-sept publications sur le registre npm entre le 20 juillet et le 17 août 2026. À titre de repère, Coolify, que la page d'accueil d'Openship cite elle-même comme référence de l'auto-hébergement, publie son code sous la même licence Apache 2.0 depuis un dépôt ouvert le 25 janvier 2021, et rassemble plus de 60 000 étoiles au 17 août 2026, soit plus de cinq fois plus. Ces écarts ne disent rien de la qualité du code ; ils disent le temps passé en production chez d'autres, et le nombre de cas tordus déjà rencontrés.

Ce qu'une équipe peut en faire dès maintenant

Le profil qui colle le mieux aujourd'hui est assez net : une application Node ou déjà conteneurisée, un serveur, une équipe qui veut sortir du déploiement artisanal sans confier sa production à une plateforme managée. Dans ce cas, le coût d'essai est faible, l'auto-hébergement est gratuit et le CLI s'installe en une commande. Un environnement de préproduction suffit à juger sur pièces : temps de build réel, comportement du rollback, qualité des logs.

Le profil qui doit attendre est tout aussi net : plusieurs noeuds, répartition de charge nécessaire, ou une pile qui demanderait de réécrire tout le pipeline à la main. Dans les deux cas, la décision se prend sur vos contraintes, pas sur une page produit, et elle commence par un inventaire honnête de l'existant. C'est exactement ce que couvre un audit et une étude de cadrage avant de toucher à une chaîne de déploiement qui, elle, fonctionne déjà.

Un dernier réflexe, valable pour tout outil jeune adopté vite : épingler la version installée plutôt que de suivre la dernière publication en date, et traiter les notes de version comme une dépendance critique à surveiller. Ce rythme de publication est un signe d'énergie, et aussi un rappel que la surface de changement bouge encore.

Pour aller plus loin

• Coolify ou Dokploy, quel PaaS auto-hébergé choisir : le comparatif des deux références citées par Openship lui-même.
• Cloud et DevOps : conteneurisation, intégration continue et hébergement, du poste de développement à la production.
• Maintenance et TMA : ce qui se passe après la mise en ligne, quand l'outil doit tenir dans la durée.
• Hermes Agent : notre agent maison, pour voir concrètement ce qu'un agent connecté à des outils sait faire.
• Notre méthode : comment on cadre un projet avant d'y toucher, de l'audit au déploiement.

Sources

Chaque fait et chaque chiffre de cet article provient d'une source primaire, vérifiée en statut 200 le 18 août 2026 :

• Openship, page officielle du produit (mécanisme de déploiement, serveur mail, MCP, interfaces, piles affichées, tableau comparatif)
• Openship, feuille de route officielle (support natif par pile, clustering et répartition de charge en cours)
• Openship, page tarifs officielle (éditeur Oblien LLC, licence, paliers Openship Cloud, auto-hébergement gratuit)
• Dépôt GitHub oblien/openship (description, licence Apache 2.0, étoiles et forks au 17 août 2026)
• Registre npm officiel, métadonnées du paquet openship (première publication le 5 mars 2026, prérequis Node 22, version 0.6.6, dates de publication des versions)
• Dépôt GitHub coollabsio/coolify (repère d'ancienneté et d'audience, licence Apache 2.0)