EvolvePHP 2 Reaches Its First Alpha — The Framework Is Becoming Real

This is a milestone I have been looking forward to for a while.

EvolvePHP 2.0.0-alpha.1 is officially out.

Until now, most of what I have written about EvolvePHP has focused on architecture: modular applications, execution isolation, long-running PHP, modernization, Bridge, service lifetimes and designing software for change.

With this release, those ideas are no longer only plans.

There is now a tagged, testable EvolvePHP 2 Alpha.

It is still experimental. APIs can change. It is not production-ready.

But it is real.

The first Alpha was published on September 13, 2026, targeting the 2.x line.

What has actually been built?

Quite a lot of the foundation is now implemented.

The Alpha includes:

• a runtime-neutral Core with configuration, service registration, Application/Execution/Transient service lifetimes, execution scopes, deterministic reset and execution orchestration;

• a PSR-based HTTP foundation with middleware, routing, dispatch, health handling and explicit response-resolution/emission boundaries;

• module and plugin foundations with dependency/capability graphs, lifecycle orchestration, restricted service registration and Composer-based plugin discovery;

• Evolve Doctor diagnostics and development tooling;

• read-only Evolve Audit foundations and adoption-planning declarations;

• embedded Bridge foundations for PSR, Laravel and Symfony;

• remote HTTP/JSON Bridge support, including an isolated PHP 7.4-compatible legacy client;

• an application skeleton with explicit CLI, route configuration and module/plugin generators.

One area I am particularly pleased with is the execution model.

EvolvePHP already distinguishes between:

Application
Execution
Transient

An HTTP request, CLI command or other execution can receive its own execution scope. Cleanup/reset results remain separate from the business operation result, which gives future runtimes enough information to decide whether a process is still safe to reuse.

That foundation is important for where EvolvePHP is going.

Modernization is also present in the Alpha

The modernization direction is no longer only an RFC.

Evolve Audit can inspect existing PHP source and Composer evidence without executing the target application.

Adoption planning can record ownership, compatibility requirements, migration evidence and rollback evidence.

Bridge can then support a capability that needs to coexist with an existing application.

For compatible environments, embedded integration can use PSR, Laravel or Symfony adapters.

Where PHP versions or dependency graphs cannot safely coexist, Remote Bridge provides a process boundary instead. The legacy remote client has a deliberately isolated PHP 7.4 compatibility boundary while EvolvePHP 2 itself continues to require PHP 8.4.

The principle remains:

Understand
   ↓
Plan ownership
   ↓
Integrate
   ↓
Move one capability
   ↓
Validate

Not:

Rewrite everything

How can you try Alpha 1?

There is an important limitation here.

The first-party packages are not yet independently published, and public composer create-project installation is not available yet.

So I do not want to pretend this is already the normal end-user installation experience.

For now, Alpha 1 is a source preview.

Developers who want to inspect or contribute to the framework can clone the repository:

git clone https://github.com/josiahking/evolvephp.git
cd evolvephp
composer install
composer quality

The repository also contains the accepted application skeleton and dedicated Alpha documentation. The skeleton already owns explicit route and CLI configuration, with doctor and route:list as its baseline commands. Development tooling also provides module:new and plugin:new when DevTools is available.

For example, the generators are designed around explicit application-owned components:

module:new Billing
    ↓
src/Modules/Billing/

plugin:new Cache
    ↓
src/Plugins/Cache/

Generated components are deliberately not auto-enabled.

Public package installation comes later.

Now the road toward Beta begins

Development has already moved beyond the Alpha tag.

Phase 8 — Evolve Insight is now in progress. The current roadmap shows the Insight storage projection and in-memory store foundation completed, with the SQLite diagnostic store next. Insight is intended to become EvolvePHP's local diagnostic system: collectors, safe diagnostic storage, retention and eventually a Telescope-style dashboard with Evolve-specific architecture and leak diagnostics.

Then comes Phase 9 — Evolve Observe and OpenTelemetry.

This takes a different role from Insight. Observe is intended for production observability: standard traces, metrics and structured logs, including context propagation across HTTP and background work.

Phase 10 — Infrastructure Contracts and Adapters moves EvolvePHP closer to practical application development by introducing replaceable contracts and initial adapters around databases, cache, sessions, queues, storage, locks, secrets and external clients.

A new Phase 10.5 — Views & Templating has also been added before reusable modules. The direction is a native PHP view engine with safe rendering, layouts, partials, shared data and module-aware view resolution, while keeping Twig or Blade optional rather than making either a framework-wide dependency.

One clarification to my earlier roadmap wording: Phase 11 is currently targeted at 2.0 Stable rather than Beta.

Phase 11 will prove the module architecture with real first-party reusable capabilities: Audit Log, Webhooks and API Keys.

So the progression is becoming much clearer:

Alpha
Core + HTTP + Modules + Doctor + Audit + Bridge
        ↓
Beta
Insight + Observe + Infrastructure + Views
        ↓
Stable direction
Reusable modules + further production hardening

A milestone, not the finish line

There is still a lot to build.

The Alpha does not yet provide the complete concrete production web runtime. Public package installation is not ready. Production deployment and several runtime integrations remain ahead.

But Alpha 1 matters because EvolvePHP has crossed an important line.

It is no longer only an architecture I am describing.

There is now code behind the execution model, module system, modernization workflow, Bridge, diagnostics and developer experience.

And from here, the work becomes increasingly visible.

EvolvePHP 2.0.0-alpha.1 is the first checkpoint.

Now we build toward Beta.

Microservices Are Not the Goal — Architectural Optionality Is

Microservices are often treated like the destination of a successful application.

Start with a monolith.

Grow.

Split into services.

Become “modern.”

I think that framing is backwards.

Microservices are not the goal.

The goal is to build a system that can change without forcing the business into a rewrite every time the architecture needs to evolve.

That is what I mean by architectural optionality.

A distributed system is not automatically a better system.

There are good reasons to use microservices:

• independent scaling,

• independent deployment,

• separate security boundaries,

• different team ownership,

• different runtime needs,

• different release cycles.

But distribution also introduces new problems:

network failures
timeouts
retries
idempotency
message delivery
service discovery
versioning
distributed tracing
data ownership
eventual consistency
operational complexity

Those costs may absolutely be worth it.

But they should be accepted because they solve a real problem, not because the system reached a certain size.

Scaling does not automatically mean microservices

A common assumption is:

More traffic
    ↓
Microservices

But traffic alone is not enough.

A well-designed monolith can handle a lot.

You can scale application instances horizontally.

You can introduce queues.

You can move files to object storage.

You can add caching.

You can optimize expensive operations.

You can improve database design.

None of those require turning every business capability into a separate service.

A better question is:

Which part of the system actually benefits from independent deployment?

That is much more useful.

Start with boundaries

Suppose an application has:

Customers
Orders
Billing
Reporting
Notifications

If all of those areas share everything freely, extracting Billing later will be painful.

But if they already have clear boundaries and explicit dependencies, you have options.

Billing can remain inside the monolith.

