---
title: Entry points
description: 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.
sidebar:
  label: Entry points
seo:
  title: DomainKit entry points
---

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

```package-install
domainkit effect@^4
```

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

```package-install
@domainkit/react react react-dom
```

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

```package-install
@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`, the Promise adapters, and `CallbackRecovery`      |
| `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:

```ts
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`, `/CallbackRecovery`, `/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

```text
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.