Installation

1. Install Bun

curl -fsSL https://bun.sh/install | bash

On Windows without WSL: npm install -g bun.

Prompt for AI agents:

Check for Bun with bun --version. If it's missing, run
curl -fsSL https://bun.sh/install | bash (Windows without WSL:
npm install -g bun), then confirm the version again before continuing.

2. Get the codebase and install

Download the complete Nuxfire monorepo directly after purchase, join our VIP Group for updates, extract it to your preferred workspace directory, and install dependencies:

cd nuxfire
bun install

The first bun install takes a few minutes — it hasn't hung. Always run it inside the extracted folder and never copy a node_modules folder from another machine or project: the workspace links (@nuxfire/*) can break, and the deploy preflight (Deploy) reports it if they do.

(Optional: Initialize your own private Git repository for version control):

git init
git add .
git commit -m "Initial commit from Nuxfire"

The three commands above are enough to start. For the recommended stage / production branch model, keeping your .env* files out of Git and a safe first release, follow Git for Your First Release.

Migrations are already versioned in apps/functions/src/database/migrations/. You only need to generate new ones if you change apps/functions/src/database/core-schema.ts or any layer's server/database/schema.ts (drizzle.config.ts reads both, not the schema.ts barrel — that file only re-exports them):

cd apps/functions
DATABASE_HOST=... DATABASE_PORT=5432 DATABASE_USER=... DATABASE_PASSWORD=... DATABASE_NAME=... \
  bunx drizzle-kit generate

(No DATABASE_URL — drizzle.config.ts reads host/port/user/password/name separately, so you never have to build or escape a URL containing a password.)

Prompt for AI agents:

In the extracted nuxfire project root, run: bun install
Only run bunx drizzle-kit generate (from apps/functions) if
core-schema.ts or a layer's server/database/schema.ts changed — ask
the user for their real DATABASE_HOST/PORT/
USER/PASSWORD/NAME first, never invent placeholder values.

3. Name your installation

Open sst.config.ts and change name: "nuxfire" to a short, unique slug for your product (lowercase, no spaces — it becomes part of every Cloudflare resource name). Do this now, before your first bun run deploy to any stage: every Cloudflare Worker, Durable Object namespace, queue and KV/R2 binding is named <name>-<stage>-..., so changing it after your first deploy recreates every resource under the new name and abandons the old ones. bun run doctor warns if this is still "nuxfire" when you deploy.

export default $config({
  app(input) {
    return {
      name: "your-product-slug", // was "nuxfire"
      // ...

Prompt for AI agents:

Open sst.config.ts. If `name` is still "nuxfire", ask the user for their
own product slug (lowercase, no spaces, short — it's used as a prefix on
every Cloudflare resource name) and set it there. Do this before running
bun run deploy for the first time; never change it after a first deploy
without the user's explicit confirmation, since it recreates every
Cloudflare resource under the new name.

Next

Cloudflare Access — create the API token the rest of setup needs.