Or later it can move behind HTTP, a queue, RPC, or events.

That is the difference between:

“We need microservices.”

and:

“We can extract this capability if the evidence says we should.”

The modular monolith preserves choice

This is one reason I think the modular monolith is still underrated.

A good modular monolith gives you many of the architectural benefits people want from microservices:

• clear ownership,

• explicit dependencies,

• isolated business capabilities,

• testable boundaries,

• easier reasoning,

• replaceable implementations.

But you still deploy one application.

You still have local calls.

You still have one operational surface.

That keeps the system simpler while preserving the option to distribute later.

Extraction should happen because something changed

Imagine Billing suddenly needs to process ten times more work than the rest of the application.

Or a separate payments team takes ownership.

Or regulatory requirements demand stronger isolation.

Or Billing needs a deployment schedule that cannot be tied to the rest of the platform.

Now extraction has a reason.

Modular Monolith

Customers
Orders
Billing
Reporting
Notifications

        ↓

Customers
Orders       ──────> Billing Service
Reporting
Notifications

The architectural boundary already existed.

The deployment boundary changed.

That is healthier than starting with five services because you think the company might grow.

Optionality also applies to language choice

Suppose most of the system is PHP.

Later, one capability develops requirements that strongly favor Go or Rust.

Maybe it is CPU intensive.

Maybe it has a very different concurrency profile.

Maybe another ecosystem has better tooling for that workload.

If the architecture has good boundaries, you should be able to make that choice locally.

PHP Application
      |
      +---- Orders
      +---- Customers
      +---- Reporting
      |
      +---- High-throughput Worker → Go

That does not mean PHP failed.

It means the architecture allowed the team to choose the right tool without rewriting everything else.

Reversibility matters

One thing I increasingly value in architecture is reversibility.

How expensive is it to change your mind?

If choosing a framework, database, deployment model, or integration pattern creates a ten-year commitment, that decision deserves scrutiny.

Sometimes that commitment is necessary.

But where possible, I would rather preserve choices.

That does not mean abstracting everything.

Over-abstraction creates its own problems.

It means putting boundaries where the business already has meaningful boundaries and avoiding unnecessary coupling between them.

This influences EvolvePHP

A major design goal behind EvolvePHP is not:

“Make building microservices easy.”

It is closer to:

Build modular applications now, and make selective extraction possible later.

That is why explicit contracts, component boundaries, execution isolation, interoperability, and modernization matter so much.

A new EvolvePHP application should not need to begin as a distributed system.

The preferred path is:

Modular Monolith
       ↓
Observe actual pressure
       ↓
Identify the affected capability
       ↓
Extract only when justified

The same idea applies to existing systems.

Modernization should create options rather than simply replacing one form of lock-in with another.

The real goal

Microservices are useful.

So are monoliths.

So are queues, workers, serverless functions, and separately deployed services.

None of them should become an ideology.

The better question is:

Can our architecture support the deployment model we need when we actually need it?

That is architectural optionality.

And for long-lived software, I think that is more valuable than choosing the architecture that looks most advanced today.

Microservices are one possible destination.

The real goal is preserving the ability to choose.

Long-Running PHP with EvolvePHP: Designing for Safe Reuse

Long-running PHP is usually introduced as a performance story.

Boot the application once.

Keep the process alive.

Handle many requests or jobs.

Avoid repeating expensive initialization.

That can absolutely improve performance.

But while working on EvolvePHP 2, I have become more interested in a different problem:

How do you know the process is still safe to reuse?

That question changes how I think about persistent PHP.

Because keeping a process alive is easy.

Keeping it clean between executions is harder.

Traditional PHP gives you an automatic reset

With the classic request-per-process model, application state has a natural ending.

A request arrives.

PHP runs.

A response is produced.

The request ends.

Conceptually:

Start
  ↓
Boot
  ↓
Handle Request
  ↓
Response
  ↓
Process ends

Anything accidentally left in memory disappears with the process.

That is surprisingly useful.

Now imagine the process stays alive:

Boot
 ↓
Request A
 ↓
Request B
 ↓
Request C
 ↓
Request D
 ↓
...

Suddenly, state from Request A can potentially affect Request B.

The runtime has stopped giving us a clean slate automatically.

We have to create one ourselves.

The dangerous state is often ordinary state

Consider something simple:

final class TenantContext
{
    public static ?string $tenantId = null;
}

Request A sets:

tenantId = company-a

The request finishes.

Request B belongs to:

company-b

But if that static value was not reset correctly, we have a much more serious problem than a memory leak.

We have an isolation failure.

The same concern applies to:

• authenticated users,

• tenant context,

• database transactions,

• request caches,

• listeners,

• authorization state,

• telemetry context,

• temporary resources.

Long-running PHP turns lifecycle management into part of correctness.

EvolvePHP uses explicit execution boundaries

This is why EvolvePHP 2 does not model everything around an HTTP request.

The lower-level concept is an execution.

An execution might eventually represent:

HTTP request
Queue message
Scheduled job
CLI command
Worker task

The important part is that each unit of work gets a clear lifetime.

The model I am using is broadly:

Application
    │
    ├── Execution A
    │
    ├── Execution B
    │
    └── Execution C

The application may survive.

The execution must not.

That distinction is fundamental.

Service lifetimes need to match reality

EvolvePHP currently distinguishes three service lifetimes:

Application
Execution
Transient

Application services may survive across many executions.

Execution services belong to one unit of work.

Transient services are created when requested and are not cached.

This allows the container to reason about lifetime relationships instead of treating every dependency as equivalent.

For example:

Application-scoped service
        ↓
Execution-scoped CurrentUser

is dangerous.

The application service could capture a user belonging to one execution and retain it into another.

That relationship should not quietly succeed.

This is one of the areas where dependency injection becomes more than convenience.

It becomes a safety boundary.

Cleanup needs to be deterministic

At the end of an execution, EvolvePHP closes the execution scope.

Services that explicitly participate in reset can be cleaned up in a deterministic order.

Conceptually:

Execution starts
      ↓
Services created
      ↓
Operation runs
      ↓
Reset participants
      ↓
Scope closes

The important word here is explicitly.

I do not think a framework should pretend it can magically identify every piece of state that needs resetting.

Services that own reusable state need a clear cleanup contract.

And cleanup needs to happen even when the operation itself fails.

What if cleanup fails?

This was one of the questions that influenced the runtime architecture heavily.

Suppose the business operation succeeds:

Payment processed successfully

but during cleanup:

TenantContext reset fails

What is the result?

The payment still succeeded.

We should not rewrite history and pretend that it failed.

But can we safely reuse the PHP process?

Probably not.

That is why EvolvePHP separates two questions:

Did the operation succeed?

Is the process safe to reuse?

They are not the same question.

An execution outcome can preserve the original result or exception separately from cleanup failure.

Then the runtime can make an explicit reuse decision.

Conceptually:

Handler succeeds
Cleanup succeeds
        ↓
      REUSE

but:

Handler succeeds
Cleanup fails
        ↓
    QUARANTINE

