Laravel Bridge Laravel Package

Product Decisions This Supports

• Hosting/build-vs-buy for Laravel: choosing between SKE, Laravel Cloud, Vapor, Forge plus own infra, or Kubernetes. This package is the concrete integration surface that determines how much platform-specific glue you would otherwise own.
• Migration cost of an existing Laravel app: the provider is auto-discovered and stays inactive off-platform, so the decision is "adopt SKE" rather than "rewrite for SKE." That materially lowers the cost of a pilot or a reversible bet.
• What you stop building in-house: queue driver for SQS/Cloud Tasks, structured stderr logging with request correlation, trusted-proxy config, IAM role credential handling, SES region wiring, dashboard-driven maintenance mode, signed direct-upload endpoint, encrypted per-environment env files, Inertia SSR routing with fallback.
• Roadmap sequencing around platform capabilities: if SKE is the target, the roadmap can assume managed SSR, direct-to-bucket uploads, and dead-letter handling, and not staff those. If SKE is still under evaluation, these become evaluation criteria against alternatives.
• UX/availability risk for Inertia apps: SSR calls go to the platform's SSR server with a time limit and fall back to client-side rendering, logged, on failure. That is a deliberate degradation choice that should be reflected in SLO and incident expectations.
• Secrets management direction: .env.{environment}.encrypted decrypted at boot, without overriding platform- or secret-set variables, sets the baseline for whether a dedicated secrets manager is still needed.
• Vendor optionality: inertiajs/inertia-laravel is optional and the bridge deactivates off-platform, but the ske queue connection, config/ske.php, and SKE_UPLOADS_URL are platform-shaped. Useful as a low-regret trial, not yet as a long-term standard.

When to Consider This Package

Consider it when:

• You are deploying a Laravel 11, 12, or 13 application on PHP 8.3+ and the target runtime is SKE. Outside SKE it adds a dependency for one upload endpoint and little else.
• You want platform-native queues without writing an SQS/Cloud Tasks driver, and you want failed jobs to flow through Laravel's existing exception handler and failed_jobs store, with platform dead-lettering only as fallback.
• You are running Inertia 2 or 3 and want SSR without operating an SSR server, and you accept logged fallback to client-side rendering.
• You want browser-to-bucket uploads via signed PUT URLs and are comfortable authorizing them through an uploadFiles gate.
• You are standardizing log ingestion on JSON-per-line stderr with X-Request-Id correlation.
• You want IAM function-role credentials by default with application-set key pairs still taking precedence.

Look elsewhere when:

• You are not on SKE, or you are evaluating multiple hosts simultaneously and need a neutral abstraction.
• You need a stable 1.x contract. This is v0.1.0; expect breaking changes across the 0.x line and pin exact versions.
• You are on PHP below 8.3 or Laravel 10 or earlier.
• You require control over queue internals, log formatting, or proxy trust beyond what the package fixes.
• You need documented failure semantics, upgrade guides, or a support/SLA commitment before committing — none are evidenced here beyond the docs link.
• Maintenance mode or environment decryption must be driven by your own tooling rather than the SKE dashboard.

How to Pitch It (Stakeholders)

For executives: SKE now has a first-party Laravel runtime bridge. It removes a meaningful amount of undifferentiated plumbing — queues to SQS and Cloud Tasks, structured logs with request correlation, proxy and IAM handling, SES mail, dashboard-driven maintenance mode, signed direct uploads, encrypted env files, and managed Inertia SSR with graceful fallback. The strategic point is reversibility: the package stays inactive off-platform, so adopting SKE is a deployment choice rather than a rewrite. The counterweight is maturity — this is v0.1.0, published without a prior assessment, so treat it as a pilot-grade dependency and budget for churn.

For engineering: the integration is convention-over-configuration and maps cleanly onto Laravel primitives. Queues reuse Laravel's own worker and timeout enforcement, failed jobs go through your exception handler and failed-jobs store, and the platform only takes over as dead letter when no store exists — so existing observability keeps working. Logs are one JSON record per line to stderr, with stack traces and X-Request-Id. AWS credentials prefer the function role including session token, but explicit key pairs still win, which preserves local and CI workflows. Proxy trust is preconfigured. Two things need explicit review before rollout: the uploadFiles gate is the sole authorization boundary for direct uploads and must be defined correctly, and SSR failure is silent-by-design apart from a log line, so alerting must key off that log.

Risks to state plainly: 0.x versioning means breaking changes are expected; there is a single-vendor dependency on SKE's platform behavior (dashboard maintenance mode, SSR server, upload signing); and there is no evidence yet of a documented deprecation or upgrade path. Recommendation: adopt behind a pinned version for a scoped workload, define the uploadFiles gate and SSR-failure alerting up front, and schedule a formal re-assessment at the first 0.x minor release to judge whether the API is stabilizing.