Alternatives RMM auto-hébergées à la tarification par endpoint

Deux idées reçues accompagnent généralement le RMM auto-hébergé, et toutes deux sont fausses, dans des sens opposés. La première : la surveillance et la gestion à distance se facturent par endpoint, donc la facture grossit avec le parc, que le travail augmente ou non. La seconde : rapatrier le plan de gestion en interne supprime ce coût. En réalité, la catégorie se tarifie sur trois axes distincts, dont un seul est par appareil, et l'auto-hébergement ne supprime pas le coût : il le déplace sur une ligne que personne ne facture, vos propres heures. Un tarif par appareil évolue sur un axe que vous ne contrôlez pas, puisque ce sont vos clients qui décident du nombre de machines, et non de la quantité de travail que ces machines génèrent. Un serveur auto-hébergé évolue sur un axe que vous contrôlez, et vous impose une obligation de maintenance ainsi qu'un contrat de support que vous n'avez plus.

Certains contrats rendent l'option commerciale juste, quel que soit le calcul : un SLA que vous ne pouvez pas garantir personnellement à trois heures du matin est un produit que vous achetez, et l'auto-hébergement ne le fournit que lorsque le projet lui-même vend un niveau de support. La tarification par technicien bat déjà les deux alternatives sur une large plage de tailles de parc.

En bref

• La catégorie ne se tarifie pas uniformément par appareil. NinjaOne facture par appareil ; Syncro et Atera facturent par siège technicien avec appareils illimités ; ConnectWise, Datto RMM et N-able ne publient pas de prix de base pour la plateforme et renvoient les acheteurs vers un devis.
• Pour une petite structure avec un ratio appareils par technicien élevé, une plateforme par technicien peut battre la tarification par appareil et le modèle d'auto-hébergement Tactical RMM utilisé dans cet article. Vérifiez-le avant de provisionner quoi que ce soit.
• Sur le modèle de coût Tactical RMM de cet article, l'auto-hébergement revient généralement plus cher qu'une plateforme par technicien en dessous d'environ 400 endpoints. Autour du troisième siège technicien, il commence à devenir compétitif, mais le point de bascule exact dépend de votre taux horaire, du niveau de sponsoring, de la taille du serveur et du ratio appareils par technicien.
• Tactical RMM n'est pas open source. Il est distribué sous une licence propre, non approuvée par l'OSI, avec des restrictions sur le SaaS, l'hébergement managé et d'autres usages commerciaux. MeshCentral est sous Apache-2.0 et le cœur de NetLock RMM sous AGPL-3.0.
• Un serveur RMM est un chemin d'exécution de code à distance, de confiance, vers chaque machine qui exécute son agent. L'auto-hébergement ne crée pas cette exposition ; il vous transfère la responsabilité des correctifs.

Comment le RMM commercial tarifie les endpoints

Les tarifs par appareil publiés par NinjaOne vont de 1,50 $ par appareil et par mois à 10 000 endpoints jusqu'à 3,75 $ à 50 endpoints ou moins. Lisez cette courbe en partant du bas et le problème saute aux yeux : la remise sur volume favorise l'échelle, donc la structure qui a le moins de machines paie le tarif le plus élevé sur chacune d'elles, sur une facture qui grossit chaque fois qu'un client achète un ordinateur portable.

Syncro se tarifie sur un axe tout à fait différent : 129 $ par utilisateur et par mois pour le plan Core en facturation annuelle, 179 $ pour Team, chaque plan incluant un nombre illimité d'endpoints par technicien. Atera adopte la même forme et explique clairement pourquoi. Avec son modèle par technicien, le coût reste le même quel que soit le nombre d'appareils que vous ajoutez.

Reste le troisième groupe. Combien coûte ConnectWise RMM ? Sa page fait passer la tarification par un formulaire de demande qui liste des packages et des fonctionnalités sans aucun chiffre, et la page produit de Datto RMM décrit longuement la plateforme sans afficher le moindre prix. N-able commercialise N-sight de la même manière, et Kaseya fait un devis pour VSA. C'est un constat sur le contenu de ces pages, pas sur les intentions, mais cela a un coût. Obtenir un chiffre demande des appels commerciaux, et ces heures sont les vôtres.

