Schedule

Storing email addresses, dates of birth or national identity numbers in plain text is a serious risk the day your database leaks. Application-side encryption makes that data unreadable to the database itself. It also makes WHERE email = :value impossible, which is usually where the project quietly stops.

This talk shows how to keep both. Client-side field encryption with Doctrine and a key management system: which algorithms to choose, how deterministic encryption enables equality lookups, how keys are stored, rotated and revoked, and what you give up in exchange. We'll also look at Symfony's new KMS component and where it fits.

You'll leave knowing how to turn your database into a safe you can still search.

The Console component runs almost everywhere PHP does: Composer, PHPStan, most frameworks and CMSes, and your own applications. Until recently, using it outside the full-stack framework meant giving up dependency injection and lazy services, or dragging the entire HTTP layer into a tool that never serves a single request.

Symfony 7.3 redesigned commands to be simpler, more powerful and more expressive. Symfony 8.2 goes further with a DI-powered, HTTP-less foundation: a real container, real service wiring, no web stack anywhere in sight.

Come see what modern Symfony commands look like today, and how standalone CLI applications finally become first-class citizens of the framework.

On Cloud Run, our backend answered its first request in 14 seconds. Almost all of that time went to one place nobody on the team would have guessed, and the profiler alone never found it.

This is the full hunt: the tooling that finally showed us the truth, the framework internals we had to read to understand what we were seeing, and the obvious optimizations that quietly made cold starts worse before anything got better. Image size, autoloading, the compiled container, cache warmup, and the way they interact.

We finished at 1.8 seconds. You'll leave with a method for diagnosing your own cold starts, not a list of tricks to copy.

At SymfonyCon 2025 we outlined a long-term supply chain security strategy. Reality caught up faster than expected. The PHP ecosystem was hit by the same class of attack that has repeatedly hit npm and PyPI: hijacked GitHub accounts and stolen access tokens, used to publish malicious tags on packages the attackers never owned.

This talk covers what we changed in response. Detection first: the Aikido malware feed integrated into Packagist.org, and a public transparency log that made analysis possible. Then prevention: Composer 2.10's unified dependency policy for malware, advisories and abandoned packages; immutable stable releases so tags can no longer be silently rewritten; Composer 2.11's minimum-release-age setting; published MFA status for maintainers; organization-level ownership controls.

You'll get concrete practices for hardening your own supply chain, and where we're taking this in 2027.

A DOM emulator reproduces your HTML. It does not reproduce a browser. Meanwhile browser tests usually run against a separate server, blind to application state. PlaywrightPHP and the Playwright Symfony bundle close that gap: a real browser drives the page while the test kernel handles the request in the same PHP process, no web server involved. One PHPUnit test can drag a card in a Live Component, wait for the async update, then assert the DOM, the dispatched events, and the database rows. Three live demos cover payment flows, Live Components, and visual regression on a design system.

PHP has a type system, and it has quietly become one of the more interesting ones among dynamic languages. It grew by accretion over two decades: scalar types, nullable types, union and intersection types, never, true, and a notion of subtyping built on Liskov's Substitution Principle.

This talk starts from the formal question of what a type system actually is, then uses that vocabulary to explain PHP's. Why LSP is the rule that governs subtyping, what variance means for the signatures you write every day, and where PHP's system is genuinely sound as opposed to pragmatically compromised.

We finish by looking forward: what PHP's type system could still gain, what each addition would cost, and what is realistically on the table. And there's a practical reason to care right now. Types are the clearest signal a codebase gives a model about what it may do, so knowing what they actually guarantee is worth more than it was two years ago.

Symfony AI gives you the components to ship AI features. It doesn't tell you how to structure them once they hit production. Human-in-the-loop approval, workflows that run for minutes instead of milliseconds, retries, cost tracking, and the extension points you reach for when the happy path stops being enough. This talk walks through the patterns that hold up in real applications, the ones that don't, and where the component boundaries actually sit. You'll leave with a working mental model for designing AI features, not just calling a model.

Migrating legacy PHP to Symfony stalls on shared resources. The database, the session, the mailer all exist twice, and duplicating that code is the cheap answer nobody wants to maintain. Calling into Symfony from outside the framework looks impossible, but it isn't. This talk shows how to boot the container from legacy code and get full dependency injection on both sides of the migration, with the trade-offs and the sharp edges spelled out. Assumes familiarity with Symfony's DI configuration.

For fifteen years Doctrine shaped how we write entities, and not always for the better. Entities could not be final, because proxies had to extend them. Every field grew a getter and a setter. Money, addresses and identifiers ended up as strings and floats, because mapping anything richer cost more than it was worth. None of that was a design decision. They were workarounds for things PHP could not express.

It can now: attributes, backed enums, property hooks, asymmetric visibility, native lazy objects, arbitrary-precision numbers in core. Doctrine ORM 3.4 and DBAL 4.3 pick all of it up, and ORM 4 is built on it.

We take one realistic entity, too many accessors and primitives, and refactor it live on the slides: final classes, no setters, typed identifiers, embedded value objects, self-registering DBAL types. Same schema. No migration. Considerably less code.

Born with profound hearing loss, I've spent fifteen years in an industry that runs on conversation, eleven of them at a fully remote company. My comprehension in meetings went from roughly 30% to somewhere near 100%. That change wasn't willpower. It was six technologies arriving one after another.

