Laravel Forge and Ploi

• With the deploy kit
• In Forge
• In Ploi
• Every time after

Laravel Forge and Ploi set a server up — PHP, Nginx, MySQL, the queue worker, the scheduler, a certificate — at DigitalOcean, Hetzner, Vultr, Akamai, AWS or a server of your own, and deploy on every push. What they cannot know is kitloom's: the token for the packages, the themes' build, the worker's command, the WordPress prefix. The deploy kit writes it. What the server needs and where else to host: Deployment.

With the deploy kit

php artisan kitloom:deploy-kit forge --domain=example.com

File	What it is
deploy/forge.sh	The deploy script to paste into Forge (Site → Deployments → Deploy script): composer install, the themes built when a theme needs it, migrate, optimize, PHP-FPM reloaded, the worker restarted the way it runs (queue:restart, or horizon:terminate with Horizon), the SSR daemon stopped so that Forge starts it again on the new bundles
deploy/ploi.sh	The same for Ploi, with its placeholders
deploy/forge.env	The lines to add to the site's environment under what Forge filled in: the theme, DB_PREFIX for a WordPress database, the queue, the mailer to set
deploy/README.md	The checklist of their screens, for this site

In Forge

1. Servers → Create server: Ubuntu 24.04, PHP 8.4, MySQL 8 (and Redis with Horizon), 2 GB of memory (4 GB for a shop or Horizon).
2. The kitloom token, saved once as the server's user, which is who deploys (ssh forge@<ip>): composer config --global http-basic.packages.kitloom.dev <your-name> <your-token>, and the same for nova.laravel.com on a Nova site.
3. Sites → New site: the domain, project type Laravel, web directory /public; then the Git repository, branch main, Install Composer dependencies ticked.
4. Environment: Forge filled in APP_KEY, APP_URL and DB_*; add the lines of deploy/forge.env under them, and a real mailer.
5. Deployments → Deploy script: replace it with deploy/forge.sh. Quick deploy on.
6. Server → PHP: max file upload size 64 MB, the media library's limit.
7. Server → Scheduler: the Laravel scheduler preset — php artisan schedule:run every minute as forge in the site's folder.
8. Server → Daemons: php artisan queue:work --sleep=3 --tries=3 --max-time=3600 (or php artisan horizon) in the site's folder as forge. The deploy script restarts it after every deploy. With a Vue or React theme, a second daemon there: php artisan inertia:start-ssr, the SSR server that renders the pages for crawlers and first visits; the deploy script stops it after the build and Forge starts it again.
9. Site → SSL: Let's Encrypt, once the DNS record points at the server.
10. Deploy now. Then, once, as forge in the site's folder: php artisan storage:link, and the first administrator with php artisan kitloom:user --login=admin [email protected] — or WordPress's database loaded instead, with DB_PREFIX in the environment.

Site Health in the admin then says whether the scheduler and the worker come by.

In Ploi

The same, under Ploi's names: a server (Servers → Create, PHP 8.4, MySQL, Redis with Horizon), the token as ploi on it, a site from the repository, Environment with deploy/forge.env added, Deploy script replaced with deploy/ploi.sh, Cronjobs with the Laravel scheduler preset, Daemons with the worker's command, SSL with Let's Encrypt.

Every time after

A push to main deploys. A new version of kitloom comes in through composer update on your machine, tested, with composer.lock committed; the server installs exactly that. The script takes the site through git pull and composer install in place — a few seconds in which a visitor may hit a half-updated site. For releases switched in one move, run Forge's Envoyer, or the kit's server target on the same server: its Deployer recipe deploys into a folder per release.