Aller au contenu
100+ endpoints control-plane
Specs OpenAPI par service — clients typés dans n'importe quel langage
Token-binding ED25519 optionnel pour les tokens hdy_
Tokens scopés par realm · whitelist IP CIDR
Pause, snapshot, copie, sync
General balance → AI balance (unidirectionnel)
100+ endpoints control-plane
Specs OpenAPI par service — clients typés dans n'importe quel langage
Token-binding ED25519 optionnel pour les tokens hdy_
Tokens scopés par realm · whitelist IP CIDR
Pause, snapshot, copie, sync
General balance → AI balance (unidirectionnel)
100+ endpoints control-plane
Specs OpenAPI par service — clients typés dans n'importe quel langage
Token-binding ED25519 optionnel pour les tokens hdy_
Tokens scopés par realm · whitelist IP CIDR
Pause, snapshot, copie, sync
General balance → AI balance (unidirectionnel)
100+ endpoints control-plane
Specs OpenAPI par service — clients typés dans n'importe quel langage
Token-binding ED25519 optionnel pour les tokens hdy_
Tokens scopés par realm · whitelist IP CIDR
Pause, snapshot, copie, sync
General balance → AI balance (unidirectionnel)
Hoody Platform

La couche cycle de vie. Une seule API.

api.hoody.com est l'endroit où les conteneurs prennent vie. Créer, mettre en pause, snapshot, copier entre serveurs, isoler en realm, facturer — tout en HTTP.

100+ endpoints. Specs OpenAPI par service. Tokens scopés par realm. Pause, snapshot, copie, sync — sur la même surface.

Tokens hdy_OpenAPI par serviceIsolation par realmWallet unidirectionnel
POST /api/v1/projects/ID/containers

# create a container

$ curl -X POST https://api.hoody.com/api/v1/projects/ID/containers \

-H "Authorization: Bearer hdy_..." \

-H "Content-Type: application/json" \

-d '{"server_id":"node-us-1","name":"dev-box","container_image":"debian/13"}'

 

<< 201 Created

{ "id": "507f1f77…", "status": "creating" }

Cycle de vie du conteneur

Six états. Transitions explicites.

Les conteneurs évoluent dans une machine à états définie. Chaque transition a un endpoint, et chaque transition est un événement enregistré dans l'historique du container.

creating

Provisioning du filesystem et des ressources

running

Vivant et servant ses URLs

stopped

Éteint · stockage facturé

paused

RAM gelée · reprise instantanée

failed

Erreur pendant une opération

copying

Duplication async en cours

Endpoints de transition

POST/containers/ID/start

POST/containers/ID/stop

POST/containers/ID/force-stop

POST/containers/ID/restart

POST/containers/ID/pause

POST/containers/ID/resume

POST/containers/ID/network/start

POST/containers/ID/network/stop

Pause · snapshot · restore

Mettez en pause le travail en cours. Snapshot des machines entières.

Gelez la RAM avec pause/resume. Capturez filesystem, processus et mémoire avec des snapshots stateful. Restaurez un conteneur à un moment antérieur sans rien réinitialiser.

Sommeil du conteneur, pas un shutdown

  • État RAM gelé sur place ; fichiers ouverts et pools de connexions DB conservés
  • Pause un LLM en pleine inférence — reprends sans réchauffer le contexte
  • Pause un job d'automatisation pour la nuit — reprends le matin
  • POST /containers/ID/pause · POST /containers/ID/resume

Git pour ordinateurs

  • Créer pendant le running = stateful (filesystem + processus + mémoire)
  • Créer pendant le stopped = stateless (filesystem seul)
  • Alias de snapshot jusqu'à 100 caractères, expiration auto en jours optionnelle
  • POST /containers/ID/snapshots · PATCH /containers/ID/snapshots/NAME pour restaurer
Copie · sync

Branchez un container. Gardez-le en sync.

Copiez l'état complet d'un conteneur — historique des snapshots inclus — vers un autre serveur ou région. Sync propage les changements incrémentaux de la source vers la copie.

Conteneur source

container-67e89abc…

server: node-us-east-1

POST /containers/ID/copy
Conteneur cible

container-abc1234d…

server: node-eu-west-1

POST /containers/ID/sync (unidirectionnel, incrémental)

