Skip to main content

Deployment Options

Choose how to deploy Permit.io: the default hybrid model, a full on-premise deployment, or a light on-premise deployment. This page is for teams that have completed the Quickstart, connected an application to Permit, and need to decide whether the hybrid model meets their network and compliance requirements.

Compare the deployment options

OptionControl planePolicy decision points (PDPs)Choose it whenOperational work
Hybrid (default)Permit's cloudYour networkYour PDPs can reach Permit's cloudLeast: you run PDPs only
Light on-premisePermit's cloud management interfaces, with policy administration (the OPAL server) in your networkYour networkYou want to review and test every policy change before it reaches your PDPsMedium
Full on-premiseYour networkYour networkYour network is air-gapped, or your security policy requires every component on-premiseMost: you run the entire Permit stack

Why you might need an on-premise deployment

Most teams don't need one. In the default hybrid deployment, PDPs run in your network and your data can stay there, while Permit runs the control plane.

You need an on-premise deployment in these cases:

  • Your network is air-gapped, with no internet connection.
  • Your security or compliance policy requires every component to run on-premise.

On-premise deployment types

Permit supports two on-premise deployment types.

Full on-premise

In a full on-premise deployment, you run the entire Permit.io stack in your own Kubernetes cluster, delivered as Helm charts. Full on-premise takes the most DevOps and IT work of the three options.

Full on-premise architecture: a Kubernetes deployment of the Permit app, embeddable UI, Permit API, and OPAL server, a Git policy store, and a PDP (PDP API, OPA, and OPAL client) next to your service in your network

Light on-premise

In a light (partial) on-premise deployment, you keep using the Permit management interfaces in the cloud. You run the policy administration components, primarily the Open Policy Administration Layer (OPAL) server, in your network:

  1. Permit writes policy state to a cloud Git repository that you own.
  2. You sync that repository to a local Git repository.
  3. The local OPAL server tracks the local repository and pushes policy to your on-premise PDPs.

Every change passes through your own repository, so you can filter, test, benchmark, and review configuration and policy before it reaches your PDPs. Light on-premise takes less work than full on-premise and more work than hybrid.

Light on-premise architecture: Permit Cloud writes generated policy and configuration to a cloud Git policy store, a controlled manual sync copies it to a local Git policy store, and an on-premise OPAL server pushes it to PDPs in your network

Get started with an on-premise deployment