Home/Docs/Build & configure

Frameworks

What Wrenship detects, what it publishes as a static site, and what renders on the server.

At a glance

Framework	Detected by	Runs on
Static HTML	`.html` files	Edge
Vite (React, Vue, Svelte)	`vite` in package.json	Edge, serves `dist`
Astro	`astro` in package.json	Edge, serves `dist`; server rendering with `output: 'server'`
SvelteKit (static adapter)	`@sveltejs/kit`	Edge, serves `build`
Create React App	`react-scripts`	Edge, serves `build`
Other Node builds	a `build` script	Edge, serves `dist`
Next.js	`next` in package.json	Edge, server rendering; static with `output: 'export'`
Nuxt	`nuxt` in package.json	Edge, server rendering; static with `nuxt generate`
Hono	`hono` in package.json	Edge, server rendering from `src/index.ts`

Static or server rendering

Wrenship picks one by looking at your code. Both run on Wrenship's edge, close to your visitors.

Static. Your build produces only HTML, CSS and JavaScript files. Build-time variables such as VITE_*, NEXT_PUBLIC_* or PUBLIC_* are fine: they are written into the files when the site builds. Anything a static site uses ends up in the browser, so a static site can't keep a value secret. If your .env.example lists secrets, the deploy screen warns you.
Server rendering. Your app runs code for each request: Next.js server rendering, API routes, Astro or Nuxt on the server, or Hono. Its static files are served from the edge as well.

With server rendering, your environment variables are available to your server code: secrets stay secret, the rest are plain values. A vars block in your config file is used too, and your project variables win over it.

Key-value storage: every KV binding in your config (for example Astro's SESSION) gets the project's own store. It's created on the first deploy and kept across deploys and rollbacks, so the data stays. Ids in your config are ignored. Queues and other bindings aren't available yet: the deploy tells you which one it found.

Database and files: a server-rendered app can have a SQLite or Postgres database and file storage.

Plans: server rendering is on paid plans (Starter: 1 project, Edge Pro: 10). Static sites are free. On the Free plan, a Next.js app can still deploy as a static site with output: 'export'.

Server rendering, framework by framework

You don't change your code: Wrenship adapts it while building, in its own copy.

Next.js: Wrenship picks the edge adapter version that supports your Next.js version. If none does, the build stops and tells you which Next.js versions work. Not yet supported: cacheComponents: true, which Next.js 16's create-next-app turns on. Those pages hang on the edge, so the build stops before deploying. Set cacheComponents: false (and remove partialPrefetching) to deploy.
Astro with output: 'server': Wrenship adds the edge adapter if you don't have it. Astro.session works (it uses the project's key-value store).
Nuxt: server routes in server/api work. A project whose build runs nuxt generate is deployed as a static site.
Hono is built from your entry file as it is.

When an app can't run on the edge as it is, the build page says why.

Static sites and front-end builds

Wrenship installs dependencies with the package manager your lockfile points to (pnpm, yarn or npm), runs your build script and publishes the output folder to the edge. Single-page apps (Vite, CRA, SvelteKit) fall back to index.html for unknown paths, so client-side routing works.

Wrenship publishes the folder in the table above. If your build writes somewhere else, point the build at that folder (for Vite, build.outDir).

When detection gets it wrong

The build log shows what ran. Set the install command, build command and output folder in Project settings, or adjust your build script to match.