Joan eduki nagusira
WebguneWebgunebeta
Tarifak

Tout ce qu'il faut pour tenir une application en production

Construire l'image, la faire tourner, lui donner une base de données, un domaine et un certificat, la surveiller, y revenir quand ça casse : c'est le travail réel d'un hébergement. Webgune couvre cette chaîne entière depuis une seule interface, sans service tiers à recoller.

Créer un compteVoir la démo

42

fonctionnalités, chacune reliée à sa documentation

  • 1Déployer12
  • 2Exploiter6
  • 3Données6
  • 4Réseau6
  • 5Équipe6
  • 6Développeurs6
  • Ce qui manque encore

Du dépôt Git au service en ligne

Le builder analyse votre dépôt à chaque déploiement : il reconnaît le framework, choisit la commande de build, les artefacts à embarquer et la commande de démarrage. Aucun Dockerfile n'est obligatoire — mais si votre dépôt en contient un, c'est lui qui gagne.

Le webhook GitHub est posé et entretenu par la plateforme : une fois le dépôt connecté, chaque push sur la branche suivie déclenche un déploiement. L'historique garde chaque build avec son commit, sa durée et ses logs, et le retour arrière est un bouton.

Build automatiqueLe builder détecte le framework et construit l'image sans configuration à écrire.Frameworks reconnusNext.js, React, Node, Python, PHP, Go et des dizaines d'autres, détectés depuis le dépôt.Déploiement depuis GitHubDépôt connecté, branche suivie, webhook géré pour vous : chaque push part en déploiement.Image Docker ou DockerfileN'importe quelle image publique ou privée, ou votre propre Dockerfile versionné.Pipeline kx712.ymlUn fichier dans le dépôt décrit les étapes de build et de déploiement, versionné avec le code.Déploiements et rollbackL'historique complet des builds, leurs logs, et le retour à une version précédente en un clic.Variables d'environnementÉdition en bloc au format .env, appliquées au redémarrage du service.Commande de démarrageSurcharge manuelle quand la détection automatique ne correspond pas à votre besoin.WorkersDes services sans port ni domaine : files d'attente, tâches planifiées, traitements de fond.Bots DiscordUn bot JavaScript ou Python déployé depuis un template, sans serveur à administrer.TemplatesDes groupes de services déjà reliés entre eux, déployés en une seule fois.Premier projetLe parcours complet, du compte créé au premier service en ligne.

Ce qui se passe une fois que c'est en ligne

Un déploiement réussi n'est que le début. Les logs défilent en direct dans le dashboard, un terminal ouvre un shell dans le conteneur en cours d'exécution sans passer par SSH, et les métriques CPU, mémoire et réplicas sont relevées sur le cluster.

L'autoscaling ajuste le nombre de réplicas sur la charge CPU : plus de trafic, plus d'instances ; accalmie, retour au minimum. Et quand quelque chose casse, trois assistants IA — documentation, diagnostic de crash, analyse de logs — se déclenchent à la demande, jamais tout seuls.

Logs en directLe flux de sortie du conteneur, en streaming dans le dashboard comme en ligne de commande.Terminal webUn shell ouvert dans le conteneur qui tourne, sans SSH ni clé à distribuer.MétriquesCPU, mémoire et réplicas relevés sur le cluster, service par service.AutoscalingLe nombre de réplicas suit la charge CPU, entre un minimum et un maximum que vous fixez.Limites de ressourcesCe que chaque plan alloue en CPU, mémoire et stockage, et ce qui se passe aux bornes.Assistant IAQuestions sur la doc, diagnostic de crash, analyse de logs — à la demande, sur votre clic.

Des bases managées, pas des conteneurs à surveiller

Cinq moteurs se provisionnent en un clic depuis le canvas du projet, avec leurs identifiants récupérables pour les services qui s'y connectent. Les connexions restent internes au cluster : une base n'est pas exposée sur Internet parce qu'un service en a besoin.

