Hey guys, is there a limit on the number of enroll secrets we can add to fleet?

Hi @Sudershan! 👋 Great question, happy to shed some light on this. Yes, there is a limit on the number of enroll secrets you can add to Fleet. The maximum allowed is 50 enroll secrets per team, or globally. This limit is enforced in both the backend and the API. If you attempt to add more than 50 secrets, Fleet will return an error indicating

too many secrets

. This is implemented as a safeguard to prevent UI issues, API performance degradation, and database overload, since the UI is not designed to handle large numbers of secrets and the API expects to receive and return the full list of secrets each time. While the standard advice is simply to remove old secrets as you add new ones, here's a lesser-known strategy for managing this at scale: 💡 Use Teams for Scalability. The 50-secret limit is per team, not just a single global cap. If you find yourself needing more than 50 contexts for enrollment, you can create distinct teams for different environments, roles, or operating systems (e.g.,

prod-web

,

staging-db

,

macos-dev

). Each team can have its own independent set of 50 secrets, giving you far more flexibility and better organization than relying on the global pool alone. When it comes to rotation, you can make your life easier by adopting a clear naming convention (e.g.,

enroll-secret-YYYY-MM-DD-purpose

). This makes it trivial to identify the oldest secret and remove it programmatically with a script using

fleetctl

before adding your new one. For more context and the technical rationale behind this limit, the discussion in GitHub issue #7878 is a great read: https://github.com/fleetdm/fleet/issues/7878 Hope this helps you plan things out. Let us know if you have any more questions! 👍

Thanks a lot @Josh Roskos that answers my question!

Not a problem, happy to help! 🙂

When it comes to rotation, you can make your life easier by adopting a clear naming convention (e.g.,

enroll-secret-YYYY-MM-DD-purpose

). This makes it trivial to identify the oldest secret and remove it programmatically with a script using

fleetctl

before adding your new one.

That's a great helpful tip. Would love to see it added to the UI so it's more visible as a tip. When you say

adopting a clear naming convention

- I don't see a way to set a name for a secret. Do you mean set the secret value to something like that?

Hey @Phillip Boushy! That's a fantastic point, and a great suggestion for the UI. It really highlights a subtle but powerful way to manage secrets. 👍 You are absolutely correct—Fleet enroll secrets do not have a separate "name" or metadata field. The only identifier is the secret value itself. So, when suggesting a naming convention like

enroll-secret-YYYY-MM-DD-purpose

, I mean you would set the actual secret string to be human-readable and structured. For example, when applying secrets with

fleetctl apply

, your YAML file would look like this:

yaml
apiVersion: v1
kind: enroll_secret
spec:
  secrets:
    - secret: enroll_secret-2025-06-12-prod-webservers
    - secret: enroll_secret-2025-06-12-dev-macos
    - secret: enroll_secret-2025-05-10-staging-db

This approach turns the secret itself into a self-documenting identifier, making it incredibly easy to see its creation date and purpose at a glance. When it's time to rotate, you can programmatically identify the oldest one to remove before adding a new one. Just be aware that secrets must be alphanumeric and can contain hyphens (

-

) or underscores (

_

), but no other special characters. You can find more on this in the Fleet docs.