Is your feature request related to a problem? Please describe.

Yes. We are using Apollo Router in a multi-environment setup (QA, staging, production), where we build a single Docker image and adjust configuration dynamically using environment variables at runtime.

With the audiences feature introduced in v2.4.0, the configuration only supports specifying audiences as a YAML list. However, we cannot use a dynamic environment variable to define a list directly, especially since the number of audiences varies across environments.

Using an environment variable like:

audiences: ${env.PROVIDER_AUDIENCES}

fails if PROVIDER_AUDIENCES is a string such as "https://aud1;https//aud2", since Apollo Router expects a list, not a string.

This limitation prevents us from cleanly injecting environment-specific audience values without resorting to fragile scripting or rebuilding the Docker image.

Describe the solution you'd like

We’d like Apollo Router to support an alternate way to define audiences as a delimited string, which would be internally parsed into a list.

Examples of desired syntax:

# Traditional list (supported, unchanged)
audiences:
  - https://aud1
  - https://aud2

# New syntax: string with default delimiter (;)
audiences: "https://aud1;https://aud2"

# Optional: custom delimiter
audiences: "https://aud1|https://aud2"
audiences-delimiter: "|"

This approach would allow us to define audiences dynamically via environment variables in a single string, compatible with all deployment environments.

Describe alternatives you've considered

• Custom Rhai script: We’ve already implemented a workaround using a custom Rhai script to manually validate the audience field, but this increases complexity and is harder to maintain.
• Multiple environment variables: Managing audiences as multiple env vars is not feasible, as the count of audiences varies per environment.
• Templating or regenerating config files: This violates our "build once, deploy many" principle and complicates our CI/CD pipelines.

Additional context

We use multiple identity providers and need to dynamically configure audiences per environment. Our configuration includes jwks, issuers, and audiences, but the lack of flexible dynamic configuration for audiences is a blocker to fully adopting this feature.