Hearing aids, subtitles, text-based communication, Bluetooth, live captions, smart glasses. I'll walk through what each one actually changed, and where each still falls short.

What emerges isn't a disability story. Subtitles work in noisy rooms, text works across time zones, captions are searchable: accessibility features help everyone, and they are still almost never the default. You'll leave with three concrete things you can do to your own product tomorrow. Every choice a developer makes either includes or excludes 15% of users.

The HttpKernel dispatches an event and every listener registered years ago fires, in an order nobody chose deliberately, doing work nobody has reviewed since. You know how that goes.

You have listeners too. Behaviors registered early, in circumstances that made sense at the time, still firing on every event today. Some of them made you a good engineer. Some of them are quietly working against you, and like any legacy listener they're hard to see precisely because they have always run.

This is a mostly non-technical talk about the habits developers carry, using a component you already understand as the way in. No prior knowledge required beyond having been a person for a while.

Every API is a public attack surface, and the failures repeat with remarkable consistency. Broken object-level authorization, broken authentication, unrestricted resource consumption, injection: the OWASP API Security Top 10 is the industry's record of what actually gets exploited, not what theoretically could be.

This talk walks the whole list. For each item: what the flaw looks like in real code, how an attacker reaches it, and the specific mitigation, from authorization checks that belong at the object level rather than the route, to rate limiting and schema validation at the edge.

You'll leave able to audit your own APIs against the list, and knowing which entries deserve your attention first.

Diversity is a large topic, and most of the companies I visit are barely diverse at all. The causes are rarely policy. They're language and habit, repeated daily by people with no intention of excluding anyone.

Are you aware of how everyday phrasing signals who belongs and who doesn't? How implicit bias shapes hiring, code review, and who gets interrupted in meetings? Small changes to language and behavior, plus knowing where the common pitfalls sit, make a workplace noticeably more welcoming without a single new initiative.

This talk works through ten concrete situations where we can do better, each with practical examples you can apply to your team next week.

Every developer knows the rule: never pass user input to innerHTML. Yet as LLMs move into our applications, we hand model output straight to the DOM, the shell, or the database, because it came from our own system and therefore feels trustworthy. It isn't.

This talk looks at OWASP LLM05, improper output handling, and what it means for web security. We'll walk through cases where entirely innocuous-looking input steers a model into producing XSS and injection payloads, and see why the input filters you already have never fire.

You'll leave professionally pessimistic about model output: how to sanitize it, how to render generated Markdown safely, and how to treat AI content as the untrusted input it always was.

Most Symfony applications buffer everything. Doctrine results, serialized objects, JSON payloads, exports: built completely, then sent. This works fine until it doesn't. Memory spikes, time-to-first-byte creeps up, and the big export starts dying in production.

LLMs make it impossible to ignore. When a model takes several seconds to answer, waiting for the return means staring at a spinner for every one of them. Streaming stopped being a backend optimization and became the foundation the interface is built on.

We'll take apart the assumption that a response must be finished before it's sent, and rebuild the data flow end to end: StreamedResponse, incremental encoding with the JsonStreamer component, iterable Doctrine sources, Server-Sent Events, EventStreamResponse. You'll leave able to stream as data is produced, export several million rows, and keep memory flat, with tools already in the framework.

Keynote

Showing growth as a developer requires evidence, and evidence requires a system. My earlier attempts at journaling all died the same way: too much friction, too little return. LLMs changed that arithmetic.

This talk describes the system I've now run for a year. What it captures, how the model helps without writing my thoughts for me, and how the open-source template works. It isn't an app and it isn't a SaaS: it lives in your IDE, in your own workflow, and you're meant to modify it.

I'll cover what changed over the year, including sharper writing prompts and MCP servers pulling context from the tools I already use, plus the pitfalls worth knowing about before you start your own.

For twenty years PHP has worked the same way: one request, one process, and then everything is forgotten. That model is why PHP is simple, robust and easy to deploy. It is not the problem.

The problem is what it cannot do. Nothing can wait, watch, or remember between requests. So we built cron jobs, supervisors, TTLs and Redis keys around the runtime to make up for one missing capability.

This talk is about adding that capability without giving up the model. I've spent the last months adding background workers to FrankenPHP: long-running PHP outside of HTTP, publishing data your requests read directly, with no serialization, no TTL and no restart. Your controllers don't change. Your requests still forget everything. Something beside them now remembers.

I'll show what that makes possible, what each step really costs, and why the runtimes that ask you to rewrite your code will stay niche while this one becomes normal.

Build a website with PHP. Build a mobile app with something else. It was a simple rule, almost self-evident, right up until the request every team eventually hears: the site is great, now we need an app. What follows is usually a new stack, new skills, new hires, and new lines in a README nobody reads.

Symfony UX Native bends that line. A single Symfony codebase, Twig templates, Doctrine entities, form types and all, becomes a real iOS and Android application through Hotwire Native. We'll write a bridge component live, and watch ux_is_native() reshape one template for two surfaces.

We'll also be honest about architecture, developer experience, and where the approach genuinely shines versus where it doesn't. No PHP developer was forced to learn Swift in the making of this talk.