Running

The CLI

Bun runs a bot's .ts files as they are. On Node, plain .js and .mjs work from Node 20; for .ts, use a Node that strips types on its own (22.18 or later), a loader such as tsx, or compile to JavaScript first.

Registering commands

Discord keeps its own copy of a bot's commands. nubis sync compares yours with it and only writes when something differs, so it's safe to run on every deploy:

nubis sync --global

Commands registered in a server appear there immediately; global ones can take a while to reach every client. That's why nubis dev uses your test server.

The gateway

By default, nubis start connects to Discord's gateway: a WebSocket the bot keeps open. It receives interactions and events, and shows a presence. It needs a process that stays up, which is what most bots run on.

DISCORD_TOKEN=... DISCORD_APPLICATION_ID=... nubis start

The HTTP transport

Discord can instead send interactions to a URL — the Interactions Endpoint URL in the Developer Portal. A bot on HTTP needs no open connection, so it can run on platforms that scale to zero. It receives no gateway events.

// nubis.config.ts
export default defineConfig({
	transport: "http",
	http: { port: 8080, path: "/interactions" },
});

nubis start then serves that path, verifying each request's signature with DISCORD_PUBLIC_KEY. Put the public URL in the Developer Portal; Discord checks it before saving.

In your own server

createInteractionHandler is the same endpoint as a function from a web standard Request to a Response, so it fits Bun, Deno, Workers and Node frameworks alike:

import { createInteractionHandler } from "nubis";
import { loadProject } from "nubis/node";

const project = await loadProject(process.cwd());
const handle = createInteractionHandler({
	publicKey: process.env.DISCORD_PUBLIC_KEY!,
	project,
});

Bun.serve({ port: 8080, fetch: handle });

On serverless platforms, pass waitUntil so follow-ups and edits finish after the response is sent. On Node's http module, toNodeListener(handle) from nubis/node adapts it.