Corfu puts a shared log under your distributed data structures

A consistency platform where the log is the primitive

Corfu is a consistency platform designed around the abstraction of a shared log. The objects it exposes are in-memory, highly available data structures that provide linearizable read and write operations and strictly serializable transactions, and the project states that it is based on peer-reviewed research with the papers linked from its wiki.

That abstraction is the whole design. Rather than exposing a table or a key space with a replication protocol hidden underneath, Corfu exposes a distributed shared log and lets clients use it for coordination, communication and storage. The log is described as a highly available, dynamic and high performance scalable fabric that is resilient to failures and can be reconfigured at any time.

The audience is systems researchers and engineers working on data structures that need strong consistency guarantees across a cluster. The topics attached to the repository reflect that: consensus, distributed databases, distributed systems, datastore, streaming.

Two things follow from the design. Clients that use the log for coordination get to decide their own protocols, which is flexible and also means the platform hands you the hard part rather than solving it for you. And because the objects are in memory, the durability story lives in the log servers and in whatever storage the deployment uses, not in the objects themselves.

The project is written in Java, its default branch is master, and the last push was on 2026-10-22.

Layout, sequencer and log servers behind one binary

The infrastructure has three server roles and the documentation is precise about what each one does.

The layout server helps Corfu clients locate the rest of the infrastructure. The sequencer server orders updates to the log. The log server stores the updates to the log. A minimal deployment needs one of each type, while a real deployment for scalability and high availability runs many, and the documentation notes that an administrator does not have to install each role separately because they ship as a single monolithic binary.

That single binary is what makes the system approachable. The corfu_server executable is the entire infrastructure, and the first run in the quick start starts it in a mode that plays all three roles at once on one machine.

The client side is the Corfu runtime. Given the address of a layout server, it enables clients to access distributed high-level data structures as if they were local ones, and the project provides a mechanism to automatically distribute most Java objects as well. The runtime is currently only available in Java, with plans to provide it in several other languages in the future.

That last point is the constraint most likely to decide a trial. The system is language neutral in principle and Java only in practice today, so a team whose services are not on the JVM is looking at a future that the documentation describes as a plan rather than a release.

Building needs JDK 25 while the runtime targets Java 11

The build requirements are spelled out in the quick start, and they are worth reading closely because the document mixes several Java versions in different places.

To build Corfu you need the Java JDK 25 along with Apache Maven 3.3 or later. On a Debian or Ubuntu system the simple route is:

$ sudo apt-get install maven

On macOS the documentation suggests homebrew:

$ brew install maven 

and mentions MacPorts as a third option for installing Maven 3.

The version to check afterwards is the one the build actually needs. The quick start says to run mvn --version and confirm that Maven 3.3 or later is installed, and it points at a specific blog post for installing a newer Maven on Ubuntu, noting that the version number in that post should be substituted. The sample mvn --version output in the documentation is from an older machine, showing Apache Maven 3.3.9 and Java 1.8.0_91.

That is the inconsistency to be aware of. Elsewhere the documentation states that the infrastructure can run on any system with Java 11 support, and it warns that Java 1.7 or earlier is not enough. So the runtime floor is Java 11, the build toolchain is JDK 25, and the example output on the page is older than both. Anyone automating this build should pin the toolchain rather than trust the sample output.

There is a Maven wrapper in the repository, with mvnw and mvnw.cmd alongside the pom.xml, so the build can be driven without a system-wide Maven install.

One command starts a single node, one command checks it

The first run is deliberately small. The build is a single Maven invocation:

$ mvn clean install

The binaries it produces are located in the bin directory, and the quick start runs the monolithic server in in-memory, single-server mode:

$ ./CorfuDB/bin/corfu_server -ms 9000

That starts an in-memory single node Corfu infrastructure on port 9000, and clients are pointed at localhost:9000. The in-memory mode is provided for nodes that do not require persistence, and the documentation is clear that this is for testing.

Verification is done with the Corfu utilities, and the first thing to check is the layout, which describes the configuration of servers in the infrastructure:

$ ./CorfuDB/bin/corfu_layouts -c localhost:9000 query

The expected output is a JSON document naming the layout servers, the sequencers and the log segments, with a replication mode, a segment range and the stripes that map to log servers. On a single node run, the layout server, the sequencer and the log server are all the same address, and the replication mode shown is CHAIN_REPLICATION.

