VitoDeploy: a self-hosted control panel for PHP servers, installed by one curl command

The gap Vito fills: server provisioning and PHP deployment behind one web UI

Managing a PHP production server usually means a pile of manual steps: create the user, install the web server, configure PHP-FPM, set up the database, add an SSL certificate, wire Supervisor for queue workers, and remember the cron entries. Vito's README describes it as a self-hosted web application that helps you manage your servers and deploy your PHP applications into production servers without a hassle. That is the scope. It is a control panel, not a deployment library you import into an application.

The target user is an engineer or small team running their own VPS or dedicated machines, deploying Laravel-style PHP applications, who would rather click through a web interface than keep a folder of shell scripts. The README lists the feature set directly: server provisioning and management, MySQL and MariaDB database management, PHP application deployment, firewall management, custom and Letsencrypt SSL, Supervisor for queues, service management, SSH key deployment, cron jobs, an API, plugins, export and import, workflows and automations, and domains and DNS management. That list is broad, and breadth is the selling point. The trade-off is that every one of those areas is a surface you now have to operate yourself, because Vito is self-hosted.

How Vito works: a Laravel control plane that drives remote servers over SSH

The stack is visible in the credits section. The application is built with Laravel and InertiaJS on the backend, ReactJS and Shadcn UI on the frontend, with Tailwind and Vite for assets, Pest for tests, and PHPSecLib in the dependency list. PHPSecLib is the signal that matters: it provides SSH and cryptographic primitives in pure PHP, which is how a PHP web application can reach out and run commands on a remote machine without shelling out to the system ssh binary.

So the data flow is: you run the Vito web application somewhere (a VPS, or via Docker, both installation paths are documented), register a server in the interface, and Vito connects to that server over SSH to provision it and to perform deployments. Server state lives in Vito's own database, and the remote machine is the thing being acted upon. This is a pull model from the control plane's perspective. The README also mentions export and import, which implies the application's own state can be moved between instances, and an API plus plugins, which implies the interface is not the only way to drive it.

What the README does not describe is the agent question. There is no mention of a long-running daemon installed on managed servers. If provisioning is purely SSH-driven, then every managed server must remain reachable from the Vito host on port 22, and the credentials Vito holds become the security boundary. That is a real architectural constraint, not a detail.

Installing Vito: the documented commands and the two deployment shapes

The quick start in the README is a single shell command:

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

That fetches scripts/install.sh from the 4.x branch and executes it. The README does not print the contents of that script, so anyone running it is trusting code they have not read. On a machine that will hold SSH credentials for other servers, reading the script first is the reasonable move.

