Statamic Kontainer Laravel Package

Technical Evaluation

Architecture fit. This is a thin Statamic addon: an addon manifest, a settings screen for Kontainer API credentials, and a custom fieldtype that browses DAM assets and stores references rather than binaries. That is the right shape for a Laravel/Statamic stack — the fieldtype is the idiomatic extension point, and keeping the DAM as the system of record means no media duplication or sync job to own. The architectural question is not "does it fit" but "does it fit us": the addon is only valuable if Kontainer is already, or is about to become, a sanctioned system of record for media. If Kontainer isn't in the picture, adopting this package is really a DAM procurement decision wearing a composer package's clothes.

Integration feasibility. Mechanically low effort: install via Composer, enable the addon, set API credentials, add the fieldtype to one or more blueprints, and render the stored reference in Antlers/Blade. There is no data migration for existing local assets because the fieldtype is additive. The real effort sits in verification, not installation.

Technical risk. High, and concentrated in maintenance rather than design:

• Effectively unmaintained. Zero stars, single-author, last release March 2022. Statamic has shipped multiple majors since; addon APIs and control-panel Vue/asset build conventions have moved. Assume incompatibility with current Statamic until proven otherwise on a branch.
• Reference durability. Saving a reference means the CMS content is now coupled to an external object's lifecycle. Asset deletion, rename, or permission changes in Kontainer can silently break published pages with no signal inside Statamic.
• Credential handling. API credentials in addon settings imply stored config; confirm whether they are environment-scoped and encrypted, and that they never land in committed YAML.
• Evidence base is contradictory. The v1.3.2 note ("Adhere to read_only") does not describe a DAM fieldtype, and the supplied PM assessment describes an unrelated read-only-attribute package. Neither can be used as a basis for a decision. Treat the repository itself as the only source of truth and re-baseline the assessment after a spike.

Key questions. Which Statamic/Laravel/PHP versions are supported, and is there a compatibility matrix? Does the fieldtype persist an asset ID, a URL, or a serialized object — and is resolution done at save time or render time? What happens in the control panel and on the front end when a referenced asset is deleted or unpublished in Kontainer? Are credentials per-environment and encrypted at rest? Does the fieldtype behave correctly with revisions, multisite/localization, and Statamic's Stache/static caching? Who owns the code if the author stops responding? Is there a Kontainer-side API contract, rate limit, and SLA we can rely on?

Integration Approach

Stack fit. Laravel + Statamic, Composer-installed, control-panel assets compiled and served through Statamic's addon pipeline. Confirm the addon's asset build is compatible with the target Statamic version's CP toolchain before assuming anything else works.

Migration path. Additive by design: no content migration is needed to introduce the fieldtype. Migration work appears only if you are replacing an existing media workflow — mapping local uploads to Kontainer assets, rewriting hardcoded image paths in templates, and preserving URLs so external links and SEO don't regress. Scope that separately; it is content work, not package work.

Compatibility. Pin an exact version and run a matrix against your Statamic minor. Two compatibility surfaces matter: the PHP/addon API (install, settings, fieldtype registration) and the control-panel JavaScript (browse, select, preview). The second fails silently for editors and is the usual casualty of a CMS upgrade.

Sequencing.

1. Spike on a throwaway branch: install, configure credentials against a non-production Kontainer tenant, confirm the fieldtype renders, browses, saves, and renders on the front end.
2. Confirm the Kontainer API contract — auth model, rate limits, pagination, asset lifecycle events — with the DAM owner, not with the addon.
3. Pilot on one blueprint in one section with two or three editors.
4. Document the template pattern for resolving references and the caching decision.
5. Roll out blueprint by blueprint; hold a decision point on forking the addon before scope widens.

Operational Impact

Maintenance. Budget for ownership. With no release since 2022, the realistic posture is "vendor it and expect to maintain a fork," not "depend on upstream." Assign an engineer, watch Statamic majors, and keep the fork shallow so upstream patches (if any) remain cherry-pickable.

Support. No vendor SLA. Kontainer support covers their API, not this addon; the seam between them is yours. You need an internal runbook covering credential rotation, "editor can't see assets," and "image missing on live page."

Scaling. Editor-side browsing hits the Kontainer API per control-panel session — check rate limits and pagination before a large editorial team lands on it. Front-end scaling depends entirely on what's stored: if references resolve to stable URLs, render cost is negligible; if templates fetch asset metadata per request, you have introduced a network dependency into page render and must cache aggressively. Static caching also means DAM-side changes won't invalidate CMS pages — decide a TTL or an explicit purge step.

Failure modes. Kontainer API outage blocks asset selection (already-saved content usually still renders if URL-based). Token expiry produces opaque control-panel errors. Asset deletion or renaming upstream breaks live media with no alert inside Statamic. A Statamic upgrade breaks the CP fieldtype while the backend looks healthy. Credentials committed to config. Empty or partial saves when the fieldtype fails silently.

Ramp-up. Low technical ramp-up, non-trivial editorial ramp-up: editors must understand the split between "approved in Kontainer" and "published in Statamic," who owns DAM taxonomy and permissions, and what to do when an asset is missing. Plan a short training session, a support-desk runbook, and broken-media monitoring as acceptance criteria — not follow-ups.