Vito: a server panel whose installer fetches a branch

The one-line installer fetches the 4.x branch, not a release

The quick start is one shell line that pipes a remote script straight into bash:

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

Two things sit in that address. The path segment is 4.x, which is also the repository's default branch, so the script you run is whatever that branch points at when you run it rather than a fixed artifact. The releases meanwhile are numbered: 4.1.1 on 2026-09-21, 4.1.0 on 2026-08-17 and 4.0.1 on 2026-07-10, and the tag names carry no prefix. So the documented install path tracks moving code on purpose while the release history gives you fixed points.

For a panel whose job is holding SSH keys, databases and firewall rules, that choice belongs to you. Since the tags are plain version strings, pinning means putting a numbered release where the branch name currently sits, and nothing in the documented command suggests that option. Read the script before running it, and decide which of the two you are installing.

Firewall, certificates, supervisor and cron: the unit of work is the host

The feature list splits into two groups that deserve different reactions.

The first group reaches into the machine: it provisions and manages the server, manages the server's firewall, supports custom and Let's Encrypt SSL, uses supervisor to handle queues, manages the server's services, deploys your SSH keys to the server, creates and manages cron jobs, and handles domains and DNS. The second group is about your application and the panel itself: deploying PHP applications such as Laravel, database management for MySQL and MariaDB, an API, plugins, export and import, and workflows and automations.

The first group is root on your server, item by item. A tool that only deployed applications could run anywhere; a tool that writes firewall rules and cron entries cannot, so the security question is not the feature count but how much host access you are handing over and which account it runs as. That is also why the SSH key deployment entry matters: the panel is built to hold credentials for the machines it manages, which is the capability worth auditing before the first install rather than after.

The repository's compose file is a Sail harness, not a deployment

docker-compose.yml at the root of this repository is the development environment for the panel, not a recipe for running it anywhere else. It builds the app from the Laravel Sail PHP 8.4 runtime under vendor, sets LARAVEL_SAIL to 1, mounts the working tree into the container at /var/www/html, and puts app, worker and a redis:alpine service on a bridge network named vito. Xdebug is wired to the host through extra_hosts and defaults to off.

The port mapping is the detail to notice in a development file:

        ports:
            - '${APP_PORT:-80}:80'
            - '${VITE_PORT:-5173}:${VITE_PORT:-5173}'

With no environment set, that publishes port 80 on the host and the Vite dev server on 5173. Redis gets a healthcheck of redis-cli ping with three retries, and the worker container runs php artisan horizon with restart: unless-stopped, depending on both app and redis. Nothing here provisions a server, which is the job Vito does for other machines.

Two queue systems: supervisor on managed hosts, Horizon in this tree

The feature list says supervisor handles queues on the servers Vito manages. This repository's compose file starts a worker whose command is php artisan horizon, backed by redis:alpine, which is the pairing Horizon expects. The two are not alternatives to each other; they belong to opposite sides of the product.

The consequence for a reader is that this repository tells you how the panel itself runs, not how a deployment it manages runs. Anything you want to know about the deployed side, such as which supervisor programs get written and what runs as which user, lives on the project's documentation site rather than in the tree. What the tree does answer is the panel's own runtime: PHP 8.4 from the Sail runtime, a queue worker on Horizon, and Redis with a persistent volume named vito-redis.

Worth keeping in mind when you read the two descriptions side by side. Supervisor is a process manager the panel installs elsewhere, Horizon is a Laravel queue daemon inside the panel, and a bug in one will not show up in the other's logs.

APP_PORT means 80 in the compose file and 8000 in the env example

The same variable carries two different defaults. The compose file falls back to 80 when APP_PORT is unset, while the example environment file ships a value of 8000:

APP_PORT=8000

SCRIBE_AUTH_KEY="YOUR-API-KEY"

Which one applies depends on whether your environment file is loaded, so a mismatch here is easy to produce and hard to read from a log.

