Vault Bundle Laravel Package

Technical Evaluation

Architecture fit Unchanged in substance: itk-dev/vault-bundle remains a Symfony bundle, hooking Bundle/Extension/CompilerPass and resolving secrets into the DI container at boot. 1.0.0 does not add a Laravel service provider, config repository, or framework-agnostic facade, so the delivery mechanism is still foreign to a Laravel codebase. The underlying capability (Vault KV v1/v2 retrieval, AppRole/K8s/token auth) remains stack-neutral and valuable, but we still consume it as a reference implementation plus client dependency, not as an installable Laravel package. Verdict unchanged: strong Symfony fit, weak Laravel fit without an adapter we own.

Integration feasibility

• Symfony: Composer install, register bundle, configure address/role/secret paths; secrets resolve at boot. Still low effort — and now nominally extends to Symfony 8 projects.
• Laravel: Still no supported path. Same three options: (a) wrap the underlying Vault client in a Laravel config repository/service provider, (b) deploy-time hydration into env, (c) sidecar. All three mean we own the integration layer.
• Effort estimate: unchanged — ~1–2 days for a Symfony PoC; 1–3 weeks engineering plus security review for a production-grade Laravel adapter. The 1.0.0 release does not reduce this, because the missing piece is framework integration, not Vault capability.

Technical risk

• Adoption signal unchanged and still the dominant risk: 2 stars, 0 dependents. A 1.0.0 tag does not create users. The published score (8.71) still reflects code heuristics, not ecosystem validation; the low opportunity score (39.94) remains the more honest signal. An unproven dependency with a stability label is still an unproven dependency.
• Bus factor: marginally improved, not resolved. A second contributor (@rimi-itk) landed the Symfony 8 work — the first evidence of anyone besides the originating agency committing. That is a positive signal but a single PR is not a maintainer bench, SLA, or succession plan.
• Versioning hygiene — new concern. The changelog is internally inconsistent: a PR titled "Hotfix/0.1.1," a compare range of 0.1.2...1.0.0, and a jump from 0.1.x straight to 1.0.0 with only two PRs and no documented breaking changes. A 1.0.0 tag is a promise about API stability; this one appears to have been cut to mark "Symfony 8 support" rather than after an API-stabilization process. Do not read 1.0.0 as a maturity signal.
• Security-critical surface unchanged: auth method choice, token/lease renewal, TLS/CA validation, secret caching. There is still no large user base to have shaken out edge cases — and a major-version bump is exactly when latent behavioral changes ship quietly.
• Boot-path coupling unchanged: secret resolution at container build/compile time keeps Vault on the startup critical path — correct fail-closed behavior, still a new blast radius for every deploy and cold start.

Key questions

1. What actually changed between 0.1.2 and 1.0.0 besides Symfony 8 constraint widening? Are there behavioral, config-key, or DI-service-id changes that the changelog omits?
2. Does 1.0.0 come with a written backwards-compatibility/deprecation policy, or is the major version purely ceremonial?
3. Which Vault auth methods are supported, and is token/lease renewal implemented or delegated to a client library?
4. Are secrets resolved at container compile time, runtime, or both — and what is cached, where, for how long?
5. Does it ever materialize secrets to disk/env (leak risk), or keep them in memory only?
6. What client dependency does it wrap, and what are its version constraints and CVE posture?
7. Is KV v2 path translation handled, and is Vault Enterprise namespace supported?
8. How does it interact with Symfony's config dump and Laravel's config:cache semantics?
9. What is the behavior when Vault is sealed or unreachable at boot — hard fail, retry, or deferred resolution?
10. Test coverage, CI matrix (now presumably PHP 8.x × Symfony 6/7/8), release cadence, and whether the Symfony 8 path has any test coverage behind it.

Integration Approach

Stack fit Targets PHP 8.x on Symfony 6/7, now with Symfony 8 declared support. It still assumes Symfony DI internals, PSR-3 logging, and (likely) a PSR-18 HTTP client — no overlap with Illuminate's container. In a Laravel-standard estate this remains a reference implementation and a Vault client dependency, not an installable solution. The 1.0.0 release expands the set of Symfony services we can adopt it in; it does nothing for Laravel.

