Laranode: self-hosted VPS and server management with cPanel-style controls

Laranode's scope for VPS and dedicated server administrators

Laranode addresses a specific gap between managing a Linux host through shell commands and adopting a full commercial control panel such as cPanel or Plesk. It is intended for administrators of VPS and dedicated servers who need to create hosting accounts, add websites, manage MySQL, assign PHP versions, issue SSL certificates, administer Apache and UFW, and inspect CPU, memory, and network usage from a browser. The repository identifies it as a PHP project, and its package files show a Laravel and React interface built around Inertia.js, Tailwind CSS, Vite, Chart.js, and Laravel Echo.

This is not presented as a general-purpose desktop control panel or a hosting provider. Laranode manages the machine on which it is installed. Its Dockerfile states that it creates system users, Apache virtual hosts, PHP-FPM pools, MySQL, UFW rules, and Let's Encrypt certificates inside the container. That distinction matters because the software expects privileges and operating-system integration beyond those of a conventional stateless PHP application.

Account roles are also part of the product. Administrators can manage panel users and server resources, while account owners can work with their own resources. The README specifically says account owners can back up and restore their own websites, files, and databases. This makes the project relevant to a small administration team that wants to delegate selected resources without exposing the full server interface.

How Laranode connects the Laravel panel to the Linux host

Laranode follows the architecture of a self-hosted LAMP control panel rather than a hosted dashboard. The application is built with Laravel on the server side. The React interface is compiled through Vite and communicates with Laravel through Inertia.js and Axios. Database-backed sessions, cache, and queues appear in `.env.example`, which indicates that the panel keeps application state in MySQL rather than relying entirely on local browser storage.

The host-facing layer is the consequential part. According to the Dockerfile, Laranode manages system users, Apache configuration, PHP-FPM, MySQL, UFW, and certificates. Its file manager uses `app/Filesystem/safe_file.py` for mutations, and Python 3 is installed as a hard dependency. The installer script and Docker image install much of the same server software, which is why the Docker route boots systemd as PID 1 rather than isolating each service in an independent container.

Realtime features also have a system component. The Docker stack includes Reverb, PHP-FPM, a queue worker, MySQL, and Apache within the same container. The package list includes Laravel Echo and Pusher.js, while the Compose file exposes the Reverb port and lets operators set its browser-facing host, port, and scheme. This supports live panel events, but it also increases the number of services and ports an administrator must understand.

Installing Laranode on a fresh Ubuntu VPS

The native installer is intended for a fresh VPS or dedicated server. Laranode documents Ubuntu 24.04 or later, one vCPU, 2 GB of RAM, and 10 GB of disk space as its minimum requirements. "Fresh" is an important boundary: the README does not describe an in-place migration procedure for installing Laranode alongside an existing server configuration.

Run the documented installer on a prepared Ubuntu server:

curl -sSL https://raw.githubusercontent.com/crivion/laranode/refs/heads/main/laranode-scripts/bin/laranode-installer.sh | bash

The installer is fetched directly from the repository's `main` branch and passed to `bash`, so reviewing or pinning that script is more important than in a package-based installation. The README then directs the administrator to open the panel through the server IP or a configured domain. Installation credentials are supplied during the process:

http://your-server-ip
OR if you pointed your domain/subdomain
http://your-domain.tld

The first practical task after login is to verify access to the intended host and review the server-related resources exposed by the panel. The README does not document an initial dry-run mode or an explicit rollback command for the native installer.

Running the privileged Laranode system container

Laranode can also be built as one Docker container. The Compose file requires `privileged: true`. Its comment explains that dropping that privilege prevents systemd from creating per-unit sandboxes, forces `NoNewPrivileges` on, and stops the panel from running its own scripts through sudo. This is a container intended to act as a managed Linux system, not an ordinary application sandbox.

Start it and create the first administrator with the documented commands:

git clone https://github.com/crivion/laranode.git && cd laranode
docker compose up -d --build
docker compose exec laranode laranode-artisan laranode:create-admin

The first build compiles several operating-system layers and frontend assets, so `docker compose logs -f` is included in the Compose documentation for following startup. Default published host ports are 80 for HTTP, 443 for HTTPS, 8080 for Reverb, and 2222 for the container's SSH endpoint. The Compose file allows these to be changed through `LARANODE_HTTP_PORT`, `LARANODE_HTTPS_PORT`, `LARANODE_REVERB_PORT`, and `LARANODE_SSH_PORT`.

Local backup archives use the dedicated `laranode-backups` volume. Container persistence still needs operator attention because the application, database state, host configuration, and backup volume all matter when rebuilding the image. The Compose file's default `restart: unless-stopped` policy helps with process restarts, but it is not a substitute for backup validation.

Website, PHP, database, and firewall operations