The process is treated as uncertain.

The safe response is not:

“Hopefully the next request is fine.”

It is:

Do not give this process more work.

Quarantine is deliberately fail-closed

I like this model because it avoids pretending we know more than we do.

If cleanup failed, the framework may not be able to prove exactly what state remains.

So rather than attempting clever recovery inside Core, the result says that process reuse is unsafe.

A runtime adapter can later decide whether that means:

stop accepting work
finish current response
restart worker
replace process

That operational policy belongs to the runtime.

The framework's job is to expose the truth.

This also changes error handling

A long-running runtime can have four interesting outcomes:

Operation success + cleanup success
Operation failure + cleanup success
Operation success + cleanup failure
Operation failure + cleanup failure

The first two may still leave the process reusable.

The last two should not.

That is quite different from saying:

exception = bad
no exception = good

Runtime safety requires more information than that.

EvolvePHP is not claiming complete persistent-runtime support yet

There is an important limitation here.

EvolvePHP 2 already has the execution-scope, cleanup and reuse/quarantine foundations.

But the broader persistent-runtime work is still ahead.

Concrete integration with runtimes such as FrankenPHP and later RoadRunner, stronger persistent-worker validation, concurrency abstractions and production runtime adapters belong to later development.

So I would not currently describe EvolvePHP as a finished persistent PHP platform.

The architecture is being prepared for that future.

That distinction matters.

Long-running PHP is not just about speed

I think this is the biggest lesson.

Persistent execution can make PHP faster.

But once the process survives the request, performance becomes only one part of the engineering problem.

You also need to think about:

Lifetime
Isolation
Cleanup
Ownership
Failure
Observability
Reuse

Because a process that handles 10,000 requests quickly is not impressive if request 9,427 sees state belonging to request 9,426.

The real goal is not:

Keep PHP alive as long as possible.

It is:

Keep PHP alive only while we still have evidence that the process is safe to reuse.

That is the direction I want EvolvePHP's long-running runtime model to take.

Evolving PHP: The Language Is Changing, and So Is the Way We Build With It

 

For a long time, PHP had a very clear operating model.

A request comes in.

PHP starts.

The application runs.

A response goes out.

The process ends.

That model shaped a lot of how PHP applications were designed.

State could live in convenient places because the process was short-lived.

Global variables were less dangerous than they would be in a long-running process.

Memory leaks were often masked by process termination.

Cleanup was less visible because the runtime effectively cleaned everything up for you.

That model worked very well.

But PHP is evolving.

And the way we design PHP applications needs to evolve with it.

PHP is no longer only a request-per-process language

The traditional PHP-FPM model is still valid and useful.

But it is no longer the only serious way to run PHP.

Today, PHP can also run in long-lived workers, application servers, queue consumers, schedulers, event-driven processes, and persistent runtimes.

That changes something fundamental.

The application may now live for:

1 request
100 requests
10,000 requests
or hours of continuous work

That means old assumptions become more important.

What happens to request-specific state after the request finishes?

What happens to the current user?

The current tenant?

The database transaction?

Listeners?

Caches?

Telemetry context?

Temporary services?

A process that does not terminate forces us to answer questions that the traditional runtime often answered for us.

Performance is only part of the story

Persistent PHP is often discussed as a performance topic.

And performance does matter.

Booting the application once and reusing it can reduce repeated initialization work.

But I think the more interesting question is not:

“How much faster can PHP become?”

It is:

“What architectural assumptions change when the process survives?”

That is a much bigger question.

A persistent process can expose bugs that were previously hidden.

For example:

class UserContext
{
    public static ?int $currentUserId = null;
}

In a traditional short-lived request, this may appear harmless.

In a reused process, the next request may inherit stale state if cleanup is incomplete.

Now the problem is not performance.

It is isolation.

Dependency injection becomes more serious

Dependency injection is usually introduced as a way to improve testability and reduce coupling.

That is true.

But in long-running applications, it also becomes a lifetime problem.

Suppose an application-scoped service depends on a request-scoped service.

Conceptually:

Application Service
        ↓
Current User

If the application service lives for hours while the current user should live for one request, the lifetime relationship is wrong.

The container should not simply allow that because the types happen to match.

This is where service lifetimes start to matter much more:

Application
Execution
Transient

Application services can live across many executions.

Execution services belong to one request, job, or command.

Transient services are created when needed.

The relationship between them becomes part of application safety.

Cleanup becomes part of correctness

In short-lived PHP, process termination often acts as cleanup.

In a persistent runtime, cleanup needs to become explicit.

Imagine this flow:

Request starts
    ↓
User state created
    ↓
Transaction opened
    ↓
Telemetry context created
    ↓
Handler runs
    ↓
Cleanup begins

If cleanup succeeds, the process may be safe to reuse.

But what if cleanup fails?

That question does not get enough attention.

A framework should not simply assume:

“The request is over, continue.”

If the state of the process is uncertain, reusing that process can be dangerous.

Sometimes the correct answer is:

Do not reuse it.

That is a runtime safety decision, not just an error-handling decision.

Observability becomes more valuable too

Long-running systems are harder to understand when something goes wrong.

You may need to know:

• which execution created the state,

• which service failed to reset,

• whether cleanup completed,

• whether the process was reused,

• what happened before a failure,

• whether tenant or user context leaked.

Logs alone may not always be enough.

This is one reason I think observability needs to be designed into modern application architecture rather than added after problems appear.

Tracing, metrics, execution context, structured events, and failure evidence become more useful as runtime complexity increases.

PHP is also becoming more attractive for different workloads

The ecosystem is gradually making PHP viable for workloads that were traditionally pushed immediately toward other languages.

That does not mean PHP should replace everything.

Go, Rust, Java, and other languages remain excellent choices depending on the problem.

But PHP applications no longer need to assume:

“If this runs continuously, it must be rewritten in another language.”

Sometimes the correct answer may still be another language.

But it should be an architectural decision, not an automatic one.

If a PHP application can safely handle a workload with acceptable performance and operational behavior, there is value in keeping the system simpler.

Framework design needs to catch up

This is the part that interests me most.

A framework designed only around short-lived requests can still run in a persistent environment.

But that does not mean it was designed for one.

I think modern PHP frameworks increasingly need to think about:

• explicit service lifetimes,

• execution isolation,

• deterministic cleanup,

• stale-state prevention,

• runtime reuse decisions,

• observability boundaries,

• worker safety,

• concurrency assumptions,

• graceful failure.

These concerns should not be hidden inside runtime adapters.

They should influence the framework architecture itself.

This is influencing EvolvePHP

A lot of the EvolvePHP 2 architecture has been shaped by this idea.

The runtime model is not limited to HTTP requests.

An execution might be:

HTTP request
Queue message
Scheduled job
CLI command
Worker task

Each execution gets its own scope.

Execution-specific state should not silently become application-global state.

Cleanup is explicit.

Cleanup failures remain visible.

And if execution cleanup leaves the process in an uncertain condition, the runtime can decide that the process should not be reused.

My goal is not to make PHP look like Java or Go.

