Schedule

Keynote

Developers know one golden rule: never use innerHTML on user input. Yet, as we're integrating Large Language Models (LLMs) into our applications, we often make a fatal mistake. We're treating AI output as a trusted source. This is fine. Well, not automatically...

Let’s look at OWASP LLM05 and how "Improper Output Handling" affects web security. Therefore, let's discuss examples of how safe inputs can trick models, leading to vulnerabilities such as XSS and injection attacks. By the end, you’ll learn how to be "professionally pessimistic" for AI. You’ll see how to sanitize LLM data, safely render Markdown, and manage AI-generated content. Let's approach technology with caution, I look forward to exploring this with you! ❤️

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.

For nearly thirty years, writing PHP has meant writing for an interpreter. When that one Symfony endpoint that won't go faster becomes performance-critical, you reach for a C extension or a rewrite in Go or Rust and leave PHP behind.

Elephc does the opposite. Written in Rust, it compiles a static subset of PHP straight to native machine code: no Zend engine, no fallback interpreter. Your project stays in PHP, only the critical modules go through Elephc.

It's the same wall that stalled a recent generics RFC: monomorphization is free in Rust but too costly in a dynamic engine like PHP. As always, the interpreter is the constraint, not the language.

After a tour of the tool, I'll take you from an everyday example to a Doom-style demo, limitations included. You'll leave with a clear mental model of AOT compilation.

A Symfony application comes to life in the browser: navigation, validation, dynamic components, and JavaScript interactions. A DOM emulator can reproduce the HTML, but not the behavior of a real browser. Yet browser tests often run outside Symfony, against a separate application server and lifecycle, with little access to application state.

Playwright drives real browsers with semantic locators, automatic waiting, and web-first assertions. PlaywrightPHP brings this API to PHP: navigate, fill forms, drag and drop, execute JavaScript, inspect the network and console, record traces, or generate PHP code. The Playwright Symfony bundle brings that journey into Symfony's test environment. One PHPUnit test drags a card in a real Live Component, waits for the asynchronous update, then asserts the DOM, dispatched events, and database state.

The browser sends a real request. The bundle turns it into a Symfony Request, lets the test kernel handle it in the same PHP process as the test, and returns the Symfony Response to the page. No separate web server is required. The same test sees both sides: network, console, and trace in the browser; Request, Response, profiler, logs, and database state in Symfony.

Through one application and three live demonstrations, you will see how this model tests payment flows, Live Components, and design systems, protects critical user journeys, and catches visual regressions.

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.

Symfony applications rarely live alone. They communicate with payment providers, identity services, messaging platforms, AI APIs, and countless external systems. But as these integrations grow, testing them becomes increasingly difficult: too many mocks, fragile fixtures, outdated assumptions, and tests that no longer reflect reality.

In this talk, we will explore modern approaches to testing HTTP integrations in Symfony applications. We will go beyond traditional mocking strategies and discover how to build tests that are both reliable and maintainable.

Using Symfony HttpClient as a foundation, we will look at practical techniques to improve the developer experience: from controlling HTTP responses, to recording and replaying real interactions, to validating that our application still respects external API contracts.

You will learn how to design a testing strategy that gives confidence without sacrificing speed, making your integrations easier to evolve and safer to maintain.

Picture this: you connect an AI agent to your API and, all at once, dozens of "tools" pile into its context before it's done a thing. There has to be a better way, and there are a few, each with its own trade-offs.

After a quick refresher on the Model Context Protocol (MCP) and its PHP SDK (how an agent discovers your tools, understands what they expect, and calls them), we'll look at how to feed an agent its tools with Symfony and API Platform. From automatic strategies (generating tools from your API, or a Hydra gateway that lets the agent discover them by navigating hypermedia links) to the manual approach, declaring exactly the tools you want using PHP attributes.

We'll build them live and weigh them honestly: what saturates the context, what scales, what respects the constraints of REST/HATEOAS. You'll leave knowing which approach fits your own APIs.

Your parents flew to Split for their summer holiday. They went to Yugoslavia. Yugoslavia doesn't exist any more, so why does your flight tracker insist they went to Croatia?

That's the question that made me realise my nice, simple CRUD database had quietly stopped being simple. Airlines merge and rebrand. Airports get renamed, and sometimes change country. Borders move. A row that just says "Croatia" rewrites my parents' holiday every time the world does.

