Building and releasing features at a startup is already complicated enough. As an engineer, your priority is simple: ship robust features, fast. You cannot be expected to understand every detail of every enterprise customer’s infrastructure. Yet customers in healthcare, finance, defense, and critical infrastructure often require software to run inside environments they control. Patient records, transaction data, audit logs, IAM policies, and security tooling may all need to remain within the customer’s own cloud or data center.
Both self-hosted and BYOC, or bring your own cloud, offer significant value in these scenarios. In both models, the software runs inside the customer’s infrastructure. The difference is who is responsible for setting it up, keeping it updated, and debugging incidents.
To make this concrete, imagine a clinical-software vendor whose application must run inside a hospital’s cloud because it processes sensitive information such as clinical notes. Both self-hosted and BYOC can keep that information inside the hospital’s environment. As we will see, though, they create very different experiences for everyone responsible for operating the software.
Day 1: Getting the Software Running
When a customer chooses to self-host, the software vendor usually hands them a Helm chart, container image, or Terraform module with a set of deployment instructions. It is then up to the customer to translate these materials into a working deployment. In theory, this sounds reasonable. In practice, every deployment can involve hundreds of configuration options spanning networking, identity, storage, secrets, resource limits, and cloud-specific dependencies.
That leaves plenty of room for error. One incorrect environment variable or Terraform modification can bring the entire deployment down. A customer might modify the Terraform module to fit its existing VPC, IAM roles, or security groups, unintentionally violating assumptions elsewhere in the deployment. A restricted egress rule, for example, could prevent the application from pulling an image or reporting its health.
When things go south, the vendor is pulled into a screen-sharing session to view logs. Both the vendor and customer then spend hours trying to determine which value, permission, or dependency went wrong. The customer owns the deployment, but the vendor understands the product’s configuration assumptions and breaking changes. Without tooling that encodes that knowledge, every customer modification risks introducing drift or failure.
BYOC changes this day-one experience. The vendor controls the application configuration, while the customer has full visibility into both the configuration and the deployment process. The customer no longer has to comprehend every variable or reverse-engineer how the application’s components fit together just to run the software.
For the clinical-software vendor, this means the hospital can approve the application and its required permissions without determining how every chart value or dependency should be configured. What was previously a bespoke setup exercise becomes a guided, repeatable installation.
Day 2 and Beyond: Updates and Configuration
Getting the software running is just the beginning. With self-hosting, every update becomes a coordination exercise. The vendor documents the new version and any accompanying configuration changes, sends the instructions to the customer, and waits for the customer to apply them within its particular environment.
Now consider what happens across several customers. Customer A upgrades immediately. Customer B waits six months. Customer C modifies the deployment to satisfy an internal networking requirement. Customer D misses a required configuration change altogether. Before long, the vendor is supporting several versions of the same product, each with different infrastructure assumptions and varying degrees of drift.
The timing is also outside the vendor’s control. A customer might apply an update at 2 a.m. on a Sunday while the engineer most familiar with the release is on vacation. If the deployment fails or the customer overlooks a required step, the vendor could still be held responsible.
What This Looked Like at Airbyte
I saw a version of this problem firsthand at Airbyte, an open-source platform for moving data from operational systems into warehouses, lakes, and other destinations. Because those pipelines carried sensitive business data, many enterprise customers wanted Airbyte to run inside their own cloud or network boundary.
Airbyte had documentation for self-hosted deployments, but documentation could only go so far. Each customer brought different cloud accounts, IAM rules, networking constraints, Kubernetes configurations, security reviews, and approval processes. Our solution architects spent hours every day helping customers adapt configurations and debug deployments across environments.
The problem was not simply that upgrades were inconvenient. Self-hosting also constrained how the product could evolve. Every configuration or architectural change needed a migration path for customers using older versions or modified deployment modules—or whose infrastructure conflicted with the new assumptions.
BYOC gives the vendor a consistent way to manage the software lifecycle across customer environments: tracking versions, coordinating migrations, observing rollouts, and rolling back failed releases. The workload remains in the customer’s cloud without transferring the entire operating burden to the customer. In the hospital example, the vendor manages the application infrastructure inside the hospital’s cloud, while the hospital keeps the workload within its boundary without inheriting the day-to-day operating burden.
When Something Breaks: Debugging and Observability
In a conventional self-hosted deployment, the vendor may have little or no visibility into the deployed version, pod health, logs, environment configuration, or underlying infrastructure state. Debugging happens indirectly: the customer shares a screen, copies logs into a message, or runs kubectl and cloud-provider commands dictated by the vendor. This process is slow, lossy, and prone to human error. More importantly, the customer with access to the environment is not necessarily the person who understands the software.
Debugging becomes especially difficult in the hospital’s case. The vendor cannot simply ask for unrestricted access whenever something breaks; the environment contains patient data that must remain tightly controlled. But without any operational visibility, the vendor will struggle to diagnose even an ordinary deployment failure.
Self-Hosted
Debugging through calls, screenshots, and customer-run commands
BYOC
Direct operational visibility through a controlled agent, with a vendor engineer steering when needed
BYOC separates those concerns more deliberately. The vendor can receive the infrastructure metadata and logs needed to support the application without gaining access to the customer data it processes. For example, the clinical-software vendor might be able to confirm which Helm release is installed, see that a pod is failing, inspect its health status, or access an approved application log. None of that requires access to the patient records flowing through the application.
That visibility also creates room for AI-assisted operations. An agent could inspect permitted logs and infrastructure signals, compare a failure with previous incidents, and recommend or apply a fix. Instead of spending hours collecting basic context over Zoom, the vendor can use agents to triage and remediate issues directly. The point is not to give the vendor unrestricted access to the customer’s cloud. It is to provide the specific operational access required to maintain the software while preserving the boundary around the customer’s data.
Why Choose One Over the Other?
Self-hosted and BYOC can both keep sensitive workloads inside the customer’s cloud. That is crucial, but it is not the differentiator. The difference is who carries the operational burden after the software gets there.
With self-hosting, the customer must interpret the deployment, coordinate every update, and act as the vendor’s eyes and hands whenever something breaks. The vendor remains accountable for the product while losing the control and visibility needed to operate it effectively. BYOC preserves the customer’s security boundary without transferring responsibility for the software. Customers retain control of their infrastructure and data, while vendors can manage configuration, coordinate releases, prepare rollbacks, and diagnose failures.
At Ryvn, we make that separation practical. Vendors get the operational control needed to keep their applications reliable, while customers retain authority over what runs inside their environments and who can access their data. That is the art of BYOC: giving vendors enough access to do their jobs without asking customers to surrender control of their infrastructure or data. Neither side has to compromise.