The useful links section points to two documented installation routes: install on a VPS, and install via Docker. The README gives the URLs (vitodeploy.com/getting-started/installation.html with the #install-on-vps and #install-via-docker anchors) but not the steps themselves, so the Docker compose file or run command cannot be reproduced from this material. What can be said is that both a bare-metal install and a container install exist, and the Docker path is likely the one to pick if you want the control plane isolated from the host it runs on.

Configuration keys, environment variables and the exact requirements (PHP version, database engine for Vito's own state, web server) are not in the README. They are on the documentation site. Treat that as the first thing to check before committing to an install.

The feature list is also the list of things you now own

Firewall management, SSL issuance, cron scheduling, Supervisor configuration, service control: each of these is a feature Vito exposes, and each is also an operational responsibility it takes over. When Vito writes an Nginx or Apache configuration, that file is now managed by Vito. When it issues a Letsencrypt certificate, renewal scheduling is Vito's job. If you later stop using Vito, you inherit a server whose configuration was generated by a tool you are no longer running. The README offers export and import, which helps move Vito's own data, but it does not claim to reverse-provision a server back to a plain state.

This is not a flaw unique to Vito. It is the nature of control panels. The point is that adopting Vito is a commitment to a particular way of describing your infrastructure, and the exit path is manual.

A second consequence: the feature list mixes provisioning (one-time setup) with ongoing management (SSL renewal, cron, deployments). Those have different failure modes. A provisioning bug is caught immediately. A renewal bug is caught in ninety days when a certificate expires. The README does not discuss monitoring or alerting for Vito's own background work, and nothing in the supplied material suggests Vito watches its own scheduled tasks.

Where Vito is the wrong choice

If your applications are not PHP, Vito is aimed elsewhere. The README says it deploys PHP applications such as Laravel, and the whole feature set (Supervisor for queues, PHP-FPM style deployment, MySQL and MariaDB) is PHP-shaped. A team running Go, Node or Python services would be using a control panel whose deployment model does not match their build artifacts.

If you need a managed service with a support contract, self-hosted is the opposite of that. You run the Vito instance, you upgrade it, you back up its database, and you are the one paged when the control plane is down. The README does not describe a hosted offering.

If your servers are not reachable from the Vito host over SSH, the model breaks. There is no documented agent, so network topology matters. Jump hosts, private subnets, or restrictive egress rules would need to be solved outside Vito.

Finally, if you only deploy one application to one server and you already have a working shell script, Vito adds a web application, a database, and an upgrade cadence to maintain. The README's feature list is long, and long feature lists are a cost when you use three of them.

Alternatives and the actual difference in approach

The README names its own building blocks rather than competitors, so a comparison has to come from the approach rather than from the text. Two reference points are worth stating.

First, plain Ansible or shell provisioning. The difference is direction and state. Ansible runs from your laptop or CI, describes the desired state in a playbook, and is idempotent by design. Vito runs as a persistent web application, holds server credentials, and applies changes when a user asks it to. Ansible leaves you a repository of text you can review and diff. Vito leaves you a database of server records and generated configuration. If your team already reviews infrastructure changes as pull requests, Vito moves part of that work into a UI where review is not the default.

Second, a managed platform such as a PaaS. The difference is who owns the machine. With a PaaS you do not manage the server at all, and the trade is cost and less control. Vito is for people who want the server and want a UI on top of it. That is a coherent position, but it means Vito's value depends on your willingness to keep running the underlying machines.

The honest summary: Vito competes with your existing scripts and your existing mental model of how a server should be configured, not with a specific product named in the README.

Licence, upgrades and the maintenance bill

Vito is licensed AGPL-3.0. The practical consequence for most users is nil: running an unmodified Vito instance to manage your own servers is the ordinary use case. The obligation becomes relevant if you modify Vito and let other people interact with it over a network, because the AGPL's network clause requires offering the corresponding source to those users. If your organisation has policies about AGPL software, check them before you build anything on top of Vito rather than after. This is not legal advice; it is a pointer to the clause that usually matters.

The release cadence visible in the supplied data is three releases in roughly two months: 4.0.0 on 2026-06-30, 4.0.1 on 2026-07-10, and 4.1.0 on 2026-08-17, with the default branch on 4.x and the last push on 2026-08-30. That is an active project, and it also means upgrades arrive often. A major version bump from 3.x to 4.x implies breaking changes somewhere, though the README does not document a migration path. Before adopting, find the upgrade notes for the 4.x line on the documentation site and confirm whether your install method (script or Docker) has a documented upgrade procedure. If it does not, you are planning to reinstall rather than upgrade, and that changes the cost calculation considerably.

The maintenance bill has three parts: the Vito instance itself (Laravel application, its database, its backups), the remote servers it manages, and the plugins or workflows you write. The README mentions plugins and workflows as features but gives no API stability statement, so anything custom you build against them should be treated as coupled to the 4.x line until the documentation says otherwise.

Editorial conclusion

Vito fits teams that run their own PHP infrastructure, want a browser interface for server provisioning and deployment, and are comfortable operating a Laravel application as the control plane. It does not fit teams that need a managed service with a support contract, or that cannot accept AGPL-3.0 obligations for a modified hosted version. Before adopting it, verify the install script's contents, confirm which database and web server versions the target distribution ships, and check that your deployment workflow maps onto the built-in features rather than requiring custom plugins.

Official sources

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