CrestVPS

reseller vps

Hosting resellers

Your brand on the panel, our hardware underneath.

What we would deploy

€86.73/mo

€123.9030% annual

Reselling works when the platform is boring and the margins are visible. Virtualizor lets you carve a TORQUE instance into your own VPS products with your own branding and your own price list; cPanel, Plesk and DirectAdmin are licensed and preinstalled if you are selling shared hosting instead. Clean IP ranges matter more here than anywhere else, and ours are audited before allocation.

Why this configuration

TORQUE has the cheapest dedicated cores and the most predictable disk performance, which is what your customers actually notice. Add a /29 so each client can have a distinct address.

What we would deploy

PlanTORQUE T3
vCPU16 (dedicated)
RAM64 GB
Storage800 GB
ImageAlmaLinux 9

Sizing

Count accounts, not cores. A TORQUE node with 16 dedicated cores and 64 GB carries roughly 150-250 typical shared-hosting accounts under Virtualizor, assuming per-account PHP-FPM pools with limits. The binding constraint is almost always NVMe IOPS during backup windows and mailbox writes, not CPU. Give every customer a hard disk quota and an inode ceiling from day one. Take a /29 for five usable addresses: one for the node, the rest for customers needing dedicated IPs.

Clean ranges, and keeping them that way

An IP's history follows it. Before you accept a block, check it against Spamhaus, SpamCop and the DNSBLs your customers' recipients actually use, and check the whole /29 rather than the first address. CrestVPS assigns from ranges it controls in its own cages, and PTR delegation is yours to set. After that the reputation is your responsibility. Rate-limit outbound SMTP per account, require SMTP AUTH, alert on any account exceeding its normal daily volume by an order of magnitude, and suspend rather than negotiate. Delisting takes days. Prevention takes an afternoon of configuration.

Virtualizor topology that survives growth

Run the Virtualizor master on its own small node, never on a node that also carries customers. When a hypervisor goes down you want the control panel still answering, and you want the master's backups independent of the machine that failed. Slaves are then disposable. Use KVM rather than containers where customers get root, keep one storage pool per slave on local NVMe rather than anything shared, and keep the master reachable only over the private VLAN plus a bastion. Adding a slave under this arrangement is a 47-second provision and a few minutes of configuration, so scale horizontally early.

What goes wrong

  • Overselling with thin LVM and no monitoring on pool metadata. When the metadata volume fills, the pool goes read-only and every container on the node stops at once. Alert at 70%.
  • Sending all customer mail from the node's main IP. One compromised WordPress install lists the address, and every unrelated customer's mail starts bouncing. Route outbound mail through a separate, dedicated address.
  • Skipping per-account IO limits. One customer's nightly rsync or an unindexed database will starve the whole node. Set io.max in cgroups v2 per container before the first customer arrives.

Tune the machine

  • Control panelVirtualizor (resell your own VPS) · €12
  • Addressing and transitIPv4 /29 subnet (5 usable) · €11
  • BackupsDaily backup, 30 restore points · €11
  • Addressing and transitCustom rDNS / PTR with SPF alignment · Included