Migration path Unchanged, with one adjustment: prefer Symfony 8 targets for greenfield Symfony work now that support is declared, but validate that path independently rather than assuming a version-constraint bump equals tested compatibility.

1. Stand up Vault with an appropriate auth method (AppRole for VMs, Kubernetes auth for containerized workloads) and seed KV.
2. Adopt the bundle directly in Symfony services first — lowest-friction, highest-confidence adoption.
3. For Laravel apps, build a thin VaultConfigRepository service provider around the same client library the bundle wraps, so auth semantics stay consistent across the estate.
4. Remove secrets from .env files and CI variables; leave only Vault address and bootstrap role/secret-id.
5. Decommission plaintext secret storage and rotate everything previously exposed.

Compatibility Pin the bundle and its transitive dependencies — now more important, since a 1.0.0 tag invites wider constraint ranges (^1.0) and the Symfony 8 support is one PR old. Symfony major upgrades (6→7→8→9) remain the likeliest breakage point because bundles reach into DI internals; the 1.0.0 release is itself evidence that framework-version support arrives as point releases, so budget for it recurring. Audit at every PHP minor. Verify Vault server version compatibility separately — the Symfony 8 work says nothing about tracking current Vault releases.

Sequencing PoC in a non-production Symfony service (now preferably on Symfony 8, to prove the new path) → validate auth, rotation, and unreachable-Vault behavior → security review of caching and logging paths → build the Laravel adapter in parallel if needed → staging → production. Do not place this on the boot path of a high-traffic Laravel application until the fallback/caching story is proven. Treat the 1.0.0 upgrade as a normal dependency bump requiring regression testing, not as a drop-in.

Operational Impact

Maintenance We remain de facto maintainers on adoption. The realistic posture is fork-and-vendor: pin a known-good commit (1.0.0 if it clears validation, otherwise 0.1.2), keep a local patch branch, and budget recurring time for PHP/Symfony/Vault-API upgrades. The second contributor slightly raises the chance upstream keeps pace with Symfony releases; it does not transfer ownership of our break/fix. MIT license keeps this straightforward — the risk is unbudgeted drift, not legal friction.

Support Community support is still thin; expect unanswered issues. The new contributor is a hopeful signal about maintenance continuity, not a support channel. If we need guaranteed turnaround, negotiate with itk-dev or accept that internal engineering owns break/fix. Document this before adoption.

Scaling Unchanged: Vault calls scale with instance count and redeploy frequency, not request volume. Watch autoscaling fleets doing mass cold starts (auth-method rate limits, AppRole secret_id quotas), long-lived processes (queue workers, Octane/Swoole) outliving short token TTLs unless renewal exists, and cross-region latency at every cold start.

Failure modes

• Vault sealed or unreachable → application fails to boot. Correct (fail-closed) but disruptive; needs a runbook and unseal-status alerting.
• Major-version upgrade → silent behavioral drift. With an undocumented 0.1.2→1.0.0 delta, a routine composer update could change config keys, service IDs, or resolution timing with no release notes to point at. Pin exactly and diff the source before upgrading.
• Token expiry without renewal → mid-life failures in long-running workers, invisible to startup health checks.
• KV v2 path mistakes → silent misconfiguration or empty secrets rather than a clean error.
• Rotation events → running processes hold stale secrets until restart; plan rolling restarts.
• Any disk-based secret caching → persistent leak surface and a compliance finding.
• Config caching interactions (Symfony config:dump, Laravel config:cache) can bake secrets into artifacts — verify explicitly as a CI/CD hygiene item.

Ramp-up A Symfony team is productive in hours. A Laravel team needs days to weeks to build and validate an adapter, plus security review, runbook authoring, and on-call training. Budget the security review as a first-class deliverable — this package sits directly on the secrets path, has almost no external scrutiny to lean on, and just shipped its first major version with a two-line changelog.