Inventory Management on cPanel: A Practical Setup Guide

You can run real inventory management on cPanel, and for a lot of small warehouses and online sellers it's the cheapest path to a working system. The catch is that shared hosting has hard limits (PHP timeouts, memory caps, a shared MySQL server, coarse cron intervals), and inventory software tends to be write-heavy at exactly the moments those limits bite. This guide shows you how to set it up properly, how to size your plan with real numbers, and the point where you should stop fighting cPanel and move to a VPS.

Why cPanel is a reasonable place to start

Most self-hosted inventory apps are a PHP plus MySQL stack, which is precisely what cPanel is built for. You get a few things for free that would otherwise cost you a weekend:

• Hosting you probably already pay for, often under $10/month.
• One-click database creation, phpMyAdmin, and a File Manager.
• AutoSSL for free HTTPS certificates.
• Managed backups and PHP version switching through MultiPHP Manager.

The trade-offs are just as real. Shared plans throttle CPU and memory, cap the number of concurrent "entry processes" (often around 20), enforce a max_execution_time, and give you no long-running background daemons. None of that is fatal. You just have to design around it.

What you actually need

Before you install anything, confirm your plan meets these. If your host hides these settings, open a ticket and ask directly.

Requirement	Minimum	Notes
PHP	8.2+	With pdo_mysql, mbstring, bcmath, intl, gd, zip, fileinfo
Database	MySQL 8 / MariaDB 10.6+	One DB and one user is enough
memory_limit	256 MB	128 MB will choke on large exports
Document root control	Yes	You must point the domain at a /public folder
Cron jobs	1-minute interval	Drives queues and scheduled syncs
SSH / Terminal	Strongly recommended	For Composer, migrations, and Git

If your host offers a "Terminal" in cPanel, that counts as SSH access for most of this. Without it, you can still upload a release zip through File Manager, but you lose Composer and command-line migrations, which makes upgrades painful.

How to set up inventory management on cPanel

Here's the sequence that works reliably across most cPanel hosts.

1. Set the PHP version. In MultiPHP Manager, pick 8.2 or newer for your domain, then confirm the required extensions are enabled in the PHP selector.
2. Create the database. Use MySQL Databases to make a database and a user, grant all privileges, and write down the exact names. cPanel prefixes them with your account name.
3. Get the code onto the server. Best case, SSH in and git clone into a folder above the web root, then run composer install --no-dev. Otherwise upload a release archive to File Manager and extract it.
4. Fix the document root. Inventory apps serve from a /public subfolder. The clean fix is to create a subdomain (or addon domain) whose document root is /yourapp/public. Never expose the app root directly, or you leak your .env.
5. Configure the environment. Copy .env.example to .env, set your DB credentials, APP_URL, and generate an app key.
6. Run migrations. From Terminal, run your app's migrate command to build the schema. This is where SSH pays for itself.
7. Wire up cron. Add a cron entry that runs every minute to fire scheduled tasks and drain the queue (more on this below).
8. Turn on AutoSSL. Issue a certificate for the subdomain so scanners and API clients talk over HTTPS.

The queue problem, and the fix

Shared hosting has no supervisor and no persistent worker process, so you cannot leave a queue:work daemon running. Instead, let cron do it. Point a one-minute cron job at a worker that processes whatever is waiting and then exits, for example queue:work --stop-when-empty. Stock adjustments, low-stock alerts, and webhook deliveries then flush within roughly 60 seconds. That latency is fine for a small operation and unacceptable for a high-volume storefront, which is one of the clearest signals you've outgrown cPanel.

A worked example: will your plan handle it?

The number people worry about is database size. It's almost never the real constraint. Here's a quick way to size it.

Stock movements per year = orders/day x average lines per order x 365, plus receiving and adjustments (add roughly 30%).

Say you ship 150 orders a day at 3 lines each:

• 150 x 3 x 365 = 164,250 movement rows/year
• Add ~30% for receipts and manual adjustments = ~213,000 rows/year

At a few hundred bytes per row plus indexes, that's roughly 60 to 120 MB of movement data per year. A typical 5 GB shared plan holds years of history before disk becomes an issue, and MySQL handles millions of rows without breaking a sweat. What fills disk first is product images, not transactions.

The real ceiling is concurrency. If three warehouse staff are scanning while a storefront syncs over the API, you're comfortably inside a 20-process cap. Put 20 pickers hammering the API simultaneously during a sale and you'll start seeing throttling. Size for peak concurrent writes, not total records.

cPanel vs VPS vs Docker

	cPanel (shared)	VPS	Docker
Cost/month	$5-15	$6-40	Host-dependent
Setup effort	Low	Medium	Medium
Concurrency	Limited (~20)	Good	Good
Background jobs	Cron only	Real workers	Real workers
Redis / search	Rare	Yes	Yes
Best for	Starting out, low volume	Growing ops	Reproducible deploys

Where cPanel stops being enough

Move up when you see any of these:

• Queue backlog builds because a one-minute cron can't keep pace with orders.
• Large exports or reports throw 500s from the memory limit.
• API partners need webhooks delivered in seconds, not up to a minute.
• You need Redis, full-text search, or a genuine queue daemon.
• Multi-location, near-real-time stock sync at volume.

None of these mean cPanel was a mistake. It means the business grew, which is the good problem.

Where Inventoros fits

Inventoros installs on cPanel, a VPS, or Docker from the same MIT-licensed codebase, so it's free, open source, and fully self-hosted. Out of the box you get multi-location stock, a REST and GraphQL API, webhooks, and an MCP server, which means starting on cPanel today and moving to a VPS next year is a configuration change, not a migration project. The full install steps for each environment are in the documentation.

FAQ

Can I run inventory management on cPanel with a shared hosting plan? Yes, for small to mid-size operations. As long as you have PHP 8.2+, MySQL 8 or MariaDB, cron, and control over the document root, a shared plan runs a full inventory system fine. The limits you'll meet first are concurrent processes and background-job latency, not database size.

Do I need SSH access? It's strongly recommended. SSH (or the cPanel Terminal) lets you use Composer, run database migrations, and update with Git. You can install from a release zip and phpMyAdmin without it, but every upgrade becomes a manual chore, and you lose easy command-line troubleshooting.

How do background jobs and queues work without a daemon? Through cron. Shared hosting won't keep a worker process alive, so you schedule a one-minute cron job that processes the queue and exits. Alerts, syncs, and webhook deliveries then flush within about a minute. If you need sub-second delivery, that's your cue to move to a VPS with a real worker.

Will it handle barcode scanning and multiple users? Yes, up to a point. A handful of staff scanning over HTTPS sits comfortably within shared-hosting limits. Once you have many concurrent users or heavy API traffic during peaks, the entry-process cap becomes the bottleneck and a VPS is the right next step.