DEV Community: Hermann D. Schimpf

What Replaced queue:work in My Laravel App (And Why I Stopped Praying to Supervisor at 3 AM)

Hermann D. Schimpf — Fri, 16 Oct 2026 15:39:41 +0000

Versión en español aquí.

In the previous chapter we figured out where our data lives: files in S3, cache and sessions in DynamoDB, and a NoSQL database that speaks Eloquent. But one question was left hanging in the air: if a Lambda function is born, responds, and dies in milliseconds, who stays awake processing jobs in the background?

On a traditional server, the answer is supervisord babysitting a long-running process. In an ephemeral environment where nothing lives longer than 15 minutes, that recipe simply doesn't work.

In this chapter we're going to replace that daemon with SQS + a Lambda worker. We'll do it in three acts: first the setup (surprisingly short), then the lifecycle of a job (where the magic happens), and finally the topic almost nobody explains in full: what happens when a job fails, who retries it, and where it ends up.

1. The Serverless Treasure Map

Quick recap, so we know where we are:

We already have Lambda running our Laravel app, CloudFront splitting traffic between S3 (assets) and Lambda (the app), and DynamoDB serving as cache, sessions, and our primary database. Today's agenda:

Managing our event queue with SQS,
and a second Lambda function for the Laravel Queue worker.

Remember the component table from the second chapter? Today we cross off this row:

Component	Dedicated Server	AWS Serverless
Event Queue	~~SSH $ `php artisan queue:work` / maybe supervisor~~	SQS + Lambda 🚀

2. Why `queue:work` Doesn't Fit in Serverless

a) How queues work on a traditional server

Oversimplifying a bit, php artisan queue:work is a while (true) loop: it asks the queue if there's any work; if there is, it processes it; if not, it sleeps for a few seconds and asks again. A resident process hogging memory and CPU 24/7, even if the queue has been empty for 3 days.

And because it's a long-running process, it needs a babysitter:

supervisor (or systemd) to resurrect it when it dies.
queue:restart after every deploy, because the process still has the old code loaded in memory.
--max-jobs and --max-time to recycle it before memory leaks turn it into a black hole.
And to scale? More processes → more RAM → bigger instances → all accompanied by a bigger bill.

queue:work is an employee getting paid to hit F5 on their inbox every three seconds. Eight hours a day. Even when nothing comes in.

b) Why that doesn't exist in Lambda

A Lambda invocation lives, at most, for 15 minutes ¹. There is no resident process, no while (true), and nobody asking "got any work?". If you try running queue:work inside a Lambda... it works for 15 minutes, dies, and nobody brings it back. And if you resurrect it with a cron job, you're paying for a Lambda 24/7 just to poll. Congratulations, you just reinvented EC2, only more expensive.

c) Flipping the model: from pull to push

The solution isn't to adapt the worker to Lambda—it's to flip it upside down. Instead of the worker pulling work (pull), the queue invokes the worker when work arrives (push):

Laravel calls dispatch() and pushes the job to SQS.
SQS detects new messages and invokes a Lambda function with those messages.
Lambda processes the jobs, finishes, and disappears.
An empty queue = zero Lambda invocations.

The worker stops being a process that waits and becomes an event that happens.

3. The New Queue Stack: SQS as the Mailbox, Lambda as the Worker

a) SQS in 30 seconds for Laravel devs

Amazon SQS (Simple Queue Service) is a managed message queue ². The bare minimum you need to know:

Message: for us, the serialized JSON payload of the job. The exact same one you'd see in the payload column of the jobs table if you were using the database driver.
Visibility timeout: when someone picks up a message, SQS hides it for X seconds. If nobody deletes it within that window, it reappears so another consumer can try again. It's the equivalent of Laravel's retry_after.
Dead Letter Queue (DLQ): a second queue where SQS moves messages that have failed too many times. The "lost and found box".
Standard vs FIFO: standard queues don't guarantee order (and they're the ones we'll use); FIFO queues do, in exchange for lower throughput.

With the vocabulary out of the way, let's jump into the code.

b) Wiring it up with Serverless Lift

Starting from the serverless.yml we built in the second chapter, we add two environment variables and a Lift construct ³ ⁴:

service: laravel

provider:
  name: aws
  environment:
    # ...
+   QUEUE_CONNECTION: sqs
+   SQS_QUEUE: ${construct:jobs.queueUrl}

functions:
  web:
    handler: Bref\LaravelBridge\Http\OctaneHandler
    runtime: php-85
    # ...

constructs:
  website:
    type: server-side-website
    # ...

+ jobs:
+   type: queue
+   worker:
+     handler: Bref\LaravelBridge\Queue\QueueHandler
+     runtime: php-85
+     timeout: 60  # seconds, the ceiling for the longest job

plugins:
  - ./vendor/bref/bref
  - serverless-lift

QUEUE_CONNECTION: sqs enables the driver Laravel ships with out of the box, and SQS_QUEUE receives the full URL of the queue Lift just created (if you prefer passing only the queue name, you'll also need SQS_PREFIX ³).

Even though on a traditional server the queue runs via CLI with artisan, here we don't use php-85-console. Just like with OctaneHandler, we use the php-85 event runtime with Bref's QueueHandler class.

And what did Lift do behind the scenes with that jobs construct? ⁴

Created the SQS queue.
Created a Dead Letter Queue with a 14-day retention period (the maximum SQS allows).
Created the worker Lambda function with Bref's handler.
Configured the event source mapping: the AWS piece that connects the SQS queue to the Lambda function and invokes it when messages arrive. Our replacement for queue:work.
And granted sqs:SendMessage permission to all functions in the stack ⁵. That's why, unlike the DynamoDB tables from the previous chapter, we didn't have to write a single line of IAM here.

Credentials, just like with DynamoDB, are assigned to each function's execution role. They rotate automatically and nobody ever sees them.

c) New infrastructure, same old code

This is my favorite part. Nothing you've already written has any idea anything changed:

// A job
SendWelcomeEmail::dispatch($user->uuid);

// A queued mailable
Mail::to($user)->queue(new WelcomeMail($user));

// A notification implementing ShouldQueue
$user->notify(new VerifyEmail);

All of that goes to SQS, and a Lambda processes it. ShouldQueue listeners, chained jobs... almost everything works the exact same way. Another point for Laravel's abstraction 💪.

Important: Laravel's SQS driver caps delay() / #[Backoff] at 900 seconds (15 minutes), which is the SQS limit ⁶.

If you need multiple queues (one for urgent emails, another with lower concurrency to avoid hammering an external API, a FIFO queue for strict ordering), each one is an additional queue construct, and since Laravel 13.26 they can be routed with Queue::forward() ⁷.

4. What Actually Happens When You Dispatch a Job?

Up to this point it all looks like magic: we added a block in serverless.yml, called dispatch(), and the job ran. But in production, magic only lasts until the first incident. Let's walk step by step through who does what, from the moment a message enters SQS until it disappears.

a) Laravel dispatches, SQS receives

When you call SendWelcomeEmail::dispatch($user->uuid), Laravel serializes the job and the sqs driver makes a SendMessage call to the SQS API to drop it into the queue. And that's it—our web Lambda has done its part and can finish its execution.

The message body is the same old JSON (displayName, job, data, uuid, attempts). To Laravel, SQS is just another mailbox to drop that exact same envelope into.

b) SQS notifies, Lambda wakes up

The event source mapping that Lift created handles long polling for us ⁸: AWS keeps an internal process polling the queue and, as soon as it detects messages, invokes our worker Lambda function with a batch of up to batchSize messages (Lift defaults this to 1; we'll see why and when to change it shortly). Polling still exists; the difference is that instead of your queue:work process doing it, AWS takes care of it now.

Important: That AWS polling counts as ReceiveMessage calls in SQS, even when the queue is empty. Fortunately, the free tier includes 1 million monthly requests ⁹: with an idle queue, that constant check generates ~21,000 requests per day (~630,000 per month), so you pay nothing.

c) Bref receives the batch, Laravel runs the job

When Lambda wakes up, it hands the SQS event to Bref's QueueHandler ¹⁰. If we peek inside its handleSqs() method (simplified), we can see exactly what happens with each message:

public function handleSqs(SqsEvent $event, Context $context): void
{
    $worker = $this->container->makeWith(Worker::class, [
        'resetScope' => fn () => $this->resetLaravel(),
        // ...
    ]);

    foreach ($event->getRecords() as $sqsRecord) {
        $timeout = $this->calculateJobTimeout($context->getRemainingTimeInMillis());

        $worker->runSqsJob(
            $job = $this->marshalJob($sqsRecord),
            $this->connection,
            $this->gatherWorkerOptions($timeout),
        );

        if (! $job->hasFailed() && ! $job->isDeleted()) {
            $job->delete();
        }
    }
}

Three key details in those few lines:

That Worker is Laravel's. It literally extends Illuminate\Queue\Worker ¹¹. Bref didn't reinvent how to run a job: it passes each message to the exact same engine that queue:work uses. Direct consequence: #[Tries], #[Backoff], $timeout, failed(), middleware, ShouldBeUnique, retryUntil(), and the JobProcessing/JobProcessed/JobFailed events... everything works just like on a traditional server. There's no "supported features" table to check.
State is cleaned up between jobs. That resetLaravel() callback flushes log context, forgets scoped container instances, and clears resolved facades before each run. Why? For the exact same reason we saw with Octane in the second chapter: the Lambda instance (and its PHP process) survives from one job to the next. Without that cleanup, the second job would inherit the in-memory leftovers of the first.
Deleting from SQS is explicit. Only if the job finished without failing does Bref call $job->delete() to remove it from the queue. If it failed or was already deleted (or released back to the queue, as we'll see next), it leaves it alone.

d) Lambda's `timeout` vs. the job's `$timeout`

Did you spot that calculateJobTimeout($context->getRemainingTimeInMillis()) inside the loop? Bref doesn't use a fixed timeout: it checks how many milliseconds the Lambda invocation has left to live (minus a 1-second safety margin) and assigns that time to the job. With that value, the Worker schedules a pcntl_alarm() ¹¹: if the job runs over, the alarm goes off, the process exits with exit(1), and the invocation fails. The job is only marked as failed (and sent to failed_jobs) if you defined #[FailOnTimeout] or $failOnTimeout = true.

Two practical takeaways:

The worker's timeout in serverless.yml is, in practice, the ceiling for the longest job you can process. Set it with your heaviest task in mind.
With a batchSize greater than 1, all jobs in the batch share that same clock: if you process long-running tasks, keep the batch small (or leave it at 1).

Watch out for #[Timeout] / $timeout: If you define a custom timeout on the job class, Laravel overrides the value calculated by Bref. If that number exceeds the time remaining in Lambda, AWS will kill the invocation cold before PHP's alarm ever rings. Recommendation: use a value well below the worker's timeout, especially with batchSize greater than 1, where the last jobs in the batch start with less time available.

5. Who Takes Over When Something Blows Up?

We all love watching the happy path play out by the book: the job comes in, runs, and gets deleted from SQS. But in the real world, external APIs go down, validations fail, and processes run out of memory.

You're probably wondering: "If Lift already created a Dead Letter Queue in SQS and Laravel already has its own failed_jobs table, aren't they doing the exact same thing?"

The answer is no. When we combine Laravel's Worker with SQS and Lambda, two retry and failure mechanisms coexist in the same stack: one on our application side and another on the AWS infrastructure side. And even though they sound similar, they tackle completely different problems.

a) Retries are handled by Laravel, not SQS

Let's start on our application side. Picture an ordinary job configured with retries and backoff:

use Illuminate\Queue\Attributes\Backoff;
use Illuminate\Queue\Attributes\Tries;

#[Tries(3)]
#[Backoff(30)]
final class SendWelcomeEmail implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable;

    public function __construct(public readonly string $user_uuid) {}

    public function handle(): void
    {
        // ... if this throws an exception, Laravel retries in 30 seconds, up to 3 times
    }

    public function failed(Throwable $e): void
    {
        // ... once all 3 attempts are exhausted, Laravel calls this
    }
}

When handle() throws an exception, Laravel's Worker does what it always does: if attempts remain, it calls $job->release(30). And here's the trick. Laravel's native SqsJob simply updates the message's visibility timeout in SQS, but Bref overrides it and does something else ¹²:

public function release($delay = 0)
{
    $this->released = true;

    $payload = $this->payload();
    $payload['attempts'] = ($payload['attempts'] ?? 0) + 1;

    // deletes the original message...
    $this->sqs->deleteMessage([
        'QueueUrl'      => $this->queue,
        'ReceiptHandle' => $this->job['ReceiptHandle'],
    ]);

    // ...and sends a brand-new copy, with the updated attempt counter and backoff delay
    $this->sqs->sendMessage([
        'QueueUrl'     => $this->queue,
        'MessageBody'  => json_encode($payload),
        'DelaySeconds' => $this->secondsUntil($delay),
    ]);
}

It's not "forwarding". It's deleting the email and composing a brand-new one, identical, with [Attempt 2] in the subject line and scheduled to send in 30 seconds.

Why? Because that way the attempt counter travels inside the payload (attempts() reads it from there, not from SQS's ApproximateReceiveCount), and backoff translates into a real DelaySeconds. As a result, #[Tries(3)] and #[Backoff(30)] behave exactly like they do on a server. Bref deliberately chose Laravel's semantics over SQS's ³.

If you don't define #[Tries] / $tries, Bref's handler defaults to 3 ¹³. And if you use exponential backoff (#[Backoff([10, 60, 300])]), that works too: each re-queued message carries the delay corresponding to that attempt.

b) The side effect: SQS never finds out about the failure

When an exception is thrown inside handle(), Laravel's Worker catches it in its own try/catch: it reports it to the logs, decides whether to retry or mark the job as failed, and moves on. Because that exception never bubbles up to handleSqs(), as far as AWS Lambda is concerned, the function succeeded without errors.

This means SQS's native retry mechanism (visibility timeout → maxReceiveCount → DLQ) never finds out that a job failed due to a PHP exception. Not on the first attempt, and not on the third.

Laravel is that teammate who says "all good" in the daily standup while production is on fire. And SQS believes them.

c) First layer: when the job exhausts its attempts in Laravel

When a job fails for the third time and runs out of attempts, Laravel gives up: it calls the class's failed() method and records the failure using the driver configured in config/queue.php (queue.failed).

The problem is that, by default, Laravel tries to save that record in a failed_jobs table inside a SQL database... which we said goodbye to in the previous chapter. Without a relational database, the quick way out is to disable it altogether with QUEUE_FAILED_DRIVER: null ³: the exception still ends up in CloudWatch logs, but the job itself isn't stored anywhere. I don't recommend it.

The good news is that Laravel already includes native support for storing failed_jobs in DynamoDB ¹⁴. We only need to tweak config/queue.php:

'failed' => [
    'driver' => env('QUEUE_FAILED_DRIVER', 'database-uuids'),
    // When using driver=dynamodb there's no need to specify 'database'
    // 'database' => env('DB_CONNECTION', 'sqlite'),
    'key'    => env('AWS_ACCESS_KEY_ID'),
    'secret' => env('AWS_SECRET_ACCESS_KEY'),
    'token'  => env('AWS_SESSION_TOKEN'),
    'region' => env('AWS_DEFAULT_REGION', 'us-east-1'),
    'table'  => env('DYNAMODB_FAILED_JOBS_TABLE', 'failed_jobs'),
],

provider:
    environment:
        QUEUE_FAILED_DRIVER: dynamodb
        DYNAMODB_FAILED_JOBS_TABLE: !Ref FailedJobsTable

And we declare the table under resources in serverless.yml. Laravel uses application as the partition key (the app name) and uuid as the sort key:

FailedJobsTable:
    Type: AWS::DynamoDB::Table
    Properties:
        TableName: failed_jobs
        BillingMode: PAY_PER_REQUEST
        AttributeDefinitions:
            - { AttributeName: application, AttributeType: S }
            - { AttributeName: uuid,        AttributeType: S }
        KeySchema:
            - { AttributeName: application, KeyType: HASH }
            - { AttributeName: uuid,        KeyType: RANGE }
        TimeToLiveSpecification:
            AttributeName: expires_at
            Enabled: true

Just like we did in the previous chapter for the cache and session tables, we use TimeToLiveSpecification; Laravel saves each failed job with an expiration timestamp (expires_at, 7 days by default ¹⁴). This driver doesn't even implement queue:flush: DynamoDB takes care of cleaning up expired records automatically.

Finally, we grant the execution role permissions on the table:

provider:
    iam:
        role:
            statements:
                -   Effect: Allow
                    Resource: !GetAtt FailedJobsTable.Arn
                    Action:
                        - dynamodb:PutItem
                        - dynamodb:Query
                        - dynamodb:GetItem
                        - dynamodb:DeleteItem

To list or retry failed jobs—since there's no SSH in Lambda—we use the bref:cli bridge we saw in the second chapter:

serverless bref:cli --args="queue:failed"
serverless bref:cli --args="queue:retry all"

"Wait, so what is the DLQ that Lift created even for?"

d) Second layer: when the infrastructure fails

A message only reaches the Dead Letter Queue when the entire Lambda invocation fails, without giving Laravel a chance to catch the error. For example:

A job exceeded the remaining invocation time (pcntl_alarm went off and execution terminated with exit(1)).
It ran out of memory (OOM).
A fatal PHP error outside the scope of the Worker.
A boot failure: a missing extension, a configuration error, a composer install that left something out.

In any of these scenarios, Lambda dies before Bref can delete the message, so SQS's native mechanism kicks in:

Wait (visibility timeout): the message stays hidden until its visibility timeout expires. Lift automatically sets it to 6 times the worker's timeout following AWS's recommendation ¹⁵ (with the 60 seconds from our example, it reappears after 6 minutes).
Retry: once visible again, SQS hands it back to Lambda.
Off to the DLQ: if the invocation fails 3 times in a row (maxRetries by default in Lift), SQS removes the message from the main queue and stores it in the Dead Letter Queue for up to 14 days, preventing it from being lost.

To inspect what landed in the DLQ or re-queue it without opening the AWS console, Lift gives us these commands ¹⁶:

serverless jobs:logs --tail      # live worker logs
serverless jobs:failed           # inspect messages in the DLQ
serverless jobs:failed:retry     # move everything back to the main queue
serverless jobs:failed:purge     # delete everything and move on with life

Of course, nobody wants to run serverless jobs:failed every day just in case. If you add the alarm property to the construct, Lift automatically sets up a CloudWatch alarm that sends you an email as soon as a message lands in the DLQ ⁴:

constructs:
    jobs:
        type: queue
        # ...
        alarm: alerts@my-domain.com  # email alert when the DLQ receives messages

After the first serverless deploy, AWS will send a confirmation email to the address configured in alarm (don't forget to confirm it to activate the alerts).

e) The two layers, side by side

	First layer: `failed_jobs`	Second layer: SQS DLQ
What failed?	Our code: exception in `handle()`	Infrastructure: timeout, OOM, fatal error
Who retries?	Laravel (`#[Tries]`, `#[Backoff]`)	SQS (visibility timeout, `maxRetries`)
What gets retried?	That job, after configured `backoff`	The in-flight job and rest of batch (6× timeout)
Where does it end?	`failed_jobs` table (DynamoDB, 7d)	Dead Letter Queue (SQS, 14 days)
How do I retry it?	`bref:cli --args="queue:retry ..."`	`serverless jobs:failed:retry`
How do I find out?	`failed()`, CloudWatch, `queue:failed`	Email alert (`alarm:`)

Take a look at the What gets retried? row in the second layer. When Lambda dies mid-batch (due to timeout or OOM), the jobs that had already finished were deleted one by one with $job->delete(), so they don't run again. SQS only re-delivers what remained undeleted: the job that was halfway through execution and the ones waiting behind it in the batch.

The danger lies in that half-finished job: when SQS retries it, it will run again from the very beginning. If it had already charged a credit card or sent an email a second before Lambda died and isn't idempotent, it will do it a second time (and you'll get acquainted with the word "refund" much sooner than you'd like).

Golden rule: always design idempotent jobs.

6. Tuning the Worker Knobs for Production

The 8 lines from section 3 are enough to get started, but now that we know what happens under the hood, we can tune the knobs for production. Here's what a battle-tested configuration looks like:

constructs:
    jobs:
        type: queue
        maxRetries: 5       # queue maxReceiveCount: AWS recommends >= 5
        maxConcurrency: 20  # the "clean" brake: Lambda stops polling, messages wait
        worker:
            handler: Bref\LaravelBridge\Queue\QueueHandler
            runtime: php-85
            layers:
                - ${bref-extra:gd-php-85}
            reservedConcurrency: 25  # hard cap & reservation; always >= maxConcurrency
            timeout: 300
        batchSize: 10

a) `timeout`: the ceiling for the longest job

It defines both the maximum duration of an invocation and the queue's visibility timeout in SQS (which Lift multiplies by 6). In my case I bumped it to 300 seconds because the worker processes heavy images, and resizing a 20 MB photo takes time. If your jobs only send emails or call an API, 30 or 60 seconds is more than enough.

b) `batchSize`: fewer invocations, more responsibility

Lift leaves it at 1 by default to keep error handling simple ¹⁷. Raising it to 10 means a burst of 500 jobs is processed in 50 invocations instead of 500, reducing cold-starts and costs. In exchange, remember the two conditions we covered earlier: all jobs in the batch share the same Lambda clock, and our jobs must be idempotent in case an invocation dies mid-batch.

There's also maxBatchingWindow: how many seconds SQS waits to gather a full batch before invoking Lambda. Zero by default. If you don't mind a job waiting a few seconds for company to arrive, you can raise it.

c) `reservedConcurrency` vs `maxConcurrency`

If 1,000 jobs arrive at once, Lambda scales up fast to hundreds of simultaneous invocations. And that sounds wonderful until those 1,000 jobs slam into a rate-limited external API, our SMTP server, or DynamoDB itself all at the same time.

There are two ways to put a ceiling on it:

reservedConcurrency (function property): the function never runs more than N simultaneous instances. But it also reserves those N from your account's total concurrency quota, even when sitting idle ¹⁸.
maxConcurrency (Lift construct property): limits how many concurrent invocations this queue's event source mapping can trigger, without reserving anything ¹⁹.

The sweet spot is combining both: maxConcurrency as a clean brake (messages wait in the queue without burning attempts) and reservedConcurrency slightly above it, as a safety net in case a bug dispatches jobs in an infinite loop.

Heads up: if you use only reservedConcurrency, anything above that limit gets throttled, and every rejection counts as a delivery attempt in SQS. With maxRetries: 3 (Lift's default), a traffic spike can send jobs straight to the DLQ without ever having executed once. That's why AWS recommends setting maxRetries to at least 5 ²⁰.

d) `memorySize`: more memory is also more CPU

As we saw in the second chapter, CPU power in Lambda scales proportionally with allocated memory. A heavy job that takes 10 seconds with 512 MB might finish in 3 seconds with 1,769 MB; and since AWS bills per GB-second, giving it more memory often ends up being cheaper. If your worker does CPU-intensive work, you can assign its own memorySize and find the sweet spot with aws-lambda-power-tuning ²¹.

e) Tailored layers: extensions only where needed

Did you notice the ${bref-extra:gd-php-85} layer in the configuration? My worker needs the GD extension to process images, but the web HTTP function doesn't. Because they are separate Lambda functions, each one loads only the extensions it actually uses: web requests stay lightweight, and the extra weight is carried exclusively by the background worker.

f) Does the worker need a warmer?

