I built CarvePHP: finding service boundaries in Laravel monoliths

I built CarvePHP: finding service boundaries in Laravel monoliths

I recently released CarvePHP v0.1.2-alpha, an open-source Laravel package that helps teams analyze large Laravel monoliths and identify possible service boundaries.

The idea came from a common problem:

Moving from a monolith to services is not hard because creating a new service is hard.
It is hard because deciding what to extract and why is hard.

Most Laravel monoliths grow naturally over time. Routes, controllers, models, migrations, jobs, events, and database tables become connected in ways that are not always obvious from the folder structure.

CarvePHP tries to make those connections visible.

What CarvePHP does

CarvePHP combines static analysis and runtime tracing.

Current alpha features:

• scans Laravel routes, controllers, models, migrations, and database usage
• optionally traces real runtime route/table coupling
• builds a dependency graph
• suggests candidate service boundaries
• generates Markdown/JSON migration reports

It is not a “one-click microservices” tool.

That would be misleading.

The goal is to help developers make safer, more explainable migration decisions.

Example workflow

Install it with Composer:

composer require carvephp/carve:^0.1@alpha --dev

Then run:

php artisan carve:install
php artisan carve:doctor
php artisan carve:scan --pretty
php artisan carve:analyze
php artisan carve:boundaries --report=carve-boundaries.md
php artisan carve:report --output=carve-report.md

The output is a migration report showing possible boundaries, related routes/controllers/models/tables, coupling signals, and warnings.

Why static analysis is not enough

Static analysis can tell you what the code appears to depend on.

But real applications often behave differently at runtime.

For example:

• one route may touch multiple tables
• two tables may frequently appear together in the same request
• a controller may indirectly depend on a model through a service
• shared tables may make extraction risky

That is why CarvePHP supports optional runtime tracing.

Runtime tracing is disabled by default and is designed to be safe. It does not log request bodies or SQL bindings by default.

Example boundary idea

A report might suggest a boundary like:

Candidate: Billing

Tables:
- invoices
- payments
- customers

Evidence:
- invoice and payment routes touch related tables
- invoices and payments co-occur in runtime traces
- billing controllers and models are strongly connected

Risk:
- customers table may be shared with other areas

This does not mean “extract Billing automatically.”

It means:

“Here is a possible boundary, and here is the evidence behind it.”

That is the kind of information I would want before starting a real migration.

What it does not do yet

CarvePHP is still alpha.

It does not currently provide:

• automatic service extraction
• automatic database splitting
• production-ready migration orchestration
• guaranteed perfect boundaries

Those are hard problems and should not be hidden behind marketing language.

For now, CarvePHP is focused on analysis, visibility, and explainable reports.

Supported versions

Current alpha supports:

• PHP 8.2+
• Laravel 11, 12, and 13
• Composer 2.x

Links

GitHub:

https://github.com/Muhammad-Waleed-Khalil/CarvePHP

Packagist:

https://packagist.org/packages/carvephp/carve

Install:

composer require carvephp/carve:^0.1@alpha --dev

Feedback wanted

I am looking for feedback from Laravel/PHP developers who have worked with large monoliths.

A few questions:

• What evidence would you want before trusting a service boundary suggestion?
• Would graph visualization be useful?
• Should the next release focus more on FormRequest analysis, API Resource analysis, or better reporting?
• What Laravel patterns should the scanner support first?

Any feedback, criticism, or real-world edge cases would be appreciated.