This is the story of how a hobby flight logger outgrew its schema, and what event sourcing actually looks like once you build it instead of reading blog posts about it. No Kafka, no swarm of microservices: just Symfony, Doctrine, Messenger and a few hundred lines of PHP. We'll go through the parts that matter (append-only events, projections, and the temporal queries that let me ask "what country was this on the day of the flight?") using real, messy aviation data.

And if your parents holidayed in Yugoslavia too, you're in the right room.

How can AI agents retain project context, working conventions and past decisions across sessions and tools? This talk shows how user- and project-level instructions can route agents through a small, indexed and versioned Markdown knowledge base, giving them the operational context they need without turning every prompt into a briefing document. We will also explore the limits of this approach, how it compares with native memory, and when heavier retrieval systems become a better fit.

Most Symfony applications buffer everything: Doctrine results, serialized objects, JSON, exports. They build the entire response, then send it. This works fine, until it doesn't: memory spikes, time-to-first-byte creeps up, and exports start dying in production.

LLMs make the problem impossible to ignore. When a model takes several seconds to answer, waiting for the return means staring at a spinner the whole time. Streaming isn't a back-end optimization anymore. It's the foundation modern user experience is built on.

In this talk, we tear down an assumption baked into most Symfony apps: that a response has to be fully built before it's sent. We'll rethink the data flow end to end: StreamedResponse, incremental JSON encoding with the JsonStreamer component, iterable Doctrine data sources, Server-Sent Events, and EventStreamResponse for real time.

You'll walk away knowing how to stream data as it's produced, power live interfaces, generate exports of several million rows, and keep memory flat, using tools already sitting in Symfony.

For fifteen years, Doctrine shaped the way 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. Domain concepts like money, addresses and identifiers ended up as strings and floats, because mapping anything richer was more trouble than it was worth.

None of that was a design decision. Those were workarounds for things PHP could not express yet.

It can now. Attributes, backed enums, property hooks, asymmetric visibility, native lazy objects, and an arbitrary-precision number object in core. Doctrine ORM 3.4 and DBAL 4.3 pick all of it up, and ORM 4 will be built on it.

We take one realistic entity, too many lines of accessors and primitives, and refactor it live on the slides: final classes, no setters, enums, typed identifiers, embedded value objects, custom DBAL types that register themselves. Same database schema at the end. No migration. Considerably less code.

`$form->handleRequest($request);`

One line, and somehow your data is hydrated, validated, CSRF-protected and ready to be persisted.

The Form component is probably the most powerful and the most misunderstood piece of Symfony. We use it every day, we copy-paste code like `'by_reference' => false` without really understanding what it does, and we cross our fingers when a data transformer doesn't fire. Black magic? Not quite.

Each "magic" behavior of the Form component has a story behind it: a problem it solved, a version it landed in, a trade-off someone had to make. Let's travel through 15 years of Symfony forms to understand why they work the way they do:
- The origins: How its start and how it gave birth to other components you use every day.
- Under the hood: Type inheritance vs. type extensions, type guessing, data transformers/mappers, form events, etc…
- Last year (7.4): Multi-step form, create your own (black magic) wizard.
- Today (8.2): Attribute-based forms, and why this brand-new syntax stands on the very same foundations.

Whether you love forms or avoid them, you'll leave this session reading the Form component like an open book rather than a spellbook.

To build a website, we used PHP. To build a mobile application, we used something else. It was a simple rule. Almost self-evident.

Then one day, a request arrived, the kind every team eventually hears: "The website is great. Now we need a mobile app." From there the script is usually familiar: new technologies, new skills, new hires, new lines in a README nobody will read.

In this talk, I'll show how Symfony UX Native quietly bends what we thought was an immovable line between web and mobile. Through concrete demos, we'll see how a single Symfony codebase (Twig templates, Doctrine entities, Form types, all of it) turns into a real iOS and Android application via Hotwire Native. We'll write a bridge component live. We'll watch ux_is_native() reshape a single template for two surfaces. We'll talk honestly about architecture, developer experience, the limits of the approach, the use cases where it genuinely shines, and the questions every PHP developer asks the first time they see it work.

Because in the end, the surprising thing isn't that a mobile application can be built with Symfony. The surprising thing is that it's starting to feel perfectly logical, even though PHP wasn't supposed to do that.

(PS: No PHP developer was harmed, or forced to learn Swift, during the preparation of this talk.)

