Weave Code
Symfony Bridge Laravel Package
bref/symfony-bridge
Bref runtime bridge for running Symfony on AWS Lambda. Install with Composer, extend BrefKernel in your Kernel, and deploy with a warm cache to reduce cold-start time. Avoid filesystem writes in production.
Bref runtime to run Symfony on AWS Lambda
Frequently asked questions about Symfony Bridge
- What is bref/symfony-bridge and what problem does it solve?
- bref/symfony-bridge is a thin glue layer between Symfony's Kernel and Bref's AWS Lambda runtimes. It provides a BrefKernel base class that adapts cache-directory handling to Lambda's ephemeral filesystem, a Symfony Runtime adapter so Lambda can invoke App\Kernel directly without public/index.php and PHP-FPM, and a bundle that wires Bref's Monolog CloudWatch formatter for request-ID-prefixed logs. It is the officially maintained Symfony on-ramp to Bref v3 rather than a standalone platform.
- How do I install bref/symfony-bridge?
- Install it with Composer using composer req bref/symfony-bridge. Then make one small change in src/Kernel.php: import Bref\SymfonyBridge\BrefKernel and extend it instead of Symfony\Component\HttpKernel\Kernel. After that your Symfony app can be invoked by Bref's Lambda runtime, and you deploy using your normal Bref or Serverless setup.
- Do I have to rewrite my Kernel to use BrefKernel?
- No. The documented migration is a single extends change: swap the base Kernel for BrefKernel while keeping MicroKernelTrait and the rest of your configuration intact. The bridge is a few hundred lines and does not require restructuring your application code. The real work is operational, not code: auditing filesystem assumptions and building a deploy pipeline that ships a warm cache.
- Which Symfony and PHP versions does bref/symfony-bridge support?
- The bridge targets modern Symfony applications, with Symfony 5.2 and newer cited as the baseline for the Bref v3 setup, and it assumes PHP 8 era runtimes. Because compatibility can change between releases, check the exact composer.json constraints on Packagist before upgrading a major version. Major Bref upgrades, such as the move to Bref v3, are the events most likely to require changes on your side rather than the bridge itself.
- How do I reduce Symfony cold-start time on AWS Lambda with Bref?
- Deploy with a warm cache so the first request after a deploy does not have to compile the Symfony container. A typical build step runs composer install --classmap-authoritative --no-dev --no-scripts, then bin/console cache:clear --env=prod, then writes an empty .env.local.php to disable the Dotenv component, and finally deploys. This removes the deploy-triggered cold request, but it does not prevent the 1 to 20 second container compilation that happens whenever AWS spins up a fresh Lambda during scale-out or a mid-day recycle.
- Why should I avoid filesystem writes on Lambda, and what is getWritableCacheDirectories()?
- Lambda's filesystem is ephemeral and largely read-only, so Symfony's default behaviour of writing compiled container and cache artefacts at runtime is unreliable and slow. BrefKernel overrides cache-directory handling, and getWritableCacheDirectories() lets you declare which cache directories must be writable in the Lambda environment. You should also avoid filesystem cache pools such as cache.system and prefer pre-warmed or external caches in production.
- Can I run Symfony Messenger consumers or console commands as Lambda functions with this bridge?
- Yes. The bridge's class-handler support lets you register a public service and point serverless.yml at its fully qualified class name, instead of writing a separate bootstrap script for every Lambda function. This is especially useful for event-driven workers where Symfony Messenger is already your queue abstraction, because adding a new consumer becomes a service registration plus a configuration entry rather than new infrastructure code. Remember that Lambda invocations do not share memory, so each function runs its own container and process lifecycle.
- What changed in bref/symfony-bridge 3.0.3 for uploaded files and /tmp?
- Version 3.0.3 adds a small but important behaviour: per-request uploaded files left in /tmp are now deleted at the start of the next request. Before this release, a Symfony app running on the Bref function runtime never cleaned up uploaded request files, so they accumulated in the invocation environment's /tmp until it filled. Because /tmp persists across requests in the same Lambda environment, that could eventually break every temp-file consumer, not just uploads, which is why this is a patch-level bug fix with real production impact.
- What are the production risks of running Symfony on Lambda with Bref?
- The dominant risk is cold start: compiling the Symfony container can take 1 to 20 seconds on a fresh Lambda, and fresh Lambdas appear a handful of times every day even at steady traffic, so you must model this against your p99 and tail-latency SLO. The FPM-to-function-runtime switch is a genuine architectural change, involving process reuse with BREF_LOOP_MAX, no shared memory between invocations, and a /tmp directory that persists and must be managed explicitly. Ephemeral storage exhaustion from uploads or other temp-file consumers has a wide blast radius and tends to surface as intermittent, load-correlated failures rather than a clean error.
- Is bref/symfony-bridge still maintained, and what are the alternatives?
- It is the officially maintained Symfony bridge for Bref and is kept in step with Bref releases, with version 3.0.3 being a recent patch-level bug fix rather than an API change. For Laravel applications the equivalent is bref/laravel-bridge, which you should not mix with this package. Alternatives to the serverless approach itself include running Symfony on PHP-FPM behind containers or a managed platform, which avoids cold starts and the ephemeral filesystem entirely but gives up the Lambda operational model.
Weaver
How can I help you explore Laravel packages today?