I acknowledge that PHP itself is changing.

And frameworks should evolve with it.

PHP’s future is not just faster PHP

When people talk about the future of PHP, the conversation often focuses on syntax, JIT, benchmarks, or framework performance.

Those things matter.

But I think the deeper evolution is architectural.

PHP is moving into environments where processes live longer, workloads are broader, infrastructure is more distributed, and operational expectations are higher.

That means application design has to become more deliberate.

The old request-per-process model hid a lot of complexity.

Persistent runtimes expose it.

And that is not necessarily a bad thing.

It gives us a chance to build systems with clearer boundaries, stronger isolation, better observability, and more predictable behavior.

PHP is evolving.

The interesting question now is whether our application architecture evolves with it.

Migrating Legacy PHP Applications to Modern Frameworks: What Actually Changes?

Migrating a legacy PHP application to a modern framework can look deceptively simple from the outside.

You have an old application.

You choose Laravel, Symfony, or another modern framework.

You move the routes, controllers, models, and views.

Done.

Except that is rarely what really happens.

The difficult part of framework migration is not translating syntax.

It is deciding which old assumptions should survive and which ones should not.

That distinction matters because it is entirely possible to move a legacy application into a modern framework and still end up with a legacy system.

A newer framework does not automatically create a newer architecture

Imagine an old application with this structure:

index.php
includes/
functions.php
database.php
users.php
orders.php
payments.php
reports.php

Everything talks directly to everything else.

Business rules are mixed with SQL.

Authentication depends on session globals.

A migration begins.

Months later, the application looks like:

Controllers/
Models/
Services/
Repositories/
Middleware/

That certainly looks more modern.

But suppose the new OrderService still directly updates customer, inventory, payment, and reporting tables.

The folders changed.

The coupling did not.

This is one of the biggest risks in framework migration:

We can modernize the shape of the code without modernizing the architecture.

Start by understanding why you are migrating

Before choosing a destination framework, I think teams should be able to answer:

What problem are we actually trying to solve?

Maybe the current framework no longer supports modern PHP.

Maybe dependencies are abandoned.

Maybe security updates have stopped.

Maybe it is difficult to hire developers who understand the stack.

Maybe the codebase has become hard to test.

Maybe deployments are fragile.

Those are good reasons to modernize.

But each one may lead to a different migration plan.

If the main problem is PHP compatibility, a framework upgrade may be enough.

If the main problem is architectural coupling, changing frameworks without changing boundaries may achieve very little.

Laravel may be the right answer

For many PHP applications, Laravel is a sensible destination.

It has a large ecosystem, good developer experience, strong community support, familiar conventions, and plenty of available developers.

If the goal is to move an application from an unsupported custom framework into a widely understood PHP stack, Laravel can reduce a lot of organizational risk.

The same is true for Symfony in environments that value stronger componentization, explicit architecture, and long-term enterprise use.

There is nothing wrong with choosing a mature framework.

The mistake is assuming the framework will make every architectural decision for you.

It will not.

Migration can happen gradually

A framework migration does not always need a single cutover date.

Suppose an application contains:

Customers
Orders
Billing
Reporting
Notifications

Maybe Reporting is reasonably independent.

Instead of rebuilding all five capabilities before launch, you could move Reporting first.

Conceptually:

Legacy Application
├── Customers
├── Orders
├── Billing
└── Notifications

        |
        v

Modern Reporting

Then observe it.

Run it in production.

Learn from the migration.

Only then decide what should move next.

This is often less exciting than a full rewrite.

It is also usually easier to control.

Data ownership matters more than controllers

One of the hardest parts of any framework migration is deciding who owns the data during the transition.

If both the legacy application and the new application can modify the same business state, things get complicated quickly.

Imagine both systems can create or update invoices.

Now you need to answer:

• Which system is authoritative?

• What happens if one succeeds and the other fails?

• How do you reconcile differences?

• Can one system understand records created by the other?

• What happens during rollback?

A cleaner migration usually has explicit ownership.

For example:

Legacy owns Orders
New system owns Reporting

Later that ownership can change.

But it should change deliberately.

Authentication can become another hidden trap

Legacy applications often have years of authentication and authorization behavior embedded in them.

Moving login forms is easy.

Preserving the actual security model is harder.

You need to understand:

• how identities are stored,

• how sessions work,

• how passwords are handled,

• how permissions are calculated,

• whether other systems depend on the same authentication state.

A migration should not accidentally weaken authorization simply because the new framework provides a nicer authentication API.

Identity and authorization deserve their own migration plan.

Tests make migration much safer

If the existing application has poor test coverage, I would not necessarily stop everything and attempt complete coverage first.

Instead, protect the behavior you are about to move.

Suppose you are migrating Billing.

Capture the important Billing behavior:

normal payment
failed payment
refund
duplicate request
discount
tax calculation
historical customer case

Then migrate against that behavior.

The tests become a record of what the old system actually does rather than what everyone thinks it does.

That is incredibly valuable in legacy modernization.

Where EvolvePHP fits into my thinking

While building EvolvePHP 2, I have been thinking about framework migration slightly differently.

I do not want adopting EvolvePHP to require the assumption:

“Eventually everything must become EvolvePHP.”

My direction is closer to:

Modernize the capabilities that benefit from moving, and allow the rest of the system to keep working.

That means coexistence matters.

Clear boundaries matter.

Data ownership matters.

Rollback matters.

And interoperability with existing PHP applications matters.

But it is influencing the architecture from the beginning.

Because I think frameworks should help applications evolve—not force businesses into another all-or-nothing rewrite.

Choosing the framework is only one decision

When somebody asks:

“Should we migrate this legacy application to Laravel or Symfony?”

my answer would usually begin with more questions.

What is wrong with the existing system?

Which capabilities change frequently?

Where is the data ownership?

What can be migrated independently?

What must remain available throughout the migration?

How will you roll back?

Only after those questions does framework choice become really useful.

Because my goal is not simply:

Move old PHP into a new framework.

My goal is:

Make the application safer, easier to understand, easier to operate, and easier to change for the next several years.

A modern framework can help enormously with that.

But the real modernization happens in the decisions you make while moving there, and not in the framework name at the end.

Modernizing Legacy PHP Applications Using EvolvePHP

Modernizing an old PHP application sounds straightforward until you actually open the codebase.

You may find an old framework, unsupported PHP version, direct SQL everywhere, global state, fragile authentication, outdated packages, and years of business logic spread across controllers, cron jobs, helpers, templates and database procedures.

At that point, the usual instinct is:

“We need to move this to something modern.”

But that still leaves the hardest question unanswered:

How do we modernize without breaking the business that already depends on it?

That is one of the problems I want EvolvePHP to help solve.

Not by converting an entire application automatically.

Not by pretending migration is easy.

But by helping teams understand the system, create boundaries, and move one capability at a time.

Modernization should begin with diagnosis

Before changing architecture, I think the first task should be understanding what actually exists.

A legacy application may have problems such as:

• unsupported PHP versions,

• abandoned Composer packages,