La conséquence compte plus que n'importe quel tarif pris isolément. Une plateforme par technicien cesse complètement d'évoluer avec le parc. Une structure de deux personnes qui gère 350 machines paie ce que paie une structure de deux personnes qui en gère 90, et avec un ratio appareils par technicien élevé, ce modèle bat déjà à la fois la tarification par appareil et un serveur à vous.

Les plateformes auto-hébergées et ce que leurs licences autorisent

Quatre plateformes reviennent dans cette discussion, sous quatre licences réellement différentes, pas quatre variantes d'une seule. « RMM open source » est l'expression qui les regroupe toutes les quatre, et elle en dit plus qu'elle ne peut en tenir. Elles diffèrent aussi par la part de RMM qu'elles contiennent et par le serveur qu'elles exigent, et la différence de licence a des conséquences contractuelles pour quiconque vend des services managés.

Tactical RMM

Tactical RMM est la plus complète des quatre : gestion des correctifs, scripts, alertes et contrôles, avec un contrôle à distance assuré par une instance MeshCentral intégrée. La version actuelle est la v1.5.2, dont le changelog mentionne la correction d'une fuite mémoire dans le traitement des contrôles de stratégie et des tâches, plus une mise à jour du MeshCentral intégré vers la 1.2.4. Une couche de contrôle à distance native est en développement.

La licence demande de l'attention. Tactical RMM est distribué sous une « Tactical RMM License v1.0 » propre, dont le texte commence par indiquer qu' il ne s'agit pas d'une licence de logiciel open source. Elle accorde un usage gratuit pour surveiller et gérer vos propres réseaux ou ceux de vos clients, et interdit de proposer les fonctionnalités du logiciel dans le cadre d'un produit SaaS, d'un service d'hébergement managé ou de tout autre service à but lucratif sans l'autorisation du concédant. C'est l'écart entre le « source-available » (vous pouvez le lire et l'exécuter, aux conditions de l'auteur) et l'open source (une licence approuvée par l'OSI accordant une redistribution commerciale sans restriction). La licence autorise expressément l'hébergement et l'utilisation de Tactical RMM pour surveiller et gérer les réseaux de clients. Elle impose par ailleurs de larges restrictions sur la mise à disposition des fonctionnalités du logiciel dans le cadre de services commerciaux ou à but lucratif, et indique qu'une approbation écrite préalable est requise pour tout usage commercial ou service à but lucratif. Si votre modèle de MSP dépend de l'endroit où se situe cette frontière, obtenez une clarification écrite d'AmidaWare plutôt que de vous fier à une interprétation éditoriale.

Il y a aussi une ligne de coût, publiée intégralement. Les agents Windows signés, les agents Linux et macOS purement et simplement, l'authentification unique et le module Reporting sont tous derrière un niveau de sponsoring. Le niveau 1 à 55 $ par mois est le minimum pour des agents signés sur n'importe quelle plateforme ; le Reporting commence au niveau 2, à 80 $. Les niveaux supérieurs sont suggérés selon la taille du parc (niveau 4, à 155 $, pour moins de 1 000 agents) et, à partir du niveau 3, s'accompagnent d'un délai de réponse par e-mail annoncé. Des agents non signés posent un problème de support sur tout parc Windows digne de ce nom, donc à l'échelle, le niveau de sponsoring est une ligne de coût, pas une option.

MeshCentral

MeshCentral n'est pas un RMM complet, mais l'écart est plus étroit qu'il n'y paraît. Il prend en charge le contrôle à distance, l'inventaire des appareils, l'accès au terminal et aux fichiers, l'exécution de commandes et de scripts, ainsi que les notifications d'appareils et de sessions. Ce qu'il ne fournit pas, c'est le flux de travail RMM complet autour de ces primitives : les flux natifs de gestion des correctifs et l'automatisation planifiée de stratégies intégrée sont les principales lacunes.

