- Does incompass/aws-secrets-bundle work with Laravel?
- No. This package is a Symfony bundle: it relies on the Symfony kernel boot hook, a DI Extension class, and compiler passes to populate container parameters before the container is compiled. Laravel does not use that lifecycle, and vlucas/phpdotenv plus config:cache own bootstrap and freeze configuration at build time. Using it in Laravel would require writing your own service provider and bootstrap hook, which is effectively a reimplementation rather than an installation.
- How do I install and register incompass/aws-secrets-bundle in a Symfony application?
- Install it with Composer and register the bundle in config/bundles.php, then set the AWS region and the secret name or ARN in your bundle configuration. With Symfony Flex autoconfiguration, the bundle registration is usually handled for you. No application code changes are needed because the fetched values are exposed as normal container parameters, so existing %parameter% and env() references keep resolving.
- Which Symfony and PHP versions does this bundle support?
- The package targets Symfony 4.x and 5.x style applications according to the project documentation, with AWS SDK credential providers driving authentication. The exact PHP version constraint and Symfony version range should be confirmed in the composer.json of the tagged release you intend to use before committing. This is a low-adoption republish, so verify that the constraints match your runtime rather than assuming broad compatibility.
- How do I configure the AWS region, credentials, and secret version or stage?
- Region, credential source, and secret version or stage are all bundle configuration options, and the bundle honors the standard AWS SDK credential provider chain including IAM instance roles, task roles, environment variables, and shared profiles. For rotation-safe behavior, point the configuration at the AWSCURRENT stage rather than a pinned version ID. Grant the role secretsmanager:GetSecretValue and, for customer-managed KMS keys, kms:Decrypt.
- Does the bundle cache secrets, and can I control the cache TTL?
- Any local caching behavior and its configurability must be confirmed in the source before you depend on it, because the documentation does not state it clearly. This matters: with no cache, every cold boot makes a live Secrets Manager call, and the cache TTL effectively becomes your credential exposure window. Too long a TTL causes authentication failures after a rotation, while too short a TTL produces per-boot API calls and throttling risk at scale.
- What happens if AWS Secrets Manager is unreachable or returns AccessDenied?
- You need to determine whether the bundle fails closed by aborting the boot or fails open by falling back to existing environment values, and whether that behavior is configurable and logged. Because the fetch happens during container build, an uncached boot becomes a hard runtime dependency on Secrets Manager, KMS, and STS, so a throttle or IAM drift can turn into a fleet-wide boot failure rather than a degraded feature. Verify the failure mode before deploying to production.
- Do secrets from AWS override existing environment variables or defer to them?
- The precedence between remotely fetched values and values already present in $_ENV or $_SERVER is a critical detail that must be checked in the source. If remote values win, rotation is handled centrally in AWS, but you lose the ability to override locally without an explicit disable flag. If local values win, developers can safely shadow secrets on their machines, but production behavior becomes less predictable.
- Can I map JSON secret values to individual container parameters?
- Yes, the bundle supports JSON secret values and maps their keys to individual parameters, so a single secret can populate several configuration values. Keep in mind that AWS Secrets Manager caps a secret at 64 KB, so avoid dumping an entire configuration document into one entry. How multiple secrets and nested JSON keys are flattened is an implementation detail worth verifying before you rely on a naming scheme.
- Is it safe to load AWS secrets into $_ENV in a Symfony application?
- Injecting secrets into environment variables works with existing configuration but widens the exposure surface, since values can leak through debug toolbars, exception pages, phpinfo() output, and logging middleware. There is no documented redaction in this package, so audit your profiler and error handling in non-production environments. Also confirm the bundle does not log secret payloads at debug level during container compilation.
- Is incompass/aws-secrets-bundle maintained, and what are the alternatives?
- This appears to be a small vendor republish of casechek/aws-secrets-bundle with no stars, no dependents, and no visible release cadence, so treat it as a reference implementation to fork or reimplement rather than a strategic dependency. Confirm the license and upstream provenance in writing before adopting it, and note that there is no issue triage or security disclosure channel. For a single GetSecretValue call, a small in-house compiler pass or boot hook backed by the official AWS SDK is often a safer long-term choice.