If you're not fond of cPanel and you want to use multiple VPSs you should definitely do it with docker, one container per client and then map them to a CNAME (e.g. www.website.com), you can use AWS, DO or any VPS provider with a mature API to automate the process, use logspout and ELK for logging and you're all set.
You can either choose to scale vertically (more servers) or horizontally (increase CPU/RAM).
So rather than finding one solution, you might think about putting your client's sites into different buckets. Some sites might be a small one-off that you're starting from scratch, and those might fall into the shared hosting bucket. Some might be bigger or use a different stack than your typical site and those could fall into the VPS bucket. The remainder might fall into that unknown/unknowable zone, so it'd be good to plan out a way of managing third-party or client-hosted sites.
I think it's a rare thing for an agency to start off a new client relationship with an entirely blank slate, it'd serve you well to be flexible.
But the choice between VPS and dedi depends on several factors (traffic, requirements, compliance, projections, etc). I always recommend starting small unless the business whose website being hosted is already established.
As far as the hosting platform is concerned, you should always seek to leverage a control panel. This is one of those things you wish you had only after you're stuck without one (we support panel-free servers too). Your clients don't need to contact you for every little change they need to make.
Sites that are 100% static content co-exist in a single jail but, other than that, it's one jail per customer (whether they have one or multiple sites). We would separate multiple sites belonging to the same customer into multiple jails if there was a good reason to, though.
Another jail runs nginx as a reverse proxy in front of the jails.
The big concern for me was the compromise of one site affecting other, unrelated customers. That's why we've separated them like this.