Server-Side API
NukeBase is a managed service that provides instant provisioning and deployment. Your project structure includes:
- server/database.js: The core database engine
- server/data/: Your database directory (a tree of
data.jsonfiles joined by$splitmarkers — see Storage & Backups) - server/files/: The file store — a plain directory tree mirroring the path arrays you address files with
- server/rules.js: Security rules configuration (and query index declarations)
- server/extensions/: Optional auth extensions — password login, easy passwordless email, magic link. Mounted from
app.js; see Authentication - server/app.js: Your application configuration file
- public/: Frontend files (index.html, css, js, etc.)
- public/sdkmod.js: The browser SDK — an engine file, refreshed by
nukebase update - public/sw.js: The service worker — push delivery and the page cache. Also an engine file; never move or edit it
- sys/deploy.js: A stub that forwards to the CLI. The CLI itself is the
nukebasenpm package (npx --yes nukebase) - sys/config.json: Deployment configuration: which account owns the project (
uid,account),excludeandbackup. It holds no sign-in - node_modules/: Dependencies (auto-generated)
- package.json: NPM package configuration
- package-lock.json: Dependency lock file
Setup and Initialization
Getting started takes one command. Open a terminal — or Claude Code — in an empty folder and run:
npx --yes nukebase start
# What it does, in order:
# 1. signs you in — a browser tab opens, click Confirm once
# (no account yet? it creates one on the free plan, no card)
# 2. creates the project and puts it online
# 3. downloads it into this folder and runs npm install
#
# Name and size up front if you like:
npx --yes nukebase start myapp 256mb # sizes: 128mb, 256mb, 512mb, 1gb
Instant Deployment: the project is provisioned, deployed and live before the command returns, at
https://<your-id>-<project>.<region>.nukebase.com — the command prints the exact address, the dashboard shows it too, and a custom domain can be added later with npx --yes nukebase domain.
No build steps, no server configuration. Using Claude Code? Paste the command, click Confirm in your browser, then tell Claude what to build — the folder it is sitting in is now the project.
Other ways to create a project. From the dashboard, create a project and it downloads as a ZIP (the Download ZIP button fetches it again later); extract it and run npm install inside. Or split the steps in the terminal: npx --yes nukebase login then npx --yes nukebase create myapp 256mb. To connect a folder you already have to an existing project, npx --yes nukebase link <name>.
Day-to-day: develop locally, push to deploy
Nothing is installed globally — npx --yes nukebase fetches the CLI as needed. The --yes matters when an AI agent runs the command for you: without it npx stops to ask "Ok to proceed?", and an agent with a terminal attached waits there forever. Inside the project folder:
node server/database.js # run the whole thing locally at http://127.0.0.1:3000
npx --yes nukebase push # upload your changes to the live server and restart it
npx --yes nukebase pull # download the live server's code to this folder
npx --yes nukebase logs --follow # stream the live server's output
npx --yes nukebase start # inside a project: restart it (also resumes a paused one)
# Tired of typing npx? Install once per computer and drop the prefix:
npm i -g nukebase
nukebase push
Any editor works. In VS Code: File → Add Folder to Workspace, pick the project folder, then Terminal → New Terminal and the commands above run from there.
NukeBase CLI Commands:
nukebase push- Upload your local changes to the live server- Before uploading,
nukebase pushrunsnode --checkon every server-side.jsfile it is about to send and refuses the push if one does not parse, naming the file and line — a syntax error would otherwise go live and only fail on the server's next start. Browser code underpublic/andnode_modulesare skipped.--no-checkpushes anyway. - Large pushes, pulls and
backuprun over 4 parallel connections: one connection is often capped well below a home line's speed, and several together fill it. Set"streams"(1–8) insys/config.json, or--streams <n>for one command; small transfers (under 32 MB and 200 files) always use one. Only changed files are sent, and an interrupted push or pull resumes: run it again and files that already arrived intact are skipped, while a file cut off mid-transfer is sent again. nukebase pull- Download the latest changes from the live server
Accounts: sign-ins are kept in ~/.nukebase/credentials.json on your computer, never in the project. sys/config.json only names the account that owns the project, and every command in that folder runs as that account, so several accounts can be signed in at once (nukebase login --email you@example.com adds one, nukebase accounts lists them, nukebase logout you@example.com signs one out, plain nukebase logout signs out all). A CLI sign-in can deploy and manage projects but not billing, and lasts until you sign it out here or under Signed-in devices on the dashboard. For CI, create a build token there and set NUKEBASE_TOKEN and NUKEBASE_UID. No browser on the machine? nukebase login --device shows a code to type on the website.
Nothing on the live site changes until you run nukebase push: develop locally, then push to deploy.
Push and pull delete files that are absent on the other side, so keep the running app's own state out of the sync with exclude in sys/config.json — the template ships ["sys", ".env", "server/data", "server/backup", "server/files"]. Review the printed add/remove lists before confirming.
Step 3: Start Developing
Your project structure is ready to use:
- /public: Edit your frontend files (HTML, CSS, JavaScript)
- /server/app.js: Configure backend logic, domains, and database triggers
- /server/rules.js: Define security rules for data access
- /server/data/: Your real-time database directory (auto-synced)
Deploying: Local edits go live when you run nukebase push. A push uploads the changed files and restarts your app, so changes to server/app.js and server/rules.js take effect, and files in /public are served from disk as soon as they arrive.
Basic Server Configuration Structure
Your server/app.js file uses a module export pattern that provides access to all NukeBase APIs:
module.exports = ({
// Data
get, set, update, increment, remove, query, data,
// Files
getFile, setFile, removeFile, listFiles, fileStat, fileUrlFor, FILES_DIR,
// Extension points
addDbTrigger, addFileTrigger, addCallable, addConnectionTrigger,
// Server
addDomain, startDB, checkAuth, withBody, hashToken, generateRequestId
}) => {
const path = require("path");
const nukebase = addDomain({
authPath: ["users"],
host: "127.0.0.1", // optional - defaults to "127.0.0.1"
port: 3000 // optional - defaults to 3000
});
nukebase.app.serveStatic("/*", path.join(__dirname, "../public"),
(res, req) => { return true; }
);
startDB(nukebase);
}
Available Exports
Your app.js module receives the following functions and objects:
| Export | Description |
|---|---|
get, set, update, increment, remove, query | Core data operations, all synchronous and running as root by default — see CRUD Operations |
getFile, setFile, removeFile, listFiles | File store operations. Unlike the data operations these are async — see File Storage |
fileStat | Synchronous stat of a file path: { name, ext, size, type, mtime, isDir }, or undefined |
fileUrlFor | Build the /_file/… URL a client would fetch for a given path array |
FILES_DIR | Absolute path of the file store root (defaults to server/files) |
addDomain | Create a domain with auth and server config |
startDB | Start the server (call once at the end) |
addDbTrigger | Register database triggers — see Database Triggers |
addFileTrigger | Register file-store triggers (reserve, release, write, remove) — see File Storage |
addCallable | Register callable functions — see Callable Functions |
addConnectionTrigger | Register connection triggers — see Connection Triggers |
generateRequestId | Generate a random hex string (crypto.randomBytes). Default 8 bytes (16 hex chars); pass a byte count for longer IDs |
data | Direct read-only reference to the in-memory database object — see CRUD Operations |
checkAuth | Authenticate a request and return the auth context. Called automatically by postWithBody; call manually in raw post handlers |
withBody | Body-parsing middleware wrapper. Wraps a (res, req) handler to parse the request body and populate req.body and req.admin. Used internally by postWithBody — useful if you need to attach body parsing to a custom HTTP method |
hashToken | SHA-256 hash a string and return the hex digest. Used internally for session token storage — useful in extensions or callables that need to store/verify tokens the same way the auth system does |
sendPush | Send a push notification to every device saved at a path, a $-wildcard path, or a list of paths — see Push Notifications |
disconnectUser | Close every open WebSocket signed in as a uid, now — for a ban or a forced sign-out. Returns how many were closed. Claim changes do not need it; see Custom Claims |
configurePush | Optional push settings at startup: hardcode your own VAPID keys (publicKey, privateKey) and a contact — see Push Notifications: Keys |