What the agent does
In a Laravel app like BookStackApp/BookStack, composer.json requires php ^8.3.0, laravel/framework ^v13.35.0, laravel/socialite ^5.10, league/commonmark ^2.3, dompdf/dompdf ^3.1, intervention/image ^3.5, onelogin/php-saml ^4.3.1, predis/predis ^3.2 and five socialiteproviders packages, among others. The dev side has phpunit/phpunit ^12.5.38, larastan/larastan ^v3.0, mockery, fakerphp/faker and squizlabs/php_codesniffer ^4.0.1. config.platform.php is set to 8.3.0, so Composer resolves for PHP 8.3 whatever PHP the machine runs. The agent keeps that setting, so the lockfile stays installable on the oldest PHP the project supports.
It runs composer outdated --direct to see what is behind, then composer update
BookStack's tests are mostly functional and need MySQL. phpunit.xml sets DB_CONNECTION to mysql_testing, and dev/docs/php-testing.md says it expects a database named bookstack-test on 127.0.0.1 with the user and password bookstack-test, or a TEST_DATABASE_URL, migrated and seeded with composer refresh-test-database. The agent installs MySQL in the sandbox, creates that database and user, runs refresh-test-database, then runs php artisan test after each update, plus composer check-static (phpstan through larastan) because a new framework version often changes return types.
An update that fails the tests or phpstan is reverted in composer.json and composer.lock. The agent keeps the failing test class and method, or the phpstan message with file and line, for the pull request. A new migration in a package is noted, since it changes the schema refresh-test-database builds.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "claude",
"input": "Upgrade this project's Composer dependencies to their latest compatible releases, keeping config.platform.php as it is. Update one package family at a time with composer update --with-dependencies. Set up MySQL with a bookstack-test database and user as dev/docs/php-testing.md describes and run composer refresh-test-database. After each update run php artisan test and composer check-static. Revert any update that fails either and record the failing test or phpstan error. Open one pull request listing each bump with its old and new version and each skipped upgrade with the error that blocked it.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
The pull request changes composer.json where a constraint had to rise and composer.lock for every update. The description lists each package with its old and new locked version, grouped by family, then each update held back with the failing test or phpstan message. If an update required a code change (a changed method signature, a renamed config key), it is listed separately with the files it touched.
This repository has no GitHub Actions workflow, so the pull request carries no CI checks of its own; the evidence is the test and phpstan output in the session transcript. A reviewer reads the Laravel release notes for the framework version, checks the SAML and OIDC login paths by hand if onelogin/php-saml or socialite moved a major, and merges.
Run it on every Monday morning
composer.lock only changes when someone runs composer update, and for a self-hosted app that sits behind for months unless something forces it. A scheduled job that sends this request each Monday keeps every week's update small enough to read.
Rush can call a webhook when the turn ends: set webhook_url on the API key, and your endpoint gets run.completed with the session_url to fetch the pull request from.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
A Laravel test run needs PHP with the right extensions (BookStack requires curl, dom, gd, mbstring, xml, zip and fileinfo), a MySQL server, a seeded test database and Composer, set up before the first test. In a Rush sandbox the agent builds that environment from the project's own docs and keeps every composer, artisan and phpunit command with its output, which matters most for a repository whose pull requests run no CI.
A bot that bumps laravel/framework alone can leave tinker or collision on an incompatible version. One run that moves families together and tests them gives one reviewable pull request a week, and several Laravel apps can run the same request at the same time.
Frequently asked questions
Does it need my production database?
No. The agent creates an empty MySQL test database in the sandbox and seeds it with the project's own test seeder. Nothing connects to your servers.
Will it upgrade PHP itself?
No. config.platform.php pins the PHP version Composer resolves for, and the agent leaves it. Raising the minimum PHP is a separate decision.
What if my app uses SQLite for tests?
Then the agent uses whatever phpunit.xml configures, and setup is simpler. It follows the test database settings the project already has.
Does it run Laravel Shift-style code changes for a major?
For a framework major it reads the upgrade guide and makes the small changes the tests point to. If the upgrade needs broad changes, it leaves the framework on its current major and explains what failed.