Native database tooling
Pier shells out to the right backup tool per engine: pg_dump for PostgreSQL, mysqldump for MySQL/MariaDB, mongodump for MongoDB, redis-cli BGSAVE for Redis. No third-party Docker images, no agent containers.
Scheduled database & volume backups to S3
Native pg_dump, mysqldump, mongodump and redis BGSAVE. Cron-scheduled, encrypted in transit, shipped to any S3-compatible bucket — including Bunny.net Storage Zones — with retention policies.
Cron-scheduled per database
Each database can have its own cron expression and retention policy. Schedules apply at the cluster level by default and can be overridden for individual databases.
S3-compatible destinations
AWS S3, Backblaze B2, Cloudflare R2, Wasabi, MinIO, Bunny.net Storage Zones — anything that speaks the S3 API. Credentials are encrypted at rest with AES-256-GCM.
Status tracking and event log
Backup jobs flow through pending → running → completed / failed states; failed jobs trigger the backup_failed alert. Every run is recorded so you can audit what was actually shipped.
Common questions
Are backups consistent on a live database?
Pier uses each engine's native dump tool, which produces a consistent point-in-time snapshot for PostgreSQL and MySQL. For applications writing during the dump, Pier surfaces a UI warning and offers an option to stop the container during the backup window for stricter consistency.
Can I restore?
Restore endpoints are stubbed in v1.0 with a one-click UI on the roadmap. In the meantime you can pull the dump from the bucket and restore manually with the engine's standard tooling.
Are volume backups supported?
Volume snapshot UI (list volumes, sizes, backup/restore) is the next planned PR. Database backups are shipping today; volume backups expand the same scheduling and storage system to arbitrary Docker volumes.
Related
Ready to deploy?
One command installs Pier on any Ubuntu or Debian VPS.
curl -fsSL https://pier.sh/install | sudo bash