The rest of that example file describes a development machine rather than a served application: APP_ENV is local, APP_DEBUG is true, APP_KEY is empty, APP_URL is empty, FILESYSTEM_DRIVER is local, and the mail settings are null placeholders with the sender built from the app name. The websocket keys are the exception to the pattern, because WS_ALLOWED_ORIGINS is set from APP_URL while WS_URL and WS_BROADCAST_SECRET are left commented out, which means a deployment that copies this file without editing it has broadcast settings that are half wired.

SCRIBE_AUTH_KEY is the line to read twice. It is a placeholder where an API key belongs, and it sits in the file everyone copies first.

A production env file and an agent config are both tracked at the root

The repository tree at the root carries three environment files: .env.example, .env.prod and .env.sail. A production variant being version controlled rather than created only on a machine is unusual for a project of this kind, and whether it holds anything sensitive is not something a directory listing can tell you. That is exactly the question to answer in your own checkout, with the file in front of you, before the panel is pointed at a host.

The same root also contains .claude/, CLAUDE.md, AGENTS.md, .mcp.json and .coderabbit.yaml. A server management panel shipping instructions for coding agents and a model context protocol server configuration is an unusual combination, and for a tool whose job is infrastructure it is worth knowing what those files declare before you install it.

None of this makes the project unsuitable. It does mean the answer to whether the defaults are safe lives in the repository rather than in a release note, so read it there.

make start is two lines that call Laravel Sail

The Makefile has exactly two targets. start runs ./sail up and stop runs ./sail down, which is the whole developer entry point and confirms that the compose file and the Makefile are two views of the same harness.

The front end is a Vite build with an Inertia React interface, and package.json is marked private and typed as an ES module. Its scripts cover build, build:ssr, dev, format, format:check, lint and types. Two of those deserve a second look: lint invokes eslint with --fix, so it rewrites files instead of reporting on them, and format only covers resources/, even though the prettier plugins include one for shell scripts and one for blade templates. Both are the kind of detail that shows up as an unexplained diff.

Static checking is three tools side by side rather than one: phpstan.neon for analysis, rector.php for automated refactoring, and pint.json for style. The presence of all three, plus phpunit.xml and a tests directory, is a reasonable signal about how changes are expected to arrive.

AGPL-3.0, a branch-named version line, and a credits list

The license recorded for this repository is AGPL-3.0, and the product is a web application you run yourself rather than a binary you install. If you intend to operate it on behalf of other people, read the license text for what that implies before the first user rather than after.

Versions move on a branch named for the line: the default branch is 4.x, the newest release is 4.1.1 from 2026-09-21, and the last recorded push is dated 2026-10-02. The credits section names the stack rather than hiding it, listing Laravel, InertiaJS, ReactJS, shadcn UI, PHPSecLib, Pest, Tailwindcss, Vite, Prettier, Spatie, a log viewer from opcodes.io, Tightenco and Forjedio's InertiaTables. The log viewer is the entry with a consequence attached, since a panel that shows server logs has already decided how much of your host's output it puts in a browser.

Documentation, the roadmap board and the contribution guide are all reachable from the project site, and the repository carries its own docs directory and a SECURITY.md that the README links as a relative path.

Editorial conclusion

Vito fits a team that wants one panel to own provisioning, TLS, queues, cron and DNS across several hosts, and the repository is straightforward about what it is: a Laravel and Inertia application whose own development environment is Sail. Read it in that order, because the feature list is the least informative part of it. Before a first install, decide whether you want the moving branch that the quick start fetches or a numbered release. Then check the three defaults that matter on a machine you care about: APP_PORT resolves to port 80 in the compose file, APP_KEY ships empty with APP_DEBUG on, and SCRIBE_AUTH_KEY is a placeholder string. Anyone who needs a panel that keeps its hands off the host firewall and service configuration will not find that here, since those are the first entries on the feature list. And anyone offering it to other people should read AGPL-3.0 before the first user rather than after.

Frequently asked questions

Official sources

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