Pour tout ce qui doit survivre au redémarrage d'un conteneur — fichiers déposés, cache disque, données d'un service qui n'est pas une base — un volume persistant se monte sur le chemin de votre choix.

PostgreSQLProvisionné, sauvegardes planifiables, accessible en connexion privée depuis vos services.MySQLUn moteur éprouvé, avec les mêmes garanties de connexion privée.MongoDBUne base documentaire managée, prête à recevoir votre chaîne de connexion.RedisCache, sessions, files d'attente légères, sans instance à administrer.Volumes persistantsUn disque monté sur le chemin de votre choix, qui survit aux redéploiements.Vue d'ensembleComment choisir un moteur, le relier à un service et récupérer ses identifiants.

Domaines, certificats et routage

Chaque service reçoit un sous-domaine gratuit dès son premier déploiement, ce qui suffit à tester. Brancher votre propre domaine ajoute un enregistrement DNS et rien d'autre : le certificat TLS est demandé, installé et renouvelé sans intervention.

Les domaines s'achètent aussi depuis le dashboard, ce qui évite d'aller chercher un registrar tiers pour ensuite recoller les zones à la main.

Domaines personnalisésVotre nom de domaine sur un service, avec la vérification DNS guidée.Certificats SSLÉmis et renouvelés automatiquement pour chaque domaine rattaché.Sous-domaine gratuitUne URL en ligne dès le premier déploiement, sans rien acheter.Achat de domaineLa recherche et l'achat d'un nom depuis le dashboard, sans registrar tiers.Enregistrements DNSLa zone de vos domaines éditable depuis l'interface : A, AAAA, CNAME, TXT, MX.RedirectionsRediriger un domaine ou un chemin vers un autre, sans déployer de service pour ça.

À plusieurs sur le même projet

Le canvas d'un projet est un espace partagé en direct : quand plusieurs membres l'ouvrent en même temps, chacun voit les curseurs des autres et les changements arrivent sans rechargement. Les rôles décident qui peut déployer, qui peut facturer et qui ne fait que regarder.

Pour les agences, chaque client a son propre sous-compte, rattaché à l'espace agence, et Webgune facture directement chaque client.

Projets partagésInviter des membres sur un projet et travailler sur la même infrastructure.Rôles et permissionsQui déploie, qui facture, qui consulte : les droits se règlent par membre.Collaboration temps réelLes curseurs des autres membres sur le canvas, et les changements sans rechargement.Abonnements par projetUn plan par projet plutôt qu'une note globale : chaque projet porte son coût.Tickets de supportUne demande ouverte depuis le dashboard, suivie au même endroit que vos services.Sécurité du compteMot de passe, double authentification et sessions actives, révocables à tout moment.

Tout se pilote aussi par script

Le dashboard n'a aucun privilège : il consomme l'API REST publique, la même que la vôtre. Ce qui se clique se scripte donc aussi — création de service, déploiement, lecture des logs, gestion des domaines.

Autour de cette API : une CLI, une extension VS Code, un SDK typé et un serveur MCP pour brancher un agent sur votre infrastructure. Les clés sont scopées et chaque appel laisse une trace dans un journal d'audit.

CLI officielleDéployer, suivre les logs et ouvrir un shell depuis votre terminal.Extension VS CodeVos services, vos logs et vos déploiements sans quitter l'éditeur.API REST publiqueLa référence complète des endpoints — celle qui alimente le dashboard.SDK JavaScript typéUn client officiel typé pour piloter la plateforme depuis Node ou le navigateur.Serveur MCPBrancher un assistant IA sur votre infrastructure via le Model Context Protocol.Clés API scopéesDes clés limitées à ce dont elles ont besoin, avec journal d'audit par clé.

Ce qui manque encore

Une page de fonctionnalités où tout est coché ne renseigne personne. Voici ce que la plateforme ne fait pas aujourd'hui — pour que vous le sachiez avant de migrer, pas après.

