Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Devtron is installed over a Kubernetes cluster. Once you create a Kubernetes cluster, Devtron can be installed standalone or along with CI/CD integration.
Choose one of the options as per your requirements:
This section includes information about the minimum requirements you need to install and use Devtron.
Devtron is installed over a Kubernetes cluster. Once you create a Kubernetes cluster, Devtron can be installed standalone or along with CI/CD integration:
In this section, we will cover the basic details on how you can quickly get started with Devtron. First, lets see what are the prerequisite requirements before you install Devtron.
You can create a cluster using one of the following cloud providers as per your requirements:
The minimum requirements for installing Helm Dashboard by Devtron
and Devtron with CI/CD
as per the number of applications you want to manage on Devtron
are provided below:
For configuring small resources (to manage not more than 5 apps on Devtron):
For configuring medium/larger resources (to manage more than 5 apps on Devtron):
Note:
Please make sure that the recommended resources are available on your Kubernetes cluster before you proceed with Devtron installation.
It is NOT recommended to use brustable CPU VMs (T series in AWS, B Series in Azure and E2/N1 in GCP) for Devtron installation to experience consistency in performance.
You can install Devtron standalone (Helm Dashboard by Devtron) or along with CI/CD integration. Or, you can upgrade Devtron to the latest version.
Choose one of the options as per your requirements:
Devtron installation with the CI/CD integration is used to perform CI/CD, security scanning, GitOps, debugging, and observability.
Use this option to install Devtron with Build and Deploy CI/CD
integration.
The Helm Dashboard by Devtron which is a standalone installation includes functionalities to deploy, observe, manage, and debug existing Helm applications in multiple clusters. You can also install integrations from .
Use this option if you are managing the applications via Helm and you want to use Devtron to deploy, observe, manage, and debug the Helm applications.
With this option, you can install Devtron with CI/CD by enabling GitOps during the installation. You can also install other integrations from .
Use this option to install Devtron with CI/CD by enabling GitOps, which is the most scalable method in terms of version control, collaboration, compliance and infrastructure automation.
: Devtron installation with the CI/CD integration is used to perform CI/CD, security scanning, GitOps, debugging, and observability.
: The Helm Dashboard by Devtron, which is a standalone installation, includes functionalities to deploy, observe, manage, and debug existing Helm applications in multiple clusters. You can also install integrations from .
Create a
You can create any (preferably K8s version 1.16 or higher) for installing Devtron.
Make sure to install .
Refer to the section for more information.
Note: If you have questions, please let us know on our discord channel.
AWS EKS
Google Kubernetes Engine (GKE)
Create a cluster using GKE.
Azure Kubernetes Service (AKS)
Create a cluster using AKS.
k3s - Lightweight Kubernetes
Create a cluster using k3s - Lightweight Kubernetes.
Note
: You can also refer our customized documentation for installing Helm Dashboard by Devtron
on Minikube, Microk8s, K3s, Kind
here.
Devtron with CI/CD
2
6 GB
Helm Dashboard by Devtron
1
1 GB
Devtron with CI/CD
6
13 GB
Helm Dashboard by Devtron
2
3 GB
Devtron installation with the CI/CD integration is used to perform CI/CD, security scanning, GitOps, debugging, and observability.
The Helm Dashboard by Devtron which is a standalone installation includes functionalities to deploy, observe, manage, and debug existing Helm applications in multiple clusters. You can also install integrations from Devtron Stack Manager.
With this option, you can install Devtron with CI/CD by enabling GitOps during the installation. You can also install other integrations from Devtron Stack Manager.
Upgrade Devtron to latest version
You can upgrade Devtron in one of the following ways:
In this section, we describe the steps in detail on how you can install Devtron with CI/CD integration.
Run the following command to install AWS EBS CSI driver using Helm:
Run the following command to install the latest version of Devtron along with the CI/CD module:
To install Devtron on clusters with the multi-architecture nodes (ARM and AMD), append the Devtron installation command with --set installer.arch=multi-arch
.
Configuring Blob Storage in your Devtron environment allows you to store build logs and cache. In case, if you do not configure the Blob Storage, then:
You will not be able to access the build and deployment logs after an hour.
Build time for commit hash takes longer as cache is not available.
Artifact reports cannot be generated in pre/post build and deployment stages.
Choose one of the options to configure blob storage:
Run the following command to install Devtron along with MinIO for storing logs and cache.
Note: Unlike global cloud providers such as AWS S3 Bucket, Azure Blob Storage and Google Cloud Storage, MinIO can be hosted locally also.
Run the following command to install Devtron along with AWS S3 buckets for storing build logs and cache:
Install using S3 IAM policy.
Note: Please ensure that S3 permission policy to the IAM role attached to the nodes of the cluster if you are using below command.
Install using access-key and secret-key for AWS S3 authentication:
Install using S3 compatible storages:
Run the following command to install Devtron along with Azure Blob Storage for storing build logs and cache:
Run the following command to install Devtron along with Google Cloud Storage for storing build logs and cache:
The installation takes about 15 to 20 minutes to spin up all of the Devtron microservices one by one
Run the following command to check the status of the installation:
The command executes with one of the following output messages, indicating the status of the installation:
Run the following command to check the installer logs:
Run the following command to get the Devtron dashboard URL:
You will get an output similar to the example shown below:
Use the hostname aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com
(Loadbalancer URL) to access the Devtron dashboard.
If you do not get a hostname or receive a message that says "service doesn't exist," it means Devtron is still installing. Please wait until the installation is completed.
You can also use a CNAME
entry corresponding to your domain/subdomain to point to the Loadbalancer URL to access at a customized domain.
When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use that credentials to log in as an administrator.
After the initial login, we recommend you set up any SSO service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (let's say, GitHub) to log in to Devtron's dashboard.
The sections below will help you understand the process of getting the administrator password.
Username: admin
Password: Run the following command to get the admin password:
Install , if you have not installed it already.
If you are using EKS version 1.23 or above, you must also install .
If you want to configure Blob Storage during the installation, refer .
If you want to install Devtron for production deployments
, please refer our for Devtron Installation.
Refer to the AWS specific
parameters on the page.
Refer to the Azure specific
parameters on the page.
Refer to the Google Cloud specific
parameters on the page.
If you want to uninstall Devtron or clean Devtron helm installer, refer our .
Related to installaltion, please also refer section also.
If you have any questions, please let us know on our Discord channel.
Downloaded
The installer has downloaded all the manifests, and the installation is in progress.
Applied
The installer has successfully applied all the manifests, and the installation is completed.
devtron.yourdomain.com
CNAME
aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com
Regular backups for Devtron PostgreSQL and ArgoCD are crucial components of a disaster recovery plan, as they protect against potential data loss due to unforeseen circumstances. This documentation provides instructions on how to take backups of Devtron and store them either on AWS S3 or Azure containers.
Go to the devtron chart store and search for devtron-backups
chart.
Select the devtron-backups
and click Configure & Deploy
.
Now follow either of the options described below according to your Cloud provider.
To store Devtron backups on AWS S3, please follow these steps:
Create an S3 bucket to store the Devtron backup, you can configure the bucket to delete all the objects older than 15/30 days.
Create a user with sufficient permissions to push to the S3 bucket created in step 1.
Obtain the access key and secret access key for the created user.
Configure the devtron-backups
chart for AWS S3 by selecting the appropriate options:
Deploy the chart, and the Devtron backup will be automatically uploaded to the AWS S3 bucket at the scheduled intervals.
To store Devtron backups on Azure Containers, please follow these steps:
Create a storage account in Azure.
Within the storage account, create two containers for the Devtron backup.
Navigate to Security + Networking > Access Key section in Azure and copy the Access Key:
Configure the devtron-backups
chart for Azure Containers by providing the Access Key:
Before deploying the backup chart, ensure that AWS.enabled
is set to false
. This will ensure that Devtron backup will be automatically uploaded to the configured Azure containers on the scheduled intervals.
By following these steps, you can ensure that your Devtron data is securely backed up and protected against any potential data loss, enabling you to recover quickly in case of emergencies.
You can install and try Devtron on a high-end machine or a Cloud VM. If you install it on a laptop/PC, it may start to respond slowly, so it is recommended to uninstall Devtron from your system before shutting it down.
2 vCPUs
4GB+ of free memory
20GB+ free disk space
Before you get started, you must set up a cluster in your server and finish the following actions:
To install devtron on Minikube/kind
cluster, run the following command:
To install devtron on k3s
cluster, run the following command:
To access Devtron dashboard when using Minikube
as cluster, run the following command:
To access Devtron dashboard when using Kind/k3s
as cluster, run the following command to port forward the devtron service to port 8000:
Dashboard: http://127.0.0.1:8000.
When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use that credentials to log in as an administrator.
After the initial login, we recommend you set up any SSO service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (let's say, GitHub) to log in to Devtron's dashboard.
The section below will help you understand the process of getting the administrator credentials.
Username: admin
Password: Run the following command to get the admin password:
It is recommended to use Cloud VM with 2vCPU+, 4GB+ free memory, 20GB+ storage, Compute Optimized VM type & Ubuntu Flavoured OS.
Make sure that the port on which the devtron-service runs remain open in the VM's security group or network security group.
If you want to uninstall Devtron or clean Devtron helm installer, refer our uninstall Devtron.
In this section, we describe the steps in detail on how you can install Devtron with CI/CD by enabling GitOps during the installation.
Install Helm if you have not installed it.
Run the following command to install the latest version of Devtron with CI/CD along with GitOps (Argo CD) module:
Note: If you want to configure Blob Storage during the installation, refer configure blob storage duing installation.
To install Devtron on clusters with the multi-architecture nodes (ARM and AMD), append the Devtron installation command with --set installer.arch=multi-arch
.
Note:
If you want to install Devtron for production deployments
, please refer to our recommended overrides for Devtron Installation.
Configuring Blob Storage in your Devtron environment allows you to store build logs and cache. In case, if you do not configure the Blob Storage, then:
You will not be able to access the build and deployment logs after an hour.
Build time for commit hash takes longer as cache is not available.
Artifact reports cannot be generated in pre/post build and deployment stages.
Choose one of the options to configure blob storage:
Run the following command to install Devtron along with MinIO for storing logs and cache.
Note: Unlike global cloud providers such as AWS S3 Bucket, Azure Blob Storage and Google Cloud Storage, MinIO can be hosted locally also.
Refer to the AWS specific
parameters on the Storage for Logs and Cache page.
Run the following command to install Devtron along with AWS S3 buckets for storing build logs and cache:
Install using S3 IAM policy.
Note: Please ensure that S3 permission policy to the IAM role attached to the nodes of the cluster if you are using below command.
Install using access-key and secret-key for AWS S3 authentication:
Install using S3 compatible storages:
Refer to the Azure specific
parameters on the Storage for Logs and Cache page.
Run the following command to install Devtron along with Azure Blob Storage for storing build logs and cache:
Refer to the Google Cloud specific
parameters on the Storage for Logs and Cache page.
Run the following command to install Devtron along with Google Cloud Storage for storing build logs and cache:
Note: The installation takes about 15 to 20 minutes to spin up all of the Devtron microservices one by one.
Run the following command to check the status of the installation:
The command executes with one of the following output messages, indicating the status of the installation:
Downloaded
The installer has downloaded all the manifests, and the installation is in progress.
Applied
The installer has successfully applied all the manifests, and the installation is completed.
Run the following command to check the installer logs:
Run the following command to get the Devtron dashboard URL:
You will get an output similar to the example shown below:
Use the hostname aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com
(Loadbalancer URL) to access the Devtron dashboard.
Note: If you do not get a hostname or receive a message that says "service doesn't exist," it means Devtron is still installing. Please wait until the installation is completed.
Note: You can also use a CNAME
entry corresponding to your domain/subdomain to point to the Loadbalancer URL to access at a customized domain.
devtron.yourdomain.com
CNAME
aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com
When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use that credentials to log in as an administrator.
After the initial login, we recommend you set up any SSO service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (let's say, GitHub) to log in to Devtron's dashboard.
The section below will help you understand the process of getting the administrator credentials.
Username: admin
Password: Run the following command to get the admin password:
If you want to uninstall Devtron or clean Devtron helm installer, refer our uninstall Devtron.
Related to installation, please also refer FAQ section also.
Devtron is a tool integration platform for Kubernetes.
Devtron deeply integrates with products across the lifecycle of microservices i.e., CI/CD, security, cost, debugging, and observability via an intuitive web interface. Devtron helps you to deploy, observe, manage & debug the existing Helm apps in all your clusters.
Workflow which understands the domain of Kubernetes, testing, CD, SecOps so that you don't have to write scripts
Reusable and composable components so that workflows are easy to construct and reason through
Deploy to multiple Kubernetes clusters on multiple cloud/on-prem from one Devtron setup
Works for all cloud providers and on-premise Kubernetes clusters
Multi-level security policy at global, cluster, environment, and application-level for efficient hierarchical policy management
Behavior-driven security policy
Define policies and exceptions for Kubernetes resources
Define policies for events for faster resolution
One place for all historical Kubernetes events
Access all manifests securely, such as secret obfuscation
Application metrics for CPU, RAM, HTTP status code, and latency with a comparison between new and old
Advanced logging with grep and JSON search
Intelligent correlation between events, logs for faster triangulation of issue
Auto issue identification
Fine-grained access control; control who can edit the configuration and who can deploy.
Audit log to know who did what and when
History of all CI and CD events
Kubernetes events impacting application
Relevant cloud events and their impact on applications
Advanced workflow policies like blackout window, branch environment relationship to secure build and deployment pipelines
GitOps exposed through API and UI so that you don't have to interact with git CLI
GitOps backed by Postgres for easy analysis
Enforce finer access control than Git
Deployment metrics to measure the success of the agile process. It captures MTTR, change failure rate, deployment frequency, and deployment size out of the box.
Audit log to understand the failure causes
Monitor changes across deployments and reverts easily
Application metrics only work for K8s version 1.16+
Get updates on Devtron's development and chat with the project maintainers, contributors, and community members.
We, at Devtron, take security and our users' trust very seriously. If you believe you have found a security issue in Devtron, please responsibly disclose it by contacting us at security@devtron.ai.
Run the following command to install Helm Dashboard by Devtron:
To install Devtron on clusters with the multi-architecture nodes (ARM and AMD), append the Devtron installation command with --set installer.arch=multi-arch
.
Run the following command to get the dashboard URL:
You will get the result something as shown below:
The hostname aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com
as mentioned above is the Loadbalancer URL where you can access the Devtron dashboard.
You can also do a CNAME entry corresponding to your domain/subdomain to point to this Loadbalancer URL to access it at a custom domain.
When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use that credentials to log in as an administrator.
After the initial login, we recommend you set up any SSO service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (let's say, GitHub) to log in to Devtron's dashboard.
The section below will help you understand the process of getting the administrator credentials.
Username: admin
Password: Run the following command to get the admin password:
Devtron uses a modified version of .
Check out our . Directions for opening issues, coding standards, and notes on our development processes are all included.
Join the
Follow
Raise feature requests, suggest enhancements, report bugs at
Read the
In this section, we describe on how you can install Helm Dashboard by Devtron without any integrations. Integrations can be added later using .
If you want to install Devtron on Minikube, Microk8s, K3s, Kind, refer this .
Install if you have not installed it.
Note: This installation command will not install CI/CD integration. For CI/CD, refer section.
Note: If you want to uninstall Devtron or clean Devtron helm installer, refer our .
To use the CI/CD capabilities with Devtron, you can Install the or .
devtron.yourdomain.com
CNAME
aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com
Here we have demonstrated the installation of Devtron on popular cloud providers. The videos are easy to follow and provide step-by-step instructions.
Cloud Provider: Amazon Web Services (AWS)
Cloud Provider: Microsoft Azure
Cloud Provider: Google Cloud Platform (GCP)
For Helm
installation this section refers to secrets section of values.yaml
.
Configure the following properties:
For Helm
installation this section refers to configs section of values.yaml
.
Configure the following properties:
Devtron provides ways to control how much memory
or CPU
can be allocated to each Devtron microservice. You can adjust the resources that are allocated to these microservices based on your requirements. The resource configurations are available in following sizes:
Small
: To configure the small resources (e.g. to manage less than 10 apps on Devtron ) based on the requirements, append the Devtron installation command with -f https://raw.githubusercontent.com/devtron-labs/devtron/main/charts/devtron/resources-small.yaml
.
For Helm
installation this section refers to customOverrides section of values.yaml
. In this section you can override values of devtron-cm which you want to keep persistent. For example:
You can configure the following properties:
AWS SPECIFIC
While installing Devtron and using the AWS-S3 bucket for storing the logs and caches, the below parameters are to be used in the ConfigMap.
NOTE: For using the S3 bucket it is important to add the S3 permission policy to the IAM role attached to the nodes of the cluster.
The below parameters are to be used in the Secrets :
AZURE SPECIFIC
While installing Devtron using Azure Blob Storage for storing logs and caches, the below parameters will be used in the ConfigMap.
GOOGLE CLOUD STORAGE SPECIFIC
While installing Devtron using Google Cloud Storage for storing logs and caches, the below parameters will be used in the ConfigMap.
To convert string to base64 use the following command:
Note:
Ensure that the cluster has read and write access to the S3 buckets/Azure Blob storage container mentioned in DEFAULT_CACHE_BUCKET, DEFAULT_BUILD_LOGS_BUCKET or AZURE_BLOB_CONTAINER_CI_LOG, or AZURE_BLOB_CONTAINER_CI_CACHE.
Ensure that the cluster has read access to AWS secrets backends (SSM & secrets manager).
We can use the --set
flag to override the default values when installing with Helm. For example, to update POSTGRESQL_PASSWORD and BLOB_STORAGE_PROVIDER, use the install command as:
Blob Storage allows users to store large amounts of unstructured data. Unstructured data is a data that does not adhere to a particular data model or definition, such as text or binary data. Configuring blob storage in your Devtron environment allows you to store build logs and cache.
In case, if you do not configure the Blob Storage, then:
You will not be able to access the build and deployment logs after an hour.
Build time for commit hash takes longer as cache is not available.
Artifact reports cannot be generated in pre/post build and deployment stages.
You can configure Blob Storage with one of the following Blob Storage providers given below:
Note: You can also use the respective following command to switch to another Blob Storage provider. As an example, If you are using MinIO Storage and want to switch to Azure Blob Storage, use the command provided on the Azure Blob Storage tab to switch.
Use the following command to configure MinIO for storing logs and cache.
Note: Unlike global cloud providers such as AWS S3 Bucket, Azure Blob Storage and Google Cloud Storage, MinIO can be hosted locally also.
Configure using S3 IAM policy:
NOTE: Pleasee ensure that S3 permission policy to the IAM role attached to the nodes of the cluster if you are using the below command.
Configure using access-key and secret-key for aws S3 authentication:
Configure using S3 compatible storages:
You can configure Devtron by using configuration files. Configuration files are YAML files which are user-friendly. The configuration allows you to quickly roll back a configuration change if necessary. It also aids cluster re-creation and restoration.
There are two ways you can perform configurations while setting up Devtron dashboard:
The following tables contain parameters and their details for Secrets and ConfigMaps that are configured during the installation of Devtron. If the installation is done using Helm
, the values can be tweaked in file.
Use the following command to configure AWS S3 bucket for storing build logs and cache. Refer to the AWS specific
parameters on the page.
Use the following command to configure Azure Blob Storage for storing build logs and cache. Refer to the Azure specific
parameters on the page.
Use the following command to configure Google Cloud Storage for storing build logs and cache. Refer to the Google Cloud specific
parameters on the page.
You can also setup ingress
while setting up Devtron dashboard. Refer for ingress setup.
POSTGRESQL_PASSWORD
Using this parameter the auto-generated password for Postgres can be edited as per requirement(Used by Devtron to store the app information)
NA
WEBHOOK_TOKEN
If you want to continue using Jenkins for CI then provide this for authentication of requests should be base64 encoded
NA
BASE_URL_SCHEME
Either of HTTP or HTTPS (required)
HTTP
BASE_URL
URL without scheme and trailing slash, this is the domain pointing to the cluster on which the Devtron platform is being installed. For example, if you have directed domain devtron.example.com
to the cluster and the ingress controller is listening on port 32080
then URL will be devtron.example.com:32080
(required)
change-me
DEX_CONFIG
dex config if you want to integrate login with SSO (optional) for more information check Argocd documentation
NA
EXTERNAL_SECRET_AMAZON_REGION
AWS region for the secret manager to pick (required)
NA
PROMETHEUS_URL
URL of Prometheus where all cluster data is stored; if this is wrong, you will not be able to see application metrics like CPU, RAM, HTTP status code, latency, and throughput (required)
NA
CI_NODE_LABEL_SELECTOR
Labels for a particular nodegroup which you want to use for running CIs
NA
CI_NODE_TAINTS_KEY
Key for toleration if nodegroup chosen for CIs have some taints
NA
CI_NODE_TAINTS_VALUE
Value for toleration if nodegroup chosen for CIs have some taints
NA
DEFAULT_CACHE_BUCKET
AWS bucket to store docker cache, it should be created beforehand (required)
DEFAULT_BUILD_LOGS_BUCKET
AWS bucket to store build logs, it should be created beforehand (required)
DEFAULT_CACHE_BUCKET_REGION
AWS region of S3 bucket to store cache (required)
DEFAULT_CD_LOGS_BUCKET_REGION
AWS region of S3 bucket to store CD logs (required)
BLOB_STORAGE_S3_ENDPOINT
S3 compatible bucket endpoint.
BLOB_STORAGE_S3_ACCESS_KEY
AWS access key to access S3 bucket. Required if installing using AWS credentials.
BLOB_STORAGE_S3_SECRET_KEY
AWS secret key to access S3 bucket. Required if installing using AWS credentials.
AZURE_ACCOUNT_NAME
Account name for AZURE Blob Storage
AZURE_BLOB_CONTAINER_CI_LOG
AZURE Blob storage container for storing ci-logs after running the CI pipeline
AZURE_BLOB_CONTAINER_CI_CACHE
AZURE Blob storage container for storing ci-cache after running the CI pipeline
BLOB_STORAGE_GCP_CREDENTIALS_JSON
Base-64 encoded GCP credentials json for accessing Google Cloud Storage
DEFAULT_CACHE_BUCKET
Google Cloud Storage bucket for storing ci-logs after running the CI pipeline
DEFAULT_LOGS_BUCKET
Google Cloud Storage bucket for storing ci-cache after running the CI pipeline
ACD_PASSWORD
ArgoCD Password for CD Workflow
Auto-Generated
Optional
AZURE_ACCOUNT_KEY
Account key to access Azure objects such as BLOB_CONTAINER_CI_LOG or CI_CACHE
""
Mandatory (If using Azure)
GRAFANA_PASSWORD
Password for Grafana to display graphs
Auto-Generated
Optional
POSTGRESQL_PASSWORD
Password for your Postgresql database that will be used to access the database
Auto-Generated
Optional
AZURE_ACCOUNT_NAME
Azure account name which you will use
""
Mandatory (If using Azure)
AZURE_BLOB_CONTAINER_CI_LOG
Name of container created for storing CI_LOG
ci-log-container
Optional
AZURE_BLOB_CONTAINER_CI_CACHE
Name of container created for storing CI_CACHE
ci-cache-container
Optional
BLOB_STORAGE_PROVIDER
Cloud provider name which you will use
MINIO
Mandatory (If using any cloud other than MINIO), MINIO/AZURE/S3
DEFAULT_BUILD_LOGS_BUCKET
S3 Bucket name used for storing Build Logs
devtron-ci-log
Mandatory (If using AWS)
DEFAULT_CD_LOGS_BUCKET_REGION
Region of S3 Bucket where CD Logs are being stored
us-east-1
Mandatory (If using AWS)
DEFAULT_CACHE_BUCKET
S3 Bucket name used for storing CACHE (Do not include s3://)
devtron-ci-cache
Mandatory (If using AWS)
DEFAULT_CACHE_BUCKET_REGION
S3 Bucket region where Cache is being stored
us-east-1
Mandatory (If using AWS)
EXTERNAL_SECRET_AMAZON_REGION
Region where the cluster is setup for Devtron installation
""
Mandatory (If using AWS)
ENABLE_INGRESS
To enable Ingress (True/False)
False
Optional
INGRESS_ANNOTATIONS
Annotations for ingress
""
Optional
PROMETHEUS_URL
Existing Prometheus URL if it is installed
""
Optional
CI_NODE_LABEL_SELECTOR
Label of CI worker node
""
Optional
CI_NODE_TAINTS_KEY
Taint key name of CI worker node
""
Optional
CI_NODE_TAINTS_VALUE
Value of taint key of CI node
""
Optional
CI_DEFAULT_ADDRESS_POOL_BASE_CIDR
CIDR ranges used to allocate subnets in each IP address pool for CI
""
Optional
CI_DEFAULT_ADDRESS_POOL_SIZE
The subnet size to allocate from the base pool for CI
""
Optional
CD_NODE_LABEL_SELECTOR
Label of CD node
kubernetes.io/os=linux
Optional
CD_NODE_TAINTS_KEY
Taint key name of CD node
dedicated
Optional
CD_NODE_TAINTS_VALUE
Value of taint key of CD node
ci
Optional
CD_LIMIT_CI_CPU
CPU limit for pre and post CD Pod
0.5
Optional
CD_LIMIT_CI_MEM
Memory limit for pre and post CD Pod
3G
Optional
CD_REQ_CI_CPU
CPU request for CI Pod
0.5
Optional
CD_REQ_CI_MEM
Memory request for CI Pod
1G
Optional
CD_DEFAULT_ADDRESS_POOL_BASE_CIDR
CIDR ranges used to allocate subnets in each IP address pool for CD
""
Optional
CD_DEFAULT_ADDRESS_POOL_SIZE
The subnet size to allocate from the base pool for CD
""
Optional
GITOPS_REPO_PREFIX
Prefix for Gitops repository
devtron
Optional
RECOMMEND_SECURITY_SCANNING
If True, security scanning
is enabled
by default for a new build pipeline. Users can however turn it off in the new or existing pipelines.
FORCE_SECURITY_SCANNING
If set to True, security scanning
is forcefully enabled
by default for a new build pipeline. Users can not turn it off for new as well as for existing build pipelines. Old pipelines that have security scanning disabled will remain unchanged and image scanning should be enabled manually for them.
HIDE_DISCORD
Hides discord chatbot from the dashboard.
Still facing issues, please reach out to us on Discord.
The Kubernetes client by Devtron is a very lightweight dashboard that can be installed on arm64/amd64-based architectures. It comes with the features such as Kubernetes Resources Browser and Cluster Management that can provide control and observability for resources across clouds and clusters.
Devtron Kubernetes client is an intuitive Kubernetes Dashboard or a command line utility installed outside a Kubernetes cluster. The client can be installed on a desktop running on any Operating Systems and interact with all your Kubernetes clusters and workloads through an API server. It is a binary, packaged in a bash script that you can download and install by using the following set of commands.
By installing Devtron Kubernetes Client
, you can access:
Managing Kubernetes Resources at scale: Clusters vary on business and architectural needs. Organizations tend to build smaller clusters for more decentralization. This practice leads to the creation of multiple clusters and more nodes. Managing them on a CLI requires multiple files, making it difficult to perform resource operations. But with the Devtron Kubernetes Client, you can gain more visibility into K8s resources easily.
Unifying information in one place: When information is scattered across clusters, and you have to type commands with arguments to fetch desired output, the process becomes slow and error-prone. Without a single point of configuration source, the configurations of different config. files diverge, making them even more challenging to restore and track. The Devtron Kubernetes Client unifies all the information and tools into one interface to perform various contextual tasks.
Accessibility during an outage for troubleshooting: As the Devtron Kubernetes Client runs outside a cluster, you can exercise basic control over their failed resources when there is a cluster-level outage. The Client helps to gather essential logs and data to pinpoint the root cause of the issue and reduce the time to restore service.
Avoiding Kubeconfig version mismatch errors: With the Devtron Kubernetes Client, you can be relieved from maintaining the Kubeconfig versions for the respective clusters (v1.16 - 1.26 i.e, current version) as the Devtron Kubernetes Client performs self kubeconfig version control. Instead of managing multiple kubectl versions manually, it eliminates the chances of errors occurring due to the mismatch in configuration.
Download the bash script using the below URL: https://cdn.devtron.ai/k8s-client/devtron-install.bash
To automatically download the executable file and to open the dashboard in the respective browser, run the following command:
Note
: Make sure you place Devtron-install.bash
in your current directory before you execute the command.
Devtron Kubernetes Client opens in your browser automatically.
You must add your cluster to make your cluster visible on the Kubernetes Resource Browser
and Clusters
section. To add a cluster, go to the Global Configurations
and click Add Cluster
. Refer documentation on how to add a cluster.
Note
: You do not need to have a super admin
permission to add a cluster if you install Devtron Kubernetes Client
. You can add more than one cluster.
Kubernetes Resource Browser
provides a graphical user interface for interacting and managing all your Kubernetes (k8s) resources across clusters. It also helps you to deploy and manage Kubernetes resources and allows pod operations such as:
View real-time logs
Check manifest and edit live manifests of k8s resources
Executable via terminal
View Events
Or, delete a resource
With Kubernetes Resource browser
, you can also perform the following:
Check the real-time health status
Search for any workloads
Manage multiple clusters and change cluster contexts
Deploy multiple K8s manifests through Create
UI option.
Perform resource grouping at the cluster level.
After your cluster is added via Global Configurations
, go to the Kubernetes Resource Browser
page and select your cluster. Refer Resource Browser documentation for detail and its operations.
Note
: You do not need to have a super admin
permission to access Kubernetes Resource Browser
if you install Devtron Kubernetes Client
.
With the Devtron Kubernetes Client
, you can manage all your clusters running on-premises or on a cloud. It is a cluster and cloud agnostic platform where you can add as many clusters as you want, be it a lightweight cluster such as k3s/ microk8s or cloud managed clusters like Amazon EKS.
It enables you to observe and monitor the cluster health and real-time node conditions. The Cluster management feature provides a summary of nodes with all available labels, annotations, taints, and other parameters such as resource usage. In addition to that, it helps you to perform node operations such as:
Debug a node
Cordon a node
Drain a node
Taint a node
Edit a node config
Delete a node
With its rich features and intuitive interface, you can easily manage and debug clusters through cluster terminal access and use any CLI debugging tools like busybox, kubectl, netshoot or any custom CLI tools like k9s.
After your cluster is added via Global Configurations
, go to the Clusters
page and search or select your cluster. Refer Clusters documentation for detail and its operations.
In case if you close the browser by mistake, you can open the dashboard by executing the following command. It will open the dashboard through a port in the available web browser and store the Kubernetes client's state.
To stop the dashboard, you can execute the following command:
To update the Devtron Kubernetes Client
, use the following command. It will stop the running dashboard and download the latest executable file and open it in the browser.
You can configure a container registry using any registry provider of your choice. It allows you to build, deploy, and manage your container images or charts with easy-to-use UI.
From the left sidebar, go to Global Configurations → Container/OCI Registry.
Click Add Registry.
Choose the Registry type:
Private Registry: Choose this if your images or artifacts are hosted or should be hosted on a private registry restricted to authenticated users of that registry. Selecting this option requires you to enter your registry credentials (username and password/token).
Public Registry: Unlike private registry, this doesn't require your registry credentials. Only the registry URL and repository name(s) would suffice.
Assuming your registry type is private, here are few of the common fields you can expect:
Click Save.
Amazon ECR is an AWS-managed container image registry service. The ECR provides resource-based permissions to the private repositories using AWS Identity and Access Management (IAM). ECR allows both Key-based and Role-based authentications.
Provide the following additional information apart from the common fields:
Provide the following additional information apart from the common fields:
Provide the following additional information apart from the common fields:
Remove all the white spaces from JSON key and wrap it in a single quote before pasting it in Service Account JSON File
field
Provide the following additional information apart from the common fields:
Remove all the white spaces from JSON key and wrap it in single quote before pasting it in Service Account JSON File
field
Provide the following additional information apart from the common fields:
Provide below information if you select the registry type as Other
.
You can use any registry which can be authenticated using docker login -u <username> -p <password> <registry-url>
. However these registries might provide a more secured way for authentication, which we will support later.
Super-admin users can decide if they want to auto-inject registry credentials or use a secret to pull an image for deployment to environments on specific clusters.
To manage the access of registry credentials, click Manage.
There are two options to manage the access of registry credentials:
You can choose one of the two options for defining credentials:
If you select Use Registry Credentials, the clusters will be auto-injected with the registry credentials of your registry type. As an example, If you select Docker
as Registry Type, then the clusters will be auto-injected with the username
and password/token
which you use on the Docker Hub account.
Click Save.
You can create a Secret by providing credentials on the command line.
Create this Secret and name it regcred
(let's say):
where,
namespace is your sub-cluster, e.g., devtron-demo
your-registry-server is your Private Docker Registry FQDN. Use https://index.docker.io/v1/ for Docker Hub.
your-name is your Docker username
your-pword is your Docker password
your-email is your Docker email
You have successfully set your Docker credentials in the cluster as a Secret called regcred
.
Typing secrets on the command line may store them in your shell history unprotected, and those secrets might also be visible to other users on your PC during the time when kubectl is running.
Enter the Secret name in the field and click Save.
To add cluster, go to the Clusters & Environments
section of Global Configurations
. Click Add cluster.
To add a Kubernetes cluster on Devtron using server url
and the bearer token
, provide the information in the following fields:
Prerequisites:
kubectl
must be installed on the bastion.
You can get the Server URL
& Bearer Token
by running the following command depending on the cluster provider:
If you are using EKS, AKS, GKE, Kops, Digital Ocean managed Kubernetes, run the following command to generate the server URL and bearer token:
If you are using a microk8s cluster
, run the following command to generate the server URL and bearer token:
Disaster Recovery:
It is not possible to edit the server URL of a cloud specific provider. If you're using an EKS URL (e.g. *****.eu-west-1.elb.amazonaws.com
), it will be a tedious task to add a new cluster and migrate all the services one by one.
But in case of using a self-hosted URL (e.g. clear.example.com
), you can just point to the new cluster's server URL in DNS manager and update the new cluster token and sync all the deployments.
Easy Cluster Migrations:
In case of managed Kubernetes clusters (like EKS, AKS, GKE etc) which is a cloud provider specific, migrating your cluster from one provider to another will result in waste of time and effort.
On the other hand, migration for a self-hosted URL is easy as the URL is of single hosted domain independent of the cloud provider.
To add clusters using kubeconfig, follow these steps:
First, navigate to the global configurations menu, and then go to "clusters and environment" section.
Click on the Add cluster
button. In the options provided, choose the From kubeconfig
option.
Next, either paste the kubeconfig file or browse for it and select the appropriate file.
Afterward, click on the Get cluster
button. This action will display the cluster details alongside the kubeconfig.
Select the desired cluster and click on Save
to successfully add the cluster to Devtron.
Note: Please ensure that the kubeconfig file you use has admin permissions
. It is crucial for Devtron to have the necessary administrative privileges; otherwise, it may encounter failures or disruptions during deployments and other operations. Admin permission is essential to ensure the smooth functioning of Devtron and to prevent any potential issues that may arise due to insufficient privileges.
If you want to see application metrics against the applications deployed in the cluster, Prometheus must be deployed in the cluster. Prometheus is a powerful tool to provide graphical insight into your application behavior.
Note: Make sure that you install
Monitoring (Grafana)
from theDevtron Stack Manager
to configure prometheus. If you do not installMonitoring (Grafana)
, then the option to configure prometheus will not be available.
Enable the application metrics to configure prometheus and provide the information in the following fields:
Now, click Save Cluster
to save your cluster on Devtron.
Your Kubernetes cluster gets mapped with Devtron when you save the cluster configurations. Now, the Devtron agent must be installed on the added cluster so that you can deploy your applications on that cluster.
When the Devtron agent starts installing, click Details
to check the installation status.
A new window pops up displaying all the details about the Devtron agent.
Once you have added your cluster in the Clusters & Environments
, you can add the environment by clicking Add environment
.
A new environment window pops up.
Click Save
and your environment will be created.
You can also update an environment by clicking the environment.
You can change Production
and Non-Production
options only.
You cannot change the Environment Name
and Namespace Name
.
Make sure to click Update to update your environment.
While are typically used for storing built by the CI Pipeline, an OCI registry can store container images as well as other artifacts such as . In other words, all container registries are OCI registries, but not all OCI registries are container registries.
Choose a provider from the Registry provider dropdown. View the .
Before you begin, create an and attach the ECR policy according to the authentication type.
For Azure, the service principal authentication method can be used to authenticate with username and password. Visit this to get the username and password for this registry.
JSON key file authentication method can be used to authenticate with username and service account JSON file. Visit this to get the username and service account JSON file for this registry.
JSON key file authentication method can be used to authenticate with username and service account JSON file. Please follow to get the username and service account JSON file for this registry.
You can create a Pod that uses a to pull an image from a private container registry. You can use any private container registry of your choice, for e.g., .
You can add your existing Kubernetes clusters and environments on the Clusters and Environments
section. You must have a access to add a cluster.
Note: We recommend to use a self-hosted URL instead of cloud hosted URL. Refer the benefits of .
Name
Provide a name to your registry, this name will appear in the Container Registry drop-down list available within the Build Configuration section of your application
Registry URL
Provide the URL of your registry in case it doesn't come prefilled (do not include oci://
, http://
, or /https://
in the URL)
Authentication Type
The credential input fields may differ depending on the registry provider, check Registry Providers
Push container images
Tick this checkbox if you wish to use the repository to push container images. This comes selected by default and you may untick it if you don't intend to push container images after a CI build. If you wish to to use the same repository to pull container images too, read Registry Credential Access.
Push helm packages
Tick this checkbox if you wish to push helm charts to your registry
Use as chart repository
Tick this checkbox if you want Devtron to pull helm charts from your registry and display them on its chart store. Also, you will have to provide a list of repositories (present within your registry) for Devtron to successfully pull the helm charts.
Set as default registry
Tick this checkbox to set your registry as the default registry hub for your images or artifacts
Registry URL
Example of URL format: xxxxxxxxxxxx.dkr.ecr.<region>.amazonaws.com
where xxxxxxxxxxxx
is your 12-digit AWS account ID
Authentication Type
Select one of the authentication types:
EC2 IAM Role: Authenticate with workernode IAM role and attach the ECR policy (AmazonEC2ContainerRegistryFullAccess) to the cluster worker nodes IAM role of your Kubernetes cluster.
User Auth: It is a key-based authentication, attach the ECR policy (AmazonEC2ContainerRegistryFullAccess) to the IAM user.
Access key ID
: Your AWS access key
Secret access key
: Your AWS secret access key ID
Username
Provide the username of the Docker Hub account you used for creating your registry.
Password/Token
Provide the password/Token corresponding to your docker hub account. It is recommended to use Token
for security purpose.
Registry URL/Login Server
Example of URL format: xxx.azurecr.io
Username/Registry Name
Provide the username of your Azure container registry
Password
Provide the password of your Azure container registry
Registry URL
Example of URL format: region-docker.pkg.dev
Service Account JSON File
Paste the content of the service account JSON file
Username
Provide the username of your Quay account
Token
Provide the password of your Quay account
Registry URL
Enter the URL of your private registry
Username
Provide the username of your account where you have created your registry
Password/Token
Provide the password or token corresponding to the username of your registry
Advanced Registry URL Connection Options
Allow Only Secure Connection: Tick this option for the registry to allow only secure connections
Allow Secure Connection With CA Certificate: Tick this option for the registry to allow secure connection by providing a private CA certificate (ca.crt)
Allow Insecure Connection: Tick this option to make an insecure communication with the registry (for e.g., when SSL certificate is expired)
Do not inject credentials to clusters
Select the clusters for which you do not want to inject credentials
Auto-inject credentials to clusters
Select the clusters for which you want to inject credentials
Name
Enter a name of your cluster.
Server URL
Server URL of a cluster. Note: We recommended to use a self-hosted URL instead of cloud hosted URL.
Bearer Token
Bearer token of a cluster.
Prometheus endpoint
Provide the URL of your prometheus.
Authentication Type
Prometheus supports two authentication types:
Basic: If you select the Basic
authentication type, then you must provide the Username
and Password
of prometheus for authentication.
Anonymous: If you select the Anonymous
authentication type, then you do not need to provide the Username
and Password
.
Note: The fields Username
and Password
will not be available by default.
TLS Key
& TLS Certificate
TLS Key
and TLS Certificate
are optional, these options are used when you use a customized URL.
Environment Name
Enter a name of your environment.
Enter Namespace
Enter a namespace corresponding to your environment. Note: If this namespace does not already exist in your cluster, Devtron will create it. If it exists already, Devtron will map the environment to the existing namespace.
Environment Type
Select your environment type:
Production
Non-production
Note: Devtron shows deployment metrics (DORA metrics) for environments tagged as Production
only.
After Devtron is installed, Devtron is accessible through service devtron-service
. If you want to access Devtron through ingress, edit devtron-service
and change the loadbalancer to ClusterIP. You can do this using kubectl patch
command:
After this, create ingress by applying the ingress yaml file. You can use this yaml file to create ingress to access Devtron:
You can access Devtron from any host after applying this yaml. For k8s versions <1.19, apply this yaml:
Optionally, you also can access Devtron through a specific host by running the following YAML file:
Once ingress setup for devtron is done and you want to run Devtron over https
, you need to add different annotations for different ingress controllers and load balancers.
In case of nginx ingress controller
, add the following annotations under service.annotations
under nginx ingress controller to run devtron over https
.
(i) Amazon Web Services (AWS)
If you are using AWS cloud, add the following annotations under service.annotations
under nginx ingress controller.
(ii) Digital Ocean
If you are using Digital Ocean cloud, add the following annotations under service.annotations
under nginx ingress controller.
In case of AWS application load balancer, add following annotations under ingress.annotations
to run devtron over https
.
In case of AWS application load balancer, the following annotations need to be added under ingress.annotations
to run devtron over https
.
For an Ingress resource to be observed by AGIC (Application Gateway Ingress Controller) must be annotated with kubernetes.io/ingress.class: azure/application-gateway. Only then AGIC will work with the Ingress resource in question.
Note: Make sure NOT to use port 80 with HTTPS and port 443 with HTTP on the Pods.
In certain cases, you may want to override default configurations provided by Devtron. For example, for deployments or statefulsets you may want to change the memory or CPU requests or limit or add node affinity or taint tolerance. Say, for ingress, you may want to add annotations or host. Samples are available inside the manifests/updates directory.
To modify a particular object, it looks in namespace devtroncd
for the corresponding configmap as mentioned in the mapping below:
argocd
argocd-override-cm
GitOps
clair
clair-override-cm
container vulnerability db
clair
clair-config-override-cm
Clair configuration
dashboard
dashboard-override-cm
UI for Devtron
gitSensor
git-sensor-override-cm
microservice for Git interaction
guard
guard-override-cm
validating webhook to block images with security violations
postgresql
postgresql-override-cm
db store of Devtron
imageScanner
image-scanner-override-cm
image scanner for vulnerability
kubewatch
kubewatch-override-cm
watches changes in ci and cd running in different clusters
lens
lens-override-cm
deployment metrics analysis
natsOperator
nats-operator-override-cm
operator for nats
natsServer
nats-server-override-cm
nats server
natsStreaming
nats-streaming-override-cm
nats streaming server
notifier
notifier-override-cm
sends notification related to CI and CD
devtron
devtron-override-cm
core engine of Devtron
devtronIngress
devtron-ingress-override-cm
ingress configuration to expose Devtron
workflow
workflow-override-cm
component to run CI workload
externalSecret
external-secret-override-cm
manage secret through external stores like vault/AWS secret store
grafana
grafana-override-cm
Grafana config for dashboard
rollout
rollout-override-cm
manages blue-green and canary deployments
minio
minio-override-cm
default store for CI logs and image cache
minioStorage
minio-storage-override-cm
db config for minio
Let's take an example to understand how to override specific values. Say, you want to override annotations and host in the ingress, i.e., you want to change devtronIngress, copy the file devtron-ingress-override.yaml. This file contains a configmap to modify devtronIngress as mentioned above. Please note the structure of this configmap, data should have the key override
with a multiline string as a value.
apiVersion
, kind
, metadata.name
in the multiline string is used to match the object which needs to be modified. In this particular case it will look for apiVersion: extensions/v1beta1
, kind: Ingress
and metadata.name: devtron-ingress
and will apply changes mentioned inside update:
as per the example inside the metadata:
it will add annotations owner: app1
and inside spec.rules.http.host
it will add http://change-me
.
In case you want to change multiple objects, for eg in argocd
you want to change the config of argocd-dex-server
as well as argocd-redis
then follow the example in devtron-argocd-override.yaml.
Once we have made these changes in our local system we need to apply them to a Kubernetes cluster on which Devtron is installed currently using the below command:
Run the following command to make these changes take effect:
Our changes would have been propagated to Devtron after 20-30 minutes.
To use Devtron for production deployments, use our recommended production overrides located in manifests/updates/production. This configuration should be enough for handling up to 200 microservices.
The overall resources required for the recommended production overrides are:
cpu
6
memory
13GB
The production overrides can be applied as pre-devtron installation
as well as post-devtron installation
in the respective namespace.
If you want to install a new Devtron instance for production-ready deployments, this is the best option for you.
Create the namespace and apply the overrides files as stated above:
After files are applied, you are ready to install your Devtron instance with production-ready resources.
If you have an existing Devtron instance and want to migrate it for production-ready deployments, this is the right option for you.
In the existing namespace, apply the production overrides as we do it above.
Projects are the logical grouping of your applications so that you can manage and control the access level of users.
Refer user access for more detail.
To add a project name, go to the Projects
section of Global Configurations
.
Click Add Project
.
Provide a project name in the field and click Save
.
A global configuration allows you to easily share common configuration between multiple repositories without copy/pasting it to these repositories.
Before you start creating an application, we recommend to provide basic information in different sections of Global Configurations available in Devtron
.
You can also refer our YouTube video provided here.
You can add more chart repositories to Devtron. Once added, they will be available in the All Charts
section of the Chart Store.
Note: After the successful installation of Devtron, click Refetch Charts
to sync and download all the default charts listed on the dashboard.
To add chart repository, go to the Chart Repositories
section of Global Configurations
. Click Add repository.
Note: Only public chart repositories can be connected as of now via Devtron.
Provide below information in the following fields:
Name
Provide a Name
of your chart repository. This name is added as prefix to the name of the chart in the listing on the helm chart section of application.
URL
This is the URL of your chart repository. E.g. https://charts.bitnami.com/bitnami
You can also update your saved chart repository settings.
Click the chart repository which you want to update.
Modify the required changes and click Update
to save you changes.
Note:
You can perform a dry run to validate the below chart repo configurations by clicking Validate
.
You can enable or disable your chart repository. If you enable it, then you will be able to see the enabled chart in All Charts
section of the Chart Store.
Once Devtron is installed, it has a built-in admin
user with super admin privileges with unrestricted access to all Devtron resources. We recommended to use a user with super admin privileges for initial and global configurations only and then switch to local users or configure SSO integration.
Only users with super-admin privileges can create SSO configuration. Devtron uses Dex for authenticating a user against the identity provider.
To add/edit SSO configuration, go to the SSO Login Services
section of Global Configurations
.
Below are the SSO providers which are available in Devtron. Select one of the SSO providers (e.g., GitHub) to configure SSO:
Google GitHub GitLab Microsoft LDAP OpenID Connect OpenShift
Dex implements connectors that target specific identity providers
for each connector configuration. You must have a created account for the corresponding identity provider and registered an app for client key and secret.
Refer the following documents for more detail.
https://dexidp.io/docs/connectors/
https://dexidp.io/docs/connectors/google/
Make sure that you have a super admin access.
Go to the Global Configurations
→ SSO Login Services
and click any SSO Provider
of your choice.
In the URL
field, enter the valid Devtron application URL
where it is hosted.
For providing redirectURI
or callbackURI
registered with the SSO provider, you can either select Configuration
or Sample Script
.
Provide the client ID
and client Secret
of your SSO provider (e.g. If you select Google
as SSO provider, then you must enter $GOOGLE_CLIENT_ID
and $GOOGLE_CLIENT_SECRET
in the client ID
and client Secret
respectively.)
Select Save
to create and activate SSO Login Service.
Note:
Only single SSO login configuration can be active at one time. Whenever you create or update any SSO configuration, it will be activated and used by Devtron and previous configurations will be deleted.
Except for the domain substring, URL and redirectURI remains same.
You can change SSO configuration anytime by updating the configuration and click Update
. Note: In case of configuration change, all users will be logged out of Devtron and will have to login again.
type
: Any platform name such as (Google, GitLab, GitHub etc.)
name
: Identity provider platform name
id
: Identity provider platform which is a unique ID in string. (Refer to dexidp.io
config
: User can put connector details for this key. Platforms may not have same structure but common configurations are clientID
, clientSecret
, redirectURI
.
hostedDomains
: Domains authorized for SSO login.
After configuring an SSO for authentication, you need to add users in Devtron, else your users won't be able to log in via SSO.
In case you have enabled auto-assign permissions in Microsoft or LDAP, relevant permission groups must also exist in Devtron for a successful login.
Devtron includes predefined helm charts that cover the majority of use cases. For any use case not addressed by the default helm charts, you can upload your own helm chart and use it as a custom chart in Devtron.
Who can upload a custom chart - Super admins
Who can use the custom chart - All users
A super admin can upload multiple versions of a custom helm chart.
A valid helm chart, which contains Chart.yaml
file with name and version fields.
Image descriptor template file .image_descriptor_template.json
.
Custom chart packaged in the *.tgz
format.
You can use the following command to create the Helm chart:
Note:
Chart.yaml
is the metadata file that gets created when you create a helm chart.
Name
Name of the helm chart (Required).
Version
This is the chart version. Update this value for each new version of the chart (Required).
Description
Description of the chart (Optional).
Please see the following example:
.image_descriptor_template.json
It's a GO template file that should produce a valid JSON
file upon rendering. This file is passed as the last argument in helm install -f myvalues.yaml -f override.yaml
command.
Place the .image_descriptor_template.json
file in the root directory of your chart.
You can use the following variables in the helm template (all the placeholders are optional):
The values from the CD deployment pipeline are injected at the placeholder specified in the
.image_descriptor_template.json
template file.
image_tag
The build image tag
image
Repository name
pipelineName
The CD pipeline name created in Devtron
releaseVersion
Devtron's internal release number
deploymentType
Deployment strategy used in the pipeline
app
Application's ID within the Devtron ecosystem
env
Environment used to deploy the chart
appMetrics
For the App metrics UI feature to be effective, include the appMetrics
placeholder.
For example:
To create a template file to allow Devtron to only render the repository name and the tag from the CI/CD pipeline that you created, edit the
.image_descriptor_template.json
file as:
*.tgz
formatBefore you begin, ensure that your helm chart includes both
Chart.yaml
(withname
andversion
fields) and.image_descriptor_template.json
files.
The helm chart to be uploaded must be packaged as a versioned archive file in the format <helm-chart-name>-vx.x.x.tgz
.
The above command will create a my-custom-chart-0.1.0.tgz
file.
A custom chart can only be uploaded by a super admin.
On the Devtron dashboard, select Global Configurations > Custom charts.
Select Import Chart.
Select tar.gz file... and upload the packaged custom chart in the *.tgz
format.
The chart is being uploaded and validated. You may also Cancel upload if required.
The uploaded archive will be validated against:
Supported archive template should be in *.tgz
format.
Content of values.yaml
should be there in app-values.yaml
file.
release-values.yaml
file is required.
ConfigMap/Secret template should be same as that of our reference chart.
Chart.yaml
must include the name and the version number.
..image_descriptor_template.json
file should be present and the field format must match the format listed in the image builder template section.
The following are the validation results:
Success
The files uploaded are validated.
Enter a description for the chart and select Save or Cancel upload.
Unsupported template
Upload another chart or Cancel upload.
New version detected
You are uploading a newer version of an existing chart
Enter a Description and select Save to continue uploading, or Cancel upload.
Already exists
There already exists a chart with the same version.
Edit the version and re-upload the same chart using Upload another chart.
Upload a new chart with a new name using Upload another chart.
Cancel upload.
All users can view the custom charts.
To view a list of available custom charts, go to Global Configurations > Custom charts page.
The charts can be searched with their name, version, or description.
New custom charts can be uploaded by selecting Upload chart.
The custom charts can be used from the Deployment Template section.
Info:
The deployment strategy for a custom chart is fetched from the custom chart template and cannot be configured in the CD pipeline.
Devtron provides a sample configuration out of the box. There are some values that you need to either get from your SSO provider or give to your SSO provider.
clientID
clientSecret
redirectURI (provided in SSO Login Services by Devtron)
Devtron provides a sample configuration out of the box. There are some values that you need to either get from your SSO provider or give to your SSO provider.
clientID
clientSecret
redirectURI (provided in SSO Login Services by Devtron)
Devtron provides a sample configuration out of the box. Here are some values you need to fetch from your LDAP.
bindDN
bindPW
baseDN
SSO login requires exact matching between Devtron permission group names and LDAP user groups. Any discrepancies or missing groups will prevent successful login.
If you're missing some permissions that you know you should have, try logging out and signing back in to Devtron. This will refresh your permissions based on your latest LDAP user group.
Devtron provides a sample configuration out of the box. There are some values that you need to either get from your SSO provider or give to your SSO provider.
clientID
tenantID (required only if you want to use Azure AD for auto-assigning permissions)
clientSecret
redirectURI (provided in SSO Login Services by Devtron)
Make sure to add tenantID in the SSO configuration field without fail.
SSO login requires exact matching between Devtron permission group names and AD groups. Any discrepancies or missing groups will prevent successful login.
If your AD permissions aren't reflecting in Devtron, a quick sign-out and sign-in can resolve the issue.
Devtron provides a sample configuration out of the box. There are some values that you need to either get from your SSO provider or give to your SSO provider.
clientID
clientSecret
redirectURI (provided in SSO Login Services by Devtron)
Authorization
section describes how to authenticate and authorize access to resources, also managing role-based access levels in Devtron.
Access can be granted to a user via:
The archive file do not match the .
Since LDAP supports creation of User Groups, this feature simplifies the onboarding process of organizations having a large headcount of users. It also eliminates repetitive permission assignment by automatically mapping your LDAP User groups to Devtron's during single sign-on (SSO) login.
If you've created user groups in LDAP, you can create corresponding permission groups in Devtron with the same names. When members of those user groups first log in to Devtron, they'll automatically inherit the permissions from their Devtron permission group. This means you can't manually adjust or add mapped to a permission group.
Once you save the configuration with this auto-assign feature enabled, existing user permissions will be cleared and the future permissions will be managed through linked to LDAP user groups.
Since Microsoft supports , this feature further simplifies the onboarding process of organizations having a large headcount of users. It also eliminates repetitive permission assignment by automatically mapping your Azure AD groups to Devtron's during single sign-on (SSO) login.
If you've defined groups in your Active Directory, you can create corresponding permission groups in Devtron with the same names. When members of those Active Directory groups first log in to Devtron, they'll automatically inherit the permissions from their Devtron permission group. This means you can't manually adjust or add mapped to a permission group.
Once you save the configuration with this feature enabled, existing user permissions will be cleared and the future permissions will be managed through linked to Azure Active Directory (Microsoft Entra ID) groups.
API tokens are the access tokens for authentication. Instead of using username and password, it can be used for programmatic access to API. It allows users to generate API tokens with the desired access. Only super admin users can generate API tokens and see the generated tokens.
To generate API tokens, go to Global Configurations -> Authorization -> API tokens
and click Generate New Token
.
Enter a name for the token.
Add Description.
Select an expiration date for the token (7 days, 30 days, 60 days, 90 days, custom and no expiration).
To select a custom expiration date, select Custom
from the drop-down list. In the adjacent field, you can select your custom expiration date for the API token.
You can assign permission to the token either with:
Super admin permission: To generate a token with super admin permission, select Super admin permission
.
Specific permissions: Selecting Specific permissions
option allows you to generate a token with a specific role for:
Devtron Apps
Helm Apps
Kubernetes Resources
Chart Groups
Click Generate Token
.
A pop-up window will appear on the screen from where you can copy the API token.
Once Devtron API token has been generated, you can use this token to request Devtron APIs using any API testing tool like Jmeter, Postman, Citrus. Using Postman here as an example.
Open Postman. Enter the request URL with POST
method and under HEADERS, enter the API token as shown in the image below.
In the Body
section, provide the API payload as shown below and click Send
.
As soon as you click Send
, the created application API will be triggered and a new Devtron app will be created as provided in the payload.
To set a new expiration date or to make changes in permissions assigned to the token, we need to update the API token in Devtron. To update the API token, click the token name or click on the edit icon.
To set a new expiration date, you can regenerate the API token. Any scripts or applications using this token must be updated. To regenerate a token, click Regenerate token
.
A pop-up window will appear on the screen from where you can select a new expiration date.
Select a new expiration date and click Regenerate token
.
This will generate a new token with a new expiration date.
To update API token permissions, give the permissions as you want to and click Update Token
.
To delete an API token, click delete
icon. Any applications or scripts using this token will no longer be able to access the Devtron API.
A verified account on Okta. Okta activates your account only if email verification is successful.
Here's a reference guide to set up your Okta org and application: Link
Once your Okta org is set up, create an app integration on Okta to get a Client ID and Client Secret.
In the Admin Console, go to Applications → Applications.
Click Create App Integration.
Select OIDC - OpenID Connect as the Sign-in method.
OIDC stands for OpenID Connect. Click here to read more.
Select Web as the application type and click Next.
On the App Integration page:
Give a name to your application.
Select the Interaction Code and Refresh Token checkbox.
Now go to Devtron's Global Configurations → SSO Login Services → OIDC.
Copy the redirect URI given in the helper text (might look like: https://xxx.xxx.xxx/xxx/callback).
Return to the Okta screen, and remove the prefilled value in Sign-in redirect URIs.
Paste the copied URI in Sign-in redirect URIs.
Click Save.
On the General tab:
Note the Client ID value.
Click the Edit option.
In Client Authentication, choose Client Secret.
Click Save.
Click Generate new secret.
Note the Client Secret value.
Go to the Global Configurations → SSO Login Services → OIDC.
In the URL field, enter the Devtron application URL (a valid https link) where it is hosted.
Under Configuration
tab, locate the config object, and provide the clientID
and clientSecret
of the app integration you created on Okta.
Add a key insecureSkipEmailVerified: true
. Note that this key is only required for Okta SSO. For other types of OIDC SSO, refer OIDC supported configurations.
Provide issuer
value as https://${yourOktaDomain}
. Replace ${yourOktaDomain}
with your domain on Okta as shown in the video.
For providing redirectURI
or callbackURI
registered with the SSO provider, you can either select Configuration
or Sample Script
. Note that the redirect URI is already given in the helper text (as seen in the previous section).
Click Save to create and activate Okta SSO login.
Now your users will be able to log in to Devtron using the Okta authentication method. Note that existing signed-in users will be logged out and they have to log in again using their OIDC account.
Devtron provides a sample configuration out of the box. There are some values that you need to either get from your SSO provider or give to your SSO provider.
clientID
clientSecret
redirectURI (provided in SSO Login Services by Devtron)
Git Accounts allow you to connect your code source with Devtron. You will be able to use these git accounts to build the code using the CI pipeline.
To add git account, go to the Git accounts
section of Global Configurations
. Click Add git account.
Provide the information in the following fields to add your git account:
Name
Git host
It is the git provider on which corresponding application git repository is hosted.
Note: By default, Bitbucket
and GitHub
are available in the drop-down list. You can add many as you want by clicking [+ Add Git Host]
.
URL
Authentication Type
Devtron supports three types of authentications:
User auth: If you select User auth
as an authentication type, then you must provide the Username
and Password
or Auth token
for the authentication of your version control account.
Anonymous: If you select Anonymous
as an authentication type, then you do not need to provide the Username
and Password
.
Note: If authentication type is set as Anonymous
, only public git repository will be accessible.
SSH Key: If you choose SSH Key
as an authentication type, then you must provide the Private SSH Key
corresponding to the public key added in your version control account.
To update the git account:
Click the git account which you want to update.
Update the required changes.
Click Update
to save the changes.
Updates can only be made within one Authentication type or one protocol type, i.e. HTTPS (Anonymous or User Auth) & SSH. You can update from Anonymous
to User Auth
& vice versa, but not from Anonymous
or User Auth
to SSH
and vice versa.
Note:
You can enable or disable a git account. Enabled git accounts will be available on the App Configuration > Git repository.
Devtron provides a sample configuration out of the box. There are some values that you need to either get from your SSO provider or give to your SSO provider.
clientID
clientSecret
redirectURI (already provided in SSO Login Services by Devtron)
Provide a name to your Git provider. Note: This name will be available on the App Configuration > drop-down list.
Provide the Git host URL
.
As an example: for Github, for GitLab etc.
Using the Permission groups
, you can assign a user to a particular group and a user inherits all the permissions granted to the group.
The advantage of the Permission groups
is to define a set of privileges like create, edit, or delete for the given set of resources that can be shared among the users within the group.
The User permissions section for Specific permissions
contains a drop-down list of all existing groups for which a user has an access. This is an optional field and more than one groups can be selected for a user.
Go to Global Configurations → Authorization → Permissions groups → Add group.
Enter the Group Name
and Description
.
You can either grant super-admin permission to a user group or specific permissions to manage access for:
In Devtron Apps
option, you can provide access to a group to manage permission for custom apps created using Devtron.
The Devtron Apps
option will be available only if you install CI/CD integration.
Provide the information in the following fields:
Project
Select a project from the drop-down list to which you want to give permission to the group. You can select only one project at a time.
Note: If you want to select more than one project, then click Add row
.
Environment
Select the specific environment or all environments from the drop-down list.
Note: If you select All environments
option, then a user gets access to all the current environments including any new environment which gets associated with the application later.
Application
Select the specific applications or all applications from the drop-down list corresponding to your selected Environments.
Note: If you select All applications
option, then a user gets access to all the current applications including any new application which gets associated with the project later
.
Role
View only
Build and Deploy
Admin
Manager
You can add multiple rows for Devtron Apps
permission.
Once you have finished assigning the appropriate permissions for the groups, Click Save.
In Helm Apps
option, you can provide access to a group to manage permission for Helm apps deployed from Devtron or outside Devtron.
Provide the information in the following fields:
Project
Select a project from the drop-down list to which you want to give permission to the group. You can select only one project at a time.
Note: If you want to select more than one project, then click Add row
.
Environment or cluster/namespace
Select the specific environment or all existing environments in default cluster
from the drop-down list.
Note: If you select all existing + future environments in default cluster
option, then a user gets access to all the current environments including any new environment which gets associated with the application later.
Application
Select the specific application or all applications from the drop-down list corresponding to your selected Environments.
Note: If All applications
option is selected, then a user gets access to all the current applications including any new application which gets associated with the project later
.
Role
View only
View & Edit
Admin
You can add multiple rows for Devtron app permission.
Once you have finished assigning the appropriate permissions for the groups, Click Save.
In Jobs
option, you can provide access to a group to manage permission for jobs created using Devtron.
Provide the information in the following fields:
Project
Select a project from the drop-down list to which you want to give permission to the group. You can select only one project at a time.
Note: If you want to select more than one project, then click Add row
.
Job Name
Select the specific job name or all jobs from the drop-down list.
Note: If you select All Jobs
option, then the user gets access to all the current jobs including any new job which gets associated with the project later.
Workflow
Select the specific workflow or all workflows from the drop-down list.
Note: If you select All Workflows
option, then the user gets access to all the current workflows including any new workflow which gets associated with the project later.
Environment
Select the specific environment or all environments from the drop-down list.
Note: If you select All environments
option, then the user gets access to all the current environments including any new environment which gets associated with the project later.
Role
View only
Run job