Yes, you can back up and restore resource instances and their access configurations in Permit.io. Here are your options: Platform-Level Backup For on-premises deployments, Permit.io provides database backup capabilities (1) :

# List available backups  
ls -la *backup*.{sql,yaml}  
  
# Restore database from backup  
kubectl exec -i -n permit-platform deployment/postgres -- psql -U permit -d permit < backup-20241201-143022.sql  
  
# Restore configuration  
cp values-backup-20241201-143022.yaml charts/permit-platform/values.yaml  
./scripts/install-permit-platform.sh # Re-apply configuration

PDP Offline Mode Backup The PDP (Policy Decision Point) automatically backs up both policy rules/code and data, which includes resource instances and access configurations (2) . This backup happens periodically and on graceful shutdown . The backup files are stored in

/app/backup

by default , and you can configure: •

PDP_OFFLINE_MODE_BACKUP_DIR

to set the backup directory •

PDP_OFFLINE_MODE_POLICY_BACKUP_FILENAME

for the policy store backup file name •

OPAL_STORE_BACKUP_INTERVAL

to control backup frequency (default: 1m) Programmatic Backup via SDKs You can programmatically export and reimport resource instances using the SDKs: Python SDK (3) :

async def list(
    self,
    page: int = 1,
    per_page: int = 100,
    tenant_key: Optional[str] = None,
    resource_key: Optional[str] = None,
    detailed_key: Optional[bool] = None,
    search_key: Optional[str] = None,
) -> List[ResourceInstanceRead]:

async def bulk_create(self, resource_instances: List[ResourceInstanceCreate]) -> ResourceInstanceCreateBulkOperationResult:

async def bulk_delete(self, resource_instances: List[str]) -> ResourceInstanceDeleteBulkOperationResult:

You can use these methods to list all instances, save them, and later recreate them in bulk after deleting resources. The same pattern is available in other SDKs - Java (4) , Node.js (5) , Go (6) , and Ruby (7) all provide list, create, and bulk operations for resource instances.

To learn more, see the sources I considered: [[1] Management Guide](https://docs.permit.io/how-to/deploy/on-prem/management) [[2] Deploy Permit to Production](https://docs.permit.io/how-to/deploy/deploy-to-production) [[3] https://github.com/permitio/permit-python/blob/main/permit/api](https://github.com/permitio/permit-python/blob/main/permit/api) [[4] https://github.com/permitio/permit-java/blob/master/src/main/java/io/permit/sdk/api](https://github.com/permitio/permit-java/blob/master/src/main/java/io/permit/sdk/api) [[5] https://github.com/permitio/permit-node/blob/main/src/api](https://github.com/permitio/permit-node/blob/main/src/api) [[6] https://github.com/permitio/permit-golang/blob/master/pkg/api](https://github.com/permitio/permit-golang/blob/master/pkg/api) [[7] permitio/permit-ruby/lib/openapi_client/api/resource_instances_api.rb](https://github.com/permitio/permit-ruby/blob/main/lib/openapi_client/api/resource_instances_api.rb)

Great addition! Let me expand on that approach with the specific details. When you expose OPA within the PDP, you can directly access the

/v1/data

endpoint to retrieve all the authorization data that's been synced to your PDP (1) . This includes users, roles, resource instances, and their relationships. The PDP runs OPA as part of its architecture (2) , and you can save this data for backup purposes. When the PDP syncs data from Permit's control plane, it stores it in OPA's data store, which you can then export. For restoring to a new environment, you'd use the Permit API to recreate the resources. The API supports managing users, tenants, and their attributes (3) :

curl -H "Authorization: Bearer <API Key>" <https://api.permit.io/v2/facts/{projectKey}/{environmentKey}/users>

curl -H "Authorization: Bearer <API Key>" <https://api.permit.io/v2/facts/{projectKey}/{environmentKey}/tenants>

You can also load custom data through multiple methods (4) : • Via the UI by editing user attributes • Via the

permit.check()

function with dynamic attributes • Via the API for user and resource attributes • Via OPAL using the Scope Config API The schema adaptation you mentioned is important since the data structure in OPA might differ from what the Permit API expects for imports, especially for resource relationships and custom attributes.

To learn more, see the sources I considered: [[1] Concepts / Glossary](https://docs.permit.io/overview/glossary) [[2] How does Permit.io work?](https://docs.permit.io/overview/how-does-it-work) [[3] Using the API](https://docs.permit.io/api/api-with-cli) [[4] Load Custom Data](https://docs.permit.io/how-to/manage-data/loading-data)