• hidden global state,

• direct access to superglobals,

• static service state,

• weak test coverage,

• tightly coupled database access,

• unsafe persistent-worker assumptions,

• unclear module boundaries.

You cannot make a good modernization plan if you do not know where those risks are.

That is the role I see for Evolve Audit.

Conceptually:

Legacy PHP Application
        ↓
    Evolve Audit
        ↓
Architecture and modernization report

Audit should help answer questions like:

• What framework is this application using?

• Which dependencies are obsolete?

• Where is state being shared?

• What parts of the application are highly coupled?

• Which capabilities look like natural module boundaries?

• Which areas are likely to be dangerous to migrate first?

The goal is not to produce a score saying:

“Your application is bad.”

The goal is to give the team enough information to make better decisions.

Then check whether the environment is ready

Architecture is only part of the problem.

Modernization can also fail because the runtime itself is not ready.

Maybe required PHP extensions are missing.

Maybe filesystem permissions are wrong.

Maybe a package combination cannot coexist.

Maybe the application holds execution-specific state in static properties.

That is where Evolve Doctor fits.

Think of it as a runtime and operational readiness check.

Audit
  ↓
Doctor
  ↓
Can we safely introduce this modernization step?

Audit tells you what you have.

Doctor tells you whether the environment and runtime assumptions are safe enough for the next step.

The next question is ownership

Suppose Audit reveals that Reporting is relatively isolated while Billing is deeply connected to Orders, Customers and several payment providers.

It may be tempting to modernize Billing because it causes the most pain.

But that does not necessarily make it the best first candidate.

A safer first move may be Reporting.

For example:

Legacy Application
├── Customers
├── Orders
├── Billing
├── Reporting
└── Notifications

could gradually become:

Legacy Application
├── Customers
├── Orders
├── Billing
└── Notifications

        |
        v

Evolve Reporting Module

The legacy application continues running.

Only one capability changes ownership.

That matters.

During modernization, there should always be a clear answer to:

Which system owns this operation right now?

Ambiguous ownership is where incremental migration becomes dangerous.

This is where Evolve Bridge comes in

Evolve Bridge is not intended to be a code converter.

It is an integration boundary.

The old system might be Laravel, Symfony, CodeIgniter, CakePHP, Yii or something completely custom.

The new capability might run inside the same process when dependencies are compatible.

Or it might run remotely when stronger isolation is needed.

Conceptually:

Legacy PHP
    |
    | delegated operation
    v
Evolve Bridge
    |
    v
Evolve Module

or:

Legacy PHP
    |
    | HTTP / Queue / Event
    v
Evolve Service

The integration mechanism can vary.

The principle stays the same:

Modernize one capability without requiring the rest of the application to move.

The database usually becomes the hardest part

Code can be reorganized relatively easily.

Data ownership is more difficult.

If the new Reporting module only reads legacy data, the transition may be straightforward.

If Billing is being migrated, things become more serious.

Who writes invoices?

Who owns payment state?

Can both systems modify the same tables?

What happens if the new system succeeds but the old system times out?

A modernization plan needs explicit data ownership.

I would rather begin with:

Legacy owns data
Evolve reads through adapter

and move deliberately from there than allow two systems to write the same business state without clear rules.

Rollback should be part of the plan

A migration is not complete simply because traffic can move forward.

You also need to know what happens if it fails.

Before cutover, I would want to know:

• Can traffic return to the legacy capability?

• Has the new system changed data the old system cannot understand?

• Can we identify which version processed an operation?

• Can we compare behavior between both implementations?

• What evidence tells us the migration is safe?

That is one reason I think modernization should happen in small steps.

Small steps are easier to observe and easier to reverse.

Not everything needs to become EvolvePHP

This is important.

If Customers works well, keep it.

If an old Reporting module is reliable and rarely changes, perhaps it stays too.

The goal should not be:

“How much of this application can we move to EvolvePHP?”

The better question is:

“Which parts benefit enough from modernization to justify moving them?”

Sometimes the answer will eventually be most of the application.

Sometimes it may only be one or two capabilities.

Both outcomes can be successful.

The wider direction

The modernization flow I am building toward looks roughly like this:

Audit
  ↓
Doctor
  ↓
Adoption Plan
  ↓
Bridge
  ↓
Modernize
  ↓
Validate
  ↓
Upgrade Confidence

Each stage reduces a different kind of uncertainty.

That is the part of EvolvePHP I find increasingly important.

Frameworks are usually very good at helping developers start new applications.

But there is an enormous amount of PHP software already running businesses today.

Those systems need somewhere to go too.

I do not think the answer should always be:

“Rewrite it in a new framework.”

Sometimes the better answer is:

Understand what you have. Create a safe boundary. Move one capability. Prove it works. Then decide whether anything else needs to move.

That is the modernization path I want EvolvePHP to make practical.

Modernizing Legacy PHP Applications: Pros and Cons

Modernizing a legacy PHP application usually sounds like an obvious win.

Newer PHP version.

Supported dependencies.

Better architecture.

Cleaner code.

Improved security.

Easier deployment.

All of that sounds good.

But modernization is not free.

Every improvement comes with cost, risk, and disruption.

That is why I think the useful question is not:

“Should we modernize?”

It is:

“What do we gain, what do we risk, and what is worth changing first?”

That balance matters.

The obvious benefit: supported technology

One of the strongest reasons to modernize is simply getting back onto supported software.

A legacy system might be running:

PHP 7.x
Old framework
Abandoned packages
Unsupported libraries

That creates risk.

Security fixes stop.

New infrastructure becomes harder to adopt.

Developers spend more time working around compatibility problems.

Moving to supported versions can immediately improve the situation.

This is often modernization at its most practical.

No dramatic architecture change required.

Just reducing unnecessary exposure.

Modernization can improve security

Old applications often carry years of assumptions that no longer fit modern security expectations.

You may find:

• outdated password handling,

• unsafe session settings,

• old authentication flows,

• weak dependency hygiene,

• direct SQL construction,

• unvalidated redirects,

• inconsistent authorization,

• insecure file handling.

Modernization creates an opportunity to review those areas properly.

But this needs an important caveat.

New code is not automatically secure code.

A rewrite can introduce fresh vulnerabilities just as easily as old code can retain them.

Security improves when modernization includes deliberate review, testing, safer defaults, and better architecture.

Not simply because the framework version changed.

Maintainability can improve dramatically

One of the biggest wins is making the application easier to understand.

A legacy system might have business rules scattered across:

controllers
helpers
models
templates
cron scripts
random utility classes

Modernization can introduce clearer boundaries.

For example:

Customers
Orders
Billing
Reporting
Notifications

Now developers can understand where functionality belongs.

That can reduce the fear around changing the codebase.

And when developers are less afraid of the system, delivery speed usually improves.

Testing gets easier

Legacy applications often have weak test coverage because the architecture was not designed for testing.

Everything may depend on:

globals
static methods
database state
framework internals
shared mutable state

Refactoring toward explicit dependencies and better boundaries can make testing much easier.

