Skip to main content

Terminology

Common terms used in Miren.

Addon​

A managed backing service that Miren provisions and operates for your app. Addons handle infrastructure setup and inject connection credentials as environment variables automatically. Available addons include PostgreSQL, MySQL, Valkey, RabbitMQ, and Memcache. See Addons.

App​

An application deployed to Miren. Each app has a name, configuration, and one or more deployments.

app.toml​

The configuration file for a Miren application, located at .miren/app.toml. Defines the app's services, environment variables, build settings, scaling behavior, disks, and addons. See app.toml Reference.

Build​

The process of creating a container image from your application source code. Miren detects your language and framework, runs build steps (including any onbuild commands), and produces an image that runs in a sandbox. Builds are powered by BuildKit.

Client Config​

The configuration file (~/.config/miren/clientconfig.yaml) that stores your CLI settings, including cluster connections and the active cluster. Managed automatically by commands like miren server install and miren cluster add.

Cluster​

A Miren server instance that runs your applications. A cluster can be standalone or connected to Miren Cloud for team management and multi-environment workflows.

Cold Start​

The additional latency on the first request to an app that has been scaled to zero or needs a new sandbox. Miren creates a sandbox, starts the process, and waits for it to bind its port before forwarding the request. Subsequent requests are served immediately.

Concurrency​

The scaling configuration for a service. Miren supports two modes: auto (scales instances up and down based on traffic) and fixed (runs a constant number of instances). Auto mode is configured with requests_per_instance and scale_down_delay; fixed mode uses num_instances. See Application Scaling.

Coordinator​

The primary node in a distributed cluster — the machine running miren server. The coordinator holds the cluster's state (entity store and etcd), image registry, and workload-identity signing, and schedules sandboxes across the cluster. It also runs workloads itself. Every distributed runner depends on the coordinator being reachable. See Distributed Runners.

Default Route​

The route automatically assigned to an app when it is first deployed. Points to the cluster's hostname (e.g., myapp.cluster-abc123.miren.systems), giving the app a URL without any DNS configuration.

Deployment​

An attempt to build and release a specific version of your app. Running miren deploy starts a deployment, which gets its own ID. A successful deployment produces a new version; a failed deployment produces no version but remains as a record of what was attempted and why it failed. A rollback is a deployment that re-releases an existing version without building a new one.

A deployment and the version it produces are distinct objects: the deployment is the action, and the version is the resulting artifact.

Disk​

Persistent storage attached to your application. Miren disks survive restarts and redeployments, making them suitable for databases and stateful workloads. See Persistent Storage.

Distributed Runner​

An additional machine that joins a cluster to host sandboxes, expanding capacity beyond the coordinator. A runner joins with miren runner join, runs stateless workloads scheduled to it, and reports health back to the coordinator, but holds no cluster state of its own. See Distributed Runners.

Ephemeral Version​

A labeled, time-boxed preview build of your app that runs alongside the active version on its own subdomain. Ephemeral versions don't affect production traffic and are deleted automatically when their TTL expires. Used for pull request previews. See Pull Request Environments.

Identity Provider​

An OIDC-compliant authentication service (e.g., Google, GitHub, Okta) registered with your cluster. Identity providers are used for route protection (SSO in front of your app) and OIDC bindings (CI/CD deployment without stored secrets). Configured with miren auth provider add.

Instance​

A single running copy of a service. Each instance runs in its own sandbox. The number of instances is controlled by the service's concurrency configuration and managed by the sandbox pool.

Label​

A DNS-compliant name assigned to an ephemeral version (e.g., pr-123). The label becomes the subdomain prefix for accessing the preview: <label>.<your-app-host>.

Miren Cloud​

A central control plane that connects and manages your Miren clusters. Provides team management, access control, and multi-environment workflows. See Miren Cloud.

Miren Runtime​

The core container orchestration system that powers Miren. Built on containerd, it handles building, deploying, and running your applications in isolated sandboxes.

Miren Runtime Client​

The miren CLI tool used to interact with your cluster. Manages apps, deployments, routes, and cluster configuration.

Miren Server​

The background service that runs on your cluster and manages applications, sandboxes, and networking. Installed as a systemd service via miren server install.

Node Port​

A port exposed directly on the host machine for non-HTTP services like game servers, IRC, or custom TCP/UDP protocols. Unlike HTTP traffic (which is routed automatically through Miren's ingress layer), node ports give external clients a direct host:port to connect to. Configured with port_type = "tcp" in app.toml. See Traffic Routing.

OIDC Binding​

A configuration that links an app to an identity provider with a subject pattern, enabling CI/CD systems to deploy using short-lived OIDC tokens instead of stored secrets. For example, a binding can authorize GitHub Actions workflows from a specific repository to deploy a specific app. See CI/CD Deployment.

Onbuild​

Commands defined in the [build] section of app.toml that run inside the build container after the main build steps. Used for tasks like asset compilation (npm run build) or pruning dev dependencies. Equivalent to Dockerfile ONBUILD instructions but configured declaratively.

Procfile​

A simple file format for defining services in your app. Each line maps a service name to a command (e.g., web: node server.js). For more advanced configuration (scaling, disks, images), use app.toml instead.

Route​

Maps a hostname to an application. Routes determine how HTTP traffic reaches your apps. Your first app gets a default route automatically. See Traffic Routing.

Rollback​

A type of deployment that re-releases a previously built version instead of building a new one. Because the container image already exists, a rollback skips the build step and re-releases the target version as-is.

Route Protection​

Authentication at the routing layer using an identity provider. Unauthenticated requests are redirected to an OIDC provider for login. After authentication, JWT claims are injected as HTTP headers (e.g., X-User-Email) before the request reaches your app — no in-app auth code required. See Protecting Routes.

Sandbox​

An isolated execution environment where your app runs. Sandboxes are Linux containers managed by containerd, isolated using kernel namespaces and cgroups, and each has its own network namespace by default.

Sandbox Pool​

The controller that manages the set of instances for a service within a version. The pool tracks desired, current, and ready instance counts and reconciles them based on the service's concurrency configuration. Visible via miren sandbox-pool list.

Scale to Zero​

Miren's ability to scale a service down to zero instances when there is no traffic. The next incoming request triggers a cold start to create a new sandbox. Enabled by default for auto-scaled services. See Application Scaling.

Service​

A named process within an app. An app can have multiple services, each with its own command, image, port, and scaling configuration. Common services include web (HTTP server), worker (background jobs), and database services like postgres. See Services.

TLS Certificate​

An SSL/TLS certificate that Miren provisions automatically from Let's Encrypt when you set a route. Certificates are obtained via ACME HTTP-01 or DNS-01 challenges, cached on disk, and renewed automatically. See TLS Certificates.

TTL​

Time to live — the expiration timer for an ephemeral version. After the TTL elapses, the ephemeral version is automatically deleted. Defaults to 24 hours and can be overridden with --ttl on deploy.

Version​

A unique identifier for a specific build of your app (e.g., myapp-vCVkjR6u7744AsMebwMjGU). Each successful deployment creates a new version, which tracks the container image, git commit, and configuration. Previous versions can be rolled back to without rebuilding — see rollback.

WAF​

Web Application Firewall — per-route request filtering using the OWASP Core Rule Set. Inspects incoming HTTP requests for common attacks like SQL injection, XSS, and path traversal. Configured per route with a paranoia level (1–4) controlling strictness. See WAF.

Wildcard Route​

A route that matches all subdomains of a domain using a * prefix (e.g., *.myapp.example.com). Useful for multi-tenant apps or custom subdomain routing. Exact routes take priority over wildcards when both match. See Traffic Routing.