Deployment

Build the files. Deploy them wherever they belong.

Nift does not need a deployment platform of its own. A conventional project builds deploy-ready files into public/; a named platform target may instead select the provider's native output layout. Your hosting provider, web server, container or backend takes over from there.

A simple production build

# optional: compile/bundle frontend assets first
npm run build:frontend

# generate the Nift-managed outputs
nift build-all

# deploy public/

Supported platform targets

For common static hosts, start with the same CLI shape and let Nift prepare the provider-specific plumbing:

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

The targets do not all work the same internally. Vercel and Amplify use native filesystem deployment bundles; Netlify, Firebase, Render and Cloudflare use provider configuration around Nift's normal static output; Azure needs its application configuration to reach the output root; GitHub Pages needs no provider file at all. The CLI deliberately hides that distinction.

These presets are shortcuts, not restrictions. If your host is not listed, Nift can still be used anywhere its ordinary generated files can be served or deployed: start with nift init, build to public/, and configure the host manually. See Platform targets for the exact generated files, build-environment requirements and provider-specific guides for the presets Nift knows how to initialise automatically.

GitLab Pages

GitLab Pages remains a straightforward generic deployment even though it does not currently have a named Nift target. Build Nift and publish the resulting public/ artifact.

pages:
  script:
    - nift build
  artifacts:
    paths:
      - public

Your real CI job may also install Nift, compile TypeScript, optimise images or run tests before the Nift build.

Supabase

Supabase is often most useful beside Nift rather than instead of a static host. Let Nift generate the frontend and use Supabase for the application services it is good at: Postgres, Auth, Data APIs, Realtime, Edge Functions and Storage.

Nift
  ↓
public/ frontend
  ↓
Cloudflare / Netlify / Vercel / nginx / etc.
  ↕
Supabase
  ├─ Postgres
  ├─ Auth
  ├─ Realtime
  ├─ Storage
  └─ Edge Functions

Browser code can use the normal Supabase client/API while Nift remains entirely a build-time concern.

import { createClient } from '@supabase/supabase-js';

const supabase = createClient(
  import.meta.env.VITE_SUPABASE_URL,
  import.meta.env.VITE_SUPABASE_ANON_KEY
);

const { data } = await supabase
  .from('projects')
  .select('*');

Supabase Storage public buckets can also serve public assets through its CDN-backed object URLs. For a whole static website, however, a normal web/static host is usually the clearer division of responsibility.

nginx / Apache / Caddy

For a traditional server, copy public/ to the directory your web server serves.

nift build-all
rsync -av --delete public/ user@example.com:/var/www/example/

Nift does not need to run on the production server if you build before deployment.

Go application

A Go backend can serve the generated directory directly or embed/copy it into the application image.

mux := http.NewServeMux()
mux.Handle("/", http.FileServer(http.Dir("public")))

http.ListenAndServe(":8080", mux)

Node / Express

import express from 'express';

const app = express();
app.use(express.static('public'));

app.listen(3000);

Python

Flask, FastAPI, Django or another Python application can serve/copy the generated frontend in whichever way is conventional for that stack. Nift does not require a Python integration layer.

Docker

A multi-stage image can build the site and copy only the final public files into a small web-server image.

# build stage
FROM your-nift-build-image AS build
WORKDIR /site
COPY . .
RUN nift build-all

# serving stage
FROM nginx:alpine
COPY --from=build /site/public /usr/share/nginx/html

Static frontend + separate API

A very common full-stack deployment is simply:

public/              → CDN/static host
api.example.com      → Go / Node / Python / serverless backend
database/auth/etc.   → your chosen services

Nift does not need to know how those runtime services are deployed. The frontend can call them with ordinary HTTP/WebSockets.

CI pipelines

Whatever platform you use, a production pipeline commonly becomes:

npm ci                  # if the project uses npm
npm run build:frontend  # TypeScript/Vite/Tailwind/etc.
nift build-all
npm test                # or your own checks
# deploy public/