Backend API / DOKS

Overview

Variant overview

Provision a Kubernetes foundation for the API, with cluster-first operations and public ingress.

Manifest file

Edit backend-api-kubernetes.environment.yaml to change the scenario.

Rendered output

OPSd renders the manifest into OpenTofu under rendered/backend-api-kubernetes.

Supported changes

The variant defines which add, remove, and scale operations are supported.

Good fit

Kubernetes is already the intended operating model; the team expects cluster-first operations; platform conventions such as GitOps are already part of the rollout plan

Tradeoff

Highest operational overhead of the currently supported variants.

What gets created for this setup

This diagram shows the result you get after rendering the selected variant.

Infrastructure shape

Before you start

Shared setup is covered in Installation and the Introduction. This section lists the minimum things you need before the first render for DigitalOcean.

Installation install the shared OPSd CLI.
Introduction understand the workflow boundary and required toolchain.
GitOps and cluster operations are already part of the team workflow.

Initialize this variant

Use this path when the team is already committed to Kubernetes as the operating model.

Initialization sequence

opsd list blueprints
opsd init blueprint backend-api backend-api-kubernetes.environment.yaml --variant kubernetes
opsd validate manifest backend-api-kubernetes.environment.yaml
opsd render manifest backend-api-kubernetes.environment.yaml --output rendered/backend-api-kubernetes
cd rendered/backend-api-kubernetes
tofu init
tofu plan

# review the rendered output before planning
cd rendered/backend-api-kubernetes
tofu init
tofu plan

Edit the manifest

Most updates stay in manifest and GitOps flow, but cluster operations require more discipline than VM or App Platform variants.

Supported change commands

Keep the initial shape

Make only supported manifest changes for this variant.

opsd validate manifest backend-api-kubernetes.environment.yaml

Edit, validate, render

# edit backend-api-kubernetes.environment.yaml

# validate the config before rendering
opsd validate manifest backend-api-kubernetes.environment.yaml

# render the updated output and review it
opsd render manifest backend-api-kubernetes.environment.yaml --output rendered/backend-api-kubernetes
cd rendered/backend-api-kubernetes

# plan and apply only after the diff is clear
tofu plan
tofu apply

Supported changes

These examples come from the variant capability map and show the supported add, remove, and scale operations for this setup.

Keep the initial shape

Make only supported manifest changes for this variant.

opsd validate manifest backend-api-kubernetes.environment.yaml

Changes are not active yet

Editing the manifest changes the desired state. To make it real, validate the manifest, render the updated output, and then run `tofu apply` against the rendered directory.

opsd validate manifest backend-api-kubernetes.environment.yaml
opsd render manifest backend-api-kubernetes.environment.yaml --output rendered/backend-api-kubernetes
cd rendered/backend-api-kubernetes
tofu plan
tofu apply

Operational boundary

These are the constraints that define the supported shape for this variant.

This is the top-end operating model in the current scenario family.
No deeper supported path exists in the current catalog.
If this shape stops fitting, the next step is a new scenario rather than a deeper variant.

Related variants

Use the scenario overview to compare the other supported variants for the same blueprint.

Scenario overview