-
-
Notifications
You must be signed in to change notification settings - Fork 0
Hosting providers
Notes on specific hosts, contributed by people running Planvio on them.
This page is community-maintained and unverified. Nobody tests Planvio against every host, and details change without notice — a provider that used PHP 8.1 last year may offer 8.4 now. Treat everything here as a starting point, and please correct anything you find to be wrong. Editing this wiki does not require any permission.
If you get Planvio running somewhere not listed, adding a few lines here is genuinely one of the more useful contributions available.
The three things that vary between hosts and cost people the most time:
-
The CLI PHP binary path. Shared hosts frequently have a different PHP for cron than
for the web, and the default
phpon the cron path is often an old one. Getting this wrong is the single most common reason the scheduler never runs. -
How the document root is set, because it must point at
planvio/publicand not atplanvio. -
Anything unusual — a symlink restriction, a
disable_functionsentry, a process limit that a queue worker trips over.
A useful entry looks like:
### Provider name
- PHP: selectable 8.1–8.4, chosen in <where>
- CLI PHP path: /usr/local/bin/ea-php83
- Document root: set in <where>
- Symlinks: allowed / not allowed
- Notes: anything that surprised you
The configuration Planvio is designed around, and the one with a dedicated guide: docs/CLOUDLINUX.md.
-
PHP: chosen per-domain in Select PHP Version (PHP Selector). Extensions are ticked
on the same screen — this is where a missing
intlorzipis fixed. -
CLI PHP path: usually
/usr/local/bin/ea-php83or/opt/alt/php83/usr/bin/php. Plainphpin a cron entry often resolves to the system PHP, which may be far older than the one your site uses. If the scheduler never runs, check this first. -
Document root: Domains → the domain → Document Root, pointed at
public_html/planvio/publicor wherever you extracted it. -
LVE limits: CloudLinux caps concurrent processes and memory per account. The queue
worker is short-lived by design and does not normally trouble these, but a very low
nproclimit can make cron entries fail intermittently rather than consistently, which is a confusing failure to diagnose. - CageFS: each account sees its own filesystem. Nothing in Planvio minds this, but it means a path you found in a general tutorial may not exist for you.
- PHP: Websites & Domains → PHP Settings, per domain.
- Document root: Hosting Settings → Document root.
- Cron: Scheduled Tasks. Choose "Run a PHP script" and Plesk supplies the correct binary for the domain's PHP version, which avoids the path problem above entirely.
Not shared hosting, but the most common non-cPanel case.
- Full walkthrough, including an Nginx server block: docs/DEPLOYMENT.md.
- The cron entries go in the web user's crontab (
www-data,nginx, whatever runs PHP-FPM) rather than root's — otherwise the files the jobs create are owned by root and the next web request cannot write them. - You may run a long-lived queue worker under systemd here, since you have one. Planvio does not need it and the cron entry still works; it just lowers the latency on notifications.
Planvio does not ship a Dockerfile, and that is a decision rather than an omission — the product exists to run where Docker does not.
Nothing prevents you writing one. If you do and it works well, a link here would be useful
to others. What it needs is ordinary: PHP 8.3+ with the listed extensions, a web server
pointed at public/, and the two scheduled jobs as either cron inside the container or
external invocations of artisan.
-
Hosts without
proc_open. Some very restricted shared plans disable it. The queue worker and the scheduler both need to spawn a process. - PHP below 8.3. The floor is real, not cautious.
- Hosts that only offer PostgreSQL. Planvio targets MySQL and MariaDB; the migrations are not written for PostgreSQL and it is listed in LIMITATIONS.md.
Wiki
Documentation (in the repo)
Get help