Skip to content
Docs

Deployment

Interplay is self-hosted by design. There is no requirement to send flows, prompts, credentials, or data to an Iterate.ai-operated service, and the same build runs from a developer laptop to a production cluster to an air-gapped site.

What are the deployment options?

Section titled “What are the deployment options?”
Form factor Use
Container image The standard production path — run on Docker, Kubernetes, or OpenShift.
Desktop application Signed installers for Windows, macOS, and Linux for local development and single-user work.
Linux server package A self-extracting installer for hosts where containers are not used; preserves existing flows, configuration, and credentials across upgrades.

A GPU-enabled variant and an OCR/document-AI variant of the container are available for workloads that need them on the same host.

What hardware does Interplay run on?

Section titled “What hardware does Interplay run on?”

Interplay is hardware-agnostic and runs across Intel, AMD, NVIDIA, and Qualcomm silicon, on both x86_64 and ARM64. Nothing about the platform requires a GPU — GPUs matter only for local model inference, fine-tuning, and some document-AI workloads. Because there is no hardware lock-in, the same flows move between a laptop, a data-center server, and an edge device.

Can Interplay run air-gapped or at the edge?

Section titled “Can Interplay run air-gapped or at the edge?”

Yes. Interplay supports cloud, on-premises, private-cloud, edge, and fully air-gapped deployments with no outbound dependency at runtime. Node packages, model weights, and dependencies are staged once at install time from an internal registry or mirror. This is the configuration used by customers in regulated and sovereign environments where no traffic may leave the site.

How is the container configured to run?

Section titled “How is the container configured to run?”

The production image runs as a non-root user with a locked root account and a restrictive umask, and is compatible with OpenShift’s arbitrary-UID model. It exposes a single configurable HTTP port (default 1880) and includes a health check. Flow storage is a mounted volume that survives image upgrades, so user flows, configuration, and credentials are preserved when the container is replaced.

How are upgrades handled?

Section titled “How are upgrades handled?”

Upgrades are an image or package swap. The installer and container entrypoint both explicitly preserve user data — flows, configuration, authentication settings, and installed runtime nodes — and versioned in-place upgrade payloads are available for server installations. Flows can also be reloaded and redeployed from storage without restarting the process, which makes routine flow changes a zero-downtime operation.

What does a production deployment look like?

Section titled “What does a production deployment look like?”

A typical production topology is: Interplay containers behind the organization’s own load balancer and ingress; persistent volumes for flows and project data; the organization’s identity provider wired in for SSO; model traffic pointed at a private inference endpoint such as Lifeboat or routed through AgentWatch for governance; and logs shipped to the existing SIEM or log platform.

Sources and references

Section titled “Sources and references”