at Scale
If you've reached this point, it's likely that you have successfully completed the onboarding guide, connected your application with Permit, and checked for permissions. Now, let's dive into the different deployment options available for incorporating Permit into your app at scale.
Deployable components
As you can see in the diagram below there a few key components that are part of every deployment, the only components you have to have are your App with an enforcement point; but some additional can be added to enjoy more features.
Component | Must ? | Reason |
---|---|---|
Your App | MUST | Otherwise what's the point? 😜😅 |
Policy Enforcement Point(PEP) | MUST | Otherwise what's the point? 😜😅 These can be Frontend code, Backend code, reverse proxy, or API Gateway |
Policy Decision Point (PDP) | OPTIONAL | Permit can host it for you. But it's recommended to use locally in production. |
Policy Git repository | OPTIONAL | Permit can host it for you. You'd host the repo is you want to use the Gitops / manually add policy as code, |
PDP Deployments
The PDP provides fast, zero-latency, scalable, secure policy decision making for your software.
The PDP opens an outgoing HTTPS websocket connection to Permit.io, which is used to subscribe to updates. The updates happen asynchronously in the background - they are not part of the authorization query critical path.
Like all Permit customer deployed components, the Permit PDP is open-source.
We often refer to the cloud-hosted PDP option as full-SaaS or cloud-PDP, and the local PDP option as hybrid SaaS. Hybrid SaaS is the default recommended layout.
Cloud PDP
By default when you first try out Permit, you start with the "cloud" PDP we host for you at "https://cloudpdp.api.permit.io" . This is a great way to start, and can be scalable for some use cases; but we do recommend running with your own local PDP in production or in any performance critical deployments.
Custom cloud PDP deployments (e.g. different AWS regions, different clouds, different network setups, different SSL / TLS configurations) are available to enterprise tier customers. Please reach out to us at support@permit.io, or schedule a call via this link: https://calendly.com/permitio/
Sidecar
The most common way to deploy the PDP locally is as a sidecar (or daemon-set) - i.e. you run one PDP container next to each of your own microservices. This is also the easiest way to scale your authorization layer with your application.
In this layout you of course enjoy zero-latency between your application and the PDP - this together with improved stability and security (no dependency on other clouds) is the main reason to use a local PDP compared to a cloud pdp.