What the agent does
For an Express app like gothinkster/node-express-realworld-example-app, the agent begins by separating actual runtime settings from type definitions. package.json declares @types/node 18.16.9, Express ~4.18.1, Prisma ^4.16.1 and Nx 17.2.6. The Node type package does not establish which Node binary runs the app. This fixture has no .nvmrc, package.json engines field or tracked GitHub Actions workflow. Its Dockerfile uses docker.io/node:lts-alpine, a moving tag. The agent inventories those facts before proposing explicit Node 24 settings, rather than claiming to replace runtime pins that are absent.
The agent reads package-lock.json and reproduces installation with npm ci under Node 24, recording node --version and npm --version with the command output. README.md calls for npx prisma generate before serving the app, and src/prisma/schema.prisma selects PostgreSQL through DATABASE_URL. Package compatibility is investigated from concrete install or execution failures. Upgrades to Prisma, Nx, esbuild or the test toolchain need a stated reason; changing the runtime does not itself authorize an Express major upgrade or a rewrite of application routes.
Validation follows the repository’s real commands: npm test delegates to nx test, npm run build delegates to nx build, and npx nx serve api starts the application. project.json builds src/main.ts into dist/api with CommonJS output, disables bundling and generates a deployment package manifest. The agent checks the generated output as well as development startup. jest.config.ts runs tests through ts-jest, while src/tests/prisma-mock.ts replaces Prisma with a mock. Those tests cannot demonstrate that a generated Prisma client connects to PostgreSQL on the new runtime; database verification needs a separate test service and an explicit result.
The container and HTTP checks finish the picture. The Dockerfile copies dist/api, installs production dependencies inside that directory and starts node api. The agent pins the base image to Node 24, builds through npx nx docker-build api and exercises the resulting container. It also inspects e2e/jest.config.ts and its support files before running npx nx e2e e2e: the global setup does not launch the application. The supplied server spec expects a Hello API message, while src/main.ts returns a status field saying API is running on /api. That discrepancy needs a baseline check and a separate explanation, not attribution to Node 24 without evidence.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Upgrade this Express project to Node 24. Inventory runtime declarations, .nvmrc, package.json engines, CI workflows, Dockerfiles and the package lockfile; explicitly report absent files. Align existing pins and add explicit runtime settings where needed. Install under Node 24, record Node and npm versions, generate Prisma, run tests and build, and verify development and built application startup. Build and exercise the Docker image. Inspect e2e prerequisites and distinguish pre-existing failures from runtime regressions. Update existing CI to run the checks on Node 24; if no workflow exists, add one for this verification and explain its service requirements. Fix demonstrated compatibility problems without unrelated upgrades. Open a pull request listing each change, command output and any checks that remain blocked.",
"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 requested pull request aligns the Docker base image, the declared local runtime and CI verification around Node 24. For this fixture, a new .nvmrc, engines declaration or workflow is described as an addition. package.json and package-lock.json change together when compatibility work requires dependency updates. The description identifies each fix, why it is needed and which failing command it addresses, with separate notes for baseline defects discovered along the way.
The review evidence covers installation, Prisma generation, unit tests, the production build, HTTP startup and container execution. A reviewer checks that the generated deployment package runs with production dependencies and that CI exercises the intended runtime. Database access or container checks that cannot run remain clearly marked as unverified. Read the session’s result and PR information through GET /o/{org}/sessions/{id}, then inspect its transcript for the actual commands instead of treating an edited version string as proof.
Run it on every runtime upgrade window
Have your weekly maintenance job decide which repositories still need a Node 24 upgrade, then submit one POST /o/{org}/sessions request per repository. Send the API key as a Bearer token and replace the example resources URL with a repository covered by your Rush GitHub App installation. Keep selection logic in your scheduler so already migrated apps do not receive the same maintenance request every week.
Persist each execution_id alongside the repository and proposed runtime. A completion webhook configured on the key can notify your service that the turn finished; read the session for the full result. Retry a submission with the same Idempotency-Key and body, and use a new key for a genuinely new upgrade run. Queue additional repositories when the key’s concurrency limit is reached.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
A runtime upgrade needs an environment you can change while keeping your own development setup usable. Rush runs the work in a cloud sandbox where the agent can install dependencies and execute the project’s commands. For this application, that means examining the Nx build and Prisma setup together with the Docker packaging, with tool output available in the session transcript.
When several services need the same runtime target, separate runs let their checks proceed within your allowed concurrency. Their compatibility fixes can differ even when their Docker base image changes are similar. You receive an answer and reviewable changes for each repository, then ask a finished session to investigate a failed container check or explain a dependency upgrade before accepting its PR.
Frequently asked questions
Does the example already pin an older Node runtime?
No explicit local Node version or engines requirement appears in the inspected fixture. Its Docker image uses lts-alpine and its Node types are version 18.16.9. The agent must establish an explicit runtime target instead of confusing the type package with an installed runtime.
Will CI and Docker change in the same pull request?
The prompt asks for both as part of verification. In this fixture Dockerfile exists, but a GitHub Actions workflow does not, so CI coverage is a new file. The result should explain that distinction and identify any database service required by the checks.
Is passing npm test enough for a Node upgrade?
The existing Jest suite includes a mocked Prisma client. It cannot by itself verify database connectivity or the production container. Review startup, generated-client and container evidence separately, with missing checks called out.
Will the agent upgrade every dependency to its latest release?
The request limits changes to demonstrated compatibility problems. A runtime migration should explain why each package changes and preserve unrelated application behavior. Broader dependency maintenance can be a separate request after the Node upgrade is reviewed.