Security and Disaster Recovery
This article summarizes how platformOS protects your applications and data, and how it recovers from failures. Policies, audit reports and detailed security documentation are available in the platformOS Trust Center.
Hosting
platformOS runs on managed Kubernetes. By default, we recommend Oracle Cloud Infrastructure (OCI), but platformOS can be deployed on any major cloud provider, such as Amazon Web Services (AWS), Google Cloud or Microsoft Azure, for example when a client has contractual obligations to use a specific provider.
Applications run either on the shared platform or on a dedicated private stack, where the cluster, network, databases, search, secrets store and file storage are reserved for a single client. Both are multi-tenant: a private stack can host any number of the client's instances, and on either platform each instance is isolated from the others at the application level.
Network and traffic
- On dedicated private stacks, public traffic passes through Cloudflare, which provides DNS, TLS and DDoS mitigation. A web application firewall can be enabled per stack.
- Traffic is distributed by the load balancing service of the chosen cloud provider to the ingress layer, which terminates TLS, redirects HTTP to HTTPS, sets HSTS and other security headers, and applies rate limits.
- Databases, cache and search have no public endpoints and are reachable only from inside the cluster.
- Administrative access to the infrastructure requires an individually named identity with multi-factor authentication.
Data protection
- In transit: all traffic is served over HTTPS.
- At rest: disks, databases, file storage and backups are encrypted by the infrastructure provider. Sensitive values, such as constants and integration credentials, are additionally encrypted at the application level.
- Passwords: stored as bcrypt hashes. Applications can enable two-factor authentication with time-based one-time passwords (TOTP) for their users.
- File uploads: uploads use signed, short-lived authorizations that confine each file to the instance that issued it. Allowed file types and maximum file sizes are enforced on upload, and private files are only accessible through signed URLs that expire.
Backups
platformOS operates its own PostgreSQL clusters and backs up the platform database to three independent locations:
| Copy | Schedule | Default retention |
|---|---|---|
| Inside the cluster | Weekly full backup and continuous transaction log archiving | 7 weekly backups |
| Off-cluster object storage | Weekly full backup, daily incremental backups and continuous transaction log archiving | 8 weekly backups |
| A second cloud provider | Daily database dump | 30 days, write-protected |
Continuous transaction log archiving allows the database to be restored to any point in time within the retention window, with at most about one minute of data loss. Backup jobs are monitored, and a failed or overdue backup raises an alert to the on-call team. Search indexes are rebuilt from the database and are not backed up separately. Backup schedules and retention for dedicated private stacks can be agreed per engagement.
Learn more:
- Data Backup and Removal: How deleted data is backed up and when it is removed permanently.
- Data Export: Export your data using pos-cli or the export API, for example for off-site backups of your choosing.
- GDPR Compliance in platformOS: How platformOS helps your project comply with privacy regulations.
High availability
- The database runs as a cluster with a primary instance, read replicas and automatic failover.
- Application servers scale automatically with load.
- The entire infrastructure is defined as code and can be rebuilt from version control.
Disaster recovery
The Disaster Recovery Plan (DRP) defines the following recovery objectives:
| Failure | Recovery time objective (RTO) | Recovery point objective (RPO) |
|---|---|---|
| Database primary failure | About 1 minute (automatic failover) | About 1 minute |
| Data corruption or an erroneous change | Under 30 minutes (point-in-time restore) | About 1 minute |
| Loss of the cluster | 24 hours | About 1 minute |
| Loss of the cloud region | 24 hours | Up to 24 hours |
Restoration testing
Backup restoration is tested quarterly, and after any change to the backup setup. Each test:
- Restores the off-cluster backup into a new, isolated database cluster, without affecting production.
- Recovers it to a defined point in time.
- Compares every table row by row against a snapshot of production taken for that point.
- Checks data integrity, indexes and schema, and confirms the restored data is accessible through the application.
Recent tests restored the production database to the requested point in time well within the recovery time objective, with no data loss and no differences from production.
Current service status is published at status.platformos.dev.