Higson Deployment Guide: Kubernetes, AWS, REST API (2026)

Why most BRMS deployment guides are useless to the architect doing the actual work

When I PoC'd three Business Rules Management Systems for a $1.8B GWP P&C carrier in the Northeast last quarter, the Lead Architect's first question was not "what features does it have." His first question was "show me the Kubernetes deployment manifest you would actually run in our cluster." Two of the three vendors could not produce one on the call. The third sent me a 40-page PDF that referenced a 2019 Kubernetes API version and a Helm chart that did not match what the support team was using.

In my experience, the gap between BRMS marketing material and BRMS deployment reality is where most evaluation projects stall. Architects want concrete artifacts - the actual REST endpoint surface, the resource limits that survive a production load test, the integration patterns that fit their event-driven microservices stack. They do not want "seamless integration" language; they want the YAML.

This article gives you the concrete deployment material for Higson. I cover the architecture (what runs where), all six deployment options (AWS Marketplace, Azure, GCP, Kubernetes, traditional servlet container, on-prem), Kubernetes manifests with sizing guidelines, REST API and Java SDK integration patterns, monitoring and observability setup, and the production checklist I run with every customer before go-live. Skip to Section 3 if you want AWS Marketplace; Section 4 for Kubernetes; Section 8 for the production checklist.

This is a technical reference, not a sales document. If something does not fit your environment, I would rather you know that before the PoC than after.

Higson deployment architecture overview

Higson has two core components plus a database. Understanding what each does and where it lives is the foundation for every deployment decision that follows.

Higson Studio (authoring environment)

The web-based no-code authoring UI where Business Analysts (the Linda persona) create and edit decision tables, rule sets, and decision flows. Higson Studio is a Java application that runs in a servlet container (Tomcat by default), as a Docker container, or as a Kubernetes pod. It is stateful in the sense that it talks to a relational database for rule storage; the application itself is stateless and can scale horizontally.

Recommended cluster footprint: 1-2 replicas for production (HA), 1 replica for staging. Higson Studio is read-heavy during authoring sessions and bursts on rule deployment - sizing should target P99 deploy latency, not average.

Higson Runtime / Runtime REST (execution engine)

The actual rule-execution engine. Two delivery modes:

• Embedded (Java SDK): Higson Runtime loaded as a Maven/Gradle dependency directly into your Java application. Rule execution happens in-process. Lowest latency (~0.23 ms P50), no network hop. Best for high-throughput Java applications.

• Standalone (Runtime REST): Higson Runtime exposed as a REST/JSON service that any language can call. Adds a network hop (typically 1-3 ms depending on cluster topology). Best for polyglot environments and microservices architectures where the calling service is not Java.

Both modes share the same rule-evaluation core - rules authored in Higson Studio deploy identically to both. I recommend running the Runtime REST mode unless your throughput requirements specifically justify embedded. In my experience the network-hop cost is usually overstated; for 90% of mid-market workloads at 1 000-5 000 req/s, REST is more than fast enough.

Database (rule storage)

Higson stores rule definitions, versions, and audit logs in a relational database. Supported: PostgreSQL, Oracle, MSSQL, MySQL. H2 is available for non-production sandboxing. The database is the source of truth for rules; both Studio and Runtime read from it. Database size for a typical mid-market deployment (2 000-10 000 rules across 12-25 decision tables): 5-20 GB including audit history.

Database connection pattern: Higson Studio writes (BAs editing rules); Runtime instances read (rule evaluation). For HA, the database itself should be a managed service (RDS, Cloud SQL, Azure SQL) or a self-managed replica set. Higson does not bundle JDBC drivers in the official Docker images - you mount or build the driver in, which is the same pattern as most JVM applications.

Component topology

In production, the topology I recommend looks like:

[Linda BA browsers]
         |
         v
[Higson Studio] <---write/read---> [PostgreSQL]
                                        ^
                                        | read
