Liftbridge is back under active development

[xe-nvdk]

Hey everyone,
Basekick Labs is taking over maintenance of Liftbridge. Big thanks to Tyler Treat for creating this project and trusting us to carry it forward.

What's staying the same:

• Apache 2.0 license
• Liftbridge name
• Core architecture and API

What's coming:

• Modernized codebase (Go 1.25+, updated dependencies)
• Security audit
• CI/CD fixes
• Documentation refresh
• Regular releases (quarterly, starting Q1 2026)

Who we are:

Basekick Labs builds data infrastructure for IoT. We also maintain Arc, a time-series database built on DuckDB and Parquet. Liftbridge fits naturally as the streaming layer in that stack.

Get involved:

We're reviewing open issues and PRs. If you're using Liftbridge or want to contribute, drop a comment here - we'd like to hear from you.

[rafaelbreno]

I'm interested in contributing for the CI/CD stuff, are there any open issues on that?

[xe-nvdk]

I'm interested in contributing for the CI/CD stuff, are there any open issues on that?

Hi @rafaelbreno, thank you! There is not an open issue, but I have this on place for Testing and Release. If you see something that can be improved, is more than welcome.

https://github.com/liftbridge-io/liftbridge/blob/master/.github/workflows/test.yml
https://github.com/liftbridge-io/liftbridge/blob/master/.github/workflows/release.yml

[ramasauskas]

Hi, I have recently stumbled upon this project.

I have been using NATS with great success for several problems, however, I found no luck with total order consumption (similar as kafka).

To that I have started a project cgnats which aims to solve that issue by basing itself on top of Jetstream and Durable Consumers.

Then I found liftbridge, which at first glance looked like the exact same solution, but I found it interesting that it is not based on Jetstream.

I was wondering what are your thoughts of my approach? Since Jetstream is already raft based, isn't it a strong foundation to build on top?

Thank you!

[xe-nvdk]

Hey! Welcome, and cool that you found us.

Your approach with cgnats sounds solid, JetStream is a great foundation and using durable consumers for total order makes sense. Nothing wrong with building on top of that.

The reason Liftbridge isn't based on JetStream is mostly historical, Tyler started this project in 2017, and JetStream didn't exist yet (it came out around 2020). By then Liftbridge already had its own replication model (Kafka-style ISR) which is different from JetStream's Raft-based approach.

Could you build something similar on JetStream today? Probably yeah. The tradeoffs are a bit different though, Liftbridge avoids double-writing to both a Raft log and a message log, which was one of the pain points Tyler saw in NATS Streaming before building this (This is 100% assumption).

Always interesting to see different takes on the same problem.

[tylertreat]

@xe-nvdk is correct. To add a bit more context, I originally created Liftbridge based on some of the learnings from working on NATS Streaming as well as my own experience working with Kafka. At the time (and perhaps still today), there was a need for something that provided Kafka-like semantics but without the operational complexity. I also felt Go was a better fit for the runtime than Java which contributes to Kafka's operational overhead. In fact, Liftbridge was originally named Jetstream (and then Jetbridge) and in a sense was a "spiritual predecessor" to Jetstream, though I did not directly work on Jetstream.

I'm no longer active in the space and don't follow Jetstream so don't know how it compares feature-wise, but it's likely the right starting point unless you're looking for something with Kafka-like semantics.