From a bare VPS to a live site, step by step
PimiDeploy sets up a fresh Ubuntu 24.04 server over SSH, then deploys your Laravel app from git. This is what it installs, what a site gets and what one deploy does.
In private testing. It already runs our own production.
202610112214024f2a91cLive202610111902339c01be7Kept20261010164810e27d5a0Kept202610091133271b8840fKept20261008090154c63f9d2Kept
One provision installs the whole stack
You create the VPS and paste the panel’s public key into it. The panel connects over SSH, installs what is below and shows the output live. On our own servers we measured about 3 minutes for this, and 21 seconds for a deploy.
| nginx | 1.24, with one config per site |
|---|---|
| PHP | 8.4 by default. Versions 8.1 to 8.5 run side by side, one per site |
| Database | MySQL 8.0 or MariaDB 10.11, chosen per server. PostgreSQL 16 beside it, or instead of it |
| Redis | 7, with a separate user per site |
| Node | 22, for your asset builds |
| supervisor | Runs your queue workers and Horizon |
| certbot | Let’s Encrypt certificates and their renewal |
| Security | A firewall, key-only SSH, fail2ban and automatic security updates |
| Roles | One server for everything, or separate database, cache, worker and web servers |
Provision again whenever you like: it changes only what differs, with no downtime.
Each site gets its own user, database and keys
Kept apart
Its own Linux user, PHP pool, database user and Redis user. Each site’s database, cache and secrets are its own.
A deploy key of its own
Read-only, for that one repository. Connect GitHub and the key and push webhook are added for you.
Push to deploy
Through a GitHub webhook, or a deploy URL any CI tool can call.
An .env editor
Read from the server, never stored in the panel. A file that breaks the app is put back.
Its own PHP version
Deploys, workers and the scheduler use it. Switching version causes no downtime.
An API for everything
Every action in the panel is an API call you can follow live.
One deploy, six steps, no downtime
-
A push starts it
A push to your branch, the deploy URL, or Deploy now in the panel.
-
A new release folder
The repository is cloned fresh into its own folder. The live site is not touched.
-
Shared files are linked
Your .env and storage folder sit outside the releases and are linked in.
-
Your deploy script runs
As the site’s own user: composer, migrations, your build. It stops at the first failing command.
-
The switch
The live link moves to the new release at once. PHP reloads and queue workers restart on the new code.
-
A health check
The panel asks the site for a page and records the answer.
Cloning [email protected]:you/shop.git (main) into releases/20261011221402 Commit 4f2a91c0d3e1: Add order export Linking shared .env and storage Running the deploy script (PHP 8.4) Switching current to 20261011221402 Pruning old releases Deployed 4f2a91c0d3e1 as release 20261011221402 Health check: 200 in 84 ms
A failed deploy never becomes the live site
If the clone or your deploy script fails, the new folder is removed. The site keeps serving the release it had, and the log shows the failed step.
If a release goes live and fails its health check, your team is alerted. With automatic rollback on, the panel returns to the release before it. Database migrations are not reversed.
You can roll back by hand to any of the last 5 releases. Queue workers move with it.
Cloning [email protected]:you/shop.git (main) into releases/20261012093015 Commit 81d3f0a2c7be: Upgrade payment library Linking shared .env and storage Running the deploy script (PHP 8.4) Deploy failed (exit 1); removing release 20261012093015, current is unchanged
What it does not do
- Ubuntu 24.04 only You create the VPS and point your DNS at it. Laravel and WordPress sites only.
- No deploys on a server it did not set up A server you already run connects read-only today.
See also what PimiDeploy can touch on your server and WordPress on your own server.