Statamic Instagram Laravel Package

Technical Evaluation

Scope of change (v2.6.1): A single patch-level fix (#10) that moves an API token out of hardcoded/committed configuration and into .env. This is a secrets-hygiene change rather than a functional one.

Architecture fit: Strong. Reading credentials from .env via config/*.php is the idiomatic Laravel pattern and aligns with how our other Laravel integrations are configured. It removes a credential from version control, which is a prerequisite for us to pass a security review or onboard the package into shared environments.

Integration feasibility: Low effort. For a greenfield integration this changes nothing — we set the variable and move on. For any existing consumer of this package, the upgrade requires the variable to be present in every environment before the new code path runs.

Technical risk: Low-to-moderate, and almost entirely deployment-time rather than code-time.

• Missing-variable failure: If the token is read from env() inside a config file and the config is cached without the variable set, the token resolves to null. Depending on how the package handles that, the symptom is a 401/403 from the upstream API rather than a clear boot-time error — a slow-to-diagnose failure mode.
• Config cache ordering: php artisan config:cache must run after the environment variable is populated in the target environment. Pipelines that cache config at build time rather than deploy time will bake in an empty token.
• Silent behavior change: Because this is a patch release, teams may apply it automatically via composer update. A previously working integration can break with no version-boundary signal.

Key questions:

1. What is the exact environment variable name, and is it documented in .env.example?
2. Is the token read through a published config/ file (correct) or via env() at call time (breaks under config:cache)?
3. Is there a fallback to the previous config key, or is this a hard cutover? If hard cutover, is the previous key silently ignored or does it fail loudly?
4. Does the package validate token presence at boot/service-provider registration, or only on first API call?
5. Is there a published config file that existing installs must re-publish (vendor:publish --force) to pick up the new key?
6. Does the package support multiple tokens/tenants, or is it single-tenant per deployment?

Integration Approach

Stack fit: Native to Laravel. No new dependencies, no service-provider changes expected, no framework version implications. Works with Laravel's standard config:cache and env() semantics.

Migration path:

1. Add the new variable to .env.example in our repos and to the secret store for each environment (Vault / AWS Secrets Manager / Forge or container env vars).
2. Set the variable in dev, staging, and production before bumping the package constraint.
3. Update the package version and run php artisan config:clear && php artisan config:cache as part of the deploy step.
4. Verify with a single authenticated call in staging before promoting.

Compatibility: Backward-incompatible in practice for anyone who had the token committed in a config file, despite the patch version number. Treat the upgrade as a config change requiring a coordinated deploy, not a routine dependency bump. Pin the version explicitly (2.6.1) rather than using a floating constraint so the change lands deliberately.

Sequencing: Secrets provisioning → env var present in all environments → package upgrade → config cache rebuild → smoke test. Do not reorder; the package upgrade before the secret exists is the failure case.

Operational Impact

Maintenance: Net positive. Removing a committed credential reduces rotation friction and eliminates a class of credential-leak incidents. Rotation becomes an env-var update plus a config cache rebuild, with no code change or redeploy of application logic.

Support: Expect a short tail of tickets from any team still on a pre-2.6.1 install whose token now resolves empty. Pre-empt this with a one-line release note to consuming teams: "the API token is now read from <VAR>; set it before upgrading." Given the release note as published contains only the PR title, we should author that internal note ourselves rather than forward the changelog.

Scaling: Fits horizontally scaled deployments cleanly, since env vars are per-environment and read once at config-cache build. The one constraint to confirm is multi-tenant use — if a single deployment ever needs to serve multiple upstream tokens, env-var-only configuration is the wrong shape and would need a database- or vault-backed resolver. Today that does not appear to be a requirement.

Failure modes to instrument:

• Token unset or empty → upstream returns 401/403; log the response body and the presence (never the value) of the config key.
• Stale config cache → old or empty token persists after a credential change; make config:cache an explicit, verified deploy step.
• Rotation drift → secret rotated in the vault but not in the running containers; alert on sustained auth failures rather than single errors.

Ramp-up: Minimal for engineers already working in Laravel — this is a familiar pattern with no new concepts. Budget roughly half a day of TPM/eng time for the coordination work (secrets provisioning across environments, pipeline adjustment, team comms) rather than for the code itself.

Assessment caveat: This evaluation is derived from a one-line changelog and an inferred package profile; no repository, version history, or prior assessment was available. Confirm the answers to the key questions above before treating the risk rating as final — in particular whether the previous config key still functions as a fallback, which is the single factor that would move this from a coordinated deploy to a routine one.