C'est précisément cet écart qui explique pourquoi Tactical RMM a été construit par-dessus. Adopter MeshCentral en espérant remplacer NinjaOne produit une déception qui n'a rien à voir avec la qualité du logiciel (les couches de gestion des correctifs et d'automatisation des stratégies ne sont pas incluses, même si l'exécution de commandes et de scripts l'est).

NetLock RMM

NetLock RMM est open core, pas uniformément ouvert, et le projet le dit sans détour : après un lancement entièrement sous AGPL, les mainteneurs sont passés en 2026 à un modèle où le cœur reste ouvert sous AGPL mais où le code source de chaque fonctionnalité n'est pas publié, en suspendant les commits publics le temps de sélectionner ce qui est diffusé. Le cœur publié est sous GNU Affero General Public License v3, approuvée par l'OSI.

Sa forme commerciale diffère aussi de toutes les autres, et la limite entre niveaux concerne directement les lecteurs qui gèrent un parc. La Community Edition gratuite est auto-hébergée mais plafonnée à 25 appareils, ce qui la met hors de portée au-delà d'un homelab ou d'une évaluation. Le niveau auto-hébergé payant lève le plafond et inclut un nombre illimité d'appareils, d'utilisateurs, de tenants et de sites, avec un support professionnel. NetLock sépare explicitement ce modèle de ses offres hébergées dans le cloud, qui sont dimensionnées par appareil. L'offre auto-hébergée supprime donc le plafond d'appareils, mais son package commercial actuel inclut le support et d'autres avantages sous forme de bundle plutôt que de tarifer uniquement selon le délai de réponse. Ce que l'on échange, c'est la maturité et l'historique.

ITarian On-Premise

La version on-premise d'ITarian est un logiciel propriétaire issu de la lignée Comodo/Xcitium. L'auto-hébergement ne supprime pas son compteur de licences par appareil : la documentation de facturation actuelle d'ITarian vous accorde jusqu'à 50 appareils gérés gratuitement, mais dès que vous ajoutez le 51e appareil géré, les endpoints gérés sont facturés par appareil au tarif applicable. Il n'est pas open source et ne prétend pas l'être. Ce qui complique l'empreinte opérationnelle, c'est que la documentation on-premise actuelle d'ITarian est incohérente en interne. Son guide de déploiement décrit une configuration Docker Compose autonome pour un maximum de 1 000 endpoints, tandis que sa section sur les prérequis matériels indique une base de deux serveurs : un nœud ITSM à 8 cœurs, 8 Go de RAM et 100 Go de stockage, accompagné d'un nœud XMPP à 4 cœurs, 4 Go et 40 Go, tous deux donnés pour 1 000 endpoints. Je considérerais cela comme une base de dimensionnement à confirmer avec ITarian avant de budgéter, et non comme la preuve qu'un déploiement sur un seul serveur n'est pas pris en charge.

À retenir de cette section : « open source » désigne trois choses différentes sur ces quatre lignes, et seules deux d'entre elles correspondent à ce que l'expression promet normalement.

Ce que le serveur doit être

La documentation d'installation de Tactical RMM fixe le plancher avec précision : une VM Linux fraîche avec 4 Go de RAM sous Debian 11, Debian 12 ou Ubuntu 22.04 LTS. La même page indique qu'un seul cœur CPU suffit en dessous de 200 agents avec des contrôles limités, et que 50 Go de stockage suffisent pour moins de douze mois d'historique à ce volume.

Ces chiffres valent au-delà de Tactical RMM, parce qu'il intègre MeshCentral et que le plancher tient déjà compte de la couche de contrôle à distance. Le mot qui pèse le plus lourd ici est « fraîche ». L'installateur suppose un serveur sans aucun autre logiciel, et prévient que l'exécuter à côté de services existants cassera l'installation. Cela exclut d'installer le RMM sur une machine qui travaille déjà (le Nginx et le Postgres qu'il installe sont les siens, et il ne partagera pas les vôtres), ce qui fait du serveur une nouvelle ligne de coût, pas de la capacité disponible. Pour ce modèle de coût, je dimensionnerais au-dessus du minimum publié plutôt que d'optimiser au plus juste : 2 vCPU et 4 Go de RAM autour de la centaine, avec 4 vCPU et 8 Go comme cible de planification plus sûre vers plusieurs centaines. Ce sont des hypothèses de planification pour cet article, pas les minimums publiés de Tactical RMM. ITarian demande une réflexion de dimensionnement à part, parce que sa documentation actuelle donne des signaux contradictoires entre déploiement autonome et à deux nœuds.

La gestion des endpoints et la supervision d'infrastructure sont constamment confondues, et ce n'est pas le même métier. Un RMM installe un agent sur les machines des utilisateurs pour les corriger, y exécuter des scripts et en prendre le contrôle à distance, ce qui est différent de demander si un hôte répond. Le raisonnement sur l'emplacement est le même dans les deux cas, et c'est le même argument en faveur d'une machine séparée de ce qu'elle surveille qui s'applique à tout moniteur de disponibilité. Un serveur de gestion qui vit à l'intérieur du site qu'il gère tombe avec lui, précisément le jour où vous en avez besoin.

