Skip to main content
waniwani init asks where the app deploys, because the answer decides the one config file the repo carries:
Pass --host vercel, --host container, --host alpic or --host none to answer ahead of time.

​
Vercel

Only Vercel leaves anything behind, and it is four lines:
vercel.json
framework: null selects the Other preset. That one key is the only thing a repo cannot say any other way: the preset is a project setting Vercel resolves before the build command runs, so a project whose dashboard says Next.js or Express fails on the preset and never reaches the build. Other is what runs the build script and adopts what the build produced.
Nothing else belongs in that file. waniwani build writes a Build Output tree inside .waniwani/ (the bundled function, the static assets, the routing config) and the build’s last step moves it to .vercel/output at the app root, the one path where Vercel adopts one. A buildCommand would restate the build script that already runs, and a routes table would duplicate routing the build writes. Both go stale against a kit that moved on; framework: null is a fact about the project, so it never changes.
A prebuilt deploy skips the preset question entirely, since it uploads the tree and asks Vercel to build nothing.
One thing the kit decides on the app’s behalf, in that tree’s own routing table:
Vercel reserves a root api/ directory. It compiles every file under one into a serverless function of its own, and an endpoint module is not a Vercel handler, since defineEndpoint({ ... }) is an object. The reservation cannot be waived, because the file list is read before the build command runs:
So the route goes in ahead of the tree’s filesystem handler, which is the phase those functions sit in. /api/* reaches the server the kit built, and the ones Vercel made are never routed to. They still cost build time, two dead functions per app.
An app carrying a vercel.json from an earlier setup has to lose everything in it but framework. A buildCommand that stages the tree by hand deletes what the build just placed. waniwani check names the keys that fight the build.

​
Docker

The build writes a Dockerfile and .dockerignore into .waniwani/, so the image is built from there:

​
Alpic

alpic.json also comes out of the build:

​
Secrets and environment variables

.env and .env.local sit next to waniwani.config.ts, and every command reads them before it runs anything. A variable already exported in the shell or set by CI wins over both files, and a hosted deploy sets its variables on the platform and reads no file at all.
.env
Loading them this early is what lets a module build its client at import time:
lib/waniwani.ts
The generated project runs from .waniwani/, one level below the file, and a module’s imports are evaluated before any line of the module that pulled it in, so neither dotenv/config nor a load inside generated code arrives in time. waniwani check reads the same files for the same reason. On a hosted deploy, environment variables live on the platform. A Vercel project that sets its variables for production alone gets previews with none, which for an app whose flow reads WANIWANI_API_KEY at import time means a function that fails to boot. Set them for every environment the project serves. Get an API key from the Waniwani dashboard. What the key turns on is described under Waniwani Platform.