Hosted vs BYOC
Every ModStack Project picks one of two hosting models for its infrastructure: Hosted, where ModStack runs everything for you, or BYOC (Bring Your Own Cloud), where the underlying compute lives in your own cloud account. The choice affects where your workloads physically run — not how you operate them.
Hosted
In the Hosted model, ModStack provisions and operates the underlying infrastructure on your behalf. You do not need a cloud account, you do not pick a region, and you do not manage any servers. Compute, network, and storage all sit inside infrastructure that ModStack owns, and billing flows through your ModStack plan.
This is the path of least resistance: you sign up, create a Project, and start deploying. It is the right default if you do not have strong reasons to run infrastructure yourself.
Bring Your Own Cloud (BYOC)
In the BYOC model, the underlying compute, network, and storage live inside infrastructure you own — your AWS account, your Azure subscription, your own servers. ModStack connects to it, deploys your workloads onto it, and operates them on your behalf, but the resources themselves sit on your bill.
Crucially, BYOC is still a fully managed environment. The difference between Hosted and BYOC is not "managed vs unmanaged" — it is "whose cloud account holds the resources." In both cases, ModStack handles deployments, rollouts, scaling, observability, and lifecycle for the workloads on top. Which features you get is determined by your billing plan, not by whether the cloud account is yours or ours.
Which Cluster types support which model?
Not every Cluster type supports both hosting models. The matrix below shows what is possible:
| Cluster Type | Hosted | BYOC |
|---|---|---|
| Kubernetes | Yes — ModStack provisions a managed Kubernetes cluster for you. | Yes — connect an existing managed Kubernetes cluster from a supported provider. |
| Single Node | Not supported. | Yes — connect an individual server you already own. |
| Local Dev | Always runs on the developer's own machine. Hosting model does not apply. | |
Why choose BYOC?
There are three common reasons teams pick BYOC over the Hosted model:
Control over your infrastructure
Some teams want their compute, networking, and data to live inside infrastructure they already operate — for compliance, network topology, data residency, or simply because they prefer to keep ownership of the underlying resources. BYOC keeps the substrate yours and gives you full visibility into it.
Leverage existing cloud commitments
If you have already spent on infrastructure with a cloud provider, you can put that spend to work. Reserved instances, savings plans, committed-use discounts, enterprise discount programs — anything you have negotiated with your cloud provider continues to apply to the compute that ModStack runs your workloads on, because that compute sits in your account.
Startup cloud credits
Many startups have meaningful credit balances from AWS, Azure, Google Cloud, or DigitalOcean — often tens or hundreds of thousands of dollars. In the Hosted model, those credits go unused for your ModStack workloads. In BYOC, the compute bill lands in your cloud account, which means startup credits cover it. This can be the single biggest lever in early-stage infrastructure costs.
The hosting model is set when a Project is created and cannot be changed afterwards. Pick deliberately — but know that the day-to-day developer experience is the same either way. If you want to use a mix of Hosted and BYOC, create separate Projects and Environments for each.