In the second chapter we set up a warmer every 5 minutes to avoid cold-starts on web requests. Does the worker need one? Not at all. A 200 ms cold-start on an HTTP route is felt by a user staring at a loading screen; in a background queue, an extra 200 ms won't keep anyone up at night.

7. What Tutorials Don't Tell You (and You Find Out in Production)

Things that aren't in the docs (or were buried in the fine print and I learned the hard way):

a) `SerializesModels` and DynamoDB composite keys

Did you notice that in SendWelcomeEmail (section 5.a) I passed $user_uuid as a string instead of the User model? That wasn't an accident. SerializesModels stores only getKey() (PK) and tries to restore the model with a traditional SQL query that doesn't include the SK or support DynamoDB.

For your own jobs, the simplest approach is passing the uuid to the constructor and fetching the model inside handle(). However, if you use queued notifications ($user->notify()), Laravel serializes the User model whether you like it or not: in that case, you have no choice but to override getQueueableId() and newQueryForRestoration() on your model to encode and reconstruct PK + SK.

b) `Bus::batch()` also needs somewhere to store its progress

By default it looks for the relational job_batches table, but Laravel includes native DynamoDB support: you just need to create the job_batches table (partition key application, sort key id), grant IAM permissions, and set queue.batching.driver to dynamodb ²².

c) Your local environment doesn't need to touch AWS

Since our job code doesn't change based on the driver, on your machine you can keep using QUEUE_CONNECTION=database (or sync) with good old queue:work, or emulate SQS locally with tools like MiniStack ²³ or LocalStack ²⁴. QUEUE_CONNECTION=sqs pointing to AWS is only needed in serverless.yml.

d) The limit is 1 MiB per message

That's SQS's hard limit ²⁵. Jobs should carry lightweight identifiers, not base64-encoded files or collections of 10,000 items. If you're anywhere near that limit, your design is screaming at you to have the job fetch the data when it runs instead of receiving it in the payload.

e) The AWS SDK cleanup from the second chapter

If you used aws/aws-sdk-php with removeUnusedServices in composer.json to shrink your deploy size, make sure to add Sqs to the list of allowed services:

"extra": {
    "aws/aws-sdk-php": [
        "DynamoDb",
        "S3",
        "Sqs"
    ]
}

Why is it so easy to forget? Because tests run with QUEUE_CONNECTION=sync or Queue::fake(), so CI passes everything in green without ever instantiating SqsClient... until the first real dispatch() in production blows up because the class was stripped out.

8. Costs: The Worker That Only Charges When It Works

Let's update the tab, just like in every chapter.

Before (EC2): the worker lived on one of the t3.small instances from the first chapter (~$15/month per instance). A resident queue:work process with reserved RAM and supervisord running 24/7, even when the queue spent 90% of the day empty.
Now (SQS + Lambda):
- SQS: the first million monthly requests are free; after that it costs \$0.40 per million ²⁶. Adding up the ~630,000 requests from idle polling and 3 requests per job (SendMessage, ReceiveMessage, and DeleteMessage), you can process up to ~120,000 jobs per month for $0.00.
- Lambda: the perpetual free tier includes 1 million invocations and 400,000 GB-seconds per month. With no jobs in the queue, compute costs literally zero.

Let's put numbers on a month with 100,000 jobs (averaging ~500 ms with 512 MB of RAM):

Item	Within Free Tier	Full Price (no Free Tier)
SQS Polling (~630k req/mo)	$0.00	$0.25
SQS Messages (300k req/mo)	$0.00	$0.12
Lambda Worker (100k jobs)	$0.00	$0.44
Monthly total	$0.00	~$0.81

Even without the free tier, processing 100,000 jobs costs less than a dollar a month!

And most importantly: with DynamoDB on PAY_PER_REQUEST, Lambda billing per millisecond, and SQS billing per request, almost no component in the queue system charges a flat fee just for existing (except for SQS polling, which in my case falls within the free tier).

9. What's Next?

Today we retired supervisord and the 24/7 queue:work process for good: we replaced them with an SQS queue and a Lambda worker that only wakes up when there's work to do. We saw how Bref reuses Laravel's own Worker (so our jobs don't change), how its release() trick preserves retries and backoff, and how failed_jobs in DynamoDB coexists with SQS's Dead Letter Queue.

But there's still a loose end between the previous chapter and this one. In section 6 I mentioned that my worker loads the GD extension to resize images; now, if in the previous chapter we saw that files travel straight from the browser to S3 without touching our application... who tells Laravel that a file finished uploading so it can queue that job?

In the next chapter we'll close that loop with S3 Event Notifications, and we'll see why the solution is not wiring S3 directly to the queue we just built.

A question for you: what are you running your Laravel queues on in production today, or what was the worst stunt a queue worker ever pulled on you at 3 AM? Let me know in the comments: the best production war stories come from there, not from post-mortems.

Qué Reemplazó a queue:work en Mi Aplicación Laravel (Y Por Qué Dejé de Rezarle a Supervisor a las 3 AM)

Hermann D. Schimpf — Fri, 16 Oct 2026 15:32:47 +0000

English version here.

En el capítulo anterior resolvimos dónde viven los datos: archivos en S3, caché y sesiones en DynamoDB, y una base de datos NoSQL que habla Eloquent. Pero quedó una pregunta flotando en el aire: si una función Lambda nace, responde y muere en milisegundos, ¿quién se queda despierto procesando los jobs en segundo plano?

En un servidor tradicional la respuesta es supervisord vigilando un proceso eterno. En un entorno efímero donde nada vive más de 15 minutos, esa receta simplemente no aplica.

En este capítulo vamos a reemplazar ese daemon por SQS + un worker en Lambda. Lo haremos en tres actos: primero la configuración (sorprendentemente corta), después el ciclo de vida de un job (donde está la magia), y finalmente el tema que casi nadie explica completo: qué pasa cuando un job falla, quién lo reintenta, y dónde termina.

1. El Mapa del Tesoro Serverless

Rápido, para ubicarnos:

Ya tenemos Lambda ejecutando nuestra App Laravel, CloudFront repartiendo tráfico entre S3 (assets) y Lambda (la app), y DynamoDB como caché, sesiones y nuestra base de datos principal. Hoy toca:

Gestionar nuestra cola de eventos con SQS,
y una segunda función Lambda para el worker de Laravel Queue.

¿Recuerdan la tabla de componentes del segundo capítulo? Hoy tachamos esta fila:

Componente	Servidor Dedicado	AWS Serverless
Cola de Eventos	~~SSH $ `php artisan queue:work` / quizás supervisor~~	SQS + Lambda 🚀

2. Por Qué `queue:work` No Encaja en Serverless

a) Cómo funciona la cola en un servidor tradicional

Simplificando mucho, php artisan queue:work es un while (true): le pregunta a la cola si hay trabajo; si hay, lo procesa; si no, duerme unos segundos y vuelve a preguntar. Un proceso residente que ocupa memoria y CPU las 24 horas, aunque la cola esté vacía desde hace 3 días.

Y como es un proceso, necesita niñera:

supervisor (o systemd) para resucitarlo cuando muere.
queue:restart después de cada deploy, porque el proceso tiene el código viejo cargado en memoria.
--max-jobs y --max-time para reciclarlo antes de que los memory leaks lo conviertan en un agujero negro.
¿Y para escalar? Más procesos → más RAM → instancias más grandes → todo acompañado de una factura mayor.

queue:work es un empleado al que le pagan por presionar F5 en la bandeja de entrada cada tres segundos. Ocho horas. Aunque no llegue nada.

b) Por qué eso no existe en Lambda

Una invocación de Lambda vive, como máximo, 15 minutos ¹. No hay proceso residente, no hay while (true), no hay nadie preguntando "¿hay trabajo?". Si intentan correr queue:work dentro de una Lambda... funciona 15 minutos, muere, y nadie lo resucita. Y si lo resucitan con un cron, están pagando una Lambda las 24 horas para hacer polling. Felicidades, reinventaron EC2, pero más caro.

c) La inversión del modelo: de pull a push

La solución no es adaptar el worker a Lambda, es darlo vuelta. En vez de que el worker busque trabajo (pull), la cola invoca al worker cuando hay trabajo (push):

Laravel hace dispatch() y registra el job en SQS.
SQS detecta que hay mensajes e invoca a una función Lambda con esos mensajes.
Lambda procesa los jobs, termina y desaparece.
Una cola vacía = cero invocaciones Lambda.

El worker deja de ser un proceso que espera y pasa a ser un evento que ocurre.

3. El Nuevo Stack de Colas: SQS como Buzón, Lambda como Worker

a) SQS en 30 segundos para devs Laravel

Amazon SQS (Simple Queue Service) es una cola de mensajes administrada ². Lo mínimo que necesitan saber:

Mensaje: para nosotros, el payload JSON serializado del job. El mismo que verían en la columna payload de la tabla jobs si usaran el driver database.
Visibility timeout: cuando alguien toma un mensaje, SQS lo oculta durante X segundos. Si en ese tiempo nadie lo borra, reaparece para que otro lo intente. Es el equivalente al retry_after de Laravel.
Dead Letter Queue (DLQ): una segunda cola donde SQS mueve los mensajes que fallaron demasiadas veces. La "caja de objetos perdidos".
Standard vs FIFO: las colas estándar no garantizan orden (y son las que vamos a usar); las FIFO sí, a cambio de menos throughput.

Con el vocabulario listo, pasemos al código.

b) Conectando los cables con Serverless Lift

Partimos del serverless.yml que construimos en el segundo capítulo y agregamos dos variables de entorno y un construct de Lift ³ ⁴:

service: laravel

provider:
  name: aws
  environment:
    # ...
+   QUEUE_CONNECTION: sqs
+   SQS_QUEUE: ${construct:jobs.queueUrl}

functions:
  web:
    handler: Bref\LaravelBridge\Http\OctaneHandler
    runtime: php-85
    # ...

constructs:
  website:
    type: server-side-website
    # ...

+ jobs:
+   type: queue
+   worker:
+     handler: Bref\LaravelBridge\Queue\QueueHandler
+     runtime: php-85
+     timeout: 60  # segundos, el techo del job más largo

plugins:
  - ./vendor/bref/bref
  - serverless-lift

QUEUE_CONNECTION: sqs activa el driver que Laravel ya trae de fábrica, y SQS_QUEUE recibe la URL completa de la cola que Lift acaba de crear (si prefieren pasar solo el nombre, van a necesitar también SQS_PREFIX ³).

Aunque en un servidor tradicional la cola se corre por CLI con artisan, acá no usamos php-85-console. Al igual que con OctaneHandler, usamos el runtime de eventos php-85 con la clase QueueHandler de Bref.

¿Y qué hizo Lift por detrás con ese construct jobs? ⁴

Creó la cola SQS.
Creó una Dead Letter Queue con retención de 14 días (el máximo que permite SQS).
Creó la función Lambda worker con el handler de Bref.
Configuró el event source mapping: la pieza de AWS que conecta la cola SQS con la función Lambda, y la invoca cuando hay mensajes. Nuestro reemplazo de queue:work.
Y le dio permiso sqs:SendMessage a todas las funciones del stack ⁵. Por eso, a diferencia de las tablas DynamoDB del capítulo anterior, acá no escribimos ni una línea de IAM.

Las credenciales, al igual que con DynamoDB, las tiene asignadas el rol de ejecución de cada función. Rotan solas y nadie las ve.

c) Nueva infraestructura, el mismo código de siempre

Esta es la parte que más me gusta. Nada de lo que ya escribieron se entera del cambio:

// Un job
SendWelcomeEmail::dispatch($user->uuid);

// Un mail encolado
Mail::to($user)->queue(new WelcomeMail($user));

// Una notificación que implementa ShouldQueue
$user->notify(new VerifyEmail);

Todo eso va a SQS, y una Lambda lo procesa. Los listeners ShouldQueue, los jobs encadenados... casi todo sigue funcionando igual. Otro punto a favor para la abstracción de Laravel 💪.

Importante: El driver SQS de Laravel limita el delay() / #[Backoff] hasta 900 segundos (15 minutos), que es el límite de SQS ⁶.

Si necesitan varias colas (una para emails urgentes, otra con menos concurrencia para no reventar una API externa, una FIFO para procesar en orden), cada una es un construct queue adicional, y desde Laravel 13.26 se enrutan con Queue::forward() ⁷.

4. ¿Qué Pasa Realmente Cuando Despachan un Job?

Hasta acá todo parece magia: configuramos un bloque en serverless.yml, hicimos dispatch() y el job se ejecutó. Pero en producción la magia dura hasta el primer incidente. Veamos paso a paso quién hace qué, desde que el mensaje entra a SQS hasta que desaparece.

a) Laravel despacha, SQS recibe

Cuando llaman a SendWelcomeEmail::dispatch($user->uuid), Laravel serializa el job y el driver sqs ejecuta una llamada SendMessage a la API de SQS para dejarlo en la cola. Y listo; nuestra Lambda web ya cumplió su parte y puede terminar su ejecución.

El cuerpo del mensaje es el JSON de siempre (displayName, job, data, uuid, attempts). Para Laravel, SQS es solo otro buzón donde depositar ese mismo sobre.

b) SQS avisa, Lambda despierta

El event source mapping que creó Lift hace el long polling por nosotros ⁸: AWS mantiene un proceso interno consultando la cola y, apenas detecta mensajes, invoca a nuestra función Lambda worker con un lote de hasta batchSize mensajes (Lift lo deja en 1 por defecto; ya veremos por qué y cuándo cambiarlo). El polling sigue existiendo; la diferencia es que, en vez del proceso queue:work, ahora AWS se encarga de hacerlo.

Importante: Ese polling de AWS cuenta como llamadas ReceiveMessage en SQS, incluso con la cola vacía. Por suerte, la capa gratuita incluye 1 millón de requests mensuales ⁹: con la cola en reposo, ese chequeo constante genera ~21.000 requests por día (~630.000 al mes), por lo que no pagan nada.

c) Bref recibe el lote, Laravel ejecuta el job

Cuando Lambda despierta, le entrega el evento de SQS al QueueHandler de Bref ¹⁰. Si espiamos su método handleSqs() (simplificado) se ve exactamente qué pasa con cada mensaje:

public function handleSqs(SqsEvent $event, Context $context): void
{
    $worker = $this->container->makeWith(Worker::class, [
        'resetScope' => fn () => $this->resetLaravel(),
        // ...
    ]);

    foreach ($event->getRecords() as $sqsRecord) {
        $timeout = $this->calculateJobTimeout($context->getRemainingTimeInMillis());

        $worker->runSqsJob(
            $job = $this->marshalJob($sqsRecord),
            $this->connection,
            $this->gatherWorkerOptions($timeout),
        );

        if (! $job->hasFailed() && ! $job->isDeleted()) {
            $job->delete();
        }
    }
}

Tres detalles clave en esas pocas líneas:

Ese Worker es el de Laravel. Literalmente extiende de Illuminate\Queue\Worker ¹¹. Bref no reinventó cómo correr un job: le pasa cada mensaje al mismo motor que usa queue:work. Consecuencia directa: #[Tries], #[Backoff], $timeout, failed(), middlewares, ShouldBeUnique, retryUntil() y los eventos JobProcessing/JobProcessed/JobFailed... todo funciona igual que en un servidor tradicional. No hay una tabla de "features soportadas" que consultar.
Entre job y job se limpia el estado. Ese callback resetLaravel() vacía el contexto de logs, olvida las instancias scoped del contenedor y limpia las facades resueltas antes de cada ejecución. ¿Por qué? Por la misma razón que vimos con Octane en el segundo capítulo: la instancia de Lambda (y su proceso PHP) sobrevive entre un job y el siguiente. Sin esa limpieza, el segundo job heredaría la basura en memoria del primero.
El borrado en SQS es explícito. Solo si el job terminó sin fallar, Bref llama a $job->delete() para quitarlo de la cola. Si falló o ya fue eliminado (o liberado de vuelta a la cola, como veremos enseguida), no lo toca.

d) El `timeout` de Lambda vs. el `$timeout` del job

¿Vieron ese calculateJobTimeout($context->getRemainingTimeInMillis()) en el loop? Bref no usa un timeout fijo: consulta cuántos milisegundos le quedan de vida a la invocación de Lambda (menos 1 segundo de margen) y le asigna ese tiempo al job. Con ese valor, el Worker programa un pcntl_alarm() ¹¹: si el job se pasa, suena la alarma, el proceso termina con exit(1) y la invocación falla. El job solo se marca como fallido (y va a failed_jobs) si definieron #[FailOnTimeout] o $failOnTimeout = true.

Dos implicaciones prácticas:

El timeout del worker en serverless.yml es, en la práctica, el techo del job más largo que pueden procesar. Configúrenlo pensando en su tarea más pesada.
Con un batchSize mayor a 1, todos los jobs del lote comparten ese mismo reloj: si procesan tareas largas, conviene mantener un lote pequeño (o dejarlo en 1).

Ojo con #[Timeout] / $timeout: Si definen un timeout propio en la clase del job, Laravel pisa el valor calculado por Bref. Si ese número supera el tiempo que le queda a Lambda, AWS matará la invocación en seco antes de que suene la alarma de PHP. Recomendación: usen un valor bastante menor al timeout del worker, sobre todo con batchSize mayor a 1, donde los últimos jobs del lote arrancan con menos tiempo disponible.

5. ¿Quién Se Hace Cargo Cuando Algo Explota?

A todos nos gusta ver cuando el camino feliz se cumple al pie de la letra: el job entra, se ejecuta y se borra de SQS. Pero en el mundo real las APIs externas se caen, las validaciones fallan y los procesos se quedan sin memoria.

Seguramente se estarán preguntando: "Si Lift ya nos creó una Dead Letter Queue en SQS y Laravel ya tiene su propia tabla failed_jobs, ¿acaso no están haciendo lo mismo?"

La respuesta es no. Cuando combinamos el Worker de Laravel con SQS y Lambda, aparecen dos mecanismos de reintento y fallo conviviendo en el mismo stack: uno del lado de nuestra aplicación y otro del lado de la infraestructura de AWS. Y aunque suenen parecidos, atacan problemas completamente distintos.

a) Los reintentos los maneja Laravel, no SQS

Empecemos por el lado de nuestra aplicación. Imaginen un job común y corriente configurado con reintentos y backoff:

use Illuminate\Queue\Attributes\Backoff;
use Illuminate\Queue\Attributes\Tries;

#[Tries(3)]
#[Backoff(30)]
final class SendWelcomeEmail implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable;

    public function __construct(public readonly string $user_uuid) {}

    public function handle(): void
    {
        // ... si esto lanza una excepción, Laravel reintenta en 30 segundos, hasta 3 veces
    }

    public function failed(Throwable $e): void
    {
        // ... agotados los 3 intentos, Laravel llama acá
    }
}

Cuando handle() lanza una excepción, el Worker de Laravel hace lo de siempre: si quedan intentos, llama a $job->release(30). Y acá está el truco. El SqsJob nativo de Laravel simplemente modifica el visibility timeout del mensaje en SQS, pero Bref lo sobreescribe y hace otra cosa ¹²:

public function release($delay = 0)
{
    $this->released = true;

    $payload = $this->payload();
    $payload['attempts'] = ($payload['attempts'] ?? 0) + 1;

    // borra el mensaje original...
    $this->sqs->deleteMessage([
        'QueueUrl'      => $this->queue,
        'ReceiptHandle' => $this->job['ReceiptHandle'],
    ]);

    // ...y envía una copia nueva, con el contador de intentos y el delay del backoff
    $this->sqs->sendMessage([
        'QueueUrl'     => $this->queue,
        'MessageBody'  => json_encode($payload),
        'DelaySeconds' => $this->secondsUntil($delay),
    ]);
}

No es un "reenviar". Es borrar el correo y redactar uno nuevo, idéntico, con [Intento 2] en el asunto y programado para dentro de 30 segundos.

¿Por qué? Porque así el contador de intentos viaja dentro del payload (attempts() lo lee de ahí, no del ApproximateReceiveCount de SQS), y el backoff se traduce a un DelaySeconds real. Resultado: #[Tries(3)] y #[Backoff(30)] se comportan exactamente como en un servidor. Bref eligió deliberadamente la semántica de Laravel por sobre la de SQS ³.

Si no definen #[Tries] / $tries, el handler de Bref usa 3 por defecto ¹³. Y si usan backoff exponencial (#[Backoff([10, 60, 300])]), también funciona: cada reenvío lleva el delay que corresponde a ese intento.

b) El efecto secundario: SQS nunca se entera del fallo

Cuando en handle() se lanza una excepción, el Worker de Laravel la atrapa en su propio try/catch: la reporta en los logs, decide si reintenta o da el job por perdido, y sigue de largo. Como esa excepción nunca llega hasta handleSqs(), para AWS Lambda la función terminó sin errores.

Esto significa que el mecanismo nativo de reintentos de SQS (visibility timeout → maxReceiveCount → DLQ) jamás se entera de que un job falló por una excepción de PHP. Ni en el primer intento, ni en el tercero.

Laravel es ese compañero que en la daily dice "todo bien" con producción en llamas. Y SQS le cree.

c) Primera capa: cuando el job agota sus intentos en Laravel

Cuando un job falla por tercera vez y agota sus intentos, Laravel se rinde: ejecuta el método failed() de la clase y registra el fallo usando el driver configurado en config/queue.php (queue.failed).

El problema es que, por defecto, Laravel intenta guardar ese registro en una tabla failed_jobs de una base de datos SQL... de la cual nos despedimos en el capítulo anterior. Sin base relacional, la salida rápida es desactivarlo completamente con QUEUE_FAILED_DRIVER: null ³: la excepción igual queda en los logs de CloudWatch, pero el job no se guarda en ningún lado. No lo recomiendo.

La buena noticia es que Laravel ya incluye soporte nativo para guardar failed_jobs en DynamoDB ¹⁴. Solo debemos ajustar config/queue.php:

'failed' => [
    'driver' => env('QUEUE_FAILED_DRIVER', 'database-uuids'),
    // Al utilizar driver=dynamodb no es necesario especificar 'database'
    // 'database' => env('DB_CONNECTION', 'sqlite'),
    'key'    => env('AWS_ACCESS_KEY_ID'),
    'secret' => env('AWS_SECRET_ACCESS_KEY'),
    'token'  => env('AWS_SESSION_TOKEN'),
    'region' => env('AWS_DEFAULT_REGION', 'us-east-1'),
    'table'  => env('DYNAMODB_FAILED_JOBS_TABLE', 'failed_jobs'),
],

provider:
  environment:
    QUEUE_FAILED_DRIVER: dynamodb
    DYNAMODB_FAILED_JOBS_TABLE: !Ref FailedJobsTable

Y declaramos la tabla dentro de resources en serverless.yml. Laravel usa application como partition key (el nombre de la app) y uuid como sort key:

FailedJobsTable:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: failed_jobs
    BillingMode: PAY_PER_REQUEST
    AttributeDefinitions:
      - { AttributeName: application, AttributeType: S }
      - { AttributeName: uuid,        AttributeType: S }
    KeySchema:
      - { AttributeName: application, KeyType: HASH }
      - { AttributeName: uuid,        KeyType: RANGE }
    TimeToLiveSpecification:
      AttributeName: expires_at
      Enabled: true

Así como lo hicimos en el capítulo anterior con la tabla de caché y sesiones, utilizamos TimeToLiveSpecification; Laravel guarda cada job fallido con fecha de vencimiento (expires_at, 7 días por defecto ¹⁴). Este driver ni siquiera implementa queue:flush: DynamoDB se encarga de limpiar los registros caducados.

Por último, le damos permisos sobre la tabla al rol de ejecución:

