Vault Bundle Laravel Package

Technical Evaluation

Architecture fit — mismatch to flag first. Despite the "Laravel/PHP package" framing, the release notes describe nowo-tech/VaultBundle, a Symfony bundle: Twig templates (vault/share.html.twig, vault/item_form.html.twig), the Symfony Form component's child-rendering loop ({% for child in form %} / form_row(child)), Doctrine ORM and MongoDB ODM dependencies, and a Symfony 8.1 badge. There is no service provider, no config/vault.php, no Blade views, and no Eloquent integration. The PHP-level fit is fine (Composer package, PSR-style tooling via .php-cs-fixer.dist.php); the framework-level fit against a Laravel codebase is close to zero without a bridge.

Integration feasibility — low for direct adoption, moderate for a sidecar. Composer will happily install the package into a Laravel app; nothing will register or boot the bundle. Realistic paths: (a) run the bundle inside a minimal Symfony kernel as a separate service, (b) treat it as a reference implementation and rebuild the vault on Laravel's Crypt + Eloquent casts, or (c) fork the encryption layer — which is the hard part, because encryption is delegated to nowo-tech/doctrine-encrypt-bundle, a Doctrine-event-listener design with no Eloquent analogue.

Technical risk — concentrated in two places.

1. View refactor in a patch release. REQ-TWIG-003 changes how share-form fields are emitted: field bodies now render through the child loop with not child.rendered guarding, and vault/item_form.html.twig drops the hand-placed _token widget in favour of the loop. Any downstream app that overrides _share_form_fields.html.twig or the item form (common for a vault UI) can now get a duplicated or missing _token → silent CSRF failures on the share form, or fields that are skipped because a prior override marked them rendered. The notes assert "rendered fields are unchanged," but that claim is only tested against the bundle's own templates, not consumer overrides.
2. Crypto dependency drift inside a patch. doctrine-encrypt-bundle moves 2.5.0 → 2.8.0 — three minor versions of the component that actually protects the secrets — shipped as a routine dependabot bump in a 1.8.2 release. Nothing in the notes states whether ciphertext format, key derivation, or algorithm defaults changed. That needs independent verification before this version touches real data. Same caution, lower stakes, for form-kit-bundle 2.11→2.12 and the MongoDB ODM bumps (which also confirm a widening persistence surface to operate).

Key questions for the maintainer / for us:

• Is Laravel genuinely in scope, or is this assessment chasing the wrong package? If Laravel is the target, we should be evaluating a Laravel-native vault, not this.
• What is the exact supported matrix — Symfony 8.1 only, or 6.4/7.x LTS too? An 8.1-only requirement is a hard blocker for most estates.
• Did doctrine-encrypt-bundle 2.5→2.8 alter stored payload format or key handling? Is there a documented upgrade note and a decrypt-forward test fixture?
• Is the REQ-TWIG-003 change covered by a regression test that renders with a custom form theme, not just the bundled one?
• Security posture: disclosure policy, CVE history, who holds commit rights, and is the encryption independently audited?
• Licensing and multi-tenancy/audit-log expectations for a secrets vault — neither is addressed anywhere in the changelog.

Maturity signal. The release is dominated by governance artefacts — REQ-* identifiers, badge/doc hygiene, canonical issue templates, "Cursor Agent queue settings," "Spec Kit inventory refresh (123/123)." That indicates a small team with heavy, possibly agent-assisted process discipline. Good for traceability; the risk is that process volume masks thin functional review, as the crypto bump above suggests.

Integration Approach

Stack fit. Target stack (assumed Laravel + MySQL/Postgres + Blade) versus package stack (Symfony 8.1 + Twig + Doctrine ORM/ODM + form-kit-bundle + doctrine-encrypt-bundle) overlaps only at the PHP runtime and Composer. Do not plan on shared DI container, shared auth guard, shared migrations, or shared view layer — none of these bridge cleanly.

