# IaGenify SDK 0.3.1 : des runtimes clairs pour les sites statiques et l’edge.

Canonical URL: https://www.iagenify.com/fr/news/iagenify-sdk-static-edge-hosting

Déployez un site compilé ou un gestionnaire edge avec une API d’hébergement qui précise ce que la plateforme sait réellement exécuter.

## Key points
- Les nouveaux hébergements utilisent les runtimes explicites `static` ou `edge`.
- Les sites statiques et les gestionnaires edge suivent des parcours de déploiement adaptés à leur exécution.
- Les serveurs Node.js persistants non pris en charge sont refusés avant l’envoi des fichiers.

Un bouton de déploiement n’est utile que si la plateforme peut exécuter ce qu’elle accepte. Avec IaGenify SDK 0.3.1, le type d’exécution est déclaré dès la création : publier un site statique ou du code destiné à l’edge.

## Deux projets, deux parcours simples

Pour un site statique, compilez avec votre framework puis envoyez les fichiers générés à un hébergement `runtime: "static"`. Les frameworks documentés comprennent HTML, Vite, React en application monopage, Vue, Angular, Astro et l’export statique de Next.js. La plateforme sert les fichiers sans démarrer de processus Node.js permanent.


```
const site = await api.hosts.create({
  label: "Product website",
  runtime: "static",
  framework: "vite",
});
await site.deploy({ files: "./dist" });
```

Pour un gestionnaire de requêtes, choisissez `runtime: "edge"` avec Worker ou Hono. Le déploiement contient le code exécuté à l’edge, sans dépendre d’un serveur Node.js persistant.


```
const endpoint = await api.hosts.create({
  label: "Status endpoint",
  runtime: "edge",
  framework: "hono",
});
await endpoint.deploy({ code: source });
```

## Une limite utile fait partie de l’API

Un export statique Next.js et une application Next.js avec rendu côté serveur ne sont pas équivalents. La première peut être publiée comme fichiers ; la seconde a besoin d’un serveur permanent que ce service ne prétend pas fournir. Express, Fastify et Nest relèvent également d’un environnement persistant.

Le SDK vérifie l’association entre runtime et framework avant l’envoi. Une demande non prise en charge est refusée clairement, au lieu de produire une adresse qui ne pourrait pas servir l’application.

## Compiler localement, déployer l’artefact

L’équipe garde son processus de compilation habituel : Vite produit par exemple `dist`, puis le SDK publie ce résultat. Pour l’edge, il publie le gestionnaire. La plateforme ne prétend pas installer n’importe quelle dépendance ni maintenir un processus général actif.

Cette séparation rend aussi l’automatisation plus lisible : un workflow peut compiler puis publier le site, tandis qu’un endpoint edge séparé traite une requête légère.

> Une API de déploiement devrait indiquer ce qu’elle sait exécuter avant d’accepter un projet.

## Une promesse plus précise, sur laquelle les développeurs peuvent compter

SDK 0.3.1 rend l’hébergement IaGenify plus explicite : les sites statiques et les gestionnaires edge disposent chacun d’un parcours simple, et les limites apparaissent dès la création.

## FAQ
### Puis-je déployer un serveur Express ou Fastify ?
Non. Les runtimes documentés sont les fichiers statiques et les gestionnaires edge ; aucun serveur Node.js persistant n’est fourni.

### Puis-je publier un site Next.js ?
Oui, s’il est compilé en export statique. Le rendu côté serveur nécessite un runtime persistant.

### Le SDK compile-t-il mon projet ?
Le parcours documenté consiste à compiler localement puis à publier les fichiers générés, par exemple `./dist`.

### À quoi sert le champ runtime ?
Il indique si l’hébergement sert des fichiers statiques ou exécute un gestionnaire edge et permet de valider le framework associé.