RuleGo: A Lightweight Go Rule Engine for Hot-Loaded Business Logic

What RuleGo Is and the Problem It Targets

Many Go applications embed business rules directly in code. When those rules change, the application must be recompiled and redeployed. This coupling becomes expensive in domains like IoT, ETL, and automation, where the rules evolve constantly and the underlying platform is stable.

RuleGo addresses this by separating the rule definition from the application binary. Rules are stored as JSON files describing a directed graph of components. The RuleGo engine loads these files at runtime and executes the graph. When the rules change, you update the JSON and reload it without restarting the process. The README calls this "hot deployment" and describes it as one of the key capabilities distinguishing RuleGo from embedding logic in compiled code.

The README lists these use cases where RuleGo applies well: edge computing that needs dynamic rule updates without redeployment, IoT device data routing and alarming, data distribution across HTTP, MQTT, and gRPC, application integration as a connector between systems and protocols, highly customized business logic that changes frequently, and complex orchestration of microservices or large model agents. It also describes LangFlow-like systems (feeding user intent into LLM calls, then triggering rule chains to act on the response) as a target scenario.

Rule Chains: How JSON Becomes Executable Logic

A rule chain is a JSON document that describes a directed graph. Each node in the graph represents a component: a JavaScript filter, a message type switch, an HTTP push, an MQTT publish, a transformer, a log writer, or any custom component you register. Edges in the graph carry message flow and can be conditional.

The README lists several built-in component types: Message Type Switch (routes by message type), JavaScript Switch (dynamic branching via JS expression), JavaScript Filter (drops or passes messages based on JS logic), JavaScript Transformer (modifies message payload with JS), HTTP Push, MQTT Push, Send Email, and Log Recording.

Connecting external systems uses Endpoints. The README names HTTP Endpoint, MQTT Endpoint, TCP/UDP Endpoint, Kafka Endpoint, and Schedule Endpoint as available options.

Rule chains support nesting: a chain can call a sub-chain by reference, enabling composition and reuse of common logic. The README also documents an AOP mechanism that lets you add behavior around rule chain and node execution without modifying the originals.

The README notes a context isolation mechanism that prevents data from leaking between concurrent message executions. In high-throughput scenarios where many messages flow through the engine simultaneously, each execution gets its own context scope. This isolation is handled by the engine rather than requiring the component author to manage it.

Installing RuleGo and Running a First Rule Chain

Install RuleGo with the standard Go module command:

go get github.com/rulego/rulego

A mirror on Gitee is also listed:

go get gitee.com/rulego/rulego

The README describes the workflow in three steps. First, define a rule chain in JSON. An example file lives at `testdata/rule/chain_call_rest_api.json` in the repository. Second, import the package and load the rule chain file to create an engine instance:

import "github.com/rulego/rulego"
ruleFile := fs.LoadFile("chain_call_rest_api.json")

Third, send messages into the engine. The engine processes each message through the chain and dispatches results to the configured downstream components.

The `examples/` directory contains runnable demonstrations organized by feature: `http_endpoint`, `mqtt_client`, `mqtt_endpoint_example`, `js_transform`, `msg_type_switch`, `db_client`, `ssh_node`, and others. Each example is a self-contained Go program showing how to configure that component type.

Dual Mode: Embedded Library or Standalone Middleware

RuleGo has two deployment modes documented in the README. In embedded mode, the engine is imported as a Go library and runs inside an existing application. The application retains full control over how messages are fed in and how results are consumed. This is the primary mode and requires no external infrastructure.

In standalone mode, RuleGo runs as middleware, providing rule engine and orchestration services over a network interface. The `server/` directory in the repository contains the standalone deployment. The README mentions a running demo at a public URL for viewing rule chain execution diagrams.

The embedded mode is the more common choice for Go teams adding dynamic rule evaluation to an existing service. The standalone mode serves as a dedicated orchestration service that other applications call over HTTP or another endpoint.

Both modes share the same rule chain DSL and the same component library. A rule chain developed and tested in embedded mode can be deployed to the standalone server without modification.

RuleGo vs Drools: Different Philosophies for Rule Execution

Apache Drools is a Java-based rule engine that uses the RETE algorithm for pattern matching across large sets of rules and facts. It has its own rule definition language (DRL), a sophisticated IDE plugin for rule editing, and a decision table format. Drools is designed for scenarios with hundreds or thousands of rules and complex forward-chaining inference.

RuleGo uses a simpler directed-graph model where components are connected by explicit edges. There is no RETE algorithm and no inference: messages flow along defined paths, and JavaScript is used for dynamic filtering and transformation. The JSON rule chain definition is simpler than DRL and easy to generate programmatically, but it does not support the same level of declarative rule reasoning.

The practical difference: Drools is better suited for insurance pricing engines, compliance checking systems, and anywhere you need to assert many facts and fire rules based on combinations of conditions. RuleGo is better suited for event routing, data pipelines, IoT command dispatching, and any scenario where the logic is a workflow graph rather than a reasoning problem. RuleGo also runs without a JVM, which matters for Go shops and edge computing environments.

Maintenance and Licence

RuleGo is licensed under Apache-2.0. The latest release is v0.37.0, published on 2026-08-03. Prior releases include v0.36.0 (2026-05-29) and v0.35.0 (2025-12-17), which shows a roughly quarterly release cadence. The last push to the repository was on 2026-09-24.

The `go.mod` requires Go 1.20 and lists dependencies including goja (JavaScript execution), paho.mqtt.golang, expr-lang/expr, go-sql-driver for MySQL, and pq for PostgreSQL. The JavaScript support via goja is how the built-in JS Filter, JS Switch, and JS Transformer components evaluate expressions at runtime without a separate process.

The repository is on GitHub and also mirrored on Gitee. The official website at rulego.cc provides English and Chinese documentation. A QQ group is listed for community support.

Editorial conclusion

RuleGo fits best when you need to externalize business rules from Go application code, deploy logic changes without restarting services, and connect heterogeneous systems through a configurable component pipeline. It is the wrong choice when your rule set runs to thousands of conditions requiring a full RETE reasoner, or when you need a rules editor with deep debugging and audit trail tooling. Before adopting it, check the `endpoint/` directory in the repository: the set of supported Endpoints (MQTT, HTTP, Kafka, etc.) determines whether RuleGo can integrate with your data sources without custom components.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. rulego/rulego on GitHub