RunMat Server
RunMat Server is a shared control and data plane for RunMat. It provides identity, organizations and projects, versioned project storage, synchronization events, package distribution, policy and usage enforcement, and remote-execution coordination through one authenticated API surface.
RunMat Cloud is a hosted deployment of RunMat Server. Organizations that need dedicated infrastructure can deploy RunMat Server in a single-tenant environment. Desktop, web, CLI, CI, Agent, and compute nodes connect to Server, while the open-source Runtime executes MATLAB-syntax programs.
Core resource model
- An organization is the tenant and policy boundary.
- A membership assigns a user or service identity a role.
- A project is a filesystem and history namespace.
- A file version connects metadata to content in blob storage.
- A run records a requested computation, target, state, and artifacts.
- A package version is an immutable published dependency.
Server uses relational metadata storage and a blob store for content. Deployments can integrate an OIDC provider and, where applicable, external billing or model providers.
Start with Deployment options, then configure Authentication and access. Runtime users looking for worker-side configuration should read Remote execution.
Server boundaries
Server is authoritative for shared identity, project metadata, committed file versions, retained-storage accounting, package versions, policy decisions, and remote-run coordination. Desktop and CLI jobs run locally unless a user selects an available remote target to scale beyond the machine.
The public API is one authenticated HTTP boundary. Requests pass through identity resolution, authorization and policy, domain services, relational transactions, blob I/O, event dispatch, metering, and observability. Those stages identify where to investigate a failed request.
Request paths
A small file write authenticates the caller, authorizes the project path, checks storage policy, stores or reuses content, commits metadata and an append-only version, updates accounting, and emits a filesystem signal. Large files can use signed upload sessions so bytes travel directly to the blob provider while Server retains authorization and commit control.
A connected client fetches authoritative project state and then follows the event stream with a cursor. Events identify changes; clients still read file state from the filesystem API.
For an optional remote run, Server checks project and compute policy, stages a committed project state, leases work to an eligible node, tracks logs and cancellation, and commits artifacts. Local runs bypass this scheduler.
Production checks
Before exposing Server, verify TLS, OIDC issuer and audience, database migrations, blob-store conformance, backup and restore, request-ID propagation, log redaction, event reconnect, quota enforcement, and a complete project round trip. Enable packages, billing, managed model providers, or remote compute after assigning credentials and operational ownership for each subsystem.