[Caller services] --REST--> [Higson Runtime REST]
                  OR

[Java app w/ embedded Higson SDK] --read--> [PostgreSQL]

Three independent scaling units (Studio, Runtime REST, database) - each sized to its own load profile. The Studio fleet handles authoring traffic; the Runtime fleet handles production decision traffic; the database backs both.

Deployment options: which one fits your environment

Six deployment paths, ranked by how often I see them used in mid-market insurance and banking.

In my experience, 70-80% of new Higson deployments at mid-market carriers go straight to Kubernetes. AWS Marketplace is the most common entry point for PoCs - architects use the $0.63/hour pay-as-you-go to validate the engine in 15 minutes before involving procurement. Traditional servlet container deployments are increasingly rare but still requested by on-prem-only carriers.

AWS Marketplace quick start ($0.63/hour PoC)

The fastest path from "never heard of Higson" to "running a real decision in production-like environment" is the AWS Marketplace listing. The walkthrough:

1. Search "Higson" in AWS Marketplace; subscribe to the SaaS offering. Pricing is $0.63/hour pay-as-you-go for the PoC tier - approximately $460/month if you leave it running 24/7, which you typically would not for a PoC.

2. Launch the CloudFormation stack template. It provisions Higson Studio, Higson Runtime REST, and an RDS PostgreSQL instance. Defaults are sized for PoC; production sizing covered in Section 6.

3. Wait approximately 10-15 minutes for the stack to come up. The CloudFormation output gives you the Studio URL, the Runtime REST endpoint, and the initial admin credentials.

4. Log in to Higson Studio. The default workspace ships with a sample decision table (insurance underwriting eligibility) that you can edit immediately. This is where the Linda BA persona starts.

5. Call the Runtime REST endpoint with sample JSON. The Marketplace listing includes a Postman collection covering all standard endpoints.

Total elapsed time from subscription to first decision execution: 15-20 minutes. The Marketplace tier is fine for PoC and small workloads (up to about 200 req/s sustained). For production, move to the enterprise license tier and a dedicated Kubernetes deployment, which is covered next.

Kubernetes deployment with manifests and Helm

The recommended production deployment path. Higson ships official Docker images for both Studio and Runtime REST, plus Helm charts for full Kubernetes deployment. Minimal example manifests below; the official Helm chart covers HPA, ingress, secrets, and TLS in more detail.

Higson Runtime REST deployment manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: higson-runtime-rest
  namespace: higson
spec:
  replicas: 3
  selector:
    matchLabels:
      app: higson-runtime-rest
  template:
    metadata:
      labels:
        app: higson-runtime-rest
    spec:
      containers:
      - name: higson-runtime
        image: higson/runtime-rest:latest
        ports:
        - containerPort: 8080
        env:
        - name: DB_URL
          valueFrom:
            secretKeyRef:
              name: higson-db-credentials
              key: url
        resources:
          requests:
            memory: "1Gi"
            cpu: "200m"
          limits:
            memory: "4Gi"
            cpu: "2000m"
        livenessProbe:
          httpGet:
            path: /actuator/health/liveness
            port: 8080
          initialDelaySeconds: 30
        readinessProbe:
          httpGet:
            path: /actuator/health/readiness
            port: 8080
          initialDelaySeconds: 15

Higson Studio deployment manifest

apiVersion: apps/v1
kind: Deployment
metadata:
  name: higson-studio
  namespace: higson
spec:
  replicas: 2
  selector:
    matchLabels:
      app: higson-studio
  template:
    metadata:
      labels:
        app: higson-studio
    spec:
      containers:
      - name: higson-studio
        image: higson/studio:latest
        ports:
        - containerPort: 8080
        env:
        - name: DB_URL
          valueFrom:
            secretKeyRef:
              name: higson-db-credentials
              key: url
        resources:
          requests:
            memory: "1Gi"
            cpu: "200m"
          limits:
            memory: "4Gi"
            cpu: "2000m"

