Intermittent "Target class [config] does not exist" during image uploads on Laravel Vapor (AWS Lambda) when Octane enabled

[UtkuDalmaz]

Octane Version

2.13.4

Laravel Version

12.47.0

PHP Version

8.4

What server type are you using?

Swoole

Server Version

1.4.2

Database Driver & Version

No response

Description

Summary

We are running a Laravel application on Laravel Vapor (AWS Lambda, runtime: docker).
When Octane is enabled (octane: true in [vapor.yml], we intermittently hit a fatal error:

Target class [config] does not exist.

The issue disappears immediately when Octane is disabled (octane: false), which strongly suggests a long-running worker / sandbox container state problem rather than broken application upload code.

Environment

• Platform: Laravel Vapor (AWS Lambda), runtime: docker
• PHP: 8.4.15 (Vapor base image / production runtime)
• laravel/framework: v12.47.0
• laravel/octane: v2.13.4
• laravel/vapor-core: v2.43.0
• symfony/http-foundation: v7.4.3
• Build steps include: php artisan config:cache, route:cache, view:cache

[vapor.yml]

• production: octane: false (workaround)

Expected behavior

The service container should always be able to resolve the config binding during request handling.

Actual behavior

When Octane is enabled on Vapor:

• Some requests fail with Target class [config] does not exist.
• This happens intermittently and seems correlated with warm containers / long-running lifecycle.
• Disabling Octane fixes the problem immediately.

Scope / where it happens

This only happens during image upload flows:

• Post image upload
• Chat image sending (general image upload endpoints)

Non-upload endpoints appear stable.

Upload flow details (PostService::createImagePost)

The flow roughly does:

• Read uploaded file from $image->path()
• Detect dimensions via a helper (ImageService::getImageDimensionsWithFallback)
• Process image using Intervention Image (GD/Imagick), generate JPEG + thumbnail in a temp path
• Upload both files to S3 using:
  • Storage::disk('s3')->putFileAs('shared_images/', new File($file), ...)
  • Storage::disk('s3')->putFileAs('shared_images/thumbs/', new File($thumbnailFile), ...)

Frequency / pattern

• Not deterministic locally.
• In production/staging it can happen under repeated image uploads (suggesting a warm worker state corruption).
• Once Octane is disabled, the issue disappears.

What we tried

• Disabling Sanctum / auth changes: no effect
• Upgrading to the latest patch versions listed above: already on latest
• Searching for application code that flushes/unsets container bindings (e.g. forgetInstance('config'), unset($app['config']), $app->flush()): none found
• Workaround: octane: false in Vapor -> fixes immediately

Request

• Is this a known issue for Vapor (AWS Lambda) + Octane?
• Any recommended mitigation/workaround (specific Octane listeners, flush/warm config, etc.)?

Steps To Reproduce

Steps to reproduce

Note: We haven't found a fully deterministic local reproduction. The issue reproduces intermittently on Laravel Vapor (AWS Lambda) with warm containers when Octane is enabled.

1. Deploy the application to Laravel Vapor (AWS Lambda, runtime: docker) with:

   • octane: true
   • warm: 10 (or any warm setting that keeps containers reused)
   • Build caches enabled (php artisan config:cache, route:cache, view:cache).

2. Ensure the environment is receiving traffic and containers stay warm.

3. Trigger image upload requests repeatedly (this is the only place we see the issue):

   • Create a post with an image (uses [PostService::createImagePost], and/or
   • Send an image in chat (any endpoint that uploads an image).

   We reproduce by running a loop that uploads images (same file is ok) for a few minutes.
   (Optional: run multiple clients in parallel to increase frequency.)

4. Observe that occasionally one request fails with:
   Target class [config] does not exist.

5. As a control / workaround:

   • Set octane: false in vapor.yml and redeploy.
   • Repeat the same upload loop.
   • The error no longer occurs.