Should self-hosted deployments be vendor or customer managed?

Self-hosting is a popular deployment model for security conscious software buyers, especially large enterprises in regulated industries. But it is challenging for software vendors to support, and as a result is expensive for customers.

One solution to this challenge is vendor deployment management, in which the vendor has full access to the self-hosted environment to manage the deployment, sometimes referred to as Bring Your Own Cloud (BYOC). This contrasts with customer managed self-hosted deployments where the vendor does not have access to the deployment, and the software is managed by the customer with support from the vendor.

When should software vendors choose customer managed vs vendor managed deployment? We’ll explore both options, and when each makes sense

Customer managed deployments

Self-hosting covers a broad range of deployment models, from deploying to on-premise servers to private cloud accounts. The common theme is that the vendor does not usually have access to the deployment, which ensures the data of the customer is not accessible to the vendor. Responsibility for managing the deployment is then with the customer.

Customer managed deployment requires significantly higher support overhead from the vendor, even though the vendor is not directly managing the deployment. Every issue that comes up during deployment or upgrades has to be resolved by the customer with support from the vendor, rather than being directly completed by the vendor. The vendor will then charge the customer for this support, resulting in significantly higher cost to purchase software on a self-hosted rather than SaaS-hosted basis.

For vendors, this means large amounts of time will be spent helping customers through upgrades, deployments, and debugging of issues, all in unfamiliar environments. This operational support work is a distraction from building the product, and does not improve the experience for other customers.

For customers, this will result in delayed time-to-value for the software, significantly more devops capacity required to manage the deployment, higher risk of downtime, and a much higher price point.

Vendor managed deployments

Vendor managed deployments grant the vendor of the software access to the environment for management purposes, including managing deployments, upgrades, and debugging issues. The software is still deployed into the customer's environment, but the key difference is that the vendor has full access to that environment. 

This results in lower total financial and time cost of ownership when compared to customer-managed deployment, and is a middle ground between full customer managed self-hosted and cloud SaaS deployment. 

The big downside of this deployment model is that it requires sharing access to the deployment with the vendor. Most customers who want to self-host do so because they do not want to share their sensitive data with the vendor, and if the vendor is granted access to the deployment for management purposes this argument is significantly undermined. The benefit of this deployment model is that the vendor can manage the software, which is their area of expertise.  

For customers, this still counts as a self-hosted deployment model but at significantly lower operational and financial costs, and much less requirement for DevOps expertise. 

For vendors, this enables the adoption of many best practices around automated upgrades and monitoring that are much more challenging when data can’t be shared back from the customer to the vendor in a truly self-hosted environment.

When should each be chosen?

Agreeing responsibility for the management of a self-hosted deployment comes down to the security requirements of the customer. Why do they want to self-host in the first place, instead of using cloud SaaS? Do they have the DevOps experience and budget to self-manage?

Vendor managed deployment is significantly easier for both the vendor and the customer, but this comes at the tradeoff of security. While the customer can honestly say the application is being self-hosted, the fact remains that a third party has access to this data, even if restricted by business and process limitations. This means the vendor may need to be added as a data sub-processor, but is still more secure than a SaaS application.

Customer managed deployment should be chosen by those who require data to not be accessible by any third party, and who are happy to shoulder the increased financial and operational costs of managing the deployment. 

I’d love to chat to share ideas and get feedback from anyone that offers customer-hosted deployment options and is thinking about these problems. Please reach out on LinkedIn or at henry@context.ai