Runtime Config Bundle Laravel Package

Getting Started

1. Install (this is a Symfony 2-era bundle; pin to a Symfony ~2.x project):

   composer require opensky/runtime-config-bundle
   

2. Register the bundle in app/AppKernel.php:

   new OpenSky\Bundle\RuntimeConfigBundle\OpenSkyRuntimeConfigBundle(),
   

3. Configure a provider under opensky_runtime_config in app/config/config.yml. Pick where values live:
   • a YAML file (Resources/config/runtime.yml) for small overrides, or
   • a Doctrine-backed key/value table for admin-editable settings.
4. Read the bundle's README and DependencyInjection/ first. The extension is where the provider service id and parameter names are wired; the boot-time listener is where values are pushed into the container. Those two files tell you exactly which service ids and config keys your version supports.
5. First use case: a site_name / maintenance_mode setting stored in the DB and edited from an admin controller, consumed in a controller or Twig global — no redeploy or cache clear needed when the value changes.

Implementation Patterns

• DB-backed settings edited by admins. Use the Doctrine provider, add a settings CRUD screen writing rows to the provider's table, and read values in services via $container->getParameter('site_name') or through the bundle's runtime config service. This is the core value proposition: marketing/ops change a value in the UI, the next request sees it.
• Layered providers. Keep a YAML provider for defaults and layer a DB provider on top; or wrap the provider in a cache decorator so you don't hit the database on every request. Clear/invalidate that cache in your admin save action.
• Consume, don't inject, when it must be live. Because service arguments are resolved at compile time, expose runtime values through a small Settings/RuntimeConfig service that reads the parameter bag on each call, or via a Twig extension/global, rather than through constructor %param% arguments.
• Feature flags / gradual rollout. Store booleans (feature_x_enabled) and branch in controllers or listeners. Cast string values from the DB to the expected type before using them.
• Test overrides. In the test environment, swap the provider for a YAML fixture provider so integration tests are deterministic and don't need a settings table.
• Console workflow. Add a command that writes settings rows and clears the provider cache; run it in deploy scripts so seeded defaults exist before any web request boots the kernel.

Gotchas and Tips

• Compile time vs. runtime is the big one. Symfony dumps the compiled container; %param% references in service definitions are baked in at compile time. Runtime injection only affects parameters read after boot via getParameter() or the bundle's service. Design around that instead of fighting it.
• Boot-order sensitivity. The bundle works via a kernel.boot listener. If your own boot listener reads settings, make sure it runs after the runtime config listener (adjust listener priority), or you'll read stale/default values.
• Chicken-and-egg with Doctrine. Reading settings from the DB at boot means every kernel boot — including cache:clear, assets:install, and other console commands — may try to connect. Guard against a missing/unmigrated table and fall back to defaults so installs and CLI don't explode.
• Prod cache staleness. Whatever cache the provider uses must be invalidated when settings change; otherwise "runtime" config silently behaves like a deploy-time value. Test the edit-then-refresh path in prod with the cache warm.
• Type coercion. Doctrine rows come back as strings; '0' is truthy in PHP. Cast to bool/int/array explicitly in your settings service.
• Secrets and logging. Values land in the parameter bag and appear in debug:container and exception dumps — don't put API keys there. Prefer environment variables for secrets.
• Debugging. Dump the parameter bag ($container->getParameterBag()->all()) or run debug:container --parameters to confirm what was injected; check that your provider service is actually the one the extension registered.
• Extension points. Write a custom provider implementing the bundle's provider interface (e.g., Redis, Consul, S3) and register its service id in config; add a decorator for caching. These are cleaner than patching the bundle.
• Version lock-in. This is Symfony 2 only and largely unmaintained. On modern Symfony, the built-in equivalents (%env()%, secrets, feature-flag bundles) are the better long-term answer — treat this package as a stopgap, and isolate access behind your own Settings interface so you can swap it out later.