Laravel Vapor Logs: Getting Papertrail to Actually Work

I had a client running a pretty slick setup on Laravel Vapor. But they had this ghost in the machine—an error that would pop up for users, but we could never replicate it. Sentry would tell us that it broke, but not why. Trying to trace the request through AWS CloudWatch was a nightmare. It’s just not built for that kind of detailed debugging. We needed proper, real-time access to our Laravel Vapor logs.

CloudWatch Isn’t a Log Viewer

Look, if you’re deploying on Vapor, you’re probably sending your logs to AWS CloudWatch using the stderr channel. It’s the default, and it works. But using CloudWatch to actually debug an application is a special kind of hell. It’s a firehose of disconnected data from every single Lambda invocation. Trying to follow a single user’s journey or find a specific transaction is like pulling teeth. It’s a storage bucket, not a diagnostic tool.

My first move was the obvious one: enable the `papertrail` channel in config/logging.php. I figured, set the PAPERTRAIL_URL and PAPERTRAIL_PORT in the environment, and we’re done. Deployed it. Nothing. Total silence. After wasting a good hour checking my ENV variables for typos, I figured it out. Here’s the kicker: Laravel’s default Papertrail handler uses UDP. And AWS Lambda, for its own reasons, blocks all outgoing UDP traffic. So that was a bust.

The Fix: Ditching UDP for TCP

I thought I was going to have to write a custom handler or use some other convoluted solution. But then I remembered an old post from a colleague, which I found again over at carlalexander.ca, who ran into the exact same UDP block on a different serverless platform. The solution wasn’t some complex custom driver; it was just telling Monolog to use a different handler that works over TCP.

You don’t need a new class or package. You just need to tweak your logging.php config file to use the SocketHandler instead of the default. It’s already there in Monolog.

<?php

# config/logging.php

use Monolog\Handler\SocketHandler;

return [

    // ...

    'channels' => [

        // ...

        'papertrail' => [
            'driver' => 'monolog',
            'level' => 'debug',
            'handler' => SocketHandler::class,
            'handler_with' => [
                'connectionString' => 'tls://'.env('PAPERTRAIL_URL').':'.env('PAPERTRAIL_PORT'),
            ],
        ],

        // ...

    ],

];

You’re just swapping out the handler and pointing it to a TLS connection string. On the Papertrail side, it’s literally a checkbox. In your Papertrail account, go to your Log Destinations, and make sure it’s set to accept connections using TCP with TLS. And that was it. Deploy the change, and suddenly you have a beautiful, clean, searchable log stream.

So, What’s the Point?

When you’re working with managed platforms like Laravel Vapor or AWS Lambda, you’re playing in their sandbox. The default tools and configs don’t always account for the platform’s specific constraints. The lesson here is simple: don’t just assume the default method is the only one. When you hit a wall, check if there’s a different protocol or handler you can use. Often, the fix is a lot simpler than you think.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.