provider:
  iam:
    role:
      statements:
        - Effect: Allow
          Resource: !GetAtt FailedJobsTable.Arn
          Action:
            - dynamodb:PutItem
            - dynamodb:Query
            - dynamodb:GetItem
            - dynamodb:DeleteItem

Para listar o reintentar los jobs fallidos, como en Lambda no hay SSH, usamos el puente bref:cli que vimos en el segundo capítulo:

serverless bref:cli --args="queue:failed"
serverless bref:cli --args="queue:retry all"

"Entonces, ¿para qué está la DLQ que creó Lift?"

d) Segunda capa: cuando falla la infraestructura

Un mensaje solo llega a la Dead Letter Queue cuando falla la invocación completa de Lambda, sin darle oportunidad a Laravel de atrapar el error. Por ejemplo:

Un job superó el tiempo que le quedaba a la invocación (el pcntl_alarm se activó y la ejecución salió con exit(1)).
Se quedó sin memoria (OOM).
Un error fatal de PHP fuera del alcance del Worker.
Un fallo de arranque: una extensión faltante, un error de configuración, un composer install que dejó algo afuera.

En cualquiera de estos escenarios, Lambda muere antes de que Bref pueda borrar el mensaje, así que entra en acción el mecanismo nativo de SQS:

Espera (visibility timeout): el mensaje queda oculto hasta que vence su tiempo de visibilidad. Lift lo configura automáticamente en 6 veces el timeout del worker siguiendo la recomendación de AWS ¹⁵ (con los 60 segundos de nuestro ejemplo, reaparece a los 6 minutos).
Reintento: una vez visible de nuevo, SQS vuelve a entregárselo a Lambda.
Rumbo a la DLQ: si la invocación falla 3 veces seguidas (maxRetries por defecto en Lift), SQS retira el mensaje de la cola principal y lo guarda en la Dead Letter Queue hasta por 14 días, evitando que se pierda.

Para inspeccionar qué cayó en la DLQ o volver a encolarlo sin entrar a la consola de AWS, Lift nos da estos comandos ¹⁶:

serverless jobs:logs --tail      # logs del worker, en vivo
serverless jobs:failed           # qué hay en la DLQ
serverless jobs:failed:retry     # devolver todo a la cola principal
serverless jobs:failed:purge     # borrar todo y seguir con la vida

Claro que nadie quiere ejecutar serverless jobs:failed todos los días por las dudas. Si agregan la propiedad alarm al construct, Lift configura automáticamente una alarma en CloudWatch que les envía un email apenas cae un mensaje en la DLQ ⁴:

constructs:
  jobs:
    type: queue
    # ...
    alarm: alertas@mi-dominio.com  # alerta por email cuando la DLQ recibe mensajes

Luego del primer serverless deploy, AWS les enviará un correo de confirmación al email configurado en alarm (no olviden confirmarlo para activar las alertas).

e) Las dos capas, lado a lado

	Primera capa: `failed_jobs`	Segunda capa: DLQ de SQS
¿Qué falló?	Nuestro código: excepción en `handle()`	La infraestructura: timeout, OOM, error fatal
¿Quién reintenta?	Laravel (`#[Tries]`, `#[Backoff]`)	SQS (visibility timeout, `maxRetries`)
¿Qué se reintenta?	Ese job, tras el `backoff` configurado	El job en curso y el resto del lote (6× timeout)
¿Dónde termina?	Tabla `failed_jobs` (DynamoDB, 7 días)	Dead Letter Queue (SQS, 14 días)
¿Cómo lo reintento?	`bref:cli --args="queue:retry ..."`	`serverless jobs:failed:retry`
¿Cómo me entero?	`failed()`, CloudWatch, `queue:failed`	Alerta por email (`alarm:`)

Fíjense en la fila ¿Qué se reintenta? de la segunda capa. Cuando Lambda muere a mitad de un lote (por timeout u OOM), los jobs que ya habían terminado fueron eliminados uno a uno con $job->delete(), así que no se repiten. SQS solo vuelve a entregar lo que quedó sin borrar: el job que estaba a mitad de ejecución y los que venían detrás en la fila.

El peligro está en ese job que quedó a medias: cuando SQS lo reintente, va a correr de nuevo desde el principio. Si ya había disparado un cobro o enviado un email un segundo antes de que muriera Lambda y no es idempotente, lo hará por segunda vez (y van a aprender la palabra "reembolso" antes de lo que quisieran).

Regla de oro: diseñen siempre jobs idempotentes.

6. Ajustando las Perillas del Worker para Producción

Las 8 líneas de la sección 3 alcanzan para arrancar, pero ahora que conocemos qué pasa debajo del capó podemos ajustar las perillas para producción. Así se ve una configuración pensada para el mundo real:

constructs:
  jobs:
    type: queue
    maxRetries: 5       # maxReceiveCount de la cola: AWS recomienda >= 5
    maxConcurrency: 20  # el freno "limpio": Lambda deja de leer, los mensajes esperan
    worker:
      handler: Bref\LaravelBridge\Queue\QueueHandler
      runtime: php-85
      layers:
        - ${bref-extra:gd-php-85}
      reservedConcurrency: 25  # tope duro y reserva; siempre >= maxConcurrency
      timeout: 300
    batchSize: 10

a) `timeout`: el techo del job más largo

Define tanto el tiempo máximo que puede durar una invocación como el visibility timeout de la cola en SQS (que Lift multiplica ×6). En mi caso lo llevé a 300 segundos porque el worker procesa imágenes pesadas, y redimensionar una foto de 20 MB lleva su tiempo. Si sus jobs solo envían emails o llaman a una API, con 30 o 60 segundos van sobrados.

b) `batchSize`: menos invocaciones, más responsabilidad

Lift lo deja en 1 por defecto para simplificar el manejo de errores ¹⁷. Subirlo a 10 significa que una ráfaga de 500 jobs se procesa en 50 invocaciones en lugar de 500, reduciendo cold-starts y costos. A cambio, recuerden las dos condiciones que vimos antes: todos los jobs del lote comparten el mismo reloj de Lambda, y nuestros jobs deben ser idempotentes por si una invocación muere a mitad del lote.

Existe también maxBatchingWindow: cuántos segundos espera SQS para juntar un lote completo antes de invocar. Cero por defecto. Si no les molesta que un job espere unos segundos a que lleguen compañeros, pueden subirlo.

c) `reservedConcurrency` vs `maxConcurrency`

Si llegan 1.000 jobs de golpe, Lambda escala rápido hasta cientos de invocaciones simultáneas. Y eso suena hermoso hasta que esos 1.000 jobs pegan al mismo tiempo contra una API externa con rate limit, contra nuestro servidor SMTP, o contra la misma DynamoDB.

Hay dos formas de ponerle un techo:

reservedConcurrency (propiedad de la función): la función nunca ejecuta más de N instancias simultáneas. Pero además reserva esas N de la cuota total de concurrencia de la cuenta, aunque estén sin uso ¹⁸.
maxConcurrency (propiedad del construct de Lift): limita cuántas invocaciones puede disparar el event source mapping de esta cola, sin reservar nada ¹⁹.

Lo ideal es combinarlos: maxConcurrency como freno limpio (los mensajes esperan en la cola sin gastar intentos) y reservedConcurrency apenas por encima, como red de seguridad por si un bug despacha jobs en loop.

Ojo: si usan solo reservedConcurrency, todo lo que supere ese límite cae en throttling, y cada rechazo cuenta como un intento en SQS. Con maxRetries: 3 (el default de Lift), un pico de tráfico puede mandar jobs directo a la DLQ sin haberse ejecutado ni una vez. Por eso AWS recomienda subir maxRetries a por lo menos 5 ²⁰.

d) `memorySize`: más memoria también es más CPU

Como vimos en el segundo capítulo, en Lambda la potencia de CPU escala de forma proporcional a la memoria asignada. Un job pesado que tarda 10 segundos con 512 MB puede resolverse en 3 segundos con 1.769 MB; y como AWS cobra por GB-segundo, darle más memoria muchas veces termina saliendo más barato. Si su worker hace trabajo intensivo, pueden asignarle su propio memorySize y medir el punto dulce con aws-lambda-power-tuning ²¹.

e) Layers a medida: extensiones solo donde hacen falta

¿Notaron el layer ${bref-extra:gd-php-85} en la configuración? Mi worker necesita la extensión GD para procesar imágenes, pero la función HTTP web no. Al ser funciones Lambda separadas, cada una carga únicamente las extensiones que usa: las peticiones web siguen livianas, y el peso extra solo lo carga el worker en segundo plano.

f) ¿Hace falta un warmer en el worker?

En el segundo capítulo implementamos un warmer cada 5 minutos para evitar el cold-start en las peticiones web. ¿Necesita uno el worker? Para nada. Un cold-start de 200 ms en una ruta HTTP lo sufre un usuario mirando cómo carga la pantalla; en una cola en segundo plano, 200 ms extra no le quitan el sueño a nadie.

7. Lo que No Te Cuentan los Tutoriales (y Descubres en Producción)

Cosas que no están en la documentación (o que estaban en letra chica y aprendí por las malas):

a) `SerializesModels` y las claves compuestas de DynamoDB

¿Notaron que en SendWelcomeEmail (sección 5.a) pasé $user_uuid como string en lugar del modelo User? No fue casualidad. SerializesModels guarda solo getKey() (PK) e intenta restaurar el modelo con una consulta SQL tradicional que no incluye la SK ni soporta DynamoDB.

Para sus propios jobs, lo más simple es pasar el uuid al constructor y buscar el modelo dentro de handle(). Ahora bien, si usan notificaciones encoladas ($user->notify()), Laravel serializa el modelo User sí o sí: ahí no queda otra que sobreescribir getQueueableId() y newQueryForRestoration() en su modelo para codificar y reconstruir PK + SK.

b) `Bus::batch()` también necesita dónde guardar su progreso

Por defecto busca la tabla relacional job_batches, pero Laravel incluye soporte nativo para DynamoDB: solo deben crear la tabla job_batches (partition key application, sort key id), darle permisos IAM y configurar queue.batching.driver en dynamodb ²².

c) El entorno local no necesita tocar AWS

Como el código de nuestros jobs no cambia según el driver, en su máquina pueden seguir usando QUEUE_CONNECTION=database (o sync) con el queue:work de toda la vida, o bien emular SQS localmente con herramientas como MiniStack ²³ o LocalStack ²⁴. QUEUE_CONNECTION=sqs apuntando a AWS solo hace falta en serverless.yml.

d) El límite es de 1 MiB por mensaje

Es el tope de SQS ²⁵. Los jobs deben transportar identificadores livianos, no archivos en base64 ni colecciones de 10.000 elementos. Si están cerca de ese límite, el diseño les está pidiendo a gritos que el job busque los datos cuando corre en vez de recibirlos en el payload.

e) La limpieza del SDK de AWS del segundo capítulo

Si usaron aws/aws-sdk-php con removeUnusedServices en composer.json para reducir el peso del deploy, asegúrense de agregar Sqs a la lista de servicios permitidos:

"extra": {
    "aws/aws-sdk-php": [
        "DynamoDb",
        "S3",
        "Sqs"
    ]
}

¿Por qué es tan fácil olvidarlo? Porque los tests corren con QUEUE_CONNECTION=sync o Queue::fake(), así que el CI pasa todo en verde sin instanciar jamás SqsClient... hasta que el primer dispatch() real en producción explota porque la clase fue borrada.

8. Costos: El Worker que Solo Cobra Cuando Trabaja

Actualicemos la cuenta, como en cada capítulo.

Antes (EC2): el worker vivía en una de las instancias t3.small del primer capítulo (~$15/mes por instancia). Un proceso queue:work residente con RAM reservada y supervisord encendido las 24 horas, aunque la cola pasara el 90% del día vacía.
Ahora (SQS + Lambda):
- SQS: el primer millón de requests mensuales es gratis; después cuesta \$0.40 por millón ²⁶. Sumando los ~630.000 requests del polling en reposo y 3 requests por cada job (SendMessage, ReceiveMessage y DeleteMessage), pueden procesar hasta ~120.000 jobs al mes por $0.00.
- Lambda: la capa gratuita perpetua incluye 1 millón de invocaciones y 400.000 GB-segundos al mes. Sin jobs en la cola, el cómputo cuesta exactamente cero.

Pongámoslo en números para un mes con 100.000 jobs (de ~500 ms promedio con 512 MB de RAM):

Concepto	Dentro del Free Tier	Tarifa Plena (sin Free Tier)
Polling SQS (~630k req/mes)	$0.00	$0.25
Mensajes SQS (300k req/mes)	$0.00	$0.12
Lambda Worker (100k jobs)	$0.00	$0.44
Total mensual	$0.00	~$0.81

¡Incluso sin la capa gratuita, procesar 100.000 jobs cuesta menos de un dólar al mes!

Y lo más importante: con DynamoDB en PAY_PER_REQUEST, Lambda facturando por milisegundo y SQS por request, casi ningún componente del sistema de colas cobra tarifa fija por existir (a excepción del polling de SQS, que en mi caso cae dentro del free tier).

9. ¿Qué Sigue?

Hoy jubilamos definitivamente a supervisord y al proceso queue:work que corría las 24 horas: los reemplazamos por una cola SQS y un worker en Lambda que solo despierta cuando hay trabajo. Vimos que Bref reutiliza el mismo Worker de Laravel (así que nuestros jobs no cambian), cómo hace su truco en release() para conservar los reintentos y el backoff, y cómo conviven failed_jobs en DynamoDB con la Dead Letter Queue de SQS.

Pero quedó un cabo suelto entre el capítulo anterior y este. En la sección 6 les conté que mi worker carga la extensión GD para redimensionar imágenes; ahora bien, si en el capítulo anterior vimos que los archivos viajan directo del navegador a S3 sin pasar por nuestra aplicación... ¿quién le avisa a Laravel que terminó de subirse un archivo para encolar ese job?

En el próximo capítulo vamos a cerrar ese círculo con S3 Event Notifications, y veremos por qué la solución no es conectar S3 directo a la cola que acabamos de crear.

Una pregunta para ustedes: ¿con qué corren sus colas de Laravel hoy en producción, o cuál fue la peor jugada que les hizo un worker a las 3 AM? Los leo en los comentarios: las mejores historias de producción salen de ahí, no de los post-mortems.

Where Does My Laravel App's Data Live in an Ephemeral Environment (Where Not Even the Disk Can Save You)

Hermann D. Schimpf — Wed, 30 Sep 2026 16:06:47 +0000

Versión en español aquí.

Spoiler: Lambda's disk exists. It's ephemeral, read-only, and self-destructs when AWS recycles the environment — and it doesn't tell you when.

In the previous chapter we turned Laravel into a digital nomad: we deployed to Lambda, served assets through CloudFront, and won the cold-start battle with Octane. But a promise was left hanging: where does your data end up when the disk is, literally, a temporary illusion?

Let's be clear: Lambda's disk exists. There's a writable /tmp directory where you can drop temporary files ¹. But treating it as real storage is like keeping your life savings in a shared taxi: technically they're in there, but good luck finding them tomorrow. The rest of the filesystem is read-only, and every Lambda instance can vanish at any moment, taking /tmp with it.

In this chapter we tackle persistence in three acts: first files (S3, the short part), then our entry into the NoSQL world with cache and sessions (DynamoDB, easy mode), and finally the main course: DynamoDB as the primary database.

1. The Serverless Treasure Map

Before we dive into the code, let's figure out where we're standing. This is the simplified architecture of my application:

In previous chapters we already covered how we use Lambda to run our Laravel app, and how CloudFront splits traffic between S3 (assets) and Lambda (the app). Today we'll:

Send uploads to S3.
Store session and cache data in DynamoDB.
And use DynamoDB as our primary database.

The other services are left for upcoming chapters. Patience, my young padawans.

2. Uploads to S3: The Short Part

This one is so simple it's almost embarrassing to dedicate a section to it. Almost.

a) The same old facade, a different destination

Laravel already abstracts storage with the Storage facade. On a traditional server it points to the local disk; in serverless, we simply define the bucket ² and switch the driver to s3 ³ ⁴:

composer require league/flysystem-aws-s3-v3

provider:
  environment:
    FILESYSTEM_DISK: s3
    AWS_BUCKET: ${construct:storage.bucketName}

constructs:
  storage:
    type: storage
    # Flysystem sends ACL headers on every operation and new buckets reject them by default [^12]
    allowAcl: true
    # CORS is required to upload files directly from the browser using pre-signed URLs
    cors: ${construct:website.url}

And that's it. Every call to Storage::put(), Storage::get() now talks to S3 without touching a single line of business logic. Zero refactoring, pure abstraction, point for Laravel.

b) Pre-signed URLs: so uploads don't even go through Lambda

But here comes the clever trick. If the user uploads a file through your application, you're paying Lambda time for bytes that are just passing by. Remember the $530 bill for idle time from the previous article? Exactly.

The elegant alternative: pre-signed URLs ⁵. Laravel generates a temporary S3 URL, the frontend uses it to upload the file directly to S3, and Lambda never even finds out:

use Illuminate\Support\Facades\Storage;

// Laravel generates the URL, the browser uploads straight to S3
['url' => $url, 'headers' => $headers] = Storage::temporaryUploadUrl(
    "uploads/{$filename}", now()->addMinutes(5)
);

The file travels directly from the browser to S3 with no layovers. Generating the URL is a local signature, zero cost. Lambda keeps sleeping, and so does your wallet.

Lambda (and API Gateway) limit the payload to a maximum of 6 MB and 10 MB respectively ⁶. Beyond that size, pre-signed URLs stop being an optimization and become mandatory ⁷.

But if Lambda keeps sleeping... how does it find out a file was uploaded?

That's where the fun begins: S3 can automatically fire events ⁸ when a file is uploaded. That event can invoke a Lambda, broadcast a message through SNS, or emit an event to SQS or EventBridge. But we'll open that Pandora's box in another chapter.

3. DynamoDB, Easy Mode: Cache and Sessions

Before using DynamoDB as a database (the final boss of this article), let's start where it hurts the least: cache and sessions.

a) Cache: the table that cleans itself

The setup is insultingly simple ⁹. We only need to switch the cache store to dynamodb, and specify the DynamoDB table name:

provider:
  environment:
    CACHE_STORE: dynamodb
    DYNAMODB_CACHE_TABLE: !Ref CacheTable

And add the table definition in serverless.yml (inside resources, as CloudFormation) ¹⁰:

CacheTable:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: my-app-cache
    BillingMode: PAY_PER_REQUEST
    AttributeDefinitions:
      - AttributeName: key
        AttributeType: S
    TimeToLiveSpecification:
      AttributeName: expires_at
      Enabled: true
    KeySchema:
      - AttributeName: key
        KeyType: HASH

The beautiful detail: TimeToLiveSpecification. DynamoDB automatically deletes expired items based on the expires_at attribute ¹¹. No cleanup cron jobs, no cache:* commands, nothing. DynamoDB's Roomba does the cleaning while you sleep.

The key and expires_at attributes are the default names Laravel uses ⁹.

b) A new home for sessions

In the previous article we left sessions in cookies as a quick fix. It works, sure, but it has its limits: cookies travel with every request and are capped at ~4KB. For something more robust, Laravel ships with native DynamoDB support ¹²:

provider:
  environment:
    SESSION_DRIVER: dynamodb

Internally, Laravel reuses the same cache table ¹² (with the same automatic TTL ¹¹). Sessions expire, DynamoDB sweeps them away, and you keep building features instead of maintaining infrastructure.

The honest trade-off: cookies were free; now every authenticated request is one read and one write in DynamoDB. With PAY_PER_REQUEST and modest traffic we're talking cents per month, but it's worth knowing before it shows up on the bill.

With cache and sessions migrated, only one stateful component is left standing: the database.

Grab some coffee, because it's about to get interesting.

4. DynamoDB as a Database: The Final Boss

This is where most Laravel devs get nervous. Our whole careers we were raised on CREATE TABLE, migrations, and JOINs. DynamoDB looks at all of that and says: "that's cute, but we don't do that here".

a) DynamoDB basics for Laravel devs

Let's translate the concepts into our language:

Table: same as always, but with no migrations and no columns: each item can have whatever attributes it wants. The only exception is the attributes you use as keys or indexes ¹³: those you do have to declare.
Item: the equivalent of a row. Basically a JSON with its own identity.
PK (Partition Key): defines which physical partition the item lives in. It's the mandatory WHERE of every query. The only one that gets a pass is Scan, but in section 4.d you'll see why you won't want to use it.
SK (Sort Key): sorts items within the same partition. PK + SK form the composite primary key.
GSI (Global Secondary Index) ¹⁴: an alternative way to organize items so you can query them by other attributes. The closest thing to an index you'll find.

The golden rule that took me a while to internalize: in DynamoDB you don't model data, you model access patterns. First you think about which queries you'll run, then you design the keys. Unlike SQL, where you model normalized and then fight with the indexes.

b) Eloquent on DynamoDB: kitar/laravel-dynamodb

To simplify implementing Eloquent on top of DynamoDB I used the kitar/laravel-dynamodb package, which provides a connection driver and a query builder that translates Eloquent calls into DynamoDB operations.

composer require kitar/laravel-dynamodb

The connection in config/database.php looks like this:

'dynamodb' => [
    'driver'   => 'dynamodb',
    'key'      => env('AWS_ACCESS_KEY_ID'),
    'secret'   => env('AWS_SECRET_ACCESS_KEY'),
    'region'   => env('AWS_DEFAULT_REGION', 'us-east-1'),
    'token'    => env('AWS_SESSION_TOKEN'),
    'endpoint' => env('DYNAMODB_ENDPOINT'), // useful for local/testing
    'prefix'   => 'my-app-', // optional prefix for table names
],

The values of AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN are automatically injected into the environment from the function's execution role. They're temporary credentials that rotate on their own, and the permissions they carry are exactly the ones we declare in IAM (section 4.e).

provider:
  environment:
    DB_CONNECTION: dynamodb

And the models... are still Eloquent models, with a couple of extra attributes for the table keys ¹⁵, and a bit of glue for the GSI:

use Illuminate\Database\Eloquent\Casts\Attribute;
use Illuminate\Support\Str;
use Kitar\Dynamodb\Model\Model;

class User extends Model
{
    protected $table          = 'users';
    protected $primaryKey     = 'PK';     // partition key → USER#<uuid>
    protected $sortKey        = 'SK';     // sort key
    protected $sortKeyDefault = 'PROFILE';
    protected $fillable       = ['name', 'email', 'password'];
    protected $appends        = ['email'];  // so it shows up when serializing

    protected static function booted(): void
    {
        static::creating(function (self $user) {
            $user->PK       = 'USER#'.Str::uuid();
            $user->GSI1PK   = 'USER'; // groups all users together
        });
    }

    protected function email(): Attribute
    {
        // the email lives in GSI1SK: the same index serves both listing users and looking up by email
        return Attribute::make(
            get: fn (): string => $this->GSI1SK,
            set: static fn (string $email): array => [ 'GSI1SK' => $email ],
        );
    }
}

