Skip to main content

LittleHorse Server


The LittleHorse Server is a high-performance and developer-first platform for building Durable Workflows in code, available free for production use under the Server-Side Public License.

Understanding the LittleHorse Server

Learn the core concepts of the LittleHorse Server.

Developer Guide

In-depth documentation for developers building on the LittleHorse Server.

Recipes

Step-by-step guides to help you get started with the LittleHorse Server.

Source Code

Check out the source code for the LittleHorse Server.

Open Source (SSPL)

The LittleHorse Server has use-cases in:

  • Microservice Orchestration: The LittleHorse Server allows teams to enjoy the benefits of microservices (such as independent deployment and elasticity) while mitigating some of the challenges such as observability, error handling, and schema evolution.
  • Business Process Management: LittleHorse is perfect for orchestrating long-running business workflows. The WfSpec pattern makes it much easier for your code to exactly reflect business requirements; reducing friction between Product and Eng teams.
  • Generative AI Workflows: LLM's are fantastic, but they are prone to hallucination and sometimes don't have all the answers. When that happens, LittleHorse User Tasks allow you to seamlessly put a human-in-the-loop to correct the situation.
  • Legacy App Modernization: LittleHorse workflows can easily span across both modern microservices and legacy monoliths, allowing you to easily connect both worlds into one business process.
  • SAGA Transactions: LittleHorse's advanced Exception Handling capabilities simplify the process of rolling back transactions across multiple systems in case of a problem (for example, canceling a shipment if payment fails).
  • And more.

Building applications on LittleHorse enables engineering teams to save on infrastructure costs, reduce time to market, and deliver more robust software with less downtime.

The code for the LittleHorse Server and all clients is available at our github, but if you want to get started we recommend you check out our Quickstart. All code is free for production use under the Server-Side Public License.

How it Works​

An application built on LittleHorse has the following three components:

The WfSpec, short for Workflow Specification, is a metadata object that tells the LittleHorse Server which Tasks to schedule and when they should be scheduled. The Task Workers connect to the LittleHorse Server and execute Tasks as they are scheduled.

You as the user of LittleHorse define your own WfSpecs, and write your own Task Workers which connect to the LittleHorse Server.

A depiction of where LittleHorse sits in the tech stack can be seen below:

Depiction of LittleHorse Stack

You can think of LittleHorse as Middleware software that sits in the same layer as your database. End-user software applications occupy the layer above LittleHorse and use LittleHorse to support a vertical business process.

Run an App​

To build an application with LittleHorse, there are three easy steps:

  1. Define your WfSpec
  2. Develop your Task Workers
  3. Run your WfRun!
tip

The easiest way to get your first workflow up and running is with our Quickstarts.

Architecture and Deployment​

LittleHorse is a distributed system that we engineered to handle the most demanding workloads. That means that we have:

  • Partitioning, to distribute work across multiple servers for horizontal scalability.
  • Replication, to ensure high availability and durability in case a server instance crashes.

Internals​

LittleHorse built its own data store RocksDB as the indexing layer and Kafka as a WAL (all through Kafka Streams). The request processing flow has two phases:

  1. The request is recorded to a Kafka topic.
  2. A Kafka Streams Processor on one of the LittleHorse Servers processes that request, at which point the response is returned to the client.

The detailed lifecycle of a write request can be found here:

Command Processing Diagram

  1. Client sends request (eg. Create Workflow Specification) to LittleHorse Server.
  2. LittleHorse Server records the request (along with a Request Guid) to the core command Kafka Topic (2a). LittleHorse Server contacts the designated Command Processor and asks to wait for the response for the Request Guid (2b).
  3. The Command Processor processes the Command after reading it from the Core Command Topic.
  4. The Command Processor updates the state (eg. create the WfRun Object) in the RocksDB State Store (4a). The Command Processor notifies the original calling LittleHorse Server of the results of the processing (4b).
  5. The LittleHorse Server sends the results back to the client.

Because the data is stored in RocksDB on the same disk as where the processing happens, we can achieve extremely high throughput. The latency of a request is normally under 40ms, depending on your LittleHorse Server configuration and sizing.

Dependencies​

For performance reasons, LittleHorse does not rely upon an external database. Instead, we built our own data store using Kafka as a write-ahead-log and using RocksDB/Speedb as our indexing layer. Kafka is a distributed log that supports partitioning, replication, and transactions, making it ideal as the backbone for the LittleHorse data store.

As such, LittleHorse has a dependency on Kafka. We have optional integrations with Prometheus, Grafana, any TLS system (such as openssl or Cert Manager), and any OAuth Identity Provider (eg. Keycloak or Auth0).

The LittleHorse Server's dependencies are:

  • Apache Kafka
  • Optional: An Oauth Provider for client authentication
  • Optional: A TLS certificate manager
  • Optional: A Prometheus-compatible system for monitoring

Deployment Options​

The LittleHorse Server is available for deployment in three ways:

  1. Self-managed via LittleHorse OSS, free of charge in your own environment.
  2. Supported by LittleHorse for Kubernetes in your own environment, and managed on autopilot by our Kubernetes Operator.
  3. As a hosted SaaS service in LittleHorse Cloud.

As the LittleHorse Server is source-available under the SSPL 1.0 license, you can run LittleHorse free of charge in production on your own infrastructure. You can get the code from our GitHub Repo, and our repo has quickstart tutorials for running LittleHorse using our public docker image.

LittleHorse OSS is licensed under the Server Side Public License. Mongo has a fantastic SSPL FAQ. The TLDR of the license is that you can use LittleHorse OSS for free in production without restriction unless you are offering LittleHorse-as-a-Service to external organizations.

For information on how to run LittleHorse OSS in production, check out our Operations Documentation.

info

If you are building a software application delivered over the internet (SaaS), you may do so without restriction even if your SaaS app is powered by LittleHorse.

A SaaS application qualifies as "powered by LittleHorse" so long as the end product used by customers has a meaningfully differentiated API from the core LittleHorse Server Public GRPC API. For example, you can sell an e-commerce application that runs on LittleHorse OSS without restriction.

However, if a company explicitly exposes the entire LittleHorse Server Public GRPC API as a SaaS service, then Section 13 of the SSPL would apply.

Security​

The LittleHorse Server supports various security mechanisms:

  • TLS to encrypt incoming connections.
  • Federated identity for authentication (either mTLS or OAuth).
  • mTLS to secure inter-server communication.

LittleHorse for Kubernetes has integrations with the Gateway API, Cert Manager, and Keycloak. Additionally, since LittleHorse Platform runs entirely in your own network, your firewall rules can add an additional layer of security.

LittleHorse Cloud uses TLS and OAuth for client authentication, and SSO for access to the LittleHorse Dashboard.

Get Started​

Want to painlessly automate your workflows?

Ride well!