An app deployed on Laravel Vapor loses user uploads and file-cache entries between requests; why does that happen, and what should it use instead?

## Why only /tmp **Laravel Vapor** deploys a Laravel app to **AWS Lambda**. A Lambda function runs in an **execution environment**: a short-lived container that AWS starts, reuses for a while, and throws away. The deployed code is mounted read-only; the one writable location is `/tmp`. Two properties of `/tmp` matter: - It is **private to one execution environment**. When traffic rises, Lambda runs many environments side by side, and each has its own `/tmp`. - It is **ephemeral**. When the environment is retired, everything in it is gone. On a Forge-managed server, by contrast, every request shares one persistent disk, so writing to `storage/app` or using the `file` cache store works indefinitely. ## What vapor-core does at boot The runtime stubs shipped in `laravel/vapor-core` (2.47) prepare Laravel for that environment each time a container starts: 1. `StorageDirectories::create()` makes `/tmp/storage/app`, `/tmp/storage/logs`, `/tmp/storage/bootstrap/cache`, `/tmp/storage/framework/cache` and `/tmp/storage/framework/views`. 2. `$app->useStoragePath(StorageDirectories::PATH)` points `storage_path()` at `/tmp/storage`. 3. Secrets from AWS SSM are injected into the environment, and `config:cache` runs so later invocations read one cached config file. 4. The runtime loops over invocations and terminates the container after `VAPOR_MAX_REQUESTS` invocations (250 by default), so even a warm container's `/tmp` has a bounded life. The result is that Laravel keeps working (views compile, logs can be written) but nothing written under storage survives beyond that container. ## Which Laravel features quietly break | Feature | Works on a server because | On Vapor | Use instead | |---|---|---|---| | `Storage::disk('local')` uploads | one persistent disk | lands in `/tmp/storage/app`, lost with the container | the `s3` disk | | `file` cache store | shared directory | each container sees only its own entries | `dynamodb`, `redis` or `database` store | | `file` session driver | shared directory | users appear logged out when routed to another container | `cookie`, `database`, `redis` or `dynamodb` | | Files a queued job reads later | same disk as the web request | the job may run in a different container | pass an S3 path, not a local path | vapor-core helps with one of these: on Vapor it fills `cache.stores.dynamodb` from the environment, defaulting the table name to `cache`, so `CACHE_STORE=dynamodb` works once the table exists. ## Uploads: the signed storage URL flow Sending large files through a Lambda-backed HTTP request is fragile, so vapor-core registers `POST /vapor/signed-storage-url` (in the `web` middleware group by default, and only while the feature is enabled). The flow is: 1. The browser asks that route for an upload URL. The controller calls `Gate::authorize('uploadFiles', [$user, $bucket])`, so the app must define an `uploadFiles` gate. 2. It answers `201` with a pre-signed S3 **PUT** URL, a `uuid`, the bucket and a key under `tmp/`, valid for 5 minutes by default and private by default. 3. The browser PUTs the file straight to S3. 4. The browser tells your controller the key, and the controller copies the object from `tmp/` to its permanent path with the `Storage` facade. The file never touches the function's disk. ## What /tmp is still good for `/tmp` is fine as **scratch space inside one invocation**: unzip an archive, render a PDF, resize an image, then upload the result to S3 before the invocation ends. It is wrong for anything a later request, another container or a queued job must read. ## Container images Vapor can also package an environment as a **container image** instead of an uploaded bundle, usually to add system libraries or PHP extensions or to fit a larger application. The image still runs on Lambda, so the `/tmp`-only rule and everything above apply unchanged; only the packaging differs. ## Auditing an app before moving it Before a first Vapor deploy, search the codebase for anything that assumes a durable local disk: - calls to `Storage::disk('local')`, `storage_path()` or `file_put_contents()` whose output a later request reads; - `CACHE_STORE=file` or `SESSION_DRIVER=file` in the production environment; - queued jobs that receive a local file path instead of an S3 key; - packages that write their own caches or export files under `storage/`. Each one either moves to a shared service or is rewritten to finish its work inside a single invocation. Logs are a special case: anything written to `storage/logs` lands in `/tmp/storage/logs` and disappears with the container, so production logging should use a channel that leaves the function, such as `stderr`.