Careful with the "still Eloquent" part: they inherit mutators, casts, events, serialization and authentication, but not relationships (hasMany(), belongsTo(), with()), nor a generic where() (here it's keyCondition(), filter() or condition()), nor arbitrary orderBy() (only by Sort Key), nor page-number paginate() (DynamoDB paginates by cursor), nor count()/aggregates. It's not a package limitation: DynamoDB simply doesn't know how to do that, and the package is honest enough not to pretend otherwise.

Why a UUID and not the email as the Partition Key, which is what the package's README does? Because in DynamoDB the primary key is the item's identity: it can't be modified, only deleted and recreated. The day a user wants to change their email, you'd have to recreate the item and everything hanging off that PK. An immutable identifier as PK and the email in a GSI lets you look up by email today and change it tomorrow without touching the item's identity.

sortKeyDefault covers the most common case: User::find('USER#2aab…11a2') automatically uses PROFILE as the sort key. And the GSI solves the other two access patterns:

// all users
User::index('GSI1')->keyCondition('GSI1PK', '=', 'USER')->query();

// the user with this email
User::index('GSI1')
    ->keyCondition('GSI1PK', '=', 'USER')
    ->keyCondition('GSI1SK', '=', 'foo@bar.com')
    ->query()->first();

A detail that bites: the GSI lets you look up by email, but it does not guarantee it's unique. Two users with the same email would happily coexist in the index. If you need uniqueness, you validate it before creating.

See those weird keys? USER#<uuid> as the primary key, USER stuffed into a GSI1 index... that has a name of its own...

c) Single-Table Design: the concept (and nothing more)

Those weird keys are the gateway to Single-Table Design: instead of one table per entity (users, posts, comments...), several entities share a single table, told apart by their keys. The PK can identify the data's "owner" (USER#123), the SK what kind of thing it is (PROFILE, POST#456), and GSIs give you alternative views for other access patterns.

Sounds like black magic? It isn't, but it is an art: properly designing a single-table layout requires mapping all your access patterns before writing a single line of code, something you can improvise on the fly in SQL.

I won't go deeper here because the topic deserves its own article (and it will get one). Today you only need to know it exists, and that it's the reason DynamoDB can replace a full relational database.

d) When DynamoDB beats SQL, and when it doesn't

Let's be honest, no smoke and mirrors. DynamoDB is brutal when:

You know the access patterns upfront (get by id, list by owner, filter by status).
You need predictable latency: single-digit millisecond reads, at any scale ¹⁶.
Traffic is unpredictable: huge spikes or no traffic at all. PAY_PER_REQUEST: you pay per request, so with almost no traffic the bill is almost zero; with sustained high traffic, consider provisioned mode ¹⁷.
You want to scale without drama: there's no "master" node dying at 4 AM, no read replicas to configure to bypass max_connections. Scalability stops being your problem.
DynamoDB Streams ¹⁸: every write can fire events. The equivalent of MySQL's binlog, but managed and capable of running code.
Zero management: no patching, no VACUUM, no scheduled maintenance.

And it's not for you if:

You need to sort or filter by any attribute: in DynamoDB you only sort by Sort Key and only search efficiently by keys (or GSIs). Everything else is filter() over what's already been read: you pay to read and then discard.
You need JOINs and ad-hoc queries: "show me all users who bought X last month grouped by state" → do it in SQL or export to a data warehouse.
You depend on UNIQUE, foreign keys or ON DELETE CASCADE: they don't exist. Uniqueness is enforced by hand with condition expressions (attribute_not_exists(PK)), and referential integrity is your code's responsibility, not the database's.
Your data models change every week: redesigning keys in DynamoDB hurts more than a migration.
You depend on reporting/analytics: dashboards, aggregated charts, exploratory queries → you need SQL. DynamoDB is not the place.
You need to store giant items: DynamoDB has a maximum of 400KB per item ¹⁹. Large documents go in S3, and only the reference goes in DynamoDB.
Scan as a strategy ²⁰: you read the whole table and pay for all of it. If your query is solved with a scan, the design failed.

Access patterns like "posts by user", "comments by post", or direct reads by ID fit perfectly in the first group. Use cases tailor-made for DynamoDB.

e) Infrastructure is code too

Tables are declared as CloudFormation resources ²¹. The table for the example User model would look like this:

UsersTable:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: my-app-users
    BillingMode: PAY_PER_REQUEST
    AttributeDefinitions:
      - { AttributeName: PK,     AttributeType: S }
      - { AttributeName: SK,     AttributeType: S }
      - { AttributeName: GSI1PK, AttributeType: S }
      - { AttributeName: GSI1SK, AttributeType: S }
    KeySchema:
      - { AttributeName: PK, KeyType: HASH }
      - { AttributeName: SK, KeyType: RANGE }
    GlobalSecondaryIndexes:
      - IndexName: GSI1
        KeySchema:
          - { AttributeName: GSI1PK, KeyType: HASH }
          - { AttributeName: GSI1SK, KeyType: RANGE }
        Projection: { ProjectionType: ALL }

And the minimum IAM permissions in the main serverless.yml ²²:

provider:
  iam:
    role:
      statements:
        - Effect: Allow
          Resource:
            - !GetAtt CacheTable.Arn
            - !GetAtt UsersTable.Arn
            - !Sub
              - '${Resource}/index/*'
              - { Resource: !GetAtt UsersTable.Arn }
          Action:
            - dynamodb:Query
            - dynamodb:GetItem
            - dynamodb:PutItem
            - dynamodb:UpdateItem
            - dynamodb:DeleteItem

Tip: We must never use Action: dynamodb:* or Resource: *. Least privilege or nothing ²³.

f) Costs: the last fixed bill goes away

Let's update the tally:

The debt from the first chapter: Back there we left an RDS MySQL db.t4g.small running, which costs ~$26/month (≈ $0.032/h × 730 h + storage ²⁴) for a database that charges just for existing. Today we retire it.
With DynamoDB: We can use BillingMode: PAY_PER_REQUEST and pay only for processed requests and stored GB. With modest traffic, the monthly bill is measured in cents: the database that charged for breathing is gone, and no major component charges a flat fee for resources nobody is using anymore.

5. What's Next?

Today we figured out where everything persists: files in S3 (with uploads that never even touch Lambda), cache and sessions in DynamoDB with automatic expiration, and a NoSQL database that speaks Eloquent.

But the map still has unexplored areas. In the next article: queues. We'll see how SQS + a Lambda worker replace the queue:work that ran forever under a supervisor, and why that's better than praying to supervisord at 3 AM.

A question for you: have you already used DynamoDB with Laravel, or are you still on Team MySQL/PostgreSQL? Tell me in the comments what holds you back (or what made you fall in love) about the NoSQL world.

Dónde Persisten los Datos de Mi Aplicación Laravel en un Entorno Efímero (Donde Ni el Disco Te Salva)

Hermann D. Schimpf — Wed, 30 Sep 2026 04:56:00 +0000

English version here.

Spoiler: El disco de Lambda existe. Es efímero, de solo lectura y se autodestruye cuando AWS recicla el entorno — y no avisa cuándo.

En el capítulo anterior convertimos a Laravel en un nómada digital: desplegamos en Lambda, servimos los assets con CloudFront y ganamos la batalla del cold-start con Octane. Pero quedó una promesa pendiente: ¿dónde van a parar los datos cuando el disco es, literalmente, una ilusión temporal?

Hablemos claro: el disco en Lambda existe. Hay un directorio /tmp escribible donde pueden tirar archivos temporales ¹. Pero tratarlo como almacenamiento real es como guardar tus ahorros en un taxi compartido: técnicamente están ahí, pero buena suerte encontrándolos mañana. El resto del filesystem es de solo lectura, y cada instancia de Lambda puede desaparecer en cualquier momento llevándose /tmp con ella.

En este capítulo atacamos la persistencia en tres actos: primero los archivos (S3, la parte corta), después nuestra entrada al mundo NoSQL con caché y sesiones (DynamoDB, modo fácil), y finalmente el plato fuerte: DynamoDB como base de datos principal.

1. El Mapa del Tesoro Serverless

Antes de meternos en el código, ubiquemos dónde estamos parados. Esta es la arquitectura simplificada de mi aplicación:

En los capítulos previos ya hablamos sobre cómo utilizamos Lambda para ejecutar nuestra App Laravel, y cómo CloudFront reparte el tráfico entre S3 (assets) y Lambda (la app). Hoy toca:

Enviar las subidas a S3.
Almacenar los datos de sesión y caché en DynamoDB.
y utilizar DynamoDB como nuestra base de datos principal.

Los demás servicios quedan para los próximos capítulos. Paciencia, mis jóvenes padawans.

2. Uploads a S3: La Parte Corta

Este punto es tan simple que casi da vergüenza dedicarle una sección. Casi.

a) El mismo facade de siempre, otro destino

Laravel ya abstrae el almacenamiento con el facade Storage. En un servidor tradicional apunta al disco local; en serverless, simplemente definimos el bucket ² y cambiamos el driver a s3 ³ ⁴:

composer require league/flysystem-aws-s3-v3

provider:
  environment:
    FILESYSTEM_DISK: s3
    AWS_BUCKET: ${construct:storage.bucketName}

constructs:
  storage:
    type: storage
    # Flysystem envía headers ACL en cada operación y los buckets nuevos los rechazan por defecto [^12]
    allowAcl: true
    # CORS es requerido para subir ficheros directamente desde el navegador utilizando URLs pre-firmadas
    cors: ${construct:website.url}

Y listo. Toda llamada a Storage::put(), Storage::get() ahora habla con S3 sin tocar una línea de lógica de negocio. Cero refactor, pura abstracción, punto para Laravel.

b) URLs pre-firmadas: para que los uploads ni siquiera pasen por Lambda

Pero acá viene el truco fino. Si el usuario sube un archivo a través de la aplicación, están pagando tiempo de Lambda por bytes que solo están de paso. ¿Recuerdan la factura de $530 por tiempo inactivo del artículo anterior? Exacto.

La alternativa elegante: URLs pre-firmadas ⁵. Laravel genera una URL temporal de S3, el frontend la usa para subir el archivo directamente a S3, y Lambda ni se entera:

use Illuminate\Support\Facades\Storage;

// Laravel genera la URL, el navegador sube directo a S3
['url' => $url, 'headers' => $headers] = Storage::temporaryUploadUrl(
    "uploads/{$filename}", now()->addMinutes(5)
);

El archivo viaja directo desde el navegador a S3 sin escalas. Generar la URL es una firma local, costo cero. Lambda sigue durmiendo, y sus billeteras también.

Lambda (y API Gateway) limitan el payload a un máximo de 6 MB y 10 MB respectivamente ⁶. Pasado ese tamaño, las URLs pre-firmadas dejan de ser una optimización y se vuelven obligatorias ⁷.

Pero, si Lambda sigue durmiendo... ¿Cómo se entera de que se subió un archivo?

Ahí empieza lo divertido: S3 puede disparar eventos automáticamente ⁸ cuando se sube un archivo. Ese evento puede invocar una Lambda, transmitir un mensaje por SNS, emitir un evento a SQS o EventBridge. Pero esa caja de Pandora la abriremos en otro capítulo.

3. DynamoDB, Modo Fácil: Caché y Sesiones

Antes de usar DynamoDB como base de datos (el boss final de este artículo), empecemos por donde duele menos: el caché y las sesiones.

a) Caché: la tabla que se limpia sola

La configuración es insultantemente simple ⁹. Solo debemos cambiar el store de caché a dynamodb, y especificar el nombre de la tabla DynamoDB:

provider:
  environment:
    CACHE_STORE: dynamodb
    DYNAMODB_CACHE_TABLE: !Ref CacheTable

Y agregar la definición de tabla en serverless.yml (dentro de resources, como CloudFormation) ¹⁰:

CacheTable:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: my-app-cache
    BillingMode: PAY_PER_REQUEST
    AttributeDefinitions:
      - AttributeName: key
        AttributeType: S
      TimeToLiveSpecification:
        AttributeName: expires_at
        Enabled: true
      KeySchema:
        - AttributeName: key
          KeyType: HASH

El detalle hermoso: TimeToLiveSpecification. DynamoDB borra automáticamente los items expirados según el atributo expires_at ¹¹. Sin cron jobs de limpieza, sin comandos cache:*, sin nada. El Roomba de DynamoDB hace el aseo mientras ustedes duermen.

Los atributos key y expires_at son los nombres por defecto que utiliza Laravel ⁹.

b) Un nuevo hogar para las sesiones

En el artículo anterior dejamos las sesiones en cookies como solución rápida. Funciona sí, pero tiene sus límites: las cookies viajan en cada request y tienen tope de ~4KB. Para algo más robusto, Laravel trae soporte nativo para DynamoDB ¹²:

provider:
  environment:
    SESSION_DRIVER: dynamodb

Internamente, Laravel reutiliza la misma tabla de caché ¹² (con el mismo TTL automático ¹¹). Las sesiones expiran, DynamoDB las barre, y ustedes siguen programando features en vez de mantener infraestructura.

El trade-off honesto: las cookies eran gratis; ahora cada request autenticado es una lectura y una escritura en DynamoDB. Con PAY_PER_REQUEST y tráfico modesto hablamos de centavos al mes, pero conviene saberlo antes de que aparezca en la factura.

Con caché y sesiones ya migrados, solo queda un componente stateful en pie: la base de datos.

Preparen café, que aquí se pone interesante.

4. DynamoDB como Base de Datos: El Boss Final

Acá es donde la mayoría de los devs Laravel se ponen nerviosos. Durante toda nuestra carrera fuimos criados a base de CREATE TABLE, migraciones y JOINs. DynamoDB mira todo eso y dice: "qué lindo, pero acá no hacemos nada de eso".

a) Básicos de DynamoDB para devs Laravel

Traduzcamos los conceptos a nuestro idioma:

Tabla: igual que siempre, pero sin migraciones ni columnas: cada item puede tener los atributos que quiera. La única excepción son los atributos que usen como clave o índice ¹³: esos sí hay que declararlos.
Item: el equivalente a una fila. Básicamente un JSON con identidad propia.
PK (Partition Key): define en qué partición física vive el item. Es el WHERE obligatorio de toda consulta. La única que se salva es Scan, pero en la sección 4.d van a ver por qué no querrán usarla.
SK (Sort Key): ordena los items dentro de una misma partición. PK + SK forman la clave primaria compuesta.
GSI (Global Secondary Index) ¹⁴: una forma alternativa de organizar los items para consultarlos por otros atributos. Lo más parecido a un índice que van a encontrar.

La regla de oro que me costó interiorizar: en DynamoDB no modelan datos, modelan los patrones de acceso. Primero piensan qué queries van a hacer, después diseñan las claves. A diferencia de SQL, donde modelan normalizado y después se pelean con los índices.

b) Eloquent sobre DynamoDB: kitar/laravel-dynamodb

Para simplificar la implementación de Eloquent con DynamoDB utilicé el paquete kitar/laravel-dynamodb, que provee un driver de conexión y un query builder que traduce las llamadas de Eloquent a operaciones de DynamoDB.

composer require kitar/laravel-dynamodb

La conexión en config/database.php se ve así:

'dynamodb' => [
    'driver'   => 'dynamodb',
    'key'      => env('AWS_ACCESS_KEY_ID'),
    'secret'   => env('AWS_SECRET_ACCESS_KEY'),
    'region'   => env('AWS_DEFAULT_REGION', 'us-east-1'),
    'token'    => env('AWS_SESSION_TOKEN'),
    'endpoint' => env('DYNAMODB_ENDPOINT'), // útil para local/testing
    'prefix'   => 'my-app-', // prefijo opcional para nombres de tabla
],

Los valores de AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, y AWS_SESSION_TOKEN son inyectados automáticamente en el entorno a partir del rol de ejecución de la función. Son credenciales temporales que rotan solas, y los permisos que tienen son exactamente los que declaremos en IAM (sección 4.e).

provider:
  environment:
    DB_CONNECTION: dynamodb

Y los modelos... siguen siendo modelos Eloquent, con un par de atributos extra para las claves de la tabla ¹⁵, y un poco de pegamento para el GSI:

use Illuminate\Database\Eloquent\Casts\Attribute;
use Illuminate\Support\Str;
use Kitar\Dynamodb\Model\Model;

class User extends Model
{
    protected $table          = 'users';
    protected $primaryKey     = 'PK';     // partition key → USER#<uuid>
    protected $sortKey        = 'SK';     // sort key
    protected $sortKeyDefault = 'PROFILE';
    protected $fillable       = ['name', 'email', 'password'];
    protected $appends        = ['email'];  // para que aparezca al serializar

    protected static function booted(): void
    {
        static::creating(function (self $user) {
            $user->PK       = 'USER#'.Str::uuid();
            $user->GSI1PK   = 'USER'; // agrupa a todos los usuarios
        });
    }

    protected function email(): Attribute
    {
        // el email vive en GSI1SK: el mismo índice sirve para listar usuarios y para buscar por email
        return Attribute::make(
            get: fn (): string => $this->GSI1SK,
            set: static fn (string $email): array => [ 'GSI1SK' => $email ],
        );
    }
}

Ojo con el "siguen siendo Eloquent": heredan mutators, casts, eventos, serialización y autenticación, pero no relaciones (hasMany(), belongsTo(), with()), ni where() genérico (acá es keyCondition(), filter() o condition()), ni orderBy() arbitrario (solo por Sort Key), ni paginate() por número de página (DynamoDB pagina por cursor), ni count()/agregados. No es limitación del paquete: es que DynamoDB no sabe hacer eso, y el paquete tiene la honestidad de no fingirlo.

¿Por qué un UUID y no el email como Partition Key, que es lo que hace el README del paquete? Porque en DynamoDB la clave primaria es la identidad del item: no se modifica, solo se borra y se vuelve a crear. El día que un usuario quiera cambiar su email, tendrían que recrear el item y todo lo que cuelgue de esa PK. Un identificador inmutable como PK y el email en un GSI les permite buscar por email hoy y cambiarlo mañana sin tocar la identidad del item.

El sortKeyDefault cubre el caso más común: User::find('USER#2aab…11a2') usa PROFILE como sort key automáticamente. Y el GSI resuelve los otros dos patrones de acceso:

// todos los usuarios
User::index('GSI1')->keyCondition('GSI1PK', '=', 'USER')->query();

// el usuario con este email
User::index('GSI1')
    ->keyCondition('GSI1PK', '=', 'USER')
    ->keyCondition('GSI1SK', '=', 'foo@bar.com')
    ->query()->first();

Un detalle que muerde: el GSI permite buscar por email, pero no garantiza que sea único. Dos usuarios con el mismo email convivirían felices en el índice. Si necesitan unicidad, se valida antes de crear.

¿Ven esas claves raras? USER#<uuid> como clave primaria, USER metido en un índice GSI1... eso tiene nombre propio...

c) Single-Table Design: el concepto (y nada más)

Esas claves raras son la puerta de entrada al Single-Table Design: en lugar de una tabla por entidad (users, posts, comments...), varias entidades comparten una sola tabla diferenciándose por sus claves. La PK puede identificar el "dueño" del dato (USER#123), la SK qué cosa es (PROFILE, POST#456), y los GSIs les dan vistas alternativas para otros patrones de acceso.

¿Suena a magia negra? No lo es, pero sí es un arte: diseñar bien una tabla "single-table" requiere mapear todos los patrones de acceso antes de escribir una línea de código, algo que en SQL pueden improvisar sobre la marcha.

No voy a profundizar acá porque el tema merece su propio artículo (y lo tendrá). Hoy solo necesitan saber que existe, y que es la razón por la que DynamoDB puede reemplazar a una base relacional completa.

d) Cuándo DynamoDB le gana a SQL, y cuándo no

Seamos honestos, sin vender humo. DynamoDB es brutal cuando:

Conocen los patrones de acceso de antemano (get by id, list by owner, filter by status).
Necesitan latencia predecible: lecturas de un dígito de milisegundos, a cualquier escala ¹⁶.
El tráfico es impredecible: picos gigantes o nada de tráfico. PAY_PER_REQUEST: pagan por request, así que con tráfico casi nulo la factura es casi nula; con tráfico sostenido y alto, evalúen el modo provisionado ¹⁷.
Quieren escalar sin dramas: no hay nodo "master" que muera a las 4 AM, no hay réplicas de solo lectura que configurar para bypassear max_connections. La escalabilidad deja de ser un problema.
DynamoDB Streams ¹⁸: cada escritura puede disparar eventos. El equivalente al binlog de MySQL, pero administrado y capaz de ejecutar código.
Gestión cero: sin parches, sin VACUUM, sin mantenimiento programado.

Y no es para ustedes si:

Necesitan ordenar o filtrar por cualquier atributo: en DynamoDB solo se ordena por Sort Key y solo se busca eficientemente por claves (o GSIs). Todo lo demás es filter() sobre lo ya leído: pagan por leer y después descartan.
Necesitan JOINs y queries ad-hoc: "mostrame todos los usuarios que compraron X en el último mes agrupado por provincia" → háganlo en SQL o exporten a un data warehouse.
Dependen de UNIQUE, foreign keys o ON DELETE CASCADE: no existen. La unicidad se garantiza a mano con condition expressions (attribute_not_exists(PK)), y la integridad referencial es responsabilidad de su código, no de la base.
Sus modelos de datos cambian cada semana: rediseñar claves en DynamoDB duele más que una migración.
Dependen de reporting/analytics: dashboards, gráficos agregados, queries exploratorias → necesitan SQL. DynamoDB no es el lugar.
Necesitan almacenar ítems gigantes: DynamoDB tiene un máximo de 400KB por item ¹⁹. Los documentos grandes van en S3, y en DynamoDB solo la referencia.
Scan como estrategia ²⁰: leen toda la tabla y pagan todo. Si la consulta se resuelve con scan, el diseño falló.

Patrones de acceso tipo «posts por usuario», «comentarios por post» o lecturas directas por ID encajan perfecto en el primer grupo. Casos de uso hechos a medida para DynamoDB.

e) La infraestructura también es código

Las tablas viven declaradas como recursos CloudFormation ²¹. La tabla del modelo User del ejemplo se vería así:

UsersTable:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: my-app-users
    BillingMode: PAY_PER_REQUEST
    AttributeDefinitions:
      - { AttributeName: PK,     AttributeType: S }
      - { AttributeName: SK,     AttributeType: S }
      - { AttributeName: GSI1PK, AttributeType: S }
      - { AttributeName: GSI1SK, AttributeType: S }
    KeySchema:
      - { AttributeName: PK, KeyType: HASH }
      - { AttributeName: SK, KeyType: RANGE }
    GlobalSecondaryIndexes:
      - IndexName: GSI1
        KeySchema:
          - { AttributeName: GSI1PK, KeyType: HASH }
          - { AttributeName: GSI1SK, KeyType: RANGE }
        Projection: { ProjectionType: ALL }

Y los permisos IAM mínimos en el serverless.yml principal ²²:

provider:
  iam:
    role:
      statements:
        - Effect: Allow
          Resource:
            - !GetAtt CacheTable.Arn
            - !GetAtt UsersTable.Arn
            - !Sub
              - '${Resource}/index/*'
              - { Resource: !GetAtt UsersTable.Arn }
            Action:
              - dynamodb:Query
              - dynamodb:GetItem
              - dynamodb:PutItem
              - dynamodb:UpdateItem
              - dynamodb:DeleteItem

Si usan Cache::many() o Cache::getMultiple(), agreguen dynamodb:BatchGetItem: Laravel los resuelve en una sola llamada batch, y sin ese permiso van a recibir un AccessDeniedException que no menciona la palabra "batch" por ningún lado.

Sugerencia: Nunca debemos utilizar Action: dynamodb:* o Resource: *. Privilegio mínimo o nada ²³.

f) Costos: la última factura fija se va

Actualicemos la cuenta:

La deuda del primer capítulo: Ahí quedó un RDS MySQL db.t4g.small que genera ~$26/mes (≈ $0.032/h × 730 h + almacenamiento ²⁴) por una base de datos que cobra solo por existir. Hoy la retiramos.
Con DynamoDB: Podemos utilizar el modo BillingMode: PAY_PER_REQUEST y así solo pagar por request procesado y GB almacenado. Con tráfico modesto, la factura del mes se mide en centavos: la base de datos que cobraba por respirar dejó de existir, y ya ningún componente grande cobra tarifa plana por recursos que nadie usa.

5. ¿Qué Sigue?

Hoy resolvimos dónde persiste todo: archivos en S3 (con uploads que ni tocan Lambda), caché y sesiones en DynamoDB con expiración automática, y una base de datos NoSQL que habla Eloquent.

Pero el mapa todavía tiene zonas inexploradas. En el próximo artículo: las colas. Veremos cómo SQS + un worker Lambda reemplazan al queue:work que corría eternamente en un supervisor, y por qué eso es mejor que rezarle a supervisord a las 3 AM.

Una pregunta para ustedes: ¿ya usaron DynamoDB con Laravel, o siguen en el equipo MySQL/PostgreSQL? Cuéntenme en los comentarios qué los frena (o qué los enamoró) del mundo NoSQL.

Cómo Mi Configuración de Docker Me Salvó de un Ataque de Supply Chain (Y Por Qué la Tuya Debería Hacerlo También)

Hermann D. Schimpf — Mon, 25 May 2026 23:50:55 +0000

English version here.

¡Por fin es viernes! Sales del trabajo y vas a casa a trabajar en tu proyecto personal (sí, ese soy yo). Abres tu computadora y empiezas a trabajar ejecutando composer update porque quieres mantener tus dependencias actualizadas.

A la mañana siguiente, te despiertas con la noticia de que un paquete popular de Laravel que usas ha sido comprometido. Los atacantes inyectaron un robo de credenciales en 233 versiones, listo para exfiltrar tus claves SSH, credenciales de la nube, datos del navegador, billeteras de criptomonedas—toda la ensalada digital ¹. El pánico se instala. Revisas tu composer.lock. Tu corazón se detiene un segundo. Tienes la versión 15.29.3 de laravel-lang/lang, una de las versiones comprometidas ².

¿Te ha pasado? A mí me pasó el 22 de mayo de 2026.

Pero aquí está el giro inesperado: cuando profundicé más, me di cuenta de que mi configuración de PHP en Docker acababa de convertirse en mi guardaespaldas inesperado. Déjame contarte cómo ejecutar PHP a través de contenedores Docker añadió una capa de seguridad que nunca planeé, y por qué tú también deberías considerarlo.

1. El Ataque: Cuando `composer update` Se Vuelve Rebelde

El 22 de mayo de 2026, los atacantes comprometieron la organización Laravel-Lang en GitHub. No solo publicaron una versión maliciosa—reescribieron cada etiqueta git en cuatro paquetes populares para apuntar a sus propios commits. ¿El payload? Un robo de credenciales disfrazado como un archivo de ayuda inofensivo que se ejecuta automáticamente a través del autoloader de Composer.

Lo que roba es una pesadilla:

Credenciales de la nube (AWS, GCP, Azure)
Claves privadas SSH
Contraseñas y cookies del navegador
Bóvedas de gestores de contraseñas
Billeteras de criptomonedas
Archivos .env con secretos
Y básicamente cualquier otra cosa que parezca valiosa

El ataque golpeó durante una ventana de 15 minutos y comprometió 233 versiones en cuatro paquetes. Si ejecutastecomposer update entre las 22:32 UTC y la medianoche del 22 de mayo, podrías haber invitado a un ladrón digital a tu máquina.

2. Mi Configuración: PHP en una Caja

Así es como ejecuto PHP y Composer en mi máquina local:

El script php-docker inicia un contenedor Docker y ejecuta PHP dentro de él:

Obtiene el directorio de trabajo actual desde donde se está ejecutando el comando (ej: ~/Projects/my-awesome-project)
Monta el directorio de trabajo actual como un volumen en el contenedor y cambia a él
NO monta ningún otro directorio, como /tmp, /home, /root, etc.

/usr/local/bin/php-docker

#!/bin/bash

# obtener la versión especificada y eliminarla de los argumentos
PHP_VERSION=$1
shift

# obtener el directorio de trabajo actual desde donde se ejecuta el comando
ORIGIN_PWD="$PWD"
# moverse al directorio del proyecto php dockerizado
cd "/opt/docker/php-fpm/" || exit

# ejecutar el contenedor de la versión php especificada
command docker compose run --rm --remove-orphans --quiet --quiet-build --quiet-pull \
  --interactive \
  # montar el directorio de ejecución original y cd a él
  --volume "${ORIGIN_PWD}":"${ORIGIN_PWD}" \
  --workdir "${ORIGIN_PWD}" \
  php-fpm-"$PHP_VERSION" php "$@"

# volver al directorio original
cd "$ORIGIN_PWD" || exit

En lugar del binario php, tengo un pequeño script que ejecuta el script php-docker con la versión de PHP especificada (obtenida del nombre del archivo):

/usr/local/bin/php

#!/bin/bash

# obtener la versión del nombre del archivo
PHP_VERSION=${0##*-}
# validar el formato de la versión
if [ ${#PHP_VERSION} -ne 3 ]; then
  # fallback a la última versión estable
  PHP_VERSION=8.5
fi

# ejecutar php-docker especificando la versión y pasando los argumentos
command php-docker "$PHP_VERSION" "$@"

Y múltiples enlaces al mismo script:

$ ls /usr/local/bin/php*
/usr/local/bin/php
/usr/local/bin/php-5.6 -> php
/usr/local/bin/php-7.4 -> php
/usr/local/bin/php-8.0 -> php
...
/usr/local/bin/php-8.5 -> php
/usr/local/bin/php-docker -> /opt/docker/php-fpm/bin/php-docker

De esa manera, cualquier ejecución cli php-* se ejecutará dentro del contenedor Docker de la versión de PHP especificada.

$ php -v
PHP 8.5.5 (cli) (built: Apr 18 2026 10:39:21) (ZTS)
Copyright (c) The PHP Group
Built by HDS Solutions
Zend Engine v4.5.5, Copyright (c) Zend Technologies
    with Xdebug v3.5.1, Copyright (c) 2002-2026, by Derick Rethans
    with Zend OPcache v8.5.5, Copyright (c), by Zend Technologies

$ php-7.4 -v
PHP 7.4.33 (cli) (built: Apr 18 2026 10:47:16) ( ZTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Xdebug v3.1.6, Copyright (c) 2002-2022, by Derick Rethans

Mi comando composer sigue el mismo patrón, todo se ejecuta dentro de Docker.

/usr/local/bin/composer

#!/bin/bash

PHP_VERSION=${0##*-}
if [ ${#PHP_VERSION} -ne 3 ]; then
  PHP_VERSION=8.5
fi

# ejecutar php-docker especificando la versión y pasando los argumentos al cli de composer
command php-docker "$PHP_VERSION" /usr/bin/composer "$@"

¿Por qué configuré esto? Originalmente para soportar múltiples versiones de PHP, tener builds ZTS, y migrar fácilmente cuando compras una nueva laptop. Pero como lo descubriría más adelante, esta elección arquitectónica tuvo un beneficio de seguridad que no fue intencional.

3. Qué Me Protegió Docker

Cuando el payload de Laravel-Lang se ejecuta, busca credenciales en ubicaciones específicas. Así es como mi configuración de Docker lo bloqueó:

a) Secretos del Directorio Home: Estilo Fort Knox

El robo apunta a:

~/.ssh/ - Claves privadas SSH
~/.aws/credentials - Credenciales de AWS
~/.config/gcloud/ - Credenciales de GCP
~/.azure/ - Credenciales de Azure
.git-credentials, .netrc, .npmrc, .pypirc
Datos del navegador (perfiles Chrome, Firefox)
Bóvedas de gestores de contraseñas (KeePass, 1Password)
Billeteras de criptomonedas

Resultado: Ninguno de estos existe en el contenedor. El directorio home del contenedor está "vacío". El atacante no encuentra nada.

/opt/docker/php-fpm/docker-compose.yml

services:
    php-fpm-8.5:
        container_name: php-fpm-zts-8.5
        domainname: php-fpm-8.5.vanilla
        build:
            args:
                user: ${USER:-http}
                uid: 33
                PHP_VERSION: 8.5
            context: ./docker
            dockerfile: common/Dockerfile
        volumes:
            - ./docker/common/php/00-php.ini:/usr/local/etc/php/conf.d/00-php.ini:ro
            - ./docker/common/php-fpm/www.conf:/usr/local/etc/php-fpm.d/www-docker.conf:ro
            - ./docker/8.5/home/.composer/cache:/home/http/.composer/cache:rw
            - ./docker/8.5/home/.composer/vendor:/home/http/.composer/vendor:rw

    php-fpm-8.4:
        container_name: php-fpm-zts-8.4
        domainname: php-fpm-8.4.vanilla
        build:
            args:
                user: ${USER:-http}
                uid: 33
                PHP_VERSION: 8.4
            context: ./docker
            dockerfile: common/Dockerfile
        ...

    php-fpm-8.3:
        container_name: php-fpm-zts-8.3
        ...

    ...

b) Secretos a Nivel de Sistema: Aislados

El payload también escanea:

/etc/kubernetes/admin.conf - Configuraciones de Kubernetes
/var/run/secrets/ - Secretos de CI/CD
Gestores de credenciales del sistema

Resultado: El contenedor no tiene acceso a los directorios del sistema host. Estos están aislados.

c) Datos del Navegador y Contraseñas: Inexistentes

El robo busca bases de datos del navegador, bóvedas de gestores de contraseñas, y billeteras de criptomonedas.

Resultado: No hay navegador, no hay gestor de contraseñas, no hay billeteras en el contenedor. Solo PHP y tu código.

4. Qué No Me Protegió Docker

O por qué no estoy lanzando un desfile de victoria todavía

Mi configuración de Docker añadió una capa de seguridad significativa, pero no es perfecta. Así es lo que sigue siendo vulnerable:

a) Secretos del Directorio del Proyecto: La Puerta Abierta

El contenedor monta tu directorio del proyecto. Si tu archivo .env contiene secretos, el robo puede leerlo:

.env

AWS_ACCESS_KEY_ID=1U0o...pzdZ
AWS_SECRET_ACCESS_KEY=KKaY...aKEd
REDIS_PASSWORD=XSFK...y4XV

Mitigación: Usa servicios solo locales (explicaré en un momento).

b) Claves de API Externas: Todavía en Riesgo

Tu archivo .env podría contener claves de API externas:

Claves de API de Google Maps
Claves de reCAPTCHA
Tokens de servicios de terceros

Estas se exfiltran si el payload se ejecuta.

Mitigación: Rota estas claves si ejecutaste composer durante la ventana del ataque.

5. Mi Estrategia de Defensa: Todo Local

Para minimizar lo que el robo podría robar, uso servicios solo locales para desarrollo (todos ellos también dockerizados):

# configuración .env
DB_CONNECTION=dynamodb
DYNAMODB_ENDPOINT=http://localhost:8000  # DynamoDB Local

BROADCAST_CONNECTION=pusher
PUSHER_HOST=soketi.vanilla  # Instancia Soketi Local

REDIS_HOST=redis-8.6.vanilla  # Redis Local
REDIS_PASSWORD=a3BM...6nys

AWS_ENDPOINT=https://minio.vanilla  # MinIO Local
AWS_ACCESS_KEY_ID=0onp...ZHjn
AWS_SECRET_ACCESS_KEY=fzfK...Aear

Por qué funciona: Incluso si estas credenciales se roban, son inútiles para un atacante. Solo funcionan contralocalhost o mis dominios de red local (*.vanilla). El atacante no puede alcanzar mi infraestructura de desarrollo local.

Qué mantengo externo: Clave de API de Google Maps, claves de reCAPTCHA. Estos son los puntos débiles, pero son de bajo riesgo comparado con las credenciales de proveedores de la nube.

6. El Veredicto: Docker como Capa de Seguridad

Mi configuración de Docker no fue diseñada para seguridad, fue diseñada para consistencia entre versiones de PHP y cambiarme fácilmente de laptop. Pero esa elección arquitectónica proporcionó protección significativa contra este ataque, completamente por accidente.

Cuando descubrí por primera vez que mi versión estaba comprometida, sentí ese sudor frío. Verifiqué mis claves SSH, mis credenciales de AWS, mis datos del navegador, todo estaba ahí. Mi ritmo cardíaco volvió lentamente a la normalidad mientras me daba cuenta: el payload había corrido, pero no tenía dónde buscar.

Si hubiera estado ejecutando PHP directamente en mi máquina host, la historia habría sido muy diferente. El robo habría encontrado mis claves SSH, mis credenciales de la nube, mis contraseñas del navegador, quizás incluso mi billetera de criptomonedas. Eso no es solo una brecha de seguridad, es robo de identidad esperando a suceder.

Lo que Docker me dio:

Aislamiento de secretos del directorio home—mis claves SSH, credenciales de AWS, y datos del navegador viven fuera del contenedor
Sin acceso a credenciales a nivel de sistema—configuraciones de Kubernetes, secretos de CI/CD, y gestores de credenciales del sistema son inalcanzables
Sin datos de navegador o gestor de contraseñas—no hay Chrome, Firefox, o KeePass dentro del contenedor
Ejecución en contenedor que limita lo que el payload puede ver—el atacante obtiene un ambiente estéril con nada valioso

Lo que Docker no me dio:

Protección contra secretos de archivo .env en el directorio del proyecto—si tuviera credenciales de producción ahí, se habrían ido
Protección contra fugas de variables de entorno—los secretos pasados al contenedor siguen siendo accesibles
Protección contra robo de claves de API externas—las claves de Google Maps y reCAPTCHA todavía se habrían exfiltrado

En resumen: Docker redujo mi superficie de ataque significativamente. En lugar de perder claves SSH, credenciales de la nube, datos del navegador, y billeteras de criptomonedas, el peor escenario sería perder credenciales de desarrollo local y algunas claves de API. Esa es la diferencia entre "mi fin de semana está arruinado" y "mi vida está arruinada".

7. Cómo Dormir Mejor por la Noche: Endurece Tu Configuración

Si no estás ejecutando PHP/Composer en Docker, considéralo. Los beneficios de consistencia por sí solos valen la pena, y el beneficio de seguridad es un bono agradable. Si ya estás usando Docker, así es cómo hacerlo aún más seguro:

a) Nunca Montes el Directorio Home

Obvio, pero crítico. Tu directorio home contiene las joyas de la corona: claves SSH, credenciales de la nube, datos del navegador, gestores de contraseñas. Si lo montas, estás invitando al atacante a tu casa.

b) Usa Servicios Solo Locales para Desarrollo

No uses credenciales de la nube de producción en desarrollo. Ejecuta instancias locales de todo:

Bases de datos (MySQL, PostgreSQL, DynamoDB Local)—Docker Compose hace esto trivial
Redis—inicia un contenedor, nunca toques una instancia real de Redis
Almacenamiento de objetos (MinIO compatible con S3)—simula el comportamiento de AWS S3 localmente
Colas de mensajes—RabbitMQ local o equivalente

El objetivo: si las credenciales se filtran, son inútiles porque solo funcionan contra localhost.

c) Separa Archivos `.env`

Mantén .env fuera del control de versiones (obviamente). Usa diferentes archivos .env para local, staging, y producción. Nunca, nunca lleves secretos en tus commits. Si lo haces por accidente, rótalos inmediatamente.

El historial de Git es para siempre.

d) No Pases Secretos Variables de Entorno

Para desarrollo, usa servicios locales. Para producción, usa sistemas de gestión de secretos (ej: AWS Secrets Manager). Pasar secretos vía variables de entorno es conveniente, pero también es filtrable—listas de procesos, herramientas de depuración, y frameworks de logging pueden exponerlos.

e) Monitorea IOCs

Si quieres saber si fuiste afectado, busca:

Tráfico de red a flipboxstudio[.]info—si tienes logging de tráfico (ej: uso Pi-Hole ³)
Archivos en /tmp/.laravel_locale/—el dropper escribe marcadores de infección aquí
Procesos PHP sospechosos—procesos PHP huérfanos sin padre son una bandera roja

f) Bloquea Tus Dependencias

Usa composer.lock y verifica los SHAs de commit. El ataque reescribió etiquetas, los SHAs de commit bloqueados de antes de la ventana del ataque son seguros. Cuando descargas dependencias, verifica que el SHA de commit coincida con lo que esperas.

También, una buena práctica es ejecutar composer outdated, revisar manualmente el CHANGELOG de cada paquete, y después de revisar los cambios, actualizar el paquete a la última versión. Si los cambios no añaden ninguna característica necesaria, o corrigen vulnerabilidades de seguridad, puedes ignorar el update de forma segura.

8. ¿Qué Sigue?

Docker no es una bala de plata, pero es una capa poderosa en tu estrategia de seguridad. El ataque de Laravel-Lang nos mostró que los ataques Supply Chain son reales, sofisticados, y cada vez más comunes.

En mi caso, una decisión tomada por consistencia de desarrollo se convirtió en una característica de seguridad. Configuré Docker para gestionar múltiples versiones de PHP y builds ZTS, pero accidentalmente construí un búnker de seguridad.

A veces la mejor seguridad es la que no sabías que tenías.

Pero aquí está el tema: Docker es solo una pieza del rompecabezas. También necesitas bloqueo de dependencias, gestión de secretos, monitoreo de red, y una dosis saludable de paranoia. La seguridad no es un destino, es un viaje, y los ataques Supply Chain son solo un peligro en el camino.

La próxima vez que configures un ambiente de desarrollo, piensa en las implicaciones de seguridad de tus elecciones. Docker, servicios locales, redes aisladas, estos no son solo conveniencias. Son armadura.

¿Y si todavía estás ejecutando PHP directamente en tu máquina host? Bueno, quizás sea hora de ponerlo en una caja. Tu futuro yo podría agradecértelo.

Pregunta para ti: ¿Ejecutas tus herramientas de desarrollo en Docker o directamente en tu host? ¿Alguna vez has considerado las implicaciones de seguridad de esa elección? Comenta abajo, tengo curiosidad sobre cómo otros manejan esto.

How My Docker Setup Saved Me From a Supply Chain Attack (And Why Yours Should Too)

Hermann D. Schimpf — Mon, 25 May 2026 23:49:56 +0000

Versión en español aquí.

It's finally Friday! You leave work and go home to work on your side project (yep, that's me). You open your computer and start working on it by running composer update because you want to keep your dependencies up to date.

Next morning, you wake up to the news that a popular Laravel package you use has been compromised. Attackers injected a credential stealer into 233 versions, ready to exfiltrate your SSH keys, cloud credentials, browser data, crypto wallets—the whole digital enchilada ¹. Panic sets in. You check your composer.lock. Your heart skips a beat. You have version 15.29.3 of laravel-lang/lang, one of the compromised versions ².

Been there? I was, on May 22, 2026.

But here's the plot twist: When I dug deeper, I realized my Dockerized PHP setup had just become my unexpected bodyguard. Let me tell you how running PHP through Docker containers added a security layer I never planned for, and why you should consider it too.

1. The Attack: When `composer update` Goes Rogue

On May 22, 2026, attackers compromised the Laravel-Lang organization on GitHub. They didn't just publish a malicious version—they rewrote every git tag across four popular packages to point to their own commits. The payload? A credential stealer disguised as a harmless helper file that runs automatically via Composer's autoloader.

What it stole is nightmare fuel:

Cloud credentials (AWS, GCP, Azure)
SSH private keys
Browser passwords and cookies
Password manager vaults
Crypto wallets
.env files with secrets
And basically anything else that looks valuable

The attack hit during a 15-minute window and compromised 233 versions across four packages. If you ran composer update between 22:32 UTC and midnight on May 22, you might have invited a digital burglar into your machine.

2. My Setup: PHP in a Box

Here's how I run PHP and Composer on my local machine:

The php-docker script spins up a Docker container and runs PHP inside it:

Gets the current working directory from where the command is being executed (ex: ~/Projects/my-awesome-project)
Mounts the current working directory as a volume in the container and changes to it
Does NOT mount any other directory, like /tmp, /home, /root, etc.

/usr/local/bin/php-docker

#!/bin/bash

# get specified version and remove it from arguments
PHP_VERSION=$1
shift

# get the current working directory from where the command is being executed
ORIGIN_PWD="$PWD"
# move into the dockerized php project directory
cd "/opt/docker/php-fpm/" || exit

# execute the specified php version container
command docker compose run --rm --remove-orphans --quiet --quiet-build --quiet-pull \
  --interactive \
  # mount the origin execution directory and cd to it
  --volume "${ORIGIN_PWD}":"${ORIGIN_PWD}" \
  --workdir "${ORIGIN_PWD}" \
  php-fpm-"$PHP_VERSION" php "$@"

# go back to original directory
cd "$ORIGIN_PWD" || exit

Instead of the php binary, I have a small script that runs the php-docker script with the specified PHP version (obtained from the filename):

/usr/local/bin/php

#!/bin/bash