Cross-namespace access via ExternalName

When the calling application is in a different namespace than Higson (the recommended isolation pattern), expose Runtime REST via ExternalName service for clean service discovery:

apiVersion: v1
kind: Service
metadata:
  name: higson-runtime-rest
  namespace: my-application
spec:
  type: ExternalName
  externalName: higson-runtime-rest.higson.svc.cluster.local

I recommend running Higson in a dedicated namespace (higson) with NetworkPolicies controlling which application namespaces can reach Runtime REST. This isolation makes audit and security review straightforward later.

Sizing guidelines for production

The defaults in the manifests above are conservative starting points. Real sizing depends on your throughput requirements, rule-set complexity, and authoring user count. The numbers below come from production deployments I have helped tune over the last 5 years.

Three sizing principles I have arrived at over many deployments:

• Size for peak, not average. Mid-market insurance quote traffic has 3-5x diurnal swing - 9 AM EST is much busier than 11 PM. Plan for peak with HPA (Horizontal Pod Autoscaler) on CPU and request-rate metrics.

• Memory matters more than CPU for rule sets > 5 000 rules. The in-memory rule index grows with rule count; if you see OOM kills, increase memory before adding more pods.

• Database connections are usually the constraint, not Higson pods. If you scale Runtime REST to 10 pods with default connection pools, you can exhaust DB connections. Tune the pool per-pod or use PgBouncer in front of PostgreSQL.

Integration patterns: REST API, Java SDK, and batch

Three integration paths into Higson. Most production deployments use REST API for online traffic and batch for nightly recalculation, with the Java SDK reserved for high-throughput in-process scenarios.

REST API (the most common pattern)

Higson Runtime exposes an OpenAPI 3.0-compliant REST surface. The core endpoint shape:

POST /api/v1/rules/{ruleId}/execute
Content-Type: application/json

{
  "input": {
    "creditScore": 720,
    "state": "TX",
    "priorClaims36mo": 0,
    "mvrViolations": 0
  }
}

The response includes the decision output, the rule version that fired, the row(s) matched, and a full audit-log entry ID. Typical latency for the API call: 1-3 ms end-to-end including network hop, with rule execution itself at 0.23 ms P50.

OpenAPI spec is auto-generated from the deployed rules - your client code can be generated from the spec using openapi-generator or similar. I recommend regenerating client stubs whenever a rule input schema changes.

Java SDK (embedded mode)

For Java applications where the network hop to Runtime REST is unacceptable - the highest-throughput pricing engines, real-time fraud scoring, in-flight quote evaluation - Higson ships as a Maven/Gradle dependency:

HigsonClient client = HigsonClient.create(
    HigsonConfig.builder()
        .dbUrl("jdbc:postgresql://...")
        .build());

DecisionResult result = client
    .rule("auto-eligibility")
    .input(Map.of(
        "creditScore", 720,
        "state", "TX"
    ))
    .execute();

Embedded mode reads rules from the same database the Studio writes to, so authoring changes propagate to all Runtime instances (REST and embedded) on the next refresh cycle. Default refresh interval: 30 seconds. Configurable down to 5 seconds for time-sensitive deployments.

Batch processing

For nightly recalculations - renewal pricing, commission settlement, periodic eligibility re-checks - Higson supports batch mode that evaluates a CSV or Parquet file of inputs and produces a corresponding output file. Throughput in batch mode: 100 000+ records per minute on a single Runtime instance with the right tuning. Notus Finance runs 100 000 commission calculations in 8 seconds using this pattern.

Event streaming integration

For event-driven microservices architectures (Kafka, Pulsar, RabbitMQ), the pattern I recommend is to deploy a small adapter service that consumes events, calls Higson Runtime REST synchronously, and publishes the decision result back to a downstream topic. Higson does not ship a built-in Kafka consumer - the explicit adapter pattern keeps the decision-engine boundary clean and the event-processing logic where it belongs. Daniel-architect carriers usually prefer this over an opinionated Kafka integration.

