Skip to content

CONCEPT Cited by 1 source

Virtual OPA instance per application

Definition

Inside one host process (typically an ingress proxy), run many logically isolated OPA instances, one per application, sharing the process's runtime but each with its own policy bundle, labels, decision log, and status-report stream. The instances are virtual — they are Go-level data structures, not separate processes, not separate containers.

Why this shape is load-bearing

  • Memory reuse. A single process runtime serves N applications; per-app overhead is a structured in-memory sub-instance, not a full process.
  • Blast-radius isolation between applications. Each virtual instance has its own bundle + labels, so a policy change for app A never affects app B. Crashes that are contained to OPA evaluation still share the host process fate; this isolation is logical, not hardware-level.
  • Grace period against route churn. Routes come and go frequently (deploys, canaries, A/B tests); immediately destroying + recreating an OPA instance on every route-table update would thrash bundle loading + status-log bootstrap. A grace period keeps unused instances warm until GC sweeps them.
  • Composable with embedded OPA. The embedding decision gives you the runtime; virtual instancing lets you multiplex tenants across it.

The shape inside the proxy

For every application ID referenced in at least one route on a Skipper replica, one virtual OPA instance is instantiated. The instance:

  • Loads the bundle named after the application ID (typically from S3).
  • Labels all its emitted spans + decision logs with the application identifier.
  • Periodically reports status back to the control plane (Styra DAS) via the OPA status plugin.
  • Streams decision logs to the control plane via the decision-log plugin.

When the last route referencing it is removed, the instance enters a grace period before GC; if the application is re-added during the grace window, the warm instance is reused.

Contrast with one-process-per-app

The vanilla Envoy OPA plugin pattern is typically one OPA process per application, with process-level isolation. Virtual instancing trades hardware-level isolation for lower per-app cost + shorter warm-up time + shared ingress lifecycle.

Seen in

  • sources/2024-12-05-zalando-open-policy-agent-in-skipper-ingress — Zalando's deployment model inside Skipper. "Inside Skipper, we create one virtual OPA instance per application that is referenced in at least one of the routes. This allows us to re-use memory and also provides a buffer against high-frequency route changes by having a grace period for garbage collection." Differentiated from the Envoy OPA plugin in the same post: "Multiple Virtual OPA Instances in one Deployment: This allows multiple virtual OPA instances to coexist within a single Skipper process deployment, providing low latency without a network hop and also no extra OPA deployment required. In a vanilla OPA deployment, you typically run one OPA process per application."
Last updated · 550 distilled / 1,221 read