Recommended path, in order of preference:

1. Do not integrate. Build the vault capability on Laravel primitives (encrypted Eloquent casts, per-record data keys, audit table). The functional surface implied by these views — named secrets, per-item-type field sets, share links with tokens — is modest and largely CRUD plus crypto.
2. Sidecar service. Stand up the Symfony bundle as an internal HTTP service, put the Laravel app behind an authenticated client. Preserves the encryption implementation, isolates the framework mismatch, and gives a clean boundary for audit logging. Cost: a second deployable, second runtime to patch, network hop on every secret read.
3. Fork and port. Only if the Doctrine encryption semantics are non-negotiable and unreproducible. Expect to reimplement listeners as Eloquent observers — highest effort, highest long-term maintenance.

Migration path. There is no prior assessment and no incumbent integration, so this is greenfield: no data migration, no cutover. The decision to make is architectural, not operational.

Compatibility checks before any commitment: PHP minor version, Symfony 8.1 vs. your LTS posture, Doctrine ORM/ODM major, Twig major, and whether form-kit-bundle pulls further Symfony constraints that cascade into your other services.

Sequencing if we proceed to a spike (2 weeks, one senior dev):

1. Pin 1.8.2 exactly; vendor-review doctrine-encrypt-bundle 2.5→2.8 changelog and diff.
2. Sandbox: install, render the share form and item form, capture before/after rendered HTML from 1.8.1 versus 1.8.2.
3. Repeat step 2 with a custom form theme override to test the REQ-TWIG-003 edge case.
4. Round-trip encrypt on 1.8.1, decrypt on 1.8.2, and vice versa — this is the go/no-go gate.
5. Only then evaluate the sidecar wiring against the Laravel app.

Operational Impact

Maintenance. Dependency updates arrive via dependabot, several per patch release. That is healthy for currency but means patch-level releases routinely touch transitive dependencies; treat every 1.8.x as requiring a changelog read rather than an auto-merge. Pin exactly and upgrade deliberately. The REQ-* traceability is genuinely useful here — changes are labelled and referenced in UPGRADING.md, which is better than most packages of this size.

Support. Community-only: GitHub issues, no vendor SLA, no published security-response commitment. For a component that stores secrets, the absence of a stated disclosure process is a material gap and should be raised before adoption, not after an incident. Maintainer concentration (apparent single-org stewardship) is a bus-factor risk.

Scaling. Rendering cost is negligible — the child-loop change is a compile-time template concern, not a runtime one. The cost centre is encryption/decryption per secret access; if reads are hot, cache decrypted values in-process with a short TTL rather than re-decrypting per request. The maintained MongoDB ODM path indicates the package has been used at document-store volumes, but nothing in the notes evidences load testing. No published performance characteristics.

Failure modes to instrument:

• CSRF rejection on share submission — most likely first symptom of a stale or custom form theme interacting with the new child loop and the removed hand-placed _token.
• Silently missing fields — a field marked rendered upstream is skipped by the not child.rendered guard; the form submits incomplete with no error. Add a post-deploy assertion on rendered field count per item type.
• Undecryptable ciphertext after a crypto-library bump — mitigate with fixture round-trip tests in CI, not manual verification.
• Symfony 8.1 floor blocking a future PHP/platform upgrade — this is a latent trap that surfaces months later during an unrelated framework refresh.
• Unregistered bundle after Composer install — a confusing, silent no-op if someone assumes installation equals integration.

Ramp-up. Assume low Laravel-to-Symfony fluency on the team. Twig, the Symfony Form rendering model (child loops, rendered flags, form themes) and Doctrine event listeners are each a distinct learning curve; the form-theming model in particular is where the REQ-TWIG-003 change bites. Budget two to three weeks before a senior engineer is productive in this codebase, and note that this knowledge is only worth acquiring if we take the sidecar or fork path — it is wasted effort if we build on Laravel primitives instead.