Running from source
Some hosts want your source code rather than a container image. BenchKit runs from source anywhere Laravel runs, including Laravel Cloud and Railway.
If your host does allows you to run Docker commands (like a VPS), use the Quick start instead. It needs nothing on the machine except Docker, and it is how you compare web servers against each other.
Install it
git clone https://github.com/serversideup/benchkit-laravel.git
cd benchkit-laravel
composer install --no-dev --optimize-autoloader
yarn install && yarn build
cp .env.example .env
php artisan key:generate
Every benchmark tool BenchKit uses ships as a Composer package, so composer install puts them in vendor/bin and gives everything you need to run the application.
.env.example is written for local Docker development, so it carries settings you won't need on a server. On a platform that manages environment variables for you, set them there and skip the .env file. APP_KEY is the one value BenchKit cannot start without.Deploying to a platform
Point the platform at the repository and give it a build command that covers both halves of the install:
# Install PHP dependencies
composer install --no-dev --optimize-autoloader
# Install Node dependencies
yarn install
# Build the frontend
yarn build
The frontend build matters. Compiled assets are not committed to the repository, so a deploy that only runs composer install will boot and then fail to render. Beyond that, nothing about the deploy is BenchKit-specific.
Where your runs are stored
Completed runs are written to storage/app/runs as JSON files. No database is involved, so there is nothing to migrate and nothing to back up beyond that directory.
The local development stack bind-mounts the repository, which keeps your history on your own machine. See CONTRIBUTING.md if you are working on BenchKit itself.