If you've made it here, it means you've likely completed the onboarding guide, successfully connected your application with Permit, and checked for permissions. Perhaps you've even delved into the basic/SaaS deployment options and are now intrigued by the idea of exploring an on-premise deployment.
Why would you need to deploy Permit.io on-premise?
Ideally you won't - and for most, if not all cases, the hybrid nature of Permit.io SaaS would enable you to use the service without any security, compliance, stability, availability hurdles. The cases where you'd still need an on-prem deployment are situations where your network is air-gapped (i.e. not connected to the internet at all), or where your compliance / security require on-premise by default (probably as part fo legacy policies), for those cases and anything else where it is your preference we are happy to provide the on-prem options.
On-premise deployment types
Let's talk about the various ways you can go about deploying Permit as part of your on-premise network. There are two types of on-premise deployments of Permit.io:
In a full on-premise deployment we'd provide the entire Permit.io setup as can be seen in the diagram below, as Kubernetes helm charts. This is of course the most expansive and labor intensive (devops and IT work) option.
In a light (aka partial) on-premise deployment - you continue to use the management interfaces in the cloud, and only deploy the administration components (primarily the OPAL server) on the local network. You then sync the downloaded state from the cloud git repository (Which you own) to the local git-repository; which the local OPAL-server would track. This flow of course allows you to filter, test, benchmark, review, and otherwise control any configuration and policy before it is loaded into the local git, and into your on-premise Permit.io system. The light on-prem option is by nature less expansive and less labor intensive than the full-no-prem options; resting in a balance point between full on-prem and hybrid SaaS.