Skip to content
Docs

Configuration & Admin

Interplay is administered from the editor itself plus a small set of environment-level settings, so a platform team can operate it without a separate console.

Server behavior is driven by environment variables and generated settings files, rendered from templates at startup. Commonly set values include the HTTP port, the runtime mode, an administrative API key, admin credentials, and paths for flows and project data. Because configuration is environment-driven, the same image is promoted unchanged from development to production with different variables.

What can administrators manage from the editor?

Section titled “What can administrators manage from the editor?”
  • Users and access — accounts, roles, and identity-provider configuration; see Security and compliance.
  • Palette — install, pin, upgrade, and remove nodes from the registry, npm, or an upload; resolve missing nodes for an imported flow.
  • Runtimes and libraries — create Python virtual environments and install or remove packages per environment.
  • Databases — provision and connect MySQL, PostgreSQL, or MongoDB, and browse data through the built-in database viewer.
  • Projects and pipelines — create projects, activate one, and assemble flows into pipelines with their own routes.
  • Files — a workspace file manager with directory listing, create, rename, move, copy, delete, zip/unzip, and disk-usage reporting.
  • Applications and templates — install and uninstall bundled starter apps and templates, with progress and status reporting.

Projects isolate flows, assets, and credentials, and a project can be Git-initialized so its history is tracked independently. Version history is browsable from the editor and a workspace can be switched between versions. For separation across environments, the usual pattern is one Interplay deployment per environment with the same flow artifacts promoted between them.

Interplay reports system health — operating system, CPU, memory, disk, and process state — through a health endpoint suitable for load-balancer and orchestrator probes, and container images include a built-in health check. Runtime logs are written to a log directory with automatic rotation and retention, and can be tailed from the container’s standard output for collection by the organization’s existing log platform. A supervisor keeps the runtime alive and restarts it if it exits unexpectedly.