target_project_id pour la copie cross-projet

source_snapshot pour copier un état spécifique

Temps typique : 3 à 5 min même serveur (50GB), 10 à 15 min cross-serveur (50GB)

Sync écrase les changements locaux sur la copie. Ce n'est pas bidirectionnel — les changements source vont vers la copie, jamais l'inverse.

Isolation · facturation

Isolation et facturation sont des primitives API

Les realms scopent l'hôte API lui-même. Le split du wallet empêche un compromis de bouffer votre budget infra.

Multi-tenancy au niveau API

https://REALM_A.api.hoody.com
https://REALM_B.api.hoody.com
  • Les agents IA dans le realm A ne peuvent littéralement pas voir les ressources du realm B
  • Les tokens sont scopés à des realms spécifiques via realm_ids
  • L'isolation par realm est au-dessus du RBAC projet — elle change l'hôte API

Balances General et AI

Solde général
Finance l'hébergement infra
transfert + frais
Solde AI
Finance l'usage LLM
  • Un workload IA compromis ne peut pas vider le budget infra
  • Stripe (PCI-compliant), 100+ cryptos (NOWPayments), virement bancaire
  • Factures PDF auto-générées · historique de transactions paginé
Surface API complète

La surface API complète

Groupée par ressource. Chaque endpoint a une spec OpenAPI.

Auth et tokens

25+ endpoints

OAuth, signup, login/refresh/logout JWT, 2FA avec codes de secours, tokens hdy_ longue durée avec whitelist IP CIDR et scoping par realm

Conteneurs & cycle de vie

20+ endpoints

CRUD, stats, start/stop/pause/resume/restart, règles de firewall, démarrage/arrêt réseau

Snapshots, Copie & Sync

10+ endpoints

CRUD snapshot avec alias et expiration, copie async cross-serveur, sync incrémental unidirectionnel

Wallet & Facturation

20+ endpoints

Balances, transactions, méthodes de paiement (Stripe + crypto + virement), paiements, factures avec PDF, transferts general→AI

Realms & Projets

5+ endpoints

Listing des realms avec stats d'usage optionnelles, CRUD projet, listing de conteneurs scopé par projet

Alias proxy · permissions · logs

31 endpoints

Servis par le Control Plane mais documentés sur /platform/proxy — alias (6), permissions (17), logs (8)

Chaque service publie sa propre spec OpenAPI (ex. Hoody SQLite, Hoody Terminal, Hoody Cron) — génère des clients typés dans n'importe quel langage.

Control Plane vs orchestration traditionnelle

Ce que l'orchestration traditionnelle vous demande d'assembler

Terraform, kubectl, AWS SDK et les APIs du daemon Docker couvrent chacun une partie de ce que couvre le Control Plane dans une seule surface. Voici un partage honnête.

CapacitéControl PlaneStack traditionnelle
CRUD conteneurPOST /projects/ID/containersProvider Terraform + module + apply
Pause de l'état RAMPOST /containers/ID/pause · /resumePas d'analogue direct (suspend VMware)
Snapshot running + RAMPOST /containers/ID/snapshotsScripts custom + snapshots VM
Copie cross-serveurPOST /containers/ID/copy + /syncrsync + bootstrap manuel + ré-enregistrement
Isolation API multi-tenantrealm_ids[] · REALM.api.hoody.comCouches RBAC + discipline namespace
Facturation unifiée + crédits LLMgeneral → AI transfer (one-way)Stripe + facture LLM séparée
Réponses API signéesX-Hoody-Signature (ED25519)TLS seul (contenu non signé)
Client typé depuis la specGET /cron/openapi.jsonÉcris votre propre SDK

Quand vous avez besoin du modèle plan/apply de Terraform, du scheduling de kubectl ou des services managés AWS, utilisez-les. Le Control Plane prend tout son sens quand le conteneur est la primitive et que vous voulez tout le cycle de vie — pause et snapshot inclus — dans une seule API.

Démarrer

votre premier conteneur tient en un POST.

Récupérez un token API, choisissez une image, et votre conteneur a chaque URL des services Kit avant que le HTTP 201 ne tombe.

Référence API

Voir aussi — /platform/proxy pour comprendre comment ces URLs routent et s'authentifient.