Monitoring, observability, and production checklist

Three categories of monitoring matter for a production Higson deployment: health and availability, decision latency and throughput, and rule-change governance. In my experience, the carriers who skip the third category - rule-change governance monitoring - are the same ones who end up surprised when a state DOI examination asks for an audit trail nobody set up.

Health and availability

Higson exposes Spring Boot Actuator endpoints on /actuator/health and /actuator/metrics. Standard Kubernetes liveness and readiness probes work out of the box (shown in Section 5 manifests). For deeper observability, the /actuator/prometheus endpoint returns Prometheus-formatted metrics covering JVM, HTTP, and Higson-specific counters.

Decision latency and throughput SLOs

The SLOs I recommend setting from day one:

• P50 decision latency < 5 ms (Higson typical 0.23 ms; the 5 ms ceiling includes network and serialization)

• P99 decision latency < 50 ms

• Error rate < 0.1%

• Sustained throughput per replica >= 1 500 req/s before HPA triggers scale-up

Grafana dashboards for these are straightforward to build off the Prometheus endpoint. The Higson docs include a reference dashboard JSON.

Rule-change governance and audit

Every rule change in Higson Studio is version-stamped with author, timestamp, and required change reason. Every decision the Runtime fires logs the inputs received, the row that matched, the outputs returned, and the rule version. For NAIC Model Bulletin on AI Use in Insurance audit-trail requirements, this is the difference between a 2-hour state DOI examination response and a 2-week one.

I recommend setting up alerts on three rule-governance metrics:

• Unexpected rule deployment outside maintenance windows

• Rule deployment without an associated change ticket (if you integrate Higson Studio with Jira or ServiceNow)

• Decision reversal rate spike (more than 2x baseline within a 1-hour window)

Production checklist

Before go-live with Higson, work through this checklist. I run this with every carrier; missing items are the source of nearly every post-launch incident.

1. Database backup strategy in place (RDS automated backups or self-managed equivalent), tested restore from backup.
2. TLS certificates configured for Studio UI and Runtime REST endpoint.
3. Authentication wired up (Higson supports OIDC, SAML, basic auth) - production deployments should use OIDC against your existing identity provider, not the local Higson user store.
4. NetworkPolicies restrict which namespaces can reach Higson Runtime REST.
5. Secrets (DB credentials, OIDC client secret) managed through Kubernetes Secrets, External Secrets Operator, or your cloud secret manager - never inlined in manifests.
6. HPA configured with both CPU and custom metrics (request rate).
7. Prometheus scraping the /actuator/prometheus endpoint.
8. Grafana dashboards covering latency, throughput, error rate.
9. Alerts wired to PagerDuty/Opsgenie for SLO violations.
10. First shadow-mode deployment of new rules tested (run rules in parallel with legacy logic for 2-4 weeks before cutover).
11. Rollback plan documented (Higson Studio supports rule-version rollback in seconds; ensure the application path also supports reverting which rule version it calls).
12. State DOI examination response template prepared (the audit-log structure that the regulator will ask for is the same across carriers; preparing the response template upfront saves time later).

Where Higson deployment is not the right fit

I would rather lose a deal than win one badly. Three deployment scenarios where I tell prospects Higson is not the right answer:

• Sustained throughput beyond 50 000 req/s with sub-millisecond P99. Higson runs 9 000 req/s comfortably on standard cloud sizing; we have customers at higher loads with tuning, but if your real-time mobile-commerce workload genuinely requires 50 000+ sustained req/s, InRule or IBM ODM at enterprise-tier pricing are better fits. We will tell you that on the call.

• .NET-only environments. Higson is a JVM-based product. The Runtime REST endpoint can be called from any language, but the SDK is Java-only. If your stack is .NET end-to-end and you want embedded SDK access, FlowWright or InRule may fit better.

