Insights from JetBrains PHPverse Conference Part 1 — System-Level Innovation in the PHP Ecosystem

PHP marked its 30th anniversary in 2025, and the JetBrains PHPVerse Conference celebrated this milestone with five hours of intense, information-packed talks. Diving deep into the language's modern infrastructure — runtime, deployment, and scaling — it delivered a firehose of insights. For those who don't have the time or patience to sit through the dense sessions, this article distills the most critical takeaways, highlighting the ecosystem's focus on solving tough, foundational challenges.

The ecosystem is evolving with projects like FrankenPHP reimagining the runtime, Composer and Packagist optimizing for scale, and MCP enabling AI tools to better understand real-world development contexts. These aren't trendy pivots but deliberate steps toward robust, scalable PHP systems.

This is Part 1 of our PHPVerse breakdown, zeroing in on system-level shifts: performance limits, deployment challenges, dependency management, and intelligent automation. More than a recap, this is a strategic guide for engineering leaders navigating adoption and impact.

FrankenPHP And The New Runtime Shaping PHP’s Future

Early in the JetBrains PHPVerse lineup, one talk immediately set the tone: Kévin Dunglas’s introduction of FrankenPHP. Among a day of technically dense sessions, it stood out, not just for what it proposed, but for how directly it questioned long-held assumptions about how PHP should operate in 2025 and beyond.

Instead of iterating on familiar tools, FrankenPHP proposes something more foundational: a complete rethinking of the PHP runtime model to align with how modern systems are actually built and deployed. It was more than just a new tool, but also a call to action for the PHP ecosystem to evolve beneath the framework level.

Why Rethink the Runtime?

Dunglas opened by diagnosing the limitations of today’s standard stack. FPM, while battle-tested, was never designed for the concurrency, containerization, or real-time requirements of modern applications. In his words, FPM “starts from zero every time,” which is tolerable for legacy architectures but increasingly untenable in cloud-native or SaaS-scale environments.

The PHPVerse audience didn’t need convincing. Many engineers already wrestle with the cold start lag, the statelessness, and the orchestration overhead baked into FPM. FrankenPHP enters here not as a niche alternative, but as a general-purpose runtime designed to erase these constraints.

FrankenPHP’s Key Innovations

The talk introduced a runtime that blends language execution and web serving in one binary. Written in Go for performance and concurrency, FrankenPHP provides:

• Automatic HTTPS and native HTTP/3 support, streamlining secure communication out of the box.
• Zero-config local dev environments, helping teams skip the nginx + PHP + certbot setup dance.
• Worker mode that enables persistent PHP processes, bringing dramatic speedups (up to 80%) for Laravel and Symfony apps.
• Built-in support for WebSockets and SSE, making real-time features native rather than bolt-ons.
• Prepackaged Docker images and binary builds, simplifying CI/CD workflows and containerized delivery.

As Dunglas noted, this is about reducing surface area, tightening the loop between dev and deploy, and giving PHP a runtime that behaves like a first-class citizen in today’s ops landscape.

Practical Takeaways for Scalable Engineering

For teams building SaaS products or operating under performance constraints, FrankenPHP’s architecture directly translates to lower latency, fewer moving parts, and less infrastructure glue. At PHPVerse, the demo underscored how real-world Symfony apps can benefit from persistent workers, faster cold starts, and seamless real-time communication and all without rewriting application logic.

At Accesto, we’ve explored FrankenPHP in depth, but our experience has been mixed. In some environments, it brought performance benefits. In others, the gains were negligible. It’s not a silver bullet, but it’s promising. What PHPVerse highlighted is that the future of PHP will be shaped less by language features and more by the systems beneath them. We’re currently running a broader performance study on FrankenPHP, so stay tuned.

Composer & Packagist – Hidden Infrastructure, Massive Impact

At PHPVerse, Nils Adermann didn’t try to dazzle with new syntax or frameworks. Instead, he brought the audience’s attention back to something deceptively quiet but structurally critical: the health of the PHP dependency ecosystem. Composer and Packagist sit at the center of virtually every PHP project, but their impact is often only felt when things go wrong.

What his talk revealed was this: as PHP applications grow more interconnected, containerized, and automated, the demands placed on dependency tooling have changed. Composer and Packagist are evolving in response and not with noise, but with precision.

Why This Matters in 2025

By 2025, Composer is doing far more than managing packages. It plays a central role in how software gets built and delivered by working inside CI/CD pipelines, helping teams keep dependencies consistent, and running in every environment, from a developer’s laptop to production servers. It has become part of the delivery process itself, not just a tool that runs before the build.

But as Adermann pointed out at PHPVerse, the assumptions Composer was originally built on were single machines, modest dependency graphs, and minimal parallelization don’t hold in today’s systems. Scale doesn’t just amplify usage; it exposes fragility. When dependency resolution slows or a package becomes unreachable, it ripples through the entire delivery pipeline.