Reindexing millions of documents across 10 Elasticsearch indexes was taking hours, long enough that it only ran on weekends. With a growing number of custom Normalizers slowing things down, Symfony's Serializer wasn't cutting it anymore.

We built a proof of concept with Symfony's JsonStreamer to see if it was as fast as advertised.

This talk is an honest account of that journey: the challenges, what we learned, and how it could apply to your application as well.

Somewhere in some company, people who don't write code are prompting their way into production. They build tools in a browser, deploy them without a single line of traditional code, and hand them off to the rest of the business. Eventually, maintaining that platform becomes someone's job. It became mine. Low-code and vibe-coding platforms are gaining massive adoption, but they offer almost none of the engineering practices we take for granted. This talk is about what happens when you try to apply rigor, testing, and architecture to an ecosystem designed to ignore them.
Following one small function from concept to production, we'll uncover everything these platforms fail to provide, and how to fix it. Because while the tools change, the core problem-solving doesn't.

APIs are the foundation of our AI applications today and need to be secure. From broken authorisation and authentication to injection attacks, the OWASP API Security Top 10 identifies the most critical security issues facing APIs today. In this talk, we'll walk through the items on the list and explore these security flaws and look at how to prevent them. By the end of this session, you'll have a clear understanding of the most critical API security risks and be equipped with the knowledge to build more secure APIs.

When a coding agent writes code, your CI becomes its definition of done, and anything your checks cannot see can pass as finished. This talk introduces harness engineering for existing Symfony applications. It covers turning tools like PHPStan and deptrac into feedback an agent can act on, adding custom architecture rules for controllers, and enforcing them on legacy code with a baseline ratchet.

At SymfonyCon 2025 we asked “Package Manager Security in 2025: What’s Next?” and outlined our long term supply chain security strategy. Reality caught up with us fast!

The PHP ecosystem has been hit by the same class of supply chain attacks that has repeatedly hit npm and PyPI: taken-over GitHub accounts and stolen access tokens used to publish malicious tags on packages the attackers had no legitimate access to. This talk walks through what we changed across Composer and Packagist in response, and what is still in flight.

Our response came in two phases. First, detection: the Aikido malware feed integrated into Packagist.org, a public transparency log that helped analyze attacks. Then the prevention work: Composer 2.10's unified dependency policy framework covering malware, advisories, and abandoned packages, stable version immutability on Packagist.org so tagged releases can no longer be silently rewritten. We’ll look at more recent changes like Composer 2.11’s minimum-release-age configuration, maintainer security posture and MFA status publication on Packagist, and the new organization level ownership and controls over open-source packages on Packagist.org.

We’ll provide concrete tips and best practices for keeping your own supply chain secure, and give an outlook into what we have planned for 2027.

Diversity is a big topic and yet a lot of companies I encounter are hardly diverse. What could be the cause, and how can we change this?

Are you aware of how your daily common language may exclude certain people or groups? Could it be that implicit bias and our own behaviour may impact our chances of improving diversity? Slightly changing your language and behaviour and being aware of potential pitfalls may make your workplace more inclusive and welcoming. In this talk we'll discuss 10 situations in which we can improve our daily (work) life to be more inclusive. It includes practical examples that can be directly applied to your team or company.

In order to be able to show growth and improve myself as a developer and coworker, I need a system. Previous attempts at journaling failed, but with the rise of LLMs and AI, there is a new option.

In this talk, I explain my journaling system, how it works for me, and how you can use the open sourced template to make it your own.

This is for developers: it is not an app, nor a SaaS. It's something you can use within your own IDE, with your own workflow, and your own modifications.

I've been using this system for a year now. It has grown, like I have. I will share some of the pitfalls and improvements I've gone through so far, which includes better text writing, use of MCPs to pull data from other systems, and more.

Eight years ago, Mercure was born: an open-source protocol and Go server designed to bring the power of real-time to any web architecture, especially ecosystems like PHP that don't natively support persistent connections.

Symfony quickly adopted Mercure as its official solution for real-time features. Today, Mercure has become an essential standard, powering hundreds of production projects, from startups to enterprise accounts. Fully integrated into Symfony (via Symfony UX) as well as API Platform, and bundled by default in FrankenPHP, Mercure radically simplifies the developer experience. Whether you are building collaborative editors (Google Docs style), syncing instant dashboards, notifying your users when a background task finishes, or, more recently, streaming LLM tokens and tracking AI agent progress, Mercure stands out as the ideal solution.

