Plateforme · Applications
Six étapes que
vous n’aurez pas à faire.
Installer un programme, sur le Hub, c’est choisir une fiche du catalogue et répondre à quelques questions. La base, les secrets, l’adresse, le certificat, la route et la connexion sont posés par le Hub.
Ce que ça vous évite
Le déploiement fait à la main, différent à chaque fois
Chaque programme s’installe par le même chemin, qui se rejoue à l’identique.
Le programme qui ne tourne que sur le serveur de son auteur
Il est livré comme une image signée, rangée dans un registre. Ce qui tourne est ce qui a été publié.
La mise à jour qui efface les données
Le programme est remplacé, sa base et ses fichiers restent.
L’installation, en six étapes
Une base de données
Un schéma PostgreSQL propre au programme, créé et isolé des autres.
Un coffre de secrets
Un chemin dans le coffre du Hub (Vault) pour ses mots de passe et ses clés.
Une adresse
L’enregistrement DNS du programme, dans la bonne zone.
Un certificat
HTTPS, sauf si un certificat joker du domaine le couvre déjà.
Une route
Le proxy envoie le trafic de cette adresse vers le conteneur.
La connexion unique
Les utilisateurs du Hub sont reconnus par le programme, selon leurs droits.
Ce que fait le Hub ensuite
Catalogue
Chaque programme installable y a sa fiche : son image, sa version, les questions posées à l’installation, les valeurs remplies d’office.
Registre signé
Les versions sont publiées dans un registre et signées (Ed25519). Un Hub peut suivre plusieurs sources de catalogue.
Mises à jour
Une nouvelle version remplace le conteneur ; la base, les fichiers et la configuration restent.
Journaux et mémoire
Les journaux de chaque programme se lisent et se téléchargent depuis la console. La mémoire se mesure et se plafonne programme par programme.
Sur vos machines aussi
Le même catalogue installe un programme sur un minihub : votre machine, votre réseau, la même console.
Ce que publie le programme
Un programme construit sur Socle V005 expose ses propres actions : le Hub les découvre et les rend appelables par les agents IA de la plateforme.
Sous le capot
| Workers | docker_worker, app_registry_worker, catalog_sync_worker, repository_editor_worker, db_worker, vault_worker |
| Actions | install_app, update_app, start_app, stop_app, restart_app, uninstall_app, get_logs, get_stats, list_env_vars, set_env_var, set_memory_limit, get_memory_usage ; list_catalog, force_sync, publish_version, regenerate_manifest ; create_app_schema, create_app_path, audit_app_bundles |
| Pipeline | AppInstallPipeline : base, Vault, DNS, certificat, route, SSO |
| Variables garanties | APP_ID, APP_BASE_URL, DATABASE_*, VAULT_ADDR, VAULT_TOKEN, REDIS_* si demandé, IAM_JWKS_URL pour une application TheSocle |
| Ce que l’installation ne crée pas | ni compartiment S3, ni flux NATS, ni clé d’API publique : ils sont communs ou se créent à part |
| Console | /hub/apps, /hub/apps/deploy, /hub/repository, /hub/logs |
Les actions MCP d’une application sont découvertes toutes les cinq minutes, pas déclarées : il suffit que l’application les publie.
En chiffres
Relevés le 2026-09-23 sur le Hub thesocle.net.
- 25
applications installées - 26
fiches au catalogue
État
Opérationnel pour le catalogue, l’installation, les mises à jour, les journaux et la mémoire (Hub 3.51.1, relevé du 2026-09-23).
Partiel : le coffre de secrets. Chaque nouvelle installation reçoit son accès au coffre ; des applications plus anciennes sont remises à niveau une par une.
Limites actuelles : une application correspond à un conteneur, sans montée en charge automatique. Le Hub juge de sa santé par l’état du conteneur, pas par une sonde HTTP.