Feature request: Built-in backup, export, import and restore for self-hosted instances

[Coke1120]

Is your feature request related to a problem?

Yes.

Phase currently supports exporting secrets from individual environments, but self-hosted administrators do not appear to have a built-in way to back up or export an entire Phase installation.

For disaster recovery or migration, administrators currently need to manually back up the PostgreSQL database, Docker volumes, configuration files and encryption-related environment variables.

This is error-prone and may not be obvious to users who expect a self-hosted secrets management platform to provide a documented and supported backup and restore workflow.

Environment-level .env export is useful, but it does not preserve the complete Phase structure and metadata, such as:

• Organizations
• Applications
• Environments
• Folders
• Secret version history
• Users and memberships
• Roles and permissions
• Service accounts
• Integrations and secret sync configurations
• Audit logs
• Encryption metadata and other required instance configuration

Describe the solution you'd like

It would be useful for Phase to provide built-in backup, export, import and restore functionality for self-hosted deployments.

This could be implemented at two levels.

1. Application export and import

Allow an administrator or authorized user to export an application into a portable encrypted archive.

The archive could optionally include:

• Application metadata
• Environments
• Folders
• Secret names and values
• Secret version history
• Tags
• Service accounts
• Access roles
• Integration and sync configuration

The exported application should then be importable into:

• The same Phase instance
• Another self-hosted Phase instance
• A newly created application

Possible UI actions:

• Export application
• Import application
• Clone application
• Export organization

2. Full self-hosted instance backup and restore

Provide an administrator-level backup command or management interface that creates a complete, restorable backup of the Phase instance.

For example:

phase-admin backup --output phase-backup.tar.enc
phase-admin restore phase-backup.tar.enc

The backup should include or clearly identify all required components:

• PostgreSQL data
• Organizations and users
• Applications and environments
• Secrets and version history
• Roles and permissions
• Service accounts
• Integrations
• Audit logs
• Encryption metadata
• Instance configuration required for decryption
• Phase version and database schema version

The backup archive should be encrypted and protected with a password or administrator-provided key.

Suggested additional features

• Backup integrity verification
• Backup manifest
• Phase version recorded in the archive
• Database schema version recorded in the archive
• Dry-run restore
• Restore compatibility checks
• Scheduled automatic backups
• Configurable retention policy
• Backup to local storage, S3-compatible storage or other object storage
• Clear documentation for Docker Compose and Kubernetes deployments
• Option to exclude audit logs or secret history to reduce backup size

Describe alternatives you've considered

Manual PostgreSQL backup

Administrators can use pg_dump and manually preserve the Phase .env and Docker Compose configuration.

However, this requires detailed knowledge of which encryption keys and configuration values are required for a successful restore.

It is also easy to create a database backup that cannot be decrypted after migration because a required instance secret was not preserved.

Environment-level secret export

Secrets can be exported environment by environment using the Phase CLI or Console.

However, this does not preserve the complete application or organization structure, permissions, service accounts, integrations, audit logs or secret history.

It also requires each environment to be recreated manually.

VPS or Docker volume snapshots

Infrastructure-level snapshots can provide some protection, but they are not portable, application-aware or guaranteed to be consistent while PostgreSQL is running.

They also do not provide a supported migration path between Phase installations.

Additional context

For a self-hosted secrets management platform, backup and restore are important operational and security requirements.

A supported backup format would help users:

• Recover from server or storage failure
• Migrate to a new VPS or Kubernetes cluster
• Test upgrades safely
• Move between Phase installations
• Meet internal disaster recovery requirements
• Verify that backups are actually restorable

Even if a full UI implementation is not currently planned, an official backup and restore command, script or documented reference implementation would already be very helpful.