Deployment

Platform targets

Tell Nift where a new static site is headed and let init create the smallest provider-ready project shape. The CLI stays consistent even though the platforms use different deployment models.

nift init --target=vercel
nift init --target=netlify
nift init --target=amplify
nift init --target=azure
nift init --target=firebase
nift init --target=render
nift init --target=cloudflare
nift init --target=github-pages
nift init --target=supabase

Targets prepare; they do not provision.

Nift creates output/configuration appropriate to the selected platform where anything extra is actually required. It does not sign in, create provider projects, configure DNS, provision databases or choose how the remote build environment installs Nift.

No target does not mean no support.

The named targets are convenience presets, not a list of the only platforms that can host Nift. Because a normal Nift build produces ordinary files in public/, you can use other static hosts and deployment systems too. Start with nift init (or nift init --ext=.ext), then configure that platform's build command, publish/output directory, workflow or provider files manually.

The extension contract

A target defaults to .html and currently accepts .html or .htm. These presets deliberately describe static websites. A misleading combination such as nift init --target=vercel --ext=.php fails instead of emitting PHP that the static target would not execute.

Without a target, Nift remains format-flexible:

nift init                 # HTML starter
nift init --ext=.php      # HTML-family PHP starter
nift init --ext=.txt      # format-neutral project

The initializer contract is cross-platform tested.

The 4.0.2 target/scaffold contract is green in native Linux, macOS and Windows GitHub Actions and in Nift's independent black-box regression suite. Those tests verify the generated project shapes, builds and diagnostics. They do not claim every provider has been deployed end-to-end; real deployments are ongoing dogfooding rather than a release gate.

What each target changes

Target	Nift output	Initial provider files	Natural dynamic/runtime path
Vercel	`.vercel/output/static/`	`.vercel/output/config.json`	Vercel Functions and platform routing/config
AWS Amplify	`.amplify-hosting/static/`	`deploy-manifest.json`	Amplify compute and routing primitives
Netlify	`public/`	`netlify.toml`	Functions and Edge Functions
Azure Static Web Apps	`public/`	tracked `staticwebapp.config.json`	Azure Functions APIs, auth and roles
Firebase Hosting	`public/`	`firebase.json`	Cloud Functions / Cloud Run rewrites
Render	`public/`	`render.yaml`	Separate Render web services/databases
Cloudflare Pages	`public/`	`wrangler.toml`	Pages Functions / Workers + bindings
GitHub Pages	`public/`	none required	Static only; use an external API/runtime
Supabase	`public/`	none required	Postgres, Auth, Storage, Realtime and Edge Functions; host the frontend separately

Build environments are separate

Some providers can consume output you build locally; others commonly run nift build in their own CI environment. A generated target does not secretly download Nift from one package manager or release URL. Make the Nift executable available in the provider's build environment using the installation route you want to trust, then run the generated build configuration.

Static site, dynamic pieces

Using a target does not turn Nift into a server framework. That is intentional. Keep the build-time site in Nift and use the platform's own runtime primitives where dynamic behaviour is genuinely needed:

Nift templates/content ── build time ──► static deployment
                                      │
                                      └─► provider functions / APIs / storage

The individual platform guides show where that boundary sits.

Start withVercel →