LIRE

Comment installer Uptime Kuma sur un VPS

Le seuil de rentabilité

Quatre chiffres tranchent la question, et deux vous appartiennent plutôt qu'à un éditeur : ce que coûte l'abonnement commercial à la taille de votre parc, ce que coûte un serveur, combien d'heures par mois il vous prend, et ce que vaut une heure de votre temps. Les voici tous, étiquetés.

Chiffres sourcés. La fourchette par appareil de NinjaOne et les tarifs par siège de Syncro proviennent des pages de tarification des éditeurs liées ci-dessus, les tarifs des niveaux de sponsoring du tableau de sponsoring publié par Tactical RMM lui-même, et le plancher de spécifications du serveur de la documentation d'installation de Tactical RMM.

Hypothèses posées, qui sont celles de cet article et non d'un éditeur. Le prix du serveur est une valeur indicative : 35 $ par mois pour la petite instance et 70 $ pour la plus grande, à remplacer par ce que votre propre fournisseur facture pour ces spécifications. Le temps d'exploitation est de quatre heures par mois à 50 et 200 endpoints, et de six dans l'exemple proche de 1 000 endpoints, couvrant les correctifs, les mises à niveau, le dépannage des agents et l'incident occasionnel. Le taux horaire est de 50 $, en tenant lieu d'heure de technicien tout compris ; le Bureau of Labor Statistics publie une médiane actuelle pour les administrateurs réseau et systèmes, mais le chiffre qui compte est votre propre taux facturable. Le nombre de techniciens suppose environ 200 appareils par technicien (si le vôtre est plus serré, ajustez le nombre de sièges et le seuil bouge avec). La ligne de sponsoring est le niveau 1, le minimum publié pour la signature de code, pour les deux parcs les plus petits, et le niveau 4 dans l'exemple proche de 1 000 endpoints ; Tactical suggère le niveau 4 pour moins de 1 000 agents.

La ligne par appareil est une fourchette à 200 et 1 000 parce que NinjaOne publie les deux extrémités de sa courbe, pas les paliers intermédiaires. Le bas de chaque fourchette est le tarif plancher à 10 000 endpoints, qu'un parc de cette taille ne se verra pas proposer ; c'est donc délibérément généreux envers l'option commerciale. Si l'auto-hébergement gagne contre cela, il gagne contre le tarif qu'on vous proposera.

Les deux points de bascule ne sont pas au même endroit. Face à la tarification par appareil, la ligne auto-hébergée de 290 $ couvre 78 machines à 3,75 $ chacune et 194 au plancher de 1,50 $, donc l'auto-hébergement prend le dessus quelque part entre 80 et 190 appareils environ, selon la position de votre contrat dans cette fourchette. Face à la tarification par technicien, le tableau change du tout au tout. Avec un ratio de 200 appareils par technicien, un siège Syncro vous couvre jusqu'à 200 endpoints (129 $), deux jusqu'à 400 (258 $) et trois jusqu'à 600 (387 $), et la ligne auto-hébergée ne passe sous cette courbe qu'au troisième siège, juste après 400 appareils.

En dessous d'environ 400 endpoints, auto-héberger un RMM complet est généralement l'option la plus chère selon ces hypothèses. C'est le second point de bascule qui compte, parce qu'une plateforme par technicien est disponible cet après-midi et ne vous demande rien à provisionner, rien à corriger et aucune responsabilité à porter.

Deux de vos propres chiffres déplacent ce seuil. Divisez par deux le taux supposé, à 25 $ de l'heure, et la ligne auto-hébergée du petit parc passe de 290 $ à 190 $. Doublez-le à 100 $ et cette même ligne monte à 490 $ avant même d'ajouter un niveau de sponsoring supérieur ou un serveur plus grand. Ces variations peuvent déplacer le point de bascule de plusieurs centaines d'endpoints, alors utilisez le niveau de sponsoring et les heures de maintenance que vous choisiriez réellement à la taille de votre parc, plutôt que de traiter 400 comme un seuil universel.

Ce que l'auto-hébergement vous remet entre les mains