# get the version from the filename
PHP_VERSION=${0##*-}
# validate version format
if [ ${#PHP_VERSION} -ne 3 ]; then
  # fallback to latest stable version
  PHP_VERSION=8.5
fi

# execute php-docker specifying version and passing through arguments
command php-docker "$PHP_VERSION" "$@"

And multiple links to the same script:

$ ls /usr/local/bin/php*
/usr/local/bin/php
/usr/local/bin/php-5.6 -> php
/usr/local/bin/php-7.4 -> php
/usr/local/bin/php-8.0 -> php
...
/usr/local/bin/php-8.5 -> php
/usr/local/bin/php-docker -> /opt/docker/php-fpm/bin/php-docker

That way, any php-* cli execution will run inside the Docker container of the specified PHP version.

$ php -v
PHP 8.5.5 (cli) (built: Apr 18 2026 10:39:21) (ZTS)
Copyright (c) The PHP Group
Built by HDS Solutions
Zend Engine v4.5.5, Copyright (c) Zend Technologies
    with Xdebug v3.5.1, Copyright (c) 2002-2026, by Derick Rethans
    with Zend OPcache v8.5.5, Copyright (c), by Zend Technologies

$ php-7.4 -v
PHP 7.4.33 (cli) (built: Apr 18 2026 10:47:16) ( ZTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Xdebug v3.1.6, Copyright (c) 2002-2022, by Derick Rethans

My composer command follows the same pattern, everything runs inside Docker.

/usr/local/bin/composer

#!/bin/bash

PHP_VERSION=${0##*-}
if [ ${#PHP_VERSION} -ne 3 ]; then
  PHP_VERSION=8.5
fi

# execute php-docker specifying version and passing through arguments to composer cli
command php-docker "$PHP_VERSION" /usr/bin/composer "$@"

Why did I set this up? Originally to support multiple PHP versions, have ZTS builds, and easily migrate when you buy a new laptop. But as I would discover, this architectural choice had an unintended security benefit.

3. What Docker Protected Me From

When the Laravel-Lang payload executes, it hunts for credentials in specific locations. Here's what my Docker setup blocked:

a) Home Directory Secrets: Fort Knox Style

The stealer targets:

~/.ssh/ - SSH private keys
~/.aws/credentials - AWS credentials
~/.config/gcloud/ - GCP credentials
~/.azure/ - Azure credentials
.git-credentials, .netrc, .npmrc, .pypirc
Browser data (Chrome, Firefox profiles)
Password manager vaults (KeePass, 1Password)
Crypto wallets

Result: None of these exist in the container. The container's home directory is "empty". The attacker finds nothing.

/opt/docker/php-fpm/docker-compose.yml

services:
    php-fpm-8.5:
        container_name: php-fpm-zts-8.5
        domainname: php-fpm-8.5.vanilla
        build:
            args:
                user: ${USER:-http}
                uid: 33
                PHP_VERSION: 8.5
            context: ./docker
            dockerfile: common/Dockerfile
        volumes:
            - ./docker/common/php/00-php.ini:/usr/local/etc/php/conf.d/00-php.ini:ro
            - ./docker/common/php-fpm/www.conf:/usr/local/etc/php-fpm.d/www-docker.conf:ro
            - ./docker/8.5/home/.composer/cache:/home/http/.composer/cache:rw
            - ./docker/8.5/home/.composer/vendor:/home/http/.composer/vendor:rw

    php-fpm-8.4:
        container_name: php-fpm-zts-8.4
        domainname: php-fpm-8.4.vanilla
        build:
            args:
                user: ${USER:-http}
                uid: 33
                PHP_VERSION: 8.4
            context: ./docker
            dockerfile: common/Dockerfile
        ...

    php-fpm-8.3:
        container_name: php-fpm-zts-8.3
        ...

    ...

b) System-Level Secrets: Isolated

The payload also scans:

/etc/kubernetes/admin.conf - Kubernetes configs
/var/run/secrets/ - CI/CD secrets
System credential managers

Result: The container doesn't have access to host system directories. These are isolated.

c) Browser and Password Data: Nonexistent

The stealer looks for browser databases, password manager vaults, and crypto wallets.

Result: No browser, no password manager, no wallets in the container. Just PHP and your code.

4. What Docker Didn't Protect

Or why I'm not throwing a victory parade just yet

My Docker setup added a significant security layer, but it's not perfect. Here's what remains vulnerable:

a) Project Directory Secrets: The Open Door

The container mounts your project directory. If your .env file contains secrets, the stealer can read it:

.env

AWS_ACCESS_KEY_ID=1U0o...pzdZ
AWS_SECRET_ACCESS_KEY=KKaY...aKEd
REDIS_PASSWORD=XSFK...y4XV

Mitigation: Use local-only services (I'll explain in a moment).

b) External API Keys: Still at Risk

Your .env might contain external API keys:

Google Maps API keys
reCAPTCHA keys
Third-party service tokens

These get exfiltrated if the payload runs.

Mitigation: Rotate these keys if you ran composer during the attack window.

5. My Defense Strategy: Local-Everything

To minimize what the stealer could steal, I use local-only services for development (all of them also dockerized):

# .env configuration
DB_CONNECTION=dynamodb
DYNAMODB_ENDPOINT=http://localhost:8000  # Local DynamoDB

BROADCAST_CONNECTION=pusher
PUSHER_HOST=soketi.vanilla  # Local Soketi instance

REDIS_HOST=redis-8.6.vanilla  # Local Redis
REDIS_PASSWORD=a3BM...6nys

AWS_ENDPOINT=https://minio.vanilla  # Local MinIO
AWS_ACCESS_KEY_ID=0onp...ZHjn
AWS_SECRET_ACCESS_KEY=fzfK...Aear

Why this works: Even if these credentials get stolen, they're useless to an attacker. They only work against localhost or my local network domains (*.vanilla). The attacker can't reach my local development infrastructure.

What I keep external: Google Maps API key, reCAPTCHA keys. These are the weak points, but they're low-risk compared to cloud provider credentials.

6. The Verdict: Docker as Security Layer

My Docker setup wasn't designed for security, it was designed for consistency across PHP versions and easy laptop migration. But that architectural choice provided significant protection against this supply chain attack, completely by accident.

When I first discovered my version was compromised, I felt that familiar cold sweat. I checked my SSH keys, my AWS credentials, my browser data—everything was there. My heart rate slowly returned to normal as I realized: the payload had run, but it had nowhere to look.

If I had been running PHP directly on my host machine, the story would have been very different. The stealer would have found my SSH keys, my cloud credentials, my browser passwords, maybe even my crypto wallet. That's not just a security breach—that's identity theft waiting to happen.

What Docker gave me:

Isolation from home directory secrets—my SSH keys, AWS credentials, and browser data live outside the container
No access to system-level credentials—Kubernetes configs, CI/CD secrets, and system credential managers are unreachable
No browser or password manager data—there's no Chrome, Firefox, or KeePass inside the container
Containerized execution that limits what the payload can see—the attacker gets a sterile environment with nothing valuable

What Docker didn't give me:

Protection against .env file secrets in project directory—if I had production credentials there, they'd be gone
Protection against environment variable leaks—secrets passed to the container are still accessible
Protection against external API key theft—Google Maps and reCAPTCHA keys would still be exfiltrated

The bottom line: Docker reduced my attack surface significantly. Instead of losing SSH keys, cloud credentials, browser data, and crypto wallets, the worst-case scenario would be losing local development credentials and a few API keys. That's the difference between "my weekend is ruined" and "my life is ruined".

7. How to sleep better at night: Harden Your Setup

If you're not running PHP/Composer in Docker, consider it. The consistency benefits alone are worth it, and the security upside is a nice bonus. If you are already using Docker, here's how to make it even more secure:

a) Never Mount Home Directory

Obvious, but critical. Your home directory contains the crown jewels: SSH keys, cloud credentials, browser data, password managers. If you mount it, you're inviting the attacker into your house.

b) Use Local-Only Services for Development

Don't use production cloud credentials in development. Run local instances of everything:

Databases (MySQL, PostgreSQL, DynamoDB Local)—Docker Compose makes this trivial
Redis—spin up a container, never touch a real Redis instance
Object storage (MinIO for S3-compatible)—mocks AWS S3 behavior locally
Message queues—local RabbitMQ or equivalent

The goal: if credentials leak, they're useless because they only work against localhost.

c) Separate `.env` Files

Keep .env out of version control (obviously). Use different .env files for local, staging, and production. Never, ever commit your secrets. If you do by accident, rotate them immediately.

Git history is forever.

d) Don't Pass Secrets via Environment Variables

For development, use local services. For production, use secret management systems (e.g., AWS Secrets Manager). Passing secrets via environment variables is convenient, but it's also leaky-process lists, debugging tools, and logging frameworks can expose them.

e) Monitor for IOCs

If you want to know if you were affected, look for:

Network traffic to flipboxstudio[.]info—if you have traffic logging (e.g., I use Pi-Hole ³)
Files in /tmp/.laravel_locale/—the dropper writes infection markers here
Suspicious PHP processes—orphaned PHP processes with no parent are a red flag

f) Lock Your Dependencies

Use composer.lock and verify commit SHAs. The attack rewrote tags, locked commit SHAs from before the attack window are safe. When you pull dependencies, check the commit SHA matches what you expect.

Also, a good practice is to run composer outdated, manually go through the CHANGELOG of each package, and after reviewing the changes, update the package to the latest version. If the changes don't add any needed features, or fix any security vulnerabilities, you can safely ignore the update.

8. What's Next?

Docker isn't a silver bullet, but it's a powerful layer in your security strategy. The Laravel-Lang attack showed us that supply chain attacks are real, sophisticated, and increasingly common.

In my case, a decision made for development consistency became a security feature. I set up Docker to manage multiple PHP versions and ZTS builds, but I accidentally built a security bunker.

Sometimes the best security is the kind you didn't know you had.

But here's the thing: Docker is just one piece of the puzzle. You also need dependency locking, secret management, network monitoring, and a healthy dose of paranoia. Security isn't a destination, it's a journey, and supply chain attacks are just one hazard along the way.

The next time you're setting up a development environment, think about the security implications of your choices. Docker, local services, isolated networks, these aren't just conveniences. They're armor.

And if you're still running PHP directly on your host machine? Well, maybe it's time to put it in a box. Your future self might thank you.

Question for you: Do you run your development tools in Docker or directly on your host? Have you ever considered the security implications of that choice? Share below, I'm curious how others handle this.

How I Managed to Take My Laravel Application to the Serverless World (And How I Almost Died Trying)

Hermann D. Schimpf — Tue, 01 Apr 2025 18:18:57 +0000

Versión en español aquí.

In the first chapter of this journey, we explored why migrating to AWS Serverless was the best decision for my Laravel application. We talked about automatic scalability, cost savings, and freedom from traditional maintenance. But like in every great adventure, the path has its obstacles.

One of the concerns shared by most readers is that since serverless does all the magic for you and scales automatically, your wallet would also need to do so.

And I must be honest with you: I fell into the trap of the magical serverless. While I celebrated the absence of servers, my code wandered through the cloud like a tourist with an unlimited credit card: enthusiastic, but wasting resources at every step.

But hey! That's why I'm here today—to reveal what no tutorial warned me about: the art of writing PHP conscious of Lambda.

Let's dive into how to turn our Laravel application into a true serverless warrior. Yes, we will tackle the necessary optimizations and the precautions we must take.

But let's start lightly with some new concepts.

1. The Serverless Magic

a) Lambda: The Execution Chef

AWS Lambda is, in short, the chef that cooks your code just when needed. Its event-driven model means it only activates upon requests (HTTP, SQS events, cron jobs, etc.), and like an a la carte kitchen, you only pay for the time the stove is used. Additionally, Lambda's free tier allows you to start without worries, as long as you keep an eye on usage limits.

But: Did you know that AWS Lambda, among all the languages it natively supports, PHP is not one of them? 😤

For our peace of mind, Lambda allows us to define our own custom runtimes.

b) Bref: The Bridge that Connects PHP and Lambda

Although I'd love to have created my own solution to run PHP on Lambda like some suggested (and thanks in advance for trusting my abilities so much), sometimes it's not necessary to reinvent the wheel.

That's where Bref comes in, an essential tool that allows us to run PHP applications on Lambda without rewriting all our code.

Great! But, how does it work?

Personally, I love knowing the inner workings of things, but to keep it simple, Bref operates as follows:

When a request enters your application, it is captured by API Gateway and sent to the Lambda function, where Bref's runtime starts PHP-FPM in the background and redirects the request via FastCGI. Once the result is obtained, it is returned to API Gateway, which in turn sends it as a response to the end user.

Simple, right?

c) Serverless Framework: The Glue That Binds All Components

Can you imagine the amount of configurations needed to set up a Lambda function with a custom runtime that runs Bref (and with it, PHP-FPM) so that your Laravel code can work?

Well, you can relax: the Serverless framework does all that for you. You just need to define the necessary components in a serverless.yml configuration file and, with a simple serverless deploy, you're in the cloud! 🚀

2. Preparing Laravel for the Serverless Jungle

First, you need to understand that migrating to a serverless environment means that Laravel must go into "nomadic mode". This means adapting it to be stateless.

Do you remember when I mentioned that Lambda is ephemeral? The simplest way to imagine Lambda is like talking to someone with a very short memory: every time you start the conversation, you have to reintroduce yourself (e.g., session data). Do you give him a notebook to write something down and then return it to you (file uploads)? Forget about it, you won't even find it in the limbo of Inception.

So, some essential adjustments are necessary:

Logs to stderr: You don't have SSH access to Lambda, so you need to store logs in CloudWatch.
Read-only storage: The file system in Lambda is read-only, except for the /tmp directory. So, file uploads need to be stored in S3 (or similar).
Sessions: You need to move session data to cookies or, better yet, use DynamoDB for a more robust solution.
Cache: For simplicity, we'll opt for DynamoDB.
Environment variables: Forget about the .env file in production; you'll need to use variables defined in the serverless.yml configuration file.

Bref's Survival Kit

To make these adjustments easier, the Bref community has created a package called bref/laravel-bridge that automates most of the changes mentioned above.

Getting Our Hands Dirty: Transforming Laravel into a Cloud Nomad

It's time to get our hands dirty.

If you want to follow along step by step, the requirements from this point on are:

PHP (obviously!)
Composer ¹
Node.js ²
serverless ³

Let's start by creating a new Laravel project ⁴:

# Installing Laravel
laravel new laravel-above-the-clouds
cd laravel-above-the-clouds

# Create and migrate the database (sqlite by default)
php artisan migrate

# Install Node.js packages (Vite.js, Tailwind CSS, etc.) and compile assets
npm install && npm run build

Install the bref/bref and bref/laravel-bridge packages ⁵:

composer require bref/bref bref/laravel-bridge --update-with-dependencies

The bref/laravel-bridge package, as I mentioned earlier, resolves the necessary adjustments for Laravel to work in a serverless environment.

Bref already includes a preconfigured serverless.yml file that we can use as a starting point for our first deploy:

php artisan vendor:publish --tag=serverless-config

Think of the serverless.yml file as a set of LEGO instructions for AWS: it's the guide that allows you to set up your application flawlessly.

Deploy the project:

serverless deploy

When finishes, in the console you will get the API Gateway URL to access your application on AWS!

3. But, what happened with my CSS?

The first thing you'll notice is that the assets (CSS and JS) don't load correctly. This happens because, in a serverless environment, we don't have Apache or Nginx to serve static assets; and here I want to make a brief pause.

Taking our application to a serverless environment implies changing our mind-set that a single server is responsible for performing all the tasks to make our application work. In a serverless environment, each component must be managed by a specialized service.

In our case, some of the main components in a Laravel application are as follows:

Component	Servidor Dedicated Server	AWS Serverless
Routes, Controllers, ...	PHP-FPM	Lambda
Static Assets (images, javascript, css)	Apache / Nginx	S3
Session Data	Database / Cookies	RDS / DynamoDB
Cache	Local Disk	DynamoDB / Redis
File Upload	Local Disk	S3
Scheduled Tasks (Schedule)	crontab	EventBridge
Event Queue	SSH $ `php artisan queue:work` / maybe supervisor	SQS
`artisan` Commands	SSH $ `php artisan ...`	Lambda
Application Log	SSH $ `tail -f storage/logs/*`	CloudWatch

But let's take it easy, solving one point at a time.

From Complexity to Simplicity: Serverless Orchestration

From the points mentioned, the bref/laravel-bridge package already solves application logs and session data. A log group is created in CloudWatch for application logs, and session data is stored in cookies (we will later see how to move session data to DynamoDB).

To serve static assets, we have two alternatives:

The hard way: Add the creation of a S3 Bucket to our serverless.yml configuration, obtain the bucket name, build the public URL, and assign it to the ASSET_URL environment variable.
The easy way: Use the serverless-lift plugin ⁶, and let the magic flow.

Although I learned a lot the hard way (I've been following Bref's growth since 2020 ⁷), you can take advantage of community-developed tools that simplify our lives.

We install the serverless-lift plugin and add a new section ⁸ within the serverless.yml file:

serverless plugin install -n serverless-lift

service: laravel

- # ...

functions:
  web:
    handler: public/index.php
    runtime: php-82-fpm

- # ...

  artisan:
    handler: artisan
    runtime: php-82-console

- # ...

+ constructs:
+   website:
+     type: server-side-website
+     assets:
+       '/build/*': public/build
+       # Add here any file or directory that needs to be served from S3

plugins:
  - ./vendor/bref/bref
+   - serverless-lift

Within the constructs section, we have defined a website component of type server-side-website. This tells the serverless-lift plugin to create a CloudFront distribution, which will act as a CDN to serve static files from an S3 Bucket, and also as a reverse proxy, redirecting requests to your PHP application's routes through API Gateway => Lambda.

serverless deploy

This deployment will take an additional 5-7 minutes only once, as CloudFront distributions are created globally. Subsequent deployments will be faster, as long as you don't modify configurations that affect the CloudFront distribution.

In the console output, you will see that you now have two URLs, one from the API Gateway (which we will no longer use), and another from CloudFront, which will serve static assets from the S3 Bucket, and the rest of the routes will be processed by Lambda.

And now the CSS loads correctly! Congratulations, you have deployed your first Laravel application in a serverless environment.

4. Optimizing for the Real World: The Battle Against Cold-Start

You may have noticed that the first time you accessed your application, it took a few extra seconds to respond.

As I mentioned in the previous article, this is called a cold-start and occurs when Lambda initializes a new instance to run your application. This initialization can take 250ms or more, especially if your application is large.

Lambda keeps an instance alive for up to 10 minutes after processing a request, then it is automatically destroyed.

We can address this from several fronts.

a) Keep a Lambda instance always alive ⁹

In low-traffic applications, it is normal to have periods of inactivity greater than 10 minutes, so we may have a higher percentage of requests processed in a cold-start.

Bref provides a special event that we can use to keep a Lambda instance alive. We simply need to add a schedule event in our serverless.yml configuration file with the payload {warmer: true}. Bref will recognize this special event and respond instantly with status code 100 ¹⁰ without executing your code, thus keeping the instance alive.

service: laravel

- # ...

functions:
  web:
    handler: public/index.php
    runtime: php-82-fpm
    events:
      - httpApi: '*'
+       - schedule:
+         rate: rate(5 minutes)
+         input:
+           warmer: true

b) Reducing the size of your application

During a cold-start, AWS Lambda downloads the application package, decompresses it in a temporary environment, and loads the runtime with all the necessary dependencies and configurations. This process, although optimized, adds latency to the first request. Therefore, reducing the package size (for example, by removing development dependencies or unnecessary modules) can significantly shorten this time.

The default serverless.yml file from Bref already ignores certain directories that are not necessary in PHP, such as node_modules.

Development packages

Before deploying, we can uninstall development packages. This will significantly reduce the size of the vendor directory, and consequently, the total size of the code sent to Lambda.

composer install --no-dev

AWS Services dependencies

In most of my applications, the composer package that takes up the most space is aws/aws-sdk-php (required by bref/laravel-bridge).

The good news is that the community has developed a composer script to clean up unused AWS service packages in our application ¹¹. We just need to specify the services we use in the composer.json file:

{
  "name": "laravel/laravel",
  "type": "project",
  ...
  "require": {
    "php": "^8.2",
    "bref/bref": "^2.3",
    "bref/laravel-bridge": "^2.5",
    "laravel/framework": "^11.31",
    "laravel/octane": "^2.8",
    ...
  },
  "scripts": {
+     "pre-autoload-dump": "Aws\\Script\\Composer\\Composer::removeUnusedServices",
    "post-autoload-dump": [
      "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
      "@php artisan package:discover --ansi"
    ],
    ...
  },
  "extra": {
    "laravel": {
      "dont-discover": []
    },
+     "aws/aws-sdk-php": [
+       "DynamoDb",
+       "S3",
+       "Sqs"
+     ]
  },
}

The cleanup script will run every time you run composer install or composer update.

c) Boosting Performance with Laravel Octane

Even when cold-starts occur, Laravel Octane kicks in to keep the application in memory and significantly reduce response times. By avoiding a full Laravel boot on each request, the user experience is greatly improved.

Laravel Octane acts as an accelerator that "keeps the application warm". Once Lambda initializes the application, Octane takes care of keeping it in memory, so that subsequent requests can be served almost instantly. It's like starting a car engine and leaving it ready to go at any moment, rather than starting it from scratch each time.

Steps to implement Laravel Octane:

composer require laravel/octane
php artisan octane:install

Once installed, update the serverless.yml file to use Laravel Octane as the handler ¹². This will ensure that your application runs with the improved performance that Laravel Octane offers:

service: laravel

- # ...

functions:
  web:
    handler: Bref\LaravelBridge\Http\OctaneHandler
    runtime: php-82
- # ...

Finally, deploy your application with the changes made:

serverless deploy

d) Metrics that Validate Progress

Applying all the improvements mentioned, we have reduced the initialization time (cold-start) of our application. And with Laravel Octane, we have not only improved the time of the cold-start, but also improved the overall response time of our application.

We can visualize the response times in the CloudWatch logs that were already configured automatically for us.

Cold-start without optimizations (499ms):

Cold-start with Laravel Octane and optimizations (190ms):

Note that when using Laravel Octane, Laravel execution is kept in memory, so be careful of memory leaks ¹³.

5. Falls and Lessons Learned: Errors Every Serverless Migrant Should Know

You may have noticed that there is a function called artisan in the serverless.yml file. This function uses the "console" version of the Bref runtime ¹⁴, which allows us to run Laravel Artisan commands in AWS Lambda.

Since we don't have SSH access to the Lambda instances, Bref provides a bridge to execute cli commands using the bref:cli command from serverless.

serverless bref:cli --args="<artisan command and its options>"
serverless bref:cli --args="route:list"

Optimizations

A very important point I want to reinforce is that we must change our mentality when developing applications for serverless environments. In this new paradigm, it is crucial to design our processes and workflows considering the unique characteristics of serverless computing, such as the ephemeral nature of functions and the billing model based on usage.

Serverless is not expensive... but poorly adapted code is.

In my first month migrating one of my applications to a serverless environment, I made the mistake of not thoroughly reviewing certain processes. One of them was responsible for synchronizing the products of the online store with an external billing system, including updating product images. And as I mentioned in the previous article, some processes are not ideal for execution in a serverless environment. In this case, I was paying for idle time, during the image download, my code in Lambda was not doing anything more than waiting 5-8 seconds per image. With 65,000 items in the store and two daily synchronizations, this resulted in a bill of ~$530 just for the idle time during image download.

This incident led me to redesign the synchronization process. In a first attempt at optimization, I implemented the download of multiple images in parallel using PHP ZTS, which led me to develop the hds-solutions/parallel-sdk library ¹⁵. This version reduced costs to ~160$, but it was still not enough; my goal was to have costs below what I was spending originally on EC2.

In a second attempt, I moved the image download process to a dedicated EC2 instance. Although this significantly reduced costs to ~50$, the application was divided into two separate components.

Finally, in the third version of the synchronization process, after talking to the client, I implemented a small script on the billing system server. Instead of my application downloading the images, this script sent the images directly from the billing system server to S3 using pre-signed URLs ¹⁶. This eliminated the costs associated with image download, leaving only the cost of S3 storage.

6. What's Next?

With this, we close another chapter in our journey to the serverless world! Today, we saw how to transform Laravel into a true cloud nomad, adapting it to live without the weight of a traditional server. But this is just the beginning.

In the next article, we'll dive into the heart of integration: we'll see how to transfer session and cache data to DynamoDB, how to use S3 for file management, configure SQS for queuing and use EventBridge to orchestrate scheduled tasks. See you in the next part!

In the meantime, have you migrated your Laravel application to serverless? Share your experiences in the comments! And for those who haven't, I encourage you to experiment with what we've implemented so far and share your doubts and experiences.

Como Logré Llevar Mi Aplicación Laravel al Mundo Serverless (Y como casi muero en el intento)

Hermann D. Schimpf — Tue, 11 Mar 2025 22:36:10 +0000

English version here.

En el primer capítulo de esta travesía, exploramos por qué migrar a AWS Serverless fue la mejor decisión para mi aplicación Laravel. Hablamos de escalabilidad automática, ahorro de costos y libertad del mantenimiento tradicional. Pero como en toda gran aventura, el camino tiene sus obstáculos.

Una de las preocupaciones que compartieron la mayoría de los lectores es que, dado que serverless hace toda la magia por ustedes y escala automáticamente, su billetera también tendría que hacerlo.

Y debo ser sincero con ustedes: caí en la trampa del serverless mágico. Mientras yo celebraba la ausencia de servidores, mi código se paseaba por la nube como un turista con tarjeta de crédito ilimitada: entusiasta, pero derrochando recursos a cada paso.

Pero hey! Para eso estoy hoy aquí—para revelarles lo que ningún tutorial me advirtió: el arte de escribir PHP consciente de Lambda.

Vamos a meternos de lleno en el cómo convertir nuestra aplicación Laravel en un verdadero guerrero serverless. Sí, atacaremos las optimizaciones necesarias y las precauciones que debemos tener.

Pero empecemos liviano con algunos conceptos nuevos.

