OpenStack Snapshot Scheduler
| License | FOSS problems | Maintenance | SSO | Users | Tested |
|---|---|---|---|---|---|
| Custom (in-house) | — | Not built yet | — | Unlimited | ❌ |
Description
Not an existing product — a small custom Docker image, still to be built: the OpenStack CLI plus cron, running scoped openstack volume snapshot create/prune commands on a schedule, with credentials injected as Coolify-managed environment variables rather than a file sitting on the host. Copy-on-write, so near-instant regardless of volume size.
Features
- OpenStack CLI + scheduling, bundled — nothing off-the-shelf combines the two the way Backrest bundles restic and scheduling together; this fills that specific gap.
- Copy-on-write snapshots — operates at the Cinder block-storage layer rather than copying data, so creation is near-instant regardless of volume size.
- Minimally-scoped credential — designed to run under a Keystone
access-rules-restricted application credential, limited to only snapshot actions, not the main provisioning credential that can touch everything.
Usage patterns
- Coolify-deployed scheduled service — keeps it consistent with how every other scheduled job on this stack is handled, rather than a bare host
cronentry nobody remembers exists. - Manual, deliberate restore — using the normal full-access credential, not the scoped one: create a new volume from a snapshot and reattach it.
License and governance
In-house and unpublished — no external license applies. That's also the actual risk, not a benefit: it's one more thing only this project understands and has to keep working, with no upstream to inherit fixes from.
Conclusion
Why you would — fills a specific gap nothing off-the-shelf covers: OpenStack CLI access combined with scheduling, the way Backrest bundles restic and scheduling together. Running it as a Coolify-deployed service keeps it consistent with every other scheduled job here.
Why you wouldn't — unbuilt and unverified: the Dockerfile/compose don't exist yet, and the minimally-scoped credential it depends on is untested against Infomaniak's specific deployment. Every custom tool is one more thing only this project understands; worth confirming no newer turnkey option has appeared to replace the need for it before actually writing this. See Draft for the actual, unbuilt setup plan.