• Pure BPMN workflow problems with few decision points. If your problem is a 30-day commercial submission with 8 human hand-offs and only 5-10 programmed decisions, Camunda is a better fit - it is purpose-built for the workflow orchestration. Higson focuses on the decisions inside such a flow.

Within mid-market insurance, banking, and healthcare - $500M-$5B GWP P&C carriers, $1B-$20B AUM banks, mid-size healthcare payers - Higson is built for this segment. Outside it, an honest evaluation acknowledges where the product runs out of road.

FAQ

How do you deploy Higson rules engine in production?

The recommended production deployment path is Kubernetes with Higson Studio and Higson Runtime REST running as separate deployments backed by managed PostgreSQL (RDS, Cloud SQL, or Azure SQL). Typical sizing: 3-5 Runtime REST replicas at 2-4 Gi memory per pod, 2 Studio replicas at 1-2 Gi, HPA on CPU and request-rate metrics. Setup time: 2-4 hours from blank Kubernetes cluster to running decisions. Production checklist covers TLS, OIDC authentication, NetworkPolicies, secrets management, monitoring, and shadow-mode rule deployment.

Can Higson be deployed on Kubernetes?

Yes - Kubernetes is the primary production deployment target. Higson ships official Docker images for both Higson Studio and Higson Runtime REST plus Helm charts covering HPA, ingress, secrets, and TLS. Stateless pods scale horizontally; managed PostgreSQL (RDS, Cloud SQL, Azure SQL) provides the rule storage. Cross-namespace access uses ExternalName services. Recommended isolation: dedicated higson namespace with NetworkPolicies controlling which application namespaces can reach Runtime REST.

What is the fastest way to try Higson rules engine?

AWS Marketplace at $0.63/hour pay-as-you-go is the fastest path - 15-20 minutes from subscription to first decision execution. The CloudFormation stack template provisions Higson Studio, Higson Runtime REST, and an RDS PostgreSQL instance; the deployment ships with a sample insurance underwriting decision table you can edit immediately. The Marketplace tier handles up to about 200 req/s sustained, fine for PoC; production deployments move to enterprise license and dedicated Kubernetes.

How much memory and CPU does Higson need?

Per Runtime REST pod: 1-4 Gi memory, 200m-2000m CPU depending on rule-set complexity and throughput. Per Higson Studio pod: 1-4 Gi memory, 200m-2000m CPU. Database: PostgreSQL on RDS db.m5.large or equivalent handles typical mid-market workloads (2 000-10 000 rules, 12-25 decision tables). Memory matters more than CPU for large rule sets (> 5 000 rules); database connections are often the throughput constraint at scale.

How do you integrate Higson with existing applications?

Three integration paths. REST API (OpenAPI 3.0 spec, ~1-3 ms end-to-end latency including network hop) for online traffic - most common. Java SDK (Maven/Gradle dependency, embedded in-process, ~0.23 ms P50 latency) for high-throughput Java applications. Batch processing (CSV or Parquet input, 100 000+ records per minute throughput) for nightly recalculations like renewal pricing and commission settlement. For Kafka/event-streaming, the recommended pattern is a small adapter service that consumes events, calls Runtime REST, and publishes results back.

How does Higson handle high availability and disaster recovery?

Higson Studio and Higson Runtime REST are stateless and scale horizontally - HA is achieved with multiple replicas behind a Kubernetes service. State lives in the database, which should be a managed HA service (RDS Multi-AZ, Cloud SQL HA, Azure SQL with replica). Backup strategy: automated database backups with tested restore procedure. Rule-version rollback within Higson Studio takes seconds; ensure application path also supports reverting which rule version is called.

What monitoring should I set up for a production Higson deployment?

