Ops Brief
Bots and automation hosting — Keep the automation off the box your clients live on
The scripts that run your business and the bot a client asked you to host have the same technical needs and completely different consequences when they fall over.
Straight answer first
Run resident processes on a small VPS with PM2 or systemd keeping them upright, and keep that box separate from the shelf your clients live on. The Economy tier carries a surprising number of bots for very little money, and the separation is what stops one careless script from being everybody's problem.
Below: why this never belongs on a client account, how to keep a process alive without babysitting it, why your own operational scripts and a client's bot should not share a machine either, and what to order.
Written by the Hosting Seller staff · Checked 24 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
A bot is the opposite of a website: almost no CPU demand, but an absolute need to stay running. That combination makes a small VPS its natural and cheapest home.
For a reseller there is a second reason to care. The automation that provisions accounts, watches your monitoring and chases your invoices is business infrastructure, and it should not be sharing a filesystem with a client's experiment.
Why this never belongs on a client shelf
Shared and reseller accounts are built for request-response work. A resident process holding memory for weeks is not what the resource limits were designed around, and it is the first thing to be killed when a machine gets busy.
Cron-only hosting looks like an answer and is not. A scheduled wake-up is not the same as staying alive, and the bot misses everything that happens in between two runs.
There is also the blast radius. A script with a memory leak on a client shelf is a support incident for accounts that have nothing to do with it.
Keeping a process alive without watching it
A process manager does this properly. A systemd unit or PM2 with startup hooks restarts on failure and brings the process back after a reboot, which covers the two failures that actually happen.
Add a health-check cron for belt and braces: something that verifies the bot is not merely running but responding, and restarts it if not. A process that is up and wedged is the failure mode nobody tests for.
Then log somewhere you will actually look. Set it up once and you can honestly forget about it, which is the entire point of the exercise.
Your ops scripts and a client's bot are not the same account
Provisioning scripts, monitoring agents and anything holding an API key to your billing system are business-critical. Treat them as production, back them up, and keep the credentials in a manager rather than in a file on the box.
A client's bot is a different risk profile. It is somebody else's code, it changes when they feel like changing it, and if it goes wrong you want the consequences contained.
Separate boxes are cheap at this size, and separation is the only thing that makes the difference between an inconvenient evening and a genuine incident.
The box to order
The plan for this is the Economy VPS. Root access, a flat price, and enough resources that VPN duty, a scheduler and a handful of bots barely register.
Memory is the real ceiling, so budget roughly 50-150MB for each Node or Python bot against your RAM and keep some headroom for spikes. Idle-heavy work such as Discord bots, schedulers and watchers stacks up generously.
It sits on the same shelf as the rest of the range, so a box that turns out to need more can be upgraded in place rather than rebuilt somewhere else.
The plan we will not sell you
We will not sell you a shared account for a resident process, because it will be killed and you will be told the platform is at fault. Saying so up front costs us a cheaper sale and saves us a support conversation neither of us enjoys.
Bring an existing site and we shift it across at no charge, usually inside 24 hours, with nothing going dark while we work.
- Root access, so systemd and PM2 are yours to configure
- Resident processes on a box built for them
- Separation between your ops and a client's code
- Upgrades applied in place when a box outgrows itself
Why Hosting Seller
On every plan, as standard
The plan behind this page
The Economy VPS gives root access and a flat price on a box that carries schedulers and bots without noticing them.
Processes that stay resident
A VPS is built for work that holds memory for weeks, which shared and reseller accounts are deliberately not.
Separation you can afford
At this size a second box is cheap, and separation is what keeps one careless script from becoming a client-facing incident.
Upgrades applied in place
A box that outgrows itself moves up on the same account rather than being rebuilt somewhere else.
A supplier you can name
IGI Security Services Ltd, registered in England and Wales, with terms published under English law.
Margin that survives renewal
The order price is the renewal price, so a long-running utility box does not quietly get more expensive.
First Steps
From choosing to live
- 1
Move resident work off the client shelf
Anything that has to stay running belongs on a VPS. Cron on a shared account schedules a wake-up; it does not keep a process alive between them.
- 2
Install the process manager before the code
systemd or PM2 with startup hooks, then a health check that tests responsiveness rather than presence. Up and wedged is the failure everyone forgets.
- 3
Split your automation from theirs
Business-critical scripts holding billing keys should not share a filesystem with a client's bot that changes whenever they feel like it.
In the Box
Packed with every plan
- Root access on the VPS range, with systemd and PM2 yours to configure
- KVM virtualisation with resources that are genuinely yours
- DDoS filtering handled out at the network edge
- Daily backups with restores you run yourself
- SSH, Git and Composer on the plans built for developers
- Free SSL on every site you host, reissued before it lapses
- Upgrades apply to the account in place, with no move between plans
- Nothing added at setup, no joining fee ever
- Real people on the counter, every hour of every day
- The renewal price on the tag matches the order price
Across the Counter
Things people ask us all the time
Why can a bot not live on a shared or reseller account?
Those accounts are built for request-response work with resource limits to match, so a process holding memory for weeks is the first thing terminated when a machine gets busy. Cron is not a substitute either: a scheduled wake-up misses everything that happens between two runs.
Who is on the hook when a client's bot stops overnight?
Whoever agreed to be, so agree it in writing. A systemd unit or PM2 with startup hooks handles the mechanical failures, and a health check catches the process that is running but wedged. What is left is somebody else's code failing on somebody else's schedule, and that is either a billable call-out or explicitly out of scope.
Should my own automation share a box with a client's bot?
No. Provisioning scripts and anything holding a key to your billing system are business infrastructure; a client's bot is somebody else's code changing on their schedule. At this size a second box is cheap, and separation is what keeps one problem from becoming two.
How do I price a box carrying several clients' bots?
From memory rather than from CPU, because memory is the ceiling. Budget roughly 50-150MB for each Node or Python bot against the RAM on the box and keep headroom for spikes. Then price for the attention rather than the resources: idle-heavy work stacks up generously, and what actually costs you is being asked about it.
Read next
Scalable Hosting Upgrade Paths
Reading the graphs before a client complains, and moving an account up without a migration.
Landing Page Hosting
Campaign pages built quickly and cheaply, and where they belong on your shelf.
VPS Hosting
KVM virtual servers with root access, DDoS filtering and one flat price.
Drupal Hosting
Drupal hosting with Composer, Drush and the PHP version set per site.
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.
Give the automation its own box.
KVM virtual servers with root access, DDoS filtering and one flat price, upgradeable in place when the work grows.
See VPS Hosting plans