Ton projet tourne en local. Mets-le en ligne.
Dépose le dossier. On installe, on construit et on sert — sur du vrai Kubernetes, en HTTPS, en une minute environ. Rien à configurer.
De l'archive au service en ligne
Chaque étape est explicite. Quand quelque chose bloque, on te dit quoi corriger et où.
Ce que tu déposes décide de ce que tu reçois
Aujourd'hui, une seule chose — mais elle marche de bout en bout, pas sur le papier.
Les workers (bots, tâches planifiées), les services HTTP et les serveurs MCP sont écrits et testés, mais aucun n'a encore tourné en production. Ils arriveront quand ils auront été prouvés, pas avant.
Ton code s'exécute une fois, dans un bac à sable
Construire, c'est exécuter les scripts d'installation de tout ton arbre de dépendances. C'est traité comme tel.
Le build tourne sous gVisor, en non-root, sans jeton de service : le pod ne peut pas parler à Kubernetes du tout.
Internet en 80/443 pour npm, et rien de privé. Un build qui atteindrait Vault ou un autre locataire vaudrait plus qu'un build.
L'archive produite repasse par la même frontière que ce que tu as téléversé. Les vérifications du script de build te rendent service ; elles ne nous garantissent rien.
Bêta privée, et on le dit
Pas de grille à trois colonnes pour un produit qui n'a pas de facturation. Voici ce qu'il y a.
Les limites réelles