1. La Magia Serverless

a) Lambda: El Chef de la Ejecución

AWS Lambda es, en pocas palabras, el chef que cocina el código justo cuando se le necesita. Su modelo basado en eventos significa que solo se activa ante solicitudes (HTTP, eventos de SQS, cron jobs, etc.) y, como en una cocina a la carta, solo pagan por el tiempo que se utiliza la estufa. Además, el nivel gratuito de Lambda les permite arrancar sin preocupaciones, siempre y cuando mantengan un ojo en los límites de uso.

Pero: ¿sabían que AWS Lambda, entre todos los lenguajes que soporta nativamente nativamente, PHP no es uno de ellos? 😤

Para nuestra tranquilidad, Lambda permite definir nuestros propios runtimes personalizados.

b) Bref: El Puente que une PHP y Lambda

Aunque me encantaría haber creado mi propia solución para ejecutar PHP en Lambda como sugirieron algunos (y gracias de antemano por confiar tanto en mis capacidades), a veces no es necesario reinventar la rueda.

Aquí es donde entra Bref, una herramienta esencial que nos permite ejecutar aplicaciones PHP en Lambda sin reescribir todo nuestro código.

¡Buenísimo! Pero, ¿cómo funciona?

Personalmente, me encanta conocer a fondo el funcionamiento interno de las cosas, pero para mantener la simplicidad, Bref opera de la siguiente manera:

Cuando una solicitud ingresa a tu aplicación, esta es capturada por API Gateway y enviada a ejecución en la función Lambda, donde el runtime de Bref inicia PHP-FPM en background y la redigire la solicitud vía FastCGI. Una vez obtenido el resultado, lo devuelve al API Gateway, para que a su vez sea enviado finalmente como respuesta al usuario final.

¿Simple, cierto?

c) Serverless Framework: El Pegamento que Une Todos los Componentes

¿Se imaginan la cantidad de configuraciones que necesitan realizar para poner en marcha una función Lambda, con un runtime personalizado, que ejecute Bref (y con éste, PHP-FPM) para que tu código Laravel pueda funcionar?

Pues ya puedes relajarte: el framework Serverless hace todo eso por ustedes. Solo tienen que definir los componentes necesarios en un fichero de configuración serverless.yml y, con un simple serverless deploy, ¡ya están en la nube! 🚀

2. Preparando Laravel para la Jungla Serverless

Primero deben entender que migrar a un entorno serverless implica que Laravel debe ponerse en "modo nómada". Esto significa adaptarlo para que sea stateless (sin estado).

¿Recuerdan que mencioné que Lambda es efímero? La forma más simple de imaginar Lambda es como conversar con alguien que tiene una memoria muy corta: cada vez que inician la conversación, tienen que volver a presentarte (por ej, los datos de sesión). ¿Le dan un cuaderno para que les anote algo y luego se lo devuelva (upload de archivos)? Olvídenlo, ni en el limbo de Inception lo encontrarán.

Por lo tanto, es necesario realizar algunos ajustes esenciales:

Logs a stderr: No tienen acceso SSH a Lambda, por lo que deben hacer que los logs se almacenen en CloudWatch.
Almacenamiento de solo lectura: El sistema de archivos en Lambda es de solo lectura, a excepción del directorio /tmp. Por lo que la subida de archivos debe ser almacenada en S3 (o similar).
Sesiones: Deben mover los datos de sesión a cookies o, mejor aún, usar DynamoDB para una solución más robusta.
Caché: Por simplicidad, optamos por DynamoDB.
Variables de entorno: Olvídense del fichero .env en producción; deberán utilizar variables definidas en el fichero de configuración serverless.yml.

El Kit de Supervivencia de Bref

Para facilitar estos ajustes, la comunidad de Bref ha creado un paquete llamado bref/laravel-bridge que automatiza la mayoría de los cambios mencionados anteriormente.

Manos a la Obra: Transformando Laravel en un Nómada Cloud

Es hora de ensuciarnos las manos.

Si quieren ir siguiendo el paso a paso, los requisitos a partir de este punto son los siguientes:

PHP (¡obviamente!)
Composer ¹
Node.js ²
serverless ³

Empecemos creando un proyecto de Laravel nuevo ⁴:

# Instalación de Laravel
laravel new laravel-above-the-clouds
cd laravel-above-the-clouds

# Creamos y migramos la base de datos (sqlite por defecto)
php artisan migrate

# Instalamos los paquetes de Node.js (Vite.js, Tailwind CSS, etc.) y compilamos los assets
npm install && npm run build

Instalamos los paquetes bref/bref y bref/laravel-bridge ⁵:

composer require bref/bref bref/laravel-bridge --update-with-dependencies

El paquete bref/laravel-bridge, como mencioné anteriormente, resuelve los ajustes necesarios para que Laravel funcione en un ambiente serverless.

Bref ya incluye un fichero de configuración serverless.yml preconfigurado que podemos utilizar como base para nuestro primer deploy:

php artisan vendor:publish --tag=serverless-config

Piensen en el fichero serverless.yml como las instrucciones de un set de LEGO para AWS: es la guía que le permite montar su aplicación de forma impecable.

Realicen el deploy del proyecto:

serverless deploy

Al finalizar, en la consola obtendrán la URL del API Gateway para acceder a su aplicación en AWS!

3. Pero, ¿qué ha pasado con mi CSS?

Lo primero que notarán es que los assets (CSS y JS) no cargan correctamente. Esto sucede porque, en un entorno serverless, no disponemos de Apache o Nginx para servir los assets estáticos; y aquí quiero hacer una breve pausa.

Llevar nuestra aplicación a un entorno serverless implica cambiar nuestro mind-set de que un único servidor es responsable de realizar todas las tareas para hacer funcionar nuestra aplicación. En un entorno serverless, cada componente debe ser gestionado por un servicio especializado.

En nuestro caso, algunos de los componentes principales en una aplicación Laravel son los siguientes:

Componente	Servidor Dedicado	AWS Serverless
Rutas, Controladores, ...	PHP-FPM	Lambda
Assets estáticos (imágenes, javascript, css)	Apache / Nginx	S3
Datos de sesión	Base de Datos / Cookies	RDS / DynamoDB
Caché	Disco local	DynamoDB / Redis
Upload de archivos	Disco local	S3
Tareas programadas (Schedule)	crontab	EventBridge
Cola de Eventos	SSH $ `php artisan queue:work` / quizás supervisor	SQS
Comandos `artisan`	SSH $ `php artisan ...`	Lambda
Log de Aplicación	SSH $ `tail -f storage/logs/*`	CloudWatch

Pero vayamos con calma, resolviendo un punto a la vez.

De la Complejidad a la Simplicidad: La Orquestación Serverless

De los puntos mencionados, el paquete bref/laravel-bridge ya resuelve el log de la aplicación y los datos de sesión. Se crea un grupo de logs en CloudWatch para los logs de aplicación, y los datos de sesión son almacenados en cookies (más adelante veremos cómo llevar los datos de sesión a DynamoDB).

Para poder servir los assets estáticos, tenemos dos alternativas:

La difícil: Agregar la creación de un Bucket S3 a nuestra configuración serverless.yml, obtener el nombre del bucket, armar la URL pública y asignarla en la variable de entorno ASSET_URL.
La simple: Utilizar el plugin serverless-lift ⁶, y dejar que la magia fluya.

Aunque aprendí mucho por el camino difícil (vengo acompañando el crecimiento de Bref desde 2020 ⁷), ustedes pueden aprovechar que la comunidad ha desarrollado herramientas que nos simplifican la vida.

Instalamos el plugin serverless-lift y agregamos una nueva sección ⁸ dentro del fichero serverless.yml:

serverless plugin install -n serverless-lift

service: laravel

- # ...

functions:
  web:
    handler: public/index.php
    runtime: php-82-fpm

- # ...

  artisan:
    handler: artisan
    runtime: php-82-console

- # ...

+ constructs:
+   website:
+     type: server-side-website
+     assets:
+       '/build/*': public/build
+       # Agreguen aquí cualquier archivo o directorio que necesite ser servido desde S3

plugins:
  - ./vendor/bref/bref
+   - serverless-lift

Dentro de la sección constructs hemos definido un componente website del tipo server-side-website. Esto le dice al plugin serverless-lift que cree una distribución de CloudFront, la cual actuará como CDN para servir los archivos estáticos desde un Bucket S3, y a su vez como proxy reverso, redirigiendo las solicitudes a las rutas de tu aplicación PHP a través de API Gateway => Lambda.

serverless deploy

Este deploy demorará unos 5-7 minutos adicionales por única vez, ya que las distribuciones de CloudFront son creadas globalmente. Los siguientes deploys serán más rápidos, siempre que no modifiquen configuraciones que afecten a la distribución de CloudFront.

En el resultado de la consola verán que ahora disponen de dos URLs, una del API Gateway (que ya no utilizaremos), y otra de CloudFront, el cual servirá los assets estáticos desde el Bucket S3, y el resto de las rutas serán procesadas por Lambda.

¡Y ahora el CSS se carga correctamente! Felicidades, han desplegado su primera aplicación Laravel en ambiente serverless.

4. Optimizando para el Mundo Real: La Batalla Contra el Cold-Start

Seguramente habrán notado que la primera vez que ingresaron a su aplicación, esta demoró unos segundos adicionales en responder.

Así como mencioné en el artículo anterior, esto es llamado cold-start y ocurre cuando Lambda inicializa una nueva instancia para ejecutar su aplicación. Esta inicialización puede llevar 250ms o más, especialmente si tu aplicación es grande.

Lambda mantiene viva una instancia hasta 10 minutos después de procesar una solicitud, luego es destruida automáticamente.

Podemos abordar esto desde varios frentes.

a) Mantener siempre viva una instancia Lambda ⁹

En aplicaciones con poco tráfico, es normal que hayan periodos mayores a 10 minutos de inactividad, por lo que podremos tener un porcentaje mayor de solicitudes procesadas en un cold-start.

Bref dispone de un evento especial que podemos utilizar para mantener viva una instancia de Lambda. Simplemente debemos agregar un evento schedule en nuestro fichero de configuración serverless.yml con el payload {warmer: true}. Bref reconocerá este evento especial y responderá instantáneamente con el código de estado 100 ¹⁰ sin ejecutar tu código, manteniendo así viva la instancia.

service: laravel

- # ...

functions:
  web:
    handler: public/index.php
    runtime: php-82-fpm
    events:
      - httpApi: '*'
+       - schedule:
+         rate: rate(5 minutes)
+         input:
+           warmer: true

b) Reducir el tamaño de su aplicación

Durante un cold-start, AWS Lambda descarga el paquete de la aplicación, lo descomprime en un entorno temporal y carga el runtime junto con todas las dependencias y configuraciones necesarias. Este proceso, aunque está optimizado, añade latencia a la primera solicitud. Por ello, reducir el tamaño del paquete (por ejemplo, eliminando dependencias de desarrollo o módulos innecesarios) puede acortar considerablemente este tiempo de inicialización.

El fichero serverless.yml por defecto de Bref ya ignora ciertos directorios que no son necesarios en PHP, como por ejemplo node_modules.

Paquetes de desarrollo

Antes de realizar el deploy, podemos desinstalar los paquetes de desarrollo. Esto reducirá en gran manera el tamaño del directorio vendor, y en consecuencia, el tamaño total del código enviado a Lambda.

composer install --no-dev

Dependencias de servicios AWS

En la mayoría de mis aplicaciones, el paquete de composer que más ocupa espacio es aws/aws-sdk-php (requerido por bref/laravel-bridge).

Lo bueno es que la comunidad ha desarrollado un script de composer para limpiar los paquetes de servicios AWS no utilizados en nuestra aplicación ¹¹. Solo debemos especificar en el fichero composer.json los servicios que sí utilizamos:

{
  "name": "laravel/laravel",
  "type": "project",
  ...
  "require": {
    "php": "^8.2",
    "bref/bref": "^2.3",
    "bref/laravel-bridge": "^2.5",
    "laravel/framework": "^11.31",
    "laravel/octane": "^2.8",
    ...
  },
  "scripts": {
+     "pre-autoload-dump": "Aws\\Script\\Composer\\Composer::removeUnusedServices",
    "post-autoload-dump": [
      "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
      "@php artisan package:discover --ansi"
    ],
    ...
  },
  "extra": {
    "laravel": {
      "dont-discover": []
    },
+     "aws/aws-sdk-php": [
+       "DynamoDb",
+       "S3",
+       "Sqs"
+     ]
  },
}

El script de limpieza correrá cada vez que ejecutemos composer install o composer update.

c) Impulsando el Rendimiento con Laravel Octane

Incluso cuando se producen cold-starts, Laravel Octane entra en acción para mantener la aplicación en memoria y reducir significativamente los tiempos de respuesta. Al evitar un arranque completo de Laravel en cada solicitud, se mejora notablemente la experiencia del usuario final.

Laravel Octane actúa como un acelerador que "mantiene caliente" la aplicación. Una vez que Lambda inicia la aplicación, Octane se encarga de conservarla en memoria, de modo que las siguientes solicitudes se atiendan casi de inmediato. Es como encender el motor de un coche y dejarlo listo para arrancar en cualquier momento, en lugar de encenderlo desde cero cada vez.

Pasos para implementar Laravel Octane:

composer require laravel/octane
php artisan octane:install

Una vez instalado, actualicen el fichero serverless.yml para utilizar Laravel Octane como handler ¹². Esto asegurará que tu aplicación se ejecute con el rendimiento mejorado que ofrece Laravel Octane:

service: laravel

- # ...

functions:
  web:
    handler: Bref\LaravelBridge\Http\OctaneHandler
    runtime: php-82
- # ...

Finalmente, desplieguen su aplicación con los cambios realizados:

serverless deploy

d) Métricas que Validan el Progreso

Aplicando todas las mejoras mencionadas, hemos reducido el tiempo de inicialización (cold-start) de nuestra aplicación. Y con Laravel Octane, no solo hemos mejorado el tiempo del cold-start, sino que mejoramos el tiempo de respuesta general de nuestra aplicación.

Podemos visualizar los tiempos de respuesta en los logs de CloudWatch que ya se configuraron automáticamente por nosotros.

Cold-start sin optimizaciones (499ms):

Cold-start con Laravel Octane y optimizaciones (190ms):

Tengan en cuenta que al utilizar Laravel Octane, se mantiene la ejecución de Laravel en memoria, por lo que deben cuidarse de los memory leaks ¹³.

5. Caídas y Aprendizajes: Los Errores que Todo Migrante Serverless Debe Conocer

Seguramente se dieron cuenta que hay una función llamada artisan en el fichero serverless.yml. Esa función utiliza la versión "consola" del runtime de Bref ¹⁴, la cual nos permite ejecutar comandos de Laravel Artisan en AWS Lambda.

Como no tenemos acceso SSH a las instancias de Lambda, Bref nos disponibiliza un puente para poder ejecutar comandos cli mediante el comando bref:cli de serverless.

serverless bref:cli --args="<comando artisan y sus opciones>"
serverless bref:cli --args="route:list"

Optimizaciones

Un punto muy importante que quiero reforzar es que debemos cambiar nuestra mentalidad al desarrollar aplicaciones para entornos serverless. En este nuevo paradigma, es crucial diseñar nuestros procesos y flujos de trabajo considerando las características únicas de la computación serverless, como la naturaleza efímera de las funciones y el modelo de facturación basado en el uso.

Serverless no es caro... pero el código mal adaptado sí lo es.

En mi primer mes migrando una de mis aplicaciones al entorno serverless, cometí el error de no revisar detalladamente ciertos procesos. Uno de ellos se encargaba de sincronizar los productos de la tienda en línea con un sistema de facturación externo, incluyendo la actualización de imágenes de productos. Y como mencioné en el artículo anterior, algunos procesos no son ideales para ejecutarse en un entorno serverless. En este caso, estaba pagando por tiempo muerto, durante la descarga de imágenes, mi código en Lambda no estaba realizando nada más que esperar 5-8 segundos por imágen. Con 65,000 artículos en la tienda y dos sincronizaciones diarias, esto resultó en una factura de ~$530 solo por el tiempo inactivo durante la descarga de imágenes.

Este incidente me llevó a rediseñar el proceso de sincronización. En un primer intento de optimización, implementé la descarga de múltiples imágenes en paralelo utilizando PHP ZTS, lo que me llevó a desarrollar la librería hds-solutions/parallel-sdk ¹⁵. Esta versión redujo los costos a ~160$, pero aún no era suficiente; mi objetivo era que los costos estuvieran por debajo de lo que gastaba originalmente en EC2.

En un segundo intento, trasladé el proceso de descarga de imágenes a una instancia EC2 dedicada. Aunque esto redujo significativamente los costos a ~50$, la aplicación quedó dividida en dos componentes separados.

Finalmente, en la tercera versión del proceso de sincronización, tras conversar con el cliente, implementé un pequeño script en el servidor del sistema de facturación. En lugar de que mi aplicación descargara las imágenes, este script enviaba las imágenes directamente desde el servidor del sistema de facturación a S3 utilizando URLs pre-firmadas ¹⁶. Esto eliminó por completo los costos asociados a la descarga de imágenes, quedando únicamente el costo de almacenamiento en S3.

6. ¿Qué Sigue?

¡Con esto, cerramos otro capítulo en nuestro viaje hacia el mundo serverless! Hoy vimos cómo transformar a Laravel en un auténtico nómada en la nube, adaptándolo para vivir sin el peso de un servidor tradicional. Pero esto es solo el comienzo.

En el próximo artículo nos adentraremos en el corazón de la integración: veremos cómo trasladar los datos de sesión y caché a DynamoDB, cómo aprovechar S3 para el manejo de archivos, configurar SQS para gestionar colas y utilizar EventBridge para orquestar tareas programadas. ¡Nos vemos en la siguiente entrega!

Mientras tanto, ¿han migrado su aplicación Laravel a serverless? ¡Compartan sus experiencias en los comentarios! Y para los que aún no lo han hecho, les animo a experimentar con lo que hemos implementado hasta ahora y a compartir sus dudas y experiencias.

Por qué Migré Mi Aplicación Laravel a AWS Serverless (Y Por Qué Podría Ahorrarte Tiempo y Dinero)

Hermann D. Schimpf — Wed, 29 Jan 2025 00:01:51 +0000

English version here.

Spoiler: No se trata solo de ahorrar dinero—aunque mi billetera no se queja.

Imagina esto: has creado una brillante aplicación en Laravel—tu obra maestra, una navaja suiza digital con funciones tan útiles que podrían cortar mantequilla... o los comentarios de los usuarios. Pero hay un detalle. Cada mes estás pagando por una instancia EC2 que está tan infrautilizada como una membresía de gimnasio después de enero. Mientras tanto, escalar se siente como intentar aparcar un crucero en medio de un huracán.

¿Te ha pasado? A mí también.

Hace tres años, hice algo que la mayoría de los desarrolladores llamarían una locura: desplegué PHP en AWS Lambda. “¿PHP? ¿En serverless? ¡Eso es como poner piña en la pizza!”, decían.

Pero aquí estoy, tres años después, comiendo mi pizza con piña con orgullo. Déjame contarte por qué Laravel en serverless es la actualización en la nube que no sabías que necesitabas.

1. El Problema del Hosting Tradicional con Laravel

(ó: Por qué mis instancias EC2 estaban teniendo una crisis existencial)

Antes de serverless, mi aplicación Laravel vivía en EC2. Para los no iniciados, EC2 es la versión de Amazon de un servidor privado virtual, donde alquilas una parte de una máquina para ejecutar tu código. Suena bien, ¿verdad? Hasta que la realidad te golpea más fuerte que un composer update rebelde.

a) Primero está: El Costo de Existir

Ejecutar una instancia EC2 es como tener un Tesla que dejas encendido las 24 horas del día, solo por si acaso quieres conducir. Mi aplicación no siempre estaba ocupada, pero eso no detenía el contador. Entre instancias EC2, balanceadores de carga y almacenamiento compartido, gastaba alrededor de $110/mes en un stack de servidores que pasaba la mayor parte del tiempo inactivo. ¿Mi billetera? Hundida como el Titanic.

Lo sé, no es mucho en el gran esquema de las cosas, pero como desarrollador/emprendedor en solitario, cada dólar cuenta.

b) Después: Las Pesadillas de Escalado

Las instancias EC2 son como ese amigo que reacciona de forma exagerada a todo.

¿Pico de tráfico? "¡Me voy a caer ahora, gracias!"
¿No hay tráfico? "¡Igual seguiré quemando tu dinero!"

Gestionar el autoescalado se sentía como enseñar a un pez a hacer malabares—es posible, pero ¿a qué costo? Ajustar manualmente los grupos de escalado, configurar balanceadores de carga y rezar para no provisionar de más se sentía como un segundo trabajo al que nunca me postulé.

c) Y finalmente: DevOps, el Interno No Pagado

Nadie me dijo que el desarrollo con Laravel venía con un lado de responsabilidades de sysadmin:

Aplicar parches de seguridad.
Depurar configuraciones de nginx/apache a las 3 AM.
Susurrar palabras bonitas a los comandos sudo, esperando que funcionaran esta vez.

No me inscribí para esta vida.

Fue entonces cuando comencé a explorar alternativas, y serverless se destacó como la solución perfecta para resolver estos dolores de cabeza.

2. AWS Serverless: El Resurgimiento de PHP en la Nube

Aclaremos un mito: serverless no significa "sin servidores". Solo significa que los servidores son el problema de otra persona. En este caso, AWS hace el trabajo pesado mientras yo me concentro en lo que realmente disfruto: programar.

a) Lambda: El Mago Impulsado por Eventos

AWS Lambda es como un superhéroe que solo aparece cuando lo necesitas. Ejecuta tu código en respuesta a eventos—solicitudes HTTP, mensajes de SQS, tareas programadas, tu nómbralo. Y cuando el trabajo termina, desaparece más rápido que una pizza gratis en una reunión de desarrolladores.

Sin costos inactivos: Solo pagas por el tiempo de ejecución (medido en milisegundos).
Magia de escalado automático: ¿Recibiste un pico de 100,000 solicitudes? Lambda las maneja sin sudar (ni vaciar tu cuenta bancaria).
Stateless por diseño: Es como un borrón y cuenta nueva cada vez, un diseño que te obliga a pensar de forma modular.

b) Servicios Administrados: Los Héroes Anónimos

Serverless no es solo Lambda—es un ecosistema. AWS reemplaza tu infraestructura DIY (hazlo tú mismo) con servicios administrados que "simplemente funcionan":

Base de datos: Opciones como Aurora Serverless (MySQL/Postgres) para los amantes de SQL.
S3: Almacena tus archivos sin preocuparte por quedarte sin espacio en disco.
SQS: Desacopla trabajos de larga duración y procésalos de forma asíncrona.

c) La Paradoja de PHP

Debo admitirlo: PHP no nació para serverless. Es como pedirle a un pez que trepe un árbol—se quejará, pero eventualmente lo hará. Laravel, tradicionalmente dependiente de PHP-FPM, necesitó algunos ajustes para prosperar en el mundo efímero de Lambda:

Sesiones: Muévelas a una base de datos externa, como MySQL o Redis.
Almacenamiento de archivos: Redirige todas las operaciones de almacenamiento a S3, usando el facade Storage de Laravel.
Gestión de colas: Configura SQS como el controlador predeterminado para la ejecución de tareas asíncronas.
Caching: Aprovecha servicios externos como Redis o DynamoDB en lugar de almacenamiento local.
Optimización del tiempo de arranque: Minimiza los inicios en frío (cold starts) recortando lo innecesario (dependencias no utilizadas).
Variables de entorno: Reemplaza los archivos .env con AWS Secrets Manager o Parameter Store para una gestión centralizada y segura de la configuración.

