Sst Laravel Laravel Package

Product Decisions This Supports

• Deployment target for a Laravel product on AWS. This package is the glue that lets a Laravel app be deployed through SST (Serverless Stack) using SST's TypeScript-based infrastructure model, rather than standing up bespoke Terraform/CDK or adopting Laravel Vapor. It turns "how do we get PHP onto AWS without a platform team" from a multi-sprint build into a buy/adopt decision.
• Build vs. buy for platform plumbing. The realistic alternative is 2–6 weeks of platform engineering to wire container builds, networking, env injection, queue/scheduler processes, and asset pipelines. Adopting this package is the cheaper experiment; the decision it unlocks is "do we fund a platform team, or do we standardize on SST + this adapter?"
• Secret hygiene and environment parity as a release gate. The 0.7.4 change "Keep the environment out of the container images" moves environment configuration from build time to runtime. That is the difference between secrets being baked into image layers (and pushed to a registry, cacheable, and hard to rotate) and secrets being injected per-environment at deploy/run time. This unblocks security review, SOC 2-style evidence, and per-environment isolation — a decision PMs usually inherit late and expensively.
• Correctness of environment configuration. The companion fix ("leave unset env file outputs out instead of sending undefined") removes a class of silent misconfiguration where an unset key could surface as a literal undefined string in the runtime environment. That is a real "works on staging, fails weirdly in prod" bug class and reduces environment-drift incidents.
• Roadmap items this enables: per-PR preview/staging environments, multi-tenant or per-client isolated deployments (agencies, white-label SaaS), unifying a Laravel backend with an existing TypeScript/SST stack, and cost-per-environment planning.
• Use cases: small-to-mid SaaS on AWS, agency/client portfolios needing repeatable isolated infra, teams already using SST for JS/TS services that want Laravel in the same deployment story, and teams that want containers (Fargate-style) rather than a Lambda-only model.

When to Consider This Package

Consider it when:

• You are already on, or actively evaluating, SST — adopting this without SST makes no sense; it is an adapter, not a deployment platform.
• Your team can tolerate a Node/TypeScript toolchain in CI alongside PHP. If the org is strictly PHP-only and resists JS tooling, this will be friction.
• You want runtime environment injection rather than baking env into images. 0.7.4 makes this the default posture, which is now a selection criterion rather than a caveat.
• You need repeatable, code-defined environments (staging, previews, per-client) and would otherwise hand-roll infrastructure.
• You value containers over Lambda for Laravel (long-running workers, native extensions, predictable memory) but still want infra-as-code.

Look elsewhere when:

• You want a managed, supported Laravel-on-AWS experience with a vendor SLA — Laravel Vapor (Lambda) or Laravel Cloud are the comparison points.
• You need multi-cloud or GCP/Azure; this is AWS-bound through SST.
• You require 1.0-level API stability. This is a 0.x package; treat the config/construct surface as movable and pin versions.
• You need deep networking/VPC/compliance control beyond what the adapter exposes — you will end up dropping to raw SST/CDK anyway, at which point evaluate whether the abstraction earns its place.
• You are on single-VM scale where Forge/Ploi/a $20 droplet is the correct answer. Do not buy serverless complexity for a low-traffic app.
• The project depends on fine-grained secret rotation workflows that your security team insists be solved by a dedicated secrets manager integration you must own.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can deploy our Laravel application to AWS using an open-source adapter on top of SST, the infrastructure tool we would otherwise have to replicate with custom platform engineering. The latest release (0.7.4) removes environment configuration from container images so secrets are injected at runtime instead of being baked into artifacts — a security and compliance improvement, not just a technical one — and fixes a bug where unset environment keys could be passed through as undefined and cause hard-to-diagnose production misconfiguration. Cost to adopt is low and reversible; the main risk is that the package is pre-1.0, so we pin the version and keep the ability to drop into raw SST if we outgrow it.

For engineering: 0.7.4 is a non-breaking patch with two material changes: build-time vs. runtime env separation, and omission of unset env outputs rather than emitting undefined. Upgrade, pin to 0.7.4, and validate on staging that (a) every required key is still present via runtime injection across services (web, queue workers, scheduler), and (b) any intentionally optional/unset keys no longer appear as literal strings. Keep the changelog review in the upgrade ritual while the package is 0.x.

For risk/ops: frame as reversible — a Composer dependency plus SST config — with two watch items: maintenance cadence of the upstream repo and coupling to SST's release line. Track time-to-first-deploy, count of custom infra code we avoid writing, and any secret-in-image findings as the success metrics; both should move in the right direction on first adoption.