Best Practice for scaling?

[RADRaze2KX]

Hi everyone, I'm new here and new to using WHMCS. So far, here's what I've got:

1. VPS Server A : WHMCS on Linux (2 CPU, 4GB RAM, 50GB NVMe)
2. VPS Server B : WordPress on Linux, bridged to WHMCS using WHMpress (2CPU, 4GB RAM, 50GB NVMe)
3. VPS Server C : Linux Server running DirectAdmin (2CPU, 4GB RAM, 100GB NVMe)

I'm not a Linux guy... primary business is actually MSP / Consulting for SMB, primarily running Windows systems, a few running MacOS. My question is, what's the best practice to scale? Do I need to set up VPS Server D from scratch, installing Linux and DirectAdmin the way I did with VPS Server C, or can I clone VPS Server C, change a few settings, and continue? Is there a simple deployment method to spin up new DirectAdmin servers for use with WHMCS?

[RADRaze2KX]

I may also be approaching this wrong (the 3+ server setup). We already have an established Web Design company, we're just adding hosting to make it easier for us to manage and deploy new systems. If we get random sign-ups from the internet, great.

Most of the guides I saw for starting a hosting company using WHMCS seem... insecure. A lot of the guides say to install WHMCS to your WordPress installation, which seems like a pretty poor way to go about doing it. Hence Servers A and B.

However, those guides also show deploying WHMCS using an existing hosting platform like Verpex or NameHero, where the "Host" (us) just deploys as they go. What's the best procedure for adding actual hosting servers where our customers (and we) will set up new websites with DirectAdmin as the backend?

[RadWebHosting]

9 hours ago, RADRaze2KX said:

Do I need to set up VPS Server D from scratch, installing Linux and DirectAdmin the way I did with VPS Server C, or can I clone VPS Server C, change a few settings, and continue? Is there a simple deployment method to spin up new DirectAdmin servers for use with WHMCS?

While I'm admittedly more familiar with cPanel, there is definitely a way "clone" the server configuration to reduce the administrative expense of setting up servers from scratch. In fact, there are numerous ways to achieve this, depending upon numerous factors, such as your deployment "toolbox" (what environments, procedures, and software are involved with your server deployment).  I would hesitate to start naming any specific methods or devices, but I will mention that even in the worst case (like if you physically go to the data center with your USB 😁), you can always utilize a shell script to run most of your build tasks in an unattended manor.

You're wise to be contemplating these issues now, as it's never too early to be optimizing your operating procedures for scale.

[RadWebHosting]

9 hours ago, RADRaze2KX said:

Most of the guides I saw for starting a hosting company using WHMCS seem... insecure. A lot of the guides say to install WHMCS to your WordPress installation, which seems like a pretty poor way to go about doing it. Hence Servers A and B.

Most of the guides show this because there is a significant number of people who spend a good deal of their days trying to achieve ways to merge WordPress and WHMCS in the least recommendable ways known to man.

I could not agree with you more. If I could only offer 1 piece of advice to the world, it would be to keep these two softwares in their respective environments and that just because there may be a product on the market that claims to have the WordPress/WHMCS bridge to paradise, this in no way changes the fact that neither WHMCS or WordPress have ever recommended a mashup of their softwares.

Having had several clients over the years, who also operate as hosting providers in their own rights, we've come across these mad scientists more times than we'd care to remember and most of them have trouble acknowledging that all the weird, unnatural integrations they've implemented are causing 90% of their support issues, and meanwhile, negatively impacting their business.

It's fine for not all of the software a business uses to be stored in the same folder and they don't need to all share database passwords, one to another and another to one, but maybe I'm just old school.