TypeDB Enterprise

Run TypeDB Enterprise on your own infrastructure, a self-hosted deployment of TypeDB, fully under your control. TypeDB Enterprise servers can be clustered for high availability.

TypeDB Enterprise is distributed and installed separately from other editions of TypeDB and requires a license.

TypeDB is also available as a fully managed cloud service with no installation required at cloud.typedb.com.

License

To access TypeDB Enterprise, contact our sales team via e-mail or contact form.

System Requirements

TypeDB Enterprise runs on macOS, Linux, and Windows.

Download and Install

Install your TypeDB Enterprise distribution with Docker or via manual download and installation.

You can deploy a cluster of TypeDB Enterprise servers manually.

Docker

The TypeDB Enterprise image is hosted in our private Docker repository. Make sure to use docker login first to authenticate.

To pull the TypeDB Enterprise Docker image, run:

docker pull typedb/typedb-cluster:latest

Use docker create to create a new container with the downloaded image. The container’s entrypoint is typedb server, so server options are passed as arguments. A TypeDB Enterprise server listens on port 1729 for gRPC, 8000 for HTTP, and on its clustering address (port 1730) for replication between servers. Because the server binds the clustering address itself, run the container on the host network so that the address other servers use is one it can bind. To ensure that data is preserved even when the container is killed or recreated, mount Docker volumes for both the data directory and the clustering directory:

docker create --name typedb --network host \
    -v $(pwd)/db/data:/opt/typedb-cluster-all-linux-x86_64/server/data \
    -v $(pwd)/db/clustering:/opt/typedb-cluster-all-linux-x86_64/server/clustering \
    typedb/typedb-cluster:latest \
    --diagnostics.deployment-id=my-cluster \
    --server.clustering.id=1 \
    --server.clustering.address=<host-ip>:1730 \
    --server.advertise-address=<host-ip>:1729 \
    --server.http.advertise-address=http://<host-ip>:8000 \
    --server.admin.enabled=true

Replace <host-ip> with the host’s address at which clients and other servers reach this server, and give every server its own --server.clustering.id. The image is published for x86_64 and arm64; on arm64 hosts, the paths inside the container start with /opt/typedb-cluster-all-linux-arm64.

The first server of a new cluster (replica id 1) must start once with --initialize.create-cluster=true. The arguments given to docker create are passed again on every docker start, so do not add the flag to the container. Instead, run the first start in a temporary container that uses the same volumes:

docker run --rm --network host --volumes-from typedb \
    typedb/typedb-cluster:latest \
    --diagnostics.deployment-id=my-cluster \
    --server.clustering.id=1 \
    --server.clustering.address=<host-ip>:1730 \
    --server.advertise-address=<host-ip>:1729 \
    --server.http.advertise-address=http://<host-ip>:8000 \
    --initialize.create-cluster=true

Once it prints Ready to process requests, stop it with kbd:[Ctrl+C] and start the typedb container as shown below. The other servers need no such step: they wait to be registered, which you do with the admin tool inside the primary’s container, for example:

docker exec typedb ./typedb admin --socket-path ./server/data/admin.sock \
    --command "servers register 2 <server-2-ip>:1730"

See Deploying manually for the full procedure.

The port numbers are configurable. For example, you could configure TypeDB Enterprise to listen on port 80 instead of the default port 1729.

Start and Stop TypeDB Enterprise in Docker

To start the Docker container, or restart a stopped container:

docker start typedb

To check the containers running:

docker ps

To stop the Docker container:

docker stop typedb

Manual installation

Download the latest TypeDB Enterprise release from the private release repository (you need access to it), unzip it in a location on your machine that is easily accessible via terminal.

If TypeDB doesn’t have a distribution you need, please open an issue on GitHub.

Start and Stop TypeDB Enterprise manually

To start TypeDB Enterprise manually:

  1. Navigate into the directory with the unpacked files of TypeDB Enterprise.

  2. Run:

    ./typedb server

Now TypeDB Enterprise should show a welcome screen with its version and connection addresses.

To stop TypeDB Enterprise:

Close the terminal or press kbd:[Ctrl+C].

Connecting

To check whether TypeDB Enterprise is working and interact with it, connect with TypeDB Studio or TypeDB Console. Note that TypeDB Console is also available from your TypeDB Enterprise directory:

./typedb console --address 127.0.0.1:1729 --username admin --tls-disabled

To run TypeDB Console from a Docker container, run:

docker exec -ti typedb bash -c '/opt/typedb-cluster-all-linux-x86_64/typedb console --address 127.0.0.1:1729 --username admin --tls-disabled'

Console prompts for the password; the default password of the admin user is password, change it on first use. Drop --tls-disabled once you have enabled TLS on the server.

Deploying manually

Multi-server setup

TypeDB Enterprise can run as a single server, but a highly available, fault-tolerant production setup is a cluster of several servers that replicate the data between them. At any point in time, one server is the primary and the others are secondaries; see Clustered TypeDB for how a cluster works. To tolerate N servers failing, a cluster needs 2N + 1 servers. This section sets up a 3-server cluster, which tolerates the failure of one server.

