Supported Paths
See what OPSd supports today.
Use this page to check the current provider, the supported starting scenarios, and the growth paths that are already modeled.
Start from a scenario your team can own
The supported catalog is not one fixed stack. The same workload can appear in several variants so the team can choose an operating model it is ready to own.
Web, API, and CMS baselines
Core application starting points include web apps, backend APIs, backend APIs with data services, and CMS workloads.
Static delivery and assets
Static delivery has its own starting paths, while asset delivery has dedicated object storage and CDN paths.
Kubernetes as a first-class path
If the team already needs a cluster-first operating model, Kubernetes foundation and Kubernetes-based application variants are part of the supported surface.
Variants are part of the supported model
- The same product shape can appear in more than one variant, such as VM, App Platform, or Kubernetes.
- The point of variants is to let the team choose an operating model it actually understands today.
- OPSd is not trying to force every user into the most advanced stack on day one.
- A simpler variant can be the right starting point if it keeps the team moving with fewer operational surprises.
Grow deliberately, not only by adding more
Growth is not only about making the same stack larger. OPSd also supports moving a workload to a better-fitting path when the shape changes.
Grow inside the same variant
Supported growth includes resizing resources, scaling compute groups, adding load balancers, adding cache, adding databases, and adding CDN endpoints where the scenario supports it.
Move to a better-fitting variant
Growth can also mean moving from one supported operating shape to another, such as starting from a VM-based path and later moving toward Kubernetes when traffic, team maturity, or operational needs justify it.
Keep the same mental model
The important part is that growth still flows through supported scenarios, manifest changes, validation, and re-rendering.
What is supported today
The current boundary is intentionally specific: provider focus, supported variants, and the growth paths the product models today.
Current provider path
OPSd currently supports DigitalOcean. Other provider paths are part of the longer-term direction, not the supported surface today.
Supported means explicit
The supported surface is the set of blueprint variants, rendered scenarios, and growth actions that are already modeled, smoke tested, and verified in the current product boundary.
Growth is not only bigger sizes
A path can grow by adding resources in the same operating model, but also by moving to another supported variant when the workload outgrows the original shape.
Know where the path ends today
Clear limits help teams avoid false assumptions, choose the right path earlier, and understand when a different approach is needed.
- OPSd does not claim to solve every cloud topology or every platform concern today.
- Hand-editing generated infrastructure code is outside the intended supported workflow.
- The current supported provider surface is DigitalOcean, not every cloud.
- If a scenario, variant, or transition is not explicitly modeled, do not assume it is supported.