Three categories. Health and availability via Spring Boot Actuator endpoints (/actuator/health, /actuator/prometheus). Decision latency and throughput SLOs (P50 < 5 ms, P99 < 50 ms, error rate < 0.1%, sustained throughput per replica >= 1 500 req/s). Rule-change governance (alerts on unexpected deployments outside maintenance windows, rule changes without associated tickets, decision-reversal-rate spikes > 2x baseline). Reference Grafana dashboard JSON ships with Higson docs.

Related reading

• What is a Rules Engine? Complete Guide for Insurance 2026 - the BRMS primer.

• Java Rules Engines: Drools, Easy Rules, Higson SDK Comparison - Java SDK reference.

• Decoupling Decisions: BRMS in Microservices Architecture - architecture patterns for event-driven stacks.

• Scalability in Business Rules Engines - performance benchmarks for mid-market workloads.

• Building Your Own Rules Engine: The Honest TCO of Build vs Buy - what you would need to recreate.

• Decision Tables in Higson Studio - the BA authoring layer that sits above Runtime REST.

• Higson is Secure - CREST certification, SOC 2 Type II attestation, encryption.

• Insurance Premium Calculation - Higson Runtime in the pricing flow.

• Simplifying Insurance Claims Management with Rules Engines - Higson Runtime in the claims flow.

Talk to Higson

Deployment is where most BRMS evaluations turn from marketing-deck conversations into actual production conversations. The carriers I work with who go to production fastest have one thing in common: they ran a $0.63/hour PoC on AWS Marketplace within 48 hours of first conversation, before any procurement cycle started. The architects validate the engine; the BAs experience the authoring flow; the CTO sees a working system with a known dollar-per-hour cost. Then the real procurement conversation begins with shared technical context.

Higson is built for mid-market P&C insurance carriers $500M-$5B GWP, mid-market banks $1B-$20B AUM, and mid-size healthcare payers. We are not the right answer for 50 000+ req/s enterprise scale, .NET-only environments, or pure BPMN workflow problems - we will say so on the first call. Where we do fit, customers move from initial PoC to production deployment in 3-6 months with Kubernetes manifests that match what their architecture team already runs.

If you would like to see Higson Studio and Higson Runtime REST in your environment - the Kubernetes manifests, the REST API surface, the sizing for your actual throughput - I would be happy to walk through it with your architect team.

Three ways to start:

• Try Higson on AWS Marketplace at $0.63 / hour - 15 minutes from subscription to first decision execution. (/contact?source=aws_marketplace)

• Schedule a 30-minute architecture review - we will walk through Kubernetes deployment, sizing, and integration patterns specific to your stack. (/contact?source=blog_deployment)

• Download the BRE Comparison Guide - 12 vendors compared on deployment options, integration patterns, and architecture. (/business-rules-engine-comparison)

Citations

1. Higson Product Documentation - deployment guides, Helm charts, and API reference. https://www.higson.io/download
2. AWS Marketplace - Higson listing at $0.63/hour. https://aws.amazon.com/marketplace/
3. Kubernetes documentation - Deployment, Service, HPA reference. https://kubernetes.io/docs/
4. Spring Boot Actuator documentation - health, metrics, prometheus endpoints. https://docs.spring.io/spring-boot/docs/current/actuator-api/htmlsingle/
5. NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers (2023, updated 2024-2025) - audit-trail requirements satisfied by Higson logging. https://content.naic.org/sites/default/files/inline-files/2023-12-4 Model Bulletin_Adopted_0.pdf
6. OpenAPI 3.0 Specification - Higson REST API surface format. https://swagger.io/specification/
7. OMG Decision Model and Notation (DMN) Specification - rule format Higson implements. https://www.omg.org/dmn/
8. Notus Finance / Higson case study (Drools migration, 100 000 calculations in 8 seconds, batch mode reference) - https://www.higson.io/case-study/
9. Gartner Hype Cycle for Decision Management Software (2025) - BRMS market context.