When trying to access your Laravel Cloud-deployed website, a 502 Gateway Error means that Cloudflare, which is used in the networking layer of Laravel Cloud, was unable to reach your application. This can happen when the container serving your application becomes unresponsive. Common issues include:

​
Your environment may be under-provisioned

Depending on the complexity and functionality of your Laravel application, your app may consume more memory than is available in your compute instance. When your application attempts to over-allocate memory than is available, the pod in which your application is deployed temporarily crashes and needs to reboot.

Small compute instances, such as those with 256MB or 512MB RAM are often common culprits for becoming over-allocated.

Common places of high RAM utilization include:

  • Unoptimized queries. Consider using eager loading or chunking when necessary to reduce data stored in memory.
  • High number of active jobs. A large number of jobs, particularly those with large payloads, may consume an excess of memory.
  • Too many queue workers. As each worker consumes memory, requesting many workers may consume more memory than anticipated.
  • Excessive logging / debugging. If your application has APP_DEBUG=true, you should expect higher memory usage through more verbose logging.
  • Inefficient Blade templates. Large, deeply nested Blade templates, and looping Blade directives can increase memory consumption.

Consider using a local development aid like Laravel Telescope, or 3rd party packages such as Laravel Debugbar, to help diagnose memory utilization for your application.

​
Laravel Horizon may be configured improperly

If you are using Laravel Horizon to manage your Redis-backed queues, be mindful of how Horizon spawns workers which can directly impact memory usage in your application.

First, ensure that within your Laravel Cloud application, you configure Horizon to run with a single process (1 process). This is important as Horizon will automatically spawn workers based on the settings within your application’s config/horizon.php file.

Be mindful of how many workers you have defined in your config/horizon.php file via the maxProcesses key. When Horizon starts, it will automatically spawn processes based on this value for each supervisor you define. In some cases, too many workers may cause an overallocation of memory.

'environments' => [
    'production' => [
        'supervisor-1' => [
            'maxProcesses' => 10,
            // ...
        ],
    ],
],

Other considerations:

  • If no jobs are being processed, ensure your config/horizon.php file has a key under environments that matches your APP_ENV value, or includes an * key as a fallback for when no matching environment is found. For more information, refer to the Horizon documentation.
  • Upgrade to Laravel Horizon >=v5.31. Older version of Horizon can be more aggressive in spawning workers on startup. Keep in mind that even if Horizon starts successfully, your application may still crash if spawning the maximum number of workers causes an overallocation of memory.
  • Considering moving your Horizon, or queue:work workers, onto worker clusters separate from your app cluster. This ensures that your application is still reachable, even if your job queues become stressed.
  • Laravel Horizon does not currently support Octane. If your application uses Octane, please use standard queue workers instead of Horizon.

Was this page helpful?