Skip to main content

​
Overview

Bring Your Own Kubernetes (BYOK) allows you to connect any Kubernetes cluster to Qovery. You maintain control over your cluster infrastructure while Qovery manages application deployments.

​
Supported Kubernetes

Cloud Managed

  • AWS EKS
  • Google GKE
  • Azure AKS
  • Scaleway Kapsule
  • DigitalOcean DOKS

Self-Managed

  • Vanilla Kubernetes
  • Rancher
  • OpenShift
  • k3s/k3d
  • Tanzu

On-Premise

  • EKS Anywhere
  • Bare metal Kubernetes
  • VMware vSphere
  • Private cloud

​
Requirements

Kubernetes 1.24 or higher
kubectl access with cluster-admin permissions
LoadBalancer support (cloud or MetalLB for on-premise)
Storage class for persistent volumes
Ingress controller (Nginx or similar)
Metrics server installed

​
Quick Start

1

Prepare Cluster

Ensure requirements are met:
# Check Kubernetes version
kubectl version --short

# Check storage class
kubectl get storageclass

# Check metrics server
kubectl top nodes
2

Get Qovery Agent

In Qovery Console:
  1. Settings → Clusters → Add Cluster
  2. Select “Bring Your Own Kubernetes”
  3. Download Helm values or kubectl manifests
3

Install Qovery Agent

Using Helm (recommended):
helm repo add qovery https://helm.qovery.com
helm repo update

helm install qovery-agent qovery/qovery-agent \
  --namespace qovery \
  --create-namespace \
  --values qovery-values.yaml
4

Verify Connection

kubectl get pods -n qovery
Cluster should show as “Connected” in Qovery Console

​
What Qovery Installs

Core Components:
  • Qovery Agent (deployment manager)
  • Qovery Shell Agent (for terminal access)
Optional Components (if not present):
  • Nginx Ingress Controller
  • Cert-Manager (SSL certificates)
  • External-DNS (domain management)
  • Metrics Server

​
Networking Requirements

​
Inbound

  • Port 443: HTTPS traffic to applications
  • Port 80: HTTP traffic (redirects to 443)

​
Outbound

  • Qovery API: https://api.qovery.com
  • Container Registries: ECR, Docker Hub, GCR, etc.
  • Git Providers: GitHub, GitLab, Bitbucket

​
Load Balancer

  • Cloud Load Balancer
  • MetalLB (On-Premise)
Automatically provisioned by cloud provider:
  • AWS: ALB/NLB
  • GCP: Google Cloud Load Balancer
  • Azure: Azure Load Balancer

​
Storage Configuration

Ensure default storage class exists: 
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/gce-pd  # Change based on your provider
parameters:
  type: pd-standard
For on-premise, consider:
  • NFS: Network File System
  • Ceph: Distributed storage
  • Local Path: Local storage (not recommended for production)

​
Best Practices

Dedicated Namespace

Use dedicated qovery namespace for Qovery components

Resource Quotas

Set resource quotas per namespace to prevent resource exhaustion

Network Policies

Implement network policies for namespace isolation

Regular Updates

Keep Kubernetes and Qovery agent updated regularly

​
Troubleshooting

Check:
  • Agent pods running: kubectl get pods -n qovery
  • Agent logs: kubectl logs -n qovery -l app=qovery-agent
  • Outbound internet access from cluster
  • API token is correct
For Cloud: Check cloud provider quotas and permissionsFor On-Premise: Install MetalLB and configure IP pool
Check:
  • Storage class exists: kubectl get sc
  • Default storage class set
  • Provisioner is working
  • Sufficient storage capacity

​
Platform-Specific Guides

https://mintcdn.com/qovery/bC94RbU5OE288_w9/images/logos/cloud-providers/aws-icon.svg?fit=max&auto=format&n=bC94RbU5OE288_w9&q=85&s=39fdefda6b2a184faa10bc1d85b46f7d

AWS EKS BYOK

Connect existing EKS cluster

EKS Anywhere

Connect EKS Anywhere cluster

Generic Kubernetes

Detailed BYOK installation guide

Local Development

Use Docker Desktop for development