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.
Top comments (0)