Comparison
GoRules vs ArboRule: an engine, or the system around it.
GoRules is the fastest way to execute a rule in your own process. The question this page answers is what you still have to build once it has returned an answer.
The short answer
Choose GoRules when
- You want the engine inside your own process. GoRules embeds in twelve languages and benchmarks at around 91,000 evaluations per second on a single core, with no network hop at all.
- Evaluation volume is your cost driver. Every tier, including the free one, is priced per seat with unlimited evaluations — so a high-throughput decision costs the same as a rare one.
- You need the rules to be yours. The engine is MIT and the logic is portable JDM JSON you can execute anywhere, including in a mobile app or at the edge.
- You want rule changes to go through Git. Branches, commits, rebase, revert and group-approval change requests are first-class, which folds policy edits into an existing review culture.
- You cannot use hosted software, for regulatory or procurement reasons. GoRules is self-host-first and documents Docker Compose, Kubernetes, ECS Fargate and Azure Container Apps.
Choose ArboRule when
- The decision has to fetch its own data. Bureau, KYB, device and open-banking calls are Connection nodes with a stored trace, not JavaScript you write inside a function node.
- You need to prove a decision months later. Every run keeps its inputs, its version, its path and each external response, queryable over an API, for five years by default.
- Some decisions need a person. A Manual Review node suspends the run and lands it in a queue with SLA targets; a challenger version can carry a slice of live traffic while you watch.
- You want to test a change against what actually happened. Datasets built from decision history pin every provider response, so a replay is deterministic.
- You would rather not run it. There is nothing to deploy, patch or scale, and the price is one number tied to decisions rather than to how many people are in the editor.
Side by side
Every row links to where it came from.
Claims about GoRules are taken from GoRules’s own documentation, pricing and repositories — never from a review site, and never from us. Follow the link in the left column to check any of them.
| Criterion | GoRules | ArboRule |
|---|---|---|
| What you buydocs.gorules.io — engine vs BRMS read 2026-07-30 | different model Two things: the MIT-licensed ZEN engine, which executes rules, and a separate commercial BRMS where you author, test, version and publish them. The docs draw that line themselves. | One hosted product. The editor, the runtime, the history and the review queue are the same system. |
| Pricinggorules.io/pricing read 2026-07-30 | in the product Published and self-serve: Free, Team at €50/month for 5 users, Business at €500/month for 20 users, then Enterprise. Metered on seats, installations and environments — evaluations are unlimited on every tier. | US$ 500 a month on the Startup plan, including 50,000 decisions across Sandbox and Live. Priced by decision, not by seat. Building and testing is free up to 10,000 decisions a period. |
| Where it runsdocs.gorules.io — architecture read 2026-07-30 | different model Self-host first. The manager is a Docker image needing PostgreSQL and object storage; execution is either a REST microservice or the engine embedded in your own process via one of twelve SDKs. | Hosted only. There is no self-hosted, on-premises or bring-your-own-cloud option, and no published certification — the controls are an append-only audit log, role-based access, scoped API keys, configurable retention and SSO/SCIM. |
| Authoringdocs.gorules.io — node types read 2026-07-30 | in the product A visual decision graph with spreadsheet-style decision tables, plus the ZEN expression language, which the docs describe as readable by non-programmers. Function nodes are raw JavaScript. | A visual canvas with 22 node types. Rule, Decision Table, Scorecard and 2D Matrix are grid editors a policy owner can work in; operand fields also accept Python, and the Code node is Python only. |
| Versioningdocs.gorules.io — releases read 2026-07-30 | in the product Git-shaped and unusually complete: branches, commits, merge previews, rebase, revert, and change requests with single or group approval. Releases are semver snapshots promoted between environments. | A version is DRAFT, PUBLISHED or ARCHIVED. Published versions are immutable — you duplicate to a new draft — and publishing can require an approved review. There is no one-click rollback: you move traffic back. |
| Staged rolloutdocs.gorules.io — releases read 2026-07-30 | not in the product Not published. Promotion is all-or-nothing per environment; no percentage rollout, canary or champion-challenger appears in the documentation. | Integer traffic weights across published versions, summing to 100, sticky per grouping_id so an application keeps the version it started on. No shadow mode: a challenger serves real traffic or none. |
| Decision historydocs.gorules.io — evaluate decision read 2026-07-30 | different model The evaluate API takes an opt-in trace flag and returns the node-by-node execution in the response. There is no decision-history endpoint in the published API reference; the audit log records authoring actions, and runtime logs go to your own observability stack. | Every run stores its input, output, the version that produced it and a node-by-node trace, including each external call's URL, status and latency and each model's SHA-256. Queryable at GET /history/api/v1/decisions. Retention is per-workspace, five years by default. |
| External datadocs.gorules.io — function nodes read 2026-07-30 | different model Through a JavaScript function node, which ships an axios-like http library with a 5-second default timeout. There is no first-class HTTP or connector node type, and the docs put function nodes on the slow path. | 28 packaged providers, six databases, and any HTTPS/JSON API through a Custom Connection. You bring your own credentials for each: the platform orchestrates the calls, it does not resell the data. |
| Human reviewdocs.gorules.io — change requests read 2026-07-30 | not in the product Approval queues cover rule changes and release deployments, not decisions. Nothing documents a decision pausing mid-execution to wait for a person, and there is no case or task node type. | A Manual Review node suspends the decision and puts it in a reviewer queue; Case nodes record work without blocking the run. Case queues carry SLA policies pinned onto each case at creation, with business-hours clocks and escalation rungs. |
| AI and modelsdocs.gorules.io — AI read 2026-07-30 | different model AI is authoring-time: a copilot that reads policy documents into decision tables and an MCP server for editor agents, on the Enterprise tier. All seven node types are deterministic — there is no LLM or model node at decision runtime. | AI and Agent nodes call OpenAI, Anthropic or Google models inside the decision, on your own API key. No key, no AI. ONNX models up to 32 MB, immutable once uploaded and re-verified by SHA-256 at scoring time, executed in-process. One graph input, CPU only. |
The real dividing line is not features
It is easy to read a comparison table as a score, and on raw execution GoRules would win one. A Rust engine that evaluates a rule in microseconds inside your own process, under an MIT licence, with unlimited evaluations at a flat seat price, is a genuinely excellent piece of engineering and it is priced generously.
But an engine answers a narrow question: given these facts, what does the policy say? A production credit or fraud decision asks a wider one. Where did the facts come from, and did that call succeed? Which version was in force? What happened to the cases that were referred? Can you show all of that to someone in eighteen months who was not there?
Every one of those is answerable with GoRules. None of them is answered by GoRules. That is the work this page is about.
The question is not which engine evaluates a rule faster. It is how much of the system around the rule you intend to build and operate yourself.
Fetching data is where the shapes diverge
In GoRules, a decision that needs a credit bureau reaches for it through a JavaScript function node, using the bundled http library. That works. It also means the call is code inside the policy, its failure handling is code you wrote, its timeout is a default you have to know about, and its response is not part of any record unless you make it so. The docs are candid that function nodes are the slow path — roughly 3,000 to 50,000 evaluations per second against 150,000-plus for tables.
In ArboRule a provider call is a Connection node. The credential lives outside the flow, the call appears in the trace with its URL, status and latency, and the response is pinned when that decision is later replayed as a test case. The policy stays a description of the decision rather than a description of the decision plus its plumbing.
Which you prefer depends on who edits the policy. If it is engineers, code in a function node is not a burden. If it is a risk analyst, an untyped fetch in the middle of the logic is the part they cannot safely touch.
What GoRules does that we do not
Two things, and both are real.
The first is running in your process. Embedding removes the network hop entirely and puts the decision inside your own transaction, which matters at very high volume and matters more if you cannot use hosted software at all. ArboRule has no answer here: it is hosted, and that is the whole story.
The second is Git. GoRules keeps rules as portable JSON with real branches, commits, rebase and group-approval change requests. If your organisation already reviews everything through pull requests, that is a better fit than any bespoke publishing workflow, including ours. ArboRule versions immutably and can require an approved review before publish, but it is not Git and does not pretend to be.
And the honest cost of choosing us
You cannot run ArboRule yourself. There is no self-hosted build, no on-premises option and no bring-your-own-cloud. If your compliance position requires the decision to execute on infrastructure you control, this comparison ends here and GoRules is the answer.
We also publish no certification. The controls are real — append-only audit log, role-based access, scoped API keys, configurable retention, SSO and SCIM, an egress guard on outbound calls — but a control is not a certificate, and we would rather say so than let a procurement checklist assume otherwise.
And the price is per decision, not per seat. Above 50,000 decisions a month that is a different curve from GoRules' unlimited-evaluation seats. If your volume is large and your team is small, do the arithmetic before you decide.
Questions
Is GoRules open source?
The engine is. ZEN Engine, the REST agent and the React editor component are MIT-licensed, and the rules themselves are portable JDM JSON. The BRMS — where you author, version and publish — is the commercial product, sold in self-hosted tiers from free to €500 a month. So the execution layer is genuinely open and the management layer is not, which is a common and reasonable split.
Is there an open-source alternative to ArboRule?
Not ArboRule itself, which is hosted only. If open source is a requirement, GoRules and Drools are the two serious answers, and they are different from each other: GoRules is a modern Rust engine with a visual editor, Drools is a deep Java inference engine you embed. What neither gives you is the operational layer — decision history you can query years later, a reviewer queue, weighted traffic across versions — which you would build or buy separately.
Can GoRules call an external API during a decision?
Yes, from a JavaScript function node, which ships an axios-like http client with a five-second default timeout. There is no dedicated connector or HTTP node type, so the call, its authentication and its error handling are code you write and maintain inside the policy, and the response is not recorded anywhere by default.
Last verified July 30, 2026 against GoRules’s public documentation. Products change and pages move; if something here is out of date, tell us at hello@arborule.com and we will correct it.