[Feature Request] Infisical provider: resolve secrets recursively across folders (or support paths in the reference syntax)

What problem will this feature address?

The Infisical secrets provider (introduced in v0.30.0) is a great addition — thank you! However, its current design makes it hard to use for anyone who organizes secrets with Infisical folders, which is a core Infisical feature (secrets are scoped by environment and path, with nested folders supported everywhere in Infisical: CLI, API, Terraform, K8s operator).

Current limitations:

1. One provider = one Secret Path. Each provider instance is bound to a single project + environment + secret path (default /). Referencing secrets living in different folders requires creating a separate provider for each folder.
2. No path in the reference syntax. The syntax is ${{vault.<provider>.<SECRET_NAME>}}, e.g. ${{vault.infisical-prod.API_KEY}}. Unlike the Vault provider (<path>:<field>) or the Scaleway provider ([folder/]<secret-name>), there is no way to point at a specific folder in the reference itself.
3. No recursion. Secrets stored in subfolders under the configured Secret Path are not picked up.

For users managing a large number of secrets organized into many folders/subfolders, the only options today are:

• Creating one Dokploy provider per Infisical folder (unmanageable beyond a handful of folders), or
• Flattening the whole Infisical project structure to /, losing the organization that Infisical itself encourages.

Describe the solution you'd like

The ideal solution would make the reference syntax folder-agnostic, with path support as a fallback if recursion is not feasible:

Primary — folder-agnostic resolution (recursive):
The provider resolves ${{vault.my-infisical.API_KEY}} regardless of which folder or subfolder the secret lives in. Concretely: the provider would fetch secrets from the entire folder tree under the configured Secret Path (recursively), exactly like the Infisical CLI already does with infisical run --path=/backend --recursive, which injects secrets from the folder and all its subfolders. This keeps the reference syntax simple and untouched — no need to know or care where a secret is stored.

Note: this would require secret names to be unique across the resolved tree (or a documented precedence rule for duplicates), which seems like a reasonable constraint since it is the same one the CLI applies.

Secondary — path in the reference syntax (fallback):
If recursion is not an option, then at least allow pointing at a specific folder in the reference, consistent with the precedent already set by the Scaleway provider:

${{vault.my-infisical.backend/API_KEY}}

or Vault-style:

${{vault.my-infisical.API_KEY:backend}}

This is more verbose and less convenient to use than the recursive approach, but it would at least make the integration usable with an organized folder structure.

Infisical exposes everything needed for both options via its API (e.g. GET /api/v3/secrets/raw with secretPath + recursive=true).

Describe alternatives you've considered

Honestly, none of the available workarounds is a real alternative for this use case:

• One provider per folder: technically possible, but with many folders and subfolders it becomes cluttered and painful to maintain (each needs its own Machine Identity credentials + config), and it multiplies the provider list in the UI.
• Bypassing the integration: wrapping the start command with the Infisical CLI (infisical run --env=prod --path=/backend --recursive -- ...). This works, but it defeats the purpose of the native Dokploy integration (visibility in the UI, centralized management, no extra CLI dependency in every image).
• Infisical Secret Syncs: pushing secrets from Infisical to another target and pointing Dokploy at that — adds another moving part instead of using the native integration.
• Flattening the Infisical structure: losing the folder organization entirely, which contradicts how Infisical itself is designed to be used.

That is why the two solutions described above (recursive/folder-agnostic resolution as the ideal, path-in-reference as a fallback) are really the only ones that would make the integration usable at scale.

Additional context

• Infisical folders documentation: https://infisical.com/docs/documentation/platform/secrets-mgmt/folders
• Infisical API for reading secrets at a path (supports recursive): https://infisical.com/docs/api-reference/endpoints/secrets/read
• Infisical CLI --path / --recursive behavior for reference: https://infisical.com/docs/cli/commands/secrets
• The Scaleway provider already supports [folder/]<secret-name> in its reference syntax, so there is in-repo precedent for path-aware references.
• Related upstream issue that introduced secrets providers: #2768

Will you send a PR to implement it?

No

Start by locating the Infisical secrets provider and its reference-resolution entry point, then compare the existing Scaleway path-aware syntax and related issue #2768. Review the Infisical raw-secrets API with secretPath and recursive support. Done means a documented folder-resolution behavior with tests covering nested folders and duplicate-name handling.