That matters because modernization itself is risky.

Tests help answer:

Did we preserve the behavior that already mattered?

Sometimes the most valuable thing modernization gives you is not cleaner code.

It is confidence.

Modern infrastructure becomes possible

Older applications can become trapped by their runtime assumptions.

They may expect:

• one server,

• local filesystem storage,

• manually configured cron jobs,

• state stored in memory,

• no structured telemetry,

• deployment through file uploads.

Modernizing can open the door to:

containers
horizontal scaling
object storage
queues
workers
centralized logs
OpenTelemetry
automated deployment

But not every application needs all of those.

Modern infrastructure should solve real operational problems.

Otherwise we are replacing one form of complexity with another.

---

The other side: modernization has real costs

This is the part that gets less attention.

You can break behavior nobody documented

Legacy systems accumulate hidden business knowledge.

You may discover code that looks completely unnecessary:

if customer_created_before_2019 ...

The natural instinct is to remove it.

Then three weeks later, a long-standing customer can no longer complete a transaction.

That strange condition may have existed for a reason.

Modernization often reveals how much of the business is encoded only in software.

That makes every “cleanup” decision potentially important.

The project can become much larger than expected

A modernization effort may begin with:

“Let’s upgrade PHP.”

Then you discover:

Framework cannot run on new PHP
        ↓
Framework upgrade required
        ↓
Old dependencies incompatible
        ↓
Authentication package abandoned
        ↓
Database layer changed
        ↓
Tests missing

Suddenly a runtime upgrade becomes an architecture project.

This is why I prefer auditing the system before setting timelines.

The visible problem is rarely the whole problem.

Dual systems create complexity

Incremental modernization reduces big-bang risk, but it introduces another challenge.

For some period of time you may have:

Legacy system
      +
Modernized capability

Now you need clear answers around:

• routing,

• ownership,

• authentication,

• data,

• deployment,

• observability,

• rollback.

If both systems think they own the same business operation, things can get messy quickly.

Incremental modernization is safer only when boundaries are explicit.

Data migration can be more difficult than code migration

Developers naturally focus on source code.

But data is usually where modernization becomes serious.

Which system owns a record?

Can both systems write?

How do we migrate history?

What happens if migration fails halfway?

Can old and new schemas coexist?

Can we roll back after new writes have already happened?

The code may be replaceable.

The business history stored in the database is not.

There is also an opportunity cost

A team modernizing the platform is not building other things.

For six months, developers may be spending time on:

dependency upgrades
refactoring
migration scripts
test coverage
deployment changes

while competitors are shipping customer-facing features.

That does not mean modernization is wrong.

It means the business case needs to be real.

Technical discomfort alone may not justify a major project.

Developers also have to learn the new system

A newer architecture may be technically better and still slow the team down initially.

New concepts.

New tooling.

New deployment model.

New framework.

New conventions.

Modernization creates learning cost.

If the team is not prepared for that, productivity can temporarily fall before it improves.

---

So when is modernization worth it?

For me, the strongest case exists when the current system is actively limiting the business.

For example:

• security support is ending,

• upgrades are blocked,

• important features take too long,

• outages are becoming more common,

• deployment is risky,

• hiring is difficult,

• infrastructure cannot scale,

• critical knowledge is trapped in a few people.

Those are measurable problems.

They give modernization a purpose.

The best approach is rarely “modernize everything”

I prefer something more deliberate:

Understand
   ↓
Prioritize
   ↓
Protect behavior with tests
   ↓
Modernize the highest-value area
   ↓
Measure the result
   ↓
Continue only when justified

That keeps modernization connected to outcomes.

Not fashion.

Not architecture diagrams.

Not a desire to make every file look new.

The goal

is not newer code

This is probably the most important point.

Modernization succeeds when the application becomes:

• safer,

• easier to change,

• easier to operate,

• easier to understand,

• cheaper to maintain.

If the team spends a year rebuilding everything and ends up with the same delivery problems, the modernization failed even if the code looks beautiful.

Old software can absolutely need modernization.

But modernization itself also needs discipline.

The right question is not:

“How much of this legacy application can we replace?”

It is:

“Which changes give us enough long-term value to justify the risk of making them?”

That is where a good modernization strategy begins.

Modernizing Legacy Applications in PHP: Considerations and Approaches

 

Legacy PHP applications are everywhere.

Some are ten or fifteen years old. Some are running on unsupported PHP versions. Some use frameworks that are no longer maintained. Others were built without a framework at all.

And many of them are still doing real work every day.

That creates an uncomfortable situation.

The application needs to change, but changing it may be risky.

The temptation is usually to jump straight to a technical solution:

Upgrade PHP.
Move to Laravel.
Rewrite it.
Break it into microservices.

I think modernization should start somewhere else.

With understanding.

First, what does “legacy” actually mean?

Old software is not automatically bad software.

A PHP application written eight years ago may still be stable, understandable and inexpensive to maintain.

Meanwhile, a three-year-old application can already feel impossible to change.

For me, a system becomes a modernization problem when things like these start happening:

• supported PHP versions cannot be adopted;

• important dependencies are abandoned;

• security fixes become difficult;

• deployments are fragile;

• developers are afraid to change certain areas;

• business logic is tightly coupled;

• testing is weak or nonexistent;

• infrastructure cannot evolve;

• new features take increasingly longer to deliver.

Age is only one signal.

The real problem is the cost and risk of change.

Before touching the code, understand what you have

A mature application contains more than PHP files.

It contains business behavior.

It may integrate with:

Payment providers
Banks
Email/SMS services
Government APIs
CRMs
Accounting software
Legacy databases
File storage
Third-party services

Some integrations may not even be documented properly anymore.

Before modernization, I would want answers to questions such as:

• Which PHP and framework versions are running?

• Which dependencies are unsupported?

• Where does authentication happen?

• Which modules own important business data?

• Which external systems depend on this application?

• What are the most frequently changed areas?

• Which parts are considered dangerous to touch?

• What tests already exist?

• What must never break?

Modernization without that understanding can easily turn into archaeology during production incidents.

There is more than one modernization strategy

This is where I think teams sometimes make modernization harder than necessary.

There is no single correct approach.

1. Upgrade in place

Sometimes the best modernization project is simply:

PHP 7.x
   ↓
PHP 8.x

Old dependencies
   ↓
Supported dependencies

The application's architecture remains mostly unchanged.

That can still deliver major benefits:

• security support,

• performance improvements,

• modern tooling,

• easier hiring,

• access to maintained libraries.

Not every modernization project needs a new framework.

2. Refactor gradually

Another approach is to improve the existing application while it continues running.

For example:

Direct SQL
   ↓
Repository / persistence boundary

Global state
   ↓
Explicit dependencies

Large controller
   ↓
Application services

This can be slow, but it keeps changes small.

It also allows the team to learn about the application before making larger architectural decisions.

3. Establish module boundaries

A tightly coupled application may benefit from becoming a modular monolith before anything is extracted.

Perhaps the system currently looks like:

Application
   ↓
Everything depends on everything

