Getting started

Availability

Sesame is Experimental: a work in progress that may change often and is not ready for production use. It is listed publicly, and like any Experimental marketplace listing, a team can start an install from it.

An install provisions the web app, Postgres and a managed queue, with no scheduler, and enables hibernation so Sesame sleeps between test runs. It generates APP_KEY, runs migrations after each deploy, and turns push-to-deploy off. That install path has not been tested on Laravel Cloud. Use Sesame only against staging.

Never deploy during a test run

Sesame acknowledges each SendEmail from a small SQLite buffer in the instance's temporary directory, then moves it to Postgres right after the response. Laravel Cloud replaces that directory on every deploy, so deploying while a test is running can lose sends from that test. An unexpected instance or process restart can lose them too. In sandbox tests the window was a few milliseconds of traffic.

• Scalpels turns push-to-deploy off so a push to your fork does not redeploy Sesame mid-run. Leave it off and deploy only between runs.
• Lost sends are reported, not hidden. Sesame tells you which accepted message IDs were lost in a replaced buffer, separately from findings about your application, so a run with losses reads as incomplete rather than as a bug in your app. Rerun it.
• A deploy also briefly takes down the URL your webhook fetches Sesame's signing certificate from. Notifications posted in those seconds can fail validation and be dropped, and those drops do look like findings. Another reason to deploy only between runs.

What the proof of concept demonstrated

All of this ran in one disposable sandbox, against a local CRM-compatible harness rather than a real consumer's staging environment:

• A 15-minute plateau at 30 sends a second. 27,000 messages went through a queued job, a Laravel Mailable and the stock ses-v2 mailer to Sesame over HTTPS. Reconciling all 27,000 against Sesame's ground truth found no mismatches. That run used the earlier design; the Cloud-native design, with no scheduler, closed the same loop with real processes. See the Sesame repository's report for its runs.
• The test suite signs every SNS message type and verifies it with the real aws/aws-php-sns-message-validator package. It also covers subscription confirmation, SNS retry rules, redelivery after a lost delivery job, reporting sends lost with a replaced buffer, and the production guard that refuses simulator configuration.

What it has not demonstrated

• Laravel Cloud. No install has run there yet, so after-response draining, delayed managed-queue jobs, hibernation and waking are untested on the platform.
• A real consumer. Growth CRM's staging app has not been pointed at Sesame. Growth currently pins the AWS certificate host and confirms subscriptions through the AWS SNS API, so it needs changes first.
• The runtime decision. The brief chooses between Laravel Octane and Rust by measuring p99 latency at 300 requests a second for 10 minutes. On the sandbox the result was not decidable. Sesame runs on PHP without Octane; if you turn Octane on, its version has to match Cloud's FrankenPHP first.