Ops Brief
Hosting a client's application without inheriting it
The risk with a client's application is not the server, it is quietly becoming the person responsible for code you did not write.
Straight answer first
Sell Business hosting for a standard-stack application and move to a VPS the moment the architecture stops being conventional, then write down what you support before the first deployment. Hosting a bespoke application is straightforward; owning it by accident is what costs a reseller money.
Below: how to draw the support boundary, the runtime checklist to run before you quote, how to keep the client's staging and production apart from each other and from your shelf, and when the account should become a server of its own.
Written by the Hosting Seller staff · Checked 4 August 2026
24/7
Answered by people, for you and them
1-click
WordPress setup in every account
Free
Certificates on every site you host
Daily
Backups across every account
Application hosting is decided by a distinctly unglamorous list: whether cron fires accurately, how many workers you get, what the database allocation is, and whether anyone can read the logs. Brochure-hosting comparisons never print any of it.
For a reseller there is a second list, and it is the one that matters commercially: which of those things you will look at when the client says the app is broken, and which you will not.
Scope it before you host it
Write down three lists. What you support without question: the account, the certificate, DNS, mail, backups and restores, PHP or runtime versions, cron configuration. What you support at an hourly rate: deployments, environment variables, log reading, database work.
And what you do not support at all: the application's own code, its dependencies, and anything a third-party developer built. Say so in the agreement rather than discovering it at nine on a Friday.
This is the whole difference between a profitable application account and one that quietly consumes a developer's week. Clients accept a clear boundary readily; they only resent one that appears after the fact.
The runtime checklist you run before quoting
Which runtime and version: PHP, Node or Python, and whether the version the app needs is one you can set per site from the panel. Which database, and how large it is today.
Whether there is background work, because cron, queues and long-running workers are where shared-class hosting either fits or does not. Whether the app writes to the filesystem, and how much.
Then whether anybody can read the logs. An application you cannot get diagnostics out of is an application you cannot support at any price, and that is worth knowing before the quote rather than after.
Keeping staging, production and your shelf apart
Separate subdomains or separate accounts, each with its own configuration. It is cheap discipline that prevents expensive accidents, and the multi-site allowance from the Pro tier upward makes the second environment effectively free.
Keep the client's application account away from the accounts carrying your ordinary brochure clients where you can. Applications get deployed to, which means they change more often and fail in more interesting ways.
And keep credentials out of your inbox. A shared password manager entry per client is a small habit that becomes essential the first time a staff member leaves.
The account to sell, and when it becomes a server
The plan for this is Business Standard. Standard frameworks such as Laravel, Django or Express on conventional architecture run well on it: managed, cheaper than a server, and quite sufficient.
Custom daemons, heavy queues, websockets or an unusual stack are where the VPS line sits. That is a repricing conversation and a support-boundary conversation at the same time, because a VPS shifts far more of the administration onto whoever agreed to look after it.
Order an annual plan and the first year of the domain registration is included, which is a small but useful thing to have on a project quote.
What we will and will not look at
We hold the same line with you that we are suggesting you hold with your clients. The platform, the runtime, the cron and the restores are ours; your client's application code is not, and pretending otherwise would help nobody.
Real people answer the counter at any hour, including the awkward questions other hosts wave off as out of scope.
- Runtime versions set per site from the panel
- Cron, queues and workers on the plans that carry them
- Several environments on one account from the Pro tier up
- Escalation that comes back to you, not to your client
Why Hosting Seller
On every plan, as standard
The plan behind this page
Business Standard carries the developer kit a conventional application needs, managed, with the essentials already in the price.
Runtimes you control
PHP versions set per site from the panel, with Node.js and Python available on the plans built for it.
Environments without extra accounts
From the Pro tier upward one account carries several sites, so staging costs configuration rather than money.
A second line behind you
Escalate platform questions to us and pass the answer on. Your client never meets the supplier.
A supplier you can name
IGI Security Services Ltd, registered in England and Wales, with terms published under English law.
One shelf, every size
Shared, VPS and dedicated under one account, so an application that outgrows managed hosting moves without changing supplier.
Price Tags Compared
How we compare with the household names
Typical sign-up and renewal prices across the market, set next to ours — the second number most comparison charts leave off.
| Line item | Hosting SellerBest seller | Typical big-brand host | Typical budget host | Typical loss-leader |
|---|---|---|---|---|
| Entry price / mo* | $2.42/mo | $4–$6 | $2–$4 | $1–$3 |
| Price at renewal / mo | $2.42/mo | $10–$15 | $8–$12 | $4–$6 |
| Renewal price on the entry plan is unchanged | ||||
| SSL on every plan | ||||
| Site migration included | ||||
| The entry plan uses NVMe storage | ||||
| Entry plan gets a backup daily | ||||
| Live human support, 24/7 |
*The number in our column is the cheapest plan on our shelf, priced on an annual term and pulled live from the very catalogue that feeds the pricing page, so it cannot drift out of date. Other columns show the ranges shared hosting tends to advertise inside each bracket: introductory rates that normally ask for a one-to-four-year commitment, then climb once that term expires. Naming individual competitors and printing their prices is something we have stopped doing. A figure we cannot re-check on the day you read it has no business sitting in front of you. So compare us with whoever you are genuinely weighing up, and read the renewal line first. That line tells you more than the headline ever will.
First Steps
From choosing to live
- 1
Write the three support lists
Supported, supported at an hourly rate, and not supported. Agree them before the first deployment, because a boundary set afterwards reads as a retreat.
- 2
Run the runtime checklist before you quote
Runtime and version, database size, background work, filesystem writes, log access. Any one of those can move the job from a shared account to a server.
- 3
Build staging on day one
A second environment on the same account costs configuration rather than money, and it is the only thing standing between a deployment and a client's live application.
In the Box
Packed with every plan
- PHP versions picked per site from the panel
- SSH, Git and Composer on the plans built for developers
- Cron jobs configured from the panel, with output you can capture
- Several sites on one account from the Pro tier upward
- Staging copies so a deployment is tested before the client meets it
- Daily backups with restores you run yourself
- Free SSL on every site you host, reissued before it lapses
- Site migration handled by our staff at no charge
- A 30-day money-back guarantee on hosting plans, 7 days on reseller
- Real people on the counter, every hour of every day
Across the Counter
Things people ask us all the time
How do I stop supporting a client's application by accident?
Write the boundary down before the first deployment: platform, runtime, cron, backups and DNS are yours; the application's code and dependencies are not; deployments and log reading are billable. Clients accept a clear line easily and resent one that appears after a bad Friday.
Which client applications justify a server of their own?
The ones with custom daemons, heavy queues, websockets or an unusual stack. Standard frameworks such as Laravel, Django or Express on conventional architecture run well on Business tiers: managed, cheaper, and quite sufficient. Crossing that line is a repricing conversation as much as a technical one, because a server moves administration onto whoever agreed to look after it.
What should I check before quoting an application account?
Runtime and version, database size today, whether there is background work such as cron or queues, how much the app writes to disk, and whether logs are readable. An application you cannot get diagnostics out of cannot be supported at any price.
Where should a client's staging environment actually live?
On a separate subdomain or a separate account with its own configuration, never as a folder inside production. From the Pro tier upward the multi-site allowance makes the second environment effectively free, which removes the only excuse anyone ever has for deploying straight to a client's live application.
Read next
Hosting With a Free Domain
The domain-plus-hosting sum on a new client quote, and which part is genuinely free.
Domain and Hosting Together
Whether to bundle the name with the hosting on a client account, and what that commits you to.
Business Hosting
Shared hosting with the developer kit: SSH, Node.js, Python and PostgreSQL.
Domain Names
Search, register and transfer names, with year one free on annual hosting.
Moving your site to another host? Start with this checklist.
A step-by-step order of work for a move your visitors never spot: which files to copy first, how to carry email across without losing one message, the right moment to repoint DNS, and the two mistakes behind nearly every hour of downtime people ring us about.
Host the app, not the responsibility.
Managed accounts with SSH, Git, cron and per-site runtime versions, plus a second line you can escalate to.
See Business Hosting plans