Weave Code
Env Params Builder Bundle Laravel Package
piwikpro/env-params-builder-bundle
A Symfony bundle from Piwik PRO that helps build and manage environment-specific parameters, making it easier to configure services and integrations from environment variables in a consistent, maintainable way across development, staging, and production environments.
Helps to build parameters.yml file based on environment variables
Frequently asked questions about Env Params Builder Bundle
- Is piwikpro/env-params-builder-bundle a Laravel package?
- No. It is a Symfony bundle from Piwik PRO whose purpose is to render a Symfony parameters.yml file from environment variables, typically as a build or deploy step. There is no Laravel service provider, facade, or config integration of any kind. If you are evaluating it for a Laravel application, the stack fit is zero.
- Can I install this bundle in a Laravel application or on any Laravel version?
- No. Laravel has no bundle registration, no parameters.yml, and no %parameter% container substitution, so there is no seam where this package plugs in. Laravel configuration is PHP arrays in config/*.php resolved through env() and cached with php artisan config:cache. It does not work on Laravel 8, 9, 10, 11, or any other version.
- What does this bundle actually do and what problem was it solving?
- It generates a parameters.yml file from environment variables so that real credentials are never committed to the repository. That was a common Symfony 2.x and 3.x pattern for keeping secrets out of version control while still populating container parameters. The problem it solves has been handled natively by Symfony since version 3.3.
- Which Symfony versions does this bundle support?
- Its design targets the Symfony 2.x and 3.x era, up to roughly Symfony 3.4. Native %env(VAR)% support arrived in Symfony 3.3, and symfony/dotenv plus Flex recipes in Symfony 4 replaced this approach entirely. Any Symfony 4 or later project should use native environment handling and not this bundle.
- How do you install and configure it on a legacy Symfony application?
- Mechanically it is a Composer require, a bundle registration in AppKernel, and an invocation of the bundle's command in CI before cache warmup. The catch is that its PHP and Symfony version constraints will almost certainly fail to resolve against any current framework release. Plan on constraint overrides or a vendored fork if you attempt it at all.
- What happens if an environment variable is missing or misspelled?
- Silent failure is the default risk. A missing or misspelled variable typically renders as a null or empty parameter rather than a hard error. That surfaces much later as an authentication failure, a broken integration, or an insecure default value. Add explicit validation that fails the build when a required key is absent.
- Why is generating parameters.yml at deploy time risky in production?
- It forces per-environment builds, which breaks the build-once and promote-everywhere promotion model. Writing secrets into a generated file means they persist in image layers, build logs, or deploy artifacts. It also conflicts with immutable-artifact deployment, where the same artifact should run unchanged in every environment.
- What should a Laravel app use instead for environment-based configuration?
- Use env() inside config/*.php files, keep a checked-in .env.example documenting required keys, and run php artisan config:cache during deployment. Add a startup guard that fails fast when a required key is missing so misconfiguration never reaches production silently. Store secrets in your platform secret manager rather than in files on disk.
- What is the Symfony-native replacement for this bundle?
- Use symfony/dotenv for local development, %env(VAR)% references in your config files, and env processors such as bool, int, json, and resolve for typing. The historical peer to this bundle was incenteev/composer-parameter-handler, which is also superseded. Both are unnecessary on Symfony 4 and later.
- Is this package maintained, and what is the safest migration path off it?
- No. It has a score of zero, no stars, zero dependents, and a bus factor of one, so there is no community bug-finding or external security review. The only defensible use is preserving an existing legacy Symfony 2 or 3 deployment that already depends on it. Migration means inventorying every key in parameters.yml, classifying each as secret, environment-specific, or static, moving secrets into a central secret store, converting the rest to real environment variables, and then removing the bundle.
Weaver
How can I help you explore Laravel packages today?