Two things are worth noticing about the design of this quick start. The system can be simulated on a single machine with a few commands, which the documentation mentions explicitly, and the storage requirements are deliberately loose: no particular storage device is imposed, and traditional hard disks, SSDs and even NVM are all acceptable as long as the operating system allows Java to work with them.

The runtime hides the log but not the language

The developer-facing promise is that a distributed data structure should feel like a local one. The runtime takes the address of a layout server, discovers the rest of the infrastructure from it, and gives the application an object it can call methods on, while the object actually lives across a cluster and is kept consistent by the log.

The consistency guarantees are the substantive part of that promise. Linearizable read and write operations mean an operation appears to take effect atomically at a point between the invocation and the response, and strictly serializable transactions mean the ordering of a set of operations is consistent with real time. For a data structure that has to behave correctly when the network misbehaves, those are the properties worth having.

The mechanics underneath are the shared log, and the client uses it for three purposes: coordination, communication and storage. Because the client drives the protocol, the platform is not prescribing how your data structure should be built. That is the appeal for research work, and it is also the cost, since the guarantees are only as good as the protocol the client implements on top.

The documentation itself directs developers to the Corfu wiki for a detailed overview of the software architecture and example usage, and links the white papers behind the design.

A custom licence and no tagged releases

Two administrative facts are worth confirming before you invest time in Corfu.

The first is the licence. The repository carries a LICENSE.txt, and the licence is recorded as a custom one that GitHub cannot classify, rather than one of the standard open source licences. That distinction is not academic. If you intend to use Corfu inside a product or to redistribute a modified version, the permission and the obligations have to come from that file, not from the fact that the source is public. This is not legal advice, it is a flag to read the file.

The second is the release history. The repository publishes no GitHub releases, so there is no tag to pin, no changelog to diff and no binary to download from a release page. The build path in the documentation is therefore the practical route in, which is why the quick start starts with building from source.

Against that, the development activity itself looks current. The last push was on 2026-10-22, and the repository contains the machinery of an actively worked-on Java project: a GitHub Actions workflow for pull requests, codecov configuration, checkstyle and checkstyle suppression files, a Lombok configuration, a Doxyfile for documentation generation, a label value configuration file, a debian directory for packaging, a TestingFramework.md, a Security.md, a.mvn directory for Maven configuration, and the Maven wrapper. There are also samples/ with its own pom.xml and proto directory, a corfudb-tools directory for command line tooling, and a cmdlets directory.

The pattern to plan for is therefore source builds from master rather than versioned artefacts.

A global log versus per-key consensus

There are two other reasonable ways to get strong consistency, and it helps to know how Corfu differs from each.

The first is the conventional replicated store, where a consensus group replicates a key space and each write is ordered by that group. The difference in approach is that the ordering there is internal to the store and the client does not see it, whereas in Corfu the log is exposed and the client coordinates against it. A per-key consensus group has to agree on writes to many keys at once for a transaction, while a shared log gives the client a single ordered stream to build that transaction on. The trade-off is that the Corfu approach pushes protocol design onto the application.

The second alternative is not a different system but a different deployment of the same one. The documentation says an administrator need not install each role separately because the roles ship as one monolithic binary, and it also says a real deployment will have many of each for scalability and high availability. So the same code can run as three single-node processes on one laptop for development, or as a fleet of layout, sequencer and log servers across machines, with the layout server acting as the directory that clients use to find the rest.

For a team evaluating this, the practical question is which side of that line you are on. A single node in-memory run is a genuine starting point and needs nothing but a JDK and Maven, while a production deployment is a distributed systems project with its own failure and reconfiguration story, and the documentation notes the fabric can be reconfigured at any time without spelling out what that procedure looks like.

Editorial conclusion

Corfu suits a research or platform team evaluating log-based consistency and willing to write against a Java-only client runtime, and it is the wrong choice for a team that needs a multi-language client or a standard licence today. Before adopting it, read LICENSE.txt rather than assuming an open source grant, confirm your build environment against the stated JDK 25 and Maven 3.3 requirements, and read the Corfu wiki architecture pages before designing around the log abstraction.

Frequently asked questions

Official sources

1. CorfuDB/CorfuDB on GitHub
2. Issues
3. README