IaGenify SDK 0.3.1: static sites and edge applications get clear runtimes.

A deploy button is useful only when the thing behind it can run what it accepts. With IaGenify SDK 0.3.1, the hosting API describes the runtime up front: publish a static build, or publish code for an edge runtime. That choice gives the developer a concrete contract before any files are sent.

Two kinds of project, two straightforward paths

For a static site, build with the framework you already use, then send the generated files to a host configured with `runtime: "static"`. The documented framework choices cover plain HTML, Vite, React single-page applications, Vue, Angular, Astro and Next.js static export. The hosting service serves the output; it does not need to start a long-running application process.

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

For a small request handler, choose `runtime: "edge"` and a supported edge framework such as Worker code or Hono. The deployment contains the handler itself, which responds at the edge rather than depending on a persistent Node.js server.

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

A useful boundary is part of the API

Static output and edge handlers are not interchangeable. An exported Next.js site can be deployed as static output; a Next.js application that needs server-side rendering needs a persistent server, which this hosting surface does not claim to provide. Express, Fastify, Nest and other persistent Node.js applications belong in a hosting model that can run a server continuously.

The SDK therefore checks the runtime and framework pairing before upload. If a project asks for a runtime that is not supported, it gets a clear refusal instead of an address that exists but cannot serve the application. This is a small interaction with a large effect: developers learn the platform boundary while the work is still local.

Build locally, deploy the artifact

This division keeps the workflow familiar. Your build tool produces `dist` or another output directory; the SDK publishes that artifact. For edge code, the SDK publishes the handler source. The platform does not imply that it will install arbitrary dependencies or keep a general-purpose process alive.

That distinction also makes automation easier to reason about. A workflow can build a site and deploy the resulting static files, while a separate edge endpoint can handle a lightweight request path. Each host states what it is, and the deploy call matches that type.

A deployment API should tell you what it can run before it accepts your project.

A smaller promise developers can rely on

SDK 0.3.1 makes IaGenify hosting more explicit rather than pretending every JavaScript application has the same runtime needs. Static websites and edge handlers now have a simple, typed path, while the limits of the service are visible at creation time.