Each server in a cluster binds to three network ports: a gRPC port for TypeDB drivers and Console (1729 by default), an HTTP port for the HTTP API and Studio (8000), and a clustering port for server-to-server replication (1730). It also serves its monitoring endpoint on port 4104.

For this tutorial, all three servers are on the same private network with these ports open, and have the IP addresses 10.0.0.1, 10.0.0.2, and 10.0.0.3.

To try a cluster on a single machine, use 127.0.0.1 for every address and prefix each port with the server number:

  • 11729, 18000, 11730, 14104 for server 1;

  • 21729, 28000, 21730, 24104 for server 2;

  • 31729, 38000, 31730, 34104 for server 3.

Set these ports in each server’s listen addresses (--server.listen-address, --server.http.listen-address), advertise addresses, clustering address, and --diagnostics.monitoring.port. Run each server from its own copy of the distribution, or also give each one its own --storage.data-directory, --storage.clustering-directory, --logging.directory, and --server.admin.socket-path.

Starting the servers

Every server needs a unique replica id (server.clustering.id), its clustering address (server.clustering.address, which it also listens on for replication), the cluster’s deployment id (diagnostics.deployment-id), and the addresses that clients should use to reach it (server.advertise-address and server.http.advertise-address). The shipped server/config.yml holds localhost placeholders for these; set them in the file or pass them as command-line arguments, which take priority over the config file. See Cluster configuration.

Example 1. Server #1

On the machine with the IP address 10.0.0.1, start the first server with --initialize.create-cluster=true. This flag lets replica 1 create a new cluster on its first start. Leave it out of every later start, including startup scripts and service definitions: a server started with it on empty storage (for example, after its disk was replaced) creates a new, separate cluster instead of waiting to be registered into the existing one.

./typedb server \
    --diagnostics.deployment-id=my-cluster \
    --server.clustering.id=1 \
    --server.clustering.address=10.0.0.1:1730 \
    --server.advertise-address=10.0.0.1:1729 \
    --server.http.advertise-address=http://10.0.0.1:8000 \
    --server.admin.enabled=true \
    --initialize.create-cluster=true

The server prints Ready to process requests and already serves clients as a cluster of one.

Example 2. Servers #2 and #3

On 10.0.0.2, start the second server without the --initialize.create-cluster flag:

./typedb server \
    --diagnostics.deployment-id=my-cluster \
    --server.clustering.id=2 \
    --server.clustering.address=10.0.0.2:1730 \
    --server.advertise-address=10.0.0.2:1729 \
    --server.http.advertise-address=http://10.0.0.2:8000 \
    --server.admin.enabled=true

Start the third server on 10.0.0.3 the same way with --server.clustering.id=3 and its own addresses. Both servers wait to be registered.

Registering the servers

On the machine of server #1 (the primary), register the two new servers with the admin tool, giving each one’s replica id and clustering address:

./typedb admin --socket-path ./server/data/admin.sock \
    --command "servers register 2 10.0.0.2:1730" \
    --command "servers register 3 10.0.0.3:1730"

Each new server receives the data from the primary and becomes a voting secondary once it has caught up. Once they have caught up, check the result:

./typedb admin --socket-path ./server/data/admin.sock --command "servers status"
id | address       | role      | term | status
-------------------------------------------------
1  | 10.0.0.1:1729 | primary   | 1    | available
2  | 10.0.0.2:1729 | secondary | 1    | available
3  | 10.0.0.3:1729 | secondary | 1    | available

The cluster is ready. Connect with TypeDB Console or a TypeDB driver to any of the three addresses; requests are routed to the primary automatically. See Administering a cluster for adding and removing servers later, failover, and migrating an existing TypeDB CE server into a cluster.

Example 3. Clients on a different network

Clients connect to every server at its advertise address, not only at the address they were given. When clients reach the servers through addresses other than the ones the servers use among themselves (for example, public hostnames in front of a private network), set the advertise addresses to the client-facing ones and keep the clustering addresses private. For example, the first start of server #1 becomes:

./typedb server \
    --diagnostics.deployment-id=my-cluster \
    --server.clustering.id=1 \
    --server.clustering.address=10.0.0.1:1730 \
    --server.advertise-address=typedb-1.example.com:1729 \
    --server.http.advertise-address=http://typedb-1.example.com:8000 \
    --server.admin.enabled=true \
    --initialize.create-cluster=true

In this case, ports 1729 and 8000 need to be reachable by clients at the advertised hostnames, while port 1730 only needs to be open between the servers. If no single address per server works for all clients, keep the advertise addresses private and let clients use address translation instead; see How clients reach the replicas. With TLS enabled, the HTTP advertise address uses https://.

Stopping servers

Stopping a clustered server is done the same way as a single server: close the terminal or press kbd:[Ctrl+C]. Each server is shut down independently. As long as a majority of the servers is running, the cluster keeps serving.

Migrating from TypeDB Community Edition

An existing TypeDB CE data directory can be migrated in place to become the first server of a TypeDB Enterprise cluster. See Migrating a TypeDB CE server into a cluster.

For LLMs & AI agents: this page as Markdown · llms.txt · llms-full.txt (TypeQL summary)