Railway a bâti toute son API publique autour de GraphQL. Webgune expose aujourd'hui une API REST complète et documentée — une couche GraphQL est en développement mais pas encore disponible.
Webgune déploie des services conteneurisés toujours actifs, pas des fonctions à la demande exécutées en périphérie de réseau. Si votre besoin est du edge compute pur (comme Vercel Functions ou Koyeb), ce n'est pas notre modèle.
L'infrastructure est répartie sur Nantes, Bordeaux et Pau — un vrai avantage pour la latence et la conformité en France/Europe, mais pas une couverture mondiale comme Fly.io ou l'edge Vercel/Koyeb. Si vos utilisateurs sont majoritairement hors Europe, ce n'est pas le bon choix aujourd'hui.
"Login with Webgune" pour des apps tierces (comme "Login with Railway") est prévu mais pas encore livré. Les clés API scopées couvrent déjà l'automatisation par script, pas encore la délégation à une app externe.

L'API GraphQL et l'OAuth pour applications tierces sont en développement.Suivre le changelog

Trois sites en France, pas un réseau mondial

Les machines tournent sur trois sites — Nantes, Bordeaux et Pau — reliés par notre propre cœur de réseau. Vos données restent en France, ce qui règle la question de la conformité sans annexe contractuelle, et la latence est excellente pour un public français ou européen.

C'est un choix, avec sa contrepartie : ce n'est pas une couverture mondiale. Si vos utilisateurs sont majoritairement hors d'Europe, une plateforme à trente régions vous servira mieux — et nous le disons aussi sur la page comparatif.

  • Trois sites français reliés par notre cœur de réseau
  • Page de statut publique, alimentée par les sondes qui déclenchent nos alertes
  • Sauvegardes planifiables des bases managées, sur tous les plans
Voir la page de statutComparer aux autres plateformes
ParisNantesBordeauxPau

Questions fréquentes

Vous ne trouvez pas votre réponse ? La documentation couvre chaque fonctionnalité en détail.
Non. Le builder analyse le dépôt et en déduit la commande de build et la commande de démarrage. Le Dockerfile reste une option — si votre dépôt en contient un, c'est lui qui est utilisé, et vous pouvez aussi partir directement d'une image existante.
Oui : chaque carte de cette page renvoie à sa page de documentation. Ce qui est prévu mais pas encore livré n'apparaît pas dans les chapitres — c'est rassemblé plus bas, dans « ce qui manque encore ».
Oui. Le dashboard consomme l'API REST publique, sans endpoint privilégié : ce que vous voyez à l'écran est accessible par API, par la CLI, par le SDK ou par l'extension VS Code, avec des clés scopées et un journal d'audit.
Non, les connexions entre vos services et vos bases restent internes au cluster. Une base n'est pas publiée sur Internet parce qu'un service s'y connecte.
L'onglet Déploiements garde l'historique complet avec les logs de chaque build. Le retour à une version précédente est un bouton, et le service repart sur l'image qui fonctionnait.

La liste est longue, l'essai est court

L'essai de 3 jours suffit à déployer un vrai service et à juger sur pièces. Rien de ce qui est décrit ici ne demande un appel commercial.

Créer un compteVoir les tarifs
WebguneWebgune

Hodei burujabe osoa, Frantzian diseinatua eta ostatatua.

DiscordDiscordGitHubGitHub
+33 (0)9 72 23 25 00support@webgune.cloud

Produktua

  • Ezaugarriak
  • Tarifak
  • Konparaketa
  • Changelog
  • Egoera
  • Ahuleziak (CVE)
  • Harremanetarako

Garatzaileak

  • Dokumentazioa
  • Frameworkak
  • API erreferentzia
  • Adibideak
  • CLI
  • Tresnak & VS Code

Legala

  • Erabilera baldintzak
  • Pribatutasun politika
  • Ohar legalak
  • Irisgarritasuna
  • RGPD
  • DPA
  • Erabilera onargarriaren politika

© 2026 KX712. Eskubide guztiak erreserbatuta. Webgune KX712-ren zerbitzu bat da.

Ordainketak:VisaMasterCardAmerican ExpressApple PayGoogle PaySEPABancontact