Multi-cloud deploy
The object-storage providers knext supports across GKE, EKS, AKS, and OKE.
knext deploys on any Kubernetes cluster with Knative Serving — GKE, EKS, AKS, OKE, or bare-metal.
Build output (static assets) is uploaded to an object store keyed by build ID, and served from
assetPrefix.
Supported storage providers
The kn-next config validator accepts exactly these storage.provider values:
const SUPPORTED_STORAGE_PROVIDERS = ['gcs', 's3', 'minio', 'azure'] as const;| Provider | Cloud | Uploads via | Notes |
|---|---|---|---|
gcs | GKE / Google Cloud | gsutil | Google Cloud Storage. |
s3 | EKS / AWS | aws | S3, or any S3-compatible store via endpoint. |
minio | Any / self-hosted | mc | MinIO or S3-compatible clusters. |
azure | AKS / Azure | az | Azure Blob Storage; bucket is the blob container. |
Each provider shells out to that cloud's CLI, which must be installed and authenticated in the
build environment (for example AZURE_STORAGE_ACCOUNT / az login for Azure, application-default
credentials for gsutil, an IAM role or keys for aws). knext never handles cloud credentials
itself — it invokes the already-authenticated CLI.
Config shape
storage: {
provider: 's3', // gcs | s3 | minio | azure
bucket: 'acme-assets', // bucket name — for azure, the blob container
publicUrl: 'https://cdn.example.com/acme-assets',
// s3-compatible stores: set region / endpoint as needed
},publicUrl is the public/CDN URL assets are served from; knext wires it into assetPrefix so the
browser fetches static chunks from object storage rather than the pod.