Une machine virtuelle complète, l'une des 17 tailles, sans rien de notre côté installé dessus.
Un VPS Xuda n'est pas un conteneur. proxmox_create_server envoie un POST /nodes/<node>/qemu/<template_vmid>/clone avec full: 1, une copie complète d'un modèle QEMU sur le matériel Xuda, et deploy_module effectue 84 appels vers des chemins /qemu/ et zéro vers /lxc/. La taille choisie est copiée telle quelle plutôt qu'interprétée : slug_to_farm_spec renvoie { cores: s.cpu, ram_gb: s.ram, disk_gb: s.disk }, la création écrit cores et memory sous forme de ram_gb x 1024 Mo, puis redimensionne scsi0 à disk_gb. Il existe 17 tailles dans le groupe de serveurs vps, réparties en quatre types, allant de 1 vCPU avec 0,5 Go et 10 Go à 2,50 $ par mois jusqu'à 32 vCPU avec 256 Go et 7200 Go à 2606 $. Une fois le clone démarré, la plateforme s'arrête là. La branche d'installation est conditionnée par if (_conf.is_debug && !isVpsApp) : un VPS client ne reçoit donc ni runtime, ni agent, ni pile logicielle installée dessus, c'est une image cloud nue portant les clés que vous avez fournies. proxmox_apply_firewall renvoie immédiatement la chaîne vps: customer-managed firewall, et le document de pare-feu par application écrit ensuite contient des tableaux entrants et sortants vides, application désactivée. deploy_vps ne déclare aucun min_plan, donc n'importe quel compte, même gratuit, peut en créer un. Ce que vous achetez ici, c'est la machine et le matériel qui la porte, pas une plateforme gérée par-dessus.
Tailles de VPS, en quatre types, un seul groupe de serveurs
Taille d'entrée : 1 vCPU, 0,5 Go de RAM, 10 Go de disque
Images d'OS sur la ferme, et aucune marketplace
Heures dans le mois de facturation, calculées au prorata de l'heure
Quatre types, et le type détermine votre disque.
Les 17 slugs vps sont regroupés en quatre types, et le type n'est pas une étiquette marketing. Il est lu deux fois. Une fois dans config.json, où PRICE_OBJ.server_types porte la description en une ligne fournie avec chaque type, et une fois dans deploy_module, où SERVER_TYPE_DISK_PREF transforme le type en une liste ordonnée de classes de disques acceptables pour le placement. Lisez chaque carte avec ses deux puces : celle de gauche est la chaîne de disques que le placeur suit, celle de droite est la fourchette de prix et les tailles qu'elle contient. Tout le reste sur un palier n'est que de l'arithmétique sur trois nombres.
VPS, Full Stack VPS et Xucode sont le même clone avec un indicateur dessus.
Trois produits dans le tableau de bord, une seule fonction en dessous. deploy_full_stack_vps appose app_type_override et délègue à deploy_vps. deploy_xucode fait de même avec un override différent, et retire d'abord farm_spec et create_datacenter de la requête pour que la taille provienne du droit d'accès plutôt que de l'appelant. Cette architecture est volontaire : un app_type distinct sortirait des branches vps pour le pare-feu, le redimensionnement, l'alimentation, la route web et le statut, la variante repose donc sur un indicateur plutôt que sur un type séparé. Lisez le tableau en colonne pour ce que vous obtenez, et en ligne pour voir à quel point peu de choses diffèrent réellement.
VPS | Full Stack VPS | Xucode | |
|---|---|---|---|
| Comment il est créé | deploy_vps directement. Aucun override. | deploy_full_stack_vps définit app_type_override, puis appelle deploy_vps. | deploy_xucode définit l'override, force app_hosting_preference à global, puis appelle deploy_vps. |
| Ce que Xuda installe | Rien. La branche d'installation est conditionnée par if (_conf.is_debug && !isVpsApp), et l'application est marquée active dès que la VM affiche running. | La même image nue, plus deux éléments écrits autour : une clé API CPI restreinte créée avant le provisionnement, et une base CouchDB par application via create_db. | Le même chemin vps, avec une machine par compte plutôt qu'une par projet. Une deuxième demande obtient la première machine en réponse. |
| Ce qui vous est facturé | Le prix du slug, calculé au prorata d'un mois fixe de 730,5 heures à partir des horodatages app_cost, avec un segment facturable minimum d'une heure. Aucun cron de facturation, aucun document accumulateur. | Le même prix de slug. Ni la clé ni la base de données n'ajoutent de ligne. | Rien sur le grand livre d'hébergement. cost.mjs renvoie null pour is_xucode, et les trois slugs xucode sont tous tarifés à 0, car le plan a déjà facturé. |
| Quelles tailles vous pouvez choisir | Les 17, de shared_vps_05 jusqu'à large_vps_32. | Pas shared. Le serveur refuse tout slug dont le type est shared, avec le message : le type de serveur shared n'est pas disponible pour un Full Stack VPS, alors que le sélecteur liste encore shared_managed_4 et shared_managed_8. | Aucun sélecteur du tout. Le slug est lu depuis le droit d'accès, et tout ce que l'appelant a envoyé sur le dimensionnement est ignoré plutôt que fusionné. |
| Qui peut en créer un | N'importe quel compte. deploy_vps ne porte aucun min_plan, contrairement à deploy_datacenter, qui exige clearance admin avec min_plan pro. | Aucun min_plan non plus, mais le refus sur shared mentionné ci-dessus fait office de plancher. | Conditionné à xucode.enabled, vrai dans config_dev.json et faux dans config.json. |
| Pare-feu | Aucun appliqué. proxmox_apply_firewall renvoie immédiatement, et le document de pare-feu applicatif est créé avec des tableaux de règles vides, application désactivée. | Pareil. La clé restreinte limite ce que la machine peut rappeler chez Xuda, pas ce qui peut l'atteindre. | La seule exception : _xucode_sync_guard enregistre une garde d'hôte pour l'adresse de la machine via fw_xucode_guard_set, et le pare-feu hôte doit être réappliqué pour que cela prenne effet. |
Choisir une région restreint deux listes. Cela ne choisit ni un fournisseur, ni une machine.
Le contrôle de région n'est pas un sélecteur de centre de données. MACRO_REGIONS dans deploy_module contient cinq clés, africa, apac, na, latam et emea, chacune portant un tableau farm_locations de codes métropolitains, un tableau de préfixes de slugs DigitalOcean et une coordonnée représentative. Choisir une région restreint le bassin de candidats à ces codes et amorce le tri par distance avec cette coordonnée. Tout le reste est de l'arithmétique sur la capacité en temps réel des nœuds, dans l'ordre ci-dessous, et la dernière étape est celle à connaître avant de vous engager : quand le bassin restreint revient vide, le déploiement est refusé plutôt que déplacé silencieusement.
- La région est une paire de listes. apac nomme sin, blr et syd ; na nomme ash, hil, sea, nyc, sfo et tor ; emea nomme hel, fsn, nbg, ams, lon et fra. Cela fait 15 des 15 codes métropolitains de FARM_LOCATIONS. africa et latam ne nomment aucun emplacement de ferme ni aucun préfixe DigitalOcean propre, leur bassin de candidats est donc vide par construction, pas par charge.
- Chaque candidat est mesuré par rapport à votre taille plus 20 pour cent. Le placement multiplie les cœurs, la RAM et le disque demandés par 1 + proxmox.headroom_pct/100, et config.json fixe headroom_pct à 20. Un optimized_vps_4 à 4 vCPU, 16 Go et 100 Go a donc besoin de 4,8 cœurs libres, 19,2 Go de RAM libre et 120 Go de disque libre sur un nœud avant que ce nœud soit même éligible.
- Puis la classe de disque, puis la distance. SERVER_TYPE_DISK_PREF restreint performance et large à nvme uniquement, optimized à ssd puis nvme, et shared à hdd, ssd, puis nvme. Les nœuds de ferme non étiquetés comptant comme nvme, sur le parc actuel chaque type finit sur du NVMe. Les survivants sont triés par distance à vol d'oiseau depuis la coordonnée de la région, le nœud le plus proche qui convient l'emporte donc.
- Une région pleine reçoit une réponse honnête, pas un contournement. proxmox.do_failover est faux, donc get_region_hosting_options renvoie provider farm ou provider unavailable avec le motif no_capacity quand la région a des métropoles mais pas de place, et no_farm_region pour africa et latam. DigitalOcean n'est jamais substitué automatiquement en coulisses : il n'est accessible que par une épingle explicite ou depuis la liste complète des options.
Sept étapes sont déclarées. Une seule s'exécute.
config.json déclare job_steps sur deploy_vps, et register_job stocke ce tableau tel quel avec current_step 1 et total_steps 7. Ces sept chaînes sont le texte littéral de la barre de progression que voit un client pendant un déploiement. Sur le chemin de la ferme, la création est farm_create_app, et elle n'émet aucune mise à jour de tâche : le seul update_job de toute la création VPS se trouve dans deploy_vps avant que le provisionnement ne soit délégué. Les deux colonnes ci-dessous répondent aux sept mêmes lignes dans le même ordre, la déclaration à gauche et le code à droite, car l'écart entre les deux est précisément le sujet.
Trois adresses, dont deux seulement sont les vôtres à saisir.
Un VPS de ferme sans IPv4 dédiée n'a aucune IPv4 publique du tout. Il détient une adresse VNet interne sur son nœud, un /24 par nœud, plus une IPv6 publique quand ce nœud porte un /64 routé. L'accessibilité est construite plutôt que présumée : à la première activation, la plateforme provisionne une route de proxy inverse sur un nom d'hôte <sub>.xuda.app pour le navigateur, et un tunnel WebSocket vers le port 22 pour le shell. Une IPv4 dédiée n'a pas de palier minimum et est conditionnée uniquement à la capacité libre du nœud ; si aucun nœud ne peut l'honorer, la demande est retirée et le déploiement continue sur le nom d'hôte partagé plutôt que d'échouer.
Région, taille, et la machine est à vous.
deploy_vps ne porte aucun min_plan, donc n'importe quel compte, y compris gratuit, peut créer un VPS, et deploy_datacenter juste à côté exige clearance admin avec min_plan pro. L'appartenance ne change aucun prix : member_price_id n'existe que sur les plans ai_workspace, et aucun slug de serveur ne porte d'identifiant de prix Stripe ni de tarif membre. L'hébergement est mesuré plutôt qu'abonné, calculé au prorata d'un mois fixe de 730,5 heures avec un segment facturable minimum d'une heure.
- 01
Choisissez une région et une taille
La gamme VPS compte 17 slugs en quatre types : shared à partir de 1 vCPU, 0,5 Go et 10 Go pour 2,50 $ jusqu'à 8 vCPU, 16 Go et 320 Go pour 94 $ ; optimized de 66 $ à 542 $ ; performance de 166 $ à 1006 $ et jusqu'à 32 vCPU, 256 Go et 800 Go pour 1342 $ ; large de 650 $ jusqu'à 32 vCPU, 256 Go et 7200 Go pour 2606 $. Le type n'est pas une étiquette marketing, c'est la chaîne de classe de disque que le placement respectera. La liste d'OS compte cinq images, Ubuntu 24.04 LTS, Ubuntu 22.04 LTS, Debian 12, Rocky Linux 9 et AlmaLinux 9. Il n'y a ni marketplace de ferme ni catalogue d'applications en un clic.
- 02
La VM se clone et démarre
Un palier est copié tel quel, pas interprété : slug_to_farm_spec renvoie cores, ram_gb et disk_gb à partir du slug, la création clone un modèle avec full: 1 pour que ce soit une machine QEMU complète plutôt qu'un conteneur ou un clone lié, définit cores, définit memory à ram_gb fois 1024 Mo, redimensionne scsi0 à disk_gb et la démarre. Dès que la VM affiche running, l'application est marquée active, car pour un VPS brut il ne reste rien à attendre. deploy_module effectue 84 appels vers des chemins /qemu/ et zéro vers /lxc/.
- 03
Prenez le relais via la route web et le tunnel
Le nom d'hôte du navigateur et l'accès SSH sur WebSocket sont tous deux assurés pendant la création, la machine est donc accessible avant même que vous ayez configuré quoi que ce soit dessus. À partir de là, elle est vôtre au sens littéral : la plateforme n'applique aucun pare-feu de VM à un VPS brut, ne s'y connecte pas et n'y installe rien. Deux limites à anticiper. Le redimensionnement se fait hors ligne et le disque ne peut que grandir : farm_resize_app refuse tant que la VM n'affiche pas stopped, prend le plus grand entre le disque actuel et celui demandé, et laisse le système de fichiers invité grandir au prochain démarrage que vous effectuez. Et le stockage bloc, bien que livré, est désactivé : proxmox.block_storage.nfs_mount est vide dans les deux configurations, chaque méthode de volume répond donc que le stockage bloc n'est pas configuré.
Neuf choses qu'un VPS Xuda ne fait pas, quatre d'entre elles promises par l'interface qui l'entoure.
- Rien n'y est installé. farm_create_app marque un VPS actif dès que la VM signale running, et la branche d'installation en dessous est conditionnée par if (_conf.is_debug && !isVpsApp), elle ne s'exécute donc jamais sur une machine client. Ce qui démarre est l'image cloud nue avec les clés SSH que vous avez fournies. cpi/deploy_module/index.mjs lignes 13621 à 13641.
- La plateforme n'y applique aucun pare-feu. proxmox_apply_firewall renvoie immédiatement la chaîne vps: customer-managed firewall aux lignes 12369 à 12372, et le document de pare-feu par application écrit ensuite porte des tableaux de règles entrantes et sortantes vides, application désactivée, dans cpi/firewall_module/index.mjs lignes 551 à 596. Fermer les ports est votre travail, rien sur la machine ne le fait pour vous.
- Le stockage bloc est livré et désactivé. proxmox.block_storage.nfs_mount est une chaîne vide dans config.json comme dans config_dev.json, les six méthodes farm_volume_, create attach detach resize list delete, répondent donc toutes que le stockage bloc n'est pas configuré. index.mjs ligne 14022. Votre disque est ce que le slug porte plus tout ce que vous avez fait grandir.
- Le sélecteur Full Stack VPS et le serveur ne sont pas d'accord. Power.vue ligne 219 liste le groupe managed moins ses deux plus petites entrées, ce qui laisse shared_managed_4 et shared_managed_8 sélectionnables, et index.mjs ligne 1748 refuse tout slug dont le type est shared avec le message : le type de serveur shared n'est pas disponible pour un Full Stack VPS. config.json ne porte non plus aucun bloc full_stack_vps : les 13 groupes d'outils et 81 méthodes ne vivent que dans config_dev.json, sur la configuration de production cette clé se résout donc en une liste d'autorisation vide.
- Les 58 slugs se résolvent à 29 identifiants de fournisseur distincts, et 16 de ces identifiants sont partagés par plusieurs slugs. lookup_server_info essaie d'abord la clé, puis parcourt par .id et renvoie la première correspondance, cost.mjs lignes 46 à 54. Pour 12 des 16, la première entrée du fichier est celle du groupe déploiement, un document ancien ayant stocké gd-2vcpu-8gb au lieu de optimized_vps_2 facture donc 73 $ par mois pour une machine listée à 66 $.
- Les six slugs service_hosting_, basic cpu general compute balanced memory, portent tous disk 50 et sont tarifés de 24 $ à 129 $ uniquement sur le CPU et la RAM. Ce sont des machines du groupe déploiement pour des services dont les données vivent dans le centre de données, elles ne sont pas proposées dans le flux VPS. config.json lignes 938 à 991.
- Les job_steps déclarés pour deploy_vps promettent setting vps firewall, setting vps backup plan, connecting to vps server, installing vps resources et activating the server. farm_create_app n'émet aucune mise à jour de progression propre, sur le chemin de la ferme seul creating vps server apparaît donc. Les quatre étapes suivantes sont de la déclaration, pas du travail.
- La liste de fonctionnalités vps dans la configuration revendique SSD-Based Servers, 1-Click App Install et Managed Backups. La préférence de disque partagé est hdd puis ssd puis nvme, la ferme offre cinq images d'OS et aucune marketplace, et les sauvegardes sont un module complémentaire optionnel à 10 $ par mois. config.json lignes 781 à 791.
- app_server_type est mandatory: false sur deploy_vps. Un déploiement global sans slug provisionne le plancher de 1 vCPU, 0,5 Go, 10 Go, n'écrit aucun app_cost, et is_billable renvoie ensuite false, la machine tourne donc sans rien facturer. Le contrôle de solde qui aurait dû le détecter, validate_account_topup, est commenté à la ligne 1480 d'index.mjs.
Les six questions auxquelles le tableau tarifaire ne répond pas
Réponses confrontées au code livré et aux clés de configuration qui les déterminent, y compris quand la réponse est non.
Regardez un clone devenir une machine en marche.
Un clone complet du modèle de VM, cœurs et mémoire écrits sur la copie, scsi0 redimensionné selon le disque du slug, puis le statut passant à actif dès que la VM signale running. La partie intéressante est ce qui ne se passe pas ensuite : aucune étape d'installation, aucun agent, aucun jeu de règles. Ce qui démarre est l'image d'OS que vous avez choisie avec les clés que vous lui avez données.
Choisissez un slug et une région, le placeur choisit la machine.
Dix-sept slugs, de 1 vCPU, 0,5 Go et 10 Go à 2,50 $ par mois jusqu'à 32 vCPU, 256 Go et 7200 Go à 2606 $, chacun étant une machine virtuelle QEMU complète clonée avec full: 1 plutôt qu'un conteneur. La région que vous choisissez est une clé macro, pas un fournisseur et pas une machine : le placement retient les nœuds de la ferme qui satisfont vos cœurs, votre RAM et votre disque plus 20 pour cent de marge, trie les survivants par distance à vol d'oiseau, et prend le plus proche. Si une région n'a pas de place, la réponse est no_capacity, pas un déplacement silencieux vers DigitalOcean, car do_failover est faux. La facturation tourne sur le compteur dès l'heure du démarrage.