The modernization target could be:

Application

├── Customers
├── Orders
├── Billing
├── Reporting
└── Notifications

Still one application.

Still one deployment.

But now responsibilities and dependencies are clearer.

That alone can make future modernization much easier.

4. Replace one capability

Sometimes one part of the application is causing most of the pain.

Maybe Reporting cannot scale.

Maybe Billing has become too risky to change.

Maybe a legacy authentication system needs replacing.

Instead of rebuilding everything:

Legacy Application
├── Customers
├── Orders
├── Billing
├── Reporting
└── Notifications

you might gradually reach:

Legacy Application
├── Customers
├── Orders
├── Billing
└── Notifications

        |
        v

Modern Reporting Capability

The business keeps operating while one boundary evolves.

This is often much easier to control than a full replacement.

5. Rewrite

Yes, rewrites still belong on the list.

There are systems where replacement is genuinely the right choice.

For example:

• the application is relatively small;

• requirements are well understood;

• data migration is straightforward;

• the current technology cannot support future needs;

• maintaining the old code costs more than replacing it.

But a rewrite should be an evaluated option.

Not the default reaction to code we dislike.

Framework migration deserves the same caution

Moving from an old PHP framework to Laravel, Symfony or another modern framework can be valuable.

But framework migration does not automatically solve architecture problems.

If tightly coupled business logic is moved unchanged into a newer framework, you may end up with:

a modern framework containing a legacy architecture.

The syntax changed.

The underlying problem did not.

I think modernization should first identify business boundaries and ownership.

Framework choice comes after that.

Data usually determines how difficult the migration really is

Applications can often tolerate temporary duplication of code.

Data is much less forgiving.

Questions quickly appear:

• Which system is the source of truth?

• Can both old and new systems write?

• How are historical records handled?

• How do we validate migrated data?

• Can the migration be reversed?

• What happens during partial failure?

This is why I strongly prefer explicit ownership during incremental modernization.

At any point, somebody should be able to answer:

Which system owns this data and operation right now?

Ambiguous ownership creates very expensive bugs.

Testing changes the risk completely

Modernizing an application without tests is possible.

But every change carries much more uncertainty.

One practical strategy is not to attempt perfect test coverage first.

Start around the behavior you intend to change.

Capture what the legacy system currently does.

Then modernize against that evidence.

Tests become a safety net for discovering undocumented behavior.

Sometimes a test that exposes a strange legacy rule is more valuable than immediately “cleaning up” that rule.

Modernization should have a rollback story

Every migration plan naturally explains how to move forward.

Fewer explain how to move backward.

Before replacing a capability, I want to know:

How do we cut over?
How do we observe it?
How do we know it is working?
How do we return safely if it isn't?

If rollback is impossible, that risk should at least be explicit.

Modernization should reduce uncertainty, not hide it.

Start with the problem, not the destination

This is probably the principle I come back to most.

Don't begin with:

“How do we migrate this system to Framework X?”

Begin with:

“What prevents this application from changing safely?”

Maybe the answer is the framework.

Maybe it is PHP version compatibility.

Maybe it is database coupling.

Maybe it is missing tests.

Maybe it is deployment.

Maybe it is one badly designed subsystem.

Once that is clear, the modernization strategy becomes much easier to reason about.

Because modernization is not really about making old PHP look new.

It is about making a valuable application safer and cheaper to change.

And sometimes the best modernization decision is surprisingly small.

Secure by Default Is Not Enough — Frameworks Need Security Evidence

“Secure by default” sounds reassuring.

It is also something almost every serious framework wants to say.

Use parameterized queries. Set sensible cookie defaults. Escape output. Protect forms from CSRF. Make unsafe configuration harder.

All of that matters.

But while designing EvolvePHP 2, I have become increasingly uncomfortable with stopping there.

Because there is another question behind every security claim:

How do we know the protection actually holds?

That is where I think frameworks need to go further.

Not just secure defaults.

Security evidence.

A security claim is not the same as a security guarantee

Imagine a framework says:

“Request state is isolated between persistent-worker executions.”

That sounds good.

But what actually supports the claim?

Documentation?

A code comment?

A few unit tests?

Or have we repeatedly tried to make one execution leak into another?

The distinction matters.

For EvolvePHP, one of the architectural rules is that execution-specific state should not survive into the next execution.

That may include:

current user
current tenant
transaction context
authorization state
trace context
temporary listeners

If I claim those things are isolated, I want more than confidence in the implementation.

I want tests designed specifically to prove me wrong.

Tests should attack the assumptions

A normal test might do this:

Execution A starts
Execution A completes
Execution B starts
Execution B completes

Everything passes.

Great.

But an assurance test should be more hostile.

Execution A
User: Alice
Tenant: Company A
Handler: succeeds

Execution B
Anonymous
No tenant
Handler: throws

Execution C
User: Bob
Tenant: Company B
Cleanup: partially fails

Then ask:

• Can Bob see Alice's state?

• Does an anonymous execution inherit authentication?

• Is a transaction left open?

• Does trace context survive?

• Is the worker reused after cleanup becomes uncertain?

That is a different mindset.

The goal isn't only to show that the framework works.

It is to discover the conditions under which it stops being safe.

Some rules should be architectural invariants

There are certain things I would rather make difficult or impossible by design.

For example:

Application-scoped service
        ↓
Execution-scoped CurrentUser

That is a dangerous lifetime relationship in a long-running process.

Instead of documenting:

“Please don't do this.”

the container should reject it when possible.

Likewise, if cleanup fails, EvolvePHP should not quietly assume the worker is safe.

The rule should be:

Cleanup successful
→ reuse may continue

Cleanup failed or uncertain
→ quarantine

Then the test suite should continuously verify that no path accidentally turns cleanup failure into safe reuse.

These are the kinds of claims that can become measurable.

Unit tests are only the beginning

Traditional tests are necessary, but they are not enough for the kinds of guarantees I want EvolvePHP to eventually make.

Different problems need different kinds of pressure.

Property-based tests can generate many combinations of lifecycle state rather than testing only examples we thought of manually.

Fuzzing can feed unexpected input into parsers, routing, protocol boundaries, and other exposed surfaces.

Mutation testing can deliberately alter security-sensitive code and show whether our tests actually notice.

Fault injection can simulate database failures, reset failures, telemetry failures, timeouts, and partial cleanup.

Soak testing can run persistent workers through hundreds of thousands of executions while alternating users, tenants, successes, failures, and memory pressure.

The idea is not complexity for its own sake.

It is proportional evidence for important claims.

Security is bigger than the runtime

Execution isolation is only one part of security.

A PHP framework also has to think about familiar application risks:

• SQL injection

• XSS

• CSRF

• SSRF

• broken authorization

• insecure sessions

• unsafe redirects

• secrets exposure

• file and path handling

• dependency vulnerabilities

• insecure defaults

I don't want EvolvePHP to invent its own definition of application security.

That is why the direction includes alignment with established security references such as OWASP ASVS and secure-development practices such as NIST SSDF.

Not so I can put a badge on the website.