En juillet 2021, une faille zero-day de divulgation d'identifiants dans les serveurs Kaseya VSA on-premise, CVE-2021-30116, a été exploitée dans la nature. Le catalogue Known Exploited Vulnerabilities de la CISA la décrit comme donnant à un attaquant un identifiant de session utilisable pour lancer d'autres attaques contre le système, et la signale comme ayant servi dans des campagnes de ransomware.

Trois ans plus tard, la CVE-2024-1709 de ConnectWise ScreenConnect, un contournement d'authentification noté CVSS 10.0 sur les versions 23.9.7 et antérieures, est entrée dans le même catalogue et a été exploitée dans la nature pour déployer des ransomwares, et le rapport post-exploitation de Huntress relève des attaquants qui déploient des mineurs de cryptomonnaie par ce biais. Aucun des deux incidents ne plaide contre le RMM commercial, et aucun ne plaide pour. Sous les deux se trouve le même fait. Un serveur RMM est un chemin d'exécution de code à distance, de confiance, vers chaque machine qui exécute son agent : c'est la conception qui fonctionne comme prévu, et exactement pourquoi elle mérite cette vigilance. Compromettez le plan de gestion et vous avez compromis le parc, que ce plan appartienne à un éditeur ou à vous.

Ce qui change quand vous auto-hébergez, c'est qui applique les correctifs, à quelle vitesse, et qui porte le nom sur l'incident. Ces plateformes ont leurs propres vulnérabilités documentées. Tactical RMM a la CVE-2025-69516, une injection de template côté serveur dans l'endpoint de prévisualisation des rapports qui permettait à des utilisateurs de rapports peu privilégiés d'atteindre l'exécution de commandes à distance, et la CVE-2025-69517, une injection HTML dans l'endpoint de création d'agents, dont la fiche se conclut sur la position du fournisseur selon laquelle elle contient des informations incorrectes. Toutes deux sont notées 8.8 et enregistrées comme affectant la v1.3.1 et antérieures, face à une v1.5.2 actuelle. MeshCentral a la CVE-2024-26135, un détournement WebSocket intersite via control.ashx qui peut compromettre une session administrateur, notée CVSS 8.3 et enregistrée comme affectant les versions antérieures à 1.1.21, face à une 1.2.5 actuelle. Les versions actuelles se situent hors des plages affectées des trois CVE citées ici. Cela ne supprime pas la surface d'attaque ; cela fait de la mise à jour continue une partie du modèle d'exploitation. C'est une surface d'attaque activement étudiée, et c'est vous qui devez garder une longueur d'avance.

L'autre chose qui change, c'est la contrepartie. Deux des quatre vendent leur propre niveau de support : les offres payantes de NetLock RMM et les niveaux de sponsoring supérieurs de Tactical RMM. Le tableau du support est inégal. MeshCentral est porté par la communauté, tandis qu'ITarian est un produit commercial soutenu par un éditeur, avec son propre canal de support et ses propres conditions de licence. Pour un opérateur dont la panne du RMM est un incident visible par le client, avec un contrat à la clé, cette contrepartie est ce qu'un accord commercial vend réellement.

La conformité joue parfois dans l'autre sens, de façon étroite. Dans un fil r/msp sur les options auto-hébergées, un opérateur décrit un contrat exigeant que « la connexion du personnel d'administration à distance passe par un chemin chiffré (certifié FIPS 140-2) », et explique que l'auto-hébergement est ce qui lui permet de le satisfaire, puisqu'un module VPN certifié peut porter la connexion là où la plupart des éditeurs n'ont pas déposé de demande de certification. Un contrat dans un fil n'est pas une tendance, mais c'est un cas où l'auto-hébergement est la réponse conforme plutôt que la réponse bon marché.

La question Tactical RMM de 2021

Quiconque évalue Tactical RMM tombera dessus en moins d'une heure de recherche. Dans un fil r/sysadmin de décembre 2021, un chercheur a trouvé du code de minage de Monero dans des binaires d'agent hébergés sur le miroir de fichiers de secours du projet. Le développeur a répondu publiquement, et cette réponse est la source de tout ce qui suit :

« yes those are 1.98.XXX are my own personal builds that have extra binaries embedded in them (using golangs new embed feature added in go 1.16) and I use them on my own machines to mine monero. » (« oui, ces 1.98.XXX sont mes builds personnels, avec des binaires supplémentaires intégrés (via la nouvelle fonction embed de Go ajoutée en go 1.16), et je les utilise sur mes propres machines pour miner du monero. »)