That’s why this moment matters: Composer is being re-architected for its real role, not as a tool developers run manually, but as a core layer of modern software delivery infrastructure.

Upcoming Changes & Insights from Nils

Adermann’s PHPVerse talk outlined concrete steps toward this new model. Composer 2.7 focuses on performance, repeatability, and resilience, all of which are qualities that matter less in theory and more in the chaotic, concurrent reality of production systems.

Some of the key improvements include:

• Secure install workflows, which help guard against supply chain compromise and enforce safer defaults for teams with sensitive environments.
• Improved caching mechanisms that allow CI pipelines and local environments to reuse install steps more intelligently, cutting build times and reducing flakiness.
• Support for Packagist mirrors, which give enterprise teams the ability to control latency, enforce geographic redundancy, and de-risk dependency retrieval.
• Built-in failover planning ensuring continuity even when the central Packagist infrastructure becomes temporarily unavailable.

They’re fault-tolerance features for teams whose systems can’t afford unpredictable install behavior.

How Teams Can Reduce Risk in Complex PHP Projects

The deeper lesson from Adermann’s talk was this: complexity hides in tooling. And Composer, precisely because it works so seamlessly most of the time, often becomes a blind spot. The danger isn’t just in broken installs, it’s in the accumulation of inefficiencies, inconsistencies, and silent fragilities that compound over time.

At Accesto, we treat dependency management as an important and often overlooked part of software development. During code audits, we frequently uncover issues buried in composer.json: unmaintained packages, transitive conflicts, or poor resolution strategies. These small misalignments compound in larger systems, resulting in slow builds, delayed releases, and increased risk of failed upgrades.

PHPVerse didn’t just spotlight what’s changing, it made the case for paying attention. Composer and Packagist are evolving because they have to. For engineering teams, the opportunity is clear: audit now, improve the defaults, and treat your dependency layer like production infrastructure, because that’s exactly what it is.

Symfony Core is 20 Years of Maturity, and Still Innovating

At the PHPVerse conference, Nicolas Grekas took a different approach. While other speakers introduced new tools and frameworks, he focused on Symfony’s steady pace of development. Rather than revisiting Symfony’s history, he spoke to how the project continues to move forward without compromising what has made it dependable for so long.

And it landed with precision. In an ecosystem where frameworks often chase features or trends, Symfony continues to do something rare: improve its internals while preserving trust at the architectural level. Good engineering is what enables software to remain dependable across product cycles, team changes, and scaling milestones.

Beyond the Framework: Release Cycles & Process

Grekas opened with a process. Symfony’s development rhythm is intentional: monthly bug fixes, twice-yearly minor releases, and a clear deprecation policy that gives teams time to adapt without fear of breakage. For engineering leaders, it’s what makes long-term planning viable.

What the PHPVerse audience saw was that Symfony’s value isn’t just in its feature set, but in the predictability of its evolution. That cadence builds trust, not just with developers, but with the product and architecture stakeholders who rely on Symfony as a long-term foundation. The framework earns its stability through discipline, not inertia.

And in enterprise environments, where software may live for 10+ years, that kind of slow, transparent progress is a strategic asset.

Highlights from Symfony 7.3 & Beyond

Symfony 7.3 brings a set of focused updates that respond directly to how teams are building applications today. One of the most notable additions is the JSON Streamer, built for more efficient processing of large data payloads, a common challenge in modern API-driven systems. The new Object Mapper simplifies how data structures are translated and reduces the amount of glue code developers typically maintain.

Another key shift is the move toward attributes as the default way to define behavior. This change improves readability and brings configuration closer to the code it affects. Symfony UX continues to develop in parallel, offering a cleaner approach to server-side UI rendering. There’s no need for React, Vite, or other heavy client-side frameworks, just HTML-first interactivity that works out of the box.

Symfony 7.3 adds practical updates for teams managing production systems. There are improvements to how HTTP clients handle secure communication, better options for tracking application behavior, and new controls for configuring background workers. These features give developers more flexibility and reduce the need to rely on third-party libraries for tasks that now come baked into the framework.

Grekas framed these changes not as flashy upgrades, but as composable building blocks, that is, small additions that reduce friction without creating surface area.

Building Future-Proof Architectures on Symfony

The subtext of the PHPVerse talk was clear: Symfony is a framework and an architectural strategy. Its conventions, lifecycle, and extensibility make it particularly suited for domain-driven design, modular systems, and enterprise-scale maintainability.

We chose Symfony as our core framework over 15 years ago, when it was still early in its journey — and that decision continues to pay off. Its structured evolution lets us modernize legacy systems without full rewrites. The predictable behavior means fewer bugs, smoother onboarding, and consistent release cycles, especially important for long-lived products. Symfony’s long-term support and discipline have been central to how we build resilient software at Accesto.