But so there is a recognized baseline asking:

What security requirements apply here?

and:

What evidence do we have that we followed them?

Framework security and application security are different

This distinction is important.

Even a well-designed framework cannot guarantee that every application built with it is secure.

A developer can still make an authorization mistake.

A company can expose a secret.

A deployment can be misconfigured.

A custom plugin can introduce a vulnerability.

So I do not want EvolvePHP to eventually claim:

“Applications built with EvolvePHP are secure.”

That would be irresponsible.

A better goal is:

EvolvePHP should provide safe defaults, enforce important boundaries where possible, expose insecure conditions, and make security verification easier for application teams.

That is a much more defensible promise.

“Secure by default” should be the starting point

I still want secure defaults.

Developers should not need to be security specialists just to get sensible behavior.

But defaults alone are not enough for software that may eventually run financial systems, SaaS platforms, government applications, or other long-lived business systems.

The stronger question is:

Can we show why we believe this behavior is safe?

That is the direction I want EvolvePHP to move toward.

Not:

“Trust us. We designed it securely.”

But:

These are our security and safety claims. These are the boundaries. And here is the evidence continuously trying to prove those claims wrong.

For me, that is a much stronger foundation for trust.

Dependency Injection Is Easy Until the Process Lives Forever

Dependency injection feels simple when the application process is short-lived.

A request comes in.

The framework resolves a few services.

The request finishes.

Then everything disappears.

Under that model, a lot of lifetime mistakes are easy to miss.

But persistent PHP workers change the rules.

Once the same application process handles multiple requests, jobs, or messages, dependency injection stops being only about convenience.

It becomes part of runtime safety.

That is one of the reasons EvolvePHP 2 treats service lifetimes as an architectural concern rather than a container feature.

The easy version of dependency injection

In a typical application, we might have something like:

final class BillingService
{
    public function __construct(
        private PaymentGateway $gateway
    ) {}
}

That is straightforward.

The container creates BillingService, injects PaymentGateway, and the application uses it.

Most developers understand this part.

The harder question is:

How long should each of those objects live?

That question becomes much more important when the PHP process itself stays alive.

Imagine the application boots once

A persistent worker might look like this:

Application boots
      ↓
Request A
      ↓
Request B
      ↓
Request C
      ↓
Request D

Now imagine we have a service created during application boot:

BillingService
Lifetime: Application

And BillingService depends on:

CurrentUser
Lifetime: Request

Conceptually:

Application-scoped BillingService
            ↓
Execution-scoped CurrentUser

That relationship is dangerous.

Why?

Because BillingService may live for hours.

CurrentUser should live for one request.

If the long-lived service captures the short-lived object, the user from Request A can remain reachable during Request B.

This is called a captive dependency

The general problem is often known as a captive dependency.

A longer-lived service captures a dependency with a shorter lifetime.

For example:

Application
    ↓
Execution

or:

Singleton
    ↓
Request-specific state

In a disposable request model, the process may end before this becomes visible.

In a persistent worker, it can turn into:

Request A
User: Alice
     ↓
BillingService retains Alice
     ↓
Request B
User: Bob
     ↓
BillingService still references Alice

That can become more than a bug.

If the state involves users, tenants, authorization, transactions, or sensitive data, it becomes a security problem.

This is why lifetimes need names

For EvolvePHP 2, I am working around three basic lifetimes:

Application
Execution
Transient

Application

Lives as long as the booted application.

Good candidates might include:

• immutable configuration,

• route metadata,

• shared infrastructure,

• reusable stateless services.

Execution

Lives for one unit of work.

That could be:

• one HTTP request,

• one queue message,

• one scheduled job,

• one CLI operation,

• one worker task.

Typical execution state might include:

• current user,

• current tenant,

• request context,

• transaction context,

• trace context,

• authorization state.

Transient

Created when needed and not automatically shared.

This gives the container more information than:

“Can I build this object?”

It can also ask:

“Is this dependency relationship safe?”

Some dependencies should be rejected

Suppose the container sees:

ApplicationService
      ↓
CurrentTenant

and CurrentTenant is execution-scoped.

Instead of allowing it and hoping the developer resets everything correctly, I would rather the framework reject the relationship.

Something like:

Invalid lifetime dependency:

Application-scoped service
cannot directly depend on
Execution-scoped service.

That is much better than discovering the mistake through a cross-tenant production incident.

A framework should make unsafe architecture difficult.

The opposite direction is usually fine

This relationship makes much more sense:

Execution Service
       ↓
Application Service

For example:

CheckoutHandler
      ↓
PaymentGateway

The execution-scoped handler can safely depend on a long-lived, stateless payment gateway abstraction.

When the execution finishes, the handler disappears.

The shared service continues.

The important rule is that the shared service does not retain the execution-specific object.

Service locators can hide the problem

There is another pattern that makes lifetime issues harder to see:

$container->get(CurrentUser::class);

from anywhere in the application.

This can feel convenient.

But now dependencies become invisible.

A class may appear to have no dependency on current user state while secretly resolving it from a global container.

That makes architecture harder to reason about.

It also makes testing and persistent-worker safety harder.

I prefer explicit dependencies where practical.

A constructor tells us:

This service needs these things.

That gives both developers and tooling something concrete to inspect.

Factories do not automatically solve it

A common workaround is:

“Just inject a factory.”

Sometimes that is correct.

For example, an application-scoped service might receive a factory that creates an execution-specific object only during the active execution.

But the important part is still ownership.

The long-lived service must not keep the result beyond the execution.

Otherwise we have only hidden the captive dependency behind another abstraction.

Cleanup still matters

Correct lifetimes reduce risk, but some infrastructure still needs reset behavior.

A connection may retain transaction state.

A logger may carry execution context.

A telemetry system may hold baggage.

An event dispatcher may temporarily register execution-specific listeners.

So persistent execution still needs:

Execute
   ↓
Cleanup
   ↓
Reset
   ↓
Verify
   ↓
Reuse or Quarantine

Dependency lifetimes and cleanup work together.

Lifetimes prevent unsafe ownership.

Cleanup removes temporary state.

Both matter.

DI becomes architecture, not just plumbing

This is the bigger point.

In short-lived applications, dependency injection is often discussed as:

• easier testing,

• cleaner constructors,

• replacing implementations,

• avoiding manual object creation.

Those are useful benefits.

But in long-running PHP, DI also answers:

• who owns state,

• how long it survives,

• what may depend on what,

• whether process reuse is safe.

That changes its importance.

This influences EvolvePHP deeply

I do not want persistent-worker support to be something added after the framework is already designed.

If the container allows unsafe lifetime relationships from the beginning, adding RoadRunner or FrankenPHP later means auditing everything after the fact.

I would rather start with the safer model.

Ask every service:

What lifetime does this belong to?

Then enforce the rules around it.

Because persistent PHP does not just make applications faster by keeping them warm.

It also makes old assumptions about object lifetime visible.

And once the process lives forever, dependency injection is no longer just about how objects are created.

It is about making sure the wrong state does not live forever with them.