Scaling MATLAB and Simulink workloads in Quix Cloud

MATLAB and Simulink are central to Model-Based Design — but they only deliver at scale with the right data infrastructure around them: live sensor feeds, raw time-series enriched with configuration context, parameter sweeps orchestrated across many runs, and model outputs wired into downstream analytics.

Quix recently joined the MathWorks Connections Program as a third-party partner — a programme of over 500 products and services that extend MATLAB and Simulink. The integration removes the infrastructure barriers that stop models running at scale.

The integration at a glance

Quix lets MATLAB and Simulink models plug into real-time and batch pipelines. Data flows in from Kafka topics, runs through MathWorks code, and the results publish back to Kafka for storage, visualisation or further processing. The Quix Runtime uses Kubernetes to manage applications in Docker containers, so multiple models run in parallel and scale automatically against trigger criteria.

There are four supported integration methods. The right one depends on whether the model runs inside Quix, whether a license server is available at runtime, and how often the code changes.

Method 1 — compiled MATLAB wheel

The most common production path. MATLAB functions compile into a Python .whl package via MATLAB Compiler. At runtime only the free MATLAB Runtime is needed — no license server, no full install — and images come in around 2–3 GB. The quix_compiler.m tool handles compilation, setup.py generation and packaging:

quix_compiler('rot', './output_folder')

The compiled function is then called from Python inside the Quix Streams loop. It's the lightest footprint, self-contained and horizontally scalable. The trade-offs: not every toolbox function survives compilation, every change means recompiling and redeploying, and output uses native NumPy arrays rather than MATLAB's type system.

Method 2 — full MATLAB Engine

For teams actively developing .m files or relying on unsupported toolboxes. A full MATLAB install runs inside the container and functions are called through the Engine API. You get the complete ecosystem, interactive debugging and changes that take effect on restart — but it needs an accessible license server, images exceed 10 GB, and each instance consumes a license seat, which complicates horizontal scaling.

Method 3 — FMU/FMI

Supports the Functional Mock-up Unit standard via FMI, an open standard used by 280+ modelling tools. FMUs run inside Quix containers with no MATLAB or Simulink install at runtime, and give the best execution speed of the containerised options for Simulink models. The limitation: an FMU is a frozen snapshot — no debugging, locked to its export-time solver and step size, and pure MATLAB functions have no FMU export path.

Method 4 — Simulink via MQTT

For teams running Simulink on a local workstation. Simulink stays on the engineer's machine and Quix catalogs the inputs and outputs over MQTT. You keep the full desktop experience and toolbox access, but the simulation runs on one machine with no parallelisation, and Quix can't manage deployment, scaling or resources because the model lives outside the platform.

Why running models inside the pipeline matters

The three containerised methods are what set Quix apart from simply streaming data to an external MATLAB install. When a model runs inside the platform it becomes a scalable service with its own CPU and memory, and multiple instances can consume the same Kafka topic through consumer groups. That's the jump from running a model once on a laptop to processing live telemetry in real time — or sweeping a parameter space across many concurrent runs. F1 teams run vehicle-dynamics models against live race telemetry; battery makers monitor cell behaviour against degradation models; HVAC manufacturers validate control algorithms against test-chamber data.

The partnership so far

Engineering teams have worked with MathWorks' consulting group on the integration architecture, and MathWorks' startup program published a spotlight on Quix. As CEO Mike Rosam put it: "The support has been unrivalled. MathWorks went the extra mile — account support, engineering support, even marketing support." Mutual customers already run these integrations in production, from F1 digital twins during live sessions to automotive OEMs processing real-time test data.

Where we're heading

Two things are in active development: native Simulink connectivity — first-class Quix I/O blocks for the Simulink library so you get drag-and-drop source and sink blocks without configuring an intermediate broker — and improved Simulink compilation performance, closing the current gap where FMU export outruns the Python-wheel path.

Get started

The MATLAB integration ships as a project template you can deploy in Quix Cloud, including a 2D vector data source, a MATLAB Wheel Runner and a MATLAB Engine Runner. Deploy it for a working end-to-end pipeline, then swap in your own function:

quix_compiler('your_function', './output_folder')

The resulting wheel drops into your existing Docker build and deploys through standard Quix pipelines. The FMU runner is available as a separate template.