Maintenance and Recovery

Run maintenance tasks inside Team Server’s container/environment with its configuration and database credentials. These are privileged local tasks.

Verify the Service

Check public readiness:

curl -f https://team-server.example.com/_readiness

Check database access and report environment, version, and build locally:

endura task system_check

Run both checks after deployment, configuration changes, upgrades, and restores.

Required Scheduled Maintenance

Keep these jobs in scheduler.jobs:

Each configured CI/CD provider also needs <provider>_sync mode:pipelines trigger:scheduled and <provider>_sync mode:builds trigger:scheduled. The complete example and schedules are in Scheduler.

Pruning marks runs still running after 24 hours interrupted, then removes expired terminal runs and diagnostics.

Prune Historical Observations

data_prune deletes old builds, workloads, violations, or statistics. It retains active builds/workloads, pipelines, deployments, Sensors, policies, users, and integrations. It has no default schedule. Choose retention periods and preview before confirming:

endura task data_prune \
  resources:builds,workloads,violations older_than_days:90

endura task data_prune \
  resources:builds,workloads,violations older_than_days:90 confirm:true

Use one cutoff: positive older_than_days or RFC 3339 before. For observations, batches default to 500 per type (range 1–5,000); repeat preview/apply until complete. Statistics delete all matches. Violations use their own timestamps, even when their parent remains. See full arguments.

Before scheduling externally, record a representative preview, test restoration, and confirm resources/cutoff meet retention policy.

Back Up PostgreSQL

Use PostgreSQL tools compatible with the server major version. Keep credentials out of history and protect archives containing tenant data and integration credentials.

For backups containing encrypted credentials, separately preserve the then-active ENDURA_CREDENTIAL_ENCRYPTION_KEY and ENDURA_CREDENTIAL_ENCRYPTION_PREVIOUS_KEYS. Startup needs the current key; credentials cannot be recovered without the matching keyring.

Create a custom-format archive:

pg_dump \
  --dbname="$DATABASE_URL" \
  --format=custom \
  --no-owner \
  --file=team-server.dump

Verify that PostgreSQL can read the archive before relying on it:

pg_restore --list team-server.dump >/dev/null

Store the archive under your recovery/retention policy and test restoration; a successful dump alone is insufficient.

Restore PostgreSQL

Practice this procedure in an isolated environment before an incident:

1. Stop Team Server and prevent Runtime Sensors or other clients from writing to the target database.
2. Create or select the intended restore database and verify that its connection string cannot target production accidentally.
3. Restore the archive with a compatible PostgreSQL client.
4. If the backup came from a version that requires credential encryption, restore its matching keyring to the Team Server environment.
5. Start the same Team Server version that created the backup. Allow its normal migrations to complete before upgrading further.
6. Run system_check, verify /_readiness, then validate representative users, policies, integrations, recent observations, and Runtime Sensor connectivity. For a backup from a version that encrypts credentials, also confirm that startup reports credentials validated.

pg_restore \
  --dbname="$RESTORE_DATABASE_URL" \
  --clean \
  --if-exists \
  --no-owner \
  team-server.dump

--clean removes database objects represented by the archive before recreating them. Use it only with the explicitly verified restore target.

If the restored database contains plaintext integration credentials, keep its earlier Team Server version in place until a supported conversion is available. See Credential Encryption before upgrading.

Load Fixture Data

database_seed defaults to src/fixtures. refresh:true previews schema deletion/recreation; confirm:true applies it. The task is refused in production.

Team Server also rejects Loco’s destructive db down, db reset, db truncate, and db seed commands when the CLI explicitly selects --environment production.

endura task database_seed path:src/fixtures
endura task database_seed path:src/fixtures refresh:true
endura task database_seed path:src/fixtures refresh:true confirm:true

Use fixture data only with disposable development and test databases.