The Purge Settings define the configuration parameters to manage the purging of FlexDeploy execution data from the database repository, purging of the artifacts stored in the artifacts repository, and purging of backups. These settings should be carefully adjusted to meet your data retention requirements for audit, and at the same time purging data which is no longer required to ensure a high performing system.

Property	Description	Default Value

Property	Description	Default Value
Purge Enabled	Indicates whether the purge process is enabled. Purge runs every 24 hours if enabled, beginning with a few minutes after server startup. If you have concerns with running purge at some specific milestone deployment event, you can disable the purge temporarily. KARL - note what is still purged.	false
Purge Time	Choose the hour of day when the purge will run. This will be in the server’s timezone.	4:00 AM
Keep Count	How many successfully-executed project versions to keep for each project/target regardless of Retention Days. This helps you keep a specific number of latest deployments so that you can revert back to previous versions if desired. If the target group, environment, or project are inactive, the keep count will not be used. If the target group is no longer associated to the environment, the keep count will not be used. All executions, build, or deploy to all targets of each project version are kept or purged together.	2
Keep Count Production	How many successfully-executed project versions to keep for each project/target that is associated to an environment with the Production flag checked regardless of Retention Days. This helps you keep a specific number of latest deployments to your production environments so that you can revert back to previous versions if desired. If the target group, environment, or project are inactive, the keep count will not be used. If the target group is no longer associated to the environment, the keep count will not be used. All executions, build, or deploy to all targets of each project version are kept or purged together.	3
Keep Pipeline Executions Count	How many pipeline executions to keep per release.	30
Retention Days For Executions	How many days to keep project executions. If you would like to retain one year worth of history for deployments, keep this value to 365 or higher and still control space usage by using lower value for `Retention Days Artifacts and Backups`. After the most recent execution of a project version is at least this many days old, every execution of the project version will be delete together if the project version is not kept by the keep counts. For example, all the execution rows of the project that have version 1.0.60 below will be deleted together, unless version 1.0.60 is one of the last Keep Count executed on a target, or one of the last Keep Count Production deployed to a production target, or it is kept because of a release snapshot in a release which is not completed. For package-based deployment, any package that contains one of the latest 2 versions of any file are always kept. Package-based keep count is not configurable. It is always 2. After this happens, the record of this execution will be gone from the project and all reports. FlexDeploy will forget that it ever existed. The audit trail is lost. All executions, build, or deploy to all targets of each project version are kept or purged together.	730
Retention Days for Artifacts and Backups	How many days to keep Artifacts and Backups, Execution Logs, and Steps. This should be less than or equal to the `Retention Days` parameter. Artifacts and Backups are always kept for executions that are not purged due to Keep criteria, so those are kept longer than this. Execution Logs and Steps may be purged from the `Retention Days of Logs and Steps` parameter. After this purge happens, the version cannot be deployed anymore, although it is still visible in the execution history. It still appears on reports. All executions, build, or deploy to all targets of each project version are kept or purged together. The project will look like this afterwards:	15
Retention Days for Execution Logs	After this many days, old project Logs and Steps are purged regardless of keep counts. Artifacts and Backups are not purged by this. The versions can still be deployed again, but the step details will be missing. This setting deletes data regardless of the versions that keep counts are keeping. This setting is not per project version, but per workflow execution, so older executions may have logs, steps, or variables, but newer ones would still have them. The execution will look like this afterwards. The plugin logs are blank. It is still able to be deployed or rolled back. It still appears on reports. @Since 8.0.0.7 / 9.0.0.0	730
Change History Purge Days	The Change History report will only show up to this many days. After that, the data will be gone, and you can’t get it back.	730
Webhook and Event Log Purge Days	Number of days to keep webhook and scheduled event messages and logs Before 9.0.0.0, it was set in code to 7. @Since 9.0.0.0	7
Custom Step/Gate Script Log Purge Days	Number of days to keep logs for custom step and gate scripts.	60

Purge Rules

Any workflow execution that is the last successful deployment to an environment is automatically excluded from the purge, unless the project, environment, or target group is inactive.
The KEEP related parameters override the DAYS parameters (e.g. if Retention Days is 1 day, anything which was deployed more than 1 day ago is still retained if necessary to satisfy the KEEP parameters).
The setting Retention Days of Logs and Steps is different from the other retention parameters because it will delete data for versions that KEEP counts are keeping.
The Retention Days are based on the first date found in this sequence:
- End time of the workflow execution
- Start time of the workflow execution
- Created time of the workflow execution
- Requested start time of the workflow request
- Created time of the workflow request.
Purged executions will not show up on any reports.
When artifacts have been purged, a red triangle will appear next to the project version indicating that the artifacts have been purged. These project version can no longer be deploy to any environment. To redeploy you would need to perform a new build using the same revision of the source code.