Make env() Function Extensible to Support Secret Managers

[noah1400]

Hello Everybody!

I'd like to propose a feature that would make the env() function extensible to support various secret management systems.

The Problem

Currently, Laravel's env() function only reads from system environment variables and the .env file. Many organizations use secret managers (Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, etc.), making it challenging to integrate these systems properly with Laravel applications.

Proposed Solution

Allow developers to implement their own environment variable resolution strategies while maintaining the simple env() interface. This would be done by making env() extensible, so users can inject their own implementation.

Example Use Case

This is how an implementation might look like:

1. Check if the secret/variable exists in cache
2. If not, retrieve a token ( from cache or by authenticating
3. Fetch the secret from Secret Manager
4. Cache the secret for future use
5. Fall back to standard env() behaviour if the secret isn't found

What do you think about this feature? Any suggestions on implementation details or potential concerns?

UPDATE: After investigating the code

I discovered that the functionality I proposed actually already exists in Laravel! The Illuminate\Support\Env class uses a $repository variable that implements Dotenv\Repository\RepositoryInterface, which allows for custom environment variable resolution.

However, there's a limitation: the $repository variable is declared as protected static, making it impossible to override in application code.

Two solution I'd like to propose

1. Make the variable public: Change protected static $repository to public static $repository so developers can override it during application bootstrapping.
2. Use the service container (preferred): Instead of using a static property, resolve the repository through Laravel's service container. This would allow developers to bind their own implementation:

// In a service provider
$this->app->bind(RepositoryInterface::class, AzureKeyVaultRepository::class);

This approach would be more aligned with Laravel's dependency injection patterns and make the feature more accessible and testable.

Documentation Update Proposal

I also propose adding a section to the documentation explaining how to implement custom environment variable resolvers, similar to how Laravel documents custom filesystem drivers or cache stores.

What do you think about these approaches?