Feature Request: Configurable Retention Policy for Audit Logs and Secret Access Events

[pramudyawibowo]

Is your feature request related to a problem?

In self-hosted environments, secret access events and audit logs can grow very quickly due to application workloads, CI/CD pipelines, and Kubernetes integrations.

Currently, there is no configurable retention policy for these events. As a result:

• PostgreSQL database size continuously increases over time
• Audit log queries may become slower as event volume grows
• Administrators must manually manage old records
• Storage requirements increase even when historical events are no longer needed

For organizations running Phase at scale, this creates unnecessary operational overhead.

Describe the solution you'd like

Add configurable retention policies for audit logs and secret-related events.

Examples:

AUDIT_LOG_RETENTION_DAYS=365
SECRET_READ_EVENT_RETENTION_DAYS=90
SECRET_UPDATE_EVENT_RETENTION_DAYS=365
SECRET_DELETE_EVENT_RETENTION_DAYS=3650
API_ACCESS_LOG_RETENTION_DAYS=30

Alternatively, expose the configuration in the admin UI:

Settings
└── Audit Logs
    └── Retention Policies

Desired behavior:

• Automatic cleanup of expired events
• Different retention periods per event type
• Scheduled cleanup job (daily or configurable)
• Option to disable retention completely
• Visibility into current log/event storage usage

Describe alternatives you've considered

Currently, the only workaround is to manually delete old records directly from PostgreSQL or implement custom database maintenance jobs outside of Phase.

While this works, it has several drawbacks:

• Additional operational complexity
• Risk of accidentally removing important audit data
• Different organizations must build and maintain their own cleanup processes
• No centralized retention management within Phase

Additional context

This feature would be particularly useful for self-hosted deployments with:

• High-frequency secret access
• Kubernetes workloads
• CI/CD pipelines
• Large development teams

A built-in retention mechanism would help keep the database size manageable while still allowing organizations to meet their own compliance and audit requirements.

[rohan-chaturvedi]

@pramudyawibowo thanks a lot for the detailed feature request! We are actively working on improving the maintenance and administration of self hosted instances including log retention, so this helps a lot.

In the mean time, you may find this management command helpful to safely delete secret read logs for your instance, as these tend to be the primary source of db bloat over time: https://docs.phase.dev/self-hosting/maintenance#purging-old-audit-logs