Un compte cloud est l'endroit où Vimonto Deploy crée des serveurs pour vous, et où il gère le DNS de vos domaines. Vous connectez Hetzner Cloud, DigitalOcean, Vultr, Akamai (Linode), Amazon Web Services ou Google Cloud une fois par organisation, et dès lors Nouveau serveur peut y créer un serveur en un clic : Vimonto Deploy récupère en direct les régions, tailles et prix du fournisseur, crée le serveur sous Ubuntu 24.04 et le provisionne. La même connexion gère le DNS des domaines de ce compte : un domaine que vous ajoutez à un site peut ainsi pointer vers son serveur tout seul. Cloudflare sert uniquement au DNS.
Ces comptes se trouvent dans la section Cloud et DNS de Paramètres → Intégrations.
Le serveur lui-même est facturé par le fournisseur, sur votre propre compte. Vimonto Deploy ne facture rien de plus par serveur. Un serveur que vous avez déjà ailleurs n'a besoin d'aucune connexion à un fournisseur : connectez-le comme VPS personnalisé.

Quels fournisseurs sont pris en charge ?
| Fournisseur | Mode de connexion | Ce que couvre une connexion |
|---|---|---|
| Hetzner Cloud | Token API | Des serveurs cloud en Allemagne, en Finlande, aux États-Unis et à Singapour ; DNS |
| DigitalOcean | Token API, ou OAuth si disponible | Des Droplets à Amsterdam, Francfort, Londres et dans le monde entier ; DNS |
| Vultr | Clé API | Du cloud compute dans de nombreux emplacements, dont Amsterdam ; DNS |
| Akamai (Linode) | Token API, ou OAuth si disponible | Des Linodes, notamment à Amsterdam et Francfort ; DNS |
| Amazon Web Services | Clé d'accès (ID et secret) | Des instances EC2 dans toutes les régions AWS ; DNS dans Route 53 |
| Google Cloud | Clé de compte de service (JSON) | Des VM Compute Engine dans toutes les régions Google Cloud ; Cloud DNS |
| Cloudflare | Token API | DNS uniquement |
Chaque serveur est créé sous Ubuntu 24.04 (x64). Vous pouvez connecter plusieurs comptes, même chez le même fournisseur, par exemple un projet Hetzner par client. Un compte Cloudflare ne peut pas être choisi dans l'assistant Nouveau serveur.
Qui peut connecter un compte ?
Chaque membre de l'organisation peut voir les comptes connectés. Connecter, modifier, tester et déconnecter un fournisseur nécessite le rôle Propriétaire ou Administrateur. Consultez membres et rôles. Chaque connexion, modification et déconnexion est enregistrée dans le journal d’audit, sans le token.
Connecter un compte avec un token API ou une clé
- Ouvrez Paramètres → Intégrations.
- Sur la carte du fournisseur, sous Ajouter une intégration, choisissez Connecter. Quand la carte propose aussi OAuth, Connecter ouvre un menu : Se connecter avec … vous connecte chez le fournisseur, Utiliser un jeton d'API ouvre le formulaire du jeton.
- Suivez les étapes de la fenêtre pour créer un token chez le fournisseur. Créer un token chez … ouvre la bonne page du tableau de bord du fournisseur.
- Collez le token dans Token API. Pour AWS, remplissez ID de clé d'accès et Clé d'accès secrète ; pour Google Cloud, collez le fichier JSON entier dans Clé du compte de service (JSON).
- Donnez à la connexion un Nom que vous reconnaîtrez, par exemple le projet ou le client.
- Choisissez Vérifier et connecter.
Vimonto Deploy vérifie le token auprès de l'API du fournisseur avant de l'enregistrer : une faute de frappe ou un token révoqué apparaît donc immédiatement comme une erreur sous le champ, plutôt qu'au milieu de la création d'un serveur. Le token est stocké chiffré. Dans la liste, une connexion par token affiche le fournisseur et les derniers caractères de son token (pour AWS, de l'ID de sa clé d'accès ; pour Google Cloud, l'adresse du compte de service). Juste après la connexion, Vimonto Deploy récupère les domaines que gère le compte (voir la carte du compte).
Hetzner Cloud : où trouver le token API
Un token Hetzner Cloud appartient à un seul projet. Les serveurs sont créés dans ce projet.
- Ouvrez votre projet dans la Hetzner Cloud Console.
- Allez dans Security → API tokens et choisissez Generate API token.
- Choisissez Read & Write et copiez le token.
DigitalOcean : où trouver le token API
- Ouvrez API → Tokens dans le tableau de bord DigitalOcean.
- Choisissez Generate New Token avec Full Access.
- Copiez le token.
Vultr : où trouver la clé API
- Ouvrez Account → API dans le tableau de bord Vultr et activez l'API.
- Sous Access Control, ajoutez les adresses IP de Vimonto Deploy.
- Copiez la clé API.
Akamai (Linode) : où trouver le token API
- Ouvrez API Tokens dans votre profil Akamai Cloud et choisissez Create a Personal Access Token.
- Donnez à Linodes, IPs, Domains et VPCs les droits de lecture et d'écriture, et ne choisissez pas de date d'expiration.
- Copiez le token.
Les VPCs sont ce qu'Akamai utilise pour les réseaux privés. Avec un token sans accès aux VPCs, Nouveau serveur l'indique sous Réseau privé, et vous pouvez quand même créer le serveur sans réseau privé. Une connexion OAuth créée avant que Vimonto Deploy ne demande les VPCs obtient cet accès lorsque vous choisissez Reconnecter.
Sans Domains, les serveurs peuvent toujours être créés, mais le compte affiche Pas d’accès DNS avec cette connexion. Un token avec une date d'expiration cesse de fonctionner à cette date. Vous en collez alors un nouveau avec Modifier le nom ou le token.
Amazon Web Services : où trouver la clé d'accès
Vimonto Deploy utilise la clé d'accès d'un utilisateur IAM de votre compte AWS. Les serveurs sont des instances EC2 ; les domaines sont vos zones hébergées Route 53.
- Ouvrez IAM → Users dans la console AWS et créez un utilisateur, sans accès à la console.
- Associez-lui les politiques AmazonEC2FullAccess et AmazonRoute53FullAccess, ainsi que AWSPriceListServiceFullAccess pour voir les prix.
- Sous Security credentials, créez une clé d'accès pour Application running outside AWS et copiez les deux parties.
L'ID de la clé d'accès commence par AKIA. Le secret n'est affiché qu'une seule fois chez AWS : copiez-le avant de fermer la page. Sans AmazonRoute53FullAccess, les serveurs peuvent toujours être créés, mais le compte affiche Pas d’accès DNS avec cette connexion. Sans la politique de la liste des prix, Nouveau serveur affiche les tailles sans prix.
EC2 fonctionne un peu différemment des autres fournisseurs. Vimonto Deploy s'en charge tout seul :
- Régions et tailles. Nouveau serveur liste les régions activées dans votre compte, les européennes d'abord, et une sélection de types d'instances x86 actuels : Burstable (t3), Usage général (m6i), Optimisé pour le calcul (c6i) et Optimisé pour la mémoire (r6i). Le prix est le prix à la demande de l'instance pour Linux dans cette région, par mois ; le disque (gp3, de 25 à 100 Go selon la taille), le trafic et l'adresse sont facturés en plus par AWS.
- Réseau. Un serveur est placé dans le VPC par défaut de la région, ou dans le réseau privé que vous choisissez sous Réseau existant. Nouveau réseau crée un VPC avec un sous-réseau et une passerelle internet. Une région sans VPC par défaut reçoit, la première fois, un VPC nommé
vimonto. - Pare-feu. EC2 bloque par défaut tout le trafic entrant. Vimonto Deploy place les serveurs dans un groupe de sécurité nommé
vimonto-openqui laisse passer le trafic, et c'est le pare-feu du serveur (ufw), que vous gérez dans Vimonto Deploy, qui décide de ce qui passe, comme chez tous les autres fournisseurs. Les règles que vous ajoutez à ce groupe dans la console AWS ne changent rien pour ufw. - Adresse fixe. Dès que l'instance tourne, elle reçoit une Elastic IP : son adresse ne change donc pas quand elle est arrêtée puis redémarrée. Supprimer le serveur dans Vimonto Deploy libère aussi l'Elastic IP. AWS autorise par défaut cinq Elastic IP par région ; au-delà, le serveur garde l'adresse reçue au démarrage.
Google Cloud : où trouver la clé du compte de service
Vimonto Deploy utilise la clé d'un compte de service d'un projet Google Cloud. Les serveurs sont des VM Compute Engine de ce projet ; les domaines sont ses zones Cloud DNS.
- Dans la console Google Cloud, choisissez le projet et activez la Compute Engine API et la Cloud DNS API.
- Ouvrez IAM & Admin → Service Accounts, créez-en un et donnez-lui les rôles Compute Admin et DNS Administrator.
- Sous Keys, ajoutez une clé de type JSON et ouvrez le fichier téléchargé.
Collez le fichier entier, de { à }, dans Clé du compte de service (JSON). Quand une API n'est pas activée ou qu'un rôle manque, l'erreur sous le champ reprend le message de Google, qui indique ce qu'il faut activer.
Google Cloud fonctionne aussi un peu différemment :
- Les régions sont des zones. Les VM vivent dans une zone : Nouveau serveur liste donc une zone par région, par exemple Netherlands (europe-west4-a), avec une sélection de types de machines : à cœur partagé (e2-micro, e2-small, e2-medium), usage général (e2 et n2), optimisées pour le calcul (c3) et optimisées pour la mémoire (n2-highmem). Google n'indique pas de prix par type de machine dans son API : les tailles sont donc affichées sans prix ; consultez le calculateur de prix de Google.
- Réseau. Un serveur rejoint le réseau
defaultdu projet, ou le réseau privé que vous choisissez sous Réseau existant. Nouveau réseau crée un réseau avec un sous-réseau dans chaque région. - Pare-feu. Comme EC2, Google Cloud bloque par défaut le trafic entrant. Vimonto Deploy ajoute une règle de pare-feu par réseau,
vimonto-open-…, qui laisse passer le trafic vers les VM portant la balise réseauvimonto, et c'est ufw sur le serveur qui décide de ce qui passe. - Adresse fixe. Chaque serveur reçoit une adresse externe statique, nommée d'après le serveur avec
-ip. Supprimer le serveur dans Vimonto Deploy supprime la VM, puis l'adresse.
Cloudflare : où trouver le token API
- Ouvrez My Profile → API Tokens dans le tableau de bord Cloudflare et choisissez Create Token.
- Partez du modèle Edit zone DNS, et ajoutez Zone → Zone → Read.
- Choisissez les zones (toutes, ou celles que vous utilisez) et copiez le token.
Le token a besoin de Zone → Zone → Read et Zone → DNS → Edit. Il sert uniquement au DNS.
Connecter DigitalOcean ou Akamai avec OAuth
DigitalOcean et Akamai prennent aussi en charge la connexion via OAuth : vous connectez un compte en un clic au lieu de coller un token. Quand la plateforme a configuré OAuth pour un fournisseur, Connecter sur sa carte vous connecte chez le fournisseur, et Utiliser un jeton d'API ouvre le formulaire du token :
- Choisissez Connecter sur la carte.
- Connectez-vous chez le fournisseur et autorisez l'accès. Vimonto Deploy demande un accès en lecture et en écriture (sur Akamai : Linodes, IPs, Domains et VPCs).
- Vous revenez sur Intégrations avec un message confirmant que le compte est connecté. La connexion porte le nom du fournisseur et de votre compte chez lui.
Les tokens OAuth expirent (au bout de 30 jours chez DigitalOcean, de deux heures chez Akamai). Vimonto Deploy les renouvelle de lui-même avant de les utiliser : vous n'avez rien à faire. Si l'accès a été révoqué chez le fournisseur, choisissez Reconnecter dans le menu de la connexion. Vous vous connectez à nouveau chez le fournisseur, et cette connexion reçoit le nouvel accès : elle garde son nom et ses serveurs, et rien n'est ajouté à côté. Connecter à nouveau le même compte DigitalOcean avec Connecter renouvelle aussi sa connexion au lieu d'en ajouter une deuxième.
Ce que montre la carte du compte
Chaque compte connecté affiche son nom, le fournisseur et le mode de connexion, Fonctionne ou Ne fonctionne pas, et ce à quoi sert la connexion :
- Serveurs : Prêt à créer des serveurs (pas pour Cloudflare).
- DNS : le nombre de domaines que gère le compte, avec les premiers noms. Pas encore vérifié signifie que les domaines n'ont pas encore été récupérés. Pas d’accès DNS avec cette connexion. signifie que le token ne peut pas lire le DNS, avec la raison à côté ; donnez au token les droits DNS décrits plus haut et choisissez Actualiser les domaines.
- Sauvegardes (Hetzner, DigitalOcean, AWS et Cloudflare) : le bucket lié à ce compte, ou Ajouter un stockage de sauvegarde. Le stockage S3 a besoin de ses propres clés d'accès : cela ouvre donc le formulaire de stockage pour Hetzner Object Storage, DigitalOcean Spaces, Amazon S3 ou Cloudflare R2. Consultez stockage des sauvegardes.
Actualiser les domaines dans le menu (⋯) récupère à nouveau les domaines du compte, par exemple après avoir ajouté un domaine chez le fournisseur. L'usage de ces domaines est expliqué dans domaines et SSL.
Vérifier qu'une connexion fonctionne
Chaque compte connecté affiche Fonctionne ou Ne fonctionne pas. Pour le vérifier à nouveau, ouvrez le menu (⋯) à côté du compte et choisissez Tester la connexion. Vimonto Deploy appelle l'API du fournisseur et vous indique ce que le fournisseur a répondu, par exemple :
- le fournisseur refuse le token ou la clé API (il est erroné ou a été révoqué) ;
- le fournisseur n'autorise pas cette action avec ce token (il a besoin des droits d'écriture) ;
- le fournisseur demande de patienter en raison d'un trop grand nombre de requêtes.
Une connexion qui Ne fonctionne pas ne peut pas être choisie dans l'assistant Nouveau serveur tant qu'elle ne fonctionne pas à nouveau.
Le menu contient aussi Actualiser les domaines, Ajouter un stockage de sauvegarde (pour Hetzner, DigitalOcean, AWS et Cloudflare), Modifier le nom ou le token (pour AWS et Google Cloud, Modifier le nom ou la clé) ou Reconnecter, et Déconnecter.
Modifier le nom ou le token
Pour une connexion par token, choisissez Modifier le nom ou le token dans le menu. Laissez Token API vide pour garder le token actuel et ne modifier que le nom. Pour AWS et Google Cloud, l'élément du menu est Modifier le nom ou la clé ; laissez le secret ou la clé JSON vide pour garder la clé actuelle. Un nouveau token est vérifié avant d'être enregistré. Pour une connexion OAuth, choisissez plutôt Reconnecter.
Déconnecter un compte
Choisissez Déconnecter dans le menu et confirmez. Plus aucun serveur ne peut être créé sur ce compte, et ses domaines ne reçoivent plus d'enregistrements DNS de Vimonto Deploy. Le stockage de sauvegarde ajouté au compte reste dans la liste Stockage des sauvegardes. Rien ne change chez le fournisseur lui-même : les serveurs que vous avez créés restent en place et continuent de fonctionner dans Vimonto Deploy, car tout le travail ultérieur sur un serveur passe par SSH. Pour couper complètement l'accès de Vimonto Deploy, supprimez aussi le token ou révoquez l'application OAuth chez le fournisseur.
Questions fréquentes
Vimonto Deploy facture-t-il les serveurs que je crée ?
Non. Le fournisseur facture le serveur sur votre propre compte, à son prix normal. L'assistant Nouveau serveur affiche ce prix, en direct depuis le fournisseur, avant que vous ne créiez quoi que ce soit. Google Cloud fait exception : son API n'a pas de prix, consultez-les donc dans le calculateur de prix de Google.
Puis-je connecter deux comptes du même fournisseur ?
Oui. Connectez autant de comptes que nécessaire et donnez à chacun un nom clair. Lors de la création d'un serveur, vous choisissez le compte dans lequel il est créé.
De quelles permissions Vimonto Deploy a-t-il besoin chez le fournisseur ?
Un accès en lecture et en écriture : il crée des serveurs, des réseaux privés et des enregistrements DNS, et lit les régions, les tailles, les prix et vos domaines. Pour donner sa clé à un nouveau serveur, Vimonto Deploy ajoute une clé SSH à votre compte le temps de la création et la supprime juste après (Akamai prend la clé directement ; sur AWS et Google Cloud, elle est transmise au serveur comme données utilisateur cloud-init). Sur Akamai, cela signifie lecture et écriture pour Linodes, IPs, Domains et VPCs (pour les réseaux privés) ; chez Hetzner, un token Read & Write ; chez DigitalOcean, un token Full Access ; chez AWS, les politiques AmazonEC2FullAccess et AmazonRoute53FullAccess (et AWSPriceListServiceFullAccess pour les prix) ; chez Google Cloud, les rôles Compute Admin et DNS Administrator ; chez Cloudflare, Zone → Zone → Read et Zone → DNS → Edit.
Quel fournisseur choisir ?
Tous fonctionnent de la même façon dans Vimonto Deploy. Hetzner Cloud est souvent le moins cher pour des serveurs en Europe ; DigitalOcean, Vultr et Akamai proposent plus d'emplacements dans le monde. AWS et Google Cloud coûtent plus cher pour le même serveur, mais ont du sens quand le reste de votre infrastructure (bases de données, files d'attente, stockage) y tourne déjà. Choisissez celui où se trouve déjà le reste de votre infrastructure, afin que les serveurs puissent partager un réseau privé.
Que devient la connexion quand je transfère un serveur ?
Un serveur que vous transférez à une autre organisation laisse sa connexion au fournisseur derrière lui : la nouvelle organisation le gère comme un VPS personnalisé. La machine reste dans le même compte chez le fournisseur, qui continue de la payer.