What Grekas showed at PHPVerse is what we already practice: if you want your software to grow without crumbling under its own weight, you need foundations built with foresight. Symfony delivers exactly that.

AI-Native Interfaces with MCP Servers

Among the technically grounded talks at PHPVerse, Marcel Pociot’s introduction of the Model Context Protocol (MCP) pointed towards a future where PHP systems don’t just respond to commands but collaborate with intelligent agents, not through vague AI integrations or brittle wrappers, but via a standardized protocol designed from the ground up to bring large language models (LLMs) into secure, context-aware alignment with actual software infrastructure.

It marked a shift in how AI is being positioned in the PHP ecosystem. Instead of speculative productivity boosts, MCP represents a step toward deep system literacy, where LLMs aren’t guessing in the dark, but operating with real-time awareness of the tools, state, and structure they’re interfacing with.

What is MCP? Why It Matters

MCP stands for Model Context Protocol and is not a product. It’s a protocol specification that allows LLMs to access localized context from within the developer’s system. This includes project files, CLI tools, internal APIs, logs, and even environment variables, but only under the precise, deliberate control of the developer.

What makes this powerful is that it inverts the default AI paradigm. Today, most LLM interactions are stateless, uninformed by the actual project at hand, and often rely on sending code out to remote APIs with limited privacy guarantees. MCP turns that on its head: context lives with the developer, and the AI must conform to the boundaries defined by the system.

At PHPVerse, this was presented as a new interface layer between codebases and automation agents. One that doesn’t require vendor lock-in, isn’t tied to a specific IDE, and can be integrated gradually into existing workflows.

MCP Use Cases for PHP Teams

Where this gets immediately practical is in how PHP teams can use MCP today. Pociot outlined real-world, near-zero-friction cases:

• Triggering infrastructure tasks like database migrations or deployments with conversational commands, where the LLM mediates input but the execution is gated through secured endpoints.
• Exposing internal APIs and diagnostic tools to local AI copilots, enabling developers to query or debug without writing temporary scripts.
• Automating internal dashboard scaffolding, CLI generation, or repetitive dev tooling, backed by real context and metadata, not just guesswork.
• Creating domain-specific copilots that know your business logic, architectural conventions, and even team coding patterns, because they’re grounded in the actual codebase, not just model hallucination.

These are incremental improvements that can be used in your projects, made safer and more reliable because they run inside the same environment where your code lives.

Marcel’s Work & PHP SDKs

One of the key takeaways from the PHPVerse session was how complete the ecosystem around MCP already feels. Pociot didn’t just propose a protocol; he shipped one. His open-source PHP MCP server is production-usable and integrates directly with tooling PHP teams already trust, like Laravel Herd and Expose.

The value here isn’t just compatibility. It’s abstraction without opacity. You don’t need to understand every nuance of an LLM to make it useful in your stack. With MCP, the AI becomes another interface layer, one that speaks your system’s language and adapts to your workflow constraints.

This grounds AI adoption in something PHP teams understand: clear boundaries, server-side control, and open standards.

Bringing AI Context to Legacy Systems

Perhaps the most subtle, but powerful, insight from the talk was how well-suited MCP is to legacy environments, especially ones where exposing proprietary code to external AI tools is a non-starter.

Instead of forcing a wholesale migration to “AI-native” stacks, MCP allows for contextual augmentation. It gives older systems new affordances: introspection, automation, and smarter scaffolding, without tearing anything down. Just by implementing a small, contained server layer, PHP applications can begin interfacing with modern AI systems securely, incrementally, and reversibly.

PHP's Infrastructure Is Strategic

If there was a single throughline across the first half of PHPVerse, it was this - the real innovation isn’t where people expect it. It’s happening at the system boundary at the runtime that serves your app, the tool that resolves your dependencies, the framework that guarantees stability five years from now.

FrankenPHP doesn’t just make PHP faster; it collapses complexity. Composer isn’t just getting quicker, it’s quietly becoming a resilient layer of your build infrastructure. Symfony isn’t “still relevant”, it’s making a case for what deliberate software evolution should look like. MCP doesn’t gesture toward AI trends; it gives teams a way to adopt automation without gambling on it.

These aren’t surface-level improvements. They’re architecture-shaping changes. And they come with real implications for how teams scale, hire, onboard, and avoid collapse under growing systems.

This is the layer Accesto works in every day, not just code, but everything beneath it. Not just whether something runs, but whether it holds up when your usage triples and your team size doubles. That’s why this recap doesn’t stop at what was announced. It starts a conversation about what to adopt, what to wait on, and what quietly changes the trajectory of your stack.

And we’re not done.

In Part 2, we’ll move up the stack and into developer tooling, full-stack workflow improvements, and what it feels like to build with PHP in 2025. From streamlined onboarding to HTML-first frontend strategies, the second half of PHPVerse was a reminder that infrastructure is only half the equation. The other half is developer experience, and it’s evolving just as quickly.