To start a Crux node, use the Java API or the Clojure crux.api.

Within Clojure, we call start-node from within crux.api, passing it a set of options for the node. There are a number of different configuration options a Crux node can have, grouped into topologies.

Crux Topologies

Name Transaction Log Topology


Uses local event log



Uses Kafka



Uses JDBC event log


Use a Kafka node when horizontal scalability is required or when you want the guarantees that Kafka offers in terms of resiliency, availability and retention of data.

Multiple Crux nodes participate in a cluster with Kafka as the primary store and as the central means of coordination.

The JDBC node is useful when you don’t want the overhead of maintaining a Kafka cluster. Read more about the motivations of this setup here.

The Standalone node is a single Crux instance which has everything it needs locally. This is good for experimenting with Crux and for small to medium sized deployments, where running a single instance is permissible.

Crux nodes implement the ICruxAPI interface and are the starting point for making use of Crux. Nodes also implement and can therefore be lifecycle managed.


The following set of options are used by KV backend implementations, defined within crux.kv:

Table 1. crux.kv options
Property Description Default Value


Directory to store K/V files



Sync the KV store to disk after every write?


Standalone Node

Using a Crux standalone node is the best way to get started. Once you’ve started a standalone Crux instance as described below, you can then follow the getting started example.

Local Standalone Mode
Table 2. Standalone configuration
Property Description Default Value


Directory used to store the event-log i.e. "data/event-log-1"



Key/Value store to use for standalone event-log persistence



Sync the event-log backend KV store to disk after every write?


Project Dependency

  juxt/crux-core {:mvn/version "20.09-1.11.0-beta"}