Once installed, Laranode groups common server administration under a web interface. Administrators can create multiple websites and assign PHP versions from 7.4 through 8.5 per site. The release notes for v1.2.5 add another operational detail: restoring a site now clears OPcache for that site's PHP version. That matters because restoring files without invalidating cached bytecode can leave a process serving stale code until the cache changes.

Database operations cover creating and controlling MySQL databases. SSL support uses Let's Encrypt and is presented as a panel action rather than a separate certificate workflow. UFW rules can also be managed from the interface. The built-in file manager provides browser-based access to site content, while live statistics cover CPU, memory, and network usage.

These features reduce the number of separate administrative surfaces, but they do not remove normal Linux ownership. Apache virtual hosts and PHP-FPM pools depend on the correct system user and path configuration. UFW changes can affect administrative access if rules are constructed incorrectly, and PHP version installation changes the server software available to every site using that version. Laranode's role-based accounts can restrict users to their own resources, yet the platform administrator retains control over the underlying services.

Laranode backup scope, destinations, and restore boundaries

Laranode supports three backup scopes: a complete hosting account with website files and databases, files for one website, and one website database. Destinations can be local storage, SFTP, or an S3-compatible object store. The README names DigitalOcean Spaces as an example of an S3-compatible destination. Administrators configure and test destinations, while account owners can operate on resources assigned to them.

Manual and scheduled operations are supported. Schedules can run daily, weekly, or monthly, and each schedule has its own retention count. A scheduler prunes expired archives, while backup and restore work runs asynchronously with live status and failure details. The local path defaults to `/var/lib/laranode/backups`, and `LARANODE_BACKUP_PATH` can change the root.

Restore protection is explicit. A restore requires typed confirmation and creates a seven-day safety snapshot before live data changes. The panel permits up to three retries after a failed restore. Completed backups otherwise remain available for later restores. These controls reduce accidental replacement, but backup completeness still depends on the chosen scope: a database-only archive does not include website files, and a files-only archive does not include databases. The documentation does not describe a cross-version restore compatibility matrix, so the release and archive contents should be checked before relying on an old backup after an upgrade.

Upgrade path, recent security changes, and maintenance cost

Native installations use a repository upgrade script:

curl -sSL https://raw.githubusercontent.com/crivion/laranode/refs/heads/main/laranode-scripts/bin/laranode-upgrade.sh | bash

The script pulls the latest release, updates dependencies, applies migrations, rebuilds frontend assets, and reapplies sudoers rules plus the PHP-FPM systemd sandbox. The README says these steps are safe to repeat. If the panel is not in `/home/laranode_ln/panel`, the operator can supply `PANEL_PATH=/path/to/panel`. Docker installations instead pull repository changes and rebuild:

git pull && docker compose up -d --build

Docker boot then applies the same upgrade steps. Laranode is under the MIT license, which permits broad use and modification under that license's conditions and obligations. That statement is not legal advice, and operators still need to preserve required notices.

The repository is not archived, and its last push was on 2026-09-23. Recent maintenance activity includes v1.2.5 on 2026-09-23, v1.2.4 on 2026-09-21, and v1.2.3 on 2026-09-21. Those releases address OPcache clearing after restore, a file-manager symlink read, and tenant symlinks that could expose panel files. The concentration of security fixes in this upgrade path is a concrete reason to review release notes before each upgrade and avoid carrying old accounts, directories, or backup archives forward without inspection.

Laranode versus a lighter admin interface or a commercial panel

Laranode instead centers accounts, domains, PHP-FPM, MySQL, SSL, and backups, making it more relevant when the goal is to delegate website hosting on a single VPS.

A commercial panel such as cPanel or Plesk can be the better choice when its documented operating-system support, extension ecosystem, support contract, and migration facilities are requirements. Laranode offers a narrower Ubuntu-centered route with no licensing fee, but the README provides little detail about third-party extensions, vendor support, multi-server clustering, or migration from an existing panel. It also requires a fresh Ubuntu host for the documented native installation.

Docker does not make that trade-off disappear. The image uses Ubuntu 24.04, privileged mode, systemd, and host-management components in one container. Operators who need strict workload isolation, immutable deployments, or independent service scaling should not treat it as a conventional PHP container. Its stated purpose is closer to reproducing the installer-managed VPS environment.

Editorial conclusion

Laranode suits administrators who want a self-hosted LAMP panel on a fresh Ubuntu VPS or dedicated machine and are comfortable granting a control panel control over system services and sudo access. It is a poor fit for shared hosting environments, non-Ubuntu hosts, or operators who cannot accept a privileged Docker container and broad host access. Verify the Ubuntu 24.04 requirement, privilege model, backup destination, restore procedure, and current security posture before adopting it. For Laranode specifically, the privileged container and recent symlink-related security fixes make those checks the first adoption boundary.

Frequently asked questions

Official sources

1. crivion/laranode on GitHub
2. License: MIT
3. Project website
4. README
5. Releases