Runtimes & Tools
Language Runtimes and Tools is an inventory of the language runtimes and developer utilities installed on the server, with their versions and exact paths on the filesystem.
It answers one question: what can my app servers, cron jobs, and terminal sessions run, and how do I call a particular version?
You can't add a runtime to the server from this page, but a runtime can offer what it manages inside your own home directory, with a tab for it on its detail page. Perl is the first one. See Install your own packages.
The panel builds it by scanning the server's installed binaries, so it's the same for every account and only your hosting provider can add to it; what you install stays in your own home directory (see below). The list is refreshed at intervals, so a runtime installed recently can take some time to appear.
What the page lists
| Category | Entries |
|---|---|
| Language runtimes | PHP, Node.js, Python, Ruby, Perl, Go, Rust, Java, .NET, Deno, and Bun. Often several versions of one runtime are installed side by side. |
| Package managers and utilities | Composer, npm, Yarn, pnpm, uv, Bundler, cpanminus, Gradle, Maven, Git, WP-CLI, and Symfony CLI. |
A Java entry says whether it's a JDK or a JRE, and which distribution. A .NET entry separates the SDK from the runtime.
Select a tool to open its detail page, which has a Paths section with the full path of each matching binary, and short usage examples for the common runtimes.
A runtime's detail page has these tabs:
| Tab | What it holds |
|---|---|
| Overview | The paths, the usage examples, and what the panel expects for this runtime. |
| Modules | What the runtime can install into your home directory. Only a runtime that offers this has the tab. |
| Activity | Every job you asked for on this runtime, newest first: what was asked, who asked, and how it came out. The tab appears after the first job. |
A job runs in the background; its page shows what the tool prints as it works, and you can leave it. The Activity tab shows the result later.
Run a specific version
Several versions of one runtime can be installed. How you call the runtime decides which one runs; no panel setting does.
- An explicit path, copied from the tool's Paths section, is the most reliable way, in an app server script, a cron job, or a shell command.
- A command with a version suffix, e.g.
node-22ornpm-22, pins a version without the full path. Not every runtime has one.
python or node follows the server defaultThat default can change when your provider updates the server. Anything that must not break should name the version it needs.
PHP versions
PHP is the exception: its version belongs to a directory, not a
command, and php follows the directory it runs in.
Its detail page lists the handler name and the loaded extensions, and has a Show phpinfo() button. PHP explains how to choose a version and change settings.
Install your own packages
Every runtime supports installing into a project in your home directory; each tool's detail page has the exact commands. In short:
| Runtime | Install into your project |
|---|---|
| Node.js | npm install <package>. npx <package> runs a package without installing it. |
| Python | Create a virtual environment with python -m venv myenv, then source myenv/bin/activate. |
| PHP | composer require <vendor>/<package> |
| Ruby | gem install <gem> |
| Perl | The Modules tab, or run cpanminus yourself. See below. |
| Go and Rust | go get and cargo add. Dependencies belong to one project by design. |
For a WordPress site, WP-CLI is available from the terminal to manage the core, plugins, and themes.
Perl modules
The Perl detail page's Modules tab lists the modules you installed into your home directory, and installs and removes them. The modules that ship with Perl itself are always available and aren't listed.
The panel installs a module with cpanminus, as you, into a directory in your home directory. Nothing is installed system-wide, and nothing you install reaches another account. An install fetches and builds the distribution, so it can take a few minutes.
The panel also keeps a shell file that puts your modules on Perl's search path. Every new shell reads it, so an installed module is available in your terminal and cron jobs right away. If you change or delete that file, Repair Environment on the Modules tab writes it again, without removing any module.
A module you install somewhere else works, but the panel can't list or remove it. The Overview tab names the directory the panel uses.
Module management needs a cpanminus that belongs to that interpreter; a module one interpreter installs isn't usable by another. Where the panel can't pair the two, the Overview tab says so and there's no Modules tab.