Le développeur de Tactical RMM, r/sysadmin, 2021

Il a indiqué dans la même réponse que l'agent de production ne télécharge pas ces builds, et que le miroir est une solution de secours pour les dépendances Python. Il y a aussi confirmé que l'agent avait cessé d'être open source avec l'arrivée de la signature de code et que le développement avait migré vers un dépôt privé, si bien que le code public était obsolète et que l'agent distribué n'était pas publiquement auditable à l'époque.

Ce que le dossier ne contient pas, c'est un audit de sécurité tiers achevé. L'assurance que l'agent de production est propre repose sur la déclaration du développeur lui-même, plus l'analyse informelle en bac à sable d'un commentateur. Les deux résumés qui circulent en font trop : « ce n'était rien » ignore que des binaires de minage ont été servis depuis l'infrastructure du projet alors que le code source de l'agent n'était pas auditable, et « l'outil embarque un cryptomineur » affirme quelque chose qu'aucune preuve publiée n'établit. Ma lecture est qu'il s'agit d'un jugement sur des pratiques opérationnelles plutôt que d'une conclusion technique établie.

Lequel convient à quel opérateur

Restez sur une offre commerciale, et laissez de côté les alternatives RMM auto-hébergées, si l'une de ces trois conditions est remplie. Un contrat client exige un éditeur nommément désigné. Votre ratio appareils par technicien fait déjà de la tarification par technicien votre ligne la moins chère, ce qui couvre la plupart des parcs de moins de 400 appareils. Ou personne ne prendra réellement en charge le serveur, ce qui fait de la ligne d'heures d'exploitation une fiction.

Choisissez Tactical RMM si vous voulez l'ensemble de fonctionnalités le plus complet, que vous gérez des réseaux internes ou de clients, que vous êtes à l'aise pour posséder un serveur Linux en production, et que vous paierez le niveau de sponsoring. Si votre modèle commercial pouvait tomber sous les restrictions plus larges de la licence sur les services à but lucratif, obtenez une clarification écrite d'AmidaWare avant de le déployer pour des clients.

Choisissez NetLock RMM si un cœur approuvé par l'OSI et une offre auto-hébergée payante avec appareils illimités et support professionnel comptent plus que l'historique, et que vous acceptez un projet plus jeune dont le dépôt public n'est plus qu'un sous-ensemble sélectionné du code. Sachez clairement quel niveau vous achetez. La Community Edition gratuite s'arrête à 25 appareils, donc à quelques centaines d'endpoints, c'est un produit payant, et son attrait est un prix qui ne bouge pas quand un client achète douze ordinateurs portables de plus.

Choisissez MeshCentral seul uniquement si votre besoin principal est l'accès à distance, l'inventaire et l'exécution ponctuelle de commandes ou de scripts, plutôt que la gestion complète des correctifs et l'automatisation de stratégies d'un RMM. Il est mature, sous licence permissive et solide dans ce qu'il fait. Si le contrôle à distance est toute votre exigence, comparez-le aussi aux options de bureau à distance dédiées, puisque RustDesk couvre un terrain similaire avec un accent différent sur les fonctionnalités. L'erreur, c'est de traiter l'un d'eux comme un substitut de RMM complet.

Choisissez ITarian on-premise uniquement si garder le plan de gestion dans votre propre infrastructure compte plus qu'échapper à la tarification par appareil, et si vous voulez une entreprise établie derrière le produit malgré la licence propriétaire et l'empreinte plus lourde. Confirmez la topologie de déploiement prise en charge avant de budgéter.

Si la réponse est l'auto-hébergement, le plan de gestion a besoin d'un endroit où vivre en dehors des sites qu'il gère, joignable le jour où l'un de ces sites ne l'est pas. Concrètement : un serveur Linux persistant sous Debian ou Ubuntu, un accès root, rien d'autre en concurrence, et vous qui le maintenez à jour. Notre Linux VPS auto-géré est exactement ce type de machine, dimensionné à partir des spécifications génériques ci-dessus. Si ce dont vous avez besoin s'avère être le contrôle à distance plutôt qu'une plateforme de gestion complète, RustDesk se déploie en un clic.

Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.

Voir les plans Linux

Foire aux questions