Recuerda que serverless no se trata solo de reemplazar servidores por funciones Lambda. Se trata de repensar tu arquitectura—dejando que AWS maneje los puntos de dolor operativos mientras tú te concentras en construir.

3. Cómo Serverless Desbloquea Todo el Potencial de Laravel

Entonces, ¿Laravel en serverless realmente cumple sus promesas?

Serverless no es solo una palabra de moda, es un cambio transformador. La belleza de Laravel en serverless radica en su capacidad para resolver los puntos débiles del alojamiento tradicional, al mismo tiempo que permite soluciones más rápidas, escalables y rentables. Pero la verdadera magia ocurre cuando profundizas en cómo se combinan estos beneficios. Vamos a desglosarlo.

a) Cold Starts: Separando el Mito de la Realidad

Los cold starts ocurren cuando Lambda inicializa una nueva instancia. Piensa en ello como si PHP despertara de una siesta. Los críticos los tratan como si fueran el apocalipsis, pero son manejables:

Realidad: Los cold starts típicos con PHP + Laravel rondan los ~3-5 segundos.
Soluciones:
- Laravel Octane: Mantiene la aplicación viva entre solicitudes, reduciendo los tiempos de inicio. Las solicitudes posteriores se procesan en ~200ms o menos.
- Concurrencia aprovisionada: AWS pre-calienta instancias para endpoints críticos (cuesta extra, pero vale la pena para puntos clave).

Para la mayoría de las aplicaciones, los retrasos menores a 3 segundos durante el tráfico bajo son aceptables. La mayoría de los usuarios no notará un cold start, especialmente durante cargas máximas de tráfico cuando Lambda permanece "caliente".

b) Escalado Sin Dolor

El escalado en el hosting tradicional suele parecer una batalla interminable. Con serverless, el escalado se vuelve muy sencillo: ya no es necesario ajustar las reglas de autoescalado ni cruzar los dedos durante un aumento repentino de tráfico. AWS Lambda elimina las conjeturas, escalando horizontalmente por defecto.

Aquí va un ejemplo:

Escenario: Tu aplicación se vuelve viral 🚀 yey!
Antigüa configuración con EC2: Comienza a experimentar latencia, corres a iniciar sesión en AWS, ajustas manualmente la cantidad de instancias, y rezas por lo mejor 🫠. Ah, y no olvides equilibrar correctamente esas instancias entre las zonas de disponibilidad.
Nueva configuración con Lambda: AWS crea automáticamente tantas instancias como sea necesario, manejando miles de solicitudes concurrentes sin que levantes un dedo. Agarras unas palomitas de maíz y observas las métricas de CloudWatch como si fuera una serie de Netflix 🍿.

Esto no es solo comodidad, es tranquilidad. Mientras tú te concentras en celebrar el éxito de tu aplicación, Lambda hace el trabajo pesado. ¿Y lo mejor? Solo pagas por el tiempo de computación que usas, no por la capacidad inactiva que podrías necesitar "por si acaso".

c) Eficiencia de Costos: El Jugador Más Valioso

Serverless no solo ahorra dinero, es como tener un buffet de $5 donde solo pagas por lo que comes.

Mi antigua configuración con EC2: ~$110/mes.
- 4x instancias EC2 t3.small: $60.00
- 1x Balanceador de Carga: $16.40
- 1x EBS (almacenamiento compartido entre instancias EC2): $7.80
- 1x instancia RDS MySQL (db.t4g.medium): ~26.00
Lambda: ~$34/mes (¡un ahorro del 60%!).
- Lambda, API Gateway ~2.5M solicitudes (~500ms / 512MB de memoria) /mes: $4.80
- Servicios gestionados (S3, SQS, CloudWatch): ~$2.90
- Instancia RDS MySQL (db.t4g.medium): ~26.00

Recurso	Costo EC2	Costo Lambda
Computación	$60.00	$4.50
Red (LB, API Gateway)	$16.40	$0.30
Almacenamiento	$7.80	$2.90
Base de datos	$26.00	$26.00
TOTAL	$110.20	$33.70

En resumen, serverless no solo ahorra dinero, libera ancho de banda mental. Cuantos menos recursos desperdicie preocupándome por el sobreaprovisionamiento, más puedo concentrarme en construir algo increíble.

Hasta ese momento, todavía utilizaba una instancia MySQL como motor de base de datos. Publicaciones posteriores explorarán cómo migrar a DynamoDB para reducir aún más los costos.

d) Libertad de Mantenimiento: Di Adiós a las Pesadillas Operativas

Serverless me liberó de las cadenas del mantenimiento de servidores. Aquí está cómo:

No más actualizaciones manuales: AWS maneja parches de seguridad, actualizaciones del sistema operativo y mejoras de tiempo de ejecución, lo que significa que siempre estás utilizando una infraestructura segura y actualizada.
Configuraciones simplificadas: Con servicios como API Gateway y S3, la complejidad de gestionar configuraciones nginx y despliegues personalizados se convierte en cosa del pasado.
Capacidad elástica: Olvídate de pagar de más por recursos de servidor no utilizados o de apresurarte a provisionar más durante picos de tráfico. Lambda escala automáticamente para satisfacer la demanda y deja de facturar cuando está inactivo.
Enfócate en las características, no en apagar incendios: El tiempo que antes dedicaba a aplicar parches o a depurar problemas en producción ahora lo invierto en crear características y mejorar la experiencia del usuario.

Serverless no solo reduce el mantenimiento, elimina las distracciones operativas que te impiden programar.

4. Pero, ¿Es Laravel Serverless para Todos?

Por muy revolucionario que sea Laravel en serverless, no es una solución universal. Para algunas aplicaciones, la naturaleza stateless y orientada a eventos de serverless puede parecer un sueño hecho realidad. Para otras, puede parecer como tratar de encajar un cuadrado en un círculo. Antes de subirte al tren de serverless, retrocedamos un poco y evaluemos si es adecuado para tu proyecto.

a) La Naturaleza Stateless: Una Espada de Doble Filo

Laravel adora las operaciones que guardan información entre interacciones, como almacenar archivos localmente y guardar sesiones en el sistema de archivos. Para pasar a serverless, debes cambiar:

Sesiones: Usa bases de datos (MySQL/Postgres) o Redis; nada más de depender del sistema de archivos.
Archivos: Redirige las subidas de archivos a S3, o evita completamente pasar por Laravel y utiliza URL pre-firmadas de S3.
Logs: Configura Laravel para transmitirlos a CloudWatch.
Configuración: Mueve las variables .env a AWS Secrets Manager o Parameter Store para una gestión centralizada.
Colas: Migra los trabajos a AWS SQS para manejar colas y mensajes de manera escalable.

b) Consideraciones Sobre la Dependencia del Proveedor (Vendor Lock-In)

Los servicios de AWS son mágicos, pero también son propietarios:

¿Migrar de SQS a colas Redis? Prepárate para reescribir código.
¿Quieres pasar de Lambda a Docker? Tómate un café: será una noche larga.

c) Cuándo No Optar por Serverless

Serverless no es una bala de plata para todas las cargas de trabajo. Debes evitarlo si:

Necesitas WebSockets: Aunque se puede lograr con servicios como API Gateway + WebSocket APIs o herramientas de terceros como Ably, añade complejidad.
Tu aplicación tiene cargas computacionales pesadas: Tareas como inferencia de IA/ML o codificación de video pueden alcanzar el límite de tiempo de 15 minutos de Lambda.
Dependes de servicios con estado: Las aplicaciones que asumen un disco persistente o un estado del servidor pueden ser costosas de refactorizar.

5. ¿Qué Sigue?

Laravel en serverless tiene el potencial de transformar la forma en que construyes y despliegas aplicaciones, pero la verdadera magia está en la implementación. ¿Estás listo para dar el salto y darle a tu aplicación Laravel el tratamiento serverless? Mantente atento a la Parte 2, donde te guiaré a través de los pasos exactos para llevar esta arquitectura a la vida.

Una pregunta para ti: ¿Cuál es tu mayor temor con serverless? ¡Compártelo abajo y abordaré los 3 principales en la Parte 2!

Why I Migrated My Laravel App to AWS Serverless (And Why It Could Save You Time and Money)

Hermann D. Schimpf — Tue, 28 Jan 2025 03:03:21 +0000

Versión en español aquí.

Spoiler: It’s not just about saving money—though my wallet isn’t complaining.

Picture this: you've built a shiny Laravel app—your magnum opus, a digital Swiss Army knife with features so sharp they could cut through butter... or user feedback. But there's a catch. Every month, you're stuck paying for an EC2 instance that’s as underutilized as a gym membership after January. Meanwhile, scaling feels like trying to parallel park a cruise ship during a hurricane.

Been there? I have too.

Three years ago, I did something that most developers would call madness: I deployed PHP on AWS Lambda. "PHP? On serverless? That's like putting pineapple on pizza!" they said.

But here I am, three years later, eating my pineapple pizza with pride. Let me tell you why serverless Laravel is the cloud upgrade you didn't know you needed.

1. The Problem with Traditional Laravel Hosting

(or: Why my EC2 instances were having an existential crisis)

Before serverless, my Laravel app lived on EC2. For the uninitiated, EC2 is Amazon’s version of a virtual private server, where you rent a slice of a machine to run your code. Sounds nice, right? Until reality hits you harder than a rogue composer update.

a) First there is: The Cost of Breathing

Running an EC2 instance is like owning a Tesla you keep running 24/7, just in case you feel like driving. My app wasn’t always busy, but that didn’t stop the meter from ticking. Between EC2 instances, load balancers, and shared storage, I was shelling out around $110/month for a server stack that spent most of its time idling. My wallet? Doing a Titanic impression.

I know, it’s not much in the grand scheme of things, but as a solo developer/entrepreneur, every dollar counts.

b) Then is: The Scaling Nightmares

EC2 instances are like that one friend who overreacts to everything.

Traffic spike? "I'll crash now, thanks!"
Traffic hush? "I’ll keep burning your money anyway!"

Managing autoscaling felt like teaching a fish to juggle—it's possible, but at what cost? Manually tweaking scaling groups, configuring load balancers, and praying I didn’t overprovision felt like a second job I never applied for.

c) And lastly DevOps: The Unpaid Intern

Nobody told me Laravel development came with a side of sysadmin responsibilities:

Applying security patches.
Debugging nginx/apache configs at 3 AM.
Whispering sweet nothings to sudo commands, hoping they’d work this time.

I didn't sign up for this life.

That’s when I started exploring alternatives, and serverless stood out as the perfect fit for solving these headaches.

2. AWS Serverless: PHP’s Cloud Glow-Up

Let’s clear up a myth: serverless doesn't mean "no servers". It just means the servers are someone else's problem. In this case, AWS does the heavy lifting while I focus on what I actually enjoy—coding.

a) Lambda: The Event-Driven Wizard

AWS Lambda is like a superhero that only shows up when you need it. It executes your code in response to events—HTTP requests, SQS messages, cron jobs, you name it. And when the job's done, it disappears faster than a free pizza at a dev meetup.

No idle costs: Pay only for execution time (measured in milliseconds).
Auto-scaling magic: Got a 100,000 requests spike? Lambda handles them without breaking a sweat (or your bank account).
Stateless by design: It's like a clean slate every time—a design that forces you to think modularly.

b) Managed Services: The Unsung Heroes

Serverless isn't just Lambda—it's an ecosystem. AWS replaces your DIY infrastructure with managed services that "just work":

Database: Serverless-friendly options like Aurora Serverless (MySQL/Postgres) for SQL lovers.
S3: Store your files without worrying about running out of disk space.
SQS: Decouple long-running jobs and process them asynchronously.

c) The PHP Paradox

I have to admit it: PHP wasn't born for serverless. It's like asking a fish to climb a tree—it'll complain, but it'll eventually get there. Laravel, traditionally reliant on PHP-FPM, needed some love to thrive in Lambda's ephemeral world:

Sessions: Move them to an external database, like MySQL or Redis.
File storage: Reroute all storage operations to S3, using Laravel’s Storage facade.
Queue handling: Set up SQS as the default queue driver for async task execution.
Caching: Leverage external services like Redis or DynamoDB instead of local storage.
Boot time optimization: Minimize cold starts by trimming fat (unused dependencies).
Environment variables: Replace .env files with AWS Secrets Manager or Parameter Store for secure and centralized configuration management.

Keep in mind that serverless isn't just about swapping out servers for Lambda functions. It’s about rethinking your architecture—letting AWS handle the operational pain points while you focus on building.

3. How Serverless Unlocks Laravel’s Full Potential

So, does serverless Laravel actually deliver on its promises?

Serverless isn't just a buzzword—it's a game-changer. The beauty of serverless Laravel lies in its ability to solve the pain points of traditional hosting while enabling faster, more scalable, and cost-effective solutions. But the real magic happens when you dive into how these benefits come together. Let’s break it down.

a) Cold Starts: Separating Fact from Fiction

Cold starts occur when Lambda initializes a new instance. Think of it as PHP waking up from a nap. Critics treat them like the apocalypse, but they’re manageable:

Reality: Typical cold starts with PHP + Laravel are ~3-5 seconds.
Solutions:
- Laravel Octane: Keeps the app alive between requests, reducing boot times. The subsequent requests are processed in ~200ms or less.
- Provisioned Concurrency: AWS pre-warms instances for critical endpoints (costs extra, but worth it for critical endpoints).

For most apps, sub-3s delays during low traffic are acceptable. Most users won't notice a cold start, especially during peak traffic loads when Lambda stays warm.

b) Scaling Without Tears

Scaling in traditional hosting often feels like fighting a never-ending battle. With serverless, scaling becomes effortless—no more tweaking auto-scaling rules or crossing your fingers during a traffic surge. AWS Lambda eliminates the guesswork, scaling horizontally by default.

Here's an example:

Scenario: Your app goes viral 🚀 yey!.
Old EC2 Setup: It starts getting latency, you scramble to log into AWS, manually adjust instance counts, and hope for the best 🫠. Oh, and don't forget to balance those instances properly across availability zones.
New Lambda Setup: AWS automatically spins up as many instances as needed, handling thousands of concurrent requests without you lifting a finger. You grab popcorn and watch CloudWatch metrics like it’s a Netflix series 🍿.

This isn’t just convenience—it’s peace of mind. While you focus on celebrating your app's success, Lambda does the heavy lifting. And the best part? You’re billed only for the compute time you use, not for the idle capacity you might need "just in case".

c) Cost Efficiency: The Real MVP

Serverless doesn't just save money—it’s like having a $5 buffet where you only pay for what you eat.

My old EC2 setup: ~$110 /month.
- 4x EC2 t3.small instances: $60.00
- 1x Load Balancer: $16.40
- 1x EBS (shared storage between EC2 instances): $7.80
- 1x RDS MySQL instance (db.t4g.medium): ~26.00
Lambda: ~$34 /month (a 60% saving!).
- Lambda, API Gateway ~2.5M requests (~500ms / 512MB memory) /month: $4.80
- Managed services (S3, SQS, CloudWatch): ~$2.90
- RDS MySQL instance (db.t4g.medium): ~26.00

Resource	EC2 Cost	Lambda Cost
Compute	$60.00	$4.50
Networking (LB, API Gateway)	$16.40	$0.30
Storage	$7.80	$2.90
Database	$26.00	$26.00
TOTAL	$110.20	$33.70

In short, serverless doesn’t just save money—it frees up mental bandwidth. The fewer resources I waste worrying about over-provisioning, the more I can focus on building something amazing.

At that time, I was still using a MySQL instance as database engine. Later posts will explore migrating the database engine to DynamoDB to cut costs further.

d) Maintenance Freedom: Say Goodbye to Ops Nightmares

Serverless freed me from the shackles of server maintenance. Here’s how:

No more manual updates: AWS handles server patching, operating system updates, and runtime upgrades, meaning you’re always running on secure, up-to-date infrastructure.
Simplified configurations: With services like API Gateway and S3, the complexity of managing nginx configs and custom deployments becomes a thing of the past.
Elastic capacity: Forget overpaying for unused server resources or scrambling to provision more during traffic spikes. Lambda automatically scales to meet demand and stops billing when idle.
Focus on features, not firefighting: The time I once spent applying patches or debugging production issues now goes into building features and improving user experience.

Serverless doesn't just reduce maintenance; it removes the operational distractions that keep you from coding.

4. But, "Is Serverless Laravel for Everyone?"

As revolutionary as serverless Laravel is, it's not a one-size-fits-all solution. For some apps, the stateless, event-driven nature of serverless can feel like a dream come true. For others, it might feel like trying to fit a square peg into a round hole. Before you jump on the serverless bandwagon, let’s take a step back and evaluate whether it’s the right fit for your project.

a) Statelessness: The Double-Edged Sword

Laravel loves stateful operations like storing files locally and caching sessions in the filesystem. To go serverless you must change:

Sessions: Use databases (MySQL/Postgres), or Redis—no more filesystem reliance.
Files: Reroute uploads to S3, or bypass Laravel entirely via pre-signed S3 URLs.
Logs: Configure Laravel to stream them to CloudWatch.
Configuration: Move .env variables to AWS Secrets Manager or Parameter Store for centralized management.
Queues: Migrate jobs to AWS SQS for scalable queueing and message handling.

b) Vendor Lock-In Considerations

AWS services are magical, but they’re also proprietary:

Migrating from SQS to Redis queues? Have fun rewriting code.
Want to move from Lambda to Docker? Grab a coffee—it’ll be a long night.

c) When Not to Go Serverless

Serverless isn’t a silver bullet for every workload, you should consider avoiding it if:

You need WebSockets: While achievable with services like API Gateway + WebSocket APIs or third-party tools like Ably, it adds complexity.
Your app has heavy computational workloads: Tasks like AI/ML inference or video encoding may hit Lambda’s 15-minute timeout.
You rely on stateful services: Applications that assume a persistent disk or server state can be costly to refactor.

5. What’s Next?

Serverless Laravel has the potential to transform the way you build and deploy applications, but the real magic is in the implementation. Are you ready to make the leap and give your Laravel app the serverless treatment? Stay tuned for Part 2, where I'll walk you through the exact steps to bring this architecture to life.

Question for you: What’s your biggest serverless fear? Share below—I’ll tackle the top 3 in Part 2!

DEV Community: Hermann D. Schimpf

What Replaced queue:work in My Laravel App (And Why I Stopped Praying to Supervisor at 3 AM)

1. The Serverless Treasure Map

2. Why queue:work Doesn't Fit in Serverless

a) How queues work on a traditional server

b) Why that doesn't exist in Lambda

c) Flipping the model: from pull to push

3. The New Queue Stack: SQS as the Mailbox, Lambda as the Worker

a) SQS in 30 seconds for Laravel devs

b) Wiring it up with Serverless Lift

c) New infrastructure, same old code

4. What Actually Happens When You Dispatch a Job?

a) Laravel dispatches, SQS receives

b) SQS notifies, Lambda wakes up

c) Bref receives the batch, Laravel runs the job

d) Lambda's timeout vs. the job's $timeout

5. Who Takes Over When Something Blows Up?

a) Retries are handled by Laravel, not SQS

b) The side effect: SQS never finds out about the failure

c) First layer: when the job exhausts its attempts in Laravel

d) Second layer: when the infrastructure fails

e) The two layers, side by side

6. Tuning the Worker Knobs for Production

a) timeout: the ceiling for the longest job

b) batchSize: fewer invocations, more responsibility

c) reservedConcurrency vs maxConcurrency

d) memorySize: more memory is also more CPU

e) Tailored layers: extensions only where needed

f) Does the worker need a warmer?

7. What Tutorials Don't Tell You (and You Find Out in Production)

a) SerializesModels and DynamoDB composite keys

b) Bus::batch() also needs somewhere to store its progress

c) Your local environment doesn't need to touch AWS

d) The limit is 1 MiB per message

e) The AWS SDK cleanup from the second chapter

8. Costs: The Worker That Only Charges When It Works

9. What's Next?

Qué Reemplazó a queue:work en Mi Aplicación Laravel (Y Por Qué Dejé de Rezarle a Supervisor a las 3 AM)

1. El Mapa del Tesoro Serverless

2. Por Qué queue:work No Encaja en Serverless

a) Cómo funciona la cola en un servidor tradicional

b) Por qué eso no existe en Lambda

c) La inversión del modelo: de pull a push

3. El Nuevo Stack de Colas: SQS como Buzón, Lambda como Worker

a) SQS en 30 segundos para devs Laravel

b) Conectando los cables con Serverless Lift

c) Nueva infraestructura, el mismo código de siempre

4. ¿Qué Pasa Realmente Cuando Despachan un Job?

a) Laravel despacha, SQS recibe

b) SQS avisa, Lambda despierta

c) Bref recibe el lote, Laravel ejecuta el job

d) El timeout de Lambda vs. el $timeout del job

5. ¿Quién Se Hace Cargo Cuando Algo Explota?

a) Los reintentos los maneja Laravel, no SQS

b) El efecto secundario: SQS nunca se entera del fallo

c) Primera capa: cuando el job agota sus intentos en Laravel

d) Segunda capa: cuando falla la infraestructura

e) Las dos capas, lado a lado

6. Ajustando las Perillas del Worker para Producción

a) timeout: el techo del job más largo

b) batchSize: menos invocaciones, más responsabilidad

c) reservedConcurrency vs maxConcurrency

d) memorySize: más memoria también es más CPU

e) Layers a medida: extensiones solo donde hacen falta

f) ¿Hace falta un warmer en el worker?

7. Lo que No Te Cuentan los Tutoriales (y Descubres en Producción)

a) SerializesModels y las claves compuestas de DynamoDB

b) Bus::batch() también necesita dónde guardar su progreso

c) El entorno local no necesita tocar AWS

d) El límite es de 1 MiB por mensaje

e) La limpieza del SDK de AWS del segundo capítulo

8. Costos: El Worker que Solo Cobra Cuando Trabaja

9. ¿Qué Sigue?

Where Does My Laravel App's Data Live in an Ephemeral Environment (Where Not Even the Disk Can Save You)

1. The Serverless Treasure Map

2. Uploads to S3: The Short Part

a) The same old facade, a different destination

b) Pre-signed URLs: so uploads don't even go through Lambda

3. DynamoDB, Easy Mode: Cache and Sessions

a) Cache: the table that cleans itself

2. Why `queue:work` Doesn't Fit in Serverless

d) Lambda's `timeout` vs. the job's `$timeout`

a) `timeout`: the ceiling for the longest job

b) `batchSize`: fewer invocations, more responsibility

c) `reservedConcurrency` vs `maxConcurrency`

d) `memorySize`: more memory is also more CPU

a) `SerializesModels` and DynamoDB composite keys

b) `Bus::batch()` also needs somewhere to store its progress

2. Por Qué `queue:work` No Encaja en Serverless

d) El `timeout` de Lambda vs. el `$timeout` del job

a) `timeout`: el techo del job más largo

b) `batchSize`: menos invocaciones, más responsabilidad

c) `reservedConcurrency` vs `maxConcurrency`

d) `memorySize`: más memoria también es más CPU

a) `SerializesModels` y las claves compuestas de DynamoDB

b) `Bus::batch()` también necesita dónde guardar su progreso

1. El Ataque: Cuando `composer update` Se Vuelve Rebelde

c) Separa Archivos `.env`

1. The Attack: When `composer update` Goes Rogue

c) Separate `.env` Files