Sidecar Laravel Package

Product Decisions This Supports

• Build vs. buy for sidecar workloads. Sidecar lets you ship a single Node/Python/Ruby/Java/.NET function from inside your Laravel repo without standing up an extra service, container, or vendor account. That turns "should we pay for a screenshot/OG-image/PDF/SSR vendor?" into a same-day engineering spike rather than a procurement cycle.
• Roadmap sequencing for "polyglot escape hatch" features. Anything blocked on "we don't have a Node/Python runtime in production" (OG image generation, headless Chrome screenshots, PDF rendering, server-side rendering of a JS frontend, a one-off Python data/ML script) becomes schedulable on the existing Laravel roadmap instead of requiring a new platform workstream.
• Scope and headcount decisions. One PHP class plus a folder of files is the entire integration surface. This supports arguing that a feature does not need a dedicated services team, a separate repository, or a new CI/CD pipeline — a Laravel developer owns it end to end.
• Infrastructure consolidation. If the org is already on AWS (or Laravel Vapor), Sidecar reuses existing IAM/Lambda primitives instead of adding a Vercel/Netlify/Cloudflare Workers account. That's a direct reduction in vendor count, secrets surface, and billing relationships.
• Cost modelling for spiky workloads. Image rendering, screenshots, and SSR are bursty and CPU-heavy. Offloading to Lambda means you pay per invocation rather than over-provisioning web workers — useful input for pricing and margin conversations on usage-based features.
• Architecture guardrails. Sidecar explicitly does not do API Gateway, databases, caches, or HTTP invocation. That constraint is itself a decision tool: it keeps the blast radius of "we added a Lambda" small and prevents scope creep into a shadow microservices estate.
• Buy-vs-build exit criteria. Because the integration is a PHP class with a handler() and package(), the switching cost to a managed vendor (or to Vapor's own Lambda tooling) is low. That de-risks the "try it for one feature" decision and makes it cheap to reverse.

When to Consider This Package

Consider it when:

• You have a Laravel (or Vapor) application and need one or two non-PHP functions — not a fleet.
• The workload is naturally request/response and callable from your own app (you don't need a public HTTP endpoint).
• You're already on AWS or prepared to be, and can accept an IAM role/user with Lambda, S3, and (optionally) ECR permissions created for you via sidecar:configure.
• The team is small and values co-location: the function's code, packaging, and deployment live in the same repo and the same artisan commands as the app.
• You want a fast spike to validate a feature (OG images, PDFs, screenshots, SSR) before committing to a vendor contract.
• You need runtime choice — Node 18/20, Python 3.9–3.12, Java 8–21, .NET 6/8, Ruby 3.2/3.3, Amazon Linux OS-only, or container images — and don't want a different deployment story per language.

Look elsewhere when:

• You need public HTTP invocation, API Gateway, queues, databases, or caches — Sidecar explicitly does none of these; you'd be pairing it with Vapor or hand-rolled AWS.
• You want a managed, vendor-supported product with an SLA. This is a ~0.8.x, pre-1.0, single-maintainer package (MIT, ~890 stars, no dependents). Recent history includes breaking changes (default runtime Node 14 → 20, function-naming algorithm changes). Budget for upgrade work and pin versions.
• Your workloads need GPUs, long-running jobs (>15 min), large container images, or heavy concurrency tuning — this is a deployment convenience layer, not a serverless platform.
• You need observability and tracing out of the box (distributed traces, dashboards, alerting). You'd be reading CloudWatch on your own.
• Your org is not on AWS, or policy forbids application code assuming deploy-time IAM permissions from a developer laptop.
• The need is genuinely one-off. If a single script runs monthly, a crontab or a managed job runner is cheaper in cognitive load than a Lambda deployment pipeline.
• You already have a platform team with a sanctioned serverless pattern. Adopting a second, app-level deployment path fragments ownership — go through the platform instead.

How to Pitch It (Stakeholders)

For executives: We can ship several backlog features that are currently blocked on "we'd need to run JavaScript/Python in production" — social preview images, PDF generation, page screenshots, marketing-site SSR — without hiring a services team, signing a new vendor, or adding a platform workstream. Sidecar lets our existing Laravel developers deploy those functions to AWS Lambda from the same repository and the same deploy commands they already use. It's MIT-licensed, free, and small enough that reversing the decision later costs days, not quarters. The trade-off is maturity: it's a pre-1.0, largely single-maintainer open-source package, so we should pin versions, start with one non-critical function, and keep the option to swap in a managed vendor.

For engineering: One PHP class with handler() and package(), one folder of files, php artisan sidecar:deploy --activate, then OgImage::execute([...]) from a controller. Runtimes span Node 18/20, Python 3.9–3.12, Java 8–21, .NET 6/8, Ruby 3.2/3.3, OS-only, and container images. sidecar:configure provisions the AWS role; environment variables, ephemeral storage, architecture selection, warming, version sweeping, and event invocation are all supported. It deliberately does not do API Gateway, databases, or HTTP invocation — this is a deployment convenience layer for the narrow "we need one non-PHP function" case, and it's a good fit for Vapor users who've hit that wall. Plan for a version-pinning policy: historical breaking changes include a default-runtime bump and a function-naming scheme change.

Recommendation: Approve a time-boxed pilot on one low-risk, non-customer-critical function (OG image generation is the canonical example). Success criteria: deploy works from CI, cold-start and p95 latency are acceptable, and CloudWatch errors are visible without new tooling. If the pilot holds, expand to the next two workloads; if the maintenance or observability burden shows up early, the integration surface is small enough to walk away cleanly.