Entry points

The public DomainKit imports, what each entry point carries, where each one runs, and the runtime and peer versions they need to be installed with.

DomainKit publishes one core package with four entry points, an optional PostgreSQL persistence package, and a React package. These names are the public contract; internal source paths are not.

Install

npm install domainkit effect@^4

pnpm add domainkit effect@^4

yarn add domainkit effect@^4

bun add domainkit effect@^4

nub add domainkit effect@^4

aube add domainkit effect@^4

Add the React package when the product needs ready-made flows or UI parts:

npm install @domainkit/react react react-dom

pnpm add @domainkit/react react react-dom

yarn add @domainkit/react react react-dom

bun add @domainkit/react react react-dom

nub add @domainkit/react react react-dom

aube add @domainkit/react react react-dom

Add the persistence package when the host runs Effect on PostgreSQL:

npm install @domainkit/capsuledb capsuledb @effect/sql-pg

pnpm add @domainkit/capsuledb capsuledb @effect/sql-pg

yarn add @domainkit/capsuledb capsuledb @effect/sql-pg

bun add @domainkit/capsuledb capsuledb @effect/sql-pg

nub add @domainkit/capsuledb capsuledb @effect/sql-pg

aube add @domainkit/capsuledb capsuledb @effect/sql-pg

Entry points

Import	Carries
`domainkit`	Lifecycle services, host seams, providers, values, and `DomainKit.Error`
`domainkit/server`	`Server.group`, its layers, `Server.Identity`, and the wire schemas
`domainkit/client`	`Transport.fromFetch` and the Promise adapters
`domainkit/testing`	Fakes, the recording transport, and the conformance runners
`@domainkit/react`	The React flow hook, the controllers, the message catalog, and `Testing`
`@domainkit/capsuledb`	`Storage` on PostgreSQL as one CapsuleDB capsule

domainkit/client runs in the browser and holds no credential. domainkit/server and @domainkit/capsuledb run on the server and never reach browser code.

One subpath per namespace

The root re-exports every namespace, and each one is also its own subpath:

import { Plan, Principal } from "domainkit";
// or
import * as Plan from "domainkit/Plan";
import * as Principal from "domainkit/Principal";

The root import is the documented default and what every example on this site uses. Reach for a subpath in two cases:

Your package emits declarations. A .d.ts that mentions Principal.Service or Plan.Model needs a module path TypeScript can name. import("domainkit/Principal").Service resolves to one module, so the declaration your build emits is portable.
You want a narrow import. One namespace, without pulling the root’s names into scope.

Runtime and types resolve to the same module either way, so the two spellings never disagree.

Subpath
`domainkit/Approval`, `/Cleanup`, `/Cloudflare`, `/Connect`, `/Custody`, `/DnsRecord`
`domainkit/DomainKit`, `/DomainName`, `/Plan`, `/Principal`, `/Provider`, `/Providers`
`domainkit/Provision`, `/Reason`, `/Receipt`, `/Resolver`, `/Storage`, `/Vercel`, `/Verify`

Nothing else is importable. There is no pattern export, and no path under internal or entry is part of the contract.

Where each one runs

browser                        server
-------                        ------
@domainkit/react               domainkit/server   -> domainkit
  -> domainkit/client  --HTTP-->                     -> @domainkit/capsuledb
                                                     -> provider APIs

Runtime requirements

domainkit needs Node.js 24.10 or newer and Effect 4 as a peer dependency.
@domainkit/react needs React 19 and React DOM 19 beside those.
@domainkit/capsuledb needs capsuledb and a host-owned SqlClient.

Install domainkit and @domainkit/react at the same release version. The React package decodes the core package’s schemas, so mixed versions can disagree about a shape.