Atlassian Connect Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for Atlassian Cloud integrations: this package supplies the undifferentiated plumbing for an Atlassian Connect app — descriptor hosting, JWT-signed request handling, and install/uninstall/enable/disable lifecycle endpoints — so the team can spend roadmap capacity on product surface instead of auth mechanics.
• Marketplace roadmap sequencing: if distribution through the Atlassian Marketplace is on the roadmap, this lowers the cost of a first shippable add-on and de-risks a pilot before committing to a full integration platform.
• Framework upgrade planning: release 4.1.0 adds Symfony 6.4 (LTS) and 7.0 compatibility. That unblocks or sustains an upgrade to a supported Symfony line and keeps the integration eligible for security patches — a minor, non-breaking bump that removes an EOL-driven "rewrite or drop the integration" decision from the next planning cycle.
• Vendor and dependency-risk posture: continued (if modest) maintenance activity is a positive signal on a single-maintainer package; the assessment should treat the Atlassian Connect layer as a buy-and-contain dependency, with a fork/exit option priced in rather than assumed away.
• Buy vs. build for adjacent platforms: the same decision framework applies if the team later targets Forge or Data Center, where this package does not apply and the build/buy calculus resets.

Note on fit: this is a Symfony bundle, not a Laravel package. For a Laravel codebase it is consumable but non-idiomatic; budget for adapter work or scope the integration as a separate Symfony service.

When to Consider This Package

Consider it when:

• You are building an Atlassian Connect (Cloud) app in PHP and want descriptor, JWT, and lifecycle handling off the shelf.
• Your stack is Symfony 6.4 or 7.x — 4.1.0 is the release that makes this viable on supported framework versions; earlier lines are effectively gated to older Symfony.
• You want a thin, forkable dependency (permissive license, small surface area) rather than a heavyweight SDK or a hosted integration platform.
• Time-to-first-working-add-on matters more than a bespoke auth layer, e.g. a marketplace pilot, a proof of concept, or an internal Rovo/Atlassian-adjacent tool.
• You can absorb single-maintainer risk through version pinning, contract tests around JWT verification and lifecycle endpoints, and a willingness to vendor the code if upstream stalls.

Look elsewhere when:

• You need Forge (the current Atlassian cloud platform) or Data Center support — Connect-era tooling does not cover these.
• You require commercial support, SLAs, or a security disclosure process; this is a community package.
• Your team is Laravel-first and unwilling to carry Symfony-shaped abstractions — a hand-rolled JWT layer or a Node/Java SDK (ACE, Connect Spring Boot) may cost less total effort.
• You are still on an older Symfony or PHP line and cannot upgrade; 4.1.0 will not help, and staying on 4.0.x means carrying an EOL framework into production.
• The integration is strategically central and needs deep customization of the Connect handshake — at that point you own the code either way.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost open-source component that shortens the path to an Atlassian Marketplace presence by handling the security and lifecycle mechanics every Atlassian Cloud add-on must implement. The new 4.1.0 release is a maintenance update — it adds support for Symfony 6.4 LTS and 7.0 — which means the component stays compatible with a supported, security-patched framework instead of becoming a blocker at our next upgrade. There are no breaking changes and no migration work. The main risk is that it is maintained by a single contributor; we mitigate that by pinning the version, testing the auth and lifecycle paths ourselves, and retaining the option to fork, which is cheap given the small codebase.

For engineering: Treat 4.1.0 as a green light to adopt or stay on the package, and an enabler for the Symfony 6.4/7.0 upgrade. It is a minor, non-breaking release confined to framework compatibility, so no code changes are expected beyond dependency resolution. Pin the version, add integration tests around JWT verification and the install/uninstall lifecycle callbacks, and document the fork procedure. Also note the integration is Symfony-shaped — if we consume it from a Laravel service, isolate it behind a boundary so the framework coupling does not leak into application code.