Configuration

Typebase uses a typebase.json file in your project root to store configuration. init creates it with a $schema reference, so every option starts on its default. Other CLI commands update it as you go, and you can edit it manually.

Example

{
  "$schema": "https://raw.githubusercontent.com/typebase-io/monorepo/refs/heads/main/apps/cli/src/helpers/typebase.schema.json",
  "projectPath": "src/lib/typebase/server/",
  "serverProvider": "vercel",
  "server": {
    "output": "ts",
    "adapter": "node",
    "outDir": "_server"
  }
}

Reference

projectPath

The path to your typebase/ directory, relative to the project root.

{
  "projectPath": "src/lib/typebase/server/"
}

This tells the CLI where to find your db/, actions/, auth.ts, env.ts, publisher.ts, storage.ts, and _generated/ files.

serverProvider

The deployment provider to use with npx typebase-io-cli deploy.

{
  "serverProvider": "vercel"
}

If not set, the CLI will ask you to choose a provider on the first deploy and save it here.

server

Configuration for npx typebase-io-cli generate-server. These are the defaults used when you don't pass CLI flags.

{
  "server": {
    "output": "ts",
    "adapter": "node",
    "outDir": "_server",
    "port": 8080
  }
}

server.output

The output format for generated server files.

• "ts": TypeScript source files (you compile them yourself)
• "esm": JavaScript with import/export syntax
• "cjs": JavaScript with require/module.exports syntax

server.adapter

The HTTP adapter for the generated server.

server.embedded

Generate an embedded server for your existing application to mount.

{
  "server": {
    "embedded": true
  }
}

Equivalent to generate-server --embedded. Set it to false or remove it to generate a standalone server. Embedded output defaults to _handler; your application provides dependencies, environment loading, and CORS. See embedded servers.

start always builds a standalone server, regardless of this setting. For how this interacts with server.port, see server.port.

server.outDir

The output directory for generated server files, relative to your typebase/ directory.

server.actionsPath

The path an embedded server serves your actions at.

{
  "server": {
    "embedded": true,
    "actionsPath": "/typebase/rpc"
  }
}

Equivalent to generate-server --actions-path, and embedded-only — see serving paths for how a standalone build treats it. Moving it changes the URL your client points at — see the server URL.

server.authPath

The path an embedded server serves auth at.

{
  "server": {
    "embedded": true,
    "authPath": "/typebase/auth"
  }
}

Equivalent to generate-server --auth-path, embedded-only on the same terms as server.actionsPath, and independent of it. The value is also written into the generated auth config as better-auth's basePath, so the framework and the route it is mounted at cannot disagree — unless your own typebase/auth.ts sets one, which wins. See the auth path.

server.storagePath

The path an embedded server serves local storage files at.

{
  "server": {
    "embedded": true,
    "storagePath": "/typebase/files"
  }
}

Equivalent to generate-server --storage-path, and embedded-only on the same terms as server.actionsPath. It only matters for a server generated with --local-storage, since no other server serves files itself. See storage in a generated server.

server.port

The port the generated server listens on.

Embedded generation never listens, so it ignores this key. Passing generate-server --port explicitly with server.embedded enabled is an error.

vercel

Vercel deployment configuration. Managed automatically by the CLI after your first deploy to Vercel.

{
  "vercel": {
    "projectId": "prj_abc123",
    "projectName": "my-typebase-server",
    "orgId": "team_xyz789"
  }
}

cloudflare

Cloudflare Workers deployment configuration. Managed automatically by the CLI.

{
  "cloudflare": {
    "accountId": "abc123",
    "workerName": "my-typebase-server",
    "subdomain": "my-subdomain"
  }
}

deno

Deno Deploy configuration. Managed automatically by the CLI.

{
  "deno": {
    "org": "my-org",
    "projectId": "abc123",
    "slug": "my-typebase-server"
  }
}

neon

Neon database configuration. Managed automatically by the CLI when you use a database.

{
  "neon": {
    "orgId": "org-abc123",
    "projectId": "proj-xyz789"
  }
}

storage

Storage configuration. Managed automatically by bucket sync, the first time you run storage sync or deploy a project with a storage.ts.

{
  "storage": {
    "project": "my-app",
    "cloudflare": {
      "accountId": "abc123"
    }
  }
}

project is chosen on the first sync and never derived again, so renaming your server project or moving to another server provider keeps your buckets. See bucket names on the provider. Only the account entry for the provider in storage.ts is read, and it is separate from the vercel and cloudflare server sections above, so your files and your server can live on different accounts, or different platforms.

telemetry

Anonymous usage data the CLI collects about the commands you run. See telemetry for exactly what is sent.

{
  "telemetry": {
    "enabled": false
  }
}

The first command you run in a project writes both fields, with enabled set to true, so the opt-out is in the file where you can find it.

Full schema

Here is the complete typebase.json schema with all optional fields:

{
  "projectPath": "typebase",
  "serverProvider": "vercel",
  "server": {
    "output": "ts",
    "adapter": "node",
    "outDir": "_server",
    "actionsPath": "/rpc",
    "authPath": "/api/auth",
    "storagePath": "/storage"
  },
  "vercel": {
    "projectId": "",
    "projectName": "",
    "orgId": ""
  },
  "cloudflare": {
    "accountId": "",
    "workerName": "",
    "subdomain": ""
  },
  "deno": {
    "org": "",
    "projectId": "",
    "slug": ""
  },
  "neon": {
    "orgId": "",
    "projectId": ""
  },
  "storage": {
    "project": "",
    "vercel": {
      "orgId": ""
    },
    "cloudflare": {
      "accountId": ""
    }
  },
  "telemetry": {
    "enabled": true,
    "noticeShown": false
  }
}

All fields are optional. The CLI will use sensible defaults and prompt you interactively when needed. Alongside them, the $schema key written by init points at this schema so your editor can autocomplete and validate the file; the CLI keeps it in place whenever it updates the config.