Multi-cloud deploy
Object-storage providers knext supports — and the one its validator rejects.
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'] as const;| Provider | Status |
|---|---|
gcs | Supported (validated). |
s3 | Supported (validated). Any S3-compatible store via endpoint. |
minio | Supported (validated). |
azure | Not accepted. See the caveat below. |
azure is typed but not accepted. The StorageProvider TypeScript type in @knext/core
includes "azure" (type StorageProvider = "s3" | "gcs" | "azure" | "minio"), but the CLI
validator's accept-list is gcs | s3 | minio only. A config with provider: "azure" is rejected
at config-load time. This is a real docs-vs-code drift to avoid — do not document azure as
supported until the validator accepts it.
Config shape
storage: {
provider: 's3', // gcs | s3 | minio
bucket: 'storefront-assets',
publicUrl: 'https://cdn.example.com/storefront-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.