VitoDeploy (vitodeploy/vito): a self-hosted PHP deployment panel you install with one shell command

The problem VitoDeploy solves: server chores without a terminal session per task

Managing a PHP production server usually means repeating the same SSH work: create a system user, install PHP and a web server, open firewall ports, issue a certificate, create a database, wire a queue worker under supervisor, add a cron entry. Each step is small, and each step is easy to get subtly wrong on the second or fifth machine.

Vito is a self-hosted web application that centralises those operations. The README describes it as a tool that "helps you manage your servers and deploy your PHP applications into production servers without a hassle", and the feature list maps closely to the list above: server provisioning and management, MySQL and MariaDB database management, PHP application deployment, firewall management, custom and Letsencrypt SSL, supervisor-managed queues, service management, SSH key deployment, cron jobs, an API, plugins, export and import, workflows and automations, and domains with DNS management.

The audience is narrow and identifiable. It is for people who already run their own VPS instances and want a control panel rather than a Kubernetes cluster. The primary language is PHP, the stack is Laravel with an InertiaJS and React front end, and the deployment target is explicitly PHP applications such as Laravel. If your workloads are not PHP, most of the value disappears.

How VitoDeploy works: a Laravel control plane talking to remote servers

The repository layout tells you the architecture. There is a standard Laravel application tree (app/, bootstrap/, config/, database/, resources/, storage/, tests/, artisan) plus a resources/ directory holding the React and TypeScript front end, confirmed by package.json depending on @inertiajs/react, @inertiajs/vite and a long list of Radix UI packages.

The control plane is therefore a Laravel app served over HTTP. Long-running work is not done in the request cycle: docker-compose.yml defines a separate worker service whose command is `php artisan horizon`, and Horizon is Laravel's Redis-backed queue dashboard and supervisor. That same compose file also runs a redis service with a healthcheck of `redis-cli ping`, so the panel's background jobs are queued through Redis and executed by the Horizon worker container.

The remote side is handled over SSH. The README credits PHPSecLib, a pure-PHP SSH implementation, and lists "Deploy your SSH Keys to the server" as a feature. So the flow is: you add a server and credentials to the panel, the panel connects over SSH, and it runs the provisioning and deployment steps on that machine. The panel itself is not an agent you install on the target; the target is a normal server that Vito reaches into. That distinction matters when you reason about failure modes, because a network partition between the panel and the target stops deployments even though the target application keeps serving traffic.

The front end is a single-page React application rendered through Inertia, with Monaco Editor present for in-browser file or script editing and @tanstack/react-table plus @forjedio/inertia-table-react for the list views. The panel exposes an API as well, and .env.example contains a SCRIBE_AUTH_KEY placeholder, which points at Scribe as the API documentation generator.

Installing VitoDeploy and deploying your first application

The README gives a one-line installer for a fresh server. It fetches a shell script from the 4.x branch and executes it:

bash <(curl -Ls https://raw.githubusercontent.com/vitodeploy/vito/4.x/scripts/install.sh)

Read that command before running it. It pipes a remote script straight into bash as root on a VPS, which is the standard pattern for panels of this kind and also the reason you should run it on a disposable machine first. The README points to the documentation for the full walkthrough at vitodeploy.com/getting-started/installation.html, which offers two paths: install on a VPS, or install via Docker.

If you prefer the Docker route, the repository ships a docker-compose.yml, but note what it actually is. It builds from ./vendor/laravel/sail/runtimes/8.4, sets LARAVEL_SAIL: 1, and mounts the working directory into /var/www/html. That is a Laravel Sail development environment, not a hardened production deployment. It publishes the app on `${APP_PORT:-80}` and Vite on `${VITE_PORT:-5173}`, and runs the Horizon worker as a second service. The Makefile wraps it in two targets, `start` and `stop`, which call `./sail up` and `./sail down`.

For local configuration, .env.example is the template. The keys that matter most on first boot are the application URL and the queue and websocket settings:

APP_NAME=Vito
APP_ENV=local
APP_KEY=
APP_DEBUG=true
APP_URL=

#WS_URL=http://localhost
#WS_BROADCAST_SECRET=
WS_ALLOWED_ORIGINS="${APP_URL}"

FILESYSTEM_DRIVER=local
APP_PORT=8000

APP_KEY must be generated before the app will run, and WS_ALLOWED_ORIGINS is derived from APP_URL, so a wrong APP_URL breaks the websocket origin check rather than failing loudly at boot. FILESYSTEM_DRIVER defaults to local, which is worth remembering when you think about backups and export files.

A first real use, based on the feature list rather than on a run I performed: install the panel, open it, add a target server with SSH credentials, let Vito provision it, then create a site for your PHP application, point a domain at it, and let the panel issue a Letsencrypt certificate. The README's feature list is the checklist for what should be available at each step: firewall rules, databases, supervisor queue workers, cron jobs, SSH keys and DNS.

Where VitoDeploy is the wrong choice

The most important limitation is scope. Vito manages servers and deploys PHP applications. It is not an orchestrator. There is no scheduler, no node pool, no rolling update strategy and no self-healing described anywhere in the README or the repository layout. If your application needs to scale horizontally across many identical instances behind a load balancer, a panel that provisions individual servers one at a time is the wrong abstraction, and you will spend more time working around it than it saves.

The second limitation is the trust boundary. The panel holds SSH access to your servers and runs commands on them. That is inherent to the design, and it means the panel host is a high-value target. The README links to a SECURITY.md, which is where disclosure policy lives, but the README itself says nothing about how credentials are encrypted at rest or how the panel authenticates its own users. Anyone evaluating Vito for a regulated environment should read the documentation and the source before assuming those controls exist.

The third is the queue dependency visible in docker-compose.yml. Background work runs through Redis and Horizon. If Redis is unavailable, provisioning and deployment jobs do not execute, and the panel will look like it accepted an action that never happened. That is a normal queue design, not a defect, but it changes how you monitor the panel: you watch the worker, not just the web process.

Finally, the licence. Vito is AGPL-3.0. If you modify it and expose it to users over a network, the AGPL's network clause is the part to read carefully. This is a real consideration for anyone planning to rebrand or extend the panel as part of a commercial service, and it is the kind of question to put to a lawyer rather than to a README.

VitoDeploy compared with Ploi and hand-rolled Ansible

The obvious comparison is Ploi, which shows up directly in the search data around this project. Both present a web UI for provisioning servers, deploying PHP applications, managing SSL and databases, and both target the same Laravel-shaped workload. The difference is where the control plane runs. Ploi is a hosted service: you sign up, and their infrastructure holds the credentials and drives your servers. Vito is self-hosted, so the panel, its database and its Redis instance live on hardware you control. That is the entire trade. You take on running and backing up the panel itself, and in exchange no third party holds SSH access to your fleet, and there is no per-server subscription.

The other alternative is doing it yourself with Ansible, or with a provisioning script and a CI pipeline. That approach is more work up front and gives you exact control: your playbooks are versioned, reviewable and testable, and nothing needs a web UI to run. What you give up is the interactive surface. Rotating a certificate, adding a cron entry, or creating a database for a colleague stops being a two-minute click and becomes a pull request. Teams that already have disciplined infrastructure-as-code should think hard before adding a panel on top; teams whose server changes happen ad hoc will get more from Vito than from another Ansible role nobody maintains.

Maintenance, upgrade cost and the AGPL-3.0 licence

Vito is not dormant. The most recent release listed is 4.1.0 on 2026-08-17, following 4.0.1 on 2026-07-10 and 4.0.0 on 2026-06-30, and the last push to the default branch was on 2026-08-30. The 4.x line is the default branch, which is also the branch the installer script pulls from, so the one-line install tracks the current major version rather than a frozen tag.

That has a practical consequence for upgrades. Because the installer URL points at the 4.x branch, re-running the installer is how the project expects you to move forward within the major version, and the README does not document a rollback path. Take a database and filesystem snapshot before upgrading, especially across a major version like 4.0.0 to 4.1.0, because the panel stores the state of your servers, sites and credentials.

The upgrade cost beyond the panel itself is small in dependency terms. The front end is built with Vite and TypeScript, the back end is Laravel, and the runtime dependencies are Redis and a queue worker. There is no exotic infrastructure to keep alive. The real ongoing cost is operational: the panel is a machine with SSH keys to everything else, so it needs patching, backups and access control of its own.

On licensing, AGPL-3.0 is a strong copyleft licence with a network-use clause. Running Vito internally to manage your own servers is the ordinary case. Modifying it and offering it to others over a network is where the obligations become material, and the LICENSE file plus the project's contribution guide are the documents to read. Nothing here is legal advice.

Editorial conclusion

Adopt Vito if you run a handful of PHP or Laravel servers and want provisioning, SSL, databases and cron behind one web UI you host yourself. Do not adopt it if your infrastructure is container orchestrated, if you need multi-region failover, or if AGPL-3.0 obligations conflict with how you ship modified code. Before committing, verify on a throwaway VPS that the install script completes, that the panel can reach your target server over SSH, and that a test deployment of your own application succeeds end to end.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. vitodeploy/vito on GitHub