Kubernetes operator
Install with Helm, then declare sources, stores, schedules, and restores as Kubernetes resources.
Learn moreResilience as Code
Backup is no longer a side process.
Drive it from the tools that run your platform.
Each team protects its data with its own tools. Declare stores, sources, and schedules in code, review them like any other change, and let the Control Plane run them across the estate.
The problem
Backup drifts when it lives outside the platform.
Infrastructure, deployments, and access are all code now. Backup is often the last thing still configured by hand.
Configured after the fact
Backups set up in a console once a service is live drift from what is actually deployed. New services ship unprotected.
One team as a bottleneck
Every new database or bucket waits on a ticket to the backup team, so protection lags behind delivery.
No review, no history
Retention and schedules changed by hand skip code review. Nobody can say who changed what, or why.
How it works
In code, or from the console.
Platform teams declare. Operations teams click. The Control Plane runs the same stores, sources, and schedules either way.
-
01 · In code
Kubernetes operator
CRDs for Source, Store, and Destination, plus ScheduleBackup, ScheduleCheck, ScheduleSync, and Restore. Protection is declared in the cluster, next to the app.
-
02 · In code
Terraform & Ansible
A Terraform provider and an Ansible collection for stores, connectors, schedules, inventories, organizations, and access, reviewed like the rest of your infrastructure.
-
03 · In code
API keys
Application users with their own API keys and an API Automation role, for CI/CD pipelines and your own tooling.
-
04 · From the console
Web console
For operations teams: policies, monitoring, and restores in a few clicks, no code required.
A ScheduleBackup resource, applied with kubectl or your GitOps tool.
apiVersion: task.plakar.io/v1alpha1 kind: ScheduleBackup metadata: name: nightly-database-backup spec: periodicity: 86400 source: name: production-database store: name: production-s3
The same schedule with the plakarkorp/plakar provider.
resource "plakar_schedule" "nightly" { name = "Nightly database backup" type = "backup" origin_id = data.plakar_connector.db.id target_id = plakar_store.offsite.id rule { periodicity = 86400 } }
What you get
Every tool your platform already speaks.
Terraform provider
Stores, connectors, schedules, inventories, organizations, members, and grants.
Learn moreAnsible collection
Sixteen modules, from backup, restore, and sync to inventories and grants. Works with Red Hat AAP.
Learn morePolicies scoped by tag
Tag connectors with an environment and data class in code, and matching SLA policies pick them up automatically.
Learn moreConfiguration bundles
Defaults applied by organization or inventory, scoped by environment, resource class, and tag.
Learn moreScoped API keys
Application users with keys bound to one organization and an API Automation role for CI/CD.
Learn more“We manage everything as code, with AI across our development workflow, so we wanted resilience orchestrated the same way, on our own schedule.”
Pierrick Gicquelais
Lead Infrastructure & AI Platform
More use cases
One Control Plane, many ways to stay resilient.
Ransomware recovery
Encrypted, tamper-evident snapshots and a copy kept out of the attacker's reach.
Learn moreStrategic autonomy
An independent, encrypted copy on infrastructure you choose, with keys you hold.
Learn morePosture management
Discover resources, apply SLA policies, and see what is covered.
Learn moreGet started
Put your backup posture in Git.
Start on the free plan, or see it running with your stack in a live demo.
See how it fits together on the Control Plane page.
Section:
Version:
Searching...
No results found.
Start typing to search.
ESC
close