Relic

Relic injects secrets as standard environment variables via `relic run` in GitHub Actions. The chunks do not mention support for JSON blob format output. Multiple sources confirm: 'Just use relic run to inject secrets as environment variables into any process' [5] and the GitHub Actions example shows `relic run -e production -- npm run deploy` with secrets injected as env vars [2]. No documentation describes JSON formatting options for secret injection.

Add explicit documentation on whether Relic supports alternative secret output formats (JSON blob, single env var with JSON, etc.) for CI/CD integrations, or clearly state that only flat environment variable injection is supported.

Where we looked: /guides/ci-cd-integration, relic.so, /changelog

Relic supports manual key rotation in specific scenarios, but does not document automatic scheduled rotation. Manual rotation can be triggered when revoking a collaborator's access with rotation enabled: this generates a new AES-256 project key, re-encrypts all secrets, and re-wraps for remaining collaborators. Service accounts are automatically re-wrapped when project keys are rotated. However, there is no documented automatic rotation schedule (e.g., 'every 90 days'), nor is there documented support for on-demand manual rotation outside of the revocation flow.

Add explicit documentation on: (1) whether Relic automatically rotates encryption keys on a schedule, and if so, what that schedule is; (2) whether users can manually trigger key rotation on demand without revoking a collaborator; (3) clarify the 'Key rotation with service accounts' section that appears in the table of contents but lacks body content in the retrieved chunks.

Where we looked: /configuration/security, /guides/service-accounts

The chunks mention that 'Sharing requires the Pro plan' (chunk [12]), indicating there is a free tier and a paid Pro plan, but the specific seat limit on the free tier and the exact headcount threshold forcing a paid plan are not stated. The Enterprise plan offers 'Unlimited projects and team members' (chunk [5]).

Add a dedicated pricing page that clearly states free tier seat limits and the specific user count or feature threshold that triggers a Pro plan requirement.

Where we looked: /guides/project-collaboration, /enterprise

Relic does not appear to offer IP range or VPC endpoint restrictions for secret access based on the available documentation. The access controls mentioned are: (1) email/domain-based sharing for project collaboration, where you invite teammates by email and they get access to the project [19]; (2) API key scoping to specific projects with permissions like `secrets.read` and `user.keys.read` [3]; (3) service accounts with scoped machine identity for CI/CD [12]. The Enterprise offering mentions 'isolated data' and 'network policies' in the context of self-hosted or hybrid deployments [16], but no specific IP allowlisting or VPC endpoint features are documented for the cloud/SaaS product.

Add explicit documentation about network-level access controls: either confirm IP allowlisting/VPC endpoints are available (with configuration steps) or explicitly state they are not supported and recommend Enterprise self-hosted for such requirements.

Where we looked: /configuration/security, /guides/ci-cd-integration, /enterprise, /guides/project-collaboration, /configuration/security

The site does not specify exact retention periods (30 days, 90 days, etc.) for audit logs. The Privacy Policy states that audit logs 'may be retained for a reasonable period for security and compliance purposes' and are anonymized upon account deletion (user ID replaced with anonymous identifier). The Audit Logs documentation confirms logs are append-only and cannot be deleted or modified, but does not state a retention duration or whether customers must export logs themselves.

Add explicit retention period (e.g., '90 days') to the Audit Logs documentation, and clarify whether customers can export logs before purging or if Relic provides automated export/archival options.

Where we looked: /configuration/audit-logs, /privacy-policy

The JWT token has a 15-minute lifetime and refreshes automatically, but this appears to be a technical implementation detail of the CLI's authentication flow rather than a configurable admin policy for idle session timeouts. The chunks do not mention whether admins can configure custom session timeout windows (such as 15 minutes) for sensitive projects, nor do they describe a default idle session timeout policy that security teams could enforce organization-wide.

Add documentation on whether session timeouts are configurable at the project or organization level, and if admins can set custom idle timeout policies for sensitive projects.

Where we looked: /configuration/session, /configuration/session, /configuration/session, /troubleshooting

There is a hard cap of 5 active service accounts per project. However, the chunks do not state whether service accounts count against user seat limits.

Add explicit clarification on whether service accounts/machine identities consume user seat quotas, as this is a common buyer concern for microservice architectures.

Where we looked: /guides/service-accounts