cPanel AI App Hosting: enable Node.js apps for customers

AI App Hosting is the cPanel plugin that deploys a Node.js app from a Git repository, a ZIP file, or an AI agent over MCP, and runs each app in its own container behind the customer's domain. It shipped with cPanel & WHM v138 in July 2026 and has been updated every week or two since. The October builds added MySQL databases, health checks, and readable deploy errors.

This guide is for server owners deciding whether to switch it on. It covers what the customer sees, what you control in WHM, and the operational details the marketing skips. The question it answers is usually "a customer built an app in Claude or Lovable, so where do they host it?"

Prerequisites

• cPanel & WHM v138 or later. Servers on the LTS tier (v134) don't have it. See cPanel update tiers if you're pinned.
• The Meridian theme on the customer account. AI App Hosting lives in Meridian's Websites hub and has no Jupiter equivalent. The v138 release notes cover Meridian itself.
• The Web Apps feature enabled in the account's feature list.
• RAM headroom. Every running app is a long-lived Node.js process inside a container, not a PHP request that exits.

Check the version and the plugin before you start:

/usr/local/cpanel/cpanel -V
rpm -q podman

Hosts that have documented the feature report that it uses Podman for the containers.

Step 1 — Enable Web Apps for the right packages

Open WHM » Packages » Feature Manager and edit the feature list behind the plans that should get app hosting. Tick Web Apps and save. With the feature on, the customer's Websites hub is renamed Websites & Apps and AI App Hosting appears in the Add Website wizard.

Don't add it to your default feature list. Create a separate list for an "app" tier, as described in WHM packages and feature lists for tiered plans, and price it accordingly. A shared plan sized for WordPress has no allowance for a Node.js server that stays resident around the clock.

You also cap how many apps an account can run. Customers who hit the cap see a message asking them to delete an app or contact you.

Step 2 — What the customer deploys

The flow in Meridian is short:

1. Add Website, then pick an existing domain or Add another domain.
2. Choose AI App Hosting and click Launch My Website.
3. Pick a source: a Git URL (HTTPS for public repositories, SSH for private ones), Upload a ZIP file, or Deploy via WebPros MCP.
4. Optionally expand Advanced to set the Node.js version, the package manager, the build output directory, environment variables, and a database.
5. Click Deploy.

cPanel installs dependencies, builds the app, starts it in a container, and points the domain at it over HTTPS. Two behaviours generate tickets:

• Deploying onto an existing domain switches it from serving files to serving the app. The old public_html content stays on disk but stops being served.
• A new domain created during the deploy can't be renamed afterwards.

Private repositories need an SSH deploy key. Meridian walks the customer through creating one. The key passphrase is never stored, so the customer types it again on every redeploy. A force-push that rewrites history makes redeploys fail.

The MCP route is the one that lets Claude Code or another agent push the app directly. The access model matches cPanel's other MCP grants, so treat it the way you treat WHM API tokens and their scopes.

Step 3 — Databases and environment variables

Since plugin version 1.3.5 (13 October 2026), each app can have one MySQL database. The app either creates a new one, named after the app, or links an existing one with a new database user. Connection details are passed to the app as environment variables. The Database option appears only if you've enabled databases for the account.

Environment variable rules, which customers hit straight away:

• Names start with a letter or underscore and contain only letters, numbers, and underscores.
• PORT is reserved. The platform assigns it.
• Variables live in the app's own .env file. If Git tracks .env, the UI won't let the customer edit them.
• Restart does not pick up changes. Redeploy does, because every redeploy recreates the container (from 1.3.4).

If a customer changes the database user's password in the Databases hub, the app breaks until they remove the database from the app and link it again.

Step 4 — Health checks and failures

Plugin version 1.3.8 (26 October 2026) checks every app every five minutes. It repairs a reverse proxy pointing at the wrong port, which used to happen after a backup restore, and emails the account when a human has to act. Apps that crash repeatedly no longer show as running, and a down app now shows a branded page instead of an Apache error.

WHM API 1 exposes the health-check cooldown, the daily repair limit, and a server-wide alert address. It can also list apps that keep failing, check one on demand, and exclude an app from scheduled checks. Point the alert address at your monitoring inbox rather than root's mailbox.

Failed deploys now name the stage and the reason. The common ones are full disk and full quota. Before you debug the app, check the account's quota.

CloudLinux servers

Two fixes matter if you run CloudLinux:

• 1.3.0 added CageFS support, so apps can run for caged accounts.
• 1.3.3 fixed apps that failed to start on CloudLinux. The container's process limit now matches the account's LVE process limit.

That second fix means your LVE NPROC setting now constrains the app. A limit tuned for PHP workers can starve a Node.js app that spawns workers. Review it using LVE limit tuning before you sell app hosting on a CloudLinux box. If customers already run apps through CloudLinux Node.js Selector, you now have two competing deployment paths. Pick one per plan and document it.

Step 5 — Clean up deploy leftovers

Builds leave staging directories, interrupted uploads, and per-deploy logs in ~/.cpanel/logs/ named <epoch>-deploy-<app>.log. Plugin 1.3.4 ships a cleanup script that lists anything older than one month and deletes it only when asked:

/usr/local/cpanel/scripts/webapp_cleanup.pl
/usr/local/cpanel/scripts/webapp_cleanup.pl --run

It always keeps each app's most recent deploy log. It exits non-zero if it can't remove a file, so it's safe to cron weekly with output mailed to you. On a server that is already tight on space, run it before you work through freeing a full disk.

Is it worth offering

It's worth offering on VPS, dedicated, and a priced "app" tier. It isn't worth it as a default on dense shared hosting. AI App Hosting does what CloudLinux's selector never quite did: build commands, framework detection (TanStack Start since 1.3.4), and a proper container per app. The cost is that each app is a resident process, and the plugin is four months old and still changing every week or two. Read the AI App Hosting release notes before each update, and keep it off the LTS tier fleet until it settles.

You need an active cPanel license on v138 to use it.

Next steps

• What changed in cPanel & WHM v138: Meridian, AI Assistant, Nova
• Set up CloudLinux Node.js Selector on a cPanel server
• WHM packages and feature lists for tiered plans