RunMat
  • Pricing
RunMat
GitHub
GitHub
DownloadSign InTry in Browser
DesktopRuntimeServer
RunMat

Run math blazing fast

GitHubX (Twitter)LinkedIn

Company

  • About
  • Pricing
  • Contact
  • License
  • Privacy

Learn

  • Docs
  • Blog
  • Benchmarks
  • RunMat vs MATLAB Online

Get product updates and release notes from the RunMat team.

© 2026 Dystr · Made withfor the scientific community.

RunMat™ is a registered trademark of Dystr, Inc. MATLAB® is a registered trademark of The MathWorks, Inc. RunMat is not affiliated with, endorsed by, or sponsored by The MathWorks, Inc.

/
    • Overview
    • Deployment
Docs>Server

Deployment options

Choose a deployment from the identity, isolation, connectivity, storage, and operational responsibility your organization requires.

ModeTypical boundaryIdentityStorage
RunMat CloudHosted multi-tenant serviceHosted identity integrationManaged relational and object storage
Single-tenantOne organization or controlled tenant setCustomer OIDCConfigured database and blob store
Isolated or air-gappedRestricted networkLocal enterprise OIDC and signed entitlement materialLocal infrastructure

Server is designed as a single public HTTP service with internal modules for authentication, organizations, files, packages, policy, execution, dispatch, and observability. Production deployments also require PostgreSQL-compatible metadata storage and a configured blob backend.

Before deployment, define the public base URL, TLS termination, OIDC issuer and audience, tenant bootstrap, blob lifecycle, database backup, outbound-provider policy, observability export, and recovery objectives. A readiness test should exercise authentication, file upload and download, history, events, and every enabled execution path.

Configuration names and availability can vary by distribution. Use the configuration reference shipped with your Server build and validate it in staging before promotion.

Required services

A production installation needs the Server binary, a PostgreSQL-compatible database for identity and resource metadata, and a supported blob store for files and artifacts. Interactive login requires an OIDC issuer. Email, analytics, observability export, enterprise SSO/SCIM, billing, managed model providers, search, and remote execution are optional integrations.

Run the API behind TLS termination. Configure forwarded client IPs for the actual proxy chain. The socket peer is the safe default. If the deployment trusts X-Forwarded-For, set the known proxy-hop count; the first header value can be client supplied.

Installation sequence

  1. Provision the database and blob container with separate least-privileged credentials.
  2. Generate encryption material, the API-key pepper, and provider secrets in a secret manager.
  3. Configure public API and application origins, CORS, and OIDC issuer, audience, and client IDs.
  4. Apply the database migrations supplied with the release.
  5. Start one instance and check liveness plus database/blob readiness.
  6. Test login, organization/project creation, small and multipart transfers, history, and event reconnect.
  7. Add replicas after confirming background-job and dispatch ownership.

Keep reviewed non-secret configuration per environment. Missing production secrets, issuers, and storage settings should fail startup. Production mode permits only production identity and durable blob backends.

Backup and recovery

Back up database metadata and blobs as one recovery set. The database records which content hashes and versions belong to each project; the blob store holds the bytes. Restore into an isolated environment and verify current files, historical versions, snapshots, and retained-storage totals. Both components are required: database metadata resolves project history, and the bucket supplies its content.

Readiness checklist

  • Readiness includes database and blob dependencies; liveness only proves the process responds.
  • Request IDs, structured logs, traces, and metrics reach the selected observability backend.
  • OIDC key rotation and clock skew have been exercised.
  • Proxy timeouts and body limits permit expected streaming and dataset sizes.
  • Backup, retention, key rotation, and incident ownership are documented.
  • Remote workers, when enabled, are isolated and use worker-scoped credentials.
On this page
  • Required services
  • Installation sequence
  • Backup and recovery
  • Readiness checklist