Today, we are releasing Mercure 1.0 along with a brand-new Symfony integration! This protocol overhaul leverages the latest web standards, "URL Pattern" and "OAuth Rich Authorization Requests," to make developing AI and real-time features even simpler, more powerful, and more secure. This new version also brings optional compatibility with OAuth and OIDC servers.

Join me during this talk to discover all the new features in this latest release of Symfony Mercure, and make your apps more interactive than ever!

What it takes to run coding agents in production across your team.
Every team has a coding agent that ships great code on someone's laptop, and that stops working once the whole team relies on it. Drawing on what we learned running (and building) a software factory at Upsun, we'll dig into a few problems: sandboxing untrusted code, keeping non-deterministic models on a deterministic track, giving agents shared context instead of per-developer prompt files, and evaluating agent work beyond "the tests passed.

Storing your users’ email addresses, dates of birth, or social security numbers in plain text poses a major risk in the event of a database leak. With robust application-side encryption, you can make the data unreadable by the database. But then it becomes impossible to do a WHERE email = :value. How can you secure your sensitive data without sacrificing essential business functionality?

We will see how to implement client-side field encryption with Doctrine and a key management system. The algorithms to use, key management and rotation: learn how to turn your database into a safe without losing your ability to query it.

Your code was never the problem. The problem is nobody wanted the thing you built. Learn how to find out who actually wants a feature before you build it, and why the answers double as the pitch you'll need later to get people to use it. Four questions, asked before you write a line. No personas. No funnels. Just the research that tells you what deserves to exist.

At Upsun, I don't decide what gets built. I'm the one who has to explain it afterwards, which makes me the first to find out when nobody did the thinking. So we'll walk the four questions you can ask before anything starts, what a bad answer sounds like, and how to kill an idea (including your own) with evidence instead of taste. Then the turn: those same four answers, relabelled, are your entire positioning. Building got cheap. Deciding didn't. You'll leave with a framework that serves as a build decision and a positioning doc, because they were never two documents.

What if we combined Symfony UX and Symfony AI to make our agents even more interactive?

Imagine interacting with an agent not only through text, but also by exploring locations on a map, visualizing data through interactive charts, or selecting exactly what you need with an autocomplete, all using components you make available to your agents.

And why stop there? We can also expose tools that let them act directly on the frontend and update the UI live, thanks to Turbo.

This is exactly what AG-UI, a new protocol for agent-to-frontend communication, is designed for. In this talk, we'll explore a small PHP implementation of it, and see what it takes to give our agents new ways to interact with users and with our applications themselves.

An agentic software factory connects the work of deciding what to build, implementing it, checking it, and running it. The coding agent is just a starting point. Around it, the factory expands in four directions. Intent and specifications give the work a purpose and clear constraints. Validation and verification establish whether the result works and solves the intended problem. Delivery and operations keep it running. Strategy uses evidence to decide what deserves attention next.

We will explore the building blocks that connect these responsibilities into a working system. Shared context, explicit handoffs, automated checks, and human decisions let each workflow use what the others learn. You'll leave with a conceptual map for building a real system around the coding agents your Symfony team already uses.

Mate started as a hallway conversation at SymfonyCon Amsterdam 2025. A few weeks later it shipped in Symfony AI 0.1, and in April it had its first public outing at SymfonyLive Berlin. Now it comes back to the conference where it began.

You'll learn what Mate is, the principles behind it, and how it gives coding agents real insight into a running Symfony application. Then we'll look at the two biggest changes since Berlin. Mate dropped its MCP server for a native CLI, after we measured how agents actually discover and use tools. And Agent Skills now ship with the packages they belong to, so the people who build a bundle can also teach agents how to use it.

There will be a live demo, and I'll be honest about the wrong turns along the way.

Should your next Symfony application be headless, or should it remain a monolith?

In e-commerce, this is often one of the first architectural questions teams need to answer. Clients want modern, dynamic, responsive user experiences. Developers want maintainable systems. Businesses want fast delivery, good SEO, reasonable costs, and the ability to evolve the product over time.

For a long time, the discussion has often been presented as a binary choice: either we build a traditional server-rendered application, or we move to a fully headless architecture with a separate frontend application. Both options have strong arguments. Both also come with hidden costs.

In this talk, we will compare both approaches from a practical Symfony perspective. We will look at SEO, performance, responsiveness, frontend flexibility, team workflow, deployment complexity, maintaining multiple repositories, and the long-term cost of ownership.

