Appearance
Deploy a Laravel CMS to DigitalOcean, Laravel Cloud or Docker — the files written from your site
Every deployment guide for a Laravel application is right in general and wrong for your site in a few places. The guide says npm run build; your site has a Blade theme and no Node at all, or a Vue theme that also needs PHP during its build. It says php artisan queue:work; your site runs Horizon, and the worker it set up starves on the default memory limit. It says DB_DATABASE=laravel; your database came from a WordPress site and every table starts with wp_. It saves the Composer token in auth.json; your admin is Nova and needs a second one. Each of these is a small thing, found at eleven at night with the site half up.
A CMS adds its own: uploads that must outlive a deploy, a queue that must run, a scheduler that must come by every minute, and packages from a private Composer repository. None of it is hard. All of it has to be right for this site.
Tell the agent
With Claude Code in the project, the deploy is a sentence:
"Deploy this site to a DigitalOcean Droplet in Frankfurt, domain example.com; the DNS is at Cloudflare."
Every kitloom project carries a skill for it. The agent asks what it cannot know, writes the deploy files with the site's own kit (below), makes the Droplet with doctl and the kit's cloud-init file as user data, tells you the DNS record, puts the server's deploy key on the repository, deploys, checks that the front page and the admin's login page answer, and makes the first administrator — handing you the password once. It confirms before anything that costs money, and it never asks for the token in the chat. Any other agent gets the same instructions as a prompt: With an AI agent.
One command, the files for this site
Behind the agent, and for anyone who would rather hold the files, is kitloom/deploy, a package every site has:
bash
php artisan kitloom:deploy-kit server # one VPS on Ubuntu 24.04
php artisan kitloom:deploy-kit laravel-cloud # cloud.laravel.com
php artisan kitloom:deploy-kit forge # Laravel Forge or Ploi
php artisan kitloom:deploy-kit docker # any Docker host
php artisan kitloom:deploy-kit digitalocean-app # DigitalOcean App PlatformThe command reads the site as it is installed — Filament at /admin or Nova at /nova, a Vue theme that needs npm or a Blade theme that does not, Horizon or a plain worker, Sentry, Import & Export, the WordPress prefix of the database, the PHP version the project asks for — and writes the files for the target, filled in:
server:deploy/server.shsets an Ubuntu 24.04 server up as root — PHP-FPM with the extensions, Nginx with the site's server block, MySQL with the site's database, Composer with your token, Node when a theme needs it, Redis when Horizon does, thedeployuser, the site's.envwith a key and a password made up, cron, the worker as a systemd service, a certificate — and is safe to run again.deploy/cloud-init.yamlis the same at the server's first boot, pasted as a Droplet's User data, Hetzner's cloud config or an EC2 instance's user data.deploy.phpis a Deployer recipe: a release in a folder of its own, switched live once built, migrated and checked,dep rollbackto go back,dep kitloom:userfor the first administrator. A GitHub Actions workflow deploys on every push, with one secret, an SSH key; the token stays on the server.laravel-cloud: Cloud keeps its settings in a dashboard, so the kit writes the checklist with this site's values — the resources, the build commands with the token (and Nova's), the worker, the scheduler — anddeploy/laravel-cloud.envto paste: the uploads on the bucket, the caches built in the build, the WordPress prefix.forge: the deploy script to paste into Forge or Ploi, with the theme build and the right restart for the worker, and the environment lines they do not know about.docker: aDockerfilewith PHP-FPM and Nginx in one container, the packages installed in a stage that stays out of the image so the token never reaches its history, the themes built in;compose.ymlwith the site, the worker, the scheduler, MySQL and Redis on one host; and what a platform that runs the image needs — the uploads on S3, the worker and the scheduler as services.digitalocean-app: the same image and.do/app.yamlfordoctl apps create— the web service, the worker and the scheduler, the managed MySQL bound in, the uploads in a Space, the domain.
Every target also writes deploy/README.md, the steps for this site in order. Install Horizon next month, add a Vue theme, change the domain: run the kit again, and it rewrites its own files while keeping the ones you edited.
What the kit found
The kit was written by deploying a site each way, and some of what it learned is not in the general guides. A TypeScript theme asks PHP for the site's page types while Vite builds it, so the Docker stage that builds the themes keeps PHP and borrows Node from its image. A console without OPcache boots the whole site at about 100 MB, which is more than Horizon lets its own process have, so the worker restarts in a loop until OPcache is on for the CLI — the kit turns it on, on the server and in the image. App Platform's development databases are Postgres only, so a MySQL site attaches a cluster made first. A container asks itself at 127.0.0.1 whether it is healthy, and a site that answers only its own hosts says no until that address is trusted. Each of these is one line in the right file; the kit knows which.
Where kitloom sits
kitloom is a Laravel CMS on the WordPress data model: an admin editors already know, in Filament or Nova; Blade, Vue or React on the front; modules for the shop, bookings, courses, forms and the rest; and an MCP server, so the agent that deployed the site goes on to run it — posts, SEO, orders — with exactly the rights of its user. A WordPress site comes along with its database, its URLs and its users. The deploy kit is how it gets onto a server: the files written from the site, by you or by the agent.
Deployment has every target by hand as well; the sandbox is a site to try without deploying anything.