But the main goal of this talk is not to declare a single winner.

Instead, we will ask a more useful question: do Symfony teams still have to choose between a classic monolith and a fully headless architecture?

Thanks to Symfony UX, Live Components, Twig Components, and the ability to use React or Vue components directly inside Twig, Symfony gives us a powerful middle ground. We can keep the productivity, simplicity, and SEO advantages of a traditional Symfony application, while progressively introducing dynamic, interactive frontend experiences exactly where they bring real value.

I will share how we successfully implemented this approach in Sylius, what we learned from the e-commerce world, and how these lessons can help Symfony teams build modern, dynamic applications without immediately turning every project into a fully headless architecture.

Attendees will leave with a practical framework for deciding when to stay with a monolith, when to go headless, and when a hybrid Symfony architecture can give them the best of both worlds.

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.

I'm Field CTO at Upsun, with profound hearing loss since birth. My primary job is to help our teams collaborate better in order to solve our customers’ problems. An ironic position given my disability.

In this personal presentation, I share six technological advancements that transformed my career over 15 years: hearing aids, subtitles, text-based communication, Bluetooth connectivity, live captions, and smart glasses.

These technologies increased my comprehension from 30% to 90-100% in meetings, enabling me to thrive in a fully remote company for 11 years. But here's the challenge: we have the technology, yet accessibility is rarely the default.

I'll demonstrate how accessibility features benefit everyone (subtitles in noisy environments, text communication for time zones, searchable captions), and provide three concrete actions developers can take tomorrow to make technology more inclusive. Every developer choice either includes or excludes 15% of users. Choose inclusion.

Twig Components have made it easier than ever to build reusable UI components in Symfony. But while templates are often nicely organized, their CSS, JavaScript, images, and other assets usually end up somewhere else.

What if every component could own everything it needs?

In this talk, we'll explore an approach that keeps templates and their assets together, making components easier to understand, reuse, and maintain. While this architecture fits naturally with Atomic Design, it works equally well for any component-based Symfony application.

To demonstrate the concept, I'll introduce AtomicAssetsBundle, an open-source bundle that automatically discovers and bundles assets alongside your Twig components. Along the way, we'll discuss the challenges of component-scoped assets, how this approach integrates into existing Symfony projects, and the trade-offs of keeping everything in one place.

Whether you're building a design system or simply want a cleaner way to organize your frontend code, you'll leave with practical ideas for creating truly self-contained Symfony components.

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.

In this talk we compare the Symfony HttpKernel and its heavy usage of EventListeners to your own behavior and the "legacy code" event listeners that you developed early in your life, but that might sabotage you today.

This is a mostly non-technical talk, rather centered around mental health.

You have an idea for a Symfony app. How long until it is in production, safe and observable?

Live on stage, we create a small app and deploy it to SymfonyCloud, the official cloud for Symfony, without writing a single build or deploy script.

Then you use it from your phone.

Next, we add a slow feature on a copy of production, your votes included, find the bottleneck with Blackfire, move the work to a background worker, and ship it safely.

No prior Symfony experience needed.

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.

Let’s compare different transports for Symfony Messenger and examine their business impact. Symfony offers multiple high-quality integrations, but teams often lack the practical know-how to decide which queue system is best for their application.

I will provide data-driven insights to guide that choice, covering retry strategies implementation, idempotency (exactly-once vs at-least-once systems), failure handling, operational hazards and hardware requirements, and how they impact your choice.

Rather than treating the Messenger component as a uniform high-level abstraction, I will look at where differences between backends matter in practice: how messages are acknowledged, how workers behave under high load or failure, how efficient different systems are budget-wise, and which trade-offs emerge when you optimize for throughput, reliability, or simplicity.

The goal is to give you a clear, technically grounded way to evaluate queue transports in Symfony-based systems and to avoid assumptions that do not hold once the system reaches production.

Your agents open pull requests faster than your team can check them. Approving them is not a review policy.

This talk is about the review process that matches modern realities. Who reviews agent-written code, and what they should actually look at. How much review a change deserves, and when this decision is taken. Who stays accountable when the code is fully generated. And how to keep a record of why a change was made, so the person who signed off can explain it six months later.

Drawn from our discovery interviews with multiple PHP teams, from Symfony agencies to a 2,000-engineer group, and from how we run review in Upsun ourselves. You leave with a review guidelines that you can start applying in your next development cycle.

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.