diff --git a/.gitbook.yaml b/.gitbook.yaml
deleted file mode 100644
index 06ab70f062..0000000000
--- a/.gitbook.yaml
+++ /dev/null
@@ -1,180 +0,0 @@
-root: ./docs/
-
-redirects:
- setup: README.md
- setup/install: setup/install/README.md
- setup/install/installation-configuration: getting-started/install/installation-configuration
- setup/install/override-default-devtron-installation-configs: getting-started/install/override-default-devtron-installation-configs
- setup/install/ingress-setup: getting-started/install/ingress-setup
- setup/upgrade: setup/upgrade/README.md
- setup/upgrade/upgrade-devtron-ui: getting-started/upgrade/upgrade-devtron-ui
- setup/upgrade/devtron-upgrade-0.6.x-0.7.x: getting-started/upgrade/devtron-upgrade-0.6.x-0.7.x
- setup/upgrade/devtron-upgrade-0.5.x-0.6.x: getting-started/upgrade/devtron-upgrade-0.5.x-0.6.x
- setup/upgrade/devtron-upgrade-0.4.x-0.5.x: getting-started/upgrade/devtron-upgrade-0.4.x-0.5.x
- setup/upgrade/devtron-upgrade-0.4.x-0.4.x: getting-started/upgrade/devtron-upgrade-0.4.x-0.4.x
- setup/upgrade/devtron-upgrade-0.3.x-0.4.x: getting-started/upgrade/devtron-upgrade-0.3.x-0.4.x
- setup/upgrade/devtron-upgrade-0.3.x-0.3.x: getting-started/upgrade/devtron-upgrade-0.3.x-0.3.x
- setup/upgrade/devtron-upgrade-0.2.x-0.3.x: getting-started/upgrade/devtron-upgrade-0.2.x-0.3.x
- setup/global-configurations: user-guide/global-configurations/README.md
- setup/global-configurations/gitops: user-guide/global-configurations/gitops.md
- setup/global-configurations/custom-charts: user-guide/global-configurations/deployment-charts.md
- setup/global-configurations/user-access: user-guide/global-configurations/authorization/user-access.md
- setup/global-configurations/external-links: user-guide/global-configurations/external-links.md
- setup/global-configurations/projects: user-guide/global-configurations/projects.md
- setup/global-configurations/manage-notification: user-guide/global-configurations/manage-notification.md
- setup/global-configurations/sso-login: user-guide/global-configurations/sso-login.md
- setup/global-configurations/git-accounts: user-guide/global-configurations/git-accounts.md
- setup/global-configurations/docker-registries: user-guide/global-configurations/container-registries.md
- setup/global-configurations/chart-repo: user-guide/global-configurations/chart-repo.md
- setup/global-configurations/cluster-and-environments: user-guide/global-configurations/cluster-and-environments.md
- setup/global-configurations/authorization: user-guide/global-configurations/authorization/README.md
- setup/global-configurations/authorization/user-access: user-guide/global-configurations/authorization/user-access.md
- setup/global-configurations/authorization/permission-groups: user-guide/global-configurations/authorization/permission-groups.md
- setup/global-configurations/authorization/api-tokens: user-guide/global-configurations/authorization/api-tokens.md
- setup/global-configurations/nodejs_app: user-guide/Deploy-sample-app/nodejs_app.md
- setup/global-configurations/host-url: user-guide/global-configurations/host-url.md
- setup/global-configurations/authorization/sso/google: user-guide/global-configurations/authorization/sso/google.md
- setup/global-configurations/authorization/sso/github: user-guide/global-configurations/authorization/sso/github.md
- setup/global-configurations/authorization/sso/gitlab: user-guide/global-configurations/authorization/sso/gitlab.md
- setup/global-configurations/authorization/sso/microsoft: user-guide/global-configurations/authorization/sso/microsoft.md
- setup/global-configurations/authorization/sso/ldap: user-guide/global-configurations/authorization/sso/ldap.md
- setup/global-configurations/authorization/sso/oidc: user-guide/global-configurations/authorization/sso/oidc.md
- setup/global-configurations/authorization/sso/openshift: user-guide/global-configurations/authorization/sso/openshift.md
- setup/global-configurations/okta: user-guide/global-configurations/authorization/sso/okta.md
- setup/global-configurations/catalog-framework: user-guide/global-configurations/catalog-framework.md
- setup/global-configurations/scoped-variables: user-guide/global-configurations/scoped-variables.md
- setup/global-configurations/pull-image-digest: user-guide/global-configurations/pull-image-digest.md
- setup/global-configurations/tags-policy: user-guide/global-configurations/tags-policy.md
- setup/global-configurations/lock-deployment-config: user-guide/global-configurations/lock-deployment-config.md
- setup/global-configurations/image-promotion-policy: user-guide/global-configurations/image-promotion-policy.md
- setup/global-configurations/filter-condition: user-guide/global-configurations/filter-condition.md
- setup/global-configurations/build-infra: user-guide/global-configurations/build-infra.md
- user-guide/creating-application: user-guide/applications.md
- user-guide/creating-application/git-material: usage/applications/creating-application/git-material
- user-guide/creating-application/docker-build-configuration: usage/applications/creating-application/docker-build-configuration
- user-guide/creating-application/deployment-template: usage/applications/creating-application/deployment-template
- user-guide/creating-application/deployment-template/rollout-deployment: usage/applications/creating-application/deployment-template/rollout-deployment
- user-guide/creating-application/deployment-template/job-and-cronjob: usage/applications/creating-application/deployment-template/job-and-cronjob
- user-guide/creating-application/workflow: user-guide/creating-application/workflow/README.md
- user-guide/creating-application/workflow/ci-pipeline: user-guide/creating-application/workflow/ci-pipeline.md
- user-guide/creating-application/workflow/ci-pipeline/ci-build-pre-post-plugins: user-guide/creating-application/workflow/pre-post-tasks.md
- usage/applications/creating-application/ci-pipeline/ci-build-pre-post-plugins: user-guide/creating-application/workflow/pre-post-tasks.md
- usage/applications/creating-application/ci-pipeline: user-guide/creating-application/workflow/ci-pipeline.md
- user-guide/creating-application/workflow/cd-pipeline: user-guide/creating-application/workflow/cd-pipeline.md
- user-guide/creating-application/workflow/ci-pipeline-legacy: user-guide/creating-application/workflow/ci-pipeline.md
- user-guide/creating-application/config-maps: usage/applications/creating-application/config-maps
- user-guide/creating-application/secrets: usage/applications/creating-application/secrets
- user-guide/creating-application/environment-overrides: usage/applications/creating-application/environment-overrides
- user-guide/creating-application/app-metrics: usage/applications/app-details/app-metrics
- usage/app-details: user-guide/app-details/README.md
- user-guide/app-details: user-guide/app-details/README.md
- user-guide/debugging-deployment-and-monitoring: usage/applications/app-details/debugging-deployment-and-monitoring
- user-guide/cloning-application: usage/applications/cloning-application
- user-guide/deploying-application: user-guide/deploying-application/README.md
- user-guide/deploying-application/triggering-ci: usage/applications/deploying-application/triggering-ci
- user-guide/deploying-application/triggering-cd: usage/applications/deploying-application/triggering-cd
- user-guide/deploy-chart: user-guide/deploy-chart/README.md
- user-guide/deploy-chart/deployment-of-charts: usage/deploy-chart/deployment-of-charts
- user-guide/deploy-chart/examples: user-guide/deploy-chart/deployment-of-charts.md
- usage/deploy-chart/examples: user-guide/deploy-chart/deployment-of-charts.md
- user-guide/deploy-chart/examples/deploying-mysql-helm-chart: user-guide/deploy-chart/deployment-of-charts.md
- user-guide/deploy-chart/examples/deploying-mongodb-helm-chart: user-guide/deploy-chart/deployment-of-charts.md
- usage/deploy-chart/examples/deploying-mongodb-helm-chart: user-guide/deploy-chart/deployment-of-charts.md
- usage/deploy-chart/examples/deploying-mysql-helm-chart: user-guide/deploy-chart/deployment-of-charts.md
- user-guide/deploy-chart/chart-group: usage/deploy-chart/chart-group
- user-guide/namespaces-and-environments: user-guide/global-configurations/cluster-and-environments.md
- user-guide/security-features: usage/security-features
- user-guide/deleting-application: usage/applications/creating-application/deleting-application
- user-guide/bulk-update: usage/bulk-update
- user-guide/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job: resources/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job
- user-guide/use-cases: user-guide/use-cases/README.md
- user-guide/use-cases/connect-springboot-with-mysql-database: resources/use-cases/connect-springboot-with-mysql-database
- user-guide/use-cases/connect-expressjs-with-mongodb-database: resources/use-cases/connect-expressjs-with-mongodb-database
- user-guide/use-cases/connect-django-with-mysql-database: resources/use-cases/connect-django-with-mysql-database
- user-guide/telemetry: resources/telemetry
- getting-started/install/installation-configuration: setup/install/installation-configuration.md
- getting-started/global-configurations: user-guide/global-configurations/README.md
- getting-started/global-configurations/container-registries: user-guide/global-configurations/container-registries.md
- getting-started/global-configurations/sso-login: user-guide/global-configurations/sso-login.md
- getting-started/global-configurations/docker-registries: user-guide/global-configurations/container-registries.md
- getting-started/global-configurations/host-url: user-guide/global-configurations/host-url.md
- getting-started/global-configurations/authorization/sso/google: user-guide/global-configurations/authorization/sso/google.md
- getting-started/global-configurations/authorization/sso/github: user-guide/global-configurations/authorization/sso/github.md
- getting-started/global-configurations/authorization/sso/gitlab: user-guide/global-configurations/authorization/sso/gitlab.md
- getting-started/global-configurations/authorization/sso/microsoft: user-guide/global-configurations/authorization/sso/microsoft.md
- getting-started/global-configurations/authorization/sso/ldap: user-guide/global-configurations/authorization/sso/ldap.md
- getting-started/global-configurations/authorization/sso/oidc: user-guide/global-configurations/authorization/sso/oidc.md
- getting-started/global-configurations/authorization/sso/openshift: user-guide/global-configurations/authorization/sso/openshift.md
- getting-started/global-configurations/okta: user-guide/global-configurations/authorization/sso/okta.md
- getting-started/global-configurations/catalog-framework: user-guide/global-configurations/catalog-framework.md
- getting-started/global-configurations/scoped-variables: user-guide/global-configurations/scoped-variables.md
- getting-started/global-configurations/pull-image-digest: user-guide/global-configurations/pull-image-digest.md
- getting-started/global-configurations/tags-policy: user-guide/global-configurations/tags-policy.md
- getting-started/global-configurations/lock-deployment-config: user-guide/global-configurations/lock-deployment-config.md
- getting-started/global-configurations/image-promotion-policy: user-guide/global-configurations/image-promotion-policy.md
- getting-started/global-configurations/filter-condition: user-guide/global-configurations/filter-condition.md
- getting-started/global-configurations/build-infra: user-guide/global-configurations/build-infra.md
- getting-started/global-configurations/gitops: user-guide/global-configurations/gitops.md
- getting-started/global-configurations/custom-charts: user-guide/global-configurations/deployment-charts.md
- getting-started/global-configurations/external-links: user-guide/global-configurations/external-links.md
- getting-started/global-configurations/projects: user-guide/global-configurations/projects.md
- getting-started/global-configurations/manage-notification: user-guide/global-configurations/manage-notification.md
- getting-started/global-configurations/git-accounts: user-guide/global-configurations/git-accounts.md
- getting-started/global-configurations/chart-repo: user-guide/global-configurations/chart-repo.md
- getting-started/global-configurations/cluster-and-environments: user-guide/global-configurations/cluster-and-environments.md
- getting-started/global-configurations/authorization: user-guide/global-configurations/authorization/README.md
- getting-started/global-configurations/authorization/user-access: user-guide/global-configurations/authorization/user-access.md
- getting-started/global-configurations/authorization/permission-groups: user-guide/global-configurations/authorization/permission-groups.md
- getting-started/global-configurations/authorization/api-tokens: user-guide/global-configurations/authorization/api-tokens.md
- getting-started/upgrade: setup/upgrade/README.md
- getting-started/upgrade/upgrade-devtron-ui: setup/upgrade/upgrade-devtron-ui
- getting-started/upgrade/devtron-upgrade-0.6.x-0.7.x: setup/upgrade/devtron-upgrade-0.6.x-0.7.x.md
- getting-started/upgrade/devtron-upgrade-0.5.x-0.6.x: setup/upgrade/devtron-upgrade-0.5.x-0.6.x.md
- getting-started/upgrade/devtron-upgrade-0.4.x-0.5.x: setup/upgrade/devtron-upgrade-0.4.x-0.5.x.md
- getting-started/upgrade/devtron-upgrade-0.4.x-0.4.x: setup/upgrade/devtron-upgrade-0.4.x-0.4.x.md
- getting-started/upgrade/devtron-upgrade-0.3.x-0.4.x: setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md
- getting-started/upgrade/devtron-upgrade-0.3.x-0.3.x: setup/upgrade/devtron-upgrade-0.3.x-0.3.x.md
- getting-started/upgrade/devtron-upgrade-0.2.x-0.3.x: setup/upgrade/devtron-upgrade-0.2.x-0.3.x.md
- global-configurations/sso-login: user-guide/global-configurations/sso-login.md
- user-guide/use-cases/untitled-3: user-guide/use-cases/connect-django-with-mysql-database.md
- global-configurations/api-token: user-guide/global-configurations/authorization/api-tokens.md
- user-guide/creating-application/workflow/ci-pipeline2: user-guide/creating-application/workflow/ci-pipeline.md
- user-guide/clusters: user-guide/resource-browser.md
- usage/clusters: user-guide/resource-browser.md
- global-configurations/authorization/sso-login/okta: user-guide/global-configurations/authorization/sso/okta.md
- global-configurations/custom-charts: user-guide/global-configurations/deployment-charts.md
- global-configurations/plugins-policy: user-guide/global-configurations/plugin-policy.md
- usage/sdh: user-guide/software-distribution-hub/README.md
- usage/sdh/tenants: user-guide/software-distribution-hub/tenants.md
- usage/sdh/release-hub: user-guide/software-distribution-hub/release-hub.md
- usage/deploy-chart/overview-of-charts: user-guide/deploy-chart/README.md
- user-guide/deploy-chart/overview-of-charts: user-guide/deploy-chart/README.md
- usage/integrations/clair: user-guide/integrations/vulnerability-scanning/clair.md
- usage/resource-browser/devtron-intelligence: user-guide/devtron-intelligence.md
- faqs-and-troubleshooting/devtron-troubleshoot: FAQs/devtron-troubleshoot.md
- usage/applications/creating-application/config-approval: user-guide/global-configurations/approval-policy.md
- user-guide: README.md
- setup/install/install-devtron-helm-3: setup/install/README.md
- setup/install/install-devtron-using-kubectl: setup/install/README.md
- faqs-and-troubleshooting: FAQs/devtron-troubleshoot.md
- user-guide/creating-application/workflow/automated-test: user-guide/creating-application/workflow/README.md
- setup/stack-manager: user-guide/integrations/README.md
- user-guide/command-bar: user-guide/command-bar.md
- setup/install/enterprise-license: setup/install/freemium.md
- enterprise-license: setup/install/freemium.md
- usage/applications/creating-application/workflow/ci-pipeline/ci-build-pre-post-plugins: user-guide/creating-application/workflow/pre-post-tasks.md
- usage/applications/creating-application/workflow/ci-pipeline/container-registry-override: user-guide/creating-application/workflow/ci-pipeline.md
- usage/jobs/configuration-job: user-guide/jobs/configuration-job
- user-guide/jobs/configuration-job: user-guide/jobs/configurations/README.md
- usage/jobs/workflow-editor-job: user-guide/jobs/workflow-editor-job
- user-guide/jobs/workflow-editor-job: user-guide/jobs/configurations/workflow-editor-job.md
- setup/install/install-devtron-with-cicd: setup/install/README.md
- setup/install/install-devtron-with-cicd-with-gitops: setup/install/README.md
- setup/install/install-devtron-on-minikube-microk8s-k3s-kind: setup/install/README.md
- setup/install/faq-on-installation: setup/install/faq-on-installation.md
- install/install-devtron-with-cicd: setup/install/README.md
- install/install-devtron-with-cicd-with-gitops: setup/install/README.md
- install/install-devtron-on-minikube-microk8s-k3s-kind: setup/install/README.md
- install/faq-on-installation: setup/install/faq-on-installation.md
- prod-infra: setup/install/prod-infra.md
- configurations-overview: setup/configurations/configurations-overview.md
\ No newline at end of file
diff --git a/.gitignore b/.gitignore
index c56fd8f053..1332a6de37 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,6 +1,25 @@
-.idea
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Backup
+/docs-backup
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
.DS_Store
-.vscode
-.env
-/cmd/external-app/devtron-ea
-devtron
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+checkEmptyOrHeadingFiles.mjsgit
\ No newline at end of file
diff --git a/.vscode/ltex.hiddenFalsePositives.en-US.txt b/.vscode/ltex.hiddenFalsePositives.en-US.txt
new file mode 100644
index 0000000000..767614008c
--- /dev/null
+++ b/.vscode/ltex.hiddenFalsePositives.en-US.txt
@@ -0,0 +1 @@
+{"rule":"ENGLISH_WORD_REPEAT_RULE","sentence":"^\\QBackup Name Required Specify a unique name for the backup that will be created from the selected schedule\nSchedule Required Select an existing backup schedule.\\E$"}
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
deleted file mode 100644
index 741b8b35b2..0000000000
--- a/CODE_OF_CONDUCT.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# Contributor Covenant Code of Conduct
-
-## Our Pledge
-
-In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our project and
-our community a harassment-free experience for everyone, regardless of age, body
-size, disability, ethnicity, sex characteristics, gender identity and expression,
-level of experience, education, socio-economic status, nationality, personal
-appearance, race, religion, or sexual identity and orientation.
-
-## Our Standards
-
-Examples of behavior that contributes to creating a positive environment
-include:
-
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
-
-Examples of unacceptable behavior by participants include:
-
-* The use of sexualized language or imagery and unwelcome sexual attention or
- advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
- address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
- professional setting
-
-## Our Responsibilities
-
-Project maintainers are responsible for clarifying the standards of acceptable
-behavior and are expected to take appropriate and fair corrective action in
-response to any instances of unacceptable behavior.
-
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
-
-## Scope
-
-This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community. Examples of
-representing a project or community include using an official project e-mail
-address, posting via an official social media account, or acting as an appointed
-representative at an online or offline event. Representation of a project may be
-further defined and clarified by project maintainers.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the project team at contact@devtron.ai. All
-complaints will be reviewed and investigated and will result in a response that
-is deemed necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of an incident.
-Further details of specific enforcement policies may be posted separately.
-
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
-
-[homepage]: https://www.contributor-covenant.org
-
-For answers to common questions about this code of conduct, see
-https://www.contributor-covenant.org/faq
diff --git a/COMMUNITY_CONTRIBUTIONS.md b/COMMUNITY_CONTRIBUTIONS.md
deleted file mode 100644
index bcdf1e736c..0000000000
--- a/COMMUNITY_CONTRIBUTIONS.md
+++ /dev/null
@@ -1,35 +0,0 @@
-# What Community Says about Devtron
-
- We at Devtron Labs always welcome the inspections done for our projects. Your reviews and support matters a lot, in terms of blogs, how-to-guides or videos. You are free to create any of them. We will feature the blogs and videos from our medium including the name of the authors. Add the links for blogs and videos and raise a PR for it. We would love to onboard you all as our valuable contributors.
-
-## Blogs
-
-* https://golangexample.com/an-open-source-software-delivery-workflow-for-kubernetes-written-in-go/ - By Golang Example
-
-* https://collabnix.com/top-10-kubernetes-tool-you-need-for-2021-devtron/ - By Collabnix Community
-
-* https://blog.livspace.io/how-livspace-revolutionised-its-ci-cd-saga-3120724e271b - By Livspace
-
-* https://dzone.com/articles/appops-with-kubernetes-and-devtron-the-perfect-fit - By Sudip Sengupta, Javelynn
-
-* https://gochronicles.com/devtron-introduction/ - By Go-Chronicals (Part-1)
-
-* https://gochronicles.com/installing-devtron/ - By Go-Chronicals (Part-2)
-
-* https://gochronicles.com/devtron-deploy/ - By Go-Chronicals (Part-3)
-* https://community.codenewbie.org/varghesejose2020/opensourcekubernetesdevtron-3fjj -By Varghese Jose
-
-* https://www.financialexpress.com/industry/sme/devtron-a-business-opportunity-in-developers-needs/2274094/ - By Srinath Srinivasan
-
-
-## Videos
-
-* https://www.youtube.com/watch?v=ZKcfZC-zSMM - By Victor Farcic
-
-* https://www.youtube.com/watch?v=bA6zgjPD_yA&t=2927s - FOSS United Conference
-
-* https://www.youtube.com/watch?v=ekxHV2Gje-E&t=7856s - AWS UG OSTech Conf 2021
-
-* https://www.youtube.com/watch?v=W4-UorfDQxI - Carbon_Capital Consulting
-
-* https://www.youtube.com/watch?v=FB5BI3Ef7uw&t=363s - Let's learn Devtron
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
deleted file mode 100644
index 96a37df429..0000000000
--- a/CONTRIBUTING.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# How to Contribute
-
-Devtron is [Apache 2.0 licensed](LICENSE) and accepts contributions via GitHub
-pull requests. This document outlines some of the conventions on development
-workflow, commit message formatting, contact points and other resources to make
-it easier to get your contribution accepted.
-
-We gratefully welcome improvements to issues and documentation as well as to code.
-
-## Certificate of Origin
-
-By contributing to this project you agree to the Developer Certificate of
-Origin (DCO). This document was created by the Linux Kernel community and is a
-simple statement that you, as a contributor, have the legal right to make the
-contribution. No action from you is required, but it's a good idea to see the
-[DCO](DCO) file for details before you start contributing code to Devtron.
-
-## Communications
-
-The project uses discord for communication:
-
-To join the conversation, simply join the **[discord](https://discord.gg/jsRG5qx2gp)** and use the __#contrib__ channel.
-
-## Code Structure
-
-Devtron has following components
-
-- [devtron](https://github.com/devtron-labs/devtron.git) main co-ordinating engine
-- [git-sensor](https://github.com/devtron-labs/git-sensor.git) microservice for watching and interacting with git
-- [ci-runner](https://github.com/devtron-labs/ci-runner.git) Devtron runner for executing jobs
-- [guard](https://github.com/devtron-labs/guard.git) A kubernetes validating webhook for policy inforcement
-- [imge-scanner](https://github.com/devtron-labs/image-scanner.git) microservice for docker image vulnerability scanning
-- [kubewatch](https://github.com/devtron-labs/kubewatch.git) microservice for k8s event filtering and recording
-- [lens](https://github.com/devtron-labs/lens.git) microservice for performing analytical task
-- [dashboard](https://github.com/devtron-labs/dashboard.git) UI for devtron written in react js
-
-
-### Contribute Helm Charts
-
-[Contribute your helm charts](https://github.com/devtron-labs/devtron/tree/main/contrib-chart) for the devtron community for upcoming `community charts` feature
-
diff --git a/DCO b/DCO
deleted file mode 100644
index 8201f99215..0000000000
--- a/DCO
+++ /dev/null
@@ -1,37 +0,0 @@
-Developer Certificate of Origin
-Version 1.1
-
-Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
-1 Letterman Drive
-Suite D4700
-San Francisco, CA, 94129
-
-Everyone is permitted to copy and distribute verbatim copies of this
-license document, but changing it is not allowed.
-
-
-Developer's Certificate of Origin 1.1
-
-By making a contribution to this project, I certify that:
-
-(a) The contribution was created in whole or in part by me and I
- have the right to submit it under the open source license
- indicated in the file; or
-
-(b) The contribution is based upon previous work that, to the best
- of my knowledge, is covered under an appropriate open source
- license and I have the right under that license to submit that
- work with modifications, whether created in whole or in part
- by me, under the same open source license (unless I am
- permitted to submit under a different license), as indicated
- in the file; or
-
-(c) The contribution was provided directly to me by some other
- person who certified (a), (b) or (c) and I have not modified
- it.
-
-(d) I understand and agree that this project and the contribution
- are public and that a record of the contribution (including all
- personal information I submit with it, including my sign-off) is
- maintained indefinitely and may be redistributed consistent with
- this project or the open source license(s) involved.
diff --git a/LICENSE b/LICENSE
old mode 100644
new mode 100755
index f29b0c0b24..e6c38ff069
--- a/LICENSE
+++ b/LICENSE
@@ -199,4 +199,4 @@
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
- limitations under the License.
+ limitations under the License.
\ No newline at end of file
diff --git a/README.md b/README.md
old mode 100644
new mode 100755
index 31b0d15cc8..8f2c597d65
--- a/README.md
+++ b/README.md
@@ -1,243 +1,157 @@
-
-
-
-
-
-
-
Cloud Native 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](#install-devtron) helps you deploy, observe, manage & debug existing Helm apps in all your clusters.
-
-
-## Devtron Demo Environment
-
-Please log in the Demo environment using github credentials. Please note the user is granted view access.
-
-## Devtron Features
-
-Application-level Resource grouping for easier Debugging
-
-
-- Devtron groups your Kubernetes objects deployed via Helm charts and display them in a slick UI for easier monitoring or debugging. Access pod logs and resource manifests right from the Devtron UI and even edit them!
-
-
-Centralized Access Management
-
-
-- Control and give customizable view-only, edit access to users on Project, Environment and Application levels
-
-
-Deploy, Manage and Observe on multiple clusters
-
-
-- Deploy and manage Helm charts, applications across multiple Kubernetes clusters (hosted on multiple clouds/on-prem) right from a single Devtron setup
-
-
-
-
-## Integrations
-
-Devtron is designed to be modular, and its functionality can be easily extended with the help of integrations.
-
-### CI/CD Integration
-
-[Devtron CI/CD with GitOps](./docs/setup/install/devtron-oss.md#tab-with-ci-cd--gitops-argo-cd) integration is used to automate the builds and deployments and enables the software development teams to focus on meeting the business requirements, code quality, and security.
-
-* Devtron leverages Kubernetes auto-scaling and centralized caching to give you unlimited cost-efficient CI workers.
-* Supports pre-CI and post-CI integrations for code quality monitoring.
-* Seamlessly integrates with Clair for image vulnerability scanning.
-* Supports different deployment strategies: Blue/Green, Rolling, Canary, and Recreate.
-* Implements GitOps to manage the state of Kubernetes applications.
-* Integrates with ArgoCD for continuous deployment.
-* Checks logs, events, and manifests or exec inside containers for debugging.
-* Provides deployment metrics like; deployment frequency, lead time, change failure rate, and mean-time recovery.
-* Seamlessly integrates with Grafana for continuous application metrics like CPU and memory usage, status code, throughput, and latency on the dashboard.
-
-## Architecture
-
-
-
-## Installation
-
-Before you begin, you must create a [Kubernetes cluster](https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/) (preferably K8s 1.16 or higher) and install [Helm](https://helm.sh/docs/intro/install/).
-
-### 1. Install Devtron with CI/CD Integration
-
-Run the following command to install the latest version of Devtron along with the CI/CD module:
+# Devtron Documentation
-```bash
-helm repo add devtron https://helm.devtron.ai
+Welcome to the official **Devtron Documentation Repository**
+This repo hosts the complete documentation for installing, using, and managing Devtron, an open-source software delivery platform built on Kubernetes.
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd}
-```
+---
-### Access Devtron
+## 🚀 What is Devtron?
-**URL**: Use the following command to get the dashboard URL:
+**[Devtron](https://devtron.ai)** is an open-source Kubernetes-native software delivery platform that simplifies complex CI/CD, infrastructure, and release management workflows.
-```bash
-kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
-```
+It provides:
+* Unified dashboards for build, deploy, and monitoring
+* GitOps-driven deployment (powered by ArgoCD)
+* AI-powered debugging and recommendations
+* Built-in vulnerability scanning
+* Plugin ecosystem for extensibility
+* Cluster and cost visibility
+* Role-based access control (RBAC) and SSO integrations
+
+With Devtron, teams can deploy and manage applications across multiple environments without the steep Kubernetes learning curve.
+
+---
+
+## 🧩 Repository Overview
+
+This repository powers the **[Devtron Docs site](https://docs.devtron.ai)** using **Docusaurus v3**.
+It contains all documentation files, categorized and rendered as website pages.
+
+### 📁 Folder Structure
+
+| Path | Description |
+|------|--------------|
+| `/docs/` | Main documentation directory containing Markdown (`.md`) and MDX files. |
+| `/docs/setup/` | Installation and configuration guides. |
+| `/docs/user-guide/` | Core user guides including Application Management, Infra, Policies, etc. |
+| `/docs/reference/` | FAQs, troubleshooting, and glossaries. |
+| `/static/` | Static assets such as images and icons. |
+| `/sidebars.js` | Defines documentation hierarchy and navigation structure. |
+| `/docusaurus.config.js` | Core site configuration including theme and plugins. |
+| `/src/` | Contains React components, layouts, and theme overrides. |
+
+---
+
+## 🧱 Docs Scaffolding Explained
+
+The documentation follows a structured hierarchy defined in [`sidebars.js`](./sidebars.js):
+
+| Section | Purpose |
+|----------|----------|
+| **Getting Started** | Onboarding and installation instructions for new users. |
+| **Application Management** | Creating, configuring, and managing applications in Devtron. |
+| **Infrastructure Management** | Managing clusters, resources, and node-level operations. |
+| **Software Release Management** | Handling multi-tenant releases and deployment visibility. |
+| **Cost Visibility** | Insights into FinOps capabilities of Devtron. |
+| **Security** | Insights into security scanning and policies. |
+| **Automation & Enablement** | Job automation, task configuration, and workflow management. |
+| **AI Recommendations** | Features powered by Devtron’s AI system. |
+| **Global Configurations** | Managing host URL, GitOps, SSO, permissions, and global policies. |
+| **Resources** | References, integrations, upgrades, and use cases. |
+
+Each folder contains a `README.md` file that serves as an index page and links to nested topics.
-**Credentials**:
+---
-**UserName**: `admin`
-**Password**: Run the following command to get the admin password for Devtron version v0.6.0 and higher
+## 🛠️ Getting Started (Local Development)
+
+### Prerequisites
+* **Node.js** ≥ 18.x
+* **npm** or **Yarn** or
+
+### Installation
```bash
-kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+# Clone the repo
+git clone https://github.com/devtron-labs/devtron-documentation.git
+cd devtron-docs
+
+# Install dependencies
+npm install
+# or
+yarn install
```
-For Devtron version less than v0.6.0, run the following command to get the admin password:
+### Run the Docs Locally
```bash
-kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ACD_PASSWORD}' | base64 -d
+npm run start
+# or
+yarn start
```
+Your site will be available at 👉 **http://localhost:3000**
+
+---
+
+## 📦 Build for Production
-Please refer to the document for more information on how to [access the Devtron Dashboard](./docs/setup/install/devtron-oss.md#step-3-obtain-the-dashboard-url).
+To generate an optimized static build resembling production behavior:
-#### Installation Status
+```bash
+npm run build
+# or
+yarn build
+```
-The above install command for CI/CD integration starts Devtron-operator, which takes about 20 minutes to spin up all of the Devtron microservices one by one. You can check the status of the installation with the following command:
+This will create a production-ready site in the `/build` directory. Use the following command to access it:
```bash
-kubectl -n devtroncd get installers installer-devtron \
--o jsonpath='{.status.sync.status}'
+npm run serve
+# or
+yarn serve
```
-The command executes with one of the following output messages, indicating the status of the installation:
+Your site will be available at 👉 **http://localhost:3000**
-* **Downloaded**: The installer has downloaded all the manifests, and installation is in progress.
-* **Applied**: The installer has successfully applied all the manifests, and the installation is complete.
+---
-### 2. Install Devtron with Helm Bundle
+## 🧑💻 Contributing Guidelines
-```bash
-helm repo add devtron https://helm.devtron.ai
+We welcome contributions from both internal as well as external contributors.
+Whether it’s fixing typos, improving clarity, or adding new guides, your help makes our documentation better.
-helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd
+### Quick Start
+1. Fork this repository
+2. Create a branch (`git checkout -b feature/add-new-guide`)
+3. Make your changes
+4. Commit and push
+5. Open a Pull Request (PR) to the `main` branch
-```
+---
+
+## 🧭 Writing Guidelines
+
+* Use clear, concise language
+* Use title case for titles and headings.
+* Prefer active voice (e.g., “Click Deploy” instead of “The button should be clicked”)
+* Use fenced code blocks for commands or YAML
+* Use Docusaurus admonitions (`:::tip`, `:::warning`, etc.) for emphasis
+* Keep paragraphs short and scannable
+
+---
+
+## 📘 License
+
+This repository is licensed under the **Apache 2.0 License**.
+See the [LICENSE](./LICENSE) file for more details.
+
+---
+
+## 🌐 Useful Links
-
-
-## :blue_heart: Technology
-
-Devtron is built on some of the most trusted and loved technologies:
-
-
-
-## :video_camera: Videos
-
-- [Devtron - A Comprehensive Overview](https://youtu.be/FB5BI3Ef7uw?t=363)
-- [Viktor Farcic's review](https://youtu.be/ZKcfZC-zSMM)
-- [Running an application on Devtron](https://youtu.be/bA6zgjPD_yA?t=2927)
-- [Devtron Demo](https://youtu.be/ekxHV2Gje-E?t=7856)
-
-## :memo: Blogs from Community
-
-* [How Livspace revolutionised its CI/CD saga](https://blog.livspace.io/how-livspace-revolutionised-its-ci-cd-saga-3120724e271b)
-* [AppOps with Kubernetes and Devtron: The Perfect Fit](https://hackernoon.com/appops-with-kubernetes-and-devtron-the-perfect-fit-sj934qj)
-* [Getting started with GitOps on Kubernetes with Devtron](https://piotrminkowski.com/2022/05/04/getting-started-with-gitops-on-kubernetes-with-devtron)
-* [Zero to hero on Kubernetes with Devtron](https://dzone.com/articles/zero-to-hero-on-kubernetes-with-devtron)
-* [Kubernetes deployment made easy](https://medium.com/container-talks/kubernetes-deployment-made-easy-cc74f0242f06)
-
-## :muscle: Trusted By
-
-Devtron is trusted by communities all across the globe. The list of organizations using Devtron can be found [here](./USERS.md).
-
-
-## :question: FAQs & Troubleshooting
-
-- Devtron - [see here](https://docs.devtron.ai/resources/devtron-troubleshoot)
-
-## :page_facing_up: Compatibility
-
-### Current build
-
-- Devtron uses modified version of [Argo Rollout](https://argoproj.github.io/argo-rollouts/)
-- Application metrics only work for K8s version 1.16+
-
-## Support, Contribution, and Community
-
-## :busts_in_silhouette: Community
-
-Get updates on Devtron's development and chat with project maintainers, contributors, and community members
-- Follow [@DevtronL on Twitter](https://twitter.com/DevtronL)
-- Raise feature requests, suggest enhancements, and report bugs in our [GitHub Issues](https://github.com/devtron-labs/devtron/issues)
-- Articles, Howtos, Tutorials - [Devtron Blogs](https://devtron.ai/blog/)
-
-### Join us at Discord channel
-
-
-## :handshake: Contribute
-
-Check out our [contributing guidelines](CONTRIBUTING.md). Included, are directions for opening issues, coding standards, and notes on our development processes. We deeply appreciate your contribution.
-
-Please look at our [community contributions](COMMUNITY_CONTRIBUTIONS.md) and feel free to create a video or blog around Devtron and add your valuable contribution to the list.
-
-### Contributors:
-
-We are deeply grateful to all our amazing contributors!
-
-
-
-
-
-## :bug: Vulnerability Reporting
-
-We at Devtron, take security and our users' trust very seriously. If you believe you have found a security issue, please report it to security@devtron.ai.
-
-## :bookmark: License
-
-Devtron is licensed under [Apache License, Version 2.0](LICENSE)
+* [Devtron Website](https://devtron.ai)
+* [Docs Portal](https://docs.devtron.ai)
+* [GitHub Repository](https://github.com/devtron-labs/devtron)
+* [Join the Slack Community](https://devtron.ai/community)
+* [Release Notes](https://github.com/devtron-labs/devtron/releases)
diff --git a/assets/Architecture.jpg b/assets/Architecture.jpg
deleted file mode 100644
index cce76cd595..0000000000
Binary files a/assets/Architecture.jpg and /dev/null differ
diff --git a/assets/GithubPullRequest-Plugin-logo.png b/assets/GithubPullRequest-Plugin-logo.png
deleted file mode 100644
index 61ea0ebf12..0000000000
Binary files a/assets/GithubPullRequest-Plugin-logo.png and /dev/null differ
diff --git a/assets/GithubReleasePluginlogo.png b/assets/GithubReleasePluginlogo.png
deleted file mode 100644
index bdbeafdb41..0000000000
Binary files a/assets/GithubReleasePluginlogo.png and /dev/null differ
diff --git a/assets/Hyperion features.mp4 b/assets/Hyperion features.mp4
deleted file mode 100644
index 50a25445dd..0000000000
Binary files a/assets/Hyperion features.mp4 and /dev/null differ
diff --git a/assets/MailMaster.png b/assets/MailMaster.png
deleted file mode 100644
index db59565b80..0000000000
Binary files a/assets/MailMaster.png and /dev/null differ
diff --git a/assets/ansible-runner.svg b/assets/ansible-runner.svg
deleted file mode 100644
index 2f3777caf7..0000000000
--- a/assets/ansible-runner.svg
+++ /dev/null
@@ -1,17 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/assets/banner-clients.png b/assets/banner-clients.png
deleted file mode 100644
index fe96fd7fd4..0000000000
Binary files a/assets/banner-clients.png and /dev/null differ
diff --git a/assets/bitbucket-logo-plugin.jpeg b/assets/bitbucket-logo-plugin.jpeg
deleted file mode 100644
index e622a0a0b7..0000000000
Binary files a/assets/bitbucket-logo-plugin.jpeg and /dev/null differ
diff --git a/assets/branch-compare-plugin-logo.png b/assets/branch-compare-plugin-logo.png
deleted file mode 100644
index d7529f2d48..0000000000
Binary files a/assets/branch-compare-plugin-logo.png and /dev/null differ
diff --git a/assets/cloudanix-logo.png b/assets/cloudanix-logo.png
deleted file mode 100644
index 1b549e35b9..0000000000
Binary files a/assets/cloudanix-logo.png and /dev/null differ
diff --git a/assets/codacy-plugin-icon.png b/assets/codacy-plugin-icon.png
deleted file mode 100644
index 228ab07025..0000000000
Binary files a/assets/codacy-plugin-icon.png and /dev/null differ
diff --git a/assets/copa-plugin-icon.png b/assets/copa-plugin-icon.png
deleted file mode 100644
index 0039b17c00..0000000000
Binary files a/assets/copa-plugin-icon.png and /dev/null differ
diff --git a/assets/cosign-logo.png b/assets/cosign-logo.png
deleted file mode 100644
index 06900dc8b8..0000000000
Binary files a/assets/cosign-logo.png and /dev/null differ
diff --git a/assets/cranecopy.png b/assets/cranecopy.png
deleted file mode 100644
index b9a008cbcb..0000000000
Binary files a/assets/cranecopy.png and /dev/null differ
diff --git a/assets/dTrack-plugin-icon.png b/assets/dTrack-plugin-icon.png
deleted file mode 100644
index 5b015530b1..0000000000
Binary files a/assets/dTrack-plugin-icon.png and /dev/null differ
diff --git a/assets/devtron-darkmode-logo.png b/assets/devtron-darkmode-logo.png
deleted file mode 100644
index ac3511ada1..0000000000
Binary files a/assets/devtron-darkmode-logo.png and /dev/null differ
diff --git a/assets/devtron-lightmode-logo.png b/assets/devtron-lightmode-logo.png
deleted file mode 100644
index 29963ab6e7..0000000000
Binary files a/assets/devtron-lightmode-logo.png and /dev/null differ
diff --git a/assets/devtron-logo-dark-light.png b/assets/devtron-logo-dark-light.png
deleted file mode 100644
index 4365c3e22f..0000000000
Binary files a/assets/devtron-logo-dark-light.png and /dev/null differ
diff --git a/assets/devtron-logo.png b/assets/devtron-logo.png
deleted file mode 100644
index 8918c60dcb..0000000000
Binary files a/assets/devtron-logo.png and /dev/null differ
diff --git a/assets/docker-logo.png b/assets/docker-logo.png
deleted file mode 100644
index 36faa2ee07..0000000000
Binary files a/assets/docker-logo.png and /dev/null differ
diff --git a/assets/dockerslim-plugin-icon.png b/assets/dockerslim-plugin-icon.png
deleted file mode 100644
index 6653a8edb6..0000000000
Binary files a/assets/dockerslim-plugin-icon.png and /dev/null differ
diff --git a/assets/eks-plugin-icon.svg b/assets/eks-plugin-icon.svg
deleted file mode 100644
index 04c9f03a10..0000000000
--- a/assets/eks-plugin-icon.svg
+++ /dev/null
@@ -1,17 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/assets/gcs-bucket.svg b/assets/gcs-bucket.svg
deleted file mode 100644
index b0cfefa08f..0000000000
--- a/assets/gcs-bucket.svg
+++ /dev/null
@@ -1,17 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/assets/gke-plugin-icon.png b/assets/gke-plugin-icon.png
deleted file mode 100644
index 0e434e31a0..0000000000
Binary files a/assets/gke-plugin-icon.png and /dev/null differ
diff --git a/assets/ic-plugin-copy-container-image.png b/assets/ic-plugin-copy-container-image.png
deleted file mode 100644
index 1b5a3c47e5..0000000000
Binary files a/assets/ic-plugin-copy-container-image.png and /dev/null differ
diff --git a/assets/ic-plugin-vulnerability-scan.png b/assets/ic-plugin-vulnerability-scan.png
deleted file mode 100644
index c324a69fbf..0000000000
Binary files a/assets/ic-plugin-vulnerability-scan.png and /dev/null differ
diff --git a/assets/jenkins.png b/assets/jenkins.png
deleted file mode 100644
index 7f8921527c..0000000000
Binary files a/assets/jenkins.png and /dev/null differ
diff --git a/assets/k6-plugin-icon.png b/assets/k6-plugin-icon.png
deleted file mode 100644
index cd15d91bd1..0000000000
Binary files a/assets/k6-plugin-icon.png and /dev/null differ
diff --git a/assets/plugin-github-pr.png b/assets/plugin-github-pr.png
deleted file mode 100644
index 892a50796a..0000000000
Binary files a/assets/plugin-github-pr.png and /dev/null differ
diff --git a/assets/plugin-golang-migrate.png b/assets/plugin-golang-migrate.png
deleted file mode 100644
index 9a2852388d..0000000000
Binary files a/assets/plugin-golang-migrate.png and /dev/null differ
diff --git a/assets/plugin-jira.png b/assets/plugin-jira.png
deleted file mode 100644
index 9e9b1800c1..0000000000
Binary files a/assets/plugin-jira.png and /dev/null differ
diff --git a/assets/plugin-poll-container-registry.png b/assets/plugin-poll-container-registry.png
deleted file mode 100644
index 729ea4680f..0000000000
Binary files a/assets/plugin-poll-container-registry.png and /dev/null differ
diff --git a/assets/preview.gif b/assets/preview.gif
deleted file mode 100644
index ac26e8a222..0000000000
Binary files a/assets/preview.gif and /dev/null differ
diff --git a/assets/readme-comic.png b/assets/readme-comic.png
deleted file mode 100644
index 21d0fe683e..0000000000
Binary files a/assets/readme-comic.png and /dev/null differ
diff --git a/assets/semgrep.png b/assets/semgrep.png
deleted file mode 100644
index 0848fe5a8e..0000000000
Binary files a/assets/semgrep.png and /dev/null differ
diff --git a/assets/sonarqube-plugin-icon.png b/assets/sonarqube-plugin-icon.png
deleted file mode 100644
index 7c3e626609..0000000000
Binary files a/assets/sonarqube-plugin-icon.png and /dev/null differ
diff --git a/assets/terraform-cli.svg b/assets/terraform-cli.svg
deleted file mode 100644
index 42f77bf97b..0000000000
--- a/assets/terraform-cli.svg
+++ /dev/null
@@ -1,17 +0,0 @@
-
-
-
\ No newline at end of file
diff --git a/assets/trusted-by.jpg b/assets/trusted-by.jpg
deleted file mode 100644
index 59971e318e..0000000000
Binary files a/assets/trusted-by.jpg and /dev/null differ
diff --git a/assets/we-support.jpg b/assets/we-support.jpg
deleted file mode 100644
index d73c02dba2..0000000000
Binary files a/assets/we-support.jpg and /dev/null differ
diff --git a/blog/2019-05-28-first-blog-post.md b/blog/2019-05-28-first-blog-post.md
new file mode 100755
index 0000000000..d3032efb35
--- /dev/null
+++ b/blog/2019-05-28-first-blog-post.md
@@ -0,0 +1,12 @@
+---
+slug: first-blog-post
+title: First Blog Post
+authors: [slorber, yangshun]
+tags: [hola, docusaurus]
+---
+
+Lorem ipsum dolor sit amet...
+
+
+
+...consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
diff --git a/blog/2019-05-29-long-blog-post.md b/blog/2019-05-29-long-blog-post.md
new file mode 100755
index 0000000000..eb4435de59
--- /dev/null
+++ b/blog/2019-05-29-long-blog-post.md
@@ -0,0 +1,44 @@
+---
+slug: long-blog-post
+title: Long Blog Post
+authors: yangshun
+tags: [hello, docusaurus]
+---
+
+This is the summary of a very long blog post,
+
+Use a `` comment to limit blog post size in the list view.
+
+
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
+
+Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque elementum dignissim ultricies. Fusce rhoncus ipsum tempor eros aliquam consequat. Lorem ipsum dolor sit amet
diff --git a/blog/2021-08-01-mdx-blog-post.mdx b/blog/2021-08-01-mdx-blog-post.mdx
new file mode 100755
index 0000000000..0c4b4a48b9
--- /dev/null
+++ b/blog/2021-08-01-mdx-blog-post.mdx
@@ -0,0 +1,24 @@
+---
+slug: mdx-blog-post
+title: MDX Blog Post
+authors: [slorber]
+tags: [docusaurus]
+---
+
+Blog posts support [Docusaurus Markdown features](https://docusaurus.io/docs/markdown-features), such as [MDX](https://mdxjs.com/).
+
+:::tip
+
+Use the power of React to create interactive blog posts.
+
+:::
+
+{/* truncate */}
+
+For example, use JSX to create an interactive button:
+
+```js
+
+```
+
+
diff --git a/blog/2021-08-26-welcome/docusaurus-plushie-banner.jpeg b/blog/2021-08-26-welcome/docusaurus-plushie-banner.jpeg
new file mode 100755
index 0000000000..11bda09284
Binary files /dev/null and b/blog/2021-08-26-welcome/docusaurus-plushie-banner.jpeg differ
diff --git a/blog/2021-08-26-welcome/index.md b/blog/2021-08-26-welcome/index.md
new file mode 100755
index 0000000000..349ea075f5
--- /dev/null
+++ b/blog/2021-08-26-welcome/index.md
@@ -0,0 +1,29 @@
+---
+slug: welcome
+title: Welcome
+authors: [slorber, yangshun]
+tags: [facebook, hello, docusaurus]
+---
+
+[Docusaurus blogging features](https://docusaurus.io/docs/blog) are powered by the [blog plugin](https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-content-blog).
+
+Here are a few tips you might find useful.
+
+
+
+Simply add Markdown files (or folders) to the `blog` directory.
+
+Regular blog authors can be added to `authors.yml`.
+
+The blog post date can be extracted from filenames, such as:
+
+- `2019-05-30-welcome.md`
+- `2019-05-30-welcome/index.md`
+
+A blog post folder can be convenient to co-locate blog post images:
+
+
+
+The blog supports tags as well!
+
+**And if you don't want a blog**: just delete this directory, and use `blog: false` in your Docusaurus config.
diff --git a/blog/authors.yml b/blog/authors.yml
new file mode 100755
index 0000000000..0fd398733b
--- /dev/null
+++ b/blog/authors.yml
@@ -0,0 +1,25 @@
+yangshun:
+ name: Yangshun Tay
+ title: Ex-Meta Staff Engineer, Co-founder GreatFrontEnd
+ url: https://linkedin.com/in/yangshun
+ image_url: https://github.com/yangshun.png
+ page: true
+ socials:
+ x: yangshunz
+ linkedin: yangshun
+ github: yangshun
+ newsletter: https://www.greatfrontend.com
+
+slorber:
+ name: Sébastien Lorber
+ title: Docusaurus maintainer
+ url: https://sebastienlorber.com
+ image_url: https://github.com/slorber.png
+ page:
+ # customize the url of the author page at /blog/authors/
+ permalink: '/all-sebastien-lorber-articles'
+ socials:
+ x: sebastienlorber
+ linkedin: sebastienlorber
+ github: slorber
+ newsletter: https://thisweekinreact.com
diff --git a/blog/tags.yml b/blog/tags.yml
new file mode 100755
index 0000000000..bfaa778fbd
--- /dev/null
+++ b/blog/tags.yml
@@ -0,0 +1,19 @@
+facebook:
+ label: Facebook
+ permalink: /facebook
+ description: Facebook tag description
+
+hello:
+ label: Hello
+ permalink: /hello
+ description: Hello tag description
+
+docusaurus:
+ label: Docusaurus
+ permalink: /docusaurus
+ description: Docusaurus tag description
+
+hola:
+ label: Hola
+ permalink: /hola
+ description: Hola tag description
diff --git a/docs/.gitbook/assets/ad-confgimap (3) (1).jpg b/docs/.gitbook/assets/ad-confgimap (3) (1).jpg
deleted file mode 100644
index 752b7de887..0000000000
Binary files a/docs/.gitbook/assets/ad-confgimap (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ad-confgimap (3) (2).jpg b/docs/.gitbook/assets/ad-confgimap (3) (2).jpg
deleted file mode 100644
index 752b7de887..0000000000
Binary files a/docs/.gitbook/assets/ad-confgimap (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ad-confgimap (3) (3).jpg b/docs/.gitbook/assets/ad-confgimap (3) (3).jpg
deleted file mode 100644
index 752b7de887..0000000000
Binary files a/docs/.gitbook/assets/ad-confgimap (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ad-confgimap (3) (4).jpg b/docs/.gitbook/assets/ad-confgimap (3) (4).jpg
deleted file mode 100644
index 752b7de887..0000000000
Binary files a/docs/.gitbook/assets/ad-confgimap (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ad-confgimap (3).jpg b/docs/.gitbook/assets/ad-confgimap (3).jpg
deleted file mode 100644
index 752b7de887..0000000000
Binary files a/docs/.gitbook/assets/ad-confgimap (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/add-new-app (1).jpg b/docs/.gitbook/assets/add-new-app (1).jpg
deleted file mode 100644
index 130d81ee38..0000000000
Binary files a/docs/.gitbook/assets/add-new-app (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/add-new-app (2).jpg b/docs/.gitbook/assets/add-new-app (2).jpg
deleted file mode 100644
index 130d81ee38..0000000000
Binary files a/docs/.gitbook/assets/add-new-app (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/add-new-app (3).jpg b/docs/.gitbook/assets/add-new-app (3).jpg
deleted file mode 100644
index 130d81ee38..0000000000
Binary files a/docs/.gitbook/assets/add-new-app (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/add-new-app (4).jpg b/docs/.gitbook/assets/add-new-app (4).jpg
deleted file mode 100644
index 130d81ee38..0000000000
Binary files a/docs/.gitbook/assets/add-new-app (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/add-new-app.jpg b/docs/.gitbook/assets/add-new-app.jpg
deleted file mode 100644
index 130d81ee38..0000000000
Binary files a/docs/.gitbook/assets/add-new-app.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/add-secret (1).png b/docs/.gitbook/assets/add-secret (1).png
deleted file mode 100644
index de8ed05ec5..0000000000
Binary files a/docs/.gitbook/assets/add-secret (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-secret (2).png b/docs/.gitbook/assets/add-secret (2).png
deleted file mode 100644
index de8ed05ec5..0000000000
Binary files a/docs/.gitbook/assets/add-secret (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-secret (3).png b/docs/.gitbook/assets/add-secret (3).png
deleted file mode 100644
index de8ed05ec5..0000000000
Binary files a/docs/.gitbook/assets/add-secret (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-secret (4).png b/docs/.gitbook/assets/add-secret (4).png
deleted file mode 100644
index de8ed05ec5..0000000000
Binary files a/docs/.gitbook/assets/add-secret (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-secret (5).png b/docs/.gitbook/assets/add-secret (5).png
deleted file mode 100644
index de8ed05ec5..0000000000
Binary files a/docs/.gitbook/assets/add-secret (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-secret.png b/docs/.gitbook/assets/add-secret.png
deleted file mode 100644
index de8ed05ec5..0000000000
Binary files a/docs/.gitbook/assets/add-secret.png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-workflow (1).png b/docs/.gitbook/assets/add-workflow (1).png
deleted file mode 100644
index fcab99f7dd..0000000000
Binary files a/docs/.gitbook/assets/add-workflow (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-workflow (2).png b/docs/.gitbook/assets/add-workflow (2).png
deleted file mode 100644
index fcab99f7dd..0000000000
Binary files a/docs/.gitbook/assets/add-workflow (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-workflow (3).png b/docs/.gitbook/assets/add-workflow (3).png
deleted file mode 100644
index fcab99f7dd..0000000000
Binary files a/docs/.gitbook/assets/add-workflow (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-workflow (4).png b/docs/.gitbook/assets/add-workflow (4).png
deleted file mode 100644
index fcab99f7dd..0000000000
Binary files a/docs/.gitbook/assets/add-workflow (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-workflow (5).png b/docs/.gitbook/assets/add-workflow (5).png
deleted file mode 100644
index fcab99f7dd..0000000000
Binary files a/docs/.gitbook/assets/add-workflow (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-workflow (6).png b/docs/.gitbook/assets/add-workflow (6).png
deleted file mode 100644
index fcab99f7dd..0000000000
Binary files a/docs/.gitbook/assets/add-workflow (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/add-workflow.png b/docs/.gitbook/assets/add-workflow.png
deleted file mode 100644
index fcab99f7dd..0000000000
Binary files a/docs/.gitbook/assets/add-workflow.png and /dev/null differ
diff --git a/docs/.gitbook/assets/adding-git-material (1).gif b/docs/.gitbook/assets/adding-git-material (1).gif
deleted file mode 100644
index ac71ed7b8e..0000000000
Binary files a/docs/.gitbook/assets/adding-git-material (1).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/adding-git-material (2).gif b/docs/.gitbook/assets/adding-git-material (2).gif
deleted file mode 100644
index ac71ed7b8e..0000000000
Binary files a/docs/.gitbook/assets/adding-git-material (2).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/adding-git-material (3).gif b/docs/.gitbook/assets/adding-git-material (3).gif
deleted file mode 100644
index ac71ed7b8e..0000000000
Binary files a/docs/.gitbook/assets/adding-git-material (3).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/adding-git-material (4).gif b/docs/.gitbook/assets/adding-git-material (4).gif
deleted file mode 100644
index ac71ed7b8e..0000000000
Binary files a/docs/.gitbook/assets/adding-git-material (4).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/adding-git-material (5).gif b/docs/.gitbook/assets/adding-git-material (5).gif
deleted file mode 100644
index ac71ed7b8e..0000000000
Binary files a/docs/.gitbook/assets/adding-git-material (5).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/adding-git-material.gif b/docs/.gitbook/assets/adding-git-material.gif
deleted file mode 100644
index ac71ed7b8e..0000000000
Binary files a/docs/.gitbook/assets/adding-git-material.gif and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-application-object-ingress (1).png b/docs/.gitbook/assets/app-details-application-object-ingress (1).png
deleted file mode 100644
index def5ff8f6e..0000000000
Binary files a/docs/.gitbook/assets/app-details-application-object-ingress (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-application-object-ingress (2).png b/docs/.gitbook/assets/app-details-application-object-ingress (2).png
deleted file mode 100644
index def5ff8f6e..0000000000
Binary files a/docs/.gitbook/assets/app-details-application-object-ingress (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-application-object-ingress (3).png b/docs/.gitbook/assets/app-details-application-object-ingress (3).png
deleted file mode 100644
index def5ff8f6e..0000000000
Binary files a/docs/.gitbook/assets/app-details-application-object-ingress (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-application-object-ingress.png b/docs/.gitbook/assets/app-details-application-object-ingress.png
deleted file mode 100644
index def5ff8f6e..0000000000
Binary files a/docs/.gitbook/assets/app-details-application-object-ingress.png and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-logs (1).jpg b/docs/.gitbook/assets/app-details-logs (1).jpg
deleted file mode 100644
index 82816b1f4a..0000000000
Binary files a/docs/.gitbook/assets/app-details-logs (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-logs (2).jpg b/docs/.gitbook/assets/app-details-logs (2).jpg
deleted file mode 100644
index 82816b1f4a..0000000000
Binary files a/docs/.gitbook/assets/app-details-logs (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-logs (3).jpg b/docs/.gitbook/assets/app-details-logs (3).jpg
deleted file mode 100644
index 82816b1f4a..0000000000
Binary files a/docs/.gitbook/assets/app-details-logs (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-logs (4).jpg b/docs/.gitbook/assets/app-details-logs (4).jpg
deleted file mode 100644
index 82816b1f4a..0000000000
Binary files a/docs/.gitbook/assets/app-details-logs (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-logs (5).jpg b/docs/.gitbook/assets/app-details-logs (5).jpg
deleted file mode 100644
index 82816b1f4a..0000000000
Binary files a/docs/.gitbook/assets/app-details-logs (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-logs.jpg b/docs/.gitbook/assets/app-details-logs.jpg
deleted file mode 100644
index 82816b1f4a..0000000000
Binary files a/docs/.gitbook/assets/app-details-logs.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-manifest (1).jpg b/docs/.gitbook/assets/app-details-manifest (1).jpg
deleted file mode 100644
index 3a7d5152d1..0000000000
Binary files a/docs/.gitbook/assets/app-details-manifest (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-manifest (2).jpg b/docs/.gitbook/assets/app-details-manifest (2).jpg
deleted file mode 100644
index 3a7d5152d1..0000000000
Binary files a/docs/.gitbook/assets/app-details-manifest (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-manifest (3).jpg b/docs/.gitbook/assets/app-details-manifest (3).jpg
deleted file mode 100644
index 3a7d5152d1..0000000000
Binary files a/docs/.gitbook/assets/app-details-manifest (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-manifest (4).jpg b/docs/.gitbook/assets/app-details-manifest (4).jpg
deleted file mode 100644
index 3a7d5152d1..0000000000
Binary files a/docs/.gitbook/assets/app-details-manifest (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/app-details-manifest.jpg b/docs/.gitbook/assets/app-details-manifest.jpg
deleted file mode 100644
index 3a7d5152d1..0000000000
Binary files a/docs/.gitbook/assets/app-details-manifest.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/app-labels-1.png b/docs/.gitbook/assets/app-labels-1.png
deleted file mode 100644
index f1dbadd47e..0000000000
Binary files a/docs/.gitbook/assets/app-labels-1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/app-labels-2.png b/docs/.gitbook/assets/app-labels-2.png
deleted file mode 100644
index e0ec7a6784..0000000000
Binary files a/docs/.gitbook/assets/app-labels-2.png and /dev/null differ
diff --git a/docs/.gitbook/assets/arora1 (2).gif b/docs/.gitbook/assets/arora1 (2).gif
deleted file mode 100644
index 80428dbe95..0000000000
Binary files a/docs/.gitbook/assets/arora1 (2).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/arora4 (2).gif b/docs/.gitbook/assets/arora4 (2).gif
deleted file mode 100644
index 5a20f4dce1..0000000000
Binary files a/docs/.gitbook/assets/arora4 (2).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-1.png b/docs/.gitbook/assets/bulk-update-1.png
deleted file mode 100644
index e0bd6b0e9f..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-2.png b/docs/.gitbook/assets/bulk-update-2.png
deleted file mode 100644
index 65a0060af6..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-2.png and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-3.png b/docs/.gitbook/assets/bulk-update-3.png
deleted file mode 100644
index faaab7cb50..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-3.png and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-editor.png b/docs/.gitbook/assets/bulk-update-editor.png
deleted file mode 100644
index d084ccc296..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-editor.png and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-empty.png b/docs/.gitbook/assets/bulk-update-empty.png
deleted file mode 100644
index 8fe3c05a81..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-empty.png and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-impacted.png b/docs/.gitbook/assets/bulk-update-impacted.png
deleted file mode 100644
index 339bb407be..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-impacted.png and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-impactobj.png b/docs/.gitbook/assets/bulk-update-impactobj.png
deleted file mode 100644
index 74d2e9cb0d..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-impactobj.png and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-message.png b/docs/.gitbook/assets/bulk-update-message.png
deleted file mode 100644
index 2c21be6115..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-message.png and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-readme.png b/docs/.gitbook/assets/bulk-update-readme.png
deleted file mode 100644
index 3b04c3f3a9..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-readme.png and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-run.png b/docs/.gitbook/assets/bulk-update-run.png
deleted file mode 100644
index d815fec7c8..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-run.png and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-sample.png b/docs/.gitbook/assets/bulk-update-sample.png
deleted file mode 100644
index be5f7b05d9..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-sample.png and /dev/null differ
diff --git a/docs/.gitbook/assets/bulk-update-script.png b/docs/.gitbook/assets/bulk-update-script.png
deleted file mode 100644
index 265723daeb..0000000000
Binary files a/docs/.gitbook/assets/bulk-update-script.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ca-workflow-basic.png b/docs/.gitbook/assets/ca-workflow-basic.png
deleted file mode 100644
index dba7415b84..0000000000
Binary files a/docs/.gitbook/assets/ca-workflow-basic.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ca-workflow-cd-add.png b/docs/.gitbook/assets/ca-workflow-cd-add.png
deleted file mode 100644
index 8fbb834525..0000000000
Binary files a/docs/.gitbook/assets/ca-workflow-cd-add.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ca-workflow-cd-advanced.png b/docs/.gitbook/assets/ca-workflow-cd-advanced.png
deleted file mode 100644
index f47dbb1d8b..0000000000
Binary files a/docs/.gitbook/assets/ca-workflow-cd-advanced.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ca-workflow-ci-advance.png b/docs/.gitbook/assets/ca-workflow-ci-advance.png
deleted file mode 100644
index 3ab51735ee..0000000000
Binary files a/docs/.gitbook/assets/ca-workflow-ci-advance.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ca-workflow-ci-basic.png b/docs/.gitbook/assets/ca-workflow-ci-basic.png
deleted file mode 100644
index c99c76f894..0000000000
Binary files a/docs/.gitbook/assets/ca-workflow-ci-basic.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ca-workflow-empty.png b/docs/.gitbook/assets/ca-workflow-empty.png
deleted file mode 100644
index b9036301d0..0000000000
Binary files a/docs/.gitbook/assets/ca-workflow-empty.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ca-workflow-external.png b/docs/.gitbook/assets/ca-workflow-external.png
deleted file mode 100644
index bed4e5d68f..0000000000
Binary files a/docs/.gitbook/assets/ca-workflow-external.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ca-workflow-linked.png b/docs/.gitbook/assets/ca-workflow-linked.png
deleted file mode 100644
index 82a92d27eb..0000000000
Binary files a/docs/.gitbook/assets/ca-workflow-linked.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ca-workflow-update.gif b/docs/.gitbook/assets/ca-workflow-update.gif
deleted file mode 100644
index bf8fb14244..0000000000
Binary files a/docs/.gitbook/assets/ca-workflow-update.gif and /dev/null differ
diff --git a/docs/.gitbook/assets/ca-workflow-update.png b/docs/.gitbook/assets/ca-workflow-update.png
deleted file mode 100644
index c713f52e72..0000000000
Binary files a/docs/.gitbook/assets/ca-workflow-update.png and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-deploy-console (1).jpg b/docs/.gitbook/assets/cd-deploy-console (1).jpg
deleted file mode 100644
index 2548604f02..0000000000
Binary files a/docs/.gitbook/assets/cd-deploy-console (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-deploy-console (2).jpg b/docs/.gitbook/assets/cd-deploy-console (2).jpg
deleted file mode 100644
index 2548604f02..0000000000
Binary files a/docs/.gitbook/assets/cd-deploy-console (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-deploy-console (3).jpg b/docs/.gitbook/assets/cd-deploy-console (3).jpg
deleted file mode 100644
index 2548604f02..0000000000
Binary files a/docs/.gitbook/assets/cd-deploy-console (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-deploy-console (4).jpg b/docs/.gitbook/assets/cd-deploy-console (4).jpg
deleted file mode 100644
index 2548604f02..0000000000
Binary files a/docs/.gitbook/assets/cd-deploy-console (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-deploy-console.jpg b/docs/.gitbook/assets/cd-deploy-console.jpg
deleted file mode 100644
index 2548604f02..0000000000
Binary files a/docs/.gitbook/assets/cd-deploy-console.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-pipeline-console (3) (1).png b/docs/.gitbook/assets/cd-pipeline-console (3) (1).png
deleted file mode 100644
index 11b0cfac66..0000000000
Binary files a/docs/.gitbook/assets/cd-pipeline-console (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-pipeline-console (3) (2).png b/docs/.gitbook/assets/cd-pipeline-console (3) (2).png
deleted file mode 100644
index 11b0cfac66..0000000000
Binary files a/docs/.gitbook/assets/cd-pipeline-console (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-pipeline-console (3) (3).png b/docs/.gitbook/assets/cd-pipeline-console (3) (3).png
deleted file mode 100644
index 11b0cfac66..0000000000
Binary files a/docs/.gitbook/assets/cd-pipeline-console (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-pipeline-console (3) (4).png b/docs/.gitbook/assets/cd-pipeline-console (3) (4).png
deleted file mode 100644
index 11b0cfac66..0000000000
Binary files a/docs/.gitbook/assets/cd-pipeline-console (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-pipeline-console (3) (5).png b/docs/.gitbook/assets/cd-pipeline-console (3) (5).png
deleted file mode 100644
index 11b0cfac66..0000000000
Binary files a/docs/.gitbook/assets/cd-pipeline-console (3) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-pipeline-console (3) (6).png b/docs/.gitbook/assets/cd-pipeline-console (3) (6).png
deleted file mode 100644
index 11b0cfac66..0000000000
Binary files a/docs/.gitbook/assets/cd-pipeline-console (3) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-pipeline-console (3).png b/docs/.gitbook/assets/cd-pipeline-console (3).png
deleted file mode 100644
index 11b0cfac66..0000000000
Binary files a/docs/.gitbook/assets/cd-pipeline-console (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cd-pipeline-console.png b/docs/.gitbook/assets/cd-pipeline-console.png
deleted file mode 100644
index 11b0cfac66..0000000000
Binary files a/docs/.gitbook/assets/cd-pipeline-console.png and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_post_build (3) (1).jpg b/docs/.gitbook/assets/cd_post_build (3) (1).jpg
deleted file mode 100644
index 7380924d8f..0000000000
Binary files a/docs/.gitbook/assets/cd_post_build (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_post_build (3) (2).jpg b/docs/.gitbook/assets/cd_post_build (3) (2).jpg
deleted file mode 100644
index 7380924d8f..0000000000
Binary files a/docs/.gitbook/assets/cd_post_build (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_post_build (3) (3).jpg b/docs/.gitbook/assets/cd_post_build (3) (3).jpg
deleted file mode 100644
index 7380924d8f..0000000000
Binary files a/docs/.gitbook/assets/cd_post_build (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_post_build (3) (4).jpg b/docs/.gitbook/assets/cd_post_build (3) (4).jpg
deleted file mode 100644
index 7380924d8f..0000000000
Binary files a/docs/.gitbook/assets/cd_post_build (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_post_build (3) (5).jpg b/docs/.gitbook/assets/cd_post_build (3) (5).jpg
deleted file mode 100644
index 7380924d8f..0000000000
Binary files a/docs/.gitbook/assets/cd_post_build (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_post_build (3) (6).jpg b/docs/.gitbook/assets/cd_post_build (3) (6).jpg
deleted file mode 100644
index 7380924d8f..0000000000
Binary files a/docs/.gitbook/assets/cd_post_build (3) (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_post_build (3).jpg b/docs/.gitbook/assets/cd_post_build (3).jpg
deleted file mode 100644
index 7380924d8f..0000000000
Binary files a/docs/.gitbook/assets/cd_post_build (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_post_build.jpg b/docs/.gitbook/assets/cd_post_build.jpg
deleted file mode 100644
index 7380924d8f..0000000000
Binary files a/docs/.gitbook/assets/cd_post_build.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_pre_build (2) (2) (1).jpg b/docs/.gitbook/assets/cd_pre_build (2) (2) (1).jpg
deleted file mode 100644
index f3972fde8f..0000000000
Binary files a/docs/.gitbook/assets/cd_pre_build (2) (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_pre_build (2) (2) (2).jpg b/docs/.gitbook/assets/cd_pre_build (2) (2) (2).jpg
deleted file mode 100644
index f3972fde8f..0000000000
Binary files a/docs/.gitbook/assets/cd_pre_build (2) (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_pre_build (2) (2) (3).jpg b/docs/.gitbook/assets/cd_pre_build (2) (2) (3).jpg
deleted file mode 100644
index f3972fde8f..0000000000
Binary files a/docs/.gitbook/assets/cd_pre_build (2) (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_pre_build (2) (2) (4).jpg b/docs/.gitbook/assets/cd_pre_build (2) (2) (4).jpg
deleted file mode 100644
index f3972fde8f..0000000000
Binary files a/docs/.gitbook/assets/cd_pre_build (2) (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_pre_build (2) (2).jpg b/docs/.gitbook/assets/cd_pre_build (2) (2).jpg
deleted file mode 100644
index f3972fde8f..0000000000
Binary files a/docs/.gitbook/assets/cd_pre_build (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cd_pre_build (2).jpg b/docs/.gitbook/assets/cd_pre_build (2).jpg
deleted file mode 100644
index f3972fde8f..0000000000
Binary files a/docs/.gitbook/assets/cd_pre_build (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cdedit2.jpg b/docs/.gitbook/assets/cdedit2.jpg
deleted file mode 100644
index 1272fe6da6..0000000000
Binary files a/docs/.gitbook/assets/cdedit2.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart-group-1.png b/docs/.gitbook/assets/chart-group-1.png
deleted file mode 100644
index 8c24445224..0000000000
Binary files a/docs/.gitbook/assets/chart-group-1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/chart-group-2.png b/docs/.gitbook/assets/chart-group-2.png
deleted file mode 100644
index 53a2fea60f..0000000000
Binary files a/docs/.gitbook/assets/chart-group-2.png and /dev/null differ
diff --git a/docs/.gitbook/assets/chart-group-3.png b/docs/.gitbook/assets/chart-group-3.png
deleted file mode 100644
index 698d17c6fd..0000000000
Binary files a/docs/.gitbook/assets/chart-group-3.png and /dev/null differ
diff --git a/docs/.gitbook/assets/chart-group-4.png b/docs/.gitbook/assets/chart-group-4.png
deleted file mode 100644
index 81d85c0d5c..0000000000
Binary files a/docs/.gitbook/assets/chart-group-4.png and /dev/null differ
diff --git a/docs/.gitbook/assets/chart-group-5.png b/docs/.gitbook/assets/chart-group-5.png
deleted file mode 100644
index cb92f66c86..0000000000
Binary files a/docs/.gitbook/assets/chart-group-5.png and /dev/null differ
diff --git a/docs/.gitbook/assets/chart-group-6.png b/docs/.gitbook/assets/chart-group-6.png
deleted file mode 100644
index 16fb123821..0000000000
Binary files a/docs/.gitbook/assets/chart-group-6.png and /dev/null differ
diff --git a/docs/.gitbook/assets/chart21 (1).jpg b/docs/.gitbook/assets/chart21 (1).jpg
deleted file mode 100644
index 31194cb889..0000000000
Binary files a/docs/.gitbook/assets/chart21 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart21 (2).jpg b/docs/.gitbook/assets/chart21 (2).jpg
deleted file mode 100644
index 31194cb889..0000000000
Binary files a/docs/.gitbook/assets/chart21 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart21 (3).jpg b/docs/.gitbook/assets/chart21 (3).jpg
deleted file mode 100644
index 31194cb889..0000000000
Binary files a/docs/.gitbook/assets/chart21 (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart21 (4).jpg b/docs/.gitbook/assets/chart21 (4).jpg
deleted file mode 100644
index 31194cb889..0000000000
Binary files a/docs/.gitbook/assets/chart21 (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart21 (5).jpg b/docs/.gitbook/assets/chart21 (5).jpg
deleted file mode 100644
index 31194cb889..0000000000
Binary files a/docs/.gitbook/assets/chart21 (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart21 (6).jpg b/docs/.gitbook/assets/chart21 (6).jpg
deleted file mode 100644
index 31194cb889..0000000000
Binary files a/docs/.gitbook/assets/chart21 (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart21.jpg b/docs/.gitbook/assets/chart21.jpg
deleted file mode 100644
index 31194cb889..0000000000
Binary files a/docs/.gitbook/assets/chart21.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart3 (1).jpg b/docs/.gitbook/assets/chart3 (1).jpg
deleted file mode 100644
index 4fb54082f5..0000000000
Binary files a/docs/.gitbook/assets/chart3 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart3 (2) (1).jpg b/docs/.gitbook/assets/chart3 (2) (1).jpg
deleted file mode 100644
index 4fb54082f5..0000000000
Binary files a/docs/.gitbook/assets/chart3 (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart3 (2) (2).jpg b/docs/.gitbook/assets/chart3 (2) (2).jpg
deleted file mode 100644
index 4fb54082f5..0000000000
Binary files a/docs/.gitbook/assets/chart3 (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart3 (2) (3).jpg b/docs/.gitbook/assets/chart3 (2) (3).jpg
deleted file mode 100644
index 4fb54082f5..0000000000
Binary files a/docs/.gitbook/assets/chart3 (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart3 (2) (4).jpg b/docs/.gitbook/assets/chart3 (2) (4).jpg
deleted file mode 100644
index 4fb54082f5..0000000000
Binary files a/docs/.gitbook/assets/chart3 (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart3 (2) (5).jpg b/docs/.gitbook/assets/chart3 (2) (5).jpg
deleted file mode 100644
index 4fb54082f5..0000000000
Binary files a/docs/.gitbook/assets/chart3 (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart3 (2).jpg b/docs/.gitbook/assets/chart3 (2).jpg
deleted file mode 100644
index 4fb54082f5..0000000000
Binary files a/docs/.gitbook/assets/chart3 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart4o (2) (1).jpg b/docs/.gitbook/assets/chart4o (2) (1).jpg
deleted file mode 100644
index b8e7c616fb..0000000000
Binary files a/docs/.gitbook/assets/chart4o (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart4o (2) (2).jpg b/docs/.gitbook/assets/chart4o (2) (2).jpg
deleted file mode 100644
index b8e7c616fb..0000000000
Binary files a/docs/.gitbook/assets/chart4o (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart4o (2) (3).jpg b/docs/.gitbook/assets/chart4o (2) (3).jpg
deleted file mode 100644
index b8e7c616fb..0000000000
Binary files a/docs/.gitbook/assets/chart4o (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart4o (2) (4).jpg b/docs/.gitbook/assets/chart4o (2) (4).jpg
deleted file mode 100644
index b8e7c616fb..0000000000
Binary files a/docs/.gitbook/assets/chart4o (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart4o (2) (5).jpg b/docs/.gitbook/assets/chart4o (2) (5).jpg
deleted file mode 100644
index b8e7c616fb..0000000000
Binary files a/docs/.gitbook/assets/chart4o (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart4o (2).jpg b/docs/.gitbook/assets/chart4o (2).jpg
deleted file mode 100644
index b8e7c616fb..0000000000
Binary files a/docs/.gitbook/assets/chart4o (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/chart4o.jpg b/docs/.gitbook/assets/chart4o.jpg
deleted file mode 100644
index b8e7c616fb..0000000000
Binary files a/docs/.gitbook/assets/chart4o.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/charts-1.png b/docs/.gitbook/assets/charts-1.png
deleted file mode 100644
index f46571d917..0000000000
Binary files a/docs/.gitbook/assets/charts-1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/charts-2.png b/docs/.gitbook/assets/charts-2.png
deleted file mode 100644
index 3d119fdb23..0000000000
Binary files a/docs/.gitbook/assets/charts-2.png and /dev/null differ
diff --git a/docs/.gitbook/assets/charts-3.png b/docs/.gitbook/assets/charts-3.png
deleted file mode 100644
index c385512b1a..0000000000
Binary files a/docs/.gitbook/assets/charts-3.png and /dev/null differ
diff --git a/docs/.gitbook/assets/charts-4.png b/docs/.gitbook/assets/charts-4.png
deleted file mode 100644
index fd1f5a7a59..0000000000
Binary files a/docs/.gitbook/assets/charts-4.png and /dev/null differ
diff --git a/docs/.gitbook/assets/charts-5.png b/docs/.gitbook/assets/charts-5.png
deleted file mode 100644
index 3b02772948..0000000000
Binary files a/docs/.gitbook/assets/charts-5.png and /dev/null differ
diff --git a/docs/.gitbook/assets/charts-6.png b/docs/.gitbook/assets/charts-6.png
deleted file mode 100644
index 8a4c3e4803..0000000000
Binary files a/docs/.gitbook/assets/charts-6.png and /dev/null differ
diff --git a/docs/.gitbook/assets/charts-7.png b/docs/.gitbook/assets/charts-7.png
deleted file mode 100644
index ca23b3fb38..0000000000
Binary files a/docs/.gitbook/assets/charts-7.png and /dev/null differ
diff --git a/docs/.gitbook/assets/charts-8.png b/docs/.gitbook/assets/charts-8.png
deleted file mode 100644
index 8dcbc6e8b7..0000000000
Binary files a/docs/.gitbook/assets/charts-8.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy (1).jpg b/docs/.gitbook/assets/ci-build-histroy (1).jpg
deleted file mode 100644
index c32a6648da..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy (2).jpg b/docs/.gitbook/assets/ci-build-histroy (2).jpg
deleted file mode 100644
index c32a6648da..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy (3).jpg b/docs/.gitbook/assets/ci-build-histroy (3).jpg
deleted file mode 100644
index c32a6648da..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy (4).jpg b/docs/.gitbook/assets/ci-build-histroy (4).jpg
deleted file mode 100644
index c32a6648da..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy (5).jpg b/docs/.gitbook/assets/ci-build-histroy (5).jpg
deleted file mode 100644
index c32a6648da..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy-artifact (1).jpg b/docs/.gitbook/assets/ci-build-histroy-artifact (1).jpg
deleted file mode 100644
index 0fd1507763..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy-artifact (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy-artifact (2).jpg b/docs/.gitbook/assets/ci-build-histroy-artifact (2).jpg
deleted file mode 100644
index 0fd1507763..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy-artifact (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy-artifact (3).jpg b/docs/.gitbook/assets/ci-build-histroy-artifact (3).jpg
deleted file mode 100644
index 0fd1507763..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy-artifact (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy-artifact (4).jpg b/docs/.gitbook/assets/ci-build-histroy-artifact (4).jpg
deleted file mode 100644
index 0fd1507763..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy-artifact (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy-artifact (5).jpg b/docs/.gitbook/assets/ci-build-histroy-artifact (5).jpg
deleted file mode 100644
index 0fd1507763..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy-artifact (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy-artifact.jpg b/docs/.gitbook/assets/ci-build-histroy-artifact.jpg
deleted file mode 100644
index 0fd1507763..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy-artifact.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy-source-code (1).jpg b/docs/.gitbook/assets/ci-build-histroy-source-code (1).jpg
deleted file mode 100644
index 8e41509859..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy-source-code (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy-source-code (2).jpg b/docs/.gitbook/assets/ci-build-histroy-source-code (2).jpg
deleted file mode 100644
index 8e41509859..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy-source-code (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy-source-code (3).jpg b/docs/.gitbook/assets/ci-build-histroy-source-code (3).jpg
deleted file mode 100644
index 8e41509859..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy-source-code (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy-source-code.jpg b/docs/.gitbook/assets/ci-build-histroy-source-code.jpg
deleted file mode 100644
index 8e41509859..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy-source-code.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-build-histroy.jpg b/docs/.gitbook/assets/ci-build-histroy.jpg
deleted file mode 100644
index c32a6648da..0000000000
Binary files a/docs/.gitbook/assets/ci-build-histroy.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-pipeline-1.png b/docs/.gitbook/assets/ci-pipeline-1.png
deleted file mode 100644
index e4a8c93e62..0000000000
Binary files a/docs/.gitbook/assets/ci-pipeline-1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-pipeline-2.png b/docs/.gitbook/assets/ci-pipeline-2.png
deleted file mode 100644
index 15bf01ddcc..0000000000
Binary files a/docs/.gitbook/assets/ci-pipeline-2.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-pipeline-3.png b/docs/.gitbook/assets/ci-pipeline-3.png
deleted file mode 100644
index 91e8e892bd..0000000000
Binary files a/docs/.gitbook/assets/ci-pipeline-3.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-pipeline-4.png b/docs/.gitbook/assets/ci-pipeline-4.png
deleted file mode 100644
index 00025c5eeb..0000000000
Binary files a/docs/.gitbook/assets/ci-pipeline-4.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-pipeline-5.png b/docs/.gitbook/assets/ci-pipeline-5.png
deleted file mode 100644
index 85ae7d9c51..0000000000
Binary files a/docs/.gitbook/assets/ci-pipeline-5.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-pipeline-6.png b/docs/.gitbook/assets/ci-pipeline-6.png
deleted file mode 100644
index 8f6164c6da..0000000000
Binary files a/docs/.gitbook/assets/ci-pipeline-6.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-pipeline-7.png b/docs/.gitbook/assets/ci-pipeline-7.png
deleted file mode 100644
index 693743682f..0000000000
Binary files a/docs/.gitbook/assets/ci-pipeline-7.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-pipeline-8.png b/docs/.gitbook/assets/ci-pipeline-8.png
deleted file mode 100644
index 13831f44ea..0000000000
Binary files a/docs/.gitbook/assets/ci-pipeline-8.png and /dev/null differ
diff --git a/docs/.gitbook/assets/ci-pipeline-9.png b/docs/.gitbook/assets/ci-pipeline-9.png
deleted file mode 100644
index fd3afbdce9..0000000000
Binary files a/docs/.gitbook/assets/ci-pipeline-9.png and /dev/null differ
diff --git a/docs/.gitbook/assets/clone_app1 (2) (1).jpg b/docs/.gitbook/assets/clone_app1 (2) (1).jpg
deleted file mode 100644
index a2fa304d95..0000000000
Binary files a/docs/.gitbook/assets/clone_app1 (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/clone_app1 (2) (2).jpg b/docs/.gitbook/assets/clone_app1 (2) (2).jpg
deleted file mode 100644
index a2fa304d95..0000000000
Binary files a/docs/.gitbook/assets/clone_app1 (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/clone_app1 (2) (3).jpg b/docs/.gitbook/assets/clone_app1 (2) (3).jpg
deleted file mode 100644
index a2fa304d95..0000000000
Binary files a/docs/.gitbook/assets/clone_app1 (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/clone_app1 (2) (4).jpg b/docs/.gitbook/assets/clone_app1 (2) (4).jpg
deleted file mode 100644
index a2fa304d95..0000000000
Binary files a/docs/.gitbook/assets/clone_app1 (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/clone_app1 (2) (5).jpg b/docs/.gitbook/assets/clone_app1 (2) (5).jpg
deleted file mode 100644
index a2fa304d95..0000000000
Binary files a/docs/.gitbook/assets/clone_app1 (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/clone_app1 (2).jpg b/docs/.gitbook/assets/clone_app1 (2).jpg
deleted file mode 100644
index a2fa304d95..0000000000
Binary files a/docs/.gitbook/assets/clone_app1 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/clone_app1.jpg b/docs/.gitbook/assets/clone_app1.jpg
deleted file mode 100644
index a2fa304d95..0000000000
Binary files a/docs/.gitbook/assets/clone_app1.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc1 (3) (1).png b/docs/.gitbook/assets/cluster_gc1 (3) (1).png
deleted file mode 100644
index b3e2392848..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc1 (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc1 (3) (2).png b/docs/.gitbook/assets/cluster_gc1 (3) (2).png
deleted file mode 100644
index b3e2392848..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc1 (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc1 (3) (3).png b/docs/.gitbook/assets/cluster_gc1 (3) (3).png
deleted file mode 100644
index b3e2392848..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc1 (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc1 (3) (4).png b/docs/.gitbook/assets/cluster_gc1 (3) (4).png
deleted file mode 100644
index b3e2392848..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc1 (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc1 (3) (5).png b/docs/.gitbook/assets/cluster_gc1 (3) (5).png
deleted file mode 100644
index b3e2392848..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc1 (3) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc1 (3) (6).png b/docs/.gitbook/assets/cluster_gc1 (3) (6).png
deleted file mode 100644
index b3e2392848..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc1 (3) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc1 (3).png b/docs/.gitbook/assets/cluster_gc1 (3).png
deleted file mode 100644
index b3e2392848..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc1 (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc1.png b/docs/.gitbook/assets/cluster_gc1.png
deleted file mode 100644
index b3e2392848..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc2 (3) (1).png b/docs/.gitbook/assets/cluster_gc2 (3) (1).png
deleted file mode 100644
index d60071cfd5..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc2 (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc2 (3) (2).png b/docs/.gitbook/assets/cluster_gc2 (3) (2).png
deleted file mode 100644
index d60071cfd5..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc2 (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc2 (3) (3).png b/docs/.gitbook/assets/cluster_gc2 (3) (3).png
deleted file mode 100644
index d60071cfd5..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc2 (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc2 (3) (4).png b/docs/.gitbook/assets/cluster_gc2 (3) (4).png
deleted file mode 100644
index d60071cfd5..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc2 (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc2 (3).png b/docs/.gitbook/assets/cluster_gc2 (3).png
deleted file mode 100644
index d60071cfd5..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc2 (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc3 (3) (1).png b/docs/.gitbook/assets/cluster_gc3 (3) (1).png
deleted file mode 100644
index 7e95887c89..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc3 (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc3 (3) (2).png b/docs/.gitbook/assets/cluster_gc3 (3) (2).png
deleted file mode 100644
index 7e95887c89..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc3 (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc3 (3) (3).png b/docs/.gitbook/assets/cluster_gc3 (3) (3).png
deleted file mode 100644
index 7e95887c89..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc3 (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc3 (3) (4).png b/docs/.gitbook/assets/cluster_gc3 (3) (4).png
deleted file mode 100644
index 7e95887c89..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc3 (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc3 (3).png b/docs/.gitbook/assets/cluster_gc3 (3).png
deleted file mode 100644
index 7e95887c89..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc3 (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/cluster_gc5.png b/docs/.gitbook/assets/cluster_gc5.png
deleted file mode 100644
index 840e0c2b6a..0000000000
Binary files a/docs/.gitbook/assets/cluster_gc5.png and /dev/null differ
diff --git a/docs/.gitbook/assets/config1 (2).jpg b/docs/.gitbook/assets/config1 (2).jpg
deleted file mode 100644
index bf227d0ed2..0000000000
Binary files a/docs/.gitbook/assets/config1 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config1 (3) (1).jpg b/docs/.gitbook/assets/config1 (3) (1).jpg
deleted file mode 100644
index bf227d0ed2..0000000000
Binary files a/docs/.gitbook/assets/config1 (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config1 (3) (2).jpg b/docs/.gitbook/assets/config1 (3) (2).jpg
deleted file mode 100644
index bf227d0ed2..0000000000
Binary files a/docs/.gitbook/assets/config1 (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config1 (3) (3).jpg b/docs/.gitbook/assets/config1 (3) (3).jpg
deleted file mode 100644
index bf227d0ed2..0000000000
Binary files a/docs/.gitbook/assets/config1 (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config1 (3) (4).jpg b/docs/.gitbook/assets/config1 (3) (4).jpg
deleted file mode 100644
index bf227d0ed2..0000000000
Binary files a/docs/.gitbook/assets/config1 (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config1 (3) (5).jpg b/docs/.gitbook/assets/config1 (3) (5).jpg
deleted file mode 100644
index bf227d0ed2..0000000000
Binary files a/docs/.gitbook/assets/config1 (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config1 (3) (6).jpg b/docs/.gitbook/assets/config1 (3) (6).jpg
deleted file mode 100644
index bf227d0ed2..0000000000
Binary files a/docs/.gitbook/assets/config1 (3) (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config1 (3).jpg b/docs/.gitbook/assets/config1 (3).jpg
deleted file mode 100644
index bf227d0ed2..0000000000
Binary files a/docs/.gitbook/assets/config1 (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config4 (3) (1).jpg b/docs/.gitbook/assets/config4 (3) (1).jpg
deleted file mode 100644
index 8f289a86b8..0000000000
Binary files a/docs/.gitbook/assets/config4 (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config4 (3) (2).jpg b/docs/.gitbook/assets/config4 (3) (2).jpg
deleted file mode 100644
index 8f289a86b8..0000000000
Binary files a/docs/.gitbook/assets/config4 (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config4 (3) (3).jpg b/docs/.gitbook/assets/config4 (3) (3).jpg
deleted file mode 100644
index 8f289a86b8..0000000000
Binary files a/docs/.gitbook/assets/config4 (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config4 (3) (4).jpg b/docs/.gitbook/assets/config4 (3) (4).jpg
deleted file mode 100644
index 8f289a86b8..0000000000
Binary files a/docs/.gitbook/assets/config4 (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/config4 (3).jpg b/docs/.gitbook/assets/config4 (3).jpg
deleted file mode 100644
index 8f289a86b8..0000000000
Binary files a/docs/.gitbook/assets/config4 (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-filepermission-1.png b/docs/.gitbook/assets/configmap-filepermission-1.png
deleted file mode 100644
index b41f25ffe1..0000000000
Binary files a/docs/.gitbook/assets/configmap-filepermission-1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-mountpath-1.png b/docs/.gitbook/assets/configmap-mountpath-1.png
deleted file mode 100644
index f31a34906d..0000000000
Binary files a/docs/.gitbook/assets/configmap-mountpath-1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (2).jpg b/docs/.gitbook/assets/configmap-yaml (3) (2).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (5) (1).jpg b/docs/.gitbook/assets/configmap-yaml (3) (5) (1).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (5) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (5) (10).jpg b/docs/.gitbook/assets/configmap-yaml (3) (5) (10).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (5) (10).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (5) (2).jpg b/docs/.gitbook/assets/configmap-yaml (3) (5) (2).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (5) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (5) (3).jpg b/docs/.gitbook/assets/configmap-yaml (3) (5) (3).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (5) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (5) (4).jpg b/docs/.gitbook/assets/configmap-yaml (3) (5) (4).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (5) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (5) (5).jpg b/docs/.gitbook/assets/configmap-yaml (3) (5) (5).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (5) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (5) (6).jpg b/docs/.gitbook/assets/configmap-yaml (3) (5) (6).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (5) (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (5) (7).jpg b/docs/.gitbook/assets/configmap-yaml (3) (5) (7).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (5) (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (5) (8).jpg b/docs/.gitbook/assets/configmap-yaml (3) (5) (8).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (5) (8).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (5) (9).jpg b/docs/.gitbook/assets/configmap-yaml (3) (5) (9).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (5) (9).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3) (5).jpg b/docs/.gitbook/assets/configmap-yaml (3) (5).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configmap-yaml (3).jpg b/docs/.gitbook/assets/configmap-yaml (3).jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/.gitbook/assets/configmap-yaml (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configure-env (1).jpg b/docs/.gitbook/assets/configure-env (1).jpg
deleted file mode 100644
index e7c439402d..0000000000
Binary files a/docs/.gitbook/assets/configure-env (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configure-env (2).jpg b/docs/.gitbook/assets/configure-env (2).jpg
deleted file mode 100644
index e7c439402d..0000000000
Binary files a/docs/.gitbook/assets/configure-env (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configure-env (3).jpg b/docs/.gitbook/assets/configure-env (3).jpg
deleted file mode 100644
index e7c439402d..0000000000
Binary files a/docs/.gitbook/assets/configure-env (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configure-env (4).jpg b/docs/.gitbook/assets/configure-env (4).jpg
deleted file mode 100644
index e7c439402d..0000000000
Binary files a/docs/.gitbook/assets/configure-env (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configure-env (5).jpg b/docs/.gitbook/assets/configure-env (5).jpg
deleted file mode 100644
index e7c439402d..0000000000
Binary files a/docs/.gitbook/assets/configure-env (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configure-env.jpg b/docs/.gitbook/assets/configure-env.jpg
deleted file mode 100644
index e7c439402d..0000000000
Binary files a/docs/.gitbook/assets/configure-env.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configure-secrets (1) (2) (1).jpg b/docs/.gitbook/assets/configure-secrets (1) (2) (1).jpg
deleted file mode 100644
index 0be7c5f02f..0000000000
Binary files a/docs/.gitbook/assets/configure-secrets (1) (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configure-secrets (1) (2) (2).jpg b/docs/.gitbook/assets/configure-secrets (1) (2) (2).jpg
deleted file mode 100644
index 0be7c5f02f..0000000000
Binary files a/docs/.gitbook/assets/configure-secrets (1) (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configure-secrets (1) (2) (3).jpg b/docs/.gitbook/assets/configure-secrets (1) (2) (3).jpg
deleted file mode 100644
index 0be7c5f02f..0000000000
Binary files a/docs/.gitbook/assets/configure-secrets (1) (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configure-secrets (1) (2) (4).jpg b/docs/.gitbook/assets/configure-secrets (1) (2) (4).jpg
deleted file mode 100644
index 0be7c5f02f..0000000000
Binary files a/docs/.gitbook/assets/configure-secrets (1) (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configure-secrets (1) (2).jpg b/docs/.gitbook/assets/configure-secrets (1) (2).jpg
deleted file mode 100644
index 0be7c5f02f..0000000000
Binary files a/docs/.gitbook/assets/configure-secrets (1) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/configuring-cd-pipeline (1).png b/docs/.gitbook/assets/configuring-cd-pipeline (1).png
deleted file mode 100644
index 662dc14629..0000000000
Binary files a/docs/.gitbook/assets/configuring-cd-pipeline (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/configuring-cd-pipeline (2).png b/docs/.gitbook/assets/configuring-cd-pipeline (2).png
deleted file mode 100644
index 662dc14629..0000000000
Binary files a/docs/.gitbook/assets/configuring-cd-pipeline (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/configuring-cd-pipeline (3).png b/docs/.gitbook/assets/configuring-cd-pipeline (3).png
deleted file mode 100644
index 662dc14629..0000000000
Binary files a/docs/.gitbook/assets/configuring-cd-pipeline (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/configuring-cd-pipeline (4).png b/docs/.gitbook/assets/configuring-cd-pipeline (4).png
deleted file mode 100644
index 662dc14629..0000000000
Binary files a/docs/.gitbook/assets/configuring-cd-pipeline (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/configuring-cd-pipeline (5).png b/docs/.gitbook/assets/configuring-cd-pipeline (5).png
deleted file mode 100644
index 662dc14629..0000000000
Binary files a/docs/.gitbook/assets/configuring-cd-pipeline (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/configuring-cd-pipeline (6).png b/docs/.gitbook/assets/configuring-cd-pipeline (6).png
deleted file mode 100644
index 662dc14629..0000000000
Binary files a/docs/.gitbook/assets/configuring-cd-pipeline (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/configuring-cd-pipeline (7).png b/docs/.gitbook/assets/configuring-cd-pipeline (7).png
deleted file mode 100644
index 662dc14629..0000000000
Binary files a/docs/.gitbook/assets/configuring-cd-pipeline (7).png and /dev/null differ
diff --git a/docs/.gitbook/assets/configuring-cd-pipeline.png b/docs/.gitbook/assets/configuring-cd-pipeline.png
deleted file mode 100644
index 662dc14629..0000000000
Binary files a/docs/.gitbook/assets/configuring-cd-pipeline.png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-app-git-account.gif b/docs/.gitbook/assets/create-app-git-account.gif
deleted file mode 100644
index 522392a78d..0000000000
Binary files a/docs/.gitbook/assets/create-app-git-account.gif and /dev/null differ
diff --git a/docs/.gitbook/assets/create-app-git-save.png b/docs/.gitbook/assets/create-app-git-save.png
deleted file mode 100644
index bc44b602d6..0000000000
Binary files a/docs/.gitbook/assets/create-app-git-save.png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-app-git-url.png b/docs/.gitbook/assets/create-app-git-url.png
deleted file mode 100644
index 03239fb6e3..0000000000
Binary files a/docs/.gitbook/assets/create-app-git-url.png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3) (3).png b/docs/.gitbook/assets/create-cd-pipeline (3) (3).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (1).png b/docs/.gitbook/assets/create-cd-pipeline (3) (5) (1).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (2).png b/docs/.gitbook/assets/create-cd-pipeline (3) (5) (2).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (3).png b/docs/.gitbook/assets/create-cd-pipeline (3) (5) (3).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (4).png b/docs/.gitbook/assets/create-cd-pipeline (3) (5) (4).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (5).png b/docs/.gitbook/assets/create-cd-pipeline (3) (5) (5).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (6).png b/docs/.gitbook/assets/create-cd-pipeline (3) (5) (6).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (7).png b/docs/.gitbook/assets/create-cd-pipeline (3) (5) (7).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (7).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (8).png b/docs/.gitbook/assets/create-cd-pipeline (3) (5) (8).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (8).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (9).png b/docs/.gitbook/assets/create-cd-pipeline (3) (5) (9).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3) (5) (9).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3) (5).png b/docs/.gitbook/assets/create-cd-pipeline (3) (5).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-cd-pipeline (3).png b/docs/.gitbook/assets/create-cd-pipeline (3).png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/.gitbook/assets/create-cd-pipeline (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/create-docker.gif b/docs/.gitbook/assets/create-docker.gif
deleted file mode 100644
index 4f2e88cc63..0000000000
Binary files a/docs/.gitbook/assets/create-docker.gif and /dev/null differ
diff --git a/docs/.gitbook/assets/create-workflow (1).jpg b/docs/.gitbook/assets/create-workflow (1).jpg
deleted file mode 100644
index 91edff4a29..0000000000
Binary files a/docs/.gitbook/assets/create-workflow (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create-workflow (2).jpg b/docs/.gitbook/assets/create-workflow (2).jpg
deleted file mode 100644
index 91edff4a29..0000000000
Binary files a/docs/.gitbook/assets/create-workflow (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create-workflow (3).jpg b/docs/.gitbook/assets/create-workflow (3).jpg
deleted file mode 100644
index 91edff4a29..0000000000
Binary files a/docs/.gitbook/assets/create-workflow (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create-workflow (4).jpg b/docs/.gitbook/assets/create-workflow (4).jpg
deleted file mode 100644
index 91edff4a29..0000000000
Binary files a/docs/.gitbook/assets/create-workflow (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create-workflow (5).jpg b/docs/.gitbook/assets/create-workflow (5).jpg
deleted file mode 100644
index 91edff4a29..0000000000
Binary files a/docs/.gitbook/assets/create-workflow (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create-workflow (6).jpg b/docs/.gitbook/assets/create-workflow (6).jpg
deleted file mode 100644
index 91edff4a29..0000000000
Binary files a/docs/.gitbook/assets/create-workflow (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create-workflow.jpg b/docs/.gitbook/assets/create-workflow.jpg
deleted file mode 100644
index 91edff4a29..0000000000
Binary files a/docs/.gitbook/assets/create-workflow.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create_group (2) (1).jpg b/docs/.gitbook/assets/create_group (2) (1).jpg
deleted file mode 100644
index c42be22bed..0000000000
Binary files a/docs/.gitbook/assets/create_group (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create_group (2) (2).jpg b/docs/.gitbook/assets/create_group (2) (2).jpg
deleted file mode 100644
index c42be22bed..0000000000
Binary files a/docs/.gitbook/assets/create_group (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create_group (2) (3).jpg b/docs/.gitbook/assets/create_group (2) (3).jpg
deleted file mode 100644
index c42be22bed..0000000000
Binary files a/docs/.gitbook/assets/create_group (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create_group (2) (4).jpg b/docs/.gitbook/assets/create_group (2) (4).jpg
deleted file mode 100644
index c42be22bed..0000000000
Binary files a/docs/.gitbook/assets/create_group (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create_group (2) (5).jpg b/docs/.gitbook/assets/create_group (2) (5).jpg
deleted file mode 100644
index c42be22bed..0000000000
Binary files a/docs/.gitbook/assets/create_group (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create_group (2).jpg b/docs/.gitbook/assets/create_group (2).jpg
deleted file mode 100644
index c42be22bed..0000000000
Binary files a/docs/.gitbook/assets/create_group (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/create_group.jpg b/docs/.gitbook/assets/create_group.jpg
deleted file mode 100644
index c42be22bed..0000000000
Binary files a/docs/.gitbook/assets/create_group.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/created-cd-pipeline.png b/docs/.gitbook/assets/created-cd-pipeline.png
deleted file mode 100644
index 50aeaae6e9..0000000000
Binary files a/docs/.gitbook/assets/created-cd-pipeline.png and /dev/null differ
diff --git a/docs/.gitbook/assets/created-clone-app (1).jpg b/docs/.gitbook/assets/created-clone-app (1).jpg
deleted file mode 100644
index 5770b6bd18..0000000000
Binary files a/docs/.gitbook/assets/created-clone-app (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/created-clone-app (2).jpg b/docs/.gitbook/assets/created-clone-app (2).jpg
deleted file mode 100644
index 5770b6bd18..0000000000
Binary files a/docs/.gitbook/assets/created-clone-app (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/created-clone-app.jpg b/docs/.gitbook/assets/created-clone-app.jpg
deleted file mode 100644
index 5770b6bd18..0000000000
Binary files a/docs/.gitbook/assets/created-clone-app.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/created-configmap (3) (1).gif b/docs/.gitbook/assets/created-configmap (3) (1).gif
deleted file mode 100644
index 63e9dd5f76..0000000000
Binary files a/docs/.gitbook/assets/created-configmap (3) (1).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-configmap (3) (2).gif b/docs/.gitbook/assets/created-configmap (3) (2).gif
deleted file mode 100644
index 63e9dd5f76..0000000000
Binary files a/docs/.gitbook/assets/created-configmap (3) (2).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-configmap (3) (3).gif b/docs/.gitbook/assets/created-configmap (3) (3).gif
deleted file mode 100644
index 63e9dd5f76..0000000000
Binary files a/docs/.gitbook/assets/created-configmap (3) (3).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-configmap (3) (4).gif b/docs/.gitbook/assets/created-configmap (3) (4).gif
deleted file mode 100644
index 63e9dd5f76..0000000000
Binary files a/docs/.gitbook/assets/created-configmap (3) (4).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-configmap (3) (5).gif b/docs/.gitbook/assets/created-configmap (3) (5).gif
deleted file mode 100644
index 63e9dd5f76..0000000000
Binary files a/docs/.gitbook/assets/created-configmap (3) (5).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-configmap (3) (6).gif b/docs/.gitbook/assets/created-configmap (3) (6).gif
deleted file mode 100644
index 63e9dd5f76..0000000000
Binary files a/docs/.gitbook/assets/created-configmap (3) (6).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-configmap (3).gif b/docs/.gitbook/assets/created-configmap (3).gif
deleted file mode 100644
index 63e9dd5f76..0000000000
Binary files a/docs/.gitbook/assets/created-configmap (3).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-configmap.gif b/docs/.gitbook/assets/created-configmap.gif
deleted file mode 100644
index 63e9dd5f76..0000000000
Binary files a/docs/.gitbook/assets/created-configmap.gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-secret (1).gif b/docs/.gitbook/assets/created-secret (1).gif
deleted file mode 100644
index 5fd32b7acd..0000000000
Binary files a/docs/.gitbook/assets/created-secret (1).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-secret (2).gif b/docs/.gitbook/assets/created-secret (2).gif
deleted file mode 100644
index 5fd32b7acd..0000000000
Binary files a/docs/.gitbook/assets/created-secret (2).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-secret (3).gif b/docs/.gitbook/assets/created-secret (3).gif
deleted file mode 100644
index 5fd32b7acd..0000000000
Binary files a/docs/.gitbook/assets/created-secret (3).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-secret (4).gif b/docs/.gitbook/assets/created-secret (4).gif
deleted file mode 100644
index 5fd32b7acd..0000000000
Binary files a/docs/.gitbook/assets/created-secret (4).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-secret (5).gif b/docs/.gitbook/assets/created-secret (5).gif
deleted file mode 100644
index 5fd32b7acd..0000000000
Binary files a/docs/.gitbook/assets/created-secret (5).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-secret (6).gif b/docs/.gitbook/assets/created-secret (6).gif
deleted file mode 100644
index 5fd32b7acd..0000000000
Binary files a/docs/.gitbook/assets/created-secret (6).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/created-secret.gif b/docs/.gitbook/assets/created-secret.gif
deleted file mode 100644
index 5fd32b7acd..0000000000
Binary files a/docs/.gitbook/assets/created-secret.gif and /dev/null differ
diff --git a/docs/.gitbook/assets/creating-env (1).gif b/docs/.gitbook/assets/creating-env (1).gif
deleted file mode 100644
index 5a20f4dce1..0000000000
Binary files a/docs/.gitbook/assets/creating-env (1).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/creating-env (2).gif b/docs/.gitbook/assets/creating-env (2).gif
deleted file mode 100644
index 5a20f4dce1..0000000000
Binary files a/docs/.gitbook/assets/creating-env (2).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/creating-env (3).gif b/docs/.gitbook/assets/creating-env (3).gif
deleted file mode 100644
index 5a20f4dce1..0000000000
Binary files a/docs/.gitbook/assets/creating-env (3).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/creating-env (4).gif b/docs/.gitbook/assets/creating-env (4).gif
deleted file mode 100644
index 5a20f4dce1..0000000000
Binary files a/docs/.gitbook/assets/creating-env (4).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/creating-env (5).gif b/docs/.gitbook/assets/creating-env (5).gif
deleted file mode 100644
index 5a20f4dce1..0000000000
Binary files a/docs/.gitbook/assets/creating-env (5).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/creating-env (6).gif b/docs/.gitbook/assets/creating-env (6).gif
deleted file mode 100644
index 5a20f4dce1..0000000000
Binary files a/docs/.gitbook/assets/creating-env (6).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/creating-env.gif b/docs/.gitbook/assets/creating-env.gif
deleted file mode 100644
index 5a20f4dce1..0000000000
Binary files a/docs/.gitbook/assets/creating-env.gif and /dev/null differ
diff --git a/docs/.gitbook/assets/custom (3) (1).jpg b/docs/.gitbook/assets/custom (3) (1).jpg
deleted file mode 100644
index 0efc01204b..0000000000
Binary files a/docs/.gitbook/assets/custom (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom (3) (2).jpg b/docs/.gitbook/assets/custom (3) (2).jpg
deleted file mode 100644
index 0efc01204b..0000000000
Binary files a/docs/.gitbook/assets/custom (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom (3) (3).jpg b/docs/.gitbook/assets/custom (3) (3).jpg
deleted file mode 100644
index 0efc01204b..0000000000
Binary files a/docs/.gitbook/assets/custom (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom (3) (4).jpg b/docs/.gitbook/assets/custom (3) (4).jpg
deleted file mode 100644
index 0efc01204b..0000000000
Binary files a/docs/.gitbook/assets/custom (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom (3) (5).jpg b/docs/.gitbook/assets/custom (3) (5).jpg
deleted file mode 100644
index 0efc01204b..0000000000
Binary files a/docs/.gitbook/assets/custom (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom (3) (6).jpg b/docs/.gitbook/assets/custom (3) (6).jpg
deleted file mode 100644
index 0efc01204b..0000000000
Binary files a/docs/.gitbook/assets/custom (3) (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom (3) (7).jpg b/docs/.gitbook/assets/custom (3) (7).jpg
deleted file mode 100644
index 0efc01204b..0000000000
Binary files a/docs/.gitbook/assets/custom (3) (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom (3) (8).jpg b/docs/.gitbook/assets/custom (3) (8).jpg
deleted file mode 100644
index 0efc01204b..0000000000
Binary files a/docs/.gitbook/assets/custom (3) (8).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom (3).jpg b/docs/.gitbook/assets/custom (3).jpg
deleted file mode 100644
index 0efc01204b..0000000000
Binary files a/docs/.gitbook/assets/custom (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom_val (2) (1).jpg b/docs/.gitbook/assets/custom_val (2) (1).jpg
deleted file mode 100644
index 522ae8a957..0000000000
Binary files a/docs/.gitbook/assets/custom_val (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom_val (2) (2).jpg b/docs/.gitbook/assets/custom_val (2) (2).jpg
deleted file mode 100644
index 522ae8a957..0000000000
Binary files a/docs/.gitbook/assets/custom_val (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom_val (2) (3).jpg b/docs/.gitbook/assets/custom_val (2) (3).jpg
deleted file mode 100644
index 522ae8a957..0000000000
Binary files a/docs/.gitbook/assets/custom_val (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom_val (2) (4).jpg b/docs/.gitbook/assets/custom_val (2) (4).jpg
deleted file mode 100644
index 522ae8a957..0000000000
Binary files a/docs/.gitbook/assets/custom_val (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom_val (2) (5).jpg b/docs/.gitbook/assets/custom_val (2) (5).jpg
deleted file mode 100644
index 522ae8a957..0000000000
Binary files a/docs/.gitbook/assets/custom_val (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom_val (2).jpg b/docs/.gitbook/assets/custom_val (2).jpg
deleted file mode 100644
index 522ae8a957..0000000000
Binary files a/docs/.gitbook/assets/custom_val (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/custom_val.jpg b/docs/.gitbook/assets/custom_val.jpg
deleted file mode 100644
index 522ae8a957..0000000000
Binary files a/docs/.gitbook/assets/custom_val.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/d1 (2).jpg b/docs/.gitbook/assets/d1 (2).jpg
deleted file mode 100644
index 130d81ee38..0000000000
Binary files a/docs/.gitbook/assets/d1 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_app3.jpg b/docs/.gitbook/assets/delete_app3.jpg
deleted file mode 100644
index a2a6936ae6..0000000000
Binary files a/docs/.gitbook/assets/delete_app3.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_configmap (2) (2) (1).png b/docs/.gitbook/assets/delete_configmap (2) (2) (1).png
deleted file mode 100644
index 99c2d8277b..0000000000
Binary files a/docs/.gitbook/assets/delete_configmap (2) (2) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_configmap (2) (2) (2).png b/docs/.gitbook/assets/delete_configmap (2) (2) (2).png
deleted file mode 100644
index 99c2d8277b..0000000000
Binary files a/docs/.gitbook/assets/delete_configmap (2) (2) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_configmap (2) (2) (3).png b/docs/.gitbook/assets/delete_configmap (2) (2) (3).png
deleted file mode 100644
index 99c2d8277b..0000000000
Binary files a/docs/.gitbook/assets/delete_configmap (2) (2) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_configmap (2) (2) (4).png b/docs/.gitbook/assets/delete_configmap (2) (2) (4).png
deleted file mode 100644
index 99c2d8277b..0000000000
Binary files a/docs/.gitbook/assets/delete_configmap (2) (2) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_configmap (2) (2).png b/docs/.gitbook/assets/delete_configmap (2) (2).png
deleted file mode 100644
index 99c2d8277b..0000000000
Binary files a/docs/.gitbook/assets/delete_configmap (2) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_configmap (2).png b/docs/.gitbook/assets/delete_configmap (2).png
deleted file mode 100644
index 99c2d8277b..0000000000
Binary files a/docs/.gitbook/assets/delete_configmap (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_secret (2) (1) (1).png b/docs/.gitbook/assets/delete_secret (2) (1) (1).png
deleted file mode 100644
index 91863fed80..0000000000
Binary files a/docs/.gitbook/assets/delete_secret (2) (1) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_secret (2) (1) (2).png b/docs/.gitbook/assets/delete_secret (2) (1) (2).png
deleted file mode 100644
index 91863fed80..0000000000
Binary files a/docs/.gitbook/assets/delete_secret (2) (1) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_secret (2) (1) (3).png b/docs/.gitbook/assets/delete_secret (2) (1) (3).png
deleted file mode 100644
index 91863fed80..0000000000
Binary files a/docs/.gitbook/assets/delete_secret (2) (1) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_secret (2) (1) (4).png b/docs/.gitbook/assets/delete_secret (2) (1) (4).png
deleted file mode 100644
index 91863fed80..0000000000
Binary files a/docs/.gitbook/assets/delete_secret (2) (1) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/delete_secret (2) (1).png b/docs/.gitbook/assets/delete_secret (2) (1).png
deleted file mode 100644
index 91863fed80..0000000000
Binary files a/docs/.gitbook/assets/delete_secret (2) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-delete-application (1).jpg b/docs/.gitbook/assets/deleting-delete-application (1).jpg
deleted file mode 100644
index a2a6936ae6..0000000000
Binary files a/docs/.gitbook/assets/deleting-delete-application (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-delete-application (2).jpg b/docs/.gitbook/assets/deleting-delete-application (2).jpg
deleted file mode 100644
index a2a6936ae6..0000000000
Binary files a/docs/.gitbook/assets/deleting-delete-application (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-delete-application (3).jpg b/docs/.gitbook/assets/deleting-delete-application (3).jpg
deleted file mode 100644
index a2a6936ae6..0000000000
Binary files a/docs/.gitbook/assets/deleting-delete-application (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-delete-application (4).jpg b/docs/.gitbook/assets/deleting-delete-application (4).jpg
deleted file mode 100644
index a2a6936ae6..0000000000
Binary files a/docs/.gitbook/assets/deleting-delete-application (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-delete-application (5).jpg b/docs/.gitbook/assets/deleting-delete-application (5).jpg
deleted file mode 100644
index a2a6936ae6..0000000000
Binary files a/docs/.gitbook/assets/deleting-delete-application (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-delete-application.jpg b/docs/.gitbook/assets/deleting-delete-application.jpg
deleted file mode 100644
index a2a6936ae6..0000000000
Binary files a/docs/.gitbook/assets/deleting-delete-application.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-warnning (1).jpg b/docs/.gitbook/assets/deleting-warnning (1).jpg
deleted file mode 100644
index 26e169d91d..0000000000
Binary files a/docs/.gitbook/assets/deleting-warnning (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-warnning (2).jpg b/docs/.gitbook/assets/deleting-warnning (2).jpg
deleted file mode 100644
index 26e169d91d..0000000000
Binary files a/docs/.gitbook/assets/deleting-warnning (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-warnning (3).jpg b/docs/.gitbook/assets/deleting-warnning (3).jpg
deleted file mode 100644
index 26e169d91d..0000000000
Binary files a/docs/.gitbook/assets/deleting-warnning (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-warnning (4).jpg b/docs/.gitbook/assets/deleting-warnning (4).jpg
deleted file mode 100644
index 26e169d91d..0000000000
Binary files a/docs/.gitbook/assets/deleting-warnning (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-warnning (5).jpg b/docs/.gitbook/assets/deleting-warnning (5).jpg
deleted file mode 100644
index 26e169d91d..0000000000
Binary files a/docs/.gitbook/assets/deleting-warnning (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-warnning (6).jpg b/docs/.gitbook/assets/deleting-warnning (6).jpg
deleted file mode 100644
index 26e169d91d..0000000000
Binary files a/docs/.gitbook/assets/deleting-warnning (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-warnning.jpg b/docs/.gitbook/assets/deleting-warnning.jpg
deleted file mode 100644
index 26e169d91d..0000000000
Binary files a/docs/.gitbook/assets/deleting-warnning.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-workflow (1).jpg b/docs/.gitbook/assets/deleting-workflow (1).jpg
deleted file mode 100644
index 8ef88434b1..0000000000
Binary files a/docs/.gitbook/assets/deleting-workflow (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-workflow (2).jpg b/docs/.gitbook/assets/deleting-workflow (2).jpg
deleted file mode 100644
index 8ef88434b1..0000000000
Binary files a/docs/.gitbook/assets/deleting-workflow (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-workflow (3).jpg b/docs/.gitbook/assets/deleting-workflow (3).jpg
deleted file mode 100644
index 8ef88434b1..0000000000
Binary files a/docs/.gitbook/assets/deleting-workflow (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-workflow (4).jpg b/docs/.gitbook/assets/deleting-workflow (4).jpg
deleted file mode 100644
index 8ef88434b1..0000000000
Binary files a/docs/.gitbook/assets/deleting-workflow (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-workflow (5).jpg b/docs/.gitbook/assets/deleting-workflow (5).jpg
deleted file mode 100644
index 8ef88434b1..0000000000
Binary files a/docs/.gitbook/assets/deleting-workflow (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-workflow (6).jpg b/docs/.gitbook/assets/deleting-workflow (6).jpg
deleted file mode 100644
index 8ef88434b1..0000000000
Binary files a/docs/.gitbook/assets/deleting-workflow (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deleting-workflow.jpg b/docs/.gitbook/assets/deleting-workflow.jpg
deleted file mode 100644
index 8ef88434b1..0000000000
Binary files a/docs/.gitbook/assets/deleting-workflow.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/demo (3) (1).jpg b/docs/.gitbook/assets/demo (3) (1).jpg
deleted file mode 100644
index 40ab55940c..0000000000
Binary files a/docs/.gitbook/assets/demo (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/demo (3) (2).jpg b/docs/.gitbook/assets/demo (3) (2).jpg
deleted file mode 100644
index 40ab55940c..0000000000
Binary files a/docs/.gitbook/assets/demo (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/demo (3) (3).jpg b/docs/.gitbook/assets/demo (3) (3).jpg
deleted file mode 100644
index 40ab55940c..0000000000
Binary files a/docs/.gitbook/assets/demo (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/demo (3) (4).jpg b/docs/.gitbook/assets/demo (3) (4).jpg
deleted file mode 100644
index 40ab55940c..0000000000
Binary files a/docs/.gitbook/assets/demo (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/demo (3) (5).jpg b/docs/.gitbook/assets/demo (3) (5).jpg
deleted file mode 100644
index 40ab55940c..0000000000
Binary files a/docs/.gitbook/assets/demo (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/demo (3).jpg b/docs/.gitbook/assets/demo (3).jpg
deleted file mode 100644
index 40ab55940c..0000000000
Binary files a/docs/.gitbook/assets/demo (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/demo.jpg b/docs/.gitbook/assets/demo.jpg
deleted file mode 100644
index 40ab55940c..0000000000
Binary files a/docs/.gitbook/assets/demo.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4config (1).jpg b/docs/.gitbook/assets/depchart4config (1).jpg
deleted file mode 100644
index 3848c70048..0000000000
Binary files a/docs/.gitbook/assets/depchart4config (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4config (2).jpg b/docs/.gitbook/assets/depchart4config (2).jpg
deleted file mode 100644
index 3848c70048..0000000000
Binary files a/docs/.gitbook/assets/depchart4config (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4config (3).jpg b/docs/.gitbook/assets/depchart4config (3).jpg
deleted file mode 100644
index 3848c70048..0000000000
Binary files a/docs/.gitbook/assets/depchart4config (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4config (4).jpg b/docs/.gitbook/assets/depchart4config (4).jpg
deleted file mode 100644
index 3848c70048..0000000000
Binary files a/docs/.gitbook/assets/depchart4config (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4config (5).jpg b/docs/.gitbook/assets/depchart4config (5).jpg
deleted file mode 100644
index 3848c70048..0000000000
Binary files a/docs/.gitbook/assets/depchart4config (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4config (6).jpg b/docs/.gitbook/assets/depchart4config (6).jpg
deleted file mode 100644
index 3848c70048..0000000000
Binary files a/docs/.gitbook/assets/depchart4config (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4config.jpg b/docs/.gitbook/assets/depchart4config.jpg
deleted file mode 100644
index 3848c70048..0000000000
Binary files a/docs/.gitbook/assets/depchart4config.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4readme (1).jpg b/docs/.gitbook/assets/depchart4readme (1).jpg
deleted file mode 100644
index f19b9ec829..0000000000
Binary files a/docs/.gitbook/assets/depchart4readme (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4readme (2).jpg b/docs/.gitbook/assets/depchart4readme (2).jpg
deleted file mode 100644
index f19b9ec829..0000000000
Binary files a/docs/.gitbook/assets/depchart4readme (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4readme (3).jpg b/docs/.gitbook/assets/depchart4readme (3).jpg
deleted file mode 100644
index f19b9ec829..0000000000
Binary files a/docs/.gitbook/assets/depchart4readme (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4readme (4).jpg b/docs/.gitbook/assets/depchart4readme (4).jpg
deleted file mode 100644
index f19b9ec829..0000000000
Binary files a/docs/.gitbook/assets/depchart4readme (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4readme (5).jpg b/docs/.gitbook/assets/depchart4readme (5).jpg
deleted file mode 100644
index f19b9ec829..0000000000
Binary files a/docs/.gitbook/assets/depchart4readme (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4readme (6).jpg b/docs/.gitbook/assets/depchart4readme (6).jpg
deleted file mode 100644
index f19b9ec829..0000000000
Binary files a/docs/.gitbook/assets/depchart4readme (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchart4readme.jpg b/docs/.gitbook/assets/depchart4readme.jpg
deleted file mode 100644
index f19b9ec829..0000000000
Binary files a/docs/.gitbook/assets/depchart4readme.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchartdeployedredo (2) (1).jpg b/docs/.gitbook/assets/depchartdeployedredo (2) (1).jpg
deleted file mode 100644
index 22e53d76a2..0000000000
Binary files a/docs/.gitbook/assets/depchartdeployedredo (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchartdeployedredo (2) (2).jpg b/docs/.gitbook/assets/depchartdeployedredo (2) (2).jpg
deleted file mode 100644
index 22e53d76a2..0000000000
Binary files a/docs/.gitbook/assets/depchartdeployedredo (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchartdeployedredo (2) (3).jpg b/docs/.gitbook/assets/depchartdeployedredo (2) (3).jpg
deleted file mode 100644
index 22e53d76a2..0000000000
Binary files a/docs/.gitbook/assets/depchartdeployedredo (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchartdeployedredo (2).jpg b/docs/.gitbook/assets/depchartdeployedredo (2).jpg
deleted file mode 100644
index 22e53d76a2..0000000000
Binary files a/docs/.gitbook/assets/depchartdeployedredo (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchartreconfig (2) (1).jpg b/docs/.gitbook/assets/depchartreconfig (2) (1).jpg
deleted file mode 100644
index 7bbc92df9a..0000000000
Binary files a/docs/.gitbook/assets/depchartreconfig (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchartreconfig (2) (2).jpg b/docs/.gitbook/assets/depchartreconfig (2) (2).jpg
deleted file mode 100644
index 7bbc92df9a..0000000000
Binary files a/docs/.gitbook/assets/depchartreconfig (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchartreconfig (2) (3).jpg b/docs/.gitbook/assets/depchartreconfig (2) (3).jpg
deleted file mode 100644
index 7bbc92df9a..0000000000
Binary files a/docs/.gitbook/assets/depchartreconfig (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchartreconfig (2) (4).jpg b/docs/.gitbook/assets/depchartreconfig (2) (4).jpg
deleted file mode 100644
index 7bbc92df9a..0000000000
Binary files a/docs/.gitbook/assets/depchartreconfig (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchartreconfig (2) (5).jpg b/docs/.gitbook/assets/depchartreconfig (2) (5).jpg
deleted file mode 100644
index 7bbc92df9a..0000000000
Binary files a/docs/.gitbook/assets/depchartreconfig (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchartreconfig (2).jpg b/docs/.gitbook/assets/depchartreconfig (2).jpg
deleted file mode 100644
index 7bbc92df9a..0000000000
Binary files a/docs/.gitbook/assets/depchartreconfig (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/depchartreconfig.jpg b/docs/.gitbook/assets/depchartreconfig.jpg
deleted file mode 100644
index 7bbc92df9a..0000000000
Binary files a/docs/.gitbook/assets/depchartreconfig.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deploy-chart-store (1).jpg b/docs/.gitbook/assets/deploy-chart-store (1).jpg
deleted file mode 100644
index c69e923526..0000000000
Binary files a/docs/.gitbook/assets/deploy-chart-store (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deploy-chart-store (2).jpg b/docs/.gitbook/assets/deploy-chart-store (2).jpg
deleted file mode 100644
index c69e923526..0000000000
Binary files a/docs/.gitbook/assets/deploy-chart-store (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deploy-chart-store (3).jpg b/docs/.gitbook/assets/deploy-chart-store (3).jpg
deleted file mode 100644
index c69e923526..0000000000
Binary files a/docs/.gitbook/assets/deploy-chart-store (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deploy-chart-store.jpg b/docs/.gitbook/assets/deploy-chart-store.jpg
deleted file mode 100644
index c69e923526..0000000000
Binary files a/docs/.gitbook/assets/deploy-chart-store.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deployed-app-details (1).jpg b/docs/.gitbook/assets/deployed-app-details (1).jpg
deleted file mode 100644
index a23e37662f..0000000000
Binary files a/docs/.gitbook/assets/deployed-app-details (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deployed-app-details (2).jpg b/docs/.gitbook/assets/deployed-app-details (2).jpg
deleted file mode 100644
index a23e37662f..0000000000
Binary files a/docs/.gitbook/assets/deployed-app-details (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deployed-app-details (3).jpg b/docs/.gitbook/assets/deployed-app-details (3).jpg
deleted file mode 100644
index a23e37662f..0000000000
Binary files a/docs/.gitbook/assets/deployed-app-details (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deployed-app-details (4).jpg b/docs/.gitbook/assets/deployed-app-details (4).jpg
deleted file mode 100644
index a23e37662f..0000000000
Binary files a/docs/.gitbook/assets/deployed-app-details (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deployed-app-details (5).jpg b/docs/.gitbook/assets/deployed-app-details (5).jpg
deleted file mode 100644
index a23e37662f..0000000000
Binary files a/docs/.gitbook/assets/deployed-app-details (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deployed-app-details.jpg b/docs/.gitbook/assets/deployed-app-details.jpg
deleted file mode 100644
index a23e37662f..0000000000
Binary files a/docs/.gitbook/assets/deployed-app-details.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment-template (3) (1).gif b/docs/.gitbook/assets/deployment-template (3) (1).gif
deleted file mode 100644
index c0c0681eac..0000000000
Binary files a/docs/.gitbook/assets/deployment-template (3) (1).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment-template (3) (2).gif b/docs/.gitbook/assets/deployment-template (3) (2).gif
deleted file mode 100644
index c0c0681eac..0000000000
Binary files a/docs/.gitbook/assets/deployment-template (3) (2).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment-template (3) (3).gif b/docs/.gitbook/assets/deployment-template (3) (3).gif
deleted file mode 100644
index c0c0681eac..0000000000
Binary files a/docs/.gitbook/assets/deployment-template (3) (3).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment-template (3) (4).gif b/docs/.gitbook/assets/deployment-template (3) (4).gif
deleted file mode 100644
index c0c0681eac..0000000000
Binary files a/docs/.gitbook/assets/deployment-template (3) (4).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment-template (3) (5).gif b/docs/.gitbook/assets/deployment-template (3) (5).gif
deleted file mode 100644
index c0c0681eac..0000000000
Binary files a/docs/.gitbook/assets/deployment-template (3) (5).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment-template (3) (6).gif b/docs/.gitbook/assets/deployment-template (3) (6).gif
deleted file mode 100644
index c0c0681eac..0000000000
Binary files a/docs/.gitbook/assets/deployment-template (3) (6).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment-template (3).gif b/docs/.gitbook/assets/deployment-template (3).gif
deleted file mode 100644
index c0c0681eac..0000000000
Binary files a/docs/.gitbook/assets/deployment-template (3).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment_application_metrics (2) (2) (1).png b/docs/.gitbook/assets/deployment_application_metrics (2) (2) (1).png
deleted file mode 100644
index 215df893e6..0000000000
Binary files a/docs/.gitbook/assets/deployment_application_metrics (2) (2) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment_application_metrics (2) (2) (2).png b/docs/.gitbook/assets/deployment_application_metrics (2) (2) (2).png
deleted file mode 100644
index 215df893e6..0000000000
Binary files a/docs/.gitbook/assets/deployment_application_metrics (2) (2) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment_application_metrics (2) (2) (3).png b/docs/.gitbook/assets/deployment_application_metrics (2) (2) (3).png
deleted file mode 100644
index 215df893e6..0000000000
Binary files a/docs/.gitbook/assets/deployment_application_metrics (2) (2) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment_application_metrics (2) (2) (4).png b/docs/.gitbook/assets/deployment_application_metrics (2) (2) (4).png
deleted file mode 100644
index 215df893e6..0000000000
Binary files a/docs/.gitbook/assets/deployment_application_metrics (2) (2) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/deployment_application_metrics (2) (2).png b/docs/.gitbook/assets/deployment_application_metrics (2) (2).png
deleted file mode 100644
index 215df893e6..0000000000
Binary files a/docs/.gitbook/assets/deployment_application_metrics (2) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/docker-configuration (1).gif b/docs/.gitbook/assets/docker-configuration (1).gif
deleted file mode 100644
index 84b70bec9e..0000000000
Binary files a/docs/.gitbook/assets/docker-configuration (1).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/docker-configuration (2).gif b/docs/.gitbook/assets/docker-configuration (2).gif
deleted file mode 100644
index 84b70bec9e..0000000000
Binary files a/docs/.gitbook/assets/docker-configuration (2).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/docker-configuration (3).gif b/docs/.gitbook/assets/docker-configuration (3).gif
deleted file mode 100644
index 84b70bec9e..0000000000
Binary files a/docs/.gitbook/assets/docker-configuration (3).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/docker-configuration (4).gif b/docs/.gitbook/assets/docker-configuration (4).gif
deleted file mode 100644
index 84b70bec9e..0000000000
Binary files a/docs/.gitbook/assets/docker-configuration (4).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/docker-configuration (5).gif b/docs/.gitbook/assets/docker-configuration (5).gif
deleted file mode 100644
index 84b70bec9e..0000000000
Binary files a/docs/.gitbook/assets/docker-configuration (5).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/docker-configuration (6).gif b/docs/.gitbook/assets/docker-configuration (6).gif
deleted file mode 100644
index 84b70bec9e..0000000000
Binary files a/docs/.gitbook/assets/docker-configuration (6).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/docker-configuration-docker-hub.png b/docs/.gitbook/assets/docker-configuration-docker-hub.png
deleted file mode 100644
index 5679d6909a..0000000000
Binary files a/docs/.gitbook/assets/docker-configuration-docker-hub.png and /dev/null differ
diff --git a/docs/.gitbook/assets/docker-configuration.gif b/docs/.gitbook/assets/docker-configuration.gif
deleted file mode 100644
index 84b70bec9e..0000000000
Binary files a/docs/.gitbook/assets/docker-configuration.gif and /dev/null differ
diff --git a/docs/.gitbook/assets/docker-configure-docker-hub-1.png b/docs/.gitbook/assets/docker-configure-docker-hub-1.png
deleted file mode 100644
index a3fdb9d082..0000000000
Binary files a/docs/.gitbook/assets/docker-configure-docker-hub-1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (2).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (2).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (1).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (1).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (10).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (10).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (10).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (11).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (11).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (11).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (2).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (2).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (3).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (3).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (4).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (4).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (5).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (5).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (6).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (6).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (7).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (7).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (8).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (8).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (8).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (9).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (9).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6) (9).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5) (6).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5) (6).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5) (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_cd_pipeline (5).jpg b/docs/.gitbook/assets/edit_cd_pipeline (5).jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/.gitbook/assets/edit_cd_pipeline (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_chart1 (1).jpg b/docs/.gitbook/assets/edit_chart1 (1).jpg
deleted file mode 100644
index 6c5d90e38d..0000000000
Binary files a/docs/.gitbook/assets/edit_chart1 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_chart1 (2).jpg b/docs/.gitbook/assets/edit_chart1 (2).jpg
deleted file mode 100644
index 6c5d90e38d..0000000000
Binary files a/docs/.gitbook/assets/edit_chart1 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_chart1 (3).jpg b/docs/.gitbook/assets/edit_chart1 (3).jpg
deleted file mode 100644
index 6c5d90e38d..0000000000
Binary files a/docs/.gitbook/assets/edit_chart1 (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_chart1 (4).jpg b/docs/.gitbook/assets/edit_chart1 (4).jpg
deleted file mode 100644
index 6c5d90e38d..0000000000
Binary files a/docs/.gitbook/assets/edit_chart1 (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_chart1 (5).jpg b/docs/.gitbook/assets/edit_chart1 (5).jpg
deleted file mode 100644
index 6c5d90e38d..0000000000
Binary files a/docs/.gitbook/assets/edit_chart1 (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_chart1 (6).jpg b/docs/.gitbook/assets/edit_chart1 (6).jpg
deleted file mode 100644
index 6c5d90e38d..0000000000
Binary files a/docs/.gitbook/assets/edit_chart1 (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_chart1.jpg b/docs/.gitbook/assets/edit_chart1.jpg
deleted file mode 100644
index 6c5d90e38d..0000000000
Binary files a/docs/.gitbook/assets/edit_chart1.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group (1).jpg b/docs/.gitbook/assets/edit_group (1).jpg
deleted file mode 100644
index 8490838613..0000000000
Binary files a/docs/.gitbook/assets/edit_group (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group (2).jpg b/docs/.gitbook/assets/edit_group (2).jpg
deleted file mode 100644
index 8490838613..0000000000
Binary files a/docs/.gitbook/assets/edit_group (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group (3).jpg b/docs/.gitbook/assets/edit_group (3).jpg
deleted file mode 100644
index 8490838613..0000000000
Binary files a/docs/.gitbook/assets/edit_group (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group (4).jpg b/docs/.gitbook/assets/edit_group (4).jpg
deleted file mode 100644
index 8490838613..0000000000
Binary files a/docs/.gitbook/assets/edit_group (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group (5).jpg b/docs/.gitbook/assets/edit_group (5).jpg
deleted file mode 100644
index 8490838613..0000000000
Binary files a/docs/.gitbook/assets/edit_group (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group.jpg b/docs/.gitbook/assets/edit_group.jpg
deleted file mode 100644
index 8490838613..0000000000
Binary files a/docs/.gitbook/assets/edit_group.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group2 (1).jpg b/docs/.gitbook/assets/edit_group2 (1).jpg
deleted file mode 100644
index e592ee4875..0000000000
Binary files a/docs/.gitbook/assets/edit_group2 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group2 (2).jpg b/docs/.gitbook/assets/edit_group2 (2).jpg
deleted file mode 100644
index e592ee4875..0000000000
Binary files a/docs/.gitbook/assets/edit_group2 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group2 (3).jpg b/docs/.gitbook/assets/edit_group2 (3).jpg
deleted file mode 100644
index e592ee4875..0000000000
Binary files a/docs/.gitbook/assets/edit_group2 (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group2 (4).jpg b/docs/.gitbook/assets/edit_group2 (4).jpg
deleted file mode 100644
index e592ee4875..0000000000
Binary files a/docs/.gitbook/assets/edit_group2 (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group2 (5).jpg b/docs/.gitbook/assets/edit_group2 (5).jpg
deleted file mode 100644
index e592ee4875..0000000000
Binary files a/docs/.gitbook/assets/edit_group2 (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group2 (6).jpg b/docs/.gitbook/assets/edit_group2 (6).jpg
deleted file mode 100644
index e592ee4875..0000000000
Binary files a/docs/.gitbook/assets/edit_group2 (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_group2.jpg b/docs/.gitbook/assets/edit_group2.jpg
deleted file mode 100644
index e592ee4875..0000000000
Binary files a/docs/.gitbook/assets/edit_group2.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (1).jpg b/docs/.gitbook/assets/edit_pipeline (1).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (10).jpg b/docs/.gitbook/assets/edit_pipeline (10).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (10).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (11).jpg b/docs/.gitbook/assets/edit_pipeline (11).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (11).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (12).jpg b/docs/.gitbook/assets/edit_pipeline (12).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (12).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (13).jpg b/docs/.gitbook/assets/edit_pipeline (13).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (13).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (14).jpg b/docs/.gitbook/assets/edit_pipeline (14).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (14).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (2).jpg b/docs/.gitbook/assets/edit_pipeline (2).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (3).jpg b/docs/.gitbook/assets/edit_pipeline (3).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (4).jpg b/docs/.gitbook/assets/edit_pipeline (4).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (5).jpg b/docs/.gitbook/assets/edit_pipeline (5).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (6).jpg b/docs/.gitbook/assets/edit_pipeline (6).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (7).jpg b/docs/.gitbook/assets/edit_pipeline (7).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (8).jpg b/docs/.gitbook/assets/edit_pipeline (8).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (8).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline (9).jpg b/docs/.gitbook/assets/edit_pipeline (9).jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline (9).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/edit_pipeline.jpg b/docs/.gitbook/assets/edit_pipeline.jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/.gitbook/assets/edit_pipeline.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/env_ride (3).jpg b/docs/.gitbook/assets/env_ride (3).jpg
deleted file mode 100644
index e7c439402d..0000000000
Binary files a/docs/.gitbook/assets/env_ride (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/environments1 (1).jpg b/docs/.gitbook/assets/environments1 (1).jpg
deleted file mode 100644
index d16d7e20ed..0000000000
Binary files a/docs/.gitbook/assets/environments1 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/environments1 (2) (1).jpg b/docs/.gitbook/assets/environments1 (2) (1).jpg
deleted file mode 100644
index d16d7e20ed..0000000000
Binary files a/docs/.gitbook/assets/environments1 (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/environments1 (2) (2).jpg b/docs/.gitbook/assets/environments1 (2) (2).jpg
deleted file mode 100644
index d16d7e20ed..0000000000
Binary files a/docs/.gitbook/assets/environments1 (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/environments1 (2) (3).jpg b/docs/.gitbook/assets/environments1 (2) (3).jpg
deleted file mode 100644
index d16d7e20ed..0000000000
Binary files a/docs/.gitbook/assets/environments1 (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/environments1 (2) (4).jpg b/docs/.gitbook/assets/environments1 (2) (4).jpg
deleted file mode 100644
index d16d7e20ed..0000000000
Binary files a/docs/.gitbook/assets/environments1 (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/environments1 (2) (5).jpg b/docs/.gitbook/assets/environments1 (2) (5).jpg
deleted file mode 100644
index d16d7e20ed..0000000000
Binary files a/docs/.gitbook/assets/environments1 (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/environments1 (2).jpg b/docs/.gitbook/assets/environments1 (2).jpg
deleted file mode 100644
index d16d7e20ed..0000000000
Binary files a/docs/.gitbook/assets/environments1 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events1 (1).jpg b/docs/.gitbook/assets/events1 (1).jpg
deleted file mode 100644
index 80eeb0405f..0000000000
Binary files a/docs/.gitbook/assets/events1 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events1 (2) (1).jpg b/docs/.gitbook/assets/events1 (2) (1).jpg
deleted file mode 100644
index 80eeb0405f..0000000000
Binary files a/docs/.gitbook/assets/events1 (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events1 (2) (2).jpg b/docs/.gitbook/assets/events1 (2) (2).jpg
deleted file mode 100644
index 80eeb0405f..0000000000
Binary files a/docs/.gitbook/assets/events1 (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events1 (2) (3).jpg b/docs/.gitbook/assets/events1 (2) (3).jpg
deleted file mode 100644
index 80eeb0405f..0000000000
Binary files a/docs/.gitbook/assets/events1 (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events1 (2) (4).jpg b/docs/.gitbook/assets/events1 (2) (4).jpg
deleted file mode 100644
index 80eeb0405f..0000000000
Binary files a/docs/.gitbook/assets/events1 (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events1 (2) (5).jpg b/docs/.gitbook/assets/events1 (2) (5).jpg
deleted file mode 100644
index 80eeb0405f..0000000000
Binary files a/docs/.gitbook/assets/events1 (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events1 (2).jpg b/docs/.gitbook/assets/events1 (2).jpg
deleted file mode 100644
index 80eeb0405f..0000000000
Binary files a/docs/.gitbook/assets/events1 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events2 (1).jpg b/docs/.gitbook/assets/events2 (1).jpg
deleted file mode 100644
index 82816b1f4a..0000000000
Binary files a/docs/.gitbook/assets/events2 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events3 (2).jpg b/docs/.gitbook/assets/events3 (2).jpg
deleted file mode 100644
index 3a7d5152d1..0000000000
Binary files a/docs/.gitbook/assets/events3 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events4 (2) (1).jpg b/docs/.gitbook/assets/events4 (2) (1).jpg
deleted file mode 100644
index af002af7d5..0000000000
Binary files a/docs/.gitbook/assets/events4 (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events4 (2) (2).jpg b/docs/.gitbook/assets/events4 (2) (2).jpg
deleted file mode 100644
index af002af7d5..0000000000
Binary files a/docs/.gitbook/assets/events4 (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events4 (2) (3).jpg b/docs/.gitbook/assets/events4 (2) (3).jpg
deleted file mode 100644
index af002af7d5..0000000000
Binary files a/docs/.gitbook/assets/events4 (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events4 (2).jpg b/docs/.gitbook/assets/events4 (2).jpg
deleted file mode 100644
index af002af7d5..0000000000
Binary files a/docs/.gitbook/assets/events4 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/events5 (1).png b/docs/.gitbook/assets/events5 (1).png
deleted file mode 100644
index b3b44ec533..0000000000
Binary files a/docs/.gitbook/assets/events5 (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/events5 (2) (1).png b/docs/.gitbook/assets/events5 (2) (1).png
deleted file mode 100644
index b3b44ec533..0000000000
Binary files a/docs/.gitbook/assets/events5 (2) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/events5 (2) (2).png b/docs/.gitbook/assets/events5 (2) (2).png
deleted file mode 100644
index b3b44ec533..0000000000
Binary files a/docs/.gitbook/assets/events5 (2) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/events5 (2) (3).png b/docs/.gitbook/assets/events5 (2) (3).png
deleted file mode 100644
index b3b44ec533..0000000000
Binary files a/docs/.gitbook/assets/events5 (2) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/events5 (2) (4).png b/docs/.gitbook/assets/events5 (2) (4).png
deleted file mode 100644
index b3b44ec533..0000000000
Binary files a/docs/.gitbook/assets/events5 (2) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/events5 (2) (5).png b/docs/.gitbook/assets/events5 (2) (5).png
deleted file mode 100644
index b3b44ec533..0000000000
Binary files a/docs/.gitbook/assets/events5 (2) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/events5 (2).png b/docs/.gitbook/assets/events5 (2).png
deleted file mode 100644
index b3b44ec533..0000000000
Binary files a/docs/.gitbook/assets/events5 (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/external_pipeline (1).jpg b/docs/.gitbook/assets/external_pipeline (1).jpg
deleted file mode 100644
index 9b038ae820..0000000000
Binary files a/docs/.gitbook/assets/external_pipeline (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/external_pipeline (2).jpg b/docs/.gitbook/assets/external_pipeline (2).jpg
deleted file mode 100644
index 9b038ae820..0000000000
Binary files a/docs/.gitbook/assets/external_pipeline (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/external_pipeline (3).jpg b/docs/.gitbook/assets/external_pipeline (3).jpg
deleted file mode 100644
index 9b038ae820..0000000000
Binary files a/docs/.gitbook/assets/external_pipeline (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/external_pipeline (4).jpg b/docs/.gitbook/assets/external_pipeline (4).jpg
deleted file mode 100644
index 9b038ae820..0000000000
Binary files a/docs/.gitbook/assets/external_pipeline (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/external_pipeline (5).jpg b/docs/.gitbook/assets/external_pipeline (5).jpg
deleted file mode 100644
index 9b038ae820..0000000000
Binary files a/docs/.gitbook/assets/external_pipeline (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/external_pipeline (6).jpg b/docs/.gitbook/assets/external_pipeline (6).jpg
deleted file mode 100644
index 9b038ae820..0000000000
Binary files a/docs/.gitbook/assets/external_pipeline (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/external_pipeline (7).jpg b/docs/.gitbook/assets/external_pipeline (7).jpg
deleted file mode 100644
index 9b038ae820..0000000000
Binary files a/docs/.gitbook/assets/external_pipeline (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/external_pipeline.jpg b/docs/.gitbook/assets/external_pipeline.jpg
deleted file mode 100644
index 9b038ae820..0000000000
Binary files a/docs/.gitbook/assets/external_pipeline.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/first (1).jpg b/docs/.gitbook/assets/first (1).jpg
deleted file mode 100644
index f17f6af8a2..0000000000
Binary files a/docs/.gitbook/assets/first (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/first (2).jpg b/docs/.gitbook/assets/first (2).jpg
deleted file mode 100644
index f17f6af8a2..0000000000
Binary files a/docs/.gitbook/assets/first (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/first (3).jpg b/docs/.gitbook/assets/first (3).jpg
deleted file mode 100644
index f17f6af8a2..0000000000
Binary files a/docs/.gitbook/assets/first (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/first (4).jpg b/docs/.gitbook/assets/first (4).jpg
deleted file mode 100644
index f17f6af8a2..0000000000
Binary files a/docs/.gitbook/assets/first (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/first (5).jpg b/docs/.gitbook/assets/first (5).jpg
deleted file mode 100644
index f17f6af8a2..0000000000
Binary files a/docs/.gitbook/assets/first (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/first (6).jpg b/docs/.gitbook/assets/first (6).jpg
deleted file mode 100644
index f17f6af8a2..0000000000
Binary files a/docs/.gitbook/assets/first (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/first.jpg b/docs/.gitbook/assets/first.jpg
deleted file mode 100644
index f17f6af8a2..0000000000
Binary files a/docs/.gitbook/assets/first.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-4 (3) (1).jpg b/docs/.gitbook/assets/gc-4 (3) (1).jpg
deleted file mode 100644
index 06d29473fb..0000000000
Binary files a/docs/.gitbook/assets/gc-4 (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-4 (3) (2).jpg b/docs/.gitbook/assets/gc-4 (3) (2).jpg
deleted file mode 100644
index 06d29473fb..0000000000
Binary files a/docs/.gitbook/assets/gc-4 (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-4 (3) (3).jpg b/docs/.gitbook/assets/gc-4 (3) (3).jpg
deleted file mode 100644
index 06d29473fb..0000000000
Binary files a/docs/.gitbook/assets/gc-4 (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-4 (3) (4).jpg b/docs/.gitbook/assets/gc-4 (3) (4).jpg
deleted file mode 100644
index 06d29473fb..0000000000
Binary files a/docs/.gitbook/assets/gc-4 (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-4 (3) (5).jpg b/docs/.gitbook/assets/gc-4 (3) (5).jpg
deleted file mode 100644
index 06d29473fb..0000000000
Binary files a/docs/.gitbook/assets/gc-4 (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-4 (3).jpg b/docs/.gitbook/assets/gc-4 (3).jpg
deleted file mode 100644
index 06d29473fb..0000000000
Binary files a/docs/.gitbook/assets/gc-4 (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-add-chart.png b/docs/.gitbook/assets/gc-add-chart.png
deleted file mode 100644
index 13f5917a98..0000000000
Binary files a/docs/.gitbook/assets/gc-add-chart.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-add-gitaccount (1).png b/docs/.gitbook/assets/gc-add-gitaccount (1).png
deleted file mode 100644
index d5549dfc3d..0000000000
Binary files a/docs/.gitbook/assets/gc-add-gitaccount (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-add-gitaccount (2).png b/docs/.gitbook/assets/gc-add-gitaccount (2).png
deleted file mode 100644
index d5549dfc3d..0000000000
Binary files a/docs/.gitbook/assets/gc-add-gitaccount (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-add-gitaccount (3).png b/docs/.gitbook/assets/gc-add-gitaccount (3).png
deleted file mode 100644
index d5549dfc3d..0000000000
Binary files a/docs/.gitbook/assets/gc-add-gitaccount (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-add-gitaccount (4).png b/docs/.gitbook/assets/gc-add-gitaccount (4).png
deleted file mode 100644
index d5549dfc3d..0000000000
Binary files a/docs/.gitbook/assets/gc-add-gitaccount (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-add-gitaccount (5).png b/docs/.gitbook/assets/gc-add-gitaccount (5).png
deleted file mode 100644
index d5549dfc3d..0000000000
Binary files a/docs/.gitbook/assets/gc-add-gitaccount (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-add-gitaccount (6).png b/docs/.gitbook/assets/gc-add-gitaccount (6).png
deleted file mode 100644
index d5549dfc3d..0000000000
Binary files a/docs/.gitbook/assets/gc-add-gitaccount (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-add-gitaccount (7).png b/docs/.gitbook/assets/gc-add-gitaccount (7).png
deleted file mode 100644
index d5549dfc3d..0000000000
Binary files a/docs/.gitbook/assets/gc-add-gitaccount (7).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-add-gitaccount (8).png b/docs/.gitbook/assets/gc-add-gitaccount (8).png
deleted file mode 100644
index d5549dfc3d..0000000000
Binary files a/docs/.gitbook/assets/gc-add-gitaccount (8).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-add-gitaccount.png b/docs/.gitbook/assets/gc-add-gitaccount.png
deleted file mode 100644
index d5549dfc3d..0000000000
Binary files a/docs/.gitbook/assets/gc-add-gitaccount.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-added-git-accounts (1).png b/docs/.gitbook/assets/gc-added-git-accounts (1).png
deleted file mode 100644
index 84c0f259cd..0000000000
Binary files a/docs/.gitbook/assets/gc-added-git-accounts (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-added-git-accounts (2).png b/docs/.gitbook/assets/gc-added-git-accounts (2).png
deleted file mode 100644
index 84c0f259cd..0000000000
Binary files a/docs/.gitbook/assets/gc-added-git-accounts (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-added-git-accounts (3).png b/docs/.gitbook/assets/gc-added-git-accounts (3).png
deleted file mode 100644
index 84c0f259cd..0000000000
Binary files a/docs/.gitbook/assets/gc-added-git-accounts (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-added-git-accounts (4).png b/docs/.gitbook/assets/gc-added-git-accounts (4).png
deleted file mode 100644
index 84c0f259cd..0000000000
Binary files a/docs/.gitbook/assets/gc-added-git-accounts (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-added-git-accounts (5).png b/docs/.gitbook/assets/gc-added-git-accounts (5).png
deleted file mode 100644
index 84c0f259cd..0000000000
Binary files a/docs/.gitbook/assets/gc-added-git-accounts (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-added-git-accounts (6).png b/docs/.gitbook/assets/gc-added-git-accounts (6).png
deleted file mode 100644
index 84c0f259cd..0000000000
Binary files a/docs/.gitbook/assets/gc-added-git-accounts (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-added-git-accounts (7).png b/docs/.gitbook/assets/gc-added-git-accounts (7).png
deleted file mode 100644
index 84c0f259cd..0000000000
Binary files a/docs/.gitbook/assets/gc-added-git-accounts (7).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-added-git-accounts (8).png b/docs/.gitbook/assets/gc-added-git-accounts (8).png
deleted file mode 100644
index 84c0f259cd..0000000000
Binary files a/docs/.gitbook/assets/gc-added-git-accounts (8).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-added-git-accounts.png b/docs/.gitbook/assets/gc-added-git-accounts.png
deleted file mode 100644
index 84c0f259cd..0000000000
Binary files a/docs/.gitbook/assets/gc-added-git-accounts.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-chart-config-password.png b/docs/.gitbook/assets/gc-chart-config-password.png
deleted file mode 100644
index e2eb9ffe21..0000000000
Binary files a/docs/.gitbook/assets/gc-chart-config-password.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-chart-configure-anonymous.png b/docs/.gitbook/assets/gc-chart-configure-anonymous.png
deleted file mode 100644
index 335f783040..0000000000
Binary files a/docs/.gitbook/assets/gc-chart-configure-anonymous.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-chart-configure-user.png b/docs/.gitbook/assets/gc-chart-configure-user.png
deleted file mode 100644
index e609674df4..0000000000
Binary files a/docs/.gitbook/assets/gc-chart-configure-user.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-chart-list.png b/docs/.gitbook/assets/gc-chart-list.png
deleted file mode 100644
index 2bfbaf559e..0000000000
Binary files a/docs/.gitbook/assets/gc-chart-list.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-chart-name-highlight.png b/docs/.gitbook/assets/gc-chart-name-highlight.png
deleted file mode 100644
index 02c30ad186..0000000000
Binary files a/docs/.gitbook/assets/gc-chart-name-highlight.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-chart-name.png b/docs/.gitbook/assets/gc-chart-name.png
deleted file mode 100644
index dadbe645f2..0000000000
Binary files a/docs/.gitbook/assets/gc-chart-name.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-add-environment (1).png b/docs/.gitbook/assets/gc-cluster-add-environment (1).png
deleted file mode 100644
index e8b4f0f77d..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-add-environment (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-add-environment (2).png b/docs/.gitbook/assets/gc-cluster-add-environment (2).png
deleted file mode 100644
index e8b4f0f77d..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-add-environment (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-add-environment (3).png b/docs/.gitbook/assets/gc-cluster-add-environment (3).png
deleted file mode 100644
index e8b4f0f77d..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-add-environment (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-add-environment (4).png b/docs/.gitbook/assets/gc-cluster-add-environment (4).png
deleted file mode 100644
index e8b4f0f77d..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-add-environment (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-add-environment (5).png b/docs/.gitbook/assets/gc-cluster-add-environment (5).png
deleted file mode 100644
index e8b4f0f77d..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-add-environment (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-add-environment (6).png b/docs/.gitbook/assets/gc-cluster-add-environment (6).png
deleted file mode 100644
index e8b4f0f77d..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-add-environment (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-add-environment (7).png b/docs/.gitbook/assets/gc-cluster-add-environment (7).png
deleted file mode 100644
index e8b4f0f77d..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-add-environment (7).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-add-environment.png b/docs/.gitbook/assets/gc-cluster-add-environment.png
deleted file mode 100644
index e8b4f0f77d..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-add-environment.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents (3) (1).png b/docs/.gitbook/assets/gc-cluster-agents (3) (1).png
deleted file mode 100644
index a9f46638ae..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents (3) (2).png b/docs/.gitbook/assets/gc-cluster-agents (3) (2).png
deleted file mode 100644
index a9f46638ae..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents (3) (3).png b/docs/.gitbook/assets/gc-cluster-agents (3) (3).png
deleted file mode 100644
index a9f46638ae..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents (3) (4).png b/docs/.gitbook/assets/gc-cluster-agents (3) (4).png
deleted file mode 100644
index a9f46638ae..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents (3) (5).png b/docs/.gitbook/assets/gc-cluster-agents (3) (5).png
deleted file mode 100644
index a9f46638ae..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents (3) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents (3) (6).png b/docs/.gitbook/assets/gc-cluster-agents (3) (6).png
deleted file mode 100644
index a9f46638ae..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents (3) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents (3).png b/docs/.gitbook/assets/gc-cluster-agents (3).png
deleted file mode 100644
index a9f46638ae..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents-details (1).png b/docs/.gitbook/assets/gc-cluster-agents-details (1).png
deleted file mode 100644
index 840e0c2b6a..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents-details (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents-details (2).png b/docs/.gitbook/assets/gc-cluster-agents-details (2).png
deleted file mode 100644
index 840e0c2b6a..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents-details (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents-details (3).png b/docs/.gitbook/assets/gc-cluster-agents-details (3).png
deleted file mode 100644
index 840e0c2b6a..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents-details (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents-details (4).png b/docs/.gitbook/assets/gc-cluster-agents-details (4).png
deleted file mode 100644
index 840e0c2b6a..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents-details (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents-details (5).png b/docs/.gitbook/assets/gc-cluster-agents-details (5).png
deleted file mode 100644
index 840e0c2b6a..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents-details (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents-details (6).png b/docs/.gitbook/assets/gc-cluster-agents-details (6).png
deleted file mode 100644
index 840e0c2b6a..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents-details (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents-details.png b/docs/.gitbook/assets/gc-cluster-agents-details.png
deleted file mode 100644
index 840e0c2b6a..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents-details.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-agents.png b/docs/.gitbook/assets/gc-cluster-agents.png
deleted file mode 100644
index a9f46638ae..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-agents.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (1).png b/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (1).png
deleted file mode 100644
index 43535e0441..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (2).png b/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (2).png
deleted file mode 100644
index 43535e0441..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (3).png b/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (3).png
deleted file mode 100644
index 43535e0441..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (4).png b/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (4).png
deleted file mode 100644
index 43535e0441..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-update-environment (1) (2) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-update-environment (1) (2).png b/docs/.gitbook/assets/gc-cluster-update-environment (1) (2).png
deleted file mode 100644
index 43535e0441..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-update-environment (1) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-cluster-update-environment (1).png b/docs/.gitbook/assets/gc-cluster-update-environment (1).png
deleted file mode 100644
index 43535e0441..0000000000
Binary files a/docs/.gitbook/assets/gc-cluster-update-environment (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-add (3) (1).png b/docs/.gitbook/assets/gc-docker-add (3) (1).png
deleted file mode 100644
index 555de5f6d7..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-add (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-add (3) (2).png b/docs/.gitbook/assets/gc-docker-add (3) (2).png
deleted file mode 100644
index 555de5f6d7..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-add (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-add (3) (3).png b/docs/.gitbook/assets/gc-docker-add (3) (3).png
deleted file mode 100644
index 555de5f6d7..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-add (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-add (3) (4).png b/docs/.gitbook/assets/gc-docker-add (3) (4).png
deleted file mode 100644
index 555de5f6d7..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-add (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-add (3).png b/docs/.gitbook/assets/gc-docker-add (3).png
deleted file mode 100644
index 555de5f6d7..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-add (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-aws (1).png b/docs/.gitbook/assets/gc-docker-configure-aws (1).png
deleted file mode 100644
index e5efe105fe..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-aws (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-aws (2).png b/docs/.gitbook/assets/gc-docker-configure-aws (2).png
deleted file mode 100644
index e5efe105fe..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-aws (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-aws (3).png b/docs/.gitbook/assets/gc-docker-configure-aws (3).png
deleted file mode 100644
index e5efe105fe..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-aws (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-aws (4).png b/docs/.gitbook/assets/gc-docker-configure-aws (4).png
deleted file mode 100644
index e5efe105fe..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-aws (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-aws (5).png b/docs/.gitbook/assets/gc-docker-configure-aws (5).png
deleted file mode 100644
index e5efe105fe..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-aws (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-aws (6).png b/docs/.gitbook/assets/gc-docker-configure-aws (6).png
deleted file mode 100644
index e5efe105fe..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-aws (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-aws (7).png b/docs/.gitbook/assets/gc-docker-configure-aws (7).png
deleted file mode 100644
index e5efe105fe..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-aws (7).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-aws.png b/docs/.gitbook/assets/gc-docker-configure-aws.png
deleted file mode 100644
index e5efe105fe..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-aws.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-docker-hub.png b/docs/.gitbook/assets/gc-docker-configure-docker-hub.png
deleted file mode 100644
index e88d447b80..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-docker-hub.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-gcr.png b/docs/.gitbook/assets/gc-docker-configure-gcr.png
deleted file mode 100644
index dd8c2a2621..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-gcr.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-other (2).png b/docs/.gitbook/assets/gc-docker-configure-other (2).png
deleted file mode 100644
index 7c0e42c958..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-other (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-other (3) (1).png b/docs/.gitbook/assets/gc-docker-configure-other (3) (1).png
deleted file mode 100644
index 08f95215b0..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-other (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-other (3) (2).png b/docs/.gitbook/assets/gc-docker-configure-other (3) (2).png
deleted file mode 100644
index 08f95215b0..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-other (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-other (3) (3).png b/docs/.gitbook/assets/gc-docker-configure-other (3) (3).png
deleted file mode 100644
index 08f95215b0..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-other (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-other (3) (4).png b/docs/.gitbook/assets/gc-docker-configure-other (3) (4).png
deleted file mode 100644
index 08f95215b0..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-other (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-other (3) (5).png b/docs/.gitbook/assets/gc-docker-configure-other (3) (5).png
deleted file mode 100644
index 08f95215b0..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-other (3) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-other (3) (6).png b/docs/.gitbook/assets/gc-docker-configure-other (3) (6).png
deleted file mode 100644
index 08f95215b0..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-other (3) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-docker-configure-other (3).png b/docs/.gitbook/assets/gc-docker-configure-other (3).png
deleted file mode 100644
index 08f95215b0..0000000000
Binary files a/docs/.gitbook/assets/gc-docker-configure-other (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-edit-chart.png b/docs/.gitbook/assets/gc-edit-chart.png
deleted file mode 100644
index cc0de6e0e3..0000000000
Binary files a/docs/.gitbook/assets/gc-edit-chart.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure (3).png b/docs/.gitbook/assets/gc-git-account-configure (3).png
deleted file mode 100644
index 7716dba60d..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure (4) (1).png b/docs/.gitbook/assets/gc-git-account-configure (4) (1).png
deleted file mode 100644
index 7716dba60d..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure (4) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure (4) (2).png b/docs/.gitbook/assets/gc-git-account-configure (4) (2).png
deleted file mode 100644
index 7716dba60d..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure (4) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure (4) (3).png b/docs/.gitbook/assets/gc-git-account-configure (4) (3).png
deleted file mode 100644
index 7716dba60d..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure (4) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure (4) (4).png b/docs/.gitbook/assets/gc-git-account-configure (4) (4).png
deleted file mode 100644
index 7716dba60d..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure (4) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure (4) (5).png b/docs/.gitbook/assets/gc-git-account-configure (4) (5).png
deleted file mode 100644
index 7716dba60d..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure (4) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure (4) (6).png b/docs/.gitbook/assets/gc-git-account-configure (4) (6).png
deleted file mode 100644
index 7716dba60d..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure (4) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure (4) (7).png b/docs/.gitbook/assets/gc-git-account-configure (4) (7).png
deleted file mode 100644
index 7716dba60d..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure (4) (7).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure (4).png b/docs/.gitbook/assets/gc-git-account-configure (4).png
deleted file mode 100644
index 7716dba60d..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-password (1).png b/docs/.gitbook/assets/gc-git-account-configure-password (1).png
deleted file mode 100644
index 2b45ad3345..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-password (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-password (2).png b/docs/.gitbook/assets/gc-git-account-configure-password (2).png
deleted file mode 100644
index 2b45ad3345..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-password (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-password (3).png b/docs/.gitbook/assets/gc-git-account-configure-password (3).png
deleted file mode 100644
index 2b45ad3345..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-password (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-password (4).png b/docs/.gitbook/assets/gc-git-account-configure-password (4).png
deleted file mode 100644
index 2b45ad3345..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-password (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-password (5).png b/docs/.gitbook/assets/gc-git-account-configure-password (5).png
deleted file mode 100644
index 2b45ad3345..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-password (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-password (6).png b/docs/.gitbook/assets/gc-git-account-configure-password (6).png
deleted file mode 100644
index 2b45ad3345..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-password (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-password (7).png b/docs/.gitbook/assets/gc-git-account-configure-password (7).png
deleted file mode 100644
index 2b45ad3345..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-password (7).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-password.png b/docs/.gitbook/assets/gc-git-account-configure-password.png
deleted file mode 100644
index 2b45ad3345..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-password.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (1).png b/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (1).png
deleted file mode 100644
index d7bb5c7a4b..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (2).png b/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (2).png
deleted file mode 100644
index d7bb5c7a4b..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (3).png b/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (3).png
deleted file mode 100644
index d7bb5c7a4b..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (4).png b/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (4).png
deleted file mode 100644
index d7bb5c7a4b..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (5).png b/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (5).png
deleted file mode 100644
index d7bb5c7a4b..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (6).png b/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (6).png
deleted file mode 100644
index d7bb5c7a4b..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (7).png b/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (7).png
deleted file mode 100644
index d7bb5c7a4b..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4) (7).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4).png b/docs/.gitbook/assets/gc-git-account-configure-user-auth (4).png
deleted file mode 100644
index d7bb5c7a4b..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-user-auth (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-git-account-configure-user-auth.png b/docs/.gitbook/assets/gc-git-account-configure-user-auth.png
deleted file mode 100644
index d7bb5c7a4b..0000000000
Binary files a/docs/.gitbook/assets/gc-git-account-configure-user-auth.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-gitops-provider.png b/docs/.gitbook/assets/gc-gitops-provider.png
deleted file mode 100644
index e0410131bd..0000000000
Binary files a/docs/.gitbook/assets/gc-gitops-provider.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-gitops-save.png b/docs/.gitbook/assets/gc-gitops-save.png
deleted file mode 100644
index 35101ae0f0..0000000000
Binary files a/docs/.gitbook/assets/gc-gitops-save.png and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification (3) (1).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification (3) (1).jpg
deleted file mode 100644
index 9a8244e5c3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification (3) (2).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification (3) (2).jpg
deleted file mode 100644
index 9a8244e5c3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification (3) (3).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification (3) (3).jpg
deleted file mode 100644
index 9a8244e5c3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification (3) (4).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification (3) (4).jpg
deleted file mode 100644
index 9a8244e5c3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification (3) (5).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification (3) (5).jpg
deleted file mode 100644
index 9a8244e5c3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification (3).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification (3).jpg
deleted file mode 100644
index 9a8244e5c3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (1).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (1).jpg
deleted file mode 100644
index 87cb86ebfc..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (2).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (2).jpg
deleted file mode 100644
index 87cb86ebfc..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (3).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (3).jpg
deleted file mode 100644
index 87cb86ebfc..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (4).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (4).jpg
deleted file mode 100644
index 87cb86ebfc..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (5).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (5).jpg
deleted file mode 100644
index 87cb86ebfc..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event.jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event.jpg
deleted file mode 100644
index 87cb86ebfc..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (1).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (1).jpg
deleted file mode 100644
index db9e313880..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (2).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (2).jpg
deleted file mode 100644
index db9e313880..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (3).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (3).jpg
deleted file mode 100644
index db9e313880..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (4).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (4).jpg
deleted file mode 100644
index db9e313880..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (5).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (5).jpg
deleted file mode 100644
index db9e313880..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (6).jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (6).jpg
deleted file mode 100644
index db9e313880..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2 (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2.jpg b/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2.jpg
deleted file mode 100644
index db9e313880..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-add-notification-configuration-select-event2.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (1).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (1).jpg
deleted file mode 100644
index d4719595e8..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (2).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (2).jpg
deleted file mode 100644
index d4719595e8..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (3).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (3).jpg
deleted file mode 100644
index d4719595e8..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (4).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (4).jpg
deleted file mode 100644
index d4719595e8..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2).jpg
deleted file mode 100644
index d4719595e8..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (1).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (1).jpg
deleted file mode 100644
index 95897b3c40..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (2).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (2).jpg
deleted file mode 100644
index 95897b3c40..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (3).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (3).jpg
deleted file mode 100644
index 95897b3c40..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (4).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (4).jpg
deleted file mode 100644
index 95897b3c40..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (5).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (5).jpg
deleted file mode 100644
index 95897b3c40..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack.jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack.jpg
deleted file mode 100644
index 95897b3c40..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add-slack.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-add.jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-add.jpg
deleted file mode 100644
index d4719595e8..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-add.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (1).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (1).jpg
deleted file mode 100644
index 82eebc4eb6..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (2).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (2).jpg
deleted file mode 100644
index 82eebc4eb6..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (3).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (3).jpg
deleted file mode 100644
index 82eebc4eb6..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (4).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (4).jpg
deleted file mode 100644
index 82eebc4eb6..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (5).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (5).jpg
deleted file mode 100644
index 82eebc4eb6..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack.jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack.jpg
deleted file mode 100644
index 82eebc4eb6..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-configure-slack.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (1).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (1).jpg
deleted file mode 100644
index ec208171f3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (2).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (2).jpg
deleted file mode 100644
index ec208171f3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (3).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (3).jpg
deleted file mode 100644
index ec208171f3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (4).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (4).jpg
deleted file mode 100644
index ec208171f3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (5).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (5).jpg
deleted file mode 100644
index ec208171f3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3).jpg
deleted file mode 100644
index ec208171f3..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-ses-confige (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (1).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (1).jpg
deleted file mode 100644
index bb3dc5d3a9..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (1).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (1).jpg
deleted file mode 100644
index bb3dc5d3a9..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (2).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (2).jpg
deleted file mode 100644
index bb3dc5d3a9..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (3).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (3).jpg
deleted file mode 100644
index bb3dc5d3a9..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (4).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (4).jpg
deleted file mode 100644
index bb3dc5d3a9..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (5).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (5).jpg
deleted file mode 100644
index bb3dc5d3a9..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (6).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (6).jpg
deleted file mode 100644
index bb3dc5d3a9..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3) (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3).jpg b/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3).jpg
deleted file mode 100644
index bb3dc5d3a9..0000000000
Binary files a/docs/.gitbook/assets/gc-noitfication-condfiguration-tab (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/git-accounts-1.png b/docs/.gitbook/assets/git-accounts-1.png
deleted file mode 100644
index 91eddbc890..0000000000
Binary files a/docs/.gitbook/assets/git-accounts-1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/git-accounts-2.png b/docs/.gitbook/assets/git-accounts-2.png
deleted file mode 100644
index 1a7eec1998..0000000000
Binary files a/docs/.gitbook/assets/git-accounts-2.png and /dev/null differ
diff --git a/docs/.gitbook/assets/git-accounts-3.png b/docs/.gitbook/assets/git-accounts-3.png
deleted file mode 100644
index 59f9342e3a..0000000000
Binary files a/docs/.gitbook/assets/git-accounts-3.png and /dev/null differ
diff --git a/docs/.gitbook/assets/git-accounts-4.png b/docs/.gitbook/assets/git-accounts-4.png
deleted file mode 100644
index 76909345cd..0000000000
Binary files a/docs/.gitbook/assets/git-accounts-4.png and /dev/null differ
diff --git a/docs/.gitbook/assets/git-accounts-5.png b/docs/.gitbook/assets/git-accounts-5.png
deleted file mode 100644
index a1ddb3d225..0000000000
Binary files a/docs/.gitbook/assets/git-accounts-5.png and /dev/null differ
diff --git a/docs/.gitbook/assets/git-accounts-6.png b/docs/.gitbook/assets/git-accounts-6.png
deleted file mode 100644
index 44675004cc..0000000000
Binary files a/docs/.gitbook/assets/git-accounts-6.png and /dev/null differ
diff --git a/docs/.gitbook/assets/git-checkout-path (1).jpg b/docs/.gitbook/assets/git-checkout-path (1).jpg
deleted file mode 100644
index c0bf3d25c2..0000000000
Binary files a/docs/.gitbook/assets/git-checkout-path (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/git-checkout-path (2).jpg b/docs/.gitbook/assets/git-checkout-path (2).jpg
deleted file mode 100644
index c0bf3d25c2..0000000000
Binary files a/docs/.gitbook/assets/git-checkout-path (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/git-checkout-path (3).jpg b/docs/.gitbook/assets/git-checkout-path (3).jpg
deleted file mode 100644
index c0bf3d25c2..0000000000
Binary files a/docs/.gitbook/assets/git-checkout-path (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/git-checkout-path (4).jpg b/docs/.gitbook/assets/git-checkout-path (4).jpg
deleted file mode 100644
index c0bf3d25c2..0000000000
Binary files a/docs/.gitbook/assets/git-checkout-path (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/git-checkout-path (5).jpg b/docs/.gitbook/assets/git-checkout-path (5).jpg
deleted file mode 100644
index c0bf3d25c2..0000000000
Binary files a/docs/.gitbook/assets/git-checkout-path (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/git-checkout-path.jpg b/docs/.gitbook/assets/git-checkout-path.jpg
deleted file mode 100644
index c0bf3d25c2..0000000000
Binary files a/docs/.gitbook/assets/git-checkout-path.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/git_account_gc3 (3).png b/docs/.gitbook/assets/git_account_gc3 (3).png
deleted file mode 100644
index 2b45ad3345..0000000000
Binary files a/docs/.gitbook/assets/git_account_gc3 (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/git_account_gc5 (4) (1).png b/docs/.gitbook/assets/git_account_gc5 (4) (1).png
deleted file mode 100644
index 97b596c545..0000000000
Binary files a/docs/.gitbook/assets/git_account_gc5 (4) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/git_account_gc5 (4) (2).png b/docs/.gitbook/assets/git_account_gc5 (4) (2).png
deleted file mode 100644
index 97b596c545..0000000000
Binary files a/docs/.gitbook/assets/git_account_gc5 (4) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/git_account_gc5 (4) (3).png b/docs/.gitbook/assets/git_account_gc5 (4) (3).png
deleted file mode 100644
index 97b596c545..0000000000
Binary files a/docs/.gitbook/assets/git_account_gc5 (4) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/git_account_gc5 (4) (4).png b/docs/.gitbook/assets/git_account_gc5 (4) (4).png
deleted file mode 100644
index 97b596c545..0000000000
Binary files a/docs/.gitbook/assets/git_account_gc5 (4) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/git_account_gc5 (4) (5).png b/docs/.gitbook/assets/git_account_gc5 (4) (5).png
deleted file mode 100644
index 97b596c545..0000000000
Binary files a/docs/.gitbook/assets/git_account_gc5 (4) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/git_account_gc5 (4) (6).png b/docs/.gitbook/assets/git_account_gc5 (4) (6).png
deleted file mode 100644
index 97b596c545..0000000000
Binary files a/docs/.gitbook/assets/git_account_gc5 (4) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/git_account_gc5 (4) (7).png b/docs/.gitbook/assets/git_account_gc5 (4) (7).png
deleted file mode 100644
index 97b596c545..0000000000
Binary files a/docs/.gitbook/assets/git_account_gc5 (4) (7).png and /dev/null differ
diff --git a/docs/.gitbook/assets/git_account_gc5 (4).png b/docs/.gitbook/assets/git_account_gc5 (4).png
deleted file mode 100644
index 97b596c545..0000000000
Binary files a/docs/.gitbook/assets/git_account_gc5 (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/git_account_gc5.png b/docs/.gitbook/assets/git_account_gc5.png
deleted file mode 100644
index 97b596c545..0000000000
Binary files a/docs/.gitbook/assets/git_account_gc5.png and /dev/null differ
diff --git a/docs/.gitbook/assets/git_material2 (3).jpg b/docs/.gitbook/assets/git_material2 (3).jpg
deleted file mode 100644
index c0bf3d25c2..0000000000
Binary files a/docs/.gitbook/assets/git_material2 (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/github_url (2) (2) (1).png b/docs/.gitbook/assets/github_url (2) (2) (1).png
deleted file mode 100644
index 3b45a16e0a..0000000000
Binary files a/docs/.gitbook/assets/github_url (2) (2) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/github_url (2) (2) (2).png b/docs/.gitbook/assets/github_url (2) (2) (2).png
deleted file mode 100644
index 3b45a16e0a..0000000000
Binary files a/docs/.gitbook/assets/github_url (2) (2) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/github_url (2) (2) (3).png b/docs/.gitbook/assets/github_url (2) (2) (3).png
deleted file mode 100644
index 3b45a16e0a..0000000000
Binary files a/docs/.gitbook/assets/github_url (2) (2) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/github_url (2) (2) (4).png b/docs/.gitbook/assets/github_url (2) (2) (4).png
deleted file mode 100644
index 3b45a16e0a..0000000000
Binary files a/docs/.gitbook/assets/github_url (2) (2) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/github_url (2) (2).png b/docs/.gitbook/assets/github_url (2) (2).png
deleted file mode 100644
index 3b45a16e0a..0000000000
Binary files a/docs/.gitbook/assets/github_url (2) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/github_url (2).png b/docs/.gitbook/assets/github_url (2).png
deleted file mode 100644
index 3b45a16e0a..0000000000
Binary files a/docs/.gitbook/assets/github_url (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/linked (3) (1).jpg b/docs/.gitbook/assets/linked (3) (1).jpg
deleted file mode 100644
index d185f51906..0000000000
Binary files a/docs/.gitbook/assets/linked (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/linked (3) (2).jpg b/docs/.gitbook/assets/linked (3) (2).jpg
deleted file mode 100644
index d185f51906..0000000000
Binary files a/docs/.gitbook/assets/linked (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/linked (3) (3).jpg b/docs/.gitbook/assets/linked (3) (3).jpg
deleted file mode 100644
index d185f51906..0000000000
Binary files a/docs/.gitbook/assets/linked (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/linked (3) (4).jpg b/docs/.gitbook/assets/linked (3) (4).jpg
deleted file mode 100644
index d185f51906..0000000000
Binary files a/docs/.gitbook/assets/linked (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/linked (3) (5).jpg b/docs/.gitbook/assets/linked (3) (5).jpg
deleted file mode 100644
index d185f51906..0000000000
Binary files a/docs/.gitbook/assets/linked (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/linked (3).jpg b/docs/.gitbook/assets/linked (3).jpg
deleted file mode 100644
index d185f51906..0000000000
Binary files a/docs/.gitbook/assets/linked (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo (1).jpg b/docs/.gitbook/assets/mongo (1).jpg
deleted file mode 100644
index d1ab56f9eb..0000000000
Binary files a/docs/.gitbook/assets/mongo (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo (2).jpg b/docs/.gitbook/assets/mongo (2).jpg
deleted file mode 100644
index d1ab56f9eb..0000000000
Binary files a/docs/.gitbook/assets/mongo (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo (3).jpg b/docs/.gitbook/assets/mongo (3).jpg
deleted file mode 100644
index d1ab56f9eb..0000000000
Binary files a/docs/.gitbook/assets/mongo (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo (4).jpg b/docs/.gitbook/assets/mongo (4).jpg
deleted file mode 100644
index d1ab56f9eb..0000000000
Binary files a/docs/.gitbook/assets/mongo (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo (5).jpg b/docs/.gitbook/assets/mongo (5).jpg
deleted file mode 100644
index d1ab56f9eb..0000000000
Binary files a/docs/.gitbook/assets/mongo (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo (6).jpg b/docs/.gitbook/assets/mongo (6).jpg
deleted file mode 100644
index d1ab56f9eb..0000000000
Binary files a/docs/.gitbook/assets/mongo (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo.jpg b/docs/.gitbook/assets/mongo.jpg
deleted file mode 100644
index d1ab56f9eb..0000000000
Binary files a/docs/.gitbook/assets/mongo.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo1 (2) (1).jpg b/docs/.gitbook/assets/mongo1 (2) (1).jpg
deleted file mode 100644
index 37600876da..0000000000
Binary files a/docs/.gitbook/assets/mongo1 (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo1 (2) (2).jpg b/docs/.gitbook/assets/mongo1 (2) (2).jpg
deleted file mode 100644
index 37600876da..0000000000
Binary files a/docs/.gitbook/assets/mongo1 (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo1 (2) (3).jpg b/docs/.gitbook/assets/mongo1 (2) (3).jpg
deleted file mode 100644
index 37600876da..0000000000
Binary files a/docs/.gitbook/assets/mongo1 (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo1 (2) (4).jpg b/docs/.gitbook/assets/mongo1 (2) (4).jpg
deleted file mode 100644
index 37600876da..0000000000
Binary files a/docs/.gitbook/assets/mongo1 (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo1 (2).jpg b/docs/.gitbook/assets/mongo1 (2).jpg
deleted file mode 100644
index 37600876da..0000000000
Binary files a/docs/.gitbook/assets/mongo1 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo4 (1) (1).png b/docs/.gitbook/assets/mongo4 (1) (1).png
deleted file mode 100644
index a152264bb9..0000000000
Binary files a/docs/.gitbook/assets/mongo4 (1) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo4 (1) (2).png b/docs/.gitbook/assets/mongo4 (1) (2).png
deleted file mode 100644
index a152264bb9..0000000000
Binary files a/docs/.gitbook/assets/mongo4 (1) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo4 (1).png b/docs/.gitbook/assets/mongo4 (1).png
deleted file mode 100644
index a152264bb9..0000000000
Binary files a/docs/.gitbook/assets/mongo4 (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo6 (1) (1).png b/docs/.gitbook/assets/mongo6 (1) (1).png
deleted file mode 100644
index d897884972..0000000000
Binary files a/docs/.gitbook/assets/mongo6 (1) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/mongo6 (1).png b/docs/.gitbook/assets/mongo6 (1).png
deleted file mode 100644
index d897884972..0000000000
Binary files a/docs/.gitbook/assets/mongo6 (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/move1 (3).gif b/docs/.gitbook/assets/move1 (3).gif
deleted file mode 100644
index ac71ed7b8e..0000000000
Binary files a/docs/.gitbook/assets/move1 (3).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/mysql (1).jpg b/docs/.gitbook/assets/mysql (1).jpg
deleted file mode 100644
index eb6219f0e0..0000000000
Binary files a/docs/.gitbook/assets/mysql (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mysql (2).jpg b/docs/.gitbook/assets/mysql (2).jpg
deleted file mode 100644
index eb6219f0e0..0000000000
Binary files a/docs/.gitbook/assets/mysql (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mysql (3).jpg b/docs/.gitbook/assets/mysql (3).jpg
deleted file mode 100644
index eb6219f0e0..0000000000
Binary files a/docs/.gitbook/assets/mysql (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mysql (4).jpg b/docs/.gitbook/assets/mysql (4).jpg
deleted file mode 100644
index eb6219f0e0..0000000000
Binary files a/docs/.gitbook/assets/mysql (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mysql (5).jpg b/docs/.gitbook/assets/mysql (5).jpg
deleted file mode 100644
index eb6219f0e0..0000000000
Binary files a/docs/.gitbook/assets/mysql (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mysql (6).jpg b/docs/.gitbook/assets/mysql (6).jpg
deleted file mode 100644
index eb6219f0e0..0000000000
Binary files a/docs/.gitbook/assets/mysql (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/mysql.jpg b/docs/.gitbook/assets/mysql.jpg
deleted file mode 100644
index eb6219f0e0..0000000000
Binary files a/docs/.gitbook/assets/mysql.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/not9 (2).jpg b/docs/.gitbook/assets/not9 (2).jpg
deleted file mode 100644
index db9e313880..0000000000
Binary files a/docs/.gitbook/assets/not9 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (4).jpg b/docs/.gitbook/assets/notifi6 (1) (4).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (1).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (1).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (10).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (10).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (10).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (11).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (11).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (11).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (12).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (12).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (12).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (13).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (13).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (13).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (2).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (2).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (3).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (3).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (4).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (4).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (5).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (5).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (6).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (6).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (7).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (7).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (8).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (8).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (8).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7) (9).jpg b/docs/.gitbook/assets/notifi6 (1) (7) (9).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7) (9).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1) (7).jpg b/docs/.gitbook/assets/notifi6 (1) (7).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1) (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/notifi6 (1).jpg b/docs/.gitbook/assets/notifi6 (1).jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/.gitbook/assets/notifi6 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/post_build (1).jpg b/docs/.gitbook/assets/post_build (1).jpg
deleted file mode 100644
index 398d64920d..0000000000
Binary files a/docs/.gitbook/assets/post_build (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/post_build (2).jpg b/docs/.gitbook/assets/post_build (2).jpg
deleted file mode 100644
index 398d64920d..0000000000
Binary files a/docs/.gitbook/assets/post_build (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/post_build (3).jpg b/docs/.gitbook/assets/post_build (3).jpg
deleted file mode 100644
index 398d64920d..0000000000
Binary files a/docs/.gitbook/assets/post_build (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/post_build (4).jpg b/docs/.gitbook/assets/post_build (4).jpg
deleted file mode 100644
index 398d64920d..0000000000
Binary files a/docs/.gitbook/assets/post_build (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/post_build (5).jpg b/docs/.gitbook/assets/post_build (5).jpg
deleted file mode 100644
index 398d64920d..0000000000
Binary files a/docs/.gitbook/assets/post_build (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/post_build.jpg b/docs/.gitbook/assets/post_build.jpg
deleted file mode 100644
index 398d64920d..0000000000
Binary files a/docs/.gitbook/assets/post_build.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/pre_build (1).jpg b/docs/.gitbook/assets/pre_build (1).jpg
deleted file mode 100644
index 759c0a7b87..0000000000
Binary files a/docs/.gitbook/assets/pre_build (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/pre_build (2).jpg b/docs/.gitbook/assets/pre_build (2).jpg
deleted file mode 100644
index 759c0a7b87..0000000000
Binary files a/docs/.gitbook/assets/pre_build (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/pre_build (3).jpg b/docs/.gitbook/assets/pre_build (3).jpg
deleted file mode 100644
index 759c0a7b87..0000000000
Binary files a/docs/.gitbook/assets/pre_build (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/pre_build (4).jpg b/docs/.gitbook/assets/pre_build (4).jpg
deleted file mode 100644
index 759c0a7b87..0000000000
Binary files a/docs/.gitbook/assets/pre_build (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/pre_build (5).jpg b/docs/.gitbook/assets/pre_build (5).jpg
deleted file mode 100644
index 759c0a7b87..0000000000
Binary files a/docs/.gitbook/assets/pre_build (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/pre_build (6).jpg b/docs/.gitbook/assets/pre_build (6).jpg
deleted file mode 100644
index 759c0a7b87..0000000000
Binary files a/docs/.gitbook/assets/pre_build (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/pre_build (7).jpg b/docs/.gitbook/assets/pre_build (7).jpg
deleted file mode 100644
index 759c0a7b87..0000000000
Binary files a/docs/.gitbook/assets/pre_build (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/pre_build.jpg b/docs/.gitbook/assets/pre_build.jpg
deleted file mode 100644
index 759c0a7b87..0000000000
Binary files a/docs/.gitbook/assets/pre_build.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/preview (1) (1) (1).gif b/docs/.gitbook/assets/preview (1) (1) (1).gif
deleted file mode 100644
index ac26e8a222..0000000000
Binary files a/docs/.gitbook/assets/preview (1) (1) (1).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/preview (1) (1) (2).gif b/docs/.gitbook/assets/preview (1) (1) (2).gif
deleted file mode 100644
index ac26e8a222..0000000000
Binary files a/docs/.gitbook/assets/preview (1) (1) (2).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/preview (1) (1) (3).gif b/docs/.gitbook/assets/preview (1) (1) (3).gif
deleted file mode 100644
index ac26e8a222..0000000000
Binary files a/docs/.gitbook/assets/preview (1) (1) (3).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/preview (1) (1) (4).gif b/docs/.gitbook/assets/preview (1) (1) (4).gif
deleted file mode 100644
index ac26e8a222..0000000000
Binary files a/docs/.gitbook/assets/preview (1) (1) (4).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/preview (1) (2).gif b/docs/.gitbook/assets/preview (1) (2).gif
deleted file mode 100644
index ac26e8a222..0000000000
Binary files a/docs/.gitbook/assets/preview (1) (2).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/preview.gif b/docs/.gitbook/assets/preview.gif
deleted file mode 100644
index ac26e8a222..0000000000
Binary files a/docs/.gitbook/assets/preview.gif and /dev/null differ
diff --git a/docs/.gitbook/assets/project_gc1 (3) (1).png b/docs/.gitbook/assets/project_gc1 (3) (1).png
deleted file mode 100644
index 470fdc831f..0000000000
Binary files a/docs/.gitbook/assets/project_gc1 (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/project_gc1 (3) (2).png b/docs/.gitbook/assets/project_gc1 (3) (2).png
deleted file mode 100644
index 470fdc831f..0000000000
Binary files a/docs/.gitbook/assets/project_gc1 (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/project_gc1 (3) (3).png b/docs/.gitbook/assets/project_gc1 (3) (3).png
deleted file mode 100644
index 470fdc831f..0000000000
Binary files a/docs/.gitbook/assets/project_gc1 (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/project_gc1 (3) (4).png b/docs/.gitbook/assets/project_gc1 (3) (4).png
deleted file mode 100644
index 470fdc831f..0000000000
Binary files a/docs/.gitbook/assets/project_gc1 (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/project_gc1 (3) (5).png b/docs/.gitbook/assets/project_gc1 (3) (5).png
deleted file mode 100644
index 470fdc831f..0000000000
Binary files a/docs/.gitbook/assets/project_gc1 (3) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/project_gc1 (3).png b/docs/.gitbook/assets/project_gc1 (3).png
deleted file mode 100644
index 470fdc831f..0000000000
Binary files a/docs/.gitbook/assets/project_gc1 (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/screen2 (1).jpg b/docs/.gitbook/assets/screen2 (1).jpg
deleted file mode 100644
index c3d05b9280..0000000000
Binary files a/docs/.gitbook/assets/screen2 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/screen2 (2).jpg b/docs/.gitbook/assets/screen2 (2).jpg
deleted file mode 100644
index c3d05b9280..0000000000
Binary files a/docs/.gitbook/assets/screen2 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/screen2 (3).jpg b/docs/.gitbook/assets/screen2 (3).jpg
deleted file mode 100644
index c3d05b9280..0000000000
Binary files a/docs/.gitbook/assets/screen2 (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/screen2 (4).jpg b/docs/.gitbook/assets/screen2 (4).jpg
deleted file mode 100644
index c3d05b9280..0000000000
Binary files a/docs/.gitbook/assets/screen2 (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/screen2 (5).jpg b/docs/.gitbook/assets/screen2 (5).jpg
deleted file mode 100644
index c3d05b9280..0000000000
Binary files a/docs/.gitbook/assets/screen2 (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/screen2 (6).jpg b/docs/.gitbook/assets/screen2 (6).jpg
deleted file mode 100644
index c3d05b9280..0000000000
Binary files a/docs/.gitbook/assets/screen2 (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/screen2.jpg b/docs/.gitbook/assets/screen2.jpg
deleted file mode 100644
index c3d05b9280..0000000000
Binary files a/docs/.gitbook/assets/screen2.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/second (2) (1).jpg b/docs/.gitbook/assets/second (2) (1).jpg
deleted file mode 100644
index b922858455..0000000000
Binary files a/docs/.gitbook/assets/second (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/second (2) (2).jpg b/docs/.gitbook/assets/second (2) (2).jpg
deleted file mode 100644
index b922858455..0000000000
Binary files a/docs/.gitbook/assets/second (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/second (2) (3).jpg b/docs/.gitbook/assets/second (2) (3).jpg
deleted file mode 100644
index b922858455..0000000000
Binary files a/docs/.gitbook/assets/second (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/second (2).jpg b/docs/.gitbook/assets/second (2).jpg
deleted file mode 100644
index b922858455..0000000000
Binary files a/docs/.gitbook/assets/second (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-created (3) (1).png b/docs/.gitbook/assets/secret-created (3) (1).png
deleted file mode 100644
index 091c44a84d..0000000000
Binary files a/docs/.gitbook/assets/secret-created (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-created (3) (2).png b/docs/.gitbook/assets/secret-created (3) (2).png
deleted file mode 100644
index 091c44a84d..0000000000
Binary files a/docs/.gitbook/assets/secret-created (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-created (3) (3).png b/docs/.gitbook/assets/secret-created (3) (3).png
deleted file mode 100644
index 091c44a84d..0000000000
Binary files a/docs/.gitbook/assets/secret-created (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-created (3) (4).png b/docs/.gitbook/assets/secret-created (3) (4).png
deleted file mode 100644
index 091c44a84d..0000000000
Binary files a/docs/.gitbook/assets/secret-created (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-created (3) (5).png b/docs/.gitbook/assets/secret-created (3) (5).png
deleted file mode 100644
index 091c44a84d..0000000000
Binary files a/docs/.gitbook/assets/secret-created (3) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-created (3) (6).png b/docs/.gitbook/assets/secret-created (3) (6).png
deleted file mode 100644
index 091c44a84d..0000000000
Binary files a/docs/.gitbook/assets/secret-created (3) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-created (3).png b/docs/.gitbook/assets/secret-created (3).png
deleted file mode 100644
index 091c44a84d..0000000000
Binary files a/docs/.gitbook/assets/secret-created (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-volume-path (1).jpg b/docs/.gitbook/assets/secret-volume-path (1).jpg
deleted file mode 100644
index d49111d1e6..0000000000
Binary files a/docs/.gitbook/assets/secret-volume-path (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-volume-path (2).jpg b/docs/.gitbook/assets/secret-volume-path (2).jpg
deleted file mode 100644
index d49111d1e6..0000000000
Binary files a/docs/.gitbook/assets/secret-volume-path (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-volume-path (3).jpg b/docs/.gitbook/assets/secret-volume-path (3).jpg
deleted file mode 100644
index d49111d1e6..0000000000
Binary files a/docs/.gitbook/assets/secret-volume-path (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-volume-path (4).jpg b/docs/.gitbook/assets/secret-volume-path (4).jpg
deleted file mode 100644
index d49111d1e6..0000000000
Binary files a/docs/.gitbook/assets/secret-volume-path (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-volume-path (5).jpg b/docs/.gitbook/assets/secret-volume-path (5).jpg
deleted file mode 100644
index d49111d1e6..0000000000
Binary files a/docs/.gitbook/assets/secret-volume-path (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-volume-path (6).jpg b/docs/.gitbook/assets/secret-volume-path (6).jpg
deleted file mode 100644
index d49111d1e6..0000000000
Binary files a/docs/.gitbook/assets/secret-volume-path (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/secret-volume-path.jpg b/docs/.gitbook/assets/secret-volume-path.jpg
deleted file mode 100644
index d49111d1e6..0000000000
Binary files a/docs/.gitbook/assets/secret-volume-path.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/secret3.jpg b/docs/.gitbook/assets/secret3.jpg
deleted file mode 100644
index d49111d1e6..0000000000
Binary files a/docs/.gitbook/assets/secret3.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-app-details-vulnerability (1).png b/docs/.gitbook/assets/security-feature-app-details-vulnerability (1).png
deleted file mode 100644
index 8629c46d47..0000000000
Binary files a/docs/.gitbook/assets/security-feature-app-details-vulnerability (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-app-details-vulnerability (2).png b/docs/.gitbook/assets/security-feature-app-details-vulnerability (2).png
deleted file mode 100644
index 8629c46d47..0000000000
Binary files a/docs/.gitbook/assets/security-feature-app-details-vulnerability (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-app-details-vulnerability (3).png b/docs/.gitbook/assets/security-feature-app-details-vulnerability (3).png
deleted file mode 100644
index 8629c46d47..0000000000
Binary files a/docs/.gitbook/assets/security-feature-app-details-vulnerability (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-app-details-vulnerability (4).png b/docs/.gitbook/assets/security-feature-app-details-vulnerability (4).png
deleted file mode 100644
index 8629c46d47..0000000000
Binary files a/docs/.gitbook/assets/security-feature-app-details-vulnerability (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-app-details-vulnerability.png b/docs/.gitbook/assets/security-feature-app-details-vulnerability.png
deleted file mode 100644
index 8629c46d47..0000000000
Binary files a/docs/.gitbook/assets/security-feature-app-details-vulnerability.png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-build-history-security (1).png b/docs/.gitbook/assets/security-feature-build-history-security (1).png
deleted file mode 100644
index f2569c96b8..0000000000
Binary files a/docs/.gitbook/assets/security-feature-build-history-security (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-build-history-security (2).png b/docs/.gitbook/assets/security-feature-build-history-security (2).png
deleted file mode 100644
index f2569c96b8..0000000000
Binary files a/docs/.gitbook/assets/security-feature-build-history-security (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-build-history-security (3).png b/docs/.gitbook/assets/security-feature-build-history-security (3).png
deleted file mode 100644
index f2569c96b8..0000000000
Binary files a/docs/.gitbook/assets/security-feature-build-history-security (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-build-history-security (4).png b/docs/.gitbook/assets/security-feature-build-history-security (4).png
deleted file mode 100644
index f2569c96b8..0000000000
Binary files a/docs/.gitbook/assets/security-feature-build-history-security (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-build-history-security.png b/docs/.gitbook/assets/security-feature-build-history-security.png
deleted file mode 100644
index f2569c96b8..0000000000
Binary files a/docs/.gitbook/assets/security-feature-build-history-security.png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image (1).png b/docs/.gitbook/assets/security-feature-deployed-image (1).png
deleted file mode 100644
index b93511e98d..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image (2).png b/docs/.gitbook/assets/security-feature-deployed-image (2).png
deleted file mode 100644
index b93511e98d..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image (3).png b/docs/.gitbook/assets/security-feature-deployed-image (3).png
deleted file mode 100644
index b93511e98d..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (1).png b/docs/.gitbook/assets/security-feature-deployed-image-security (3) (1).png
deleted file mode 100644
index 418278859c..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (2).png b/docs/.gitbook/assets/security-feature-deployed-image-security (3) (2).png
deleted file mode 100644
index 418278859c..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (3).png b/docs/.gitbook/assets/security-feature-deployed-image-security (3) (3).png
deleted file mode 100644
index 418278859c..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (4).png b/docs/.gitbook/assets/security-feature-deployed-image-security (3) (4).png
deleted file mode 100644
index 418278859c..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (5).png b/docs/.gitbook/assets/security-feature-deployed-image-security (3) (5).png
deleted file mode 100644
index 418278859c..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (6).png b/docs/.gitbook/assets/security-feature-deployed-image-security (3) (6).png
deleted file mode 100644
index 418278859c..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image-security (3) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image-security (3).png b/docs/.gitbook/assets/security-feature-deployed-image-security (3).png
deleted file mode 100644
index 418278859c..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image-security (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image-security.png b/docs/.gitbook/assets/security-feature-deployed-image-security.png
deleted file mode 100644
index 418278859c..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image-security.png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-deployed-image.png b/docs/.gitbook/assets/security-feature-deployed-image.png
deleted file mode 100644
index b93511e98d..0000000000
Binary files a/docs/.gitbook/assets/security-feature-deployed-image.png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-global-security-policies (1).png b/docs/.gitbook/assets/security-feature-global-security-policies (1).png
deleted file mode 100644
index 5bb2289746..0000000000
Binary files a/docs/.gitbook/assets/security-feature-global-security-policies (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-global-security-policies (2).png b/docs/.gitbook/assets/security-feature-global-security-policies (2).png
deleted file mode 100644
index 5bb2289746..0000000000
Binary files a/docs/.gitbook/assets/security-feature-global-security-policies (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-global-security-policies (3).png b/docs/.gitbook/assets/security-feature-global-security-policies (3).png
deleted file mode 100644
index 5bb2289746..0000000000
Binary files a/docs/.gitbook/assets/security-feature-global-security-policies (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-global-security-policies (4).png b/docs/.gitbook/assets/security-feature-global-security-policies (4).png
deleted file mode 100644
index 5bb2289746..0000000000
Binary files a/docs/.gitbook/assets/security-feature-global-security-policies (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-global-security-policies.png b/docs/.gitbook/assets/security-feature-global-security-policies.png
deleted file mode 100644
index 5bb2289746..0000000000
Binary files a/docs/.gitbook/assets/security-feature-global-security-policies.png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (1).png b/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (1).png
deleted file mode 100644
index 017c08fa4f..0000000000
Binary files a/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (2).png b/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (2).png
deleted file mode 100644
index 017c08fa4f..0000000000
Binary files a/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (3).png b/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (3).png
deleted file mode 100644
index 017c08fa4f..0000000000
Binary files a/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (4).png b/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (4).png
deleted file mode 100644
index 017c08fa4f..0000000000
Binary files a/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2).png b/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2).png
deleted file mode 100644
index 017c08fa4f..0000000000
Binary files a/docs/.gitbook/assets/security-feature-securitytab-list-vulnerability (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (1).png b/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (1).png
deleted file mode 100644
index 93174a0307..0000000000
Binary files a/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (2).png b/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (2).png
deleted file mode 100644
index 93174a0307..0000000000
Binary files a/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (3).png b/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (3).png
deleted file mode 100644
index 93174a0307..0000000000
Binary files a/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (4).png b/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (4).png
deleted file mode 100644
index 93174a0307..0000000000
Binary files a/docs/.gitbook/assets/security-feature-securitytab-security-scan (2) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature-securitytab-security-scan (2).png b/docs/.gitbook/assets/security-feature-securitytab-security-scan (2).png
deleted file mode 100644
index 93174a0307..0000000000
Binary files a/docs/.gitbook/assets/security-feature-securitytab-security-scan (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature8 (2) (1).png b/docs/.gitbook/assets/security-feature8 (2) (1).png
deleted file mode 100644
index a533ffc703..0000000000
Binary files a/docs/.gitbook/assets/security-feature8 (2) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature8 (2) (2).png b/docs/.gitbook/assets/security-feature8 (2) (2).png
deleted file mode 100644
index a533ffc703..0000000000
Binary files a/docs/.gitbook/assets/security-feature8 (2) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature8 (2) (3).png b/docs/.gitbook/assets/security-feature8 (2) (3).png
deleted file mode 100644
index a533ffc703..0000000000
Binary files a/docs/.gitbook/assets/security-feature8 (2) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature8 (2) (4).png b/docs/.gitbook/assets/security-feature8 (2) (4).png
deleted file mode 100644
index a533ffc703..0000000000
Binary files a/docs/.gitbook/assets/security-feature8 (2) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/security-feature8 (2).png b/docs/.gitbook/assets/security-feature8 (2).png
deleted file mode 100644
index a533ffc703..0000000000
Binary files a/docs/.gitbook/assets/security-feature8 (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts (1).jpg b/docs/.gitbook/assets/select_charts (1).jpg
deleted file mode 100644
index 46f6495d7b..0000000000
Binary files a/docs/.gitbook/assets/select_charts (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts (2).jpg b/docs/.gitbook/assets/select_charts (2).jpg
deleted file mode 100644
index 46f6495d7b..0000000000
Binary files a/docs/.gitbook/assets/select_charts (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts (3).jpg b/docs/.gitbook/assets/select_charts (3).jpg
deleted file mode 100644
index 46f6495d7b..0000000000
Binary files a/docs/.gitbook/assets/select_charts (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts (4).jpg b/docs/.gitbook/assets/select_charts (4).jpg
deleted file mode 100644
index 46f6495d7b..0000000000
Binary files a/docs/.gitbook/assets/select_charts (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts (5).jpg b/docs/.gitbook/assets/select_charts (5).jpg
deleted file mode 100644
index 46f6495d7b..0000000000
Binary files a/docs/.gitbook/assets/select_charts (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts (6).jpg b/docs/.gitbook/assets/select_charts (6).jpg
deleted file mode 100644
index 46f6495d7b..0000000000
Binary files a/docs/.gitbook/assets/select_charts (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts.jpg b/docs/.gitbook/assets/select_charts.jpg
deleted file mode 100644
index 46f6495d7b..0000000000
Binary files a/docs/.gitbook/assets/select_charts.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts2 (2) (1).jpg b/docs/.gitbook/assets/select_charts2 (2) (1).jpg
deleted file mode 100644
index 6954e5d2cb..0000000000
Binary files a/docs/.gitbook/assets/select_charts2 (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts2 (2) (2).jpg b/docs/.gitbook/assets/select_charts2 (2) (2).jpg
deleted file mode 100644
index 6954e5d2cb..0000000000
Binary files a/docs/.gitbook/assets/select_charts2 (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts2 (2) (3).jpg b/docs/.gitbook/assets/select_charts2 (2) (3).jpg
deleted file mode 100644
index 6954e5d2cb..0000000000
Binary files a/docs/.gitbook/assets/select_charts2 (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts2 (2) (4).jpg b/docs/.gitbook/assets/select_charts2 (2) (4).jpg
deleted file mode 100644
index 6954e5d2cb..0000000000
Binary files a/docs/.gitbook/assets/select_charts2 (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts2 (2) (5).jpg b/docs/.gitbook/assets/select_charts2 (2) (5).jpg
deleted file mode 100644
index 6954e5d2cb..0000000000
Binary files a/docs/.gitbook/assets/select_charts2 (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts2 (2).jpg b/docs/.gitbook/assets/select_charts2 (2).jpg
deleted file mode 100644
index 6954e5d2cb..0000000000
Binary files a/docs/.gitbook/assets/select_charts2 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/select_charts2.jpg b/docs/.gitbook/assets/select_charts2.jpg
deleted file mode 100644
index 6954e5d2cb..0000000000
Binary files a/docs/.gitbook/assets/select_charts2.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/sql1 (1).png b/docs/.gitbook/assets/sql1 (1).png
deleted file mode 100644
index 313b7f3cd5..0000000000
Binary files a/docs/.gitbook/assets/sql1 (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql1 (2).png b/docs/.gitbook/assets/sql1 (2).png
deleted file mode 100644
index 313b7f3cd5..0000000000
Binary files a/docs/.gitbook/assets/sql1 (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql1 (3).png b/docs/.gitbook/assets/sql1 (3).png
deleted file mode 100644
index 313b7f3cd5..0000000000
Binary files a/docs/.gitbook/assets/sql1 (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql1 (4).png b/docs/.gitbook/assets/sql1 (4).png
deleted file mode 100644
index 313b7f3cd5..0000000000
Binary files a/docs/.gitbook/assets/sql1 (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql1 (5).png b/docs/.gitbook/assets/sql1 (5).png
deleted file mode 100644
index 313b7f3cd5..0000000000
Binary files a/docs/.gitbook/assets/sql1 (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql1 (6).png b/docs/.gitbook/assets/sql1 (6).png
deleted file mode 100644
index 313b7f3cd5..0000000000
Binary files a/docs/.gitbook/assets/sql1 (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql1.png b/docs/.gitbook/assets/sql1.png
deleted file mode 100644
index 313b7f3cd5..0000000000
Binary files a/docs/.gitbook/assets/sql1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql2 (1).png b/docs/.gitbook/assets/sql2 (1).png
deleted file mode 100644
index 9babf652b3..0000000000
Binary files a/docs/.gitbook/assets/sql2 (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql2 (2).png b/docs/.gitbook/assets/sql2 (2).png
deleted file mode 100644
index 9babf652b3..0000000000
Binary files a/docs/.gitbook/assets/sql2 (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql2 (3).png b/docs/.gitbook/assets/sql2 (3).png
deleted file mode 100644
index 9babf652b3..0000000000
Binary files a/docs/.gitbook/assets/sql2 (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql2 (4).png b/docs/.gitbook/assets/sql2 (4).png
deleted file mode 100644
index 9babf652b3..0000000000
Binary files a/docs/.gitbook/assets/sql2 (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql2 (5).png b/docs/.gitbook/assets/sql2 (5).png
deleted file mode 100644
index 9babf652b3..0000000000
Binary files a/docs/.gitbook/assets/sql2 (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql2 (6).png b/docs/.gitbook/assets/sql2 (6).png
deleted file mode 100644
index 9babf652b3..0000000000
Binary files a/docs/.gitbook/assets/sql2 (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/sql2.png b/docs/.gitbook/assets/sql2.png
deleted file mode 100644
index 9babf652b3..0000000000
Binary files a/docs/.gitbook/assets/sql2.png and /dev/null differ
diff --git a/docs/.gitbook/assets/sso-config.jpg b/docs/.gitbook/assets/sso-config.jpg
deleted file mode 100644
index eb20cbfaad..0000000000
Binary files a/docs/.gitbook/assets/sso-config.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/sso-login-1.png b/docs/.gitbook/assets/sso-login-1.png
deleted file mode 100644
index 34354eedbc..0000000000
Binary files a/docs/.gitbook/assets/sso-login-1.png and /dev/null differ
diff --git a/docs/.gitbook/assets/sso-login-2.png b/docs/.gitbook/assets/sso-login-2.png
deleted file mode 100644
index 48167c446e..0000000000
Binary files a/docs/.gitbook/assets/sso-login-2.png and /dev/null differ
diff --git a/docs/.gitbook/assets/sso-login-3.png b/docs/.gitbook/assets/sso-login-3.png
deleted file mode 100644
index 4a1ee721c2..0000000000
Binary files a/docs/.gitbook/assets/sso-login-3.png and /dev/null differ
diff --git a/docs/.gitbook/assets/sso-login-4.png b/docs/.gitbook/assets/sso-login-4.png
deleted file mode 100644
index 47ebfcc2c5..0000000000
Binary files a/docs/.gitbook/assets/sso-login-4.png and /dev/null differ
diff --git a/docs/.gitbook/assets/terminal-controls.png b/docs/.gitbook/assets/terminal-controls.png
deleted file mode 100644
index 7ee6ab4f52..0000000000
Binary files a/docs/.gitbook/assets/terminal-controls.png and /dev/null differ
diff --git a/docs/.gitbook/assets/terminal-open.png b/docs/.gitbook/assets/terminal-open.png
deleted file mode 100644
index be3c1abb63..0000000000
Binary files a/docs/.gitbook/assets/terminal-open.png and /dev/null differ
diff --git a/docs/.gitbook/assets/three (2).jpg b/docs/.gitbook/assets/three (2).jpg
deleted file mode 100644
index 12e1d44495..0000000000
Binary files a/docs/.gitbook/assets/three (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_cd5.jpg b/docs/.gitbook/assets/tri_cd5.jpg
deleted file mode 100644
index a23e37662f..0000000000
Binary files a/docs/.gitbook/assets/tri_cd5.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci2 (2) (1).jpg b/docs/.gitbook/assets/tri_ci2 (2) (1).jpg
deleted file mode 100644
index 5aed0bb481..0000000000
Binary files a/docs/.gitbook/assets/tri_ci2 (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci2 (2) (2).jpg b/docs/.gitbook/assets/tri_ci2 (2) (2).jpg
deleted file mode 100644
index 5aed0bb481..0000000000
Binary files a/docs/.gitbook/assets/tri_ci2 (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci2 (2) (3).jpg b/docs/.gitbook/assets/tri_ci2 (2) (3).jpg
deleted file mode 100644
index 5aed0bb481..0000000000
Binary files a/docs/.gitbook/assets/tri_ci2 (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci2 (2).jpg b/docs/.gitbook/assets/tri_ci2 (2).jpg
deleted file mode 100644
index 5aed0bb481..0000000000
Binary files a/docs/.gitbook/assets/tri_ci2 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci3 (1).jpg b/docs/.gitbook/assets/tri_ci3 (1).jpg
deleted file mode 100644
index 50bf1f81ef..0000000000
Binary files a/docs/.gitbook/assets/tri_ci3 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci3 (2) (1).jpg b/docs/.gitbook/assets/tri_ci3 (2) (1).jpg
deleted file mode 100644
index 50bf1f81ef..0000000000
Binary files a/docs/.gitbook/assets/tri_ci3 (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci3 (2) (2).jpg b/docs/.gitbook/assets/tri_ci3 (2) (2).jpg
deleted file mode 100644
index 50bf1f81ef..0000000000
Binary files a/docs/.gitbook/assets/tri_ci3 (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci3 (2) (3).jpg b/docs/.gitbook/assets/tri_ci3 (2) (3).jpg
deleted file mode 100644
index 50bf1f81ef..0000000000
Binary files a/docs/.gitbook/assets/tri_ci3 (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci3 (2) (4).jpg b/docs/.gitbook/assets/tri_ci3 (2) (4).jpg
deleted file mode 100644
index 50bf1f81ef..0000000000
Binary files a/docs/.gitbook/assets/tri_ci3 (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci3 (2) (5).jpg b/docs/.gitbook/assets/tri_ci3 (2) (5).jpg
deleted file mode 100644
index 50bf1f81ef..0000000000
Binary files a/docs/.gitbook/assets/tri_ci3 (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci3 (2).jpg b/docs/.gitbook/assets/tri_ci3 (2).jpg
deleted file mode 100644
index 50bf1f81ef..0000000000
Binary files a/docs/.gitbook/assets/tri_ci3 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci4 (1).jpg b/docs/.gitbook/assets/tri_ci4 (1).jpg
deleted file mode 100644
index 0fd1507763..0000000000
Binary files a/docs/.gitbook/assets/tri_ci4 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/tri_ci5 (1).jpg b/docs/.gitbook/assets/tri_ci5 (1).jpg
deleted file mode 100644
index c32a6648da..0000000000
Binary files a/docs/.gitbook/assets/tri_ci5 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-console (1).jpg b/docs/.gitbook/assets/trigger-console (1).jpg
deleted file mode 100644
index da9501605e..0000000000
Binary files a/docs/.gitbook/assets/trigger-console (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-console (2) (1).jpg b/docs/.gitbook/assets/trigger-console (2) (1).jpg
deleted file mode 100644
index da9501605e..0000000000
Binary files a/docs/.gitbook/assets/trigger-console (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-console (2) (2).jpg b/docs/.gitbook/assets/trigger-console (2) (2).jpg
deleted file mode 100644
index da9501605e..0000000000
Binary files a/docs/.gitbook/assets/trigger-console (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-console (2) (3).jpg b/docs/.gitbook/assets/trigger-console (2) (3).jpg
deleted file mode 100644
index da9501605e..0000000000
Binary files a/docs/.gitbook/assets/trigger-console (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-console (2) (4).jpg b/docs/.gitbook/assets/trigger-console (2) (4).jpg
deleted file mode 100644
index da9501605e..0000000000
Binary files a/docs/.gitbook/assets/trigger-console (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-console (2) (5).jpg b/docs/.gitbook/assets/trigger-console (2) (5).jpg
deleted file mode 100644
index da9501605e..0000000000
Binary files a/docs/.gitbook/assets/trigger-console (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-console (2).jpg b/docs/.gitbook/assets/trigger-console (2).jpg
deleted file mode 100644
index da9501605e..0000000000
Binary files a/docs/.gitbook/assets/trigger-console (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-select-image (1).jpg b/docs/.gitbook/assets/trigger-select-image (1).jpg
deleted file mode 100644
index 67b393d08f..0000000000
Binary files a/docs/.gitbook/assets/trigger-select-image (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-select-image (2) (1).jpg b/docs/.gitbook/assets/trigger-select-image (2) (1).jpg
deleted file mode 100644
index 67b393d08f..0000000000
Binary files a/docs/.gitbook/assets/trigger-select-image (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-select-image (2) (2).jpg b/docs/.gitbook/assets/trigger-select-image (2) (2).jpg
deleted file mode 100644
index 67b393d08f..0000000000
Binary files a/docs/.gitbook/assets/trigger-select-image (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-select-image (2) (3).jpg b/docs/.gitbook/assets/trigger-select-image (2) (3).jpg
deleted file mode 100644
index 67b393d08f..0000000000
Binary files a/docs/.gitbook/assets/trigger-select-image (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-select-image (2) (4).jpg b/docs/.gitbook/assets/trigger-select-image (2) (4).jpg
deleted file mode 100644
index 67b393d08f..0000000000
Binary files a/docs/.gitbook/assets/trigger-select-image (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-select-image (2) (5).jpg b/docs/.gitbook/assets/trigger-select-image (2) (5).jpg
deleted file mode 100644
index 67b393d08f..0000000000
Binary files a/docs/.gitbook/assets/trigger-select-image (2) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/trigger-select-image (2).jpg b/docs/.gitbook/assets/trigger-select-image (2).jpg
deleted file mode 100644
index 67b393d08f..0000000000
Binary files a/docs/.gitbook/assets/trigger-select-image (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_configmap (1).png b/docs/.gitbook/assets/update_configmap (1).png
deleted file mode 100644
index 33c07760f7..0000000000
Binary files a/docs/.gitbook/assets/update_configmap (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/update_configmap (3) (1).png b/docs/.gitbook/assets/update_configmap (3) (1).png
deleted file mode 100644
index 33c07760f7..0000000000
Binary files a/docs/.gitbook/assets/update_configmap (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/update_configmap (3) (2).png b/docs/.gitbook/assets/update_configmap (3) (2).png
deleted file mode 100644
index 33c07760f7..0000000000
Binary files a/docs/.gitbook/assets/update_configmap (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/update_configmap (3) (3).png b/docs/.gitbook/assets/update_configmap (3) (3).png
deleted file mode 100644
index 33c07760f7..0000000000
Binary files a/docs/.gitbook/assets/update_configmap (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/update_configmap (3) (4).png b/docs/.gitbook/assets/update_configmap (3) (4).png
deleted file mode 100644
index 33c07760f7..0000000000
Binary files a/docs/.gitbook/assets/update_configmap (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/update_configmap (3) (5).png b/docs/.gitbook/assets/update_configmap (3) (5).png
deleted file mode 100644
index 33c07760f7..0000000000
Binary files a/docs/.gitbook/assets/update_configmap (3) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/update_configmap (3) (6).png b/docs/.gitbook/assets/update_configmap (3) (6).png
deleted file mode 100644
index 33c07760f7..0000000000
Binary files a/docs/.gitbook/assets/update_configmap (3) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/update_configmap (3).png b/docs/.gitbook/assets/update_configmap (3).png
deleted file mode 100644
index 33c07760f7..0000000000
Binary files a/docs/.gitbook/assets/update_configmap (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_cd (2) (2) (1).jpg b/docs/.gitbook/assets/update_pipeline_cd (2) (2) (1).jpg
deleted file mode 100644
index 3ec0673c15..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_cd (2) (2) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_cd (2) (2) (2).jpg b/docs/.gitbook/assets/update_pipeline_cd (2) (2) (2).jpg
deleted file mode 100644
index 3ec0673c15..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_cd (2) (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_cd (2) (2) (3).jpg b/docs/.gitbook/assets/update_pipeline_cd (2) (2) (3).jpg
deleted file mode 100644
index 3ec0673c15..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_cd (2) (2) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_cd (2) (2) (4).jpg b/docs/.gitbook/assets/update_pipeline_cd (2) (2) (4).jpg
deleted file mode 100644
index 3ec0673c15..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_cd (2) (2) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_cd (2) (2).jpg b/docs/.gitbook/assets/update_pipeline_cd (2) (2).jpg
deleted file mode 100644
index 3ec0673c15..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_cd (2) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_cd (2).jpg b/docs/.gitbook/assets/update_pipeline_cd (2).jpg
deleted file mode 100644
index 3ec0673c15..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_cd (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_ci (1).jpg b/docs/.gitbook/assets/update_pipeline_ci (1).jpg
deleted file mode 100644
index 0cc6127338..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_ci (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_ci (2).jpg b/docs/.gitbook/assets/update_pipeline_ci (2).jpg
deleted file mode 100644
index 0cc6127338..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_ci (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_ci (3).jpg b/docs/.gitbook/assets/update_pipeline_ci (3).jpg
deleted file mode 100644
index 0cc6127338..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_ci (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_ci (4).jpg b/docs/.gitbook/assets/update_pipeline_ci (4).jpg
deleted file mode 100644
index 0cc6127338..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_ci (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_ci (5).jpg b/docs/.gitbook/assets/update_pipeline_ci (5).jpg
deleted file mode 100644
index 0cc6127338..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_ci (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/update_pipeline_ci.jpg b/docs/.gitbook/assets/update_pipeline_ci.jpg
deleted file mode 100644
index 0cc6127338..0000000000
Binary files a/docs/.gitbook/assets/update_pipeline_ci.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/updating_secrets (3) (1).png b/docs/.gitbook/assets/updating_secrets (3) (1).png
deleted file mode 100644
index a780aa88bc..0000000000
Binary files a/docs/.gitbook/assets/updating_secrets (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/updating_secrets (3) (2).png b/docs/.gitbook/assets/updating_secrets (3) (2).png
deleted file mode 100644
index a780aa88bc..0000000000
Binary files a/docs/.gitbook/assets/updating_secrets (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/updating_secrets (3) (3).png b/docs/.gitbook/assets/updating_secrets (3) (3).png
deleted file mode 100644
index a780aa88bc..0000000000
Binary files a/docs/.gitbook/assets/updating_secrets (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/updating_secrets (3) (4).png b/docs/.gitbook/assets/updating_secrets (3) (4).png
deleted file mode 100644
index a780aa88bc..0000000000
Binary files a/docs/.gitbook/assets/updating_secrets (3) (4).png and /dev/null differ
diff --git a/docs/.gitbook/assets/updating_secrets (3) (5).png b/docs/.gitbook/assets/updating_secrets (3) (5).png
deleted file mode 100644
index a780aa88bc..0000000000
Binary files a/docs/.gitbook/assets/updating_secrets (3) (5).png and /dev/null differ
diff --git a/docs/.gitbook/assets/updating_secrets (3) (6).png b/docs/.gitbook/assets/updating_secrets (3) (6).png
deleted file mode 100644
index a780aa88bc..0000000000
Binary files a/docs/.gitbook/assets/updating_secrets (3) (6).png and /dev/null differ
diff --git a/docs/.gitbook/assets/updating_secrets (3).png b/docs/.gitbook/assets/updating_secrets (3).png
deleted file mode 100644
index a780aa88bc..0000000000
Binary files a/docs/.gitbook/assets/updating_secrets (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-chart-store (1).jpg b/docs/.gitbook/assets/use-case-chart-store (1).jpg
deleted file mode 100644
index b5915b1413..0000000000
Binary files a/docs/.gitbook/assets/use-case-chart-store (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-chart-store (2).jpg b/docs/.gitbook/assets/use-case-chart-store (2).jpg
deleted file mode 100644
index b5915b1413..0000000000
Binary files a/docs/.gitbook/assets/use-case-chart-store (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-chart-store (3).jpg b/docs/.gitbook/assets/use-case-chart-store (3).jpg
deleted file mode 100644
index b5915b1413..0000000000
Binary files a/docs/.gitbook/assets/use-case-chart-store (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-chart-store (4).jpg b/docs/.gitbook/assets/use-case-chart-store (4).jpg
deleted file mode 100644
index b5915b1413..0000000000
Binary files a/docs/.gitbook/assets/use-case-chart-store (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-chart-store (5).jpg b/docs/.gitbook/assets/use-case-chart-store (5).jpg
deleted file mode 100644
index b5915b1413..0000000000
Binary files a/docs/.gitbook/assets/use-case-chart-store (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-chart-store (6).jpg b/docs/.gitbook/assets/use-case-chart-store (6).jpg
deleted file mode 100644
index b5915b1413..0000000000
Binary files a/docs/.gitbook/assets/use-case-chart-store (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-chart-store (7).jpg b/docs/.gitbook/assets/use-case-chart-store (7).jpg
deleted file mode 100644
index b5915b1413..0000000000
Binary files a/docs/.gitbook/assets/use-case-chart-store (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-chart-store.jpg b/docs/.gitbook/assets/use-case-chart-store.jpg
deleted file mode 100644
index b5915b1413..0000000000
Binary files a/docs/.gitbook/assets/use-case-chart-store.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-deploy-chart (2).jpg b/docs/.gitbook/assets/use-case-deploy-chart (2).jpg
deleted file mode 100644
index 3762b296d0..0000000000
Binary files a/docs/.gitbook/assets/use-case-deploy-chart (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-deploy-chart (3) (1).jpg b/docs/.gitbook/assets/use-case-deploy-chart (3) (1).jpg
deleted file mode 100644
index 3762b296d0..0000000000
Binary files a/docs/.gitbook/assets/use-case-deploy-chart (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-deploy-chart (3) (2).jpg b/docs/.gitbook/assets/use-case-deploy-chart (3) (2).jpg
deleted file mode 100644
index 3762b296d0..0000000000
Binary files a/docs/.gitbook/assets/use-case-deploy-chart (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-deploy-chart (3) (3).jpg b/docs/.gitbook/assets/use-case-deploy-chart (3) (3).jpg
deleted file mode 100644
index 3762b296d0..0000000000
Binary files a/docs/.gitbook/assets/use-case-deploy-chart (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-deploy-chart (3) (4).jpg b/docs/.gitbook/assets/use-case-deploy-chart (3) (4).jpg
deleted file mode 100644
index 3762b296d0..0000000000
Binary files a/docs/.gitbook/assets/use-case-deploy-chart (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-deploy-chart (3) (5).jpg b/docs/.gitbook/assets/use-case-deploy-chart (3) (5).jpg
deleted file mode 100644
index 3762b296d0..0000000000
Binary files a/docs/.gitbook/assets/use-case-deploy-chart (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-deploy-chart (3) (6).jpg b/docs/.gitbook/assets/use-case-deploy-chart (3) (6).jpg
deleted file mode 100644
index 3762b296d0..0000000000
Binary files a/docs/.gitbook/assets/use-case-deploy-chart (3) (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-deploy-chart (3).jpg b/docs/.gitbook/assets/use-case-deploy-chart (3).jpg
deleted file mode 100644
index 3762b296d0..0000000000
Binary files a/docs/.gitbook/assets/use-case-deploy-chart (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-django-ingress-template (4) (1).jpg b/docs/.gitbook/assets/use-case-django-ingress-template (4) (1).jpg
deleted file mode 100644
index 2aff8733c6..0000000000
Binary files a/docs/.gitbook/assets/use-case-django-ingress-template (4) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-django-ingress-template (4) (2).jpg b/docs/.gitbook/assets/use-case-django-ingress-template (4) (2).jpg
deleted file mode 100644
index 2aff8733c6..0000000000
Binary files a/docs/.gitbook/assets/use-case-django-ingress-template (4) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-django-ingress-template (4) (3).jpg b/docs/.gitbook/assets/use-case-django-ingress-template (4) (3).jpg
deleted file mode 100644
index 2aff8733c6..0000000000
Binary files a/docs/.gitbook/assets/use-case-django-ingress-template (4) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-django-ingress-template (4) (4).jpg b/docs/.gitbook/assets/use-case-django-ingress-template (4) (4).jpg
deleted file mode 100644
index 2aff8733c6..0000000000
Binary files a/docs/.gitbook/assets/use-case-django-ingress-template (4) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-django-ingress-template (4) (5).jpg b/docs/.gitbook/assets/use-case-django-ingress-template (4) (5).jpg
deleted file mode 100644
index 2aff8733c6..0000000000
Binary files a/docs/.gitbook/assets/use-case-django-ingress-template (4) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-django-ingress-template (4) (6).jpg b/docs/.gitbook/assets/use-case-django-ingress-template (4) (6).jpg
deleted file mode 100644
index 2aff8733c6..0000000000
Binary files a/docs/.gitbook/assets/use-case-django-ingress-template (4) (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-django-ingress-template (4) (7).jpg b/docs/.gitbook/assets/use-case-django-ingress-template (4) (7).jpg
deleted file mode 100644
index 2aff8733c6..0000000000
Binary files a/docs/.gitbook/assets/use-case-django-ingress-template (4) (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-django-ingress-template (4).jpg b/docs/.gitbook/assets/use-case-django-ingress-template (4).jpg
deleted file mode 100644
index 2aff8733c6..0000000000
Binary files a/docs/.gitbook/assets/use-case-django-ingress-template (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-django-ingress-template.jpg b/docs/.gitbook/assets/use-case-django-ingress-template.jpg
deleted file mode 100644
index 2aff8733c6..0000000000
Binary files a/docs/.gitbook/assets/use-case-django-ingress-template.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (1).jpg b/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (1).jpg
deleted file mode 100644
index b85b9f777b..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (2).jpg b/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (2).jpg
deleted file mode 100644
index b85b9f777b..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (3).jpg b/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (3).jpg
deleted file mode 100644
index b85b9f777b..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (4).jpg b/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (4).jpg
deleted file mode 100644
index b85b9f777b..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (5).jpg b/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (5).jpg
deleted file mode 100644
index b85b9f777b..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3).jpg b/docs/.gitbook/assets/use-case-expressjs-ingress-template (3).jpg
deleted file mode 100644
index b85b9f777b..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-ingress-template (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-ingress-template.jpg b/docs/.gitbook/assets/use-case-expressjs-ingress-template.jpg
deleted file mode 100644
index b85b9f777b..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-ingress-template.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (1).jpg b/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (1).jpg
deleted file mode 100644
index ab18a08ed9..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (2).jpg b/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (2).jpg
deleted file mode 100644
index ab18a08ed9..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (3).jpg b/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (3).jpg
deleted file mode 100644
index ab18a08ed9..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (4).jpg b/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (4).jpg
deleted file mode 100644
index ab18a08ed9..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (5).jpg b/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (5).jpg
deleted file mode 100644
index ab18a08ed9..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3) (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3).jpg b/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3).jpg
deleted file mode 100644
index ab18a08ed9..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1).jpg b/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1).jpg
deleted file mode 100644
index ab18a08ed9..0000000000
Binary files a/docs/.gitbook/assets/use-case-expressjs-view-demo-data (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-ingress-template (1).jpg b/docs/.gitbook/assets/use-cases-springboot-ingress-template (1).jpg
deleted file mode 100644
index 12e1d44495..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-ingress-template (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-ingress-template (2).jpg b/docs/.gitbook/assets/use-cases-springboot-ingress-template (2).jpg
deleted file mode 100644
index 12e1d44495..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-ingress-template (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-ingress-template (3).jpg b/docs/.gitbook/assets/use-cases-springboot-ingress-template (3).jpg
deleted file mode 100644
index 12e1d44495..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-ingress-template (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-ingress-template (4).jpg b/docs/.gitbook/assets/use-cases-springboot-ingress-template (4).jpg
deleted file mode 100644
index 12e1d44495..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-ingress-template (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-ingress-template (5).jpg b/docs/.gitbook/assets/use-cases-springboot-ingress-template (5).jpg
deleted file mode 100644
index 12e1d44495..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-ingress-template (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-ingress-template (6).jpg b/docs/.gitbook/assets/use-cases-springboot-ingress-template (6).jpg
deleted file mode 100644
index 12e1d44495..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-ingress-template (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-ingress-template (7).jpg b/docs/.gitbook/assets/use-cases-springboot-ingress-template (7).jpg
deleted file mode 100644
index 12e1d44495..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-ingress-template (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-ingress-template.jpg b/docs/.gitbook/assets/use-cases-springboot-ingress-template.jpg
deleted file mode 100644
index 12e1d44495..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-ingress-template.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data (1).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data (1).jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data (10).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data (10).jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data (10).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data (11).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data (11).jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data (11).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data (2).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data (2).jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data (3).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data (3).jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data (4).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data (4).jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data (5).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data (5).jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data (6).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data (6).jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data (7).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data (7).jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data (8).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data (8).jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data (8).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data (9).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data (9).jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data (9).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (1).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (1).jpg
deleted file mode 100644
index c2d9c5f3b3..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (2).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (2).jpg
deleted file mode 100644
index c2d9c5f3b3..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (3).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (3).jpg
deleted file mode 100644
index c2d9c5f3b3..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (4).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (4).jpg
deleted file mode 100644
index c2d9c5f3b3..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (5).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (5).jpg
deleted file mode 100644
index c2d9c5f3b3..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (5).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (6).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (6).jpg
deleted file mode 100644
index c2d9c5f3b3..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (6).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (7).jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (7).jpg
deleted file mode 100644
index c2d9c5f3b3..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id (7).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id.jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id.jpg
deleted file mode 100644
index c2d9c5f3b3..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data-with-id.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/use-cases-springboot-view-student-data.jpg b/docs/.gitbook/assets/use-cases-springboot-view-student-data.jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/.gitbook/assets/use-cases-springboot-view-student-data.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/user1.jpg b/docs/.gitbook/assets/user1.jpg
deleted file mode 100644
index d40e964fef..0000000000
Binary files a/docs/.gitbook/assets/user1.jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/user_gc1 (3) (1).png b/docs/.gitbook/assets/user_gc1 (3) (1).png
deleted file mode 100644
index 99a4ca870c..0000000000
Binary files a/docs/.gitbook/assets/user_gc1 (3) (1).png and /dev/null differ
diff --git a/docs/.gitbook/assets/user_gc1 (3) (2).png b/docs/.gitbook/assets/user_gc1 (3) (2).png
deleted file mode 100644
index 99a4ca870c..0000000000
Binary files a/docs/.gitbook/assets/user_gc1 (3) (2).png and /dev/null differ
diff --git a/docs/.gitbook/assets/user_gc1 (3) (3).png b/docs/.gitbook/assets/user_gc1 (3) (3).png
deleted file mode 100644
index 99a4ca870c..0000000000
Binary files a/docs/.gitbook/assets/user_gc1 (3) (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/user_gc1 (3).png b/docs/.gitbook/assets/user_gc1 (3).png
deleted file mode 100644
index 99a4ca870c..0000000000
Binary files a/docs/.gitbook/assets/user_gc1 (3).png and /dev/null differ
diff --git a/docs/.gitbook/assets/user_gc1-3-4.png b/docs/.gitbook/assets/user_gc1-3-4.png
deleted file mode 100644
index 99a4ca870c..0000000000
Binary files a/docs/.gitbook/assets/user_gc1-3-4.png and /dev/null differ
diff --git a/docs/.gitbook/assets/wf1 (2).jpg b/docs/.gitbook/assets/wf1 (2).jpg
deleted file mode 100644
index 91edff4a29..0000000000
Binary files a/docs/.gitbook/assets/wf1 (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/wf2 (1).jpg b/docs/.gitbook/assets/wf2 (1).jpg
deleted file mode 100644
index fcab99f7dd..0000000000
Binary files a/docs/.gitbook/assets/wf2 (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/workflow (1).gif b/docs/.gitbook/assets/workflow (1).gif
deleted file mode 100644
index 80428dbe95..0000000000
Binary files a/docs/.gitbook/assets/workflow (1).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/workflow (2).gif b/docs/.gitbook/assets/workflow (2).gif
deleted file mode 100644
index 80428dbe95..0000000000
Binary files a/docs/.gitbook/assets/workflow (2).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/workflow (3).gif b/docs/.gitbook/assets/workflow (3).gif
deleted file mode 100644
index 80428dbe95..0000000000
Binary files a/docs/.gitbook/assets/workflow (3).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/workflow (4).gif b/docs/.gitbook/assets/workflow (4).gif
deleted file mode 100644
index 80428dbe95..0000000000
Binary files a/docs/.gitbook/assets/workflow (4).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/workflow (5).gif b/docs/.gitbook/assets/workflow (5).gif
deleted file mode 100644
index 80428dbe95..0000000000
Binary files a/docs/.gitbook/assets/workflow (5).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/workflow (6).gif b/docs/.gitbook/assets/workflow (6).gif
deleted file mode 100644
index 80428dbe95..0000000000
Binary files a/docs/.gitbook/assets/workflow (6).gif and /dev/null differ
diff --git a/docs/.gitbook/assets/workflow.gif b/docs/.gitbook/assets/workflow.gif
deleted file mode 100644
index 80428dbe95..0000000000
Binary files a/docs/.gitbook/assets/workflow.gif and /dev/null differ
diff --git a/docs/.gitbook/assets/yaml (3) (1).jpg b/docs/.gitbook/assets/yaml (3) (1).jpg
deleted file mode 100644
index 986f58e63e..0000000000
Binary files a/docs/.gitbook/assets/yaml (3) (1).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/yaml (3) (2).jpg b/docs/.gitbook/assets/yaml (3) (2).jpg
deleted file mode 100644
index 986f58e63e..0000000000
Binary files a/docs/.gitbook/assets/yaml (3) (2).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/yaml (3) (3).jpg b/docs/.gitbook/assets/yaml (3) (3).jpg
deleted file mode 100644
index 986f58e63e..0000000000
Binary files a/docs/.gitbook/assets/yaml (3) (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/yaml (3) (4).jpg b/docs/.gitbook/assets/yaml (3) (4).jpg
deleted file mode 100644
index 986f58e63e..0000000000
Binary files a/docs/.gitbook/assets/yaml (3) (4).jpg and /dev/null differ
diff --git a/docs/.gitbook/assets/yaml (3).jpg b/docs/.gitbook/assets/yaml (3).jpg
deleted file mode 100644
index 986f58e63e..0000000000
Binary files a/docs/.gitbook/assets/yaml (3).jpg and /dev/null differ
diff --git a/docs/.gitbook/gc-gitops-tab.png b/docs/.gitbook/gc-gitops-tab.png
deleted file mode 100644
index d96ffe8742..0000000000
Binary files a/docs/.gitbook/gc-gitops-tab.png and /dev/null differ
diff --git a/docs/FAQs/devtron-troubleshoot.md b/docs/FAQs/devtron-troubleshoot.md
old mode 100644
new mode 100755
index fb12392e73..cfe617bc93
--- a/docs/FAQs/devtron-troubleshoot.md
+++ b/docs/FAQs/devtron-troubleshoot.md
@@ -1,8 +1,11 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
# Troubleshooting Guide
We always try to make your experience of using Devtron as smooth as possible but still if you face any issues, follow the troubleshooting guide given below or join our [discord channel](https://discord.gg/jsRG5qx2gp) if you couldn't find the solution for the issue you are facing.
-#### 1. How to resolve unauthorized errors, while trying to save global configurations like hostname, GitOps etc. after successful devtron installation
+### 1. How to resolve unauthorized errors, while trying to save global configurations like hostname, GitOps etc. after successful devtron installation
This occurs most of the time because any one or multiple jobs get failed during installation. To resolve this, you'll need to first check which jobs have failed. Follow these steps:
@@ -30,7 +33,7 @@ kubectl apply -f migrator.yaml -n devtroncd
```
- It will re-create the failed jobs and you’ll see their pods created again. Just wait for a few minutes until the jobs gets completed then you are good to go. You should be able to save your global configurations now.
-#### 2. Not able to see deployment metrics on production environment or Not able to enable application-metrics or Not able to deploy the app after creating a configmap or secret with data-volume option enabled
+### 2. Not able to see deployment metrics on production environment or Not able to enable application-metrics or Not able to deploy the app after creating a configmap or secret with data-volume option enabled
Update the rollout CRDs to latest version, run the following command:
@@ -38,7 +41,7 @@ Update the rollout CRDs to latest version, run the following command:
kubectl apply -f https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/yamls/rollout.yaml -n devtroncd
```
-#### 3. SSO Login not working even after entering correct SSO Credentials
+### 3. SSO Login not working even after entering correct SSO Credentials
```error: user/UserAuthHandler.go:236","msg":"service err, AuthVerification","err":"no token provided```
@@ -52,7 +55,7 @@ Delete devtron pod once to reload the configurations using:
kubectl delete pod -n devtroncd -l app=devtron
```
-#### 4. Logs are not Visible on UI while running the build and not even able to abort the same
+### 4. Logs are not Visible on UI while running the build and not even able to abort the same
Check if the pods are being created when you start a new build, run the command and look if a new pod is created when you started the build:
```bash
@@ -71,10 +74,10 @@ kubectl delete pod -n devtroncd -l app=kubewatch
```
Again wait for 5 minutes and your issue should be resolved
-#### 5. Grafana dashboards not visible in App Details page even after adding prometheus endpoint or Graphs showing error panel with id 2 not found
+### 5. Grafana dashboards not visible in App Details page even after adding prometheus endpoint or Graphs showing error panel with id 2 not found
-If the graphs are not visible check if prometheus is configured properly. Then go to Global Configurations > Clusters & Environments > Click on any environment for the cluster where you added prometheus endpoint and simply click `Update`.
-If the charts are still not visible, try visiting the url: /grafana?orgId=2
+If the graphs are not visible check if prometheus is configured properly. Then go to Global Configurations → Clusters & Environments → Click on any environment for the cluster where you added prometheus endpoint and simply click `Update`.
+If the charts are still not visible, try visiting the url: ``/grafana?orgId=2
If you see `Not Found` on this page, then follow all the given steps or if the page is accessible and you are getting `panel with id 2 not found` then follow from step 6:
1. Get grafana password using `kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.GRAFANA_PASSWORD}' | base64 -d`
2. `kubectl run --rm -it --image quay.io/devtron/k8s-utils:tutum-curl curl` Run this command and it will create a pod for using `curl`
@@ -105,9 +108,9 @@ curl "${grafanaUrl}/api/datasources/2" -X PUT \
EOF
```
and run in the pod that we created above in step 2.
-4. Now visit /grafana?orgId=2 again and you'll see grafana login page. Login using username `admin` and password from step 1 and check if prometheus url is updated in datasources. If not, update it in the default datasource.
+4. Now visit ``/grafana?orgId=2 again and you'll see grafana login page. Login using username `admin` and password from step 1 and check if prometheus url is updated in datasources. If not, update it in the default datasource.
5. Now from devtron UI, update any of the environment again and it's datasource will be created automatically.
-6. In Grafana UI you need to be logged in and Go to Dashboards > Manage then click `Import` and Import the given dashboards one by one.
+6. In Grafana UI you need to be logged in and Go to Dashboards → Manage then click `Import` and Import the given dashboards one by one.
```
https://grafana.com/api/dashboards/13322/revisions/4/download
https://grafana.com/api/dashboards/13320/revisions/4/download
@@ -116,7 +119,7 @@ https://grafana.com/api/dashboards/13321/revisions/6/download
```
After that, your issue should be resolved and you should be able to see all the graphs on UI.
-#### 6. Unable to Login Devtron dashboard even if the password is correct
+### 6. Unable to Login Devtron dashboard even if the password is correct
If you are not able to login into Devtron dashboard even after giving the correct password, it is possible that the argocd token of previous session has been stored in the cookies and is not able to override the new token that is generated for the new session. If you are facing this issue, follow the steps below -
@@ -125,7 +128,8 @@ If using Firefox -
2. Navigate to storage tab in inspect.
3. Click on url where Devtron has been installed under `Cookies` tab and you could see an argocd token with its value, something similar to below image.
-
+
+
Figure 1: Inspect-cookies
4. Now right click on token, and click on `Delete All Session Cookies` option.
@@ -134,35 +138,39 @@ If using Chrome -
2. Navigate to Application tab, and under `Storage` tab click on `Cookies`.
3. Click on url under `Cookie` and you would be able tto see an argocd token with its value, as shown in the image below.
-
+
+
Figure 2: Chrome-cookie
4. Now right click on token and click on `delete` option.
If using Safari -
-1. Goto Safari preferences >> Advanced options and check the show develop menu as shown in the image below.
+1. Goto Safari preferences → Advanced options and check the show develop menu as shown in the image below.
-
+
+
Figure 3: Safari-preferences
2. Now goto login page of Devtron and press `option+command+I`. It will open inspect element.
3. Then navigate to `Storage`, click on `Cookies` and you would be able to see an argocd token with its value as shown in the image below.
-
+
+
Figure 4: Safari-cookie
4. Now right click on token and select `delete` option.
After clearing `Cookies`, try again to login, you should be able to login now.
-#### 7. No charts found in Charts Discover Section
+### 7. No charts found in Charts Discover Section
-In the Devtron's Discover Chart section, if you are not able to see any charts available, goto `Global Configuration` >> `Chart Repositories` and click on `Refresh Chart` at the top-right as shown in the image below. After clicking the button, it might take 4-5mins to show all the charts in `Discover` section depending upon the chart repositories added.
+In the Devtron's Discover Chart section, if you are not able to see any charts available, go to **Application Management** → **Configurations** → **Chart Repository** and click on `Refresh Chart` at the top-right as shown in the image below. After clicking the button, it might take 4-5mins to show all the charts in `Discover` section depending upon the chart repositories added.
-
+
+
Figure 5: Charts-not-found
-#### 8. Not able to update cluster
+### 8. Not able to update cluster
-In `Global Configurations` >> `Cluters & Environments`, if you try to update a cluster which has been already added in Devtron, you might get an error as `{"message":"Failed to update datasource. Reload new version and try again"}`. If you are facing such issue, please follow the following steps -
+In **Global Configurations** → **Clusters & Environments**, if you try to update a cluster which has been already added in Devtron, you might get an error as `{"message":"Failed to update datasource. Reload new version and try again"}`. If you are facing such issue, please follow the following steps -
1. Edit the changes you want to make in respective cluster
2. Click on save after making changes and you may get error message stated above.
@@ -171,7 +179,7 @@ In `Global Configurations` >> `Cluters & Environments`, if you try to update a c
[Note: If you already have created some environments in that cluster, it needs to be updated again]
-#### 9. Postgresql is in crashloop with error - Failed to pull image
+### 9. Postgresql is in crashloop with error - Failed to pull image
There may be some other pods also in crashloop as they are not able to connect to database. To resolve this issue, you can either [update devtron to latest version](../setup/upgrade/README.md) or run the following commands to fix instantly on the same version you are using:
```bash
@@ -183,17 +191,17 @@ kubectl delete pod -n devtroncd postgresql-postgresql-0
```
You can also delete other pods which are in crashloop after postgresql is up and running so that they can restart and connect to postgresql and Devtron will be up and running again in a few moments.
-#### 10. Unable to fetch the latest commit and not able to trigger auto build.
+### 10. Unable to fetch the latest commit and not able to trigger auto build.
To solve this, bounce the git-sensor-0 pod.
```bash
kubectl delete pod -n devtroncd git-sensor-0
```
-#### 11. If you have restricted devtron-service to be accessible on certain IPs only and SSO login isn’t working
+### 11. If you have restricted devtron-service to be accessible on certain IPs only and SSO login isn’t working
Whitelist the NAT-gateway IPs of the cluster (There can be multiple NAT-gateways if your cluster is multi-AZ)
-#### 12. If CPU metrics are not showing but memory metrics are visible in graphs.
+### 12. If CPU metrics are not showing but memory metrics are visible in graphs.
Do the following:-
@@ -203,7 +211,7 @@ Do the following:-
CPU metrics should start showing up in a while.
-#### 13. If user not able to upload a file more than specific size.
+### 13. If user not able to upload a file more than specific size.
`Please use below annotation in ingress`
```bash
@@ -211,22 +219,22 @@ nginx.ingress.kubernetes.io/proxy-body-size: 100m
```
`Note:- `Where m is MiB.
-#### 14. If AWS Load balancer controller is unable to provision ALB and getting message in alb controller as unauthorized, attach these IAM policy to the nodegroup IAM Role.
+### 14. If AWS Load balancer controller is unable to provision ALB and getting message in alb controller as unauthorized, attach these IAM policy to the nodegroup IAM Role.
[IAM policy](https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.3.1/docs/install/iam_policy.json)
-#### 15. When app metrics is not coming on grafana and devtron dashboard, set the value of the following parameter as false in kube prometheus stack values.
+### 15. When app metrics is not coming on grafana and devtron dashboard, set the value of the following parameter as false in kube prometheus stack values.
```
serviceMonitorSelectorNilUsesHelmValues: false
```
-#### 16. Unable to deploy metrics-server using chart on devtron
+### 16. Unable to deploy metrics-server using chart on devtron
To solve
Disable certificate validation by passing `--kubelet-insecure-tls` argument to metrics server chart.
-#### 17. Unable to delete a database from postgres
+### 17. Unable to delete a database from postgres
`Description of issue`
ERROR: database `` is being accessed by other users
@@ -239,7 +247,7 @@ SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg
```
Then run the command to delete database - `drop databases `
-#### 18. Unable to login with admin password or reset devtron admin password
+### 18. Unable to login with admin password or reset devtron admin password
`Debug`
@@ -259,7 +267,7 @@ If you are getting an error message of "invalid username or password" or you wan
3. Restart argocd dex server to create new admin password for devtron using `kubectl delete po -n devtroncd -l app.kubernetes.io/name=argocd-dex-server`
4. Run the command given above to get the new admin password
-#### 19. After installing Devtron using Helm, getting the admin password does not work.(if using windows)
+### 19. After installing Devtron using Helm, getting the admin password does not work.(if using windows)
`Debug`
@@ -274,9 +282,9 @@ The other way is to get the password in the encoded form using the cmd
`kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ACD_PASSWORD}'`, further decode it into plaintext using an online [encoder decoder](https://www.base64decode.org/).
-#### 20. Getting `UPGRADE FAILED: cannot patch "postgresql-postgresql"` while upgrading Devtron to newer versions
+### 20. Getting `UPGRADE FAILED: cannot patch "postgresql-postgresql"` while upgrading Devtron to newer versions
`Debug:`
-1. Make sure to [annotate and label](../setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md#id-3.-annotate-and-label-all-the-devtron-resources) all the Devtron resources.
+1. Make sure to [annotate and label](../setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md#3-annotate-and-label-all-the-devtron-resources) all the Devtron resources.
2. Description of error
```
Error: UPGRADE FAILED: cannot patch "postgresql-postgresql" with kind StatefulSet: StatefulSet.apps "postgresql-postgresql" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy' and 'minReadySeconds' are forbidden
@@ -290,14 +298,14 @@ helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
--set components.postgres.persistence.volumeSize=20Gi
```
-#### 21. Configure Blob Storage
+### 21. Configure Blob Storage
You can configure blob storage with one of the following:
-{% tabs %}
+
-{% tab title="MinIO storage" %}
+
This configuration will use MinIO for storing logs and cache.
@@ -311,9 +319,9 @@ helm upgrade devtron devtron/devtron-operator \
--set minio.enabled=true
```
-{% endtab %}
+
-{% tab title="AWS S3 Bucket" %}
+
This configuration will use AWS S3 bucket for storing build logs and cache. Refer to the `AWS specific` parameters on the [Storage for Logs and Cache](../setup/install/installation-configuration.md#aws-specific) page.
* **Configure using S3 IAM policy:**
@@ -367,9 +375,9 @@ helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
--set configs.BLOB_STORAGE_S3_ENDPOINT=
```
-{% endtab %}
+
-{% tab title="Azure Blob Storage" %}
+
This configuration will use Azure Blob Storage for storing build logs and cache.
Refer to the `Azure specific` parameters on the [Storage for Logs and Cache](../setup/install/installation-configuration.md#azure-specific) page.
@@ -385,9 +393,9 @@ helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
--set configs.AZURE_BLOB_CONTAINER_CI_CACHE=ci-cache-container
```
-{% endtab %}
+
-{% tab title="Google Cloud Storage" %}
+
This configuration will use Google Cloud Storage for storing build logs and cache.
Refer to the `Google Cloud specific` parameters on the [Storage for Logs and Cache](../setup/install/installation-configuration.md#google-cloud-storage-specific) page.
@@ -403,19 +411,19 @@ helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
--set configs.DEFAULT_BUILD_LOGS_BUCKET: log-bucket
```
-{% endtab %}
-{% endtabs %}
+
+
-#### 22. Rollout is showing error - :111: attempt to index a non-table object(nil) with key 'stableRS' stack traceback: :111: in main chunk [G]: ?
+### 22. Rollout is showing error - ``:111: attempt to index a non-table object(nil) with key 'stableRS' stack traceback: ``:111: in main chunk [G]: ?
This can occur if you are using or recently upgraded to Kubernetes version 1.22 or above and you are using rollout controller version 0.13.0 from chart `devtron-charts/rollout` or `devtron/rollout`. The issue can be because of CRDs which were updated in later versions of rollout chart.
1. Check which chart repo and version of rollout controller are you using on that cluster from Helm Apps section
-2. Update the rollout chart version to latest and re-deploy. If your rollout controller is deployed from `devtron-charts` helm repo then change the repo to `devtron/rollout` and then update the version to latest. Also, if devtron helm repo is not showing on your devtron then go to Global Configurations > Chart Repositories and add a new repo with the name `devtron` and url `https://helm.devtron.ai`. Wait for few minutes and then charts from devtron repo will be there on your devtron. This should resolve your issue
+2. Update the rollout chart version to latest and re-deploy. If your rollout controller is deployed from `devtron-charts` helm repo then change the repo to `devtron/rollout` and then update the version to latest. Also, if devtron helm repo is not showing on your devtron then go to Application Management → Configurations → Chart Repository and add a new repo with the name `devtron` and url `https://helm.devtron.ai`. Wait for few minutes and then charts from devtron repo will be there on your devtron. This should resolve your issue
-#### 23. How to resolve if Deployment Status shows Failed or Degraded when you pull images from private container registry
+### 23. How to resolve if Deployment Status shows Failed or Degraded when you pull images from private container registry
If the deployment status shows `Failed` or `Degraded`, then the cluster is not able to pull container image from the private registry. In that case, the status of pod shows `ImagePullBackOff`.
@@ -427,21 +435,24 @@ The failure of deployment can be one of the following reasons:
You can resolve the `ImagePullBackOff` issue by clicking **How to resolve?** on the **App Details** page.
+
Figure 6: Deployment Status Failed
To provide the auto-inject credentials to the specific clusters for pulling the image from the private repository, click **Manage Access** which will take you to the **Container Registries** page.
+
Figure 7: Manage Access
1. On the **Container Registries** page, select the docker registry and click **Manage**.
2. In the **Auto-inject credentials to clusters**, click **Confirm to edit** to select the specific cluster or all clusters for which you want to auto-inject the credentials to and click **Save**.
3. Redeploy the application after allowing the access.
+
Figure 8: Auto Inject to Clusters
-#### 24. Devtron Terminal Connection Timeout Issue on GKE Cluster
+### 24. Devtron Terminal Connection Timeout Issue on GKE Cluster
**Problem:**
@@ -487,7 +498,7 @@ metadata:
With these configuration changes, the Devtron dashboard connection should no longer timeout after 30 seconds, allowing for a more stable and consistent connection.
-#### 25. Refreshing ArgoCD Certificates When Expired
+### 25. Refreshing ArgoCD Certificates When Expired
1. **Edit ArgoCD Secret**
@@ -524,7 +535,7 @@ This command deletes the Devtron pod in the `devtroncd` namespace with the label
Following these steps should allow you to refresh the ArgoCD certificates when they have expired.
-#### 26. Not able to see commits, throwing exit status 128
+### 26. Not able to see commits, throwing exit status 128
1. **Save the Git Repository Again**
Wait for few minutes and check the build pipeline if commits are visible or not
@@ -544,11 +555,12 @@ kubectl delete po -n devtroncd -l app=git-sensor
In case the cloning fails, you can generate the token, update the Git account in Global Configurations, and try to save the git repository again.
-#### 27. Git-sensor PVC- disk full
+### 27. Git-sensor PVC- disk full
**Need to increase the PVC size if you are getting following error:**
+
Figure 9: Git Sensor PVC
**Need to check the `Storageclass` by which PVC was provisioned.**
@@ -575,13 +587,14 @@ spec:
kubectl delete po -n devtroncd git-sensor-0
```
-#### 28. Getting 'Invalid JSON Document' while deploying via ArgoCD
+### 28. Getting 'Invalid JSON Document' while deploying via ArgoCD
+
Figure 10: Invalid JSON
As shown above, Rollout object’s sync status is showing `Failed` and throwing an `Invalid JSON Document` error.
-This might happen due to manual changes in the Rollout object in the annotation `kubectl.kubernetes.io/last-applied-configuration:` The value of the above annotation is a JSON. ArgoCD tries to validate that JSON and throws an error if it is invalid.
+This might happen due to manual changes in the Rollout object in the annotation `kubectl.kubernetes.io/last-applied-configuration:` The value of the above annotation is a JSON. ArgoCD tries to validate that JSON and throws an error if it is invalid.
Below is a sample annotation for your reference.
@@ -591,11 +604,11 @@ kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","data":{"
You may take the help of JSON validators to identify where the unintended human error has occured in the JSON. Rectifying the same should resolve this issue.
-{% hint style="info" %}
+:::info
The annotation `kubectl.kubernetes.io/last-applied-configuration:` is automatically added to each object when you run `kubectl apply`.
-{% endhint %}
+:::
-#### 29. Helm Charts provided by Bitnami are not visible in Chart Store. Getting 'tls: handshake failure' while deploying Bitnami Charts.
+### 29. Helm Charts provided by Bitnami are not visible in Chart Store. Getting 'tls: handshake failure' while deploying Bitnami Charts.
`rpc error: code = Unknown desc = Get "https://repo.broadcom.com/bitnami-files/index.yaml": remote error: tls: handshake failure`
@@ -603,25 +616,27 @@ Follow the below steps if you are getting the above error:
* Make sure your [Devtron version](https://devtron-public-asset.s3.us-east-2.amazonaws.com/integrations/about-devtron.png) is 0.7.1 ([check how to upgrade](../setup/upgrade/README.md)).
-* Navigate to Global Configurations → Chart Repositories → Bitnami
+* Navigate to **Application Management** → **Chart Repository** → **Bitnami**
* Now in the Bitnami repository, uncheck the **Allow Insecure Connection** and update it as shown below.
+
Figure 11: Bitnami Chart Issue
-* Go to Chart Store and initiate the Chart Sync.
+* Go to **Application Management** → **Chart Store** and initiate the Chart Sync.
+
Figure 12: Chart Sync
-#### 30. The Advanced (YAML) and Basic (GUI) sections are appearing blank in the Base Deployment Template of the application.
+### 30. The Advanced (YAML) and Basic (GUI) sections are appearing blank in the Base Deployment Template of the application.
+
Figure 13: Empty Values
-This happens due to a missing [app-values.yaml](../user-guide/global-configurations/deployment-charts.md#id-3.-add-app-values.yaml) file in your deployment chart.
-
-To fix this issue, include an `app-values.yaml` file in your deployment helm chart before uploading the chart. Refer [adding app-values.yaml](../user-guide/global-configurations/deployment-charts.md#id-3.-add-app-valuesyaml) to know more.
+This happens due to a missing [app-values.yaml](../user-guide/global-configurations/deployment-charts.md#3-add-app-valuesyaml) file in your deployment chart.
-#### 31. Unable to create a GitOps deployment pipeline or encountering errors with GitOps deployment.
+To fix this issue, include an `app-values.yaml` file in your deployment helm chart before uploading the chart. Refer [adding app-values.yaml](../user-guide/global-configurations/deployment-charts.md#3-add-app-valuesyaml) to know more.
-If the **GitOps** section is already configured for your [external Argo apps](../user-guide/creating-application/workflow/cd-pipeline.md#migrate-argo-cd-application), and later if you install the GitOps (ArgoCD) module from [Devtron Stack Manager](../user-guide/integrations/argocd.md), make sure to save the [GitOps](../user-guide/global-configurations/gitops.md) configuration once again and also the [Cluster](../user-guide/global-configurations/cluster-and-environments.md) configuration. This might prevent potential errors and ensure your GitOps deployments (for Devtron Apps/Helm Apps) are functional.
+### 31. Unable to create a GitOps deployment pipeline or encountering errors with GitOps deployment.
+If the **GitOps** section is already configured for your [external Argo apps](../user-guide/creating-application/workflow/cd-pipeline.md#migrate-argo-cd-application), and later if you install the GitOps (ArgoCD) module from [Devtron Stack Manager](../user-guide/integrations/argocd.md), make sure to save the [GitOps](../user-guide/global-configurations/gitops.md) configuration once again and also the [Cluster](../user-guide/global-configurations/cluster-and-environments.md) configuration. This might prevent potential errors and ensure your GitOps deployments (for Devtron Apps/Helm Apps) are functional.
\ No newline at end of file
diff --git a/docs/README.md b/docs/README.md
old mode 100644
new mode 100755
index 2d73d31bc7..565936e8a9
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,73 +1,80 @@
+---
+title: Introduction to Devtron
+sidebar_label: Introduction to Devtron
+description: Learn what Devtron is, how it simplifies Kubernetes application management, and how to navigate your journey through the platform.
+---
+
# Introduction to Devtron
-
-Devtron is a tool integration platform for Kubernetes.
+Devtron is an open-source tool integration platform for Kubernetes. It is built to simplify how teams deploy, manage, secure, and observe their applications.
-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.
-
-
-{% embed url="https://www.youtube.com/watch?v=AG8HfTceHxw" caption="Introducing Devtron" %}
-
-
-## Devtron's Key Features:
-
-### No Code Software Delivery Workflow for Kubernetes
-
-* 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
-
-### Multi-cloud Deployment
-
-* Deploy to multiple Kubernetes clusters on multiple cloud/on-prem from one Devtron setup
-* Works for all cloud providers and on-premise Kubernetes clusters
-
-### Easy DevSecOps Integration
-
-* 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
-
-### Application Debugging Dashboard
-
-* 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
-
-### Enterprise-Grade Security and Compliances
-
-* 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
-
-### Implements GitOps
-
-* 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
-
-### Operational Insights
-
-* 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
-
-## Compatibility Notes
-
-* Devtron uses a modified version of [Argo Rollout](https://argoproj.github.io/argo-rollouts/).
-* Application metrics only work for K8s version 1.16+
-
-
-## Contributing Guidelines
-
-Check out our [contributing guidelines](https://github.com/devtron-labs/devtron/blob/main/CONTRIBUTING.md). Directions for opening issues, coding standards, and notes on our development processes are all included.
+Devtron is like a control plane for the entire Kubernetes app lifecycle, where CI/CD, infrastructure provisioning, cost visibility, security, and debugging all meet in one unified interface.
+
+## Quick Walkthrough
+
+
+
+---
+
+## Why Devtron Exists
+
+Kubernetes is powerful but complex.
+Organizations often end up juggling 8-12 different tools just to achieve visibility, deployments, and governance. Devtron bridges these gaps by integrating all critical DevOps capabilities into a single coherent experience, without forcing teams to change their existing toolchains.
+
+With Devtron, you can:
+
+* **Deploy and manage** microservices across clusters with visual CI/CD pipelines.
+* **Provision infrastructure** like EKS clusters directly from the UI.
+* **Observe, debug, and troubleshoot** applications in real-time.
+* **Integrate security and cost insights** right into your release workflow.
+* **Automate repetitive DevOps workflows** using policies and templates.
+* **Leverage AI-powered recommendations** for smarter scaling, debugging, and optimization.
+
+---
+
+## Map Your Journey
+
+Here’s how you can explore Devtron step-by-step through this documentation:
+
+| Stage | What You’ll Learn |
+|-------|------------------|
+| **1. Setup & Installation** | Install and access Devtron in your cluster. |
+| **2. Application Management** | Create, deploy, monitor, and roll back microservices using Helm or CI/CD pipelines. |
+| **3. Infrastructure Management** | Monitor and Debug using Resource Browser, and perform remediation actions. |
+| **4. Software Release Management** | Control releases with advanced workflows, approvals, and versioning. |
+| **5. Cost Visibility** | Track and analyze Kubernetes resource costs across clusters. |
+| **6. Security & Policies** | Integrate scanning and enforce policies across your workloads. |
+| **7. Automation & Enablement** | Automate tasks and streamline operations. |
+| **8. AI Recommendations** | Use AI to get actionable insights for right-sizing and optimization. |
+| **9. Global Configurations** | Manage environment-level configs, secrets, and templates. |
+| **10. Resources** | Access troubleshooting, glossary, additional configs, upgrades, plugins, integrations |
+
+---
+
+## What Makes Devtron Unique
+
+* **Unified DevOps Hub** - Bring CI/CD, observability, cost, and security into one dashboard.
+* **Deep Kubernetes Integration** - Works seamlessly with Helm, ArgoCD, Prometheus, Grafana, and more.
+* **Developer-Friendly UI** - No need to memorize kubectl commands because every operation is visual and intuitive.
+* **Enterprise-Ready** - Built-in RBAC, audit logs, SSO, and multi-cluster management.
+* **AI-Augmented Decisions** - Get smart recommendations to debug faster and deploy confidently.
+
+---
+
+## Who Is Devtron For?
+
+* **Developers** - who want fast, reliable deployments without losing control.
+* **DevOps Engineers** - who need central governance and automation.
+* **SREs** - who care about reliability, visibility, and cost efficiency.
+* **Engineering Leaders** - who want a unified platform that scales with their teams.
+
+---
+
+## Next Steps
+
+Ready to begin? Start with: **[Initial Setup →](./setup/getting-started/initial-setup.md)** to get Devtron running on your cluster.
+
+---
## Community
@@ -75,9 +82,12 @@ Get updates on Devtron's development and chat with the project maintainers, cont
* Join the [Discord Community](https://discord.gg/jsRG5qx2gp)
* Follow [@DevtronL on Twitter](https://twitter.com/DevtronL)
-* Raise feature requests, suggest enhancements, report bugs at [GitHub issues](https://github.com/devtron-labs/devtron/issues)
-* Read the [Devtron blog](https://devtron.ai/blog/)
+* Raise feature requests, suggest enhancements, report bugs at [GitHub Issues](https://github.com/devtron-labs/devtron/issues)
+* Read the [Devtron Blog](https://devtron.ai/blog/)
+* You can also checkout the sandbox given at the top of this website to experience Devtron quickly.
+
+---
## Vulnerability Reporting
-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**.
+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**.
\ No newline at end of file
diff --git a/docs/SUMMARY.md b/docs/SUMMARY.md
deleted file mode 100644
index 5c836d80a2..0000000000
--- a/docs/SUMMARY.md
+++ /dev/null
@@ -1,209 +0,0 @@
-# Table of contents
-
-* [Introduction](README.md)
-* [Getting Started](setup/getting-started/getting-started.md)
-* [Install Devtron](setup/install/README.md)
- * [Install Devtron OSS](setup/install/devtron-oss.md)
- * [Install Devtron Freemium](setup/install/devtron-freemium.md)
- * [Get Devtron Enterprise](https://devtron.ai/contact-sales)
- * [Devtron Admin Credentials](setup/install/install-devtron.md)
-* [Global Configurations](user-guide/global-configurations/README.md)
- * [Host URL](user-guide/global-configurations/host-url.md)
- * [GitOps](user-guide/global-configurations/gitops.md)
- * [Projects](user-guide/global-configurations/projects.md)
- * [Clusters & Environments](user-guide/global-configurations/cluster-and-environments.md)
- * [Git Accounts](user-guide/global-configurations/git-accounts.md)
- * [Container/OCI Registry](user-guide/global-configurations/container-registries.md)
- * [Chart Repositories](user-guide/global-configurations/chart-repo.md)
- * [Deployment Charts](user-guide/global-configurations/deployment-charts.md)
- * [Authorization](user-guide/global-configurations/authorization/README.md)
- * [SSO Login Services](user-guide/global-configurations/sso-login.md)
- * [Google](user-guide/global-configurations/authorization/sso/google.md)
- * [GitHub](user-guide/global-configurations/authorization/sso/github.md)
- * [GitLab](user-guide/global-configurations/authorization/sso/gitlab.md)
- * [Microsoft](user-guide/global-configurations/authorization/sso/microsoft.md)
- * [LDAP](user-guide/global-configurations/authorization/sso/ldap.md)
- * [OIDC](user-guide/global-configurations/authorization/sso/oidc.md)
- * [Keycloak](user-guide/global-configurations/authorization/sso/keycloak.md)
- * [Okta](user-guide/global-configurations/authorization/sso/okta.md)
- * [OpenShift](user-guide/global-configurations/authorization/sso/openshift.md)
- * [User Permissions](user-guide/global-configurations/authorization/user-access.md)
- * [Permission Groups](user-guide/global-configurations/authorization/permission-groups.md)
- * [API Tokens](user-guide/global-configurations/authorization/api-tokens.md)
- * [Notifications](user-guide/global-configurations/manage-notification.md)
- * [Application Templates](user-guide/global-configurations/application-template.md)
- * [Deployment Window](user-guide/global-configurations/deployment-window.md)
- * [Approval Policy](user-guide/global-configurations/approval-policy.md)
- * [External Links](user-guide/global-configurations/external-links.md)
- * [Catalog Framework](user-guide/global-configurations/catalog-framework.md)
- * [Scoped Variables](user-guide/global-configurations/scoped-variables.md)
- * [Plugin Policy](user-guide/global-configurations/plugin-policy.md)
- * [Pull Image Digest](user-guide/global-configurations/pull-image-digest.md)
- * [Tags Policy](user-guide/global-configurations/tags-policy.md)
- * [Filter Condition](user-guide/global-configurations/filter-condition.md)
- * [Lock Deployment Configuration](user-guide/global-configurations/lock-deployment-config.md)
- * [Image Promotion Policy](user-guide/global-configurations/image-promotion-policy.md)
- * [Build Infra](user-guide/global-configurations/build-infra.md)
-
-## Usage
-
-* [Applications](user-guide/applications.md)
- * [Create a New Application](user-guide/create-application.md)
- * [Clone an Existing Application](user-guide/cloning-application.md)
- * [Create Application From Template](user-guide/using-application-templates.md)
- * [Deploy a Sample Application](user-guide/Deploy-sample-app/nodejs_app.md)
- * [App Configuration](user-guide/creating-application/README.md)
- * [Git Repository](user-guide/creating-application/git-material.md)
- * [Build Configuration](user-guide/creating-application/docker-build-configuration.md)
- * [Base Configurations](user-guide/creating-application/base-config/README.md)
- * [Deployment Template](user-guide/creating-application/base-config/deployment-template.md)
- * [Types of Deployment Templates](user-guide/creating-application/base-config/deployment-template/README.md)
- * [Deployment](user-guide/creating-application/base-config/deployment-template/deployment.md)
- * [Rollout Deployment](user-guide/creating-application/base-config/deployment-template/rollout-deployment.md)
- * [Job and Cronjob](user-guide/creating-application/base-config/deployment-template/job-and-cronjob.md)
- * [StatefulSets](user-guide/creating-application/base-config/deployment-template/statefulset.md)
- * [ConfigMaps](user-guide/creating-application/base-config/config-maps.md)
- * [Secrets](user-guide/creating-application/base-config/secrets.md)
- * [Types of External Secrets](user-guide/creating-application/base-config/eso/README.md)
- * [Install ESO](user-guide/creating-application/base-config/eso/install-eso.md)
- * [AWS Secrets Manager](user-guide/creating-application/base-config/eso/aws-eso.md)
- * [Google Secrets Manager](user-guide/creating-application/base-config/eso/gcp-eso.md)
- * [HashiCorp Vault](user-guide/creating-application/base-config/eso/hashicorp-eso.md)
- * [GitOps Configuration](user-guide/creating-application/gitops-config.md)
- * [Workflow Editor](user-guide/creating-application/workflow/README.md)
- * [CI Pipeline](user-guide/creating-application/workflow/ci-pipeline.md)
- * [CD Pipeline](user-guide/creating-application/workflow/cd-pipeline.md)
- * [Pre/Post Stages](user-guide/creating-application/workflow/pre-post-tasks.md)
- * [Environment Overrides](user-guide/creating-application/environment-overrides.md)
- * [Deleting Application](user-guide/deleting-application.md)
- * [Build and Deploy](user-guide/deploying-application/README.md)
- * [Triggering CI](user-guide/deploying-application/triggering-ci.md)
- * [Triggering CD](user-guide/deploying-application/triggering-cd.md)
- * [Rollback Deployment](user-guide/deploying-application/rollback-deployment.md)
- * [Applying Labels to Images](user-guide/deploying-application/image-labels-and-comments.md)
- * [App Details](user-guide/app-details/README.md)
- * [App Summary](user-guide/app-details/application-summary.md)
- * [Application Metrics](user-guide/creating-application/app-metrics.md)
- * [Deployment Visibility & Actions](user-guide/app-details/deployment-visibility.md)
- * [App Resource Management](user-guide/app-details/app-resource-management.md)
- * [Using Ephemeral Containers](user-guide/app-details/ephemeral-containers.md)
- * [Application Overview](user-guide/creating-application/overview.md)
-* [Jobs](user-guide/jobs/README.md)
- * [What is Job?](user-guide/jobs/what-is-job.md)
- * [Create a New Job](user-guide/jobs/create-job.md)
- * [Configurations](user-guide/jobs/configurations/README.md)
- * [Source Code](user-guide/jobs/configurations/source-code-job.md)
- * [Workflow Editor](user-guide/jobs/configurations/workflow-editor-job.md)
- * [ConfigMaps & Secrets](user-guide/jobs/configurations/configmap-secret/README.md)
- * [ConfigMaps](user-guide/jobs/configurations/configmap-secret/configmap-job.md)
- * [Secrets](user-guide/jobs/configurations/configmap-secret/secret-job.md)
- * [Environment Overrides](user-guide/jobs/configurations/environment-override-job.md)
- * [Trigger Job](user-guide/jobs/triggering-job.md)
- * [Run History](user-guide/jobs/run-history-job.md)
- * [Job Overview](user-guide/jobs/overview-job.md)
-* [Application Groups](user-guide/application-groups.md)
-* [Software Distribution Hub](user-guide/software-distribution-hub/README.md)
- * [Tenants](user-guide/software-distribution-hub/tenants.md)
- * [Release Hub](user-guide/software-distribution-hub/release-hub.md)
-* [Resource Browser](user-guide/resource-browser/README.md)
- * [Overview Page](user-guide/resource-browser/overview.md)
- * [Discover and Manage Resources](user-guide/resource-browser/manage-resources.md)
- * [Compare & Sync Clusters](user-guide/resource-browser/compare-and-sync.md)
- * [Nodes and Operations](user-guide/resource-browser/nodes.md)
- * [Pod Management and Debugging](user-guide/resource-browser/pods.md)
- * [Resource Recommender](user-guide/resource-browser/resource-recommender.md)
- * [Cluster Terminal](user-guide/resource-browser/cluster-terminal.md)
- * [Add Monitoring Dashboards/Graphs](user-guide/resource-browser/monitoring-graphs.md)
- * [Run Kubectl Commands Locally](user-guide/resource-browser/kubectl-local.md)
- * [Configure GUI Schema](user-guide/operations/edit-gui-schema.md)
- * [Configure Lock Schema](user-guide/operations/edit-lock-schema.md)
-* [Resource Watcher](user-guide/resource-watcher.md)
-* [Chart Store](user-guide/deploy-chart/README.md)
- * [Deploy Charts](user-guide/deploy-chart/deployment-of-charts.md)
- * [Chart Groups](user-guide/deploy-chart/chart-group.md)
-* [Security](user-guide/security-features.md)
- * [Security Scans](user-guide/security-features/security-scans.md)
- * [Security Policies](user-guide/security-features/security-policies.md)
-* [Bulk Edit](user-guide/bulk-update.md)
-* [Integrations](user-guide/integrations/README.md)
- * [Build and Deploy (CI/CD)](user-guide/integrations/build-and-deploy-ci-cd.md)
- * [GitOps (Argo CD)](user-guide/integrations/argocd.md)
- * [Vulnerability Scanning](user-guide/integrations/vulnerability-scanning/README.md)
- * [Clair](user-guide/integrations/vulnerability-scanning/clair.md)
- * [Trivy](user-guide/integrations/vulnerability-scanning/trivy.md)
- * [Notifications](user-guide/integrations/notifications.md)
- * [Monitoring (Grafana)](user-guide/integrations/grafana.md)
-* [Pipeline Plugins](user-guide/plugins/README.md)
- * [Create Your Plugin](user-guide/plugins/create-plugin.md)
- * [Our Plugins](user-guide/plugins/plugin-list.md)
- * [Ansible Runner](user-guide/plugins/ansible-runner.md)
- * [Bitbucket Runner Trigger](user-guide/plugins/bitbucket-runner-trigger.md)
- * [Codacy](user-guide/plugins/codacy.md)
- * [Code-Scan](user-guide/plugins/code-scan.md)
- * [Copacetic](user-guide/plugins/copacetic.md)
- * [Container Image Exporter](user-guide/plugins/container-image-exporter.md)
- * [Copy Container Image](user-guide/plugins/copy-container-image.md)
- * [Cosign](user-guide/plugins/cosign.md)
- * [CraneCopy](user-guide/plugins/crane-copy.md)
- * [Dependency track - Maven & Gradle](user-guide/plugins/dependency-track-maven-gradle.md)
- * [Dependency track - NodeJS](user-guide/plugins/dependency-track-nodejs.md)
- * [Dependency track - Python](user-guide/plugins/dependency-track-python.md)
- * [Devtron CD Trigger](user-guide/plugins/devtron-cd-trigger.md)
- * [Devtron CI Trigger](user-guide/plugins/devtron-ci-trigger.md)
- * [Devtron Job Trigger](user-guide/plugins/devtron-job-trigger.md)
- * [DockerSlim](user-guide/plugins/docker-slim.md)
- * [EKS Create Cluster](user-guide/plugins/eks-create-cluster.md)
- * [GCS Create Bucket](user-guide/plugins/gcs-create-bucket.md)
- * [GitHub Pull Request Updater](user-guide/plugins/github-pull-request-updater.md)
- * [GKE Provisioner](user-guide/plugins/gke-provisioner.md)
- * [GoLang-migrate](user-guide/plugins/golang-migrate.md)
- * [Jenkins](user-guide/plugins/jenkins.md)
- * [Jira Issue Validator](user-guide/plugins/jira-validator.md)
- * [Jira Issue Updater](user-guide/plugins/jira-updater.md)
- * [K6 Load Testing](user-guide/plugins/k6-load-testing.md)
- * [Pull images from container repository](user-guide/plugins/pull-images-from-container-repository.md)
- * [Semgrep](user-guide/plugins/semgrep.md)
- * [SonarQube](user-guide/plugins/sonarqube.md)
- * [SonarQube v1.1.0](user-guide/plugins/sonarqube-v1.1.0.md)
- * [Terraform CLI](user-guide/plugins/terraform-cli.md)
- * [Vulnerability Scanning](user-guide/plugins/vulnerability-scanning.md)
-* [Using Devtron Intelligence](user-guide/devtron-intelligence.md)
-* [Enable GitOps Deployments with FluxCD](user-guide/creating-application/fluxcd.md)
-
-## Resources
-
-* [Glossary](reference/glossary.md)
-* [Upgrade Devtron](setup/upgrade/README.md)
- * [Update Devtron from Devtron UI](setup/upgrade/upgrade-devtron-ui.md)
- * [Upgrade to 1.5.0](setup/upgrade/devtron-upgrade-1.5.0.md)
- * [0.6.x-0.7.x](setup/upgrade/devtron-upgrade-0.6.x-0.7.x.md)
- * [0.5.x-0.6.x](setup/upgrade/devtron-upgrade-0.5.x-0.6.x.md)
- * [0.4.x-0.5.x](setup/upgrade/devtron-upgrade-0.4.x-0.5.x.md)
- * [0.4.x-0.4.x](setup/upgrade/devtron-upgrade-0.4.x-0.4.x.md)
- * [0.3.x-0.4.x](setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md)
- * [0.3.x-0.3.x](setup/upgrade/devtron-upgrade-0.3.x-0.3.x.md)
- * [0.2.x-0.3.x](setup/upgrade/devtron-upgrade-0.2.x-0.3.x.md)
-* [Additional Installation Resources](reference/README.md)
- * [Production Infra Recommendations](setup/install/prod-infra.md)
- * [Advanced Configurations](setup/configurations/configurations-overview.md)
- * [Installation Configurations](setup/install/installation-configuration.md)
- * [Override Configurations](setup/install/override-default-devtron-installation-configs.md)
- * [Ingress Setup](setup/install/ingress-setup.md)
- * [Install Devtron on Air-gapped Environment](setup/install/install-devtron-in-airgapped-environment.md)
- * [Install Devtron Freemium](setup/install/freemium.md)
- * [Devtron Kubernetes Desktop Client](setup/install/install-devtron-Kubernetes-client.md)
- * [Installation Walkthrough on EKS, AKS, GKE](setup/install/demo-tutorials.md)
- * [Backup for Disaster Recovery](setup/install/devtron-backup.md)
- * [FAQs](setup/install/faq-on-installation.md)
-* [Troubleshooting](FAQs/devtron-troubleshoot.md)
-* [Use Cases](user-guide/use-cases/README.md)
- * [Devtron Generic Helm Chart To Run CronJob Or One Time Job](user-guide/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job.md)
- * [Connect SpringBoot with Mysql Database](user-guide/use-cases/connect-springboot-with-mysql-database.md)
- * [Connect Expressjs With Mongodb Database](user-guide/use-cases/connect-expressjs-with-mongodb-database.md)
- * [Connect Django With Mysql Database](user-guide/use-cases/connect-django-with-mysql-database.md)
- * [Pull Helm Charts from OCI Registry](user-guide/use-cases/oci-pull.md)
-* [Telemetry Overview](user-guide/telemetry.md)
-* [Devtron on Graviton](reference/graviton.md)
-* [Command Bar](user-guide/command-bar.md)
-* [Release Notes](https://github.com/devtron-labs/devtron/releases)
-* [Uninstall Devtron](setup/install/uninstall-devtron.md)
diff --git a/docs/cli/README.md b/docs/cli/README.md
new file mode 100644
index 0000000000..e5c5c58f46
--- /dev/null
+++ b/docs/cli/README.md
@@ -0,0 +1,688 @@
+---
+title: Tron CLI
+sidebar_label: Tron CLI
+description: Use Tron (devtron-cli) to automate Devtron application and infrastructure management with YAML.
+---
+
+# Tron CLI
+
+Tron is a command-line tool that automates Devtron application and configuration tasks using modular YAML configuration files.
+
+> **Support status**
+> The CLI is currently validated and supported for the Enterprise edition. Other editions may work but are not officially supported yet.
+
+## Highlights
+
+- Create Devtron applications from YAML
+- Update existing applications
+- Manage environments and pipelines
+- Simple CLI interface
+- Usable as a Python module
+
+## Install
+
+```bash
+pip install devtron-cli
+```
+
+## Quick Start
+
+```bash
+# Create a new application (provide Devtron URL and API token via CLI or environment variables)
+tron --config config.yaml create-app --devtron-url https://devtron.example.com --api-token your-api-token
+
+# Update an existing application
+tron --config config.yaml update-app --devtron-url https://devtron.example.com --api-token your-api-token
+
+# Or set environment variables and omit the URL and token from CLI
+export DEVTRON_URL=https://devtron.example.com
+export DEVTRON_API_TOKEN=your-api-token
+tron --config config.yaml create-app
+```
+
+## Global Options
+
+These options can be used with any command:
+
+| Option | Short | Required | Description | Possible Values |
+|--------|-------|----------|-------------|-----------------|
+| `--config` | `-c` | No | Path to the YAML configuration file | Any valid file path |
+| `--devtron-url` | `-u` | Yes | Devtron URL | Valid Devtron instance URL |
+| `--api-token` | `-t` | Yes | API token | Valid Devtron API token with required access |
+
+## Environment Variables
+
+You can also set the following environment variables instead of providing options on the command line:
+
+| Environment Variable | Description |
+|----------------------|-------------|
+| `DEVTRON_URL` | Devtron URL |
+| `DEVTRON_API_TOKEN` | Devtron API token |
+
+## Commands
+
+### 1. create-app
+
+Creates a new application in Devtron.
+
+```bash
+tron create-app [OPTIONS]
+```
+
+#### Options
+
+| Option | Short | Required | Description | Possible Values |
+|--------|-------|----------|-------------|-----------------|
+| `--config` | `-c` | Yes | Path to the YAML configuration file | Any valid file path |
+| `--devtron-url` | `-u` | Yes | Devtron URL | Valid Devtron instance URL |
+| `--api-token` | `-t` | Yes | API token | Valid Devtron API token with required access |
+
+#### Configuration File Fields
+
+The configuration file should contain the following fields:
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `app_name` | Yes | Name of the application | String |
+| `project_name` | Yes | Name of the project | String |
+| `description` | No | Description of the application | String |
+| `labels` | No | Labels for the application | Array of label objects |
+| `git_repositories` | Yes | Git repository configurations | Array of git repository objects |
+| `build_configurations` | Yes | Build configuration settings | Build configuration object |
+| `config_approval` | No | Configuration approval settings (if enabled) | Object |
+| `base_configurations` | Yes | Base deployment configuration | Base configuration object |
+| `workflows` | Yes | Workflow configurations for CI/CD | Array of workflow objects |
+
+#### Label Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `key` | Yes | Label key | String |
+| `value` | Yes | Label value | String |
+| `propagate` | No | Whether to propagate the label to all resources created in application | `true` or `false` |
+
+#### Git Repository Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `url` | Yes | Git repository URL | Valid Git URL |
+| `git_account_name` | Yes | Name of the git account | String |
+| `checkout_path` | Yes | Path to checkout the repository | String (default: "./") |
+| `fetch_submodules` | No | Whether to fetch submodules | `true` or `false` |
+| `filter_pattern` | No | Filter patterns for files | Array of strings |
+
+#### Build Configuration Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `container_registry_name` | Yes | Name of the container registry | String |
+| `repository_name` | Yes | Name of the repository | String |
+| `target_platform` | No | Target platforms for buildx | Comma-separated platform list |
+| `dockerfile_repository` | Yes | Repository for Dockerfile | String |
+| `build_context` | No | Docker build context | String (default: "./") |
+| `docker_build_args` | No | Docker build arguments | Key-value pairs |
+| `build_type` | Yes | Type of build | `"DockerfileExists"`, `"CreateDockerfile"`, or `"Buildpacks"` |
+| `dockerfile_path` | Yes (if build_type is DockerfileExists) | Path to Dockerfile | String |
+| `language` | Yes (if build_type is CreateDockerfile) | Programming language | String |
+| `language_framework` | Yes (if build_type is CreateDockerfile) | Framework | String |
+| `dockerfile_content` | Yes (if build_type is CreateDockerfile) | Dockerfile content | Multi-line string |
+| `builder_image` | Yes (if build_type is Buildpacks) | Builder image for buildpacks | String |
+| `version` | Yes (if build_type is Buildpacks) | Language version | String |
+
+#### Base Configuration Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `deployment_template` | Yes | Base deployment template | Template object |
+| `config_maps` | No | ConfigMap configurations | Array of ConfigMap objects |
+| `secrets` | No | Secret configurations | Array of Secret objects |
+
+#### Template Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `version` | Yes | Version of the template | `"1.6.0"`, `"4.21.0"`, `"5.0.0"` |
+| `chart_type` | Yes | Type of chart | `"Job & CronJob"`, `"Deployment"`, `"StatefulSet"`, `"GPU-Workload"`, `"Rollout Deployment"` |
+| `use_default` | No | Whether to use default values | `true` or `false` |
+| `values_patch` | No (works only if use_default is true) | Patch/override keys in deployment template | Object |
+
+#### ConfigMap Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `name` | Yes | Name of the ConfigMap | String |
+| `type` | No | Type of ConfigMap | `"volume"` or `"environment"` (default: "environment") |
+| `data` | Yes (if from_file not provided) | Key-value data | Object |
+| `mountPath` | No | Mount path for volume | String |
+| `subPath` | No | Whether to use subPath | `true` or `false` |
+| `filePermission` | No | File permission | String |
+| `external` | No | Whether it's an external ConfigMap | `true` or `false` |
+| `from_file` | Yes (if data not provided) | Path to ConfigMap value file | String |
+
+#### Secret Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `name` | Yes | Name of the Secret | String |
+| `type` | No | Type of Secret | `"volume"` or `"environment"` (default: "environment") |
+| `data` | No | Key-value data | Object |
+| `mountPath` | No | Mount path for volume | String |
+| `subPath` | No | Whether to use subPath | `true` or `false` |
+| `filePermission` | No | File permission | String |
+| `external` | No | Whether it's an external Secret | `true` or `false` |
+| `from_file` | No | Path to Secret value file | String |
+| `roleARN` | No | AWS role ARN | String |
+| `externalType` | No | External secret type | String (for example, `"ESO_AWSSecretsManager"`) |
+| `esoSecretData` | No | ESO secret data | Object |
+
+#### Workflow Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `ci_pipeline` | Yes | CI pipeline configuration | CI Pipeline object |
+| `cd_pipelines` | No | CD pipeline configurations | Array of CD Pipeline objects |
+
+#### CI Pipeline Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `type` | Yes | Type of pipeline | `"CI_JOB"`, `"CI_BUILD"`, `"LINKED"` |
+| `is_manual` | Yes | Whether to trigger the CI pipeline manually | `true` or `false` |
+| `name` | Yes | Name of the CI pipeline | String |
+| `branches` | Yes (unless type is LINKED) | Branches for the git repositories | Array of branch objects |
+| `source_pipeline` | Yes (if type is LINKED) | Name of the source CI pipeline | String |
+| `pre_build_configs` | No | Pre-build configurations | Object (see below) |
+| `post_build_configs` | No | Post-build configurations | Object (see below) |
+
+##### Pre/Post Build Configs Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `tasks` | No | List of build tasks | Array of build task objects |
+| `is_manual` | No | Manual trigger | `true` or `false` (default: `true`) |
+
+##### Build Task Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `type` | Yes | Type of build task | `"plugin"` or `"custom"` |
+| `task_name` | Yes | Name of the task | String |
+| `name` | No | Name of the plugin | String |
+| `version` | No | Plugin version | String |
+| `description` | No | Task description | String |
+| `input_variables` | No | Input variables | Key-value dict or array (custom tasks) |
+| `output_variables` | No | Output variables (custom tasks) | Array of variable objects |
+| `output_directory_paths` | No | Output directories (custom tasks) | Array of strings |
+| `script` | No | Script to execute (custom tasks) | Multi-line string |
+| `container_image` | No | Container image for task | String |
+| `script_mount_path` | No | Script mount path | String |
+| `command` | No | Command to run | String |
+| `args` | No | Command arguments | Array of strings |
+| `ports_mappings` | No | Port mappings | Array of mappings |
+| `script_mount_path_on_container` | No | Script path inside container | String |
+| `directory_mappings` | No | Directory mappings | Array of mappings |
+| `trigger_conditions` | No | Trigger conditions | Array of condition objects |
+| `pass_conditions` | No | Pass conditions | Array of condition objects |
+
+#### Branch Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `repo` | Yes | Repository name | String |
+| `branch` | Yes | Branch name | String |
+| `type` | Yes | Branch type | `"SOURCE_TYPE_BRANCH_FIXED"` |
+| `regex` | No | Regex pattern for branch | String |
+
+#### Build Config Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `type` | Yes | Type of pre or post build config | `"plugin"` or `"custom"` |
+| `name` | No | Name of the plugin to use | String |
+| `version` | No | Version of the plugin to use | String |
+| `description` | No | Task description | String |
+| `input_variables` | No | Input variables | Array of variable objects |
+
+#### Variable Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| Variable name | Yes | Variable name | String |
+| Variable value | Yes | Variable value | String |
+
+#### CD Pipeline Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `name` | No | Name of the CD pipeline | String |
+| `environment_name` | Yes | Name of the environment for deployment | String |
+| `is_manual` | Yes | Whether to trigger the CD pipeline manually | `true` or `false` |
+| `deployment_type` | No | Deployment type | `"helm"`, `"argo_cd"` (default: "helm") |
+| `placement` | No | Placement strategy | `"parallel"`, `"serial"` (default: "parallel") |
+| `deployment_strategies` | No | Deployment strategies | Array of strategy objects |
+| `depends_on` | No | Name of environment to which this pipeline needs to be attached | String |
+| `pre_cd_configs` | No | Pre-deploy configurations | Object (see below) |
+| `post_cd_configs` | No | Post-deploy configurations | Object (see below) |
+| `env_configuration` | No | Environment-specific overrides | Object (see below) |
+
+##### Pre/Post CD Configs Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `tasks` | No | List of build tasks | Array of build task objects |
+| `is_manual` | No | Manual trigger | `true` or `false` (default: `true`) |
+| `run_in_app_env` | No | Run tasks in app environment | `true` or `false` |
+
+##### Env Configuration Object Structure
+
+| Field | Required | Description | Possible Values |
+|-------|----------|-------------|-----------------|
+| `deployment_template` | No | Deployment template override | Object |
+| `config_maps` | No | ConfigMap overrides | Array of ConfigMap objects |
+| `secrets` | No | Secret overrides | Array of Secret objects |
+
+### 2. update-app
+
+Updates an existing application in Devtron.
+
+```bash
+tron update-app [OPTIONS]
+```
+
+#### Options
+
+| Option | Short | Required | Description | Possible Values |
+|--------|-------|----------|-------------|-----------------|
+| `--config` | `-c` | Yes | Path to the YAML configuration file | Any valid file path |
+| `--devtron-url` | `-u` | Yes | Devtron URL | Valid Devtron instance URL |
+| `--api-token` | `-t` | Yes | API token | Valid Devtron API token |
+
+#### Configuration File Fields
+
+The configuration file structure is the same as for `create-app`. Refer to the `create-app` section for details on all possible fields and their values.
+
+### 3. get-app
+
+Gets application configuration from Devtron and outputs it in YAML format.
+
+```bash
+tron get-app --app APPLICATION_NAME [OPTIONS]
+```
+
+#### Options
+
+| Option | Short | Required | Description | Possible Values |
+|--------|-------|----------|-------------|-----------------|
+| `--app` | | Yes | Name of the application to fetch | String |
+| `--config` | `-c` | No | Path to the YAML configuration file | Any valid file path |
+| `--devtron-url` | `-u` | Yes | Devtron URL | Valid Devtron instance URL |
+| `--api-token` | `-t` | Yes | API token | Valid Devtron API token |
+
+## Examples
+
+### Create a new application
+
+```bash
+tron create-app -c config.yaml -u https://devtron.example.com -t your_api_token
+```
+
+### Update an existing application
+
+```bash
+tron update-app -c config.yaml -u https://devtron.example.com -t your_api_token
+```
+
+### Get application configuration
+
+```bash
+tron get-app --app my-app -u https://devtron.example.com -t your_api_token
+```
+
+## Sample Configuration File (create-app)
+
+```yaml
+app_name: "my-application"
+project_name: "my-project"
+description: "Sample application created via Tron"
+labels:
+ - key: "app-usage"
+ value: "platform"
+ propagate: false
+ - key: "owner"
+ value: "devtron-team"
+ propagate: true
+git_repositories:
+ - url: "https://github.com/org/sample-repo.git"
+ git_account_name: "GitHub"
+ checkout_path: "./src"
+ fetch_submodules: false
+ filter_pattern:
+ - "!Dockerfile.old"
+ - url: "https://github.com/org/another-repo.git"
+ git_account_name: "GitHub"
+ checkout_path: "./lib"
+build_configurations:
+ container_registry_name: "company-registry"
+ repository_name: "sample-app"
+ target_platform: "linux/amd64,linux/arm64"
+ dockerfile_repository: "sample-repo"
+ build_context_repository: "sample-repo"
+ build_context: "./"
+ docker_build_args:
+ ENV: production
+ DEBUG: "false"
+ build_type: "DockerfileExists"
+ dockerfile_path: "Dockerfile"
+config_approval:
+ action: proposed
+ if_draft_already_exists: merge
+ notify_all: true
+ specific_approvers:
+ - "devtron@example.com"
+ comments: "Proposed by CLI"
+base_configurations:
+ deployment_template:
+ show_application_metrics: true
+ version: "4.21.0"
+ chart_type: "Deployment"
+ # values_path: "base-deployment.yaml"
+ values_patch:
+ EnvVariables:
+ - name: ENVIRONMENT
+ value: production
+ replicaCount: 3
+ # NOTE: Set either values_path or values_patch (not both).
+ config_maps:
+ - name: app-config-env
+ data:
+ API_URL: "https://api.example.com"
+ FEATURE_FLAG: "enabled"
+ mountPath: /etc/config
+ subPath: true
+ filePermission: "0644"
+ - name: logging-config
+ data:
+ LOG_LEVEL: "INFO"
+ LOG_FORMAT: "json"
+ mountPath: /etc/logging
+ subPath: true
+ filePermission: "0644"
+ - name: external-config-env
+ external: true
+ - name: external-config-volume
+ external: true
+ mountPath: /mnt/external
+ subPath: true
+ filePermission: "0644"
+ - name: configmap-from-file-volume
+ from_file: "config-volume.yaml"
+ mountPath: /mnt/volume
+ subPath: true
+ filePermission: "0644"
+ - name: configmap-from-file-env
+ from_file: "config-env.yaml"
+ secrets:
+ - name: db-credentials
+ from_file: "db-creds.yaml"
+ mountPath: /etc/secrets
+ subPath: false
+ filePermission: "0600"
+ - name: api-secret
+ data:
+ API_KEY: "REDACTED"
+ API_SECRET: "REDACTED"
+ - name: external-secret-env
+ external: true
+ - name: external-secret-vol
+ external: true
+ mountPath: /mnt/secret
+ subPath: true
+ filePermission: "0600"
+ - name: cloud-secret
+ roleARN: "arn:aws:iam::123456789012:role/CloudSecretRole"
+ externalType: ESO_AWSSecretsManager
+ external: true
+ esoSecretData:
+ secretStore:
+ aws:
+ service: SecretsManager
+ region: us-east-1
+ auth:
+ secretRef:
+ accessKeyIDSecretRef:
+ name: aws-secret
+ key: access-key
+ secretAccessKeySecretRef:
+ name: aws-secret
+ key: secret-access-key
+ esoData:
+ - secretKey: prod-db-password
+ key: secrets/prod-db-secrets
+ property: prodPassword
+ esoSecretData:
+ secretStore:
+ aws:
+ service: SecretsManager
+ region: us-east-1
+ auth:
+ secretRef:
+ accessKeyIDSecretRef:
+ name: awssm-secret
+ key: access-key
+ secretAccessKeySecretRef:
+ name: awssm-secret
+ key: secret-access-key
+ esoData:
+ - secretKey: prod-mysql-password
+ key: secrets/prod-mysql-secrets
+ property: prodPassword
+workflows:
+ - ci_pipeline:
+ type: "CI_JOB"
+ is_manual: true
+ name: "test-ci-pipeline"
+ branches:
+ - repo: "test"
+ branch: "master"
+ type: "SOURCE_TYPE_BRANCH_FIXED"
+ regex: ""
+ - repo: "getting-started-node-js"
+ branch: "main"
+ type: "SOURCE_TYPE_BRANCH_FIXED"
+ regex: ""
+ pre_build_configs:
+ tasks:
+ - type: "plugin"
+ task_name: Devtron CI Trigger
+ name: "Devtron CI Trigger"
+ version: "1.1.0"
+ input_variables:
+ DevtronApiToken: "demo-repo"
+ DevtronEndpoint: "https://demo.ai"
+ DevtronApp: "sample-app-10"
+ DevtronEnv: "@{{Keka}}"
+ - type: "custom"
+ task_name: "Create Readme File"
+ description: "Creates a README.md file with project information"
+ input_variables:
+ - key: "PROJECT_NAME"
+ type: "STRING"
+ value: "sample-app"
+ - key: "AUTHOR"
+ type: "STRING"
+ value: "devtron-labs"
+ output_variables:
+ - key: "README_PATH"
+ type: "STRING"
+ description: "Path to the created README file"
+ output_directory_paths:
+ - "/workspace"
+ script: |
+ #!/bin/sh
+ set -e
+ echo "# $PROJECT_NAME" > /workspace/README.md
+ echo "Author: $AUTHOR" >> /workspace/README.md
+ trigger_conditions:
+ - key: "PROJECT_NAME"
+ operator: "!="
+ value: "dummy-project"
+ pass_conditions:
+ - key: "README_PATH"
+ operator: "!="
+ value: "/workspace/README.md"
+ post_build_configs: {}
+ cd_pipelines:
+ - name: my-new-pipeline
+ environment_name: "devtron-demo"
+ is_manual: true
+ deployment_type: "helm"
+ placement: parallel
+ deployment_strategies:
+ - name: "Rolling"
+ strategy:
+ maxSurge: 25%
+ maxUnavailable: 1
+ default: true
+ - name: "recreate"
+ strategy: {}
+ pre_cd_configs:
+ tasks:
+ - type: "plugin"
+ task_name: Devtron CI Trigger
+ name: "Devtron CI Trigger"
+ version: "1.1.0"
+ input_variables:
+ DevtronApiToken: "demo-repo"
+ DevtronEndpoint: "https://demo.ai"
+ DevtronApp: "sample-app-10"
+ DevtronEnv: "@{{Keka}}"
+ - type: "custom"
+ task_name: "Run container task"
+ description: "Runs a container task with the specified image and command"
+ container_image: "alpine:latest"
+ input_variables:
+ - key: "PROJECT_NAME"
+ type: "STRING"
+ value: "sample-app"
+ - key: "AUTHOR"
+ type: "STRING"
+ value: "devtron-labs"
+ output_directory_paths:
+ - "/container_workspace"
+ script: |
+ #!/bin/sh
+ set -e
+ echo "# $PROJECT_NAME" > /container_workspace/README.md
+ echo "Author: $AUTHOR" >> /container_workspace/README.md
+ script_mount_path: "/container_workspace/test.sh"
+ command: "/bin/sh"
+ args: ["-c", "test.sh"]
+ ports_mappings:
+ - 8080:8090
+ script_mount_path_on_container: "/sourcecode/test.sh"
+ directory_mappings:
+ - "/devtroncd:/sourcecode"
+ - type: "plugin"
+ task_name: Code Scan
+ name: "Code Scan"
+ version: "1.0.0"
+ input_variables: {}
+ is_manual: true
+ run_in_app_env: true
+ post_cd_configs:
+ is_manual: true
+ tasks:
+ - type: "plugin"
+ task_name: Code Scan
+ name: "Code Scan"
+ version: "1.0.0"
+ input_variables: {}
+ - type: "plugin"
+ task_name: Devtron CI Trigger
+ name: "Devtron CI Trigger"
+ version: "1.1.0"
+ input_variables:
+ DevtronApiToken: "demo-repo-5"
+ DevtronEndpoint: "https://demo.ai"
+ DevtronApp: "sample-app-10"
+ DevtronEnv: "@{{Keka}}"
+ env_configuration:
+ deployment_template:
+ version: "4.20.0"
+ merge_strategy: "patch"
+ show_application_metrics: true
+ values_patch:
+ replicaCount: 2
+ resources:
+ limits:
+ cpu: "2"
+ memory: "500Mi"
+ requests:
+ cpu: "0.50"
+ memory: "200Mi"
+ config_maps:
+ - name: configmap-from-file-env
+ type: "volume"
+ mountPath: /etc/config
+ filePermission: "0400"
+ subPath: false
+ merge_strategy: "patch"
+ data:
+ key1: overridden-value1
+ key4: value4
+ - name: configmap-from-file-env-new
+ type: "volume"
+ mountPath: /etc/config
+ filePermission: "0400"
+ subPath: false
+ merge_strategy: "replace"
+ data:
+ key1: overridden-value1
+ key4: value4
+ secrets:
+ - name: secret-from-file-env
+ type: "volume"
+ mountPath: /etc/config
+ filePermission: "0400"
+ subPath: false
+ merge_strategy: "replace"
+ from_file: "test-config-map.yaml"
+ data:
+ key1: overridden-value1
+ key4: value4
+ - name: secret-from-file-env-new
+ data:
+ key1: overridden-value1
+ key4: value4
+ - name: demo3-deploy
+ environment_name: "demo3"
+ is_manual: true
+ deployment_type: "helm"
+ - ci_pipeline:
+ type: "LINKED"
+ is_manual: true
+ name: "test-ci-pipeline-2"
+ source_pipeline: "test-ci-pipeline"
+ cd_pipelines:
+ - name: demo2-deploy
+ environment_name: "demo2"
+ is_manual: true
+ deployment_type: "helm"
+ pre_cd_configs:
+ tasks:
+ - type: "plugin"
+ task_name: Devtron CI Trigger
+ name: "Devtron CI Trigger"
+ version: "1.1.0"
+ input_variables:
+ DevtronApiToken: "demo-repo"
+ DevtronEndpoint: "https://demo.ai"
+ DevtronApp: "sample-app-10"
+ DevtronEnv: "@{{Keka}}"
+ - type: "plugin"
+ task_name: Code Scan
+ name: "Code Scan"
+ version: "1.0.0"
+ input_variables: {}
+ is_manual: true
+```
diff --git a/docs/hyperion/FAQs/hyperion-troubleshoot.md b/docs/hyperion/FAQs/hyperion-troubleshoot.md
deleted file mode 100644
index 505a89984d..0000000000
--- a/docs/hyperion/FAQs/hyperion-troubleshoot.md
+++ /dev/null
@@ -1,46 +0,0 @@
-## Troubleshooting Guide
-
-We always try to make your experience of using hyperion as smooth as possible but still if you face any issues, follow the troubleshooting guide given below or join our [discord channel](https://discord.gg/jsRG5qx2gp) if you couldn't find the solution for the issue you are facing.
-
-#### 1. Hyperion Installed but still helm apps are not visible on dashboard
-
-To get helm apps on dashboard, it's important for migration jobs to be completed. To resolve this, check if Jobs are in `1/1 Completed` state by running the command:
-
-```
-kubectl get jobs -n devtroncd
-```
-
-If you see any of the jobs in `0/1 Completed` state then check if it's pod is still running using the following command:
-
-```
-kubectl get pods -n devtroncd
-```
-
-If the pods are in running state, then wait for them to complete and your helm apps should be visible on dashboard after that and if any of job's pod is in `CrashloopBackOff` state, then check the logs of that pod using:
-
-```
-kubectl logs -f -n devtroncd -c
-```
-
-Now, if you get something like `dirty db found` in the logs, then follow the steps given below and if not dirty db, then wait for the pod to automatically restart and complete the job so that helm apps are visible on dashboard.
-
-#### Steps to follow in case you get dirty db found
-
-1. Run this command to get postgresql password - `kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.PG_PASSWORD}' | base64 -d`
-2. Copy the password you get and exec inside postgresql pod using `kubectl exec -it postgresql-postgresql-0 -n devtroncd -- sh`
-3. Now when you are inside postgres, run the command to authenticate postgres user - `psql -U postgres` and enter the password that you got in step 1.
-4. Terminate the connections to databases, delete them and then re-create using the commands given below
-```
-SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = 'orchestrator';
-SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = 'casbin';
-DROP database orchestrator;
-DROP database casbin;
-CREATE database orchestrator;
-CREATE database casbin;
-```
-5. Download the migrator file and re-apply using the following commands:
-```
-kubectl delete -f https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/hyperion/migrator.yaml -n devtroncd
-kubectl apply -f https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/hyperion/migrator.yaml -n devtroncd
-```
-After completing all the steps, you should see the helm apps on dashboard.
\ No newline at end of file
diff --git a/docs/hyperion/README.md b/docs/hyperion/README.md
deleted file mode 100644
index 0b79e314db..0000000000
--- a/docs/hyperion/README.md
+++ /dev/null
@@ -1,44 +0,0 @@
-# Overview
-
-## Hyperion 🦹
-
-### Why Hyperion?
-Hyperion is a lightweight Dashboard for Kubernetes deployments. Packed with full-fledged debugging features enabled with resource grouping for easier debugging for Development and Infra team.
-You can also upgrade to Devtron from Hyperion to enjoy full stack features of Devtron.
-
-> Do check the [Hyperion Installation Guide ⎈](../hyperion/setup/install.md)
-
-### Hyperion Features
-
-#### Application-level resource grouping for easier Debugging
-- Hyperion groups your deployed microservices and displays them in a slick UI for easier monitoring or debugging. Access pod logs and resource manifests right from the Hyperion UI and even edit them!
-
-#### Centralized Access Management
-- Give access to users on Project, Environment and App level and control the level of access with customizable View only and Edit access.
-
-#### Manage and observe Multiple Clusters
-- Manage access of all the Kubernetes clusters (hosted on multiple cloud/on-prem) right from one Hyperion setup.
-
-#### View and Edit Kubernetes Manifests
-- View and Edit all Kubernetes resources right from the Hyperion dashboard.
-
-
----
-
-## Contribute
-
-Check out our [contributing guidelines](https://github.com/devtron-labs/devtron/blob/main/CONTRIBUTING.md). Included are directions for opening issues, coding standards, and notes on our development processes.
-
-
-## Community
-
-Get updates on Devtron's development and chat with the project maintainers, contributors and community members.
-
-* Join the [Discord Community](https://discord.gg/jsRG5qx2gp)
-* Follow [@DevtronL on Twitter](https://twitter.com/DevtronL)
-* Raise feature requests, suggest enhancements, report bugs at [GitHub issues](https://github.com/devtron-labs/devtron/issues)
-* Read the [Devtron blog](https://devtron.ai/blog/)
-
-## Vulnerability Reporting
-
-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 by contacting us at security@devtron.ai.
diff --git a/docs/hyperion/devtron.md b/docs/hyperion/devtron.md
deleted file mode 100644
index 929e28fe68..0000000000
--- a/docs/hyperion/devtron.md
+++ /dev/null
@@ -1,3 +0,0 @@
-Don't worry, your beloved Hyperion is still supported. It has been merged with Devtron and if you want to install Devtron with same functionality as hyperion [visit here](../setup/install/README.md).
-
-Please reach out to us on [discord](https://discord.devtron.ai/) in case of any queries.
\ No newline at end of file
diff --git a/docs/hyperion/setup/install.md b/docs/hyperion/setup/install.md
deleted file mode 100644
index 596d784b51..0000000000
--- a/docs/hyperion/setup/install.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# Install Hyperion using Helm3 (Deprecated)
-
-> **Note**: Hyperion is now Devtron
-
-Before you begin, install [Helm3](https://helm.sh/docs/intro/install/)
-
-{% tabs %}
-{% tab title="Install with default configurations" %}
-```bash
-helm repo add devtron https://helm.devtron.ai
-helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd --set installer.mode=hyperion
-```
-{% endtab %}
-{% endtabs %}
-
-For those countries/users where Github is blocked, you can download the [Hyperion Helm chart](https://s3-ap-southeast-1.amazonaws.com/devtron.ai/devtron-operator-latest.tgz)
-
-
-```bash
-wget https://s3-ap-southeast-1.amazonaws.com/devtron.ai/devtron-operator-latest.tgz
-helm install devtron devtron-operator-latest.tgz --create-namespace --namespace devtroncd --set installer.mode=hyperion
-```
-
-[//]: # (If you are planning to use Hyperion for `production deployments`, please refer to our recommended overrides for [Devtron Installation](override-default-devtron-installation-configs.md).)
-
-[//]: # (## Installation status)
-
-[//]: # ()
-[//]: # (Run following command)
-
-[//]: # ()
-[//]: # (```bash)
-
-[//]: # (kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.status}')
-
-[//]: # (```)
-
-## Access Hyperion dashboard
-
-If you did not provide a **BASE\_URL** during install or have used the default installation, Devtron creates a loadbalancer for you on its own. Use the following command to get the dashboard url.
-
-```text
-kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
-```
-
-You will get result something like below
-
-```text
-[test2@server ~]$ kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
-[map[hostname:aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com]]
-```
-
-The hostname mentioned here \( aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com \) is the Loadbalancer URL where you can access the Devtron dashboard.
-
-**PS:** 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.
-
-| Host | Type | Points to |
-| ---: | :--- | :--- |
-| devtron.yourdomain.com | CNAME | aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com |
-
-### Hyperion Admin credentials
-
-For admin login use username:`admin` and for password run the following command.
-
-```bash
-kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ACD_PASSWORD}' | base64 -d
-```
-
-### Cleaning Hyperion Helm3
-
-Please make sure that you do not have anything inside namespaces devtroncd, devtron-cd devtron-ci and devtron-demo as the below steps will clean everything inside these namespaces
-```
-helm uninstall devtron --namespace devtroncd
-kubectl delete -n devtroncd -f https://raw.githubusercontent.com/devtron-labs/charts/main/charts/devtron/crds/crd-devtron.yaml
-kubectl delete ns devtroncd
-```
diff --git a/docs/hyperion/setup/upgrade-to-devtron.md b/docs/hyperion/setup/upgrade-to-devtron.md
deleted file mode 100644
index 2ed7ff68e6..0000000000
--- a/docs/hyperion/setup/upgrade-to-devtron.md
+++ /dev/null
@@ -1,95 +0,0 @@
-# Upgrade Hyperion to Devtron Full mode
-
-To install Helm3, please check [Installing Helm3](https://helm.sh/docs/intro/install/)
-
-{% tabs %}
-{% tab title="Upgrade with default configurations" %}
-This installation will use Minio for storing build logs and cache.
-
-```bash
-helm upgrade devtron devtron/devtron-operator --namespace devtroncd --set installer.mode=full
-```
-{% endtab %}
-
-{% tab title="Upgrade with AWS S3" %}
-This installation will use AWS s3 buckets for storing build logs and cache
-
-```bash
-helm upgrade devtron devtron/devtron-operator --create-namespace --namespace devtroncd \
---set installer.mode=full \
---set configs.BLOB_STORAGE_PROVIDER=S3 \
---set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
---set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1
-```
-{% endtab %}
-
-{% tab title="Upgrade with Azure Blob Storage" %}
-This installation will use Azure Blob Storage for storing build logs and cache
-
-```bash
-helm upgrade devtron devtron/devtron-operator --create-namespace --namespace devtroncd \
---set installer.mode=full \
---set secrets.AZURE_ACCOUNT_KEY=xxxxxxxxxx \
---set configs.BLOB_STORAGE_PROVIDER=AZURE \
---set configs.AZURE_ACCOUNT_NAME=test-account \
---set configs.AZURE_BLOB_CONTAINER_CI_LOG=ci-log-container \
---set configs.AZURE_BLOB_CONTAINER_CI_CACHE=ci-cache-container
-```
-{% endtab %}
-{% endtabs %}
-
-
-If you are planning to use Devtron for `production deployments`, please refer to our recommended overrides for [Devtron Installation](override-default-devtron-installation-configs.md).
-
-## Installation status
-
-Run following command
-
-```bash
-kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.status}'
-```
-
-The install commands initiates Devtron-operator which spins up all the Devtron micro-services one by one in about 20 mins. You can use the above command to check the status of the installation if the installation is still in progress, it will print `Downloaded`. When the installation is complete, it prints `Applied`.
-
-## Access Devtron dashboard
-
-If you did not provide a **BASE\_URL** during install or have used the default installation, Devtron creates a loadbalancer for you on its own. Use the following command to get the dashboard url.
-
-```text
-kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
-```
-
-You will get result something like below
-
-```text
-[test2@server ~]$ kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
-[map[hostname:aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com]]
-```
-
-The hostname mentioned here \( aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com \) is the Loadbalancer URL where you can access the Devtron dashboard.
-
-**PS:** 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.
-
-| Host | Type | Points to |
-| ---: | :--- | :--- |
-| devtron.yourdomain.com | CNAME | aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com |
-
-### Devtron Admin credentials
-If you are upgrading from Hyperion to Devtron full mode, the admin password does NOT change.
-For admin login use username:`admin` and for password run the following command.
-
-```bash
-kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ACD_PASSWORD}' | base64 -d
-```
-
-### Cleaning Devtron Installer Helm3
-
-Please make sure that you do not have anything inside namespaces devtroncd, devtron-cd devtron-ci and devtron-demo as the below steps will clean everything inside these namespaces
-```
-helm uninstall devtron --namespace devtroncd
-kubectl delete -n devtroncd -f https://raw.githubusercontent.com/devtron-labs/charts/main/charts/devtron/crds/crd-devtron.yaml
-kubectl delete -n argo -f https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/yamls/workflow.yaml
-kubectl delete ns devtroncd devtron-cd devtron-ci devtron-demo
-```
diff --git a/docs/hyperion/user-guide/global-configurations/README.md b/docs/hyperion/user-guide/global-configurations/README.md
deleted file mode 100644
index 8776b6741e..0000000000
--- a/docs/hyperion/user-guide/global-configurations/README.md
+++ /dev/null
@@ -1,13 +0,0 @@
-# Global Configurations
-
-This documentation consists of the Global Configurations available in Devtron.
-
-**Parts of the Documentation**
-
-[Cluster And Environments](cluster-and-environments.md)
-
-[SSO Login Service](sso-login.md)
-
-[User Access](user-access.md)
-
-
diff --git a/docs/hyperion/user-guide/global-configurations/cluster-and-environments.md b/docs/hyperion/user-guide/global-configurations/cluster-and-environments.md
deleted file mode 100644
index 6f48d5e05e..0000000000
--- a/docs/hyperion/user-guide/global-configurations/cluster-and-environments.md
+++ /dev/null
@@ -1,113 +0,0 @@
-# Cluster And Environments
-
-The Global configuration provides a feature of `Cluster & Environment` in which you can add your Kubernetes clusters and environment.
-
-Select the Cluster & Environment section of global configuration and click on `Add Cluster` to add your cluster.
-
-## Add Cluster:
-
-To add a cluster on devtron, you must have superadmin access.
-
-Navigate to the `Global Configurations` → `Clusters and Environments` on devtron and click on `Add Cluster`. Provide the below information to add your kubernetes cluster:
-
-1. Name
-2. Kubernetes Cluster Info
- * Server URL
- * Bearer token
-3. Prometheus Info
- * Prometheus endpoint
- * Basic
- * Username
- * Password
- * Anonymous
- * TLS Key
- * TLS Certificate
-
-
-
-
-### 1. Name
-
-Give a name to your cluster inside the name box.
-
-### 2. Kubernetes Cluster Info
-
-Provide your kubernetes cluster’s credentials.
-
-* **Server URL**
-
-Provide the endpoint/URL of your kubernetes cluster.It is recommended to use a self-hosted URL instead of cloud hosted. Self-hosted URL will provide the following benefits.
-
-**\(a\) Disaster Recovery -** It is not possible to edit the server-url of a cluster. So if you're using an eks url, For eg- ` *****.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. While using a self-hosted url For eg- `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.
-
-**\(b\) Easy cluster migrations -** Cluster url is given in the name of the cloud provider used, so migrating your cluster from one provider to another will result in waste of time and effort. On the other hand, if using a self-hosted url migrations will be easy as the url is of single hosted domain independent of the cloud provider.
-
-* **Bearer token**
-
-Provide your kubernetes cluster’s Bearer token for authentication purposes so that the Devtron tool will be able to talk to your kubernetes cluster and can deploy your application in your kubernetes cluster.Generate the admin token to add the cluster on devtron by running the following command. Please ensure that you have kubectl and jq installed on the bastion that you’re running the command.
-
-```bash
-curl -O https://raw.githubusercontent.com/devtron-labs/utilities/main/kubeconfig-exporter/kubernetes_export_sa.sh && bash kubernetes_export_sa.sh cd-user devtroncd https://raw.githubusercontent.com/devtron-labs/utilities/main/kubeconfig-exporter/clusterrole.yaml
-```
-
-### 3. Prometheus Info
-
-Prometheus is a powerful solution to provide graphical insight into your application behavior. If you want to see your application matrix against your applications deployed in kubernetes, install Prometheus in your kubernetes cluster. The below inputs are required to configure your prometheus into Devtron’s tool.
-
-* **Prometheus endpoint**
-
-Provide the URL of your prometheus. Prometheus supports two types of authentication `Basic` and `Anonymous`. Select the authentication type for your Prometheus setup.
-
-* **Basic**
-
-If you select the `basic` type of authentication then you have to provide the `Username` and `Password` of prometheus for authentication.
-
-* **Anonymous**
-
-If you select `Anonymous` then you do not have to provide any username and password for authentication.
-
-* **TLS Key & TLS Certificate**
-
-TLS key and TLS certificate both options are optional, these options are used when you use a custom URL, in that case, you can pass your TLS key and TLS certificate.
-
-
-### K8s Version
-on saving or update a cluster there is a call to fetch k8s version, it will store corresponding to cluster on db. used in listing api's and app detail page for grafana url.
-
-
-Check the below screenshots to know how it looks like If you select the `Basic` authentication type
-
-
-
-If you select the `Anonymous` authentication type
-
-
-
-Now click on `Save Cluster` to save your cluster information.
-
-### Note:
-
-Your kubernetes cluster gets mapped with the Devtron when you save your kubernetes cluster Configuration. Now the agents of devtron will be installed on your cluster so that the components of devtron can communicate to your cluster. When the agent starts installing on your cluster, you can check the status of the agents in the Cluster & Environment tab also.
-
-
-
-Click on `Details` to check what got installed inside the agents. A new window will be popped up displaying all the details about these agents.
-
-
-
-## Add Environment
-
-Once you have added your cluster in Cluster & Environment, you can add the environment also. Click on `Add Environment`, a window will be opened. Give a name to your environment in the `Environment Name` box and provide a namespace corresponding to your environment in the `Namespace` input box. Now choose if your environment is for Production purposes or for Non-production purposes. Production and Non-production options are only for tagging purposes. Click on `Save` and your environment will be created.
-
-
-
-You can update an already created environment, Select and click on the environment which you want to update. You can only change Production and Non-production options here.
-
-**Note**
-
-You can not change the Environment name and Namespace name.
-
-
-
-Click on `Update` to update your environment.
-
diff --git a/docs/hyperion/user-guide/global-configurations/sso-login.md b/docs/hyperion/user-guide/global-configurations/sso-login.md
deleted file mode 100644
index 884c87077d..0000000000
--- a/docs/hyperion/user-guide/global-configurations/sso-login.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# SSO LOGIN
-## Overview
-
-Once installed Devtron has one built-in `admin` user with super-admin privileges that has complete access to the system. It is recommended to use `admin` user only for initial and global configuration and then switch to local users or configure SSO integration.
-
-Only users with super-admin privileges have access to create SSO configuration. Devtron uses dex for authenticating a user against the identity provider.
-
-To add/edit SSO configuration please go to the left main panel -> Select `Global Configurations` -> Select `SSO Login Services`
-
-## Supported SSO Providers
-
-`LDAP`
-`GitHub`
-`OpenID Connect`
-`Google`
-`Microsoft`
-`OpenShift`
-
-Dex implements connectors that target specific `identity providers`, for each connector configuration user must have created account for the corresponding identity provider and registered an app for client key and secret.
-For examples see
-* https://dexidp.io/docs/connectors/
-* https://dexidp.io/docs/connectors/google/
-
-
-### 1. Create new SSO Configuration
-
-Login as a user with super-admin privileges and go to `Global Configurations` -> `SSO Login Services` and click on any `Identity Provider` and fill the configuration.
-
-Add valid devtron application `URL` where it is hosted.
-
-Fill correct `redirect URL` or `callback URL` from which you have registered with the identity provider in the previous step along with the `client id` and `client secret` shared by the identity provider.
-
-Only single SSO login configuration can be active at one time. Whenever you create or update any SSO config, it will be activated and used by the system and previous configurations will be deleted.
-
-Except for the domain substring, URL and redirectURI should be the same as in the screenshots.
-
-
-
-Select `Save` to create and activate SSO login.
-
-### 2. Update SSO Configuration
-
-SSO configuration can be changed by the user at any later point in time by updating the configuration and clicking on the `Save` button at the bottom right.
-In case of configuration change all users will be logged out of the system and will have to login again.
-
-### 3. Configuration Payload
-
-* `type` : oidc or any platform name such as (google, gitlab, github etc)
-* `name` : identity provider platform name
-* `id` : identity provider platform unique id in string. (refer to dexidp.io)
-* `config` : user can put connector details into this key. platforms may not have same structure but commons are clientID, clientSecret, redirectURI.
-* `hostedDomains` : domains authorized for SSO login.
diff --git a/docs/hyperion/user-guide/global-configurations/user-access.md b/docs/hyperion/user-guide/global-configurations/user-access.md
deleted file mode 100644
index 42adafcb71..0000000000
--- a/docs/hyperion/user-guide/global-configurations/user-access.md
+++ /dev/null
@@ -1,195 +0,0 @@
-# User Access for Hyperion Mode
-
-Like any enterprise product, Devtron supports fine grained access control to the resources
-
-Access can be added to the User either directly or via Groups.
-
-## Access Levels
-Devtron supports 4 levels of access
-1. **View only**: User with `view` only access has the least privilege. This user can only view combination of environments, applications and helm charts on which access has been granted to the user. This user cannot view sensitive data like secrets used in applications or charts.
-2. **View and Edit**: In addition to `view` privilege mentioned in above, user with `View and Edit` permission can edit the resource manifests of permitted applications and helm charts to permitted environments.
-3. **Admin**: User with `admin` access can create, edit, delete and view permitted applications in permitted projects.
-4. **Super Admin**: User with `super admin` privilege has unrestricted access to all Devtron resources. Super admin can create, modify, delete and view any Devtron resource without any restriction; its like Superman without the weakness of Kryptonite. Super Admin can also add and delete user access across any Devtron resource, add delete git repository credentials, docker registry credentials, cluster and environment.
-
-## Visualize using access table (Apps)
-
-| Access Level | View App | Create App | Edit App | Delete App | Trigger App |
-|--|--|--|--|--|--|
-| View | Yes | No | No | No| No |
-| View and Edit | Yes | No | Yes | Yes| Yes |
-|Admin| Yes | Yes | Yes | Yes | Yes |
-|Super Admin| Yes | Yes | Yes | Yes | Yes |
-
-
-## Visualize using access table (Charts)
-| Access Level | View Charts | Install Charts | Edit Charts | Delete Charts |
-|--|--|--|--|--|
-| View | Yes | No | No | No|
-| View and Edit | Yes | No | No | No|
-|Admin| Yes | Yes | Yes | Yes |
-|Super Admin| Yes | Yes | Yes | Yes |
-
-
-## Visualize using access table (User Management)
-| Access Level | Add User Access | Edit User Access | Delete User Access |
-|--|--|--|--|
-|Super Admin| Yes | Yes | Yes |
-
-
-## Visualize using access table (Config Management)
-| Access Level | Add Global Config | Edit Global Config | Delete Global Config |
-|--|--|--|--|
-|Super Admin| Yes | Yes |
-
-
-To control the access of User and Group
-
-Go to the left main panel -> `Select Global Configurations` -> Select `User Access`
-
-## Users
-### 1. Add new user
-
-Click on `Add User`, to add one or multiple users.
-
-
-
-### 2. Search the existing User
-Click on `Search Box`, and type your user's email
-
-
-
-### 3. Create User Permissions
-
-When you click on Add User, you will see 4 options to set permission for users which are as follow:
-
-* Email addresses
-* Assign super admin permissions
-* Group permissions
-* Helm Apps
- * Project
- * Environment
- * Application
- * Permission
-
-## Email addresses:
-
-In the `Email address` box, you have to provide the mail ID of the user to whom you want to give access to your applications.
-
-**`IMP`** Please note that Email address should be same as that in the `email` field in the JWT token returned by OIDC provider.
-
-
-### Assign super admin permissions
-
-If you check the option `Assign super admin permissions`, the user will get full access to your system and the rest of the options will disappear. Please check [above](#access-levels) to see permission levels.
-
-
-
-Click on `Save` and your user will be saved with super admin permissions.
-
-We suggest that super admin privileges should be given to only select few.
-
-If you don’t want to assign super admin permissions then you have to provide the rest of the information.
-
-
-### Group permissions
-
-This is used to assign user to a particular group and user inherits all the permissions granted to this group. The Group permissions section contains a drop-down of all existing groups on which you have access. This is optional field and more than one groups can be selected for a user.
-
-
-
-We will discuss how to create groups in the later section.
-
-### Helm Apps
-
-Access can be given to user by attaching permission directly to his/her email id through the `Helm Apps` section. This section has 4 options to manage the permissions of your users.
-
-* **Project**
-
-Select a project from the drop-down to which you want to give permission to the users. You can select only one project at a time if you want to select more than one project then click `Add row`.
-
-* **Environment or cluster/namespace**
-
-In the `Environment or cluster/namespace` section, you can select one or more than one or all environments at a time. Click on the environment section, you will see a drop-down of your environments and select any environment on which you want to give permission to the user.
-
-**`IMP`** If `all environments` option is selected then user gets access to all current environments and any new environment which gets associated with this application later.
-
-* **Application**
-
-Similarly, you can select `Applications` from the drop-down corresponding to your selected Environments. In this section, you can also give permissions to one or more than one or to all applications at a time.
-
-**`IMP`** If `all applications` option is selected then user gets access to all current applications and any new application which gets associated with this project later.
-
-* **Permission**
-
- Inside the `Permission`, you actually choose which type of permissions you want to give to the users.
-
-There are there different view access levels available for both User and Group as described [above](#access-levels):
-
-
-
-You can add multiple rows, for Helm Apps.
-
-Once you have finished assigning the appropriate permissions for the listed user, Click on `Save`.
-
-### 4. Edit User Permissions
-
-You can edit the user permissions, by clicking on the `downward arrow`.
-
-
-
-Then you can edit the user permissions here.
-
-
-
-After you have done editing the user permissions. Click on `Save`.
-
-If you want to delete the user/users with particular permissions. Click on `Delete`.
-
-## Groups
-
-The advantage of the 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. Users can be added to an existing group to utilize the privileges that it grants. Any access change to group is reflected immediately in user access.
-
-You can select the group which you are creating in the `Group permissions` section inside `Add users`.
-
-### 1. Add new Group
-
-Click on `Add Group`, to create a new group.
-
-
-
-Enter the `Group Name` and `Description`.
-
-
-
-### 2. Create Group Permissions
-
-Once you have given the group name and group description.
-
-Then, control the access permissions of groups in the Helm Apps section. Manage the Project, Environment, Application, and Permission access the same as we discuss in the above users section.
-
-
-
-You can add multiple rows, for the Helm Apps section.
-
-Once you have finished assigning the appropriate permissions for the listed users, Click on `Save`.
-
-### 3. Edit Group Permissions
-
-You can edit the group permissions, by clicking on the `downward arrow.`
-
-
-
-Then you can edit the group permissions here.
-
-
-
-Once you are done editing the group permissions. Click on `Save`.
-
-If you want to delete the groups with particular permissions. Click on `Delete`.
-
-
-### 4. Manage Chart Group Permissions
-
-The chart group permissions for the group will be managed in the same way as for the users. For reference, check Manage chart group permissions for users.
-
-
diff --git a/docs/images/cloning-application/add-new-app.jpg b/docs/images/cloning-application/add-new-app.jpg
deleted file mode 100644
index 130d81ee38..0000000000
Binary files a/docs/images/cloning-application/add-new-app.jpg and /dev/null differ
diff --git a/docs/images/cloning-application/configur-add-new-app.jpg b/docs/images/cloning-application/configur-add-new-app.jpg
deleted file mode 100644
index a2fa304d95..0000000000
Binary files a/docs/images/cloning-application/configur-add-new-app.jpg and /dev/null differ
diff --git a/docs/images/cloning-application/created-clone-app.jpg b/docs/images/cloning-application/created-clone-app.jpg
deleted file mode 100644
index 5770b6bd18..0000000000
Binary files a/docs/images/cloning-application/created-clone-app.jpg and /dev/null differ
diff --git a/docs/images/command-bar/cmd-bar-gif.gif b/docs/images/command-bar/cmd-bar-gif.gif
deleted file mode 100644
index d8b124403f..0000000000
Binary files a/docs/images/command-bar/cmd-bar-gif.gif and /dev/null differ
diff --git a/docs/images/command-bar/cmdbar-workflow-editor-path.png b/docs/images/command-bar/cmdbar-workflow-editor-path.png
deleted file mode 100644
index 0e26f76efb..0000000000
Binary files a/docs/images/command-bar/cmdbar-workflow-editor-path.png and /dev/null differ
diff --git a/docs/images/command-bar/command-bar-parts.png b/docs/images/command-bar/command-bar-parts.png
deleted file mode 100644
index 70d6b65be9..0000000000
Binary files a/docs/images/command-bar/command-bar-parts.png and /dev/null differ
diff --git a/docs/images/creating-application/app-metrics/app-metrics-1.jpg b/docs/images/creating-application/app-metrics/app-metrics-1.jpg
deleted file mode 100644
index 4ee269344d..0000000000
Binary files a/docs/images/creating-application/app-metrics/app-metrics-1.jpg and /dev/null differ
diff --git a/docs/images/creating-application/app-metrics/app-metrics.png b/docs/images/creating-application/app-metrics/app-metrics.png
deleted file mode 100644
index 4aad1ee992..0000000000
Binary files a/docs/images/creating-application/app-metrics/app-metrics.png and /dev/null differ
diff --git a/docs/images/creating-application/config-maps/ad-confgimap.jpg b/docs/images/creating-application/config-maps/ad-confgimap.jpg
deleted file mode 100644
index 752b7de887..0000000000
Binary files a/docs/images/creating-application/config-maps/ad-confgimap.jpg and /dev/null differ
diff --git a/docs/images/creating-application/config-maps/configmap-filepermission-1.png b/docs/images/creating-application/config-maps/configmap-filepermission-1.png
deleted file mode 100644
index b41f25ffe1..0000000000
Binary files a/docs/images/creating-application/config-maps/configmap-filepermission-1.png and /dev/null differ
diff --git a/docs/images/creating-application/config-maps/configmap-mountpath-1.png b/docs/images/creating-application/config-maps/configmap-mountpath-1.png
deleted file mode 100644
index f31a34906d..0000000000
Binary files a/docs/images/creating-application/config-maps/configmap-mountpath-1.png and /dev/null differ
diff --git a/docs/images/creating-application/config-maps/configmap-yaml.jpg b/docs/images/creating-application/config-maps/configmap-yaml.jpg
deleted file mode 100644
index fcb8d1a7e4..0000000000
Binary files a/docs/images/creating-application/config-maps/configmap-yaml.jpg and /dev/null differ
diff --git a/docs/images/creating-application/config-maps/configure-configmap.jpg b/docs/images/creating-application/config-maps/configure-configmap.jpg
deleted file mode 100644
index bf227d0ed2..0000000000
Binary files a/docs/images/creating-application/config-maps/configure-configmap.jpg and /dev/null differ
diff --git a/docs/images/creating-application/config-maps/created-configmap.gif b/docs/images/creating-application/config-maps/created-configmap.gif
deleted file mode 100644
index 63e9dd5f76..0000000000
Binary files a/docs/images/creating-application/config-maps/created-configmap.gif and /dev/null differ
diff --git a/docs/images/creating-application/config-maps/created-configmap.jpg b/docs/images/creating-application/config-maps/created-configmap.jpg
deleted file mode 100644
index 8f289a86b8..0000000000
Binary files a/docs/images/creating-application/config-maps/created-configmap.jpg and /dev/null differ
diff --git a/docs/images/creating-application/config-maps/delete_configmap.png b/docs/images/creating-application/config-maps/delete_configmap.png
deleted file mode 100644
index 99c2d8277b..0000000000
Binary files a/docs/images/creating-application/config-maps/delete_configmap.png and /dev/null differ
diff --git a/docs/images/creating-application/config-maps/update_configmap.png b/docs/images/creating-application/config-maps/update_configmap.png
deleted file mode 100644
index 33c07760f7..0000000000
Binary files a/docs/images/creating-application/config-maps/update_configmap.png and /dev/null differ
diff --git a/docs/images/creating-application/deployment-template/deployment-template.gif b/docs/images/creating-application/deployment-template/deployment-template.gif
deleted file mode 100644
index c0c0681eac..0000000000
Binary files a/docs/images/creating-application/deployment-template/deployment-template.gif and /dev/null differ
diff --git a/docs/images/creating-application/docker-build-configuration/docker-configuration.gif b/docs/images/creating-application/docker-build-configuration/docker-configuration.gif
deleted file mode 100644
index 84b70bec9e..0000000000
Binary files a/docs/images/creating-application/docker-build-configuration/docker-configuration.gif and /dev/null differ
diff --git a/docs/images/creating-application/environment-overrides/configure-env.jpg b/docs/images/creating-application/environment-overrides/configure-env.jpg
deleted file mode 100644
index e7c439402d..0000000000
Binary files a/docs/images/creating-application/environment-overrides/configure-env.jpg and /dev/null differ
diff --git a/docs/images/creating-application/environment-overrides/creating-env.gif b/docs/images/creating-application/environment-overrides/creating-env.gif
deleted file mode 100644
index 5a20f4dce1..0000000000
Binary files a/docs/images/creating-application/environment-overrides/creating-env.gif and /dev/null differ
diff --git a/docs/images/creating-application/git-material/adding-git-material.gif b/docs/images/creating-application/git-material/adding-git-material.gif
deleted file mode 100644
index ac71ed7b8e..0000000000
Binary files a/docs/images/creating-application/git-material/adding-git-material.gif and /dev/null differ
diff --git a/docs/images/creating-application/git-material/git-checkout-path.jpg b/docs/images/creating-application/git-material/git-checkout-path.jpg
deleted file mode 100644
index c0bf3d25c2..0000000000
Binary files a/docs/images/creating-application/git-material/git-checkout-path.jpg and /dev/null differ
diff --git a/docs/images/creating-application/git-material/github_url.png b/docs/images/creating-application/git-material/github_url.png
deleted file mode 100644
index 3b45a16e0a..0000000000
Binary files a/docs/images/creating-application/git-material/github_url.png and /dev/null differ
diff --git a/docs/images/creating-application/secrets/add-secret.png b/docs/images/creating-application/secrets/add-secret.png
deleted file mode 100644
index de8ed05ec5..0000000000
Binary files a/docs/images/creating-application/secrets/add-secret.png and /dev/null differ
diff --git a/docs/images/creating-application/secrets/configure-secrets.jpg b/docs/images/creating-application/secrets/configure-secrets.jpg
deleted file mode 100644
index 0be7c5f02f..0000000000
Binary files a/docs/images/creating-application/secrets/configure-secrets.jpg and /dev/null differ
diff --git a/docs/images/creating-application/secrets/created-secret.gif b/docs/images/creating-application/secrets/created-secret.gif
deleted file mode 100644
index 5fd32b7acd..0000000000
Binary files a/docs/images/creating-application/secrets/created-secret.gif and /dev/null differ
diff --git a/docs/images/creating-application/secrets/delete_secret.png b/docs/images/creating-application/secrets/delete_secret.png
deleted file mode 100644
index 91863fed80..0000000000
Binary files a/docs/images/creating-application/secrets/delete_secret.png and /dev/null differ
diff --git a/docs/images/creating-application/secrets/secret-created.png b/docs/images/creating-application/secrets/secret-created.png
deleted file mode 100644
index 091c44a84d..0000000000
Binary files a/docs/images/creating-application/secrets/secret-created.png and /dev/null differ
diff --git a/docs/images/creating-application/secrets/secret-mountpath-1.png b/docs/images/creating-application/secrets/secret-mountpath-1.png
deleted file mode 100644
index 248d315e81..0000000000
Binary files a/docs/images/creating-application/secrets/secret-mountpath-1.png and /dev/null differ
diff --git a/docs/images/creating-application/secrets/secret-volume-path.jpg b/docs/images/creating-application/secrets/secret-volume-path.jpg
deleted file mode 100644
index d49111d1e6..0000000000
Binary files a/docs/images/creating-application/secrets/secret-volume-path.jpg and /dev/null differ
diff --git a/docs/images/creating-application/secrets/updating_secrets.png b/docs/images/creating-application/secrets/updating_secrets.png
deleted file mode 100644
index a780aa88bc..0000000000
Binary files a/docs/images/creating-application/secrets/updating_secrets.png and /dev/null differ
diff --git a/docs/images/creating-application/workflow-cd-pipeline/cd-pipeline-console.png b/docs/images/creating-application/workflow-cd-pipeline/cd-pipeline-console.png
deleted file mode 100644
index 11b0cfac66..0000000000
Binary files a/docs/images/creating-application/workflow-cd-pipeline/cd-pipeline-console.png and /dev/null differ
diff --git a/docs/images/creating-application/workflow-cd-pipeline/cd_post_build.jpg b/docs/images/creating-application/workflow-cd-pipeline/cd_post_build.jpg
deleted file mode 100644
index 7380924d8f..0000000000
Binary files a/docs/images/creating-application/workflow-cd-pipeline/cd_post_build.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow-cd-pipeline/cd_pre_build.jpg b/docs/images/creating-application/workflow-cd-pipeline/cd_pre_build.jpg
deleted file mode 100644
index f3972fde8f..0000000000
Binary files a/docs/images/creating-application/workflow-cd-pipeline/cd_pre_build.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow-cd-pipeline/configuring-cd-pipeline.png b/docs/images/creating-application/workflow-cd-pipeline/configuring-cd-pipeline.png
deleted file mode 100644
index 662dc14629..0000000000
Binary files a/docs/images/creating-application/workflow-cd-pipeline/configuring-cd-pipeline.png and /dev/null differ
diff --git a/docs/images/creating-application/workflow-cd-pipeline/create-cd-pipeline.png b/docs/images/creating-application/workflow-cd-pipeline/create-cd-pipeline.png
deleted file mode 100644
index 310866d015..0000000000
Binary files a/docs/images/creating-application/workflow-cd-pipeline/create-cd-pipeline.png and /dev/null differ
diff --git a/docs/images/creating-application/workflow-cd-pipeline/created-cd-pipeline.png b/docs/images/creating-application/workflow-cd-pipeline/created-cd-pipeline.png
deleted file mode 100644
index 50aeaae6e9..0000000000
Binary files a/docs/images/creating-application/workflow-cd-pipeline/created-cd-pipeline.png and /dev/null differ
diff --git a/docs/images/creating-application/workflow-cd-pipeline/edit_cd_pipeline.jpg b/docs/images/creating-application/workflow-cd-pipeline/edit_cd_pipeline.jpg
deleted file mode 100644
index 2c1bc57afe..0000000000
Binary files a/docs/images/creating-application/workflow-cd-pipeline/edit_cd_pipeline.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow-cd-pipeline/update_pipeline_cd.jpg b/docs/images/creating-application/workflow-cd-pipeline/update_pipeline_cd.jpg
deleted file mode 100644
index 3ec0673c15..0000000000
Binary files a/docs/images/creating-application/workflow-cd-pipeline/update_pipeline_cd.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow-ci-pipeline/ci-yaml.jpg b/docs/images/creating-application/workflow-ci-pipeline/ci-yaml.jpg
deleted file mode 100644
index 986f58e63e..0000000000
Binary files a/docs/images/creating-application/workflow-ci-pipeline/ci-yaml.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow-ci-pipeline/edit_pipeline.jpg b/docs/images/creating-application/workflow-ci-pipeline/edit_pipeline.jpg
deleted file mode 100644
index ac4269dc0d..0000000000
Binary files a/docs/images/creating-application/workflow-ci-pipeline/edit_pipeline.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow-ci-pipeline/external_pipeline.jpg b/docs/images/creating-application/workflow-ci-pipeline/external_pipeline.jpg
deleted file mode 100644
index 9b038ae820..0000000000
Binary files a/docs/images/creating-application/workflow-ci-pipeline/external_pipeline.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow-ci-pipeline/linked.jpg b/docs/images/creating-application/workflow-ci-pipeline/linked.jpg
deleted file mode 100644
index d185f51906..0000000000
Binary files a/docs/images/creating-application/workflow-ci-pipeline/linked.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow-ci-pipeline/post_build.jpg b/docs/images/creating-application/workflow-ci-pipeline/post_build.jpg
deleted file mode 100644
index 398d64920d..0000000000
Binary files a/docs/images/creating-application/workflow-ci-pipeline/post_build.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow-ci-pipeline/pre_build.jpg b/docs/images/creating-application/workflow-ci-pipeline/pre_build.jpg
deleted file mode 100644
index 759c0a7b87..0000000000
Binary files a/docs/images/creating-application/workflow-ci-pipeline/pre_build.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow-ci-pipeline/update_pipeline_ci.jpg b/docs/images/creating-application/workflow-ci-pipeline/update_pipeline_ci.jpg
deleted file mode 100644
index 0cc6127338..0000000000
Binary files a/docs/images/creating-application/workflow-ci-pipeline/update_pipeline_ci.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow/add-workflow.png b/docs/images/creating-application/workflow/add-workflow.png
deleted file mode 100644
index fcab99f7dd..0000000000
Binary files a/docs/images/creating-application/workflow/add-workflow.png and /dev/null differ
diff --git a/docs/images/creating-application/workflow/create-workflow.jpg b/docs/images/creating-application/workflow/create-workflow.jpg
deleted file mode 100644
index 91edff4a29..0000000000
Binary files a/docs/images/creating-application/workflow/create-workflow.jpg and /dev/null differ
diff --git a/docs/images/creating-application/workflow/workflow.gif b/docs/images/creating-application/workflow/workflow.gif
deleted file mode 100644
index 80428dbe95..0000000000
Binary files a/docs/images/creating-application/workflow/workflow.gif and /dev/null differ
diff --git a/docs/images/debugging-deployment-and-monitoring/app-details-application-object-ingress.png b/docs/images/debugging-deployment-and-monitoring/app-details-application-object-ingress.png
deleted file mode 100644
index def5ff8f6e..0000000000
Binary files a/docs/images/debugging-deployment-and-monitoring/app-details-application-object-ingress.png and /dev/null differ
diff --git a/docs/images/debugging-deployment-and-monitoring/app-details-application-object.png b/docs/images/debugging-deployment-and-monitoring/app-details-application-object.png
deleted file mode 100644
index b3b44ec533..0000000000
Binary files a/docs/images/debugging-deployment-and-monitoring/app-details-application-object.png and /dev/null differ
diff --git a/docs/images/debugging-deployment-and-monitoring/app-details-events.jpg b/docs/images/debugging-deployment-and-monitoring/app-details-events.jpg
deleted file mode 100644
index 80eeb0405f..0000000000
Binary files a/docs/images/debugging-deployment-and-monitoring/app-details-events.jpg and /dev/null differ
diff --git a/docs/images/debugging-deployment-and-monitoring/app-details-logs.jpg b/docs/images/debugging-deployment-and-monitoring/app-details-logs.jpg
deleted file mode 100644
index 82816b1f4a..0000000000
Binary files a/docs/images/debugging-deployment-and-monitoring/app-details-logs.jpg and /dev/null differ
diff --git a/docs/images/debugging-deployment-and-monitoring/app-details-manifest.jpg b/docs/images/debugging-deployment-and-monitoring/app-details-manifest.jpg
deleted file mode 100644
index 3a7d5152d1..0000000000
Binary files a/docs/images/debugging-deployment-and-monitoring/app-details-manifest.jpg and /dev/null differ
diff --git a/docs/images/debugging-deployment-and-monitoring/debbug-app-details.jpg b/docs/images/debugging-deployment-and-monitoring/debbug-app-details.jpg
deleted file mode 100644
index af002af7d5..0000000000
Binary files a/docs/images/debugging-deployment-and-monitoring/debbug-app-details.jpg and /dev/null differ
diff --git a/docs/images/deleting-application/deleting-delete-application.jpg b/docs/images/deleting-application/deleting-delete-application.jpg
deleted file mode 100644
index a2a6936ae6..0000000000
Binary files a/docs/images/deleting-application/deleting-delete-application.jpg and /dev/null differ
diff --git a/docs/images/deleting-application/deleting-warnning.jpg b/docs/images/deleting-application/deleting-warnning.jpg
deleted file mode 100644
index 26e169d91d..0000000000
Binary files a/docs/images/deleting-application/deleting-warnning.jpg and /dev/null differ
diff --git a/docs/images/deleting-application/deleting-workflow.jpg b/docs/images/deleting-application/deleting-workflow.jpg
deleted file mode 100644
index 8ef88434b1..0000000000
Binary files a/docs/images/deleting-application/deleting-workflow.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/chart-store.jpg b/docs/images/deploy-chart/overview-of-charts/chart-store.jpg
deleted file mode 100644
index ae770e8353..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/chart-store.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/create_group.jpg b/docs/images/deploy-chart/overview-of-charts/create_group.jpg
deleted file mode 100644
index c42be22bed..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/create_group.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/custom.jpg b/docs/images/deploy-chart/overview-of-charts/custom.jpg
deleted file mode 100644
index 0efc01204b..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/custom.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/custom1.jpg b/docs/images/deploy-chart/overview-of-charts/custom1.jpg
deleted file mode 100644
index a5bbf7678a..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/custom1.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/custom_val.jpg b/docs/images/deploy-chart/overview-of-charts/custom_val.jpg
deleted file mode 100644
index 522ae8a957..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/custom_val.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/depchart4config.jpg b/docs/images/deploy-chart/overview-of-charts/depchart4config.jpg
deleted file mode 100644
index 3848c70048..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/depchart4config.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/depchart4readme.jpg b/docs/images/deploy-chart/overview-of-charts/depchart4readme.jpg
deleted file mode 100644
index f19b9ec829..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/depchart4readme.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/depchartdeployedredo.jpg b/docs/images/deploy-chart/overview-of-charts/depchartdeployedredo.jpg
deleted file mode 100644
index 22e53d76a2..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/depchartdeployedredo.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/depchartreconfig.jpg b/docs/images/deploy-chart/overview-of-charts/depchartreconfig.jpg
deleted file mode 100644
index 7bbc92df9a..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/depchartreconfig.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/deploy-chart-store.jpg b/docs/images/deploy-chart/overview-of-charts/deploy-chart-store.jpg
deleted file mode 100644
index c69e923526..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/deploy-chart-store.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/deploy-chart.jpg b/docs/images/deploy-chart/overview-of-charts/deploy-chart.jpg
deleted file mode 100644
index 68df9c9cbc..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/deploy-chart.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/edit_chart1.jpg b/docs/images/deploy-chart/overview-of-charts/edit_chart1.jpg
deleted file mode 100644
index 6c5d90e38d..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/edit_chart1.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/edit_group.jpg b/docs/images/deploy-chart/overview-of-charts/edit_group.jpg
deleted file mode 100644
index 8490838613..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/edit_group.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/edit_group2.jpg b/docs/images/deploy-chart/overview-of-charts/edit_group2.jpg
deleted file mode 100644
index e592ee4875..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/edit_group2.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/readme.jpg b/docs/images/deploy-chart/overview-of-charts/readme.jpg
deleted file mode 100644
index 08c4da0ca6..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/readme.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/screen2.jpg b/docs/images/deploy-chart/overview-of-charts/screen2.jpg
deleted file mode 100644
index c3d05b9280..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/screen2.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/select_charts.jpg b/docs/images/deploy-chart/overview-of-charts/select_charts.jpg
deleted file mode 100644
index 46f6495d7b..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/select_charts.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/select_charts2.jpg b/docs/images/deploy-chart/overview-of-charts/select_charts2.jpg
deleted file mode 100644
index 6954e5d2cb..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/select_charts2.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/update-and-deploy.jpg b/docs/images/deploy-chart/overview-of-charts/update-and-deploy.jpg
deleted file mode 100644
index 8a56fb4a6b..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/update-and-deploy.jpg and /dev/null differ
diff --git a/docs/images/deploy-chart/overview-of-charts/values.jpg b/docs/images/deploy-chart/overview-of-charts/values.jpg
deleted file mode 100644
index efe282fe78..0000000000
Binary files a/docs/images/deploy-chart/overview-of-charts/values.jpg and /dev/null differ
diff --git a/docs/images/deploying-application/triggering-cd/cd-deploy-console.jpg b/docs/images/deploying-application/triggering-cd/cd-deploy-console.jpg
deleted file mode 100644
index 2548604f02..0000000000
Binary files a/docs/images/deploying-application/triggering-cd/cd-deploy-console.jpg and /dev/null differ
diff --git a/docs/images/deploying-application/triggering-cd/deployed-app-details.jpg b/docs/images/deploying-application/triggering-cd/deployed-app-details.jpg
deleted file mode 100644
index a23e37662f..0000000000
Binary files a/docs/images/deploying-application/triggering-cd/deployed-app-details.jpg and /dev/null differ
diff --git a/docs/images/deploying-application/triggering-cd/trigger-select-image.jpg b/docs/images/deploying-application/triggering-cd/trigger-select-image.jpg
deleted file mode 100644
index 67b393d08f..0000000000
Binary files a/docs/images/deploying-application/triggering-cd/trigger-select-image.jpg and /dev/null differ
diff --git a/docs/images/deploying-application/triggering-ci/ci-build-histroy-artifact.jpg b/docs/images/deploying-application/triggering-ci/ci-build-histroy-artifact.jpg
deleted file mode 100644
index 0fd1507763..0000000000
Binary files a/docs/images/deploying-application/triggering-ci/ci-build-histroy-artifact.jpg and /dev/null differ
diff --git a/docs/images/deploying-application/triggering-ci/ci-build-histroy-source-code.jpg b/docs/images/deploying-application/triggering-ci/ci-build-histroy-source-code.jpg
deleted file mode 100644
index 8e41509859..0000000000
Binary files a/docs/images/deploying-application/triggering-ci/ci-build-histroy-source-code.jpg and /dev/null differ
diff --git a/docs/images/deploying-application/triggering-ci/ci-build-histroy.jpg b/docs/images/deploying-application/triggering-ci/ci-build-histroy.jpg
deleted file mode 100644
index c32a6648da..0000000000
Binary files a/docs/images/deploying-application/triggering-ci/ci-build-histroy.jpg and /dev/null differ
diff --git a/docs/images/deploying-application/triggering-ci/running-build.jpg b/docs/images/deploying-application/triggering-ci/running-build.jpg
deleted file mode 100644
index 50bf1f81ef..0000000000
Binary files a/docs/images/deploying-application/triggering-ci/running-build.jpg and /dev/null differ
diff --git a/docs/images/deploying-application/triggering-ci/start-build.jpg b/docs/images/deploying-application/triggering-ci/start-build.jpg
deleted file mode 100644
index 5aed0bb481..0000000000
Binary files a/docs/images/deploying-application/triggering-ci/start-build.jpg and /dev/null differ
diff --git a/docs/images/deploying-application/triggering-ci/trigger-console.jpg b/docs/images/deploying-application/triggering-ci/trigger-console.jpg
deleted file mode 100644
index da9501605e..0000000000
Binary files a/docs/images/deploying-application/triggering-ci/trigger-console.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/chart-repo/gc-add-chart.png b/docs/images/global-configurations/chart-repo/gc-add-chart.png
deleted file mode 100644
index 13f5917a98..0000000000
Binary files a/docs/images/global-configurations/chart-repo/gc-add-chart.png and /dev/null differ
diff --git a/docs/images/global-configurations/chart-repo/gc-chart-config-password.png b/docs/images/global-configurations/chart-repo/gc-chart-config-password.png
deleted file mode 100644
index e2eb9ffe21..0000000000
Binary files a/docs/images/global-configurations/chart-repo/gc-chart-config-password.png and /dev/null differ
diff --git a/docs/images/global-configurations/chart-repo/gc-chart-configure-anonymous.png b/docs/images/global-configurations/chart-repo/gc-chart-configure-anonymous.png
deleted file mode 100644
index 335f783040..0000000000
Binary files a/docs/images/global-configurations/chart-repo/gc-chart-configure-anonymous.png and /dev/null differ
diff --git a/docs/images/global-configurations/chart-repo/gc-chart-configure-user.png b/docs/images/global-configurations/chart-repo/gc-chart-configure-user.png
deleted file mode 100644
index e609674df4..0000000000
Binary files a/docs/images/global-configurations/chart-repo/gc-chart-configure-user.png and /dev/null differ
diff --git a/docs/images/global-configurations/chart-repo/gc-chart-list.png b/docs/images/global-configurations/chart-repo/gc-chart-list.png
deleted file mode 100644
index 2bfbaf559e..0000000000
Binary files a/docs/images/global-configurations/chart-repo/gc-chart-list.png and /dev/null differ
diff --git a/docs/images/global-configurations/chart-repo/gc-edit-chart.png b/docs/images/global-configurations/chart-repo/gc-edit-chart.png
deleted file mode 100644
index cc0de6e0e3..0000000000
Binary files a/docs/images/global-configurations/chart-repo/gc-edit-chart.png and /dev/null differ
diff --git a/docs/images/global-configurations/cluster-and-environments/gc-cluster-add-environment.png b/docs/images/global-configurations/cluster-and-environments/gc-cluster-add-environment.png
deleted file mode 100644
index e8b4f0f77d..0000000000
Binary files a/docs/images/global-configurations/cluster-and-environments/gc-cluster-add-environment.png and /dev/null differ
diff --git a/docs/images/global-configurations/cluster-and-environments/gc-cluster-add.png b/docs/images/global-configurations/cluster-and-environments/gc-cluster-add.png
deleted file mode 100644
index b3e2392848..0000000000
Binary files a/docs/images/global-configurations/cluster-and-environments/gc-cluster-add.png and /dev/null differ
diff --git a/docs/images/global-configurations/cluster-and-environments/gc-cluster-agents-details.png b/docs/images/global-configurations/cluster-and-environments/gc-cluster-agents-details.png
deleted file mode 100644
index 840e0c2b6a..0000000000
Binary files a/docs/images/global-configurations/cluster-and-environments/gc-cluster-agents-details.png and /dev/null differ
diff --git a/docs/images/global-configurations/cluster-and-environments/gc-cluster-agents.png b/docs/images/global-configurations/cluster-and-environments/gc-cluster-agents.png
deleted file mode 100644
index a9f46638ae..0000000000
Binary files a/docs/images/global-configurations/cluster-and-environments/gc-cluster-agents.png and /dev/null differ
diff --git a/docs/images/global-configurations/cluster-and-environments/gc-cluster-configure-anonymous.png b/docs/images/global-configurations/cluster-and-environments/gc-cluster-configure-anonymous.png
deleted file mode 100644
index 7e95887c89..0000000000
Binary files a/docs/images/global-configurations/cluster-and-environments/gc-cluster-configure-anonymous.png and /dev/null differ
diff --git a/docs/images/global-configurations/cluster-and-environments/gc-cluster-configure.png b/docs/images/global-configurations/cluster-and-environments/gc-cluster-configure.png
deleted file mode 100644
index d60071cfd5..0000000000
Binary files a/docs/images/global-configurations/cluster-and-environments/gc-cluster-configure.png and /dev/null differ
diff --git a/docs/images/global-configurations/cluster-and-environments/gc-cluster-update-environment.png b/docs/images/global-configurations/cluster-and-environments/gc-cluster-update-environment.png
deleted file mode 100644
index 43535e0441..0000000000
Binary files a/docs/images/global-configurations/cluster-and-environments/gc-cluster-update-environment.png and /dev/null differ
diff --git a/docs/images/global-configurations/docker-registries/gc-docker-add.png b/docs/images/global-configurations/docker-registries/gc-docker-add.png
deleted file mode 100644
index 555de5f6d7..0000000000
Binary files a/docs/images/global-configurations/docker-registries/gc-docker-add.png and /dev/null differ
diff --git a/docs/images/global-configurations/docker-registries/gc-docker-configure-aws.png b/docs/images/global-configurations/docker-registries/gc-docker-configure-aws.png
deleted file mode 100644
index e5efe105fe..0000000000
Binary files a/docs/images/global-configurations/docker-registries/gc-docker-configure-aws.png and /dev/null differ
diff --git a/docs/images/global-configurations/docker-registries/gc-docker-configure-docker-hub.png b/docs/images/global-configurations/docker-registries/gc-docker-configure-docker-hub.png
deleted file mode 100644
index e88d447b80..0000000000
Binary files a/docs/images/global-configurations/docker-registries/gc-docker-configure-docker-hub.png and /dev/null differ
diff --git a/docs/images/global-configurations/docker-registries/gc-docker-configure-other.png b/docs/images/global-configurations/docker-registries/gc-docker-configure-other.png
deleted file mode 100644
index 08f95215b0..0000000000
Binary files a/docs/images/global-configurations/docker-registries/gc-docker-configure-other.png and /dev/null differ
diff --git a/docs/images/global-configurations/git-accounts/gc-add-gitaccount.png b/docs/images/global-configurations/git-accounts/gc-add-gitaccount.png
deleted file mode 100644
index d5549dfc3d..0000000000
Binary files a/docs/images/global-configurations/git-accounts/gc-add-gitaccount.png and /dev/null differ
diff --git a/docs/images/global-configurations/git-accounts/gc-added-git-accounts.png b/docs/images/global-configurations/git-accounts/gc-added-git-accounts.png
deleted file mode 100644
index 84c0f259cd..0000000000
Binary files a/docs/images/global-configurations/git-accounts/gc-added-git-accounts.png and /dev/null differ
diff --git a/docs/images/global-configurations/git-accounts/gc-edit-git-account.png b/docs/images/global-configurations/git-accounts/gc-edit-git-account.png
deleted file mode 100644
index 97b596c545..0000000000
Binary files a/docs/images/global-configurations/git-accounts/gc-edit-git-account.png and /dev/null differ
diff --git a/docs/images/global-configurations/git-accounts/gc-git-account-configure-password.png b/docs/images/global-configurations/git-accounts/gc-git-account-configure-password.png
deleted file mode 100644
index 2b45ad3345..0000000000
Binary files a/docs/images/global-configurations/git-accounts/gc-git-account-configure-password.png and /dev/null differ
diff --git a/docs/images/global-configurations/git-accounts/gc-git-account-configure-user-auth.png b/docs/images/global-configurations/git-accounts/gc-git-account-configure-user-auth.png
deleted file mode 100644
index d7bb5c7a4b..0000000000
Binary files a/docs/images/global-configurations/git-accounts/gc-git-account-configure-user-auth.png and /dev/null differ
diff --git a/docs/images/global-configurations/git-accounts/gc-git-account-configure.png b/docs/images/global-configurations/git-accounts/gc-git-account-configure.png
deleted file mode 100644
index 7716dba60d..0000000000
Binary files a/docs/images/global-configurations/git-accounts/gc-git-account-configure.png and /dev/null differ
diff --git a/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification-configuration-select-event.jpg b/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification-configuration-select-event.jpg
deleted file mode 100644
index 87cb86ebfc..0000000000
Binary files a/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification-configuration-select-event.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification-configuration-select-event2.jpg b/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification-configuration-select-event2.jpg
deleted file mode 100644
index db9e313880..0000000000
Binary files a/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification-configuration-select-event2.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification-configuration.jpg b/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification-configuration.jpg
deleted file mode 100644
index 24470c8786..0000000000
Binary files a/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification-configuration.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification.jpg b/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification.jpg
deleted file mode 100644
index 9a8244e5c3..0000000000
Binary files a/docs/images/global-configurations/manage-notification/gc-noitfication-add-notification.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-add-slack.jpg b/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-add-slack.jpg
deleted file mode 100644
index 95897b3c40..0000000000
Binary files a/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-add-slack.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-add.jpg b/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-add.jpg
deleted file mode 100644
index d4719595e8..0000000000
Binary files a/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-add.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-configure-slack.jpg b/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-configure-slack.jpg
deleted file mode 100644
index 82eebc4eb6..0000000000
Binary files a/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-configure-slack.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-ses-confige.jpg b/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-ses-confige.jpg
deleted file mode 100644
index ec208171f3..0000000000
Binary files a/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-ses-confige.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-tab.jpg b/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-tab.jpg
deleted file mode 100644
index bb3dc5d3a9..0000000000
Binary files a/docs/images/global-configurations/manage-notification/gc-noitfication-condfiguration-tab.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/projects/gc-project.png b/docs/images/global-configurations/projects/gc-project.png
deleted file mode 100644
index 470fdc831f..0000000000
Binary files a/docs/images/global-configurations/projects/gc-project.png and /dev/null differ
diff --git a/docs/images/global-configurations/user-access/gc-user-access-add-group-configure.jpg b/docs/images/global-configurations/user-access/gc-user-access-add-group-configure.jpg
deleted file mode 100644
index 9a57485cc7..0000000000
Binary files a/docs/images/global-configurations/user-access/gc-user-access-add-group-configure.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/user-access/gc-user-access-add-group-edit-configure.jpg b/docs/images/global-configurations/user-access/gc-user-access-add-group-edit-configure.jpg
deleted file mode 100644
index 642ac38839..0000000000
Binary files a/docs/images/global-configurations/user-access/gc-user-access-add-group-edit-configure.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/user-access/gc-user-access-add-group.jpg b/docs/images/global-configurations/user-access/gc-user-access-add-group.jpg
deleted file mode 100644
index cca177a83b..0000000000
Binary files a/docs/images/global-configurations/user-access/gc-user-access-add-group.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/user-access/gc-user-access-add-user.jpg b/docs/images/global-configurations/user-access/gc-user-access-add-user.jpg
deleted file mode 100644
index d40e964fef..0000000000
Binary files a/docs/images/global-configurations/user-access/gc-user-access-add-user.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/user-access/gc-user-access-configure-chart-permission-edit.jpg b/docs/images/global-configurations/user-access/gc-user-access-configure-chart-permission-edit.jpg
deleted file mode 100644
index f2fde3f4c8..0000000000
Binary files a/docs/images/global-configurations/user-access/gc-user-access-configure-chart-permission-edit.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/user-access/gc-user-access-configure-chart-permission-select-chart.jpg b/docs/images/global-configurations/user-access/gc-user-access-configure-chart-permission-select-chart.jpg
deleted file mode 100644
index a717ee1e61..0000000000
Binary files a/docs/images/global-configurations/user-access/gc-user-access-configure-chart-permission-select-chart.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/user-access/gc-user-access-configure-chart-permission.jpg b/docs/images/global-configurations/user-access/gc-user-access-configure-chart-permission.jpg
deleted file mode 100644
index 0603bba777..0000000000
Binary files a/docs/images/global-configurations/user-access/gc-user-access-configure-chart-permission.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/user-access/gc-user-access-configure-direct-permission.jpg b/docs/images/global-configurations/user-access/gc-user-access-configure-direct-permission.jpg
deleted file mode 100644
index 89a64e7952..0000000000
Binary files a/docs/images/global-configurations/user-access/gc-user-access-configure-direct-permission.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/user-access/gc-user-access-edit-user-permission.jpg b/docs/images/global-configurations/user-access/gc-user-access-edit-user-permission.jpg
deleted file mode 100644
index 36500c1408..0000000000
Binary files a/docs/images/global-configurations/user-access/gc-user-access-edit-user-permission.jpg and /dev/null differ
diff --git a/docs/images/global-configurations/user-access/gc-user-access-superadmin-user.png b/docs/images/global-configurations/user-access/gc-user-access-superadmin-user.png
deleted file mode 100644
index 99a4ca870c..0000000000
Binary files a/docs/images/global-configurations/user-access/gc-user-access-superadmin-user.png and /dev/null differ
diff --git a/docs/images/namespaces-and-environments/environments1.jpg b/docs/images/namespaces-and-environments/environments1.jpg
deleted file mode 100644
index d16d7e20ed..0000000000
Binary files a/docs/images/namespaces-and-environments/environments1.jpg and /dev/null differ
diff --git a/docs/images/security-features/security-feature-app-details-vulnerability.png b/docs/images/security-features/security-feature-app-details-vulnerability.png
deleted file mode 100644
index 8629c46d47..0000000000
Binary files a/docs/images/security-features/security-feature-app-details-vulnerability.png and /dev/null differ
diff --git a/docs/images/security-features/security-feature-build-history-security.png b/docs/images/security-features/security-feature-build-history-security.png
deleted file mode 100644
index f2569c96b8..0000000000
Binary files a/docs/images/security-features/security-feature-build-history-security.png and /dev/null differ
diff --git a/docs/images/security-features/security-feature-deployed-image-1.png b/docs/images/security-features/security-feature-deployed-image-1.png
deleted file mode 100755
index 1c32fa06fb..0000000000
Binary files a/docs/images/security-features/security-feature-deployed-image-1.png and /dev/null differ
diff --git a/docs/images/security-features/security-feature-deployed-image-security.png b/docs/images/security-features/security-feature-deployed-image-security.png
deleted file mode 100644
index 418278859c..0000000000
Binary files a/docs/images/security-features/security-feature-deployed-image-security.png and /dev/null differ
diff --git a/docs/images/security-features/security-feature-deployed-image.png b/docs/images/security-features/security-feature-deployed-image.png
deleted file mode 100644
index b93511e98d..0000000000
Binary files a/docs/images/security-features/security-feature-deployed-image.png and /dev/null differ
diff --git a/docs/images/security-features/security-feature-global-security-policies-global.png b/docs/images/security-features/security-feature-global-security-policies-global.png
deleted file mode 100644
index a533ffc703..0000000000
Binary files a/docs/images/security-features/security-feature-global-security-policies-global.png and /dev/null differ
diff --git a/docs/images/security-features/security-feature-global-security-policies.png b/docs/images/security-features/security-feature-global-security-policies.png
deleted file mode 100644
index 5bb2289746..0000000000
Binary files a/docs/images/security-features/security-feature-global-security-policies.png and /dev/null differ
diff --git a/docs/images/security-features/security-feature-securitytab-list-vulnerability.png b/docs/images/security-features/security-feature-securitytab-list-vulnerability.png
deleted file mode 100644
index 017c08fa4f..0000000000
Binary files a/docs/images/security-features/security-feature-securitytab-list-vulnerability.png and /dev/null differ
diff --git a/docs/images/security-features/security-feature-securitytab-security-scan.png b/docs/images/security-features/security-feature-securitytab-security-scan.png
deleted file mode 100644
index 93174a0307..0000000000
Binary files a/docs/images/security-features/security-feature-securitytab-security-scan.png and /dev/null differ
diff --git a/docs/images/use-cases/connect-django-with-mysql-database/use-case-django-ingress-template.jpg b/docs/images/use-cases/connect-django-with-mysql-database/use-case-django-ingress-template.jpg
deleted file mode 100644
index 2aff8733c6..0000000000
Binary files a/docs/images/use-cases/connect-django-with-mysql-database/use-case-django-ingress-template.jpg and /dev/null differ
diff --git a/docs/images/use-cases/connect-django-with-mysql-database/use-case-django-view-edemo-data.jpg b/docs/images/use-cases/connect-django-with-mysql-database/use-case-django-view-edemo-data.jpg
deleted file mode 100644
index 40ab55940c..0000000000
Binary files a/docs/images/use-cases/connect-django-with-mysql-database/use-case-django-view-edemo-data.jpg and /dev/null differ
diff --git a/docs/images/use-cases/connect-expressjs-with-mongodb-database/use-case-expressjs-ingress-template.jpg b/docs/images/use-cases/connect-expressjs-with-mongodb-database/use-case-expressjs-ingress-template.jpg
deleted file mode 100644
index b85b9f777b..0000000000
Binary files a/docs/images/use-cases/connect-expressjs-with-mongodb-database/use-case-expressjs-ingress-template.jpg and /dev/null differ
diff --git a/docs/images/use-cases/connect-expressjs-with-mongodb-database/use-case-expressjs-view-demo-data.jpg b/docs/images/use-cases/connect-expressjs-with-mongodb-database/use-case-expressjs-view-demo-data.jpg
deleted file mode 100644
index ab18a08ed9..0000000000
Binary files a/docs/images/use-cases/connect-expressjs-with-mongodb-database/use-case-expressjs-view-demo-data.jpg and /dev/null differ
diff --git a/docs/images/use-cases/connect-expressjs-with-mongodb-database/use-case-expressjs-view-student-data-with-id.jpg b/docs/images/use-cases/connect-expressjs-with-mongodb-database/use-case-expressjs-view-student-data-with-id.jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/images/use-cases/connect-expressjs-with-mongodb-database/use-case-expressjs-view-student-data-with-id.jpg and /dev/null differ
diff --git a/docs/images/use-cases/connect-springboot-with-mysql-database/use-cases-springboot-ingress-template.jpg b/docs/images/use-cases/connect-springboot-with-mysql-database/use-cases-springboot-ingress-template.jpg
deleted file mode 100644
index 12e1d44495..0000000000
Binary files a/docs/images/use-cases/connect-springboot-with-mysql-database/use-cases-springboot-ingress-template.jpg and /dev/null differ
diff --git a/docs/images/use-cases/connect-springboot-with-mysql-database/use-cases-springboot-view-student-data-with-id.jpg b/docs/images/use-cases/connect-springboot-with-mysql-database/use-cases-springboot-view-student-data-with-id.jpg
deleted file mode 100644
index c2d9c5f3b3..0000000000
Binary files a/docs/images/use-cases/connect-springboot-with-mysql-database/use-cases-springboot-view-student-data-with-id.jpg and /dev/null differ
diff --git a/docs/images/use-cases/connect-springboot-with-mysql-database/use-cases-springboot-view-student-data.jpg b/docs/images/use-cases/connect-springboot-with-mysql-database/use-cases-springboot-view-student-data.jpg
deleted file mode 100644
index c061312939..0000000000
Binary files a/docs/images/use-cases/connect-springboot-with-mysql-database/use-cases-springboot-view-student-data.jpg and /dev/null differ
diff --git a/docs/images/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job/use-case-chart-store.jpg b/docs/images/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job/use-case-chart-store.jpg
deleted file mode 100644
index b5915b1413..0000000000
Binary files a/docs/images/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job/use-case-chart-store.jpg and /dev/null differ
diff --git a/docs/images/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job/use-case-deploy-chart.jpg b/docs/images/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job/use-case-deploy-chart.jpg
deleted file mode 100644
index 3762b296d0..0000000000
Binary files a/docs/images/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job/use-case-deploy-chart.jpg and /dev/null differ
diff --git a/docs/images/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job/use-case-devtron-genric-configuration b/docs/images/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job/use-case-devtron-genric-configuration
deleted file mode 100644
index 06d29473fb..0000000000
Binary files a/docs/images/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job/use-case-devtron-genric-configuration and /dev/null differ
diff --git a/docs/reference/README.md b/docs/reference/README.md
old mode 100644
new mode 100755
index 0b90557f91..6759fe76b8
--- a/docs/reference/README.md
+++ b/docs/reference/README.md
@@ -1,16 +1,20 @@
+---
+hide_table_of_contents: true
+---
+
# Additional Installation Resources
Every environment is different, and you may want to tune, extend, or troubleshoot your installation.
This section brings together all the extra resources you might need beyond the basic install:
-* [Production Infra Recommendations](../setup/install/prod-infra.md) - Plan a stable, scalable Devtron setup in production.
-* [Advanced Configurations](../setup/configurations/configurations-overview.md) - Learn how to adjust Devtron’s install and runtime behavior.
- * [Installation Configurations](../setup/install/installation-configuration.md) - Fine-tune installation values for blob storage, node selectors and tolerations, StorageClass, etc.
- * [Override Configurations](../setup/install/override-default-devtron-installation-configs.md) - Customize default settings.
- * [Ingress Setup](../setup/install/ingress-setup.md) - Configure ingress for external access.
-* [Install Devtron on Air-gapped Environment](../setup/install/install-devtron-in-airgapped-environment.md) - Steps to install Devtron in restricted/offline environments.
-* [Devtron Kubernetes Desktop Client](../setup/install/install-devtron-Kubernetes-client.md) - Try Devtron locally without touching your cluster.
-* [Installation Walkthrough on EKS, AKS, GKE](../setup/install/demo-tutorials.md) - Hands-on installation demos on EKS, AKS, and GKE.
-* [Backup for Disaster Recovery](../setup/install/devtron-backup.md) - Protect your data and recover quickly.
-* [FAQs](../setup/install/faq-on-installation.md) - Answers to common installation questions.
+* **[Production Infra Recommendations](../setup/install/prod-infra.md)** - Plan a stable, scalable Devtron setup in production.
+* **[Advanced Configurations](../setup/configurations/configurations-overview.md)** - Learn how to adjust Devtron’s install and runtime behavior.
+ * **[Installation Configurations](../setup/install/installation-configuration.md)** - Fine-tune installation values for blob storage, node selectors and tolerations, StorageClass, etc.
+ * **[Override Configurations](../setup/install/override-default-devtron-installation-configs.md)** - Customize default settings.
+ * **[Ingress Setup](../setup/install/ingress-setup.md)** - Configure ingress for external access.
+* **[Install Devtron on Air-gapped Environment](../setup/install/install-devtron-in-airgapped-environment.md)** - Steps to install Devtron in restricted/offline environments.
+* **[Devtron Kubernetes Desktop Client](../setup/install/install-devtron-Kubernetes-client.md)** - Try Devtron locally without touching your cluster.
+* **[Installation Walkthrough on EKS, AKS, GKE](../setup/install/demo-tutorials.md)** - Hands-on installation demos on EKS, AKS, and GKE.
+* **[Backup for Disaster Recovery](../setup/install/devtron-backup.md)** - Protect your data and recover quickly.
+* **[FAQs](../setup/install/faq-on-installation.md)** - Answers to common installation questions.
\ No newline at end of file
diff --git a/docs/reference/glossary.md b/docs/reference/glossary.md
old mode 100644
new mode 100755
index fff9b42799..c2e68f33c0
--- a/docs/reference/glossary.md
+++ b/docs/reference/glossary.md
@@ -4,17 +4,17 @@
An immutable blob of data generated as an output after the execution of a job, build, or deployment process, e.g., container image, helm chart. In Devtron, you can view the artifacts in the `Build History` and `Deployment History` of your application. Whereas, job artifacts are visible in the `Run history` of your job.
-* Once a build is complete, you can view the build artifacts by going to Applications (choose your app) → Build History (tab) → (choose a pipeline and date of triggering the build) → Artifacts (tab).
+* Once a build is complete, you can view the build artifacts by going to Application Management → Applications (choose your app) → Build History (tab) → (choose a pipeline and date of triggering the build) → Artifacts (tab).
-* Once a deployment is complete, you can view the deployment artifacts by going to Applications (choose your app) → Deployment History (tab) → (choose an environment and date of deployment) → Artifacts (tab).
+* Once a deployment is complete, you can view the deployment artifacts by going to Application Management → Applications (choose your app) → Deployment History (tab) → (choose an environment and date of deployment) → Artifacts (tab).
-* Once a job is complete, you can view the job artifacts by going to Jobs → Run history (tab) → (choose a pipeline and date of triggering the build) → Artifacts (tab).
+* Once a job is complete, you can view the job artifacts by going to Automation & Enablement → Jobs → Run history (tab) → (choose a pipeline and date of triggering the build) → Artifacts (tab).
### ArgoCD Apps
ArgoCD Apps are the micro-services deployed using a [GitOps](#gitops) deployment tool named [Argo CD](https://argo-cd.readthedocs.io/en/stable/).
-If ArgoCD applications are present in your cluster, they will appear in the [ArgoCD Apps listing](../user-guide/applications.md#enabling-argocd-app-listing).
+If ArgoCD applications are present in your cluster, they will appear in the [ArgoCD Apps listing](../user-guide/infra-management/other-applications.md#enabling-argocd-app-listing).
### Deployment Template
@@ -30,11 +30,11 @@ For building a docker image we require a [Dockerfile](#dockerfile) and a build c
To build files from the root, use (.) as the build context. Or to refer a subdirectory, enter the path in the format `/myfolder` or `/myfolder/mysubfolder`. If the path is not set, the default path will be the root directory of selected git repository.
-Go to Applications (choose your app) → App Configuration (tab) → Build Configuration → (choose 'I have a Dockerfile') → Set Build Context.
+Go to Application Management → Applications (choose your app) → App Configuration (tab) → Build Configuration → (choose 'I have a Dockerfile') → Set Build Context.
### Build Pipeline
-A series of automated steps that transform source code into a deployable container image. In Devtron, you can create a build pipeline by going to Applications (choose your app) → App Configuration (tab) → Workflow Editor → New Workflow. [Read More...](../user-guide/creating-application/workflow/ci-pipeline.md)
+A series of automated steps that transform source code into a deployable container image. In Devtron, you can create a build pipeline by going to Application Management → Applications (choose your app) → App Configuration (tab) → Workflow Editor → New Workflow. [Read More...](../user-guide/creating-application/workflow/ci-pipeline.md)
### Chart Store
@@ -64,7 +64,7 @@ An OCI-compliant registry can also store artifacts (such as helm charts). Here,
### Cordoning
-Temporarily marking a node as unschedulable, preventing new pods from being assigned to it. In Devtron, you can cordon a node by going to Resource Browser → (choose a cluster) → Nodes → (click on a node) → Cordon (available in blue). [Read More...](../user-guide/resource-browser/nodes.md#cordon-a-node)
+Temporarily marking a node as unschedulable, preventing new pods from being assigned to it. In Devtron, you can cordon a node by going to Infrastructure Management → Resource Browser → (choose a cluster) → Nodes → (click on a node) → Cordon (available in blue). [Read More...](../user-guide/resource-browser/nodes.md#cordon-a-node)
### CRD
@@ -72,7 +72,7 @@ A Custom Resource Definition (CRD) allows you to add custom resource types to Ku
### CronJob
-CronJob is used to create Jobs on a repeating schedule. It is commonly used for running periodic tasks with no manual intervention. In Devtron, you can view a list of cronjobs by going to Resource Browser → (choose a cluster) → Workloads → CronJob. [Read More...](../user-guide/creating-application/base-config/deployment-template/job-and-cronjob.md#id-2.-cronjob)
+CronJob is used to create Jobs on a repeating schedule. It is commonly used for running periodic tasks with no manual intervention. In Devtron, you can view a list of cronjobs by going to Infrastructure Management → Resource Browser → (choose a cluster) → Workloads → CronJob. [Read More...](../user-guide/creating-application/base-config/deployment-template-types/job-and-cronjob.md#2-cronjob)
### Deployment Charts
@@ -82,29 +82,29 @@ Devtron offers a variety of ready-made Helm charts for common tasks and function
A Kubernetes object that ensures a specific pod runs on all or certain nodes within a cluster, often used for tasks such as logging or monitoring.
-In Devtron, you can view a list of DaemonSets by going to Resource Browser → (choose a cluster) → Workloads → DaemonSet.
+In Devtron, you can view a list of DaemonSets by going to Infrastructure Management → Resource Browser → (choose a cluster) → Workloads → DaemonSet.
### Deployment Strategy
A defined approach for deploying updates or changes to applications. Devtron supports rolling updates, blue-green deployments, canary releases, and recreate strategy.
-In Devtron, you can choose a deployment strategy by going to Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit deployment pipeline) → Deployment Strategy. [Read More...](../user-guide/creating-application/workflow/cd-pipeline.md#deployment-strategies)
+In Devtron, you can choose a deployment strategy by going to Application Management → Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit deployment pipeline) → Deployment Strategy. [Read More...](../user-guide/creating-application/workflow/cd-pipeline.md#deployment-strategies)
### Devtron Apps
-Devtron Apps are the micro-services deployed using Kubernetes-native CI/CD with Devtron. To create one, go to Applications → Create (button) → Custom App.
+Devtron Apps are the micro-services deployed using Kubernetes-native CI/CD with Devtron. To create one, go to Application Management → Applications → Create (button) → Custom App.
### Dockerfile
A script that defines how to build a Docker [container image](#image). It includes instructions to assemble the image's base, dependencies, and application code. It's recommended that you include a Dockerfile with your source code.
-However, in case you don't have a Dockerfile, Devtron helps you create one. Go to Applications (choose your app) → App Configuration (tab) → Build Configuration. [Read More...](../user-guide/creating-application/docker-build-configuration.md#build-docker-image-by-creating-dockerfile)
+However, in case you don't have a Dockerfile, Devtron helps you create one. Go to Application Management → Applications (choose your app) → App Configuration (tab) → Build Configuration. [Read More...](../user-guide/creating-application/docker-build-configuration.md#build-docker-image-by-creating-dockerfile)
### Draining
Evacuating pods from a node before cordoning it, ensuring that running pods are gracefully rescheduled on other nodes.
-In Devtron, you can drain a node by going to Resource Browser → (choose a cluster) → Nodes → (click on a node) → Drain (available in blue). [Read More...](../user-guide/resource-browser/nodes.md#drain-a-node)
+In Devtron, you can drain a node by going to Infrastructure Management → Resource Browser → (choose a cluster) → Nodes → (click on a node) → Drain (available in blue). [Read More...](../user-guide/resource-browser/nodes.md#drain-a-node)
### Endpoints
@@ -124,13 +124,13 @@ Similarly, the CPU and memory resources can be different for each environment. T
### External Links
-You can add external links related to the application. For e.g., you can add Prometheus, Grafana, and many more to your application by going to Global Configurations → External Links. [Read More...](../user-guide/global-configurations/external-links.md)
+You can add external links related to the application. For e.g., you can add Prometheus, Grafana, and many more to your application by going to Application Management → Configurations → External Links. [Read More...](../user-guide/global-configurations/external-links.md)
### FluxCD Apps
FluxCD Apps are the micro-services deployed using a [GitOps](#gitops) deployment tool named [Flux CD](https://fluxcd.io/).
-If FluxCD applications are present in your cluster, they will appear in the [FluxCD Apps listing](../user-guide/applications.md#view-external-fluxcd-app-listing).
+If FluxCD applications are present in your cluster, they will appear in the [FluxCD Apps listing](../user-guide/infra-management/other-applications.md#view-external-fluxcd-app-listing).
### GitOps
@@ -138,7 +138,7 @@ A methodology for managing and automating Kubernetes deployments using Git repos
### Helm Apps
-Apps deployed using Helm Chart from the `Chart Store` section of Devtron. In Devtron, you can view such apps under a tab named `Helm Apps` in the Applications section. To create one, go to Applications → Create (button) → From Chart store.
+Apps deployed using Helm Chart from the `Chart Store` section of Devtron. In Devtron, you can view such apps under a tab named `Helm Apps` in the Applications section. To create one, go to Application Management → Applications → Create (button) → From Chart store.
### Helm Charts/Packages
@@ -180,19 +180,19 @@ In Devtron, you can view the manifest of K8s resources under `App Details` and a
### Material
-In Git Repo, the source code of your application in a given commit is referred as material. The option to choose a Git material will be available in the CI stage under the `Build & Deploy` tab of your application. [Read More...](../user-guide/jobs/triggering-job.md#triggering-job-pipeline)
+In Git Repo, the source code of your application in a given commit is referred as material. The option to choose a Git material will be available in the CI stage under the `Build & Deploy` tab of your application. [Read More...](../user-guide/jobs/triggering-job.md)
### Namespace
A namespace is a way to organize and isolate resources within a Kubernetes cluster. It provides a logical separation between different applications or environments within a cluster.
-In Devtron, you can view a list of namespaces by going to Resource Browser → (choose a cluster) → Namespaces.
+In Devtron, you can view a list of namespaces by going to Infrastructure Management → Resource Browser → (choose a cluster) → Namespaces.
### Node Taint
A setting applied to a node that influences the scheduling of pods. Taints can restrict which pods are allowed to run on the node.
-In Devtron, you can edit the taints of a node by going to Resource Browser → (choose a cluster) → Nodes → (click on a node) → Edit taints (available in blue). [Read More...](../user-guide/resource-browser/nodes.md#taint-a-node)
+In Devtron, you can edit the taints of a node by going to Infrastructure Management → Resource Browser → (choose a cluster) → Nodes → (click on a node) → Edit taints (available in blue). [Read More...](../user-guide/resource-browser/nodes.md#taint-a-node)
### NodePort
@@ -202,7 +202,7 @@ A Kubernetes service type that exposes a port on each node in the cluster, makin
The physical or virtual machines that make up a Kubernetes cluster, where containers are scheduled to run.
-In Devtron, you can view nodes by going to Resource Browser → (choose a cluster) → Nodes. [Read More...](../user-guide/resource-browser/nodes.md)
+In Devtron, you can view nodes by going to Infrastructure Management → Resource Browser → (choose a cluster) → Nodes. [Read More...](../user-guide/resource-browser/nodes.md)
### Objects
@@ -214,43 +214,43 @@ Devtron's [Resource Browser](../user-guide/resource-browser/README.md) helps you
The smallest deployable unit in Kubernetes, consisting of one or more containers that share storage and network resources within the same context.
-In Devtron, you can view a list of Pods by going to Resource Browser → (choose a cluster) → Workloads → Pod. In Devtron, you can create a pod by going to Resource Browser → Create Resource (button).
+In Devtron, you can view a list of Pods by going to Infrastructure Management → Resource Browser → (choose a cluster) → Workloads → Pod. In Devtron, you can create a pod by going to Resource Browser → Create Resource (button).
### Pre-build
Actions or processes performed before the actual image-building process in a containerized application's deployment pipeline, e.g., Jira Issue Validator.
-In Devtron, you can configure pre-build actions by going to Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit build pipeline) → Pre-build stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/pre-post-tasks.md#creating-prepost-tasks)
+In Devtron, you can configure pre-build actions by going to Application Management → Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit build pipeline) → Pre-build stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/pre-post-tasks.md#creating-prepost-tasks)
### Post-build
Actions or processes performed after the [image](#image) building process in a containerized application's deployment pipeline, e.g., email notification about build status.
-In Devtron, you can configure post-build actions by going to Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit build pipeline) → Post-build stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/pre-post-tasks.md#creating-prepost-tasks)
+In Devtron, you can configure post-build actions by going to Application Management → Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit build pipeline) → Post-build stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/pre-post-tasks.md#creating-prepost-tasks)
### Pre-deployment
Steps, scripts, or configurations executed before deploying a new version of an application to a Kubernetes cluster.
-In Devtron, you can configure pre-deployment actions by going to Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit deployment pipeline) → Pre-deployment stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/cd-pipeline.md#pre-deployment-stage)
+In Devtron, you can configure pre-deployment actions by going to Application Management → Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit deployment pipeline) → Pre-deployment stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/cd-pipeline.md#pre-deployment-stage)
### Post-deployment
Actions, checks, or processes carried out after a new version of an application is successfully deployed to a Kubernetes cluster, e.g., Jira Issue Updater.
-In Devtron, you can configure post-deployment actions by going to Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit deployment pipeline) → Post-deployment stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/cd-pipeline.md#post-deployment-stage)
+In Devtron, you can configure post-deployment actions by going to Application Management → Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit deployment pipeline) → Post-deployment stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/cd-pipeline.md#post-deployment-stage)
### ReplicaSet
A Kubernetes object responsible for maintaining a specified number of replica pods, ensuring high availability and desired scaling.
-In Devtron, you can view the deployed ReplicaSet by going to Applications (choose your app) → App Details (tab) → K8s Resources (under Application Metrics section).
+In Devtron, you can view the deployed ReplicaSet by going to Application Management → Applications (choose your app) → App Details (tab) → K8s Resources (under Application Metrics section).
### Repo
Abbreviation for "repository". It could either signify a Git repo, container repo, or helm repo.
-**Git repo** - A version control system (like Git) that stores and manages source code and other project assets. Once you create a git repo, you can add it in Applications (choose your app) → App Configuration (tab) → Git Repository → Add Git Repository.
+**Git repo** - A version control system (like Git) that stores and manages source code and other project assets. Once you create a git repo, you can add it in Application Management → Applications (choose your app) → App Configuration (tab) → Git Repository → Add Git Repository.
**Container repo** - A collection of [container images](#image), e.g., Docker repository.
@@ -264,7 +264,7 @@ The process where you allocate resources (e.g., `memory`) to different environme
The process of reverting a deployment to a previously known working version in case of errors or issues with the current version.
-In Devtron, you can rollback a deployment by going to Applications (choose your app) → Build & Deploy (tab) → (click the rollback icon in the deployment pipeline). [Read More...](../user-guide/deploying-application/rollback-deployment.md)
+In Devtron, you can rollback a deployment by going to Application Management → Applications (choose your app) → Build & Deploy (tab) → (click the rollback icon in the deployment pipeline). [Read More...](../user-guide/deploying-application/rollback-deployment.md)
### Secrets
@@ -274,7 +274,7 @@ In Devtron, you get the option to add secrets in the `App Configuration` tab of
### Security Context
-A Kubernetes resource configuration that defines security settings and permissions for pods and containers. A security context defines privilege and access control settings for a pod or container. [Read More...](../user-guide/creating-application/base-config/deployment-template/deployment.md#security-context)
+A Kubernetes resource configuration that defines security settings and permissions for pods and containers. A security context defines privilege and access control settings for a pod or container. [Read More...](../user-guide/creating-application/base-config/deployment-template-types/deployment.md#security-context)
### Service
@@ -284,14 +284,10 @@ When the network addresses of pods changes frequently, it becomes difficult to c
A Kubernetes object designed for managing stateful applications, maintaining stable network identities and storage across pod rescheduling.
-In Devtron, view the list of StatefulSets by going to Resource Browser → (choose a cluster) → Workloads → StatefulSet. [Read More...](../user-guide/creating-application/base-config/deployment-template/statefulset.md)
+In Devtron, view the list of StatefulSets by going to Infrastructure Management → Resource Browser → (choose a cluster) → Workloads → StatefulSet. [Read More...](../user-guide/creating-application/base-config/deployment-template-types/statefulset.md)
### Target Platform
The operating system and architecture for which the [container image](#image) will be built, e.g., ubuntu/arm64, linux/amd64. The image will only be compatible to run only on the target platform chosen in the build configuration.
-In Devtron, you can choose the target platform by going to Applications (choose your app) → App Configuration (tab) → Build Configuration → (create build pipeline) → (click `Allow Override` button) → Target platform for the build (section). [Read More...](../user-guide/creating-application/docker-build-configuration.md)
-
-
-
-
+In Devtron, you can choose the target platform by going to Application Management → Applications (choose your app) → App Configuration (tab) → Build Configuration → (create build pipeline) → (click `Allow Override` button) → Target platform for the build (section). [Read More...](../user-guide/creating-application/docker-build-configuration.md)
\ No newline at end of file
diff --git a/docs/reference/graviton.md b/docs/reference/graviton.md
old mode 100644
new mode 100755
index 312cb74197..674c560968
--- a/docs/reference/graviton.md
+++ b/docs/reference/graviton.md
@@ -18,14 +18,18 @@ The utilization of Graviton machines for building Graviton architecture has led
**AMD Build**
+
Figure 1: Amd Build
-
+
+
-
+
+
Figure 4: Resource Utilization on ARM
@@ -47,10 +51,12 @@ We have attached some snapshots of the resource utilization for the critical mic
**AMD-Based**
+
#### 2. argocd-server
@@ -58,31 +64,33 @@ We have attached some snapshots of the resource utilization for the critical mic
**AMD-Based**
+
\ No newline at end of file
diff --git a/docs/reference/resources.md b/docs/reference/resources.md
new file mode 100755
index 0000000000..f26ede220b
--- /dev/null
+++ b/docs/reference/resources.md
@@ -0,0 +1,24 @@
+---
+hide_table_of_contents: true
+---
+
+# Resources
+
+This section groups reference material, troubleshooting notes, upgrade/install resources, integrations and plugins, use-cases and other supporting docs.
+
+## Quick links
+
+* **[Glossary](./glossary)** - Definitions for Devtron terminology and common concepts used across the docs.
+* **[Tron CLI](../cli/README.md)** - Automate Devtron application and configuration tasks using the CLI.
+* **[Troubleshooting Guide](../FAQs/devtron-troubleshoot)** - Common issues and troubleshooting steps.
+* **[Upgrade Devtron](../setup/upgrade)** - Guides for upgrading Devtron releases and the UI. Also includes version-specific notes.
+* **[Additional installation resources](README.md)** - Extra installation references and environment notes.
+* **[Integrations](../user-guide/integrations)** - How to integrate Devtron with CI/CD, Grafana, notifications and vulnerability scanners. Examples: Grafana, ArgoCD, Notifications, Vulnerability scanning (Trivy/Clair).
+* **[Pipeline plugins](../user-guide/plugins/plugin-list)** - Plugin reference and how to build/use plugins in CI/CD pipelines. Examples: Jenkins, GitHub PR updater, Semgrep, container-image-exporter, etc.
+* **[Using Devtron Intelligence](../user-guide/devtron-intelligence.md)** - Docs and notes about installing Devtron Intelligence and how to use it for debugging.
+* **[Enable GitOps Deployments with FluxCD](../user-guide/creating-application/fluxcd.md)** - Guides and examples for FluxCD-based GitOps usage.
+* **[Use cases](../user-guide/use-cases)** - Practical examples for common application patterns.
+* **[Telemetry](../user-guide/telemetry)** - How telemetry works and what data Devtron collects.
+* **[Graviton](./graviton)** - Information on the Graviton reference (architecture / compatibility).
+* **[Release Notes](https://github.com/devtron-labs/devtron/releases)** - Official release notes and changelog (external).
+* **[Uninstall Devtron](../setup/install/uninstall-devtron)** - Steps to remove Devtron from a cluster.
\ No newline at end of file
diff --git a/docs/setup/configurations/configurations-overview.md b/docs/setup/configurations/configurations-overview.md
old mode 100644
new mode 100755
index c33397ca66..2f700e099e
--- a/docs/setup/configurations/configurations-overview.md
+++ b/docs/setup/configurations/configurations-overview.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Advanced Configurations
You can configure Devtron by using configuration files. Configuration files are YAML files which are user-friendly.
@@ -9,4 +13,4 @@ There are two ways you can perform configurations while setting up Devtron dashb
* [Override Configurations](../install/override-default-devtron-installation-configs.md)
-You can also setup `ingress` while setting up Devtron dashboard. Refer [here](../install/ingress-setup.md) for ingress setup.
+You can also setup `ingress` while setting up Devtron dashboard. Refer [here](../install/ingress-setup.md) for ingress setup.
\ No newline at end of file
diff --git a/docs/setup/detailed-installation-instructions.md b/docs/setup/detailed-installation-instructions.md
deleted file mode 100644
index 07ba7aa5a5..0000000000
--- a/docs/setup/detailed-installation-instructions.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# Detailed Installation instructions
-
diff --git a/docs/setup/getting-started/README.md b/docs/setup/getting-started/README.md
deleted file mode 100644
index a5e8c6a16f..0000000000
--- a/docs/setup/getting-started/README.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# Start Using devtron
-
diff --git a/docs/setup/getting-started/deploying-sample-springboot-app.md b/docs/setup/getting-started/deploying-sample-springboot-app.md
deleted file mode 100644
index 7ffd688361..0000000000
--- a/docs/setup/getting-started/deploying-sample-springboot-app.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# Deploying sample springboot app
-
diff --git a/docs/setup/getting-started/getting-started.md b/docs/setup/getting-started/getting-started.md
deleted file mode 100644
index e29aac7355..0000000000
--- a/docs/setup/getting-started/getting-started.md
+++ /dev/null
@@ -1,58 +0,0 @@
-# Getting Started
-
-### Introduction
-
-Devtron is installed over a Kubernetes cluster. Once you create a Kubernetes cluster, Devtron can be installed standalone or along with integrations. This section includes information about the minimum requirements you need to install and use Devtron.
-
-***
-
-### Create a Kubernetes Cluster
-
-{% hint style="info" %}
-**Setting up a production-grade infrastructure?**
-
-Refer [Devtron's Production Infra Recommendations](../install/prod-infra.md)
-{% endhint %}
-
-You can create any [Kubernetes cluster](https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/) (preferably K8s version 1.16 or higher) for installing Devtron.
-
-| Cloud Provider | Description |
-| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **AWS EKS** |
|
-
-***
-
-### Recommended Resources
-
-The minimum requirements for installing Devtron depends on the integrations you need.
-
-* For configuring small resources (to manage not more than 5 apps on Devtron):
-
- | Integration | CPU | Memory |
- | --------------------------------------------- | :-: | :----: |
- | **With CI/CD, GitOps** | 2 | 6 GB |
- | **Minimal (Only Dashboard, No Integrations)** | 1 | 1 GB |
-* For configuring medium/larger resources (to manage more than 5 apps on Devtron):
-
- | Integration | CPU | Memory |
- | --------------------------------------------- | :-: | :----: |
- | **With CI/CD, GitOps** | 6 | 13 GB |
- | **Minimal (Only Dashboard, No Integrations)** | 2 | 3 GB |
-
-> Refer to the [Override Configurations](../install/override-default-devtron-installation-configs.md) section for more information. If you have questions, let us know on our Discord channel. [](https://discord.gg/jsRG5qx2gp)
-
-{% hint style="warning" %}
-#### Note
-
-* Please make sure that the recommended resources are available on your Kubernetes cluster before you proceed with Devtron installation.
-* We do not recommend using burstable CPU VMs (T series in AWS, B series in Azure, or E2/N1 in GCP) for installing Devtron, as they may lead to inconsistent performance.
-{% endhint %}
-
-{% hint style="success" %}
-#### Next Step
-
-[Install Devtron on your Kubernetes Cluster](../install/)
-{% endhint %}
diff --git a/docs/setup/getting-started/global-configurations.md b/docs/setup/getting-started/global-configurations.md
deleted file mode 100644
index 733bef0b61..0000000000
--- a/docs/setup/getting-started/global-configurations.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# Global Configurations
-
diff --git a/docs/setup/getting-started/initial-setup.md b/docs/setup/getting-started/initial-setup.md
new file mode 100755
index 0000000000..b39fab5aa9
--- /dev/null
+++ b/docs/setup/getting-started/initial-setup.md
@@ -0,0 +1,54 @@
+# Initial Setup
+
+### Introduction
+
+Devtron is installed over a Kubernetes cluster. Once you create a Kubernetes cluster, Devtron can be installed standalone or along with integrations. This section includes information about the minimum requirements you need to install and use Devtron.
+
+---
+
+### Create a Kubernetes Cluster
+
+:::info
+**Setting up a production-grade infrastructure?**
+
+Refer [Devtron's Production Infra Recommendations](../install/prod-infra.md)
+:::
+
+You can create any [Kubernetes cluster](https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/) (preferably K8s version 1.16 or higher) for installing Devtron.
+
+| Cloud Provider | |
+| ---------------------------------- | -------------------------------------------------------- |
+| **AWS EKS** |
Create a cluster using [AWS EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html)
Note: [Refer our documentation](http://github.com/devtron-labs/devtron/blob/b33a37bb608d07966c8f8b89e4f59287db873c6c/docs/setup/install/install-devtron-on-aws-eks.md) for installing Devtron on AWS EKS Cluster
|
+| **Google Kubernetes Engine (GKE)** | Create a cluster using [GKE](https://cloud.google.com/kubernetes-engine/) |
+| **Azure Kubernetes Service (AKS)** | Create a cluster using [AKS](https://learn.microsoft.com/en-us/azure/aks/) |
+| **k3s - Lightweight Kubernetes** |
Create a cluster using [k3s - Lightweight Kubernetes](https://devtron.ai/blog/deploy-your-applications-over-k3s-lightweight-kubernetes-in-no-time/)
Note: [Refer our documentation](../install/devtron-oss.md) for installing Devtron on Minikube, Microk8s, K3s, or Kind
|
+
+---
+
+### Recommended Resources
+
+The minimum requirements for installing Devtron depends on the integrations you need.
+
+* For configuring small resources (to manage not more than 5 apps on Devtron):
+
+ | Integration | CPU | Memory |
+ | --------------------------------------------- | :-: | :----: |
+ | **With CI/CD, GitOps** | 2 | 6 GB |
+ | **Minimal (Only Dashboard, No Integrations)** | 1 | 1 GB |
+* For configuring medium/larger resources (to manage more than 5 apps on Devtron):
+
+ | Integration | CPU | Memory |
+ | --------------------------------------------- | :-: | :----: |
+ | **With CI/CD, GitOps** | 6 | 13 GB |
+ | **Minimal (Only Dashboard, No Integrations)** | 2 | 3 GB |
+
+> Refer to the [Override Configurations](../install/override-default-devtron-installation-configs.md) section for more information. If you have questions, let us know on our Discord channel. [](https://discord.gg/jsRG5qx2gp)
+
+:::warning Note
+* Please make sure that the recommended resources are available on your Kubernetes cluster before you proceed with Devtron installation.
+* We do not recommend using burstable CPU VMs (T series in AWS, B series in Azure, or E2/N1 in GCP) for installing Devtron, as they may lead to inconsistent performance.
+:::
+
+:::success Next Step
+[Install Devtron on your Kubernetes Cluster](../install/)
+:::
\ No newline at end of file
diff --git a/docs/setup/getting-started/installation-with-default-values.md b/docs/setup/getting-started/installation-with-default-values.md
deleted file mode 100644
index 995f288425..0000000000
--- a/docs/setup/getting-started/installation-with-default-values.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# Installation with default values
-
diff --git a/docs/setup/getting-started/other-quickstart-apps.md b/docs/setup/getting-started/other-quickstart-apps.md
deleted file mode 100644
index 165f269aac..0000000000
--- a/docs/setup/getting-started/other-quickstart-apps.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# Other quickstart apps
-
diff --git a/docs/setup/getting-started/why-devtron.md b/docs/setup/getting-started/why-devtron.md
old mode 100644
new mode 100755
index 417ec0a894..17d702d03a
--- a/docs/setup/getting-started/why-devtron.md
+++ b/docs/setup/getting-started/why-devtron.md
@@ -10,16 +10,10 @@ To improve the usage of Kubernetes, several tools are needed to be integrated. B
This is where **Devtron** comes into the picture!
-
+
The need to declaratively manage Kubernetes clusters and application delivery is what is driving **Devtron** on Kubernetes.
Devtron is an open-source modular product that provides a `seamless` and `implementation-agnostic uniform interface`, that can be integrated with both open-source and commercial tools across the entire application lifecycle.
-With Devtron, you can efficiently handle security, stability, cost, and more in a unified experience.
-
-
-
-
-
-
+With Devtron, you can efficiently handle security, stability, cost, and more in a unified experience.
\ No newline at end of file
diff --git a/docs/setup/install/Install-devtron-on-Minikube-Microk8s-K3s-Kind.md b/docs/setup/install/Install-devtron-on-Minikube-Microk8s-K3s-Kind.md
deleted file mode 100644
index 8f4171167f..0000000000
--- a/docs/setup/install/Install-devtron-on-Minikube-Microk8s-K3s-Kind.md
+++ /dev/null
@@ -1,284 +0,0 @@
-# Install Devtron on Minikube, Microk8s, K3s, Kind, Cloud VMs
-
-## Introduction
-
-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.
-
-{% hint style="success" %}
-
-Try Devtron Freemium to access all the enterprise features for free and forever, limited to adding one additional cluster. [Install Devtron Freemium](https://license.devtron.ai/dashboard)
-
-{% endhint %}
-
----
-
-## Tutorial
-
-{% embed url="https://www.youtube.com/watch?v=rKUymNJqcjA" caption="Installing Devtron on Minikube" %}
-
----
-
-## Add Helm Repo
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-```
-
----
-
-## Update Helm Repo
-
-```bash
-helm repo update devtron
-```
-
----
-
-## For Minikube, MicroK8s, Kind, K3s
-
-{% hint style="warning" %}
-
-### Prerequisites
-
-Ensure you meet [all the requirements](../getting-started/getting-started.md#prerequisites) for installing Devtron.
-
-{% endhint %}
-
-### Installation Commands
-
-{% tabs %}
-
-{% tab title="Without Integrations" %}
-
-**Minikube/MicroK8s/Kind Cluster**
-
-To install Devtron on **Minikube/MicroK8s/Kind** cluster, run the following command:
-
-```bash
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set components.devtron.service.type=NodePort
-```
-
-**K3s Cluster**
-
-To install Devtron on **K3s** cluster, run the following commands:
-
-```bash
-kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
-```
-
-```bash
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set components.devtron.service.type=NodePort
-```
-
-{% endtab %}
-
-{% tab title="With CI/CD" %}
-
-**Minikube/MicroK8s/Kind Cluster**
-
-To install Devtron on **Minikube/MicroK8s/Kind** cluster, run the following command:
-
-```bash
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set components.devtron.service.type=NodePort \
---set installer.modules={cicd}
-```
-
-**K3s Cluster**
-
-To install Devtron on **K3s** cluster, run the following commands:
-
-```bash
-kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
-```
-
-```bash
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set components.devtron.service.type=NodePort \
---set installer.modules={cicd}
-```
-
-{% endtab %}
-
-{% tab title="With CI/CD and GitOps (Argo CD)" %}
-
-**Minikube/MicroK8s/Kind Cluster**
-
-To install Devtron on **Minikube/MicroK8s/Kind** cluster, run the following command:
-
-```bash
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set components.devtron.service.type=NodePort \
---set installer.modules={cicd} \
---set argo-cd.enabled=true
-```
-
-**K3s Cluster**
-
-To install Devtron on **K3s** cluster, run the following commands:
-
-```bash
-kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
-```
-
-```bash
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set components.devtron.service.type=NodePort \
---set installer.modules={cicd} \
---set argo-cd.enabled=true
-```
-
-{% endtab %}
-
-{% endtabs %}
-
-### Access Devtron Dashboard
-
-{% tabs %}
-{% tab title="Minikube" %}
-
-To access the dashboard on **Minikube** cluster, run the following command:
-
-```bash
-minikube service devtron-service --namespace devtroncd
-```
-
-This will directly open the dashboard URL in your browser
-
-{% endtab %}
-{% tab title="MicroK8s/Kind/K3s Cluster" %}
-
-To access the dashboard on **MicroK8s/Kind/K3s** cluster, run the following command to port-forward the devtron service to port 8000:
-
-```bash
-kubectl -n devtroncd port-forward service/devtron-service 8000:80
-```
-
-After port-forwarding, you can access the dashboard at this URL: `http://127.0.0.1:8000`
-
-{% endtab %}
-{% endtabs %}
-
-### Get Admin Credentials
-
-When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use those credentials to log in as an administrator.
-
-**Username**: `admin`
-**Password**: Run the following command to get the admin password:
-
-```bash
-kubectl -n devtroncd get secret devtron-secret \
--o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
-```
-
-You can also install integrations from the [Devtron Stack Manager](../../user-guide/integrations/README.md).
-
-{% hint style="info" %}
-
-#### Next Recommended Action
-
-When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
-
-After the initial login, we recommend you set up any [Single Sign-On (SSO)](../../user-guide/global-configurations/sso-login.md) service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (e.g., GitHub) to log in to the Dashboard.
-
-{% endhint %}
-
----
-
-## For Cloud VM (AWS EC2, Azure VM, GCP VM)
-
-{% hint style="warning" %}
-
-### Prerequisites
-
-* Ensure you meet [all the requirements](../getting-started/getting-started.md#prerequisites) for installing Devtron.
-
-* It is recommended to use Cloud VM with 2vCPU+, 4GB+ free memory, 20GB+ storage, Compute Optimized VM type & Ubuntu Flavoured OS.
-
-{% endhint %}
-
-### Create MicroK8s Cluster
-
-```bash
-sudo snap install microk8s --classic
-sudo usermod -a -G microk8s $USER
-sudo chown -f -R $USER ~/.kube
-newgrp microk8s
-microk8s enable dns storage helm3
-echo "alias kubectl='microk8s kubectl '" >> .bashrc
-echo "alias helm='microk8s helm3 '" >> .bashrc
-source .bashrc
-```
-
-### Installation Commands
-
-{% tabs %}
-
-{% tab title="Without Integrations" %}
-
-```bash
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set components.devtron.service.type=NodePort
-```
-
-{% endtab %}
-
-{% tab title="With CI/CD" %}
-
-```bash
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set components.devtron.service.type=NodePort \
---set installer.modules={cicd}
-```
-
-{% endtab %}
-
-{% tab title="With CI/CD and GitOps (Argo CD)" %}
-
-```bash
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set components.devtron.service.type=NodePort \
---set installer.modules={cicd} \
---set argo-cd.enabled=true
-```
-
-{% endtab %}
-
-{% endtabs %}
-
-### Get devtron-service Port Number
-
-```bash
-kubectl get svc -n devtroncd devtron-service -o jsonpath='{.spec.ports[0].nodePort}'
-```
-
-Make sure that the port used by the devtron-service remain open in the VM's security group or network security group.
-
-You can also install integrations from the [Devtron Stack Manager](../../user-guide/integrations/README.md).
-
-{% hint style="info" %}
-
-#### Next Recommended Action
-
-When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
-
-After the initial login, we recommend you set up any [Single Sign-On (SSO)](../../user-guide/global-configurations/sso-login.md) service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (e.g., GitHub) to log in to the Dashboard.
-
-{% endhint %}
-
-{% hint style="info" %}
-
-If you have questions, please let us know on our Discord channel. [](https://discord.gg/jsRG5qx2gp)
-
-{% endhint %}
\ No newline at end of file
diff --git a/docs/setup/install/README.md b/docs/setup/install/README.md
old mode 100644
new mode 100755
index 9011830d32..c77628ad71
--- a/docs/setup/install/README.md
+++ b/docs/setup/install/README.md
@@ -2,48 +2,16 @@
## Introduction
-Devtron can be installed on any [Kubernetes cluster](../getting-started/getting-started.md#create-a-kubernetes-cluster) of your choice.
+Devtron can be installed on any [Kubernetes cluster](../getting-started/initial-setup.md#create-a-kubernetes-cluster) of your choice.
The following tiers are available in Devtron:
-
-
-
-
Tiers
-
Description
-
Installation Link
-
-
-
-
-
OSS
-
OSS edition, with optional CI/CD and GitOps modules
+| Tiers | Description | Installation Link |
+|------------|-----------------------------------------------------------------------------------------------|-------------------|
+| OSS | OSS edition, with optional CI/CD and GitOps modules | [**Install Devtron OSS**](../install/devtron-oss.md) |
+| Freemium | All enterprise features, limited to 1 cluster managed by Devtron | [**Install Devtron Freemium**](../install/devtron-freemium.md) |
+| Enterprise | Full access to enterprise features, with multi-cluster support and enterprise-scale solutions | [**Get Devtron Enterprise**](https://devtron.ai/contact-sales) |
+
## Additional Resources
@@ -68,7 +36,7 @@ See the full guide here: [Install Devtron in Air-gapped Environment](install-dev
Need help or demo?
-* [Discord community for support](https://discord.gg/jsRG5qx2gp)[](https://discord.gg/jsRG5qx2gp).
+* [Discord community for support](https://discord.gg/jsRG5qx2gp) [](https://discord.gg/jsRG5qx2gp)
* [Book time with our team](https://devtron.ai/demo)
diff --git a/docs/setup/install/demo-tutorials.md b/docs/setup/install/demo-tutorials.md
old mode 100644
new mode 100755
index 55b5ad1a66..33f1aa363e
--- a/docs/setup/install/demo-tutorials.md
+++ b/docs/setup/install/demo-tutorials.md
@@ -6,7 +6,7 @@ Here we have demonstrated the installation of Devtron on popular cloud providers
**Cloud Provider**: [Amazon Web Services (AWS)](https://aws.amazon.com/)
-{% embed url="https://www.youtube.com/watch?v=eY2vudE5jFM" caption="Installing Devtron on AWS" %}
+
---
@@ -14,7 +14,7 @@ Here we have demonstrated the installation of Devtron on popular cloud providers
**Cloud Provider**: [Microsoft Azure](https://azure.microsoft.com/)
-{% embed url="https://www.youtube.com/watch?v=8ZdhwJQ-IU4" caption="Installing Devtron on Azure" %}
+
---
@@ -22,16 +22,13 @@ Here we have demonstrated the installation of Devtron on popular cloud providers
**Cloud Provider**: [Google Cloud Platform (GCP)](https://console.cloud.google.com/)
-{% embed url="https://www.youtube.com/watch?v=7UN_Fbo3VMM" caption="Installing Devtron on Google Cloud" %}
+
---
-{% hint style="info" %}
-
-### Next Recommended Action
-
+:::info Next Recommended Action
When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
After the initial login, we recommend you set up any [Single Sign-On (SSO)](../../user-guide/global-configurations/sso-login.md) service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (e.g., GitHub) to log in to the Dashboard.
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/setup/install/devtron-backup.md b/docs/setup/install/devtron-backup.md
old mode 100644
new mode 100755
index a0b2dc31ae..0c0be1288b
--- a/docs/setup/install/devtron-backup.md
+++ b/docs/setup/install/devtron-backup.md
@@ -1,15 +1,16 @@
-## Devtron Backup
+# Backup for Disaster Recovery
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.
1. Go to the devtron chart store and search for `devtron-backups` chart.
+
Figure 1: Search Chart
2. Select the `devtron-backups` and click `Configure & Deploy`.
3. Now follow either of the options described below according to your Cloud provider.
-### AWS S3 Backup
+## AWS S3 Backup
To store Devtron backups on AWS S3, please follow these steps:
@@ -18,23 +19,26 @@ To store Devtron backups on AWS S3, please follow these steps:
3. Obtain the access key and secret access key for the created user.
4. Configure the `devtron-backups` chart for AWS S3 by selecting the appropriate options:
-
+
+
Figure 2: AWS Backup Configuration
5. Deploy the chart, and the Devtron backup will be automatically uploaded to the AWS S3 bucket at the scheduled intervals.
-### Azure Containers Backup
+## Azure Containers Backup
To store Devtron backups on Azure Containers, please follow these steps:
1. Create a storage account in Azure.
2. Within the storage account, create two containers for the Devtron backup.
-3. Navigate to Security + Networking > Access Key section in Azure and copy the Access Key:
+3. Navigate to Security + Networking → Access Key section in Azure and copy the Access Key:
-
+
+
Figure 3: Azure Storage Account Key
4. Configure the `devtron-backups` chart for Azure Containers by providing the Access Key:
-
+
+
Figure 4: Azure Backup Configuration
5. 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.
diff --git a/docs/setup/install/devtron-freemium.md b/docs/setup/install/devtron-freemium.md
old mode 100644
new mode 100755
index efdc85e85c..2ac3955e89
--- a/docs/setup/install/devtron-freemium.md
+++ b/docs/setup/install/devtron-freemium.md
@@ -11,14 +11,13 @@ With Devtron Freemium, you can access all the enterprise features limited to 1 c
* Security scans
* Policies related to approval, deployment, plugins, tags, infra...and many more.
-{% hint style="info" %}
-**Already using Devtron OSS?**
+:::info Already using Devtron OSS?
This guide is intended for fresh installation of **Devtron Freemium**.\
If you're currently using the [open-source (OSS) version of Devtron](../install/devtron-oss.md), we **do not recommend** upgrading your existing setup to Devtron Freemium.
Instead, we suggest you to perform a fresh installation of Devtron Freemium on a separate cluster (following the steps below) for the best experience.
-{% endhint %}
+:::
---
@@ -32,8 +31,11 @@ You can choose any of the two methods to sign up: [SSO](devtron-freemium.md#meth
1. Log in using **Google**, **GitHub**, or **Microsoft** SSO providers. Personal email accounts such as Gmail, Yahoo are not supported.
- 
+ 
+
Figure 1: Selecting SSO Provider
+
2. Once logged in, the **Devtron License Dashboard** will open.
+
3. Under **Tell Us About You**, fill the required basic details, and click **Next** to proceed to [Step 2: Install Devtron](devtron-freemium.md#step-2-install-devtron).
### Method 2: Sign up using Work Email
@@ -42,42 +44,73 @@ Use this method if your email is not associated with any of the SSO options prov
1. Select **Continue with Email** to log in.
- 
+ 
+
Figure 2: Selecting 'Continue with Email'
+
2. Enter your work email and select **Send Login Link**
- 
+ 
+
Figure 3: Entering Email
+
3. A login link will be sent to the email address provided by you. If you do not receive the link, you can resend it after 30 seconds.
**Note:** Your login link will be valid only for 10 minutes.
- 
+ 
+
Figure 4: Sending Login Link
-{% hint style="info" %}
+:::info
**Did Not Receive Email?**
* Check all sections of the mailbox, including the 'Spam' section.
* If the email is in the Spam section, mark it as 'Not Spam'.
-{% endhint %}
+:::
4. Open the email and click **Login to License Dashboard**.
- 
+ 
+
Figure 5: Email with Login Link
Once logged in, the **Devtron License Dashboard** will open.
5. Under **Tell Us About You**, fill the required basic details, and click **Next** to proceed to [Step 2: Install Devtron](devtron-freemium.md#step-2-install-devtron).
- 
+ 
+
Figure 6: Entering the Details
---
## Step 2: Install Devtron
-{% hint style="warning" %}
-### Note
+For convenience, Devtron Freemium offers you three installation options:
+
+* [**Option 1**: Install on own K8s Cluster](#option-1-install-on-own-k8s-cluster)
+* [**Option 2**: Install via AWS Marketplace](#option-2-install-via-aws-marketplace)
+* [**Option 3**: Devtron Cloud (SaaS)](#option-3-devtron-cloud-saas)
+
+The below table will help you identify the right option for you.
+
+
+| If you want to… | Install on Own K8s Cluster | Via AWS Marketplace | Devtron Cloud (SaaS) |
+| ----------------------------------------- | -------------------------- | --------------- | -------------------- |
+| Get started in minutes with zero setup | ❌ | ❌ | ✅ |
+| Use Devtron long term | ✅ | ✅ | ❌ |
+| Evaluate Devtron quickly | ❌ | ❌ | ✅ |
+| Run Devtron inside your own cloud account | ✅ | ✅ | ❌ |
+| Use Devtron for production workloads | ✅ | ✅ | ❌ |
+| Pay nothing for Devtron | ✅ | ✅ | ❌ (30-day trial) |
+
+### Option 1: Install on own K8s Cluster
+
+Choose this option if you want Devtron installed in your Kubernetes cluster.
+
+
+
Figure 7: Choosing 'Install on own K8s Cluster'
+
+:::warning Note
We recommend installing Devtron on a separate Kubernetes cluster, since the cluster may run critical system services. Therefore, it should be kept separate from application workloads. Also ensure your `kubeconfig` is properly configured.
See [Additional Installation Resources](../../reference/README.md) for production infra recommendations, air-gapped installs, blob storage, config overrides, StorageClass, Database, Ingress setup, backups, and more.
-{% endhint %}
+:::
The installation commands are directly available on the [Devtron License Dashboard](https://license.devtron.ai/dashboard) for supported K8s distributions.
@@ -89,7 +122,7 @@ The installation commands are directly available on the [Devtron License Dashboa
Once Devtron is installed and you have the dashboard URL, click **Next** to proceed to [Step 3: Get License Key](devtron-freemium.md#step-3-get-license-key)
-{% hint style="info" %}
+:::info
**Using MicroK8s/Kind/K3s/Cloud VMs? Want to Access Dashboard via NodePort? Or Locally from Remote VM?**
* **Access via NodePort**:
@@ -100,7 +133,7 @@ To obtain the Dashboard URL on MicroK8s/Kind/K3s/Cloud VMs using NodePort, run t
kubectl get svc -n devtroncd devtron-service -o jsonpath='{.spec.ports[0].nodePort}'
```
-**Dashboard URL**: `http://:/dashboard`
+**Dashboard URL**: `http://:/dashboard`
---
@@ -114,8 +147,48 @@ kubectl config use-context # Set the correct context.
kubectl -n devtroncd port-forward service/devtron-service 8000:80
```
-**Dashboard URL**: `http://127.0.0.1:8000`
-{% endhint %}
+**Dashboard URL**: `http://127.0.0.1:8000`
+
+:::
+
+### Option 2: Install via AWS Marketplace
+
+Choose this option if you want a Devtron instance inside your AWS account with minimal setup effort. It will launch a preconfigured Devtron instance from AWS Marketplace.
+
+
+
Figure 8: Choosing 'Install via AWS Marketplace'
+
+
+
+:::caution
+Since the instance runs inside your AWS account and infrastructure, you might incur infra costs.
+:::
+
+### Option 3: Devtron Cloud (SaaS)
+
+Choose this option if you want to try Devtron without setting up any Kubernetes cluster. You will directly get the credentials to log in to Devtron. This is a 30-day trial meant for fair usage and not production workloads.
+
+
+
Figure 9: Choosing 'Devtron Cloud (SaaS)'
+
+* Click **Launch Devtron**.
+
+ Devtron will provision the SaaS instance within a couple of minutes. The Dashboard URL and credentials will be shown on screen.
+
+ 
+
Figure 10: Enter Installation Fingerprint
+
+* Click **Go to Devtron Dashboard** to open the Devtron login page.
+
+ The username will be `admin`. Enter the password shown to you in the above step.
+
+:::caution
+Instance will automatically hibernate after 72 hours of inactivity.
+:::
+
+:::tip
+Step 3 (given below) will not be applicable for **Devtron Cloud (SaaS)** as you already get the license key and credentials here.
+:::
---
@@ -123,7 +196,8 @@ kubectl -n devtroncd port-forward service/devtron-service 8000:80
You will now need to enter your Devtron **Installation Fingerprint** to generate a license key.
-
+
+
Figure 11: Enter Installation Fingerprint
### Get Devtron installation's fingerprint
@@ -131,45 +205,53 @@ To get the **Installation Fingerprint**, follow the below steps:
1. Visit the Dashboard URL obtained in Step 2.
- 
+ 
+
Figure 12: License Activation Screen
2. You will see an installation fingerprint that uniquely identifies your installation. Copy the fingerprint.
- 
+ 
+
Figure 13: Copying Installation Fingerprint
+
3. Go back to the **License Dashboard** and paste the fingerprint you copied earlier and click **Get License Key**.
- 
+ 
+
Figure 14: Pasting Installation Fingerprint
+
4. Your license will be generated. Copy the license key.
- 
+ 
+
Figure 15: Copying Generated License Key
-{% hint style="warning" %}
+:::warning
**Note**
The license key you generate will be valid only for your Devtron Freemium installation.
* Only one Devtron Freemium cluster per organization.
* The license key is uniquely mapped to your installation fingerprint.
-{% endhint %}
+:::
-{% hint style="danger" %}
+:::danger
**Warning**
The license is bound to your Kubernetes cluster and cannot be transferred to another cluster. In case the cluster is deleted, you cannot claim freemium license on a new cluster. In that case, contact [support@devtron.ai](mailto:support@devtron.ai).
-{% endhint %}
+:::
5. Go back to your **Devtron Dashboard URL** page. Paste your license key under the **License Key** field, and click **Activate**.
- 
+ 
+
Figure 16: Pasting License Key and Activating
6. Devtron Freemium will be activated, and you can log in to **Devtron Dashboard**.
- 
+ 
+
Figure 17: Log in as Administrator
-{% hint style="info" %}
+:::info
**Facing Issues?**
Visit the [Troubleshoot](devtron-freemium.md#troubleshoot-issues) section to identify the issue or connect with [Devtron Support](mailto:support@devtron.ai).
-{% endhint %}
+:::
---
@@ -177,7 +259,8 @@ Visit the [Troubleshoot](devtron-freemium.md#troubleshoot-issues) section to ide
1. After successful license activation, you will see the Devtron login page.
- 
+ 
+
Figure 18: Devtron Login Page
2. Initially, log in with the administrator credentials. By default, the username is **admin**. Run the following command to get the admin password:
```bash
@@ -185,15 +268,14 @@ Visit the [Troubleshoot](devtron-freemium.md#troubleshoot-issues) section to ide
-o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
```
-{% hint style="success" %}
-### Next Recommended Action
-
+:::success Next Recommended Action
After the initial login, we recommend you set up an [Single Sign-On (SSO) service](../../user-guide/global-configurations/sso-login.md) like Google, GitHub, etc., and then [add other members](../../user-guide/global-configurations/authorization/user-access.md#add-users) (including yourself). Thereafter, they can log in using the configured SSO.
-{% endhint %}
+:::
3. After a successful login, the **Devtron Dashboard** will open, and you can explore all the enterprise features supported by Devtron Freemium.
- 
+ 
+
Figure 19: Devtron Dashboard
---
@@ -207,19 +289,22 @@ In Devtron, click the **Help** menu (top-right corner) → **About Devtron** to
* Installation fingerprint
* Enterprise version
-
+
+
Figure 20: 'About Devtron' Help Menu
### Update License
If you have a new license key, you can update the license key directly within Devtron, from the **About Devtron** page.
-
+
+
Figure 21: Updating License
### Upgrade License
If you want to add more than one cluster, email us at enterprise@devtron.ai or reach out to your Devtron representative to upgrade your license.
-
+
+
Figure 22: Upgrade License
---
@@ -227,12 +312,12 @@ If you want to add more than one cluster, email us at enterprise@devtron.ai or r
| Issue | What it means | Where is it shown | Solution |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------ |
-|
| You have added more than one cluster | Devtron Dashboard Page or License Dashboard | Reach out to enterprise@devtron.ai for renewal |
+|
License Key Already Exists for Fingerprint Snapshot
| You cannot generate more than 1 license key for 1 fingerprint | License Dashboard (Step-3) | Contact Support |
---
@@ -276,4 +361,4 @@ If the cluster is deleted, you will not be able to claim a Freemium license on a
If you need help, contact [support@devtron.ai](mailto:support@devtron.ai).
-
+
\ No newline at end of file
diff --git a/docs/setup/install/devtron-oss.md b/docs/setup/install/devtron-oss.md
old mode 100644
new mode 100755
index 1621693c9d..9aad5f8928
--- a/docs/setup/install/devtron-oss.md
+++ b/docs/setup/install/devtron-oss.md
@@ -1,3 +1,6 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
# Install Devtron OSS
## Introduction
@@ -8,15 +11,13 @@ The table below shows the installation options available in Devtron OSS. Further
| Installation Option | What Is Included | When To Use |
| -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------------- |
-| [**Minimal (without integrations)**](devtron-oss.md#install-devtron-without-integrations) | Dashboard + Resource Browser + Core operator configurations | A unified view of Helm apps, FluxCD apps, ArgoCD apps, and their related K8s resources |
-| [**With CI/CD**](devtron-oss.md#install-devtron-with-ci-cd) | Everything in Minimal + Build and Deploy (CI/CD) module | You need a complete CI-CD pipeline for your custom apps (a.k.a Devtron Apps) |
-| [**With CI/CD + GitOps (Argo CD)**](devtron-oss.md#install-devtron-with-ci-cd--gitops-argocd) | Everything in CI/CD + GitOps (Argo CD) module | You need automated, Git-driven deployments |
-
-{% hint style="success" %}
-#### Not Sure What To Choose?
+| [**Minimal (without integrations)**](#option-a-minimal-without-integrations) | Dashboard + Resource Browser + Core operator configurations | A unified view of Helm apps, FluxCD apps, ArgoCD apps, and their related K8s resources |
+| [**With CI/CD**](#option-b-install-devtron-with-cicd) | Everything in Minimal + Build and Deploy (CI/CD) module | You need a complete CI-CD pipeline for your custom apps (a.k.a Devtron Apps) |
+| [**With CI/CD + GitOps (Argo CD)**](#option-c-install-devtron-with-cicd--gitops-argocd) | Everything in CI/CD + GitOps (Argo CD) module | You need automated, Git-driven deployments |
+:::success Not Sure What To Choose?
Begin with the **Minimal** version. You can always install CI/CD and GitOps integrations later from [Devtron Stack Manager](../../user-guide/integrations/).
-{% endhint %}
+:::
---
@@ -26,9 +27,7 @@ Begin with the **Minimal** version. You can always install CI/CD and GitOps inte
* [Helm v3.8+ installed](https://helm.sh/docs/intro/install/)
* For production cases, fulfill the [Infrastructure Recommendations](prod-infra.md)
-{% hint style="warning" %}
-#### Cluster created on AWS? Is your EKS version 1.23 or above?
-
+:::warning Cluster created on AWS? Is your EKS version 1.23 or above?
Install ['AWS EBS CSI' driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) using the following command:
```bash
@@ -37,23 +36,19 @@ helm repo update
helm upgrade --install aws-ebs-csi-driver \
--namespace kube-system aws-ebs-csi-driver/aws-ebs-csi-driver
```
-{% endhint %}
-
-{% hint style="warning" %}
-#### Using K3s?
+:::
+:::warning Using K3s?
K3s does not include a default storage provisioner, so before you run Helm install in [Step 2](devtron-oss.md#step-2-choose-an-installation-option), apply the Rancher local-path-provisioner to enable dynamic storage:
```bash
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
```
-{% endhint %}
-
-{% hint style="info" %}
-#### Want to Customize the Installation?
+:::
+:::info Want to Customize the Installation?
See [Additional Installation Resources](../../reference/README.md) for production infra recommendations, air-gapped installs, blob storage, config overrides, StorageClass, Database, Ingress setup, backups, and more.
-{% endhint %}
+:::
---
@@ -68,10 +63,7 @@ helm repo update devtron
## Step 2: Choose an Installation Option
-{% tabs %}
-{% tab title="Minimal (Dashboard Only)" %}
-
-### Install Devtron without Integrations
+### Option A: Minimal (without integrations)
After you [add Devtron Helm Repository](#step-1-add-devtron-helm-repository) run the command below:
@@ -79,11 +71,8 @@ After you [add Devtron Helm Repository](#step-1-add-devtron-helm-repository) run
helm install devtron devtron/devtron-operator \
--create-namespace --namespace devtroncd
```
-{% endtab %}
-{% tab title="With CI/CD" %}
-
-### Install Devtron with CI/CD
+### Option B: Install Devtron with CI/CD
After you [add Devtron Helm Repository](#step-1-add-devtron-helm-repository) run the command below:
@@ -92,11 +81,8 @@ helm install devtron devtron/devtron-operator \
--create-namespace --namespace devtroncd \
--set installer.modules={cicd}
```
-{% endtab %}
-
-{% tab title="With CI/CD + GitOps (Argo CD)" %}
-### Install Devtron with CI/CD + GitOps (ArgoCD)
+### Option C: Install Devtron with CI/CD + GitOps (ArgoCD)
After you [add Devtron Helm Repository](#step-1-add-devtron-helm-repository) run the command below:
@@ -106,13 +92,9 @@ helm install devtron devtron/devtron-operator \
--set installer.modules={cicd} \
--set argo-cd.enabled=true
```
-{% endtab %}
-{% endtabs %}
-{% hint style="info" %}
-### How much time does it take for installation?
-
-It usually takes 5–15 minutes to spin up all Devtron microservices (depending on your installation option).
+:::info How much time does it take for installation?
+It usually takes 5-15 minutes to spin up all Devtron microservices (depending on your installation option).
You may check the status by running the command below. If the output is `Applied`, Devtron is installed.
@@ -121,24 +103,25 @@ kubectl -n devtroncd get installers installer-devtron \
-o jsonpath='{.status.sync.status}'
```
-{% endhint %}
+:::
---
## Step 3: Obtain the Dashboard URL
-{% tabs %}
-{% tab title="For EKS/AKS/GKE" %}
+
+
To access the dashboard on EKS, AKS, or GKE cluster, run the following command:
```bash
kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
```
-**Dashboard URL**: The LoadBalancer URL displayed in the output
-{% endtab %}
+**Dashboard URL**: The LoadBalancer URL displayed in the output
+
+
-{% tab title="MicroK8s/Kind/K3s (and Cloud VMs)" %}
+
You have a few different ways to open the Devtron dashboard on local or VM-based clusters.\
Pick the method that works best for you: quick port-forward, persistent NodePort, or remote access via kubeconfig.
@@ -150,9 +133,9 @@ Run the following command to port-forward the devtron service to port `8000`
kubectl -n devtroncd port-forward service/devtron-service 8000:80
```
-**Dashboard URL**: `http://127.0.0.1:8000`
+**Dashboard URL**: `http://127.0.0.1:8000`
-***
+---
#### Accessing the Dashboard via NodePort
@@ -168,9 +151,9 @@ Then run the following command to get the port number assigned to the service:
kubectl get svc -n devtroncd devtron-service -o jsonpath='{.spec.ports[0].nodePort}'
```
-**Dashboard URL**: `http://:/dashboard`
+**Dashboard URL**: `http://:/dashboard`
-***
+---
#### Accessing the Dashboard locally from a remote VM (Port Forwarding via Kubeconfig)
@@ -184,25 +167,28 @@ kubectl config use-context # Set the correct context.
kubectl -n devtroncd port-forward service/devtron-service 8000:80
```
-**Dashboard URL**: `http://127.0.0.1:8000`
-{% endtab %}
+**Dashboard URL**: `http://127.0.0.1:8000`
-{% tab title="Minikube" %}
+
+
+
+
Run the following command:
```bash
minikube service devtron-service --namespace devtroncd
```
-**Dashboard URL**: (Directly opens in your browser)
-{% endtab %}
-{% endtabs %}
+**Dashboard URL**: (Directly opens in your browser)
+
+
+
---
## Step 4: Log in to Devtron
-1. From your browser, visit the dashboard URL (obtained in the previous step) to view the login page of Devtron.
+1. From your browser, visit the Dashboard URL (obtained in the previous step) to view the login page of Devtron.
2. Enter **`admin`** in the username.
3. Run the below command to get your password.
@@ -213,8 +199,6 @@ minikube service devtron-service --namespace devtroncd
You should see the **Devtron Dashboard** post successful login.
-{% hint style="success" %}
-#### Next Recommended Action
-
+:::success Next Recommended Action
After the initial login, we recommend you set up an [Single Sign-On (SSO) service](../../user-guide/global-configurations/sso-login.md) like Google, GitHub, etc., and then [add other members](../../user-guide/global-configurations/authorization/user-access.md#add-users) (including yourself). Thereafter, they can log in using the configured SSO.
-{% endhint %}
+:::
\ No newline at end of file
diff --git a/docs/setup/install/faq-on-installation.md b/docs/setup/install/faq-on-installation.md
old mode 100644
new mode 100755
index f3e7f66f05..c64ac2fad7
--- a/docs/setup/install/faq-on-installation.md
+++ b/docs/setup/install/faq-on-installation.md
@@ -1,3 +1,6 @@
+---
+hide_table_of_contents: true
+---
# FAQ
@@ -43,4 +46,4 @@
-Still facing issues, please reach out to us on [Discord](https://discord.gg/jsRG5qx2gp).
+Still facing issues, please reach out to us on [Discord](https://discord.gg/jsRG5qx2gp).
\ No newline at end of file
diff --git a/docs/setup/install/freemium.md b/docs/setup/install/freemium.md
old mode 100644
new mode 100755
index 1a8f868f5f..914ca8bf3b
--- a/docs/setup/install/freemium.md
+++ b/docs/setup/install/freemium.md
@@ -2,6 +2,9 @@
hidden: true
---
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
# Install Devtron Freemium
## Introduction
@@ -16,16 +19,14 @@ With Devtron Freemium, you can access all the enterprise features limited to add
6. Policies related to approval, deployment, plugins, tags, infra...and many more.
-{% hint style="info" %}
-#### Already using Devtron's Open Source version?
-
+:::info Already using Devtron's Open Source version?
This guide is intended for fresh installation of **Devtron Freemium**.
If you're currently using the open-source (OSS) version of Devtron, we **do not recommend** upgrading your existing setup to Devtron Freemium.
Instead, we suggest you to perform a fresh installation of Devtron Freemium on a separate cluster (following the steps below) for the best experience.
-{% endhint %}
+:::
-***
+---
## Step 1: Go to the Devtron License Dashboard
@@ -37,13 +38,15 @@ Log in with your work email to access the license dashboard. Devtron provides tw
1. Log in using **Google**, **GitHub**, or **Microsoft** SSO providers. Personal email accounts such as Gmail, Yahoo are not supported.
-
+
+
Figure 1: Selecting SSO Provider
2. Once logged in, the **Devtron License Dashboard** will open.
3. Under **Tell Us About You**, enter some basic details to help us improve your Devtron Experience.
4. After entering the details, click **Next** to proceed to [Step 2: Install Devtron](freemium.md#step-2-install-devtron).
-
+
+
Figure 2: Entering the Details
### Method 2: Log In with Email
@@ -51,45 +54,46 @@ You can also log in via **Continue with Email**. This will send a login link to
1. Select **Continue with Email** to log in.
-
+
+
Figure 3: Selecting 'Continue with Email'
2. Enter your work email and select **Send Login Link**
-
+
+
Figure 4: Entering Email
3. A login link will be sent to the email provided by you. If you do not receive the link, you can resend it after 30 seconds.
**Note:** Your login link is valid only for 10 minutes.
-
-
-{% hint style="info" %}
-#### Email not received?
+
+
Figure 5: Sending Login Link
+:::info Email not received?
* Check all sections of the mailbox, including the Spam section.
* If you find the login link email in the Spam section, mark it as 'Not Spam'.
-{% endhint %}
+:::
4. Go to your provided email inbox and use the login link.
-
+
+
Figure 6: Email with Login Link
Once logged in, the **Devtron License Dashboard** will open.
5. Under **Tell Us About You**, enter a few basic details to help us improve your Devtron Experience.
6. Click **Next** to proceed to [Step 2: Install Devtron](freemium.md#step-2-install-devtron).
-
+
+
Figure 7: Entering the Details
-***
+---
## Step 2: Install Devtron
-{% hint style="success" %}
-#### Recommendation
-
+:::success Recommendation
We recommend installing Devtron on a separate Kubernetes cluster, as Devtron Cluster (cluster on which Devtron is installed) has critical system services and should be kept separate from application workloads.
-{% endhint %}
+:::
After entering the basic details, the next step is to install **Devtron Freemium**.
@@ -97,23 +101,20 @@ The installation commands for installing **Devtron in Full Mode** (with integrat
Choose your preferred K8s distribution and follow the displayed commands to install **Devtron in Full Mode**.
-
-
-In case, you want to install Devtron dashboard only, use the commands given in **Devtron without integrations (only dashboard)** tab in [Choose an Installation Option](freemium.md#id-2.2-choose-an-installation-option) section.
+
+
Figure 8: Installing Devtron
-{% hint style="info" %}
-#### Install Devtron in Air-Gapped Environments
+In case, you want to install Devtron dashboard only, use the commands given in **Devtron without integrations (only dashboard)** tab in [Choose an Installation Option](freemium.md#22-choose-an-installation-option) section.
+:::info Install Devtron in Air-Gapped Environments
You can also install Devtron in Air-Gapped environments to securely manage and deploy applications without internet access.
Refer the [Devtron Enterprise (Air‐gapped) Guide](https://github.com/devtron-labs/utilities/wiki/Devtron-Enterprise-\(Air%E2%80%90gapped\)) to install Devtron in Air-Gapped environments.
-{% endhint %}
-
-{% hint style="warning" %}
-#### Note
+:::
+:::warning Note
Please ensure that cluster `kubeconfig` is properly configured and available in your system.
-{% endhint %}
+:::
### 2.1 Add Devtron Helm Repository
@@ -124,8 +125,8 @@ helm repo update devtron
### 2.2 Choose an Installation Option
-{% tabs %}
-{% tab title="Devtron in Full Mode" %}
+
+
* To install Devtron with all core enterprise features **except ArgoCD**:
```bash
@@ -137,9 +138,9 @@ helm install devtron devtron/devtron-enterprise --create-namespace --namespace d
```bash
helm install devtron devtron/devtron-enterprise --create-namespace --namespace devtroncd --set devtron.argo-cd.enabled=true
```
-{% endtab %}
+
-{% tab title="Devtron without integrations (only Dashboard)" %}
+
To install only the Devtron Dashboard (without CI/CD, ArgoCD, Security, Notification, or Monitoring):
```bash
@@ -147,13 +148,13 @@ helm install devtron devtron/devtron-enterprise --create-namespace --namespace d
--set devtron.installer.modules={} --set devtron.security.enabled=false \
--set devtron.notifier.enabled=false --set devtron.security.trivy.enabled=false --set devtron.monitoring.grafana.enabled=false
```
-{% endtab %}
-{% endtabs %}
+
+
### 2.3 Obtain the Dashboard URL
-{% tabs %}
-{% tab title="For EKS/AKS/GKE" %}
+
+
Run the following command to get the Dashboard URL:
```bash
@@ -161,9 +162,9 @@ kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.
```
You can access your Devtron Dashboard using the LoadBalancer URL displayed in the output.
-{% endtab %}
+
-{% tab title="MicroK8s/Kind/K3s" %}
+
#### Accessing the Dashboard locally (MicroK8s/Kind/K3s)
To obtain the Dashboard URL when MicroK8s/Kind/K3s running locally, run the following command to port-forward the devtron service to port `8000`
@@ -201,9 +202,9 @@ kubectl -n devtroncd port-forward service/devtron-service 8000:80
```
The Dashboard URL will be `http://127.0.0.1:8000` on your local machine.
-{% endtab %}
+
-{% tab title="Minikube" %}
+
To access the dashboard on Minikube cluster, run the following command:
```bash
@@ -211,9 +212,9 @@ minikube service devtron-service --namespace devtroncd
```
This will directly open the dashboard URL on your browser
-{% endtab %}
+
-{% tab title="Cloud VMs" %}
+
#### Accessing the Dashboard via NodePort
To obtain the dashboard URL on Cloud VMs using NodePort, run the following command to retrieve the port number assigned to the service:
@@ -241,77 +242,79 @@ kubectl -n devtroncd port-forward service/devtron-service 8000:80
```
The Dashboard URL will be `http://127.0.0.1:8000` on your local machine.
-{% endtab %}
-{% endtabs %}
+
+
After successfully installing Devtron and obtaining the dashboard URL, click **Next** to proceed to [Step 3: Get License Key](freemium.md#step-3-get-license-key)
-***
+---
## Step 3: Get License Key
You will now need to enter your Devtron **Installation Fingerprint** to generate a license key.
-
+
+
Figure 9: Enter Installation Fingerprint
### Get Devtron installation's fingerprint
To get the **Installation Fingerprint**, follow the below steps
-1. Visit your Dashboard URL (which you have obtained in [Step-2.3](freemium.md#id-2.3-obtain-the-dashboard-url)) as shown below.
+1. Visit your Dashboard URL (which you have obtained in [Step-2.3](freemium.md#23-obtain-the-dashboard-url)) as shown below.
-
+
+
Figure 10: License Activation Screen
2. You will see an Installation Fingerprint that uniquely identifies your installation. Copy the fingerprint.
-
+
+
Figure 11: Copying Installation Fingerprint
3. Go back to the **License Dashboard** and paste the fingerprint you copied earlier and click **Get License Key**.
-
+
+
Figure 12: Pasting Installation Fingerprint
4. Your license will be generated. Copy the license key.
-
-
-{% hint style="warning" %}
-#### Note
+
+
Figure 13: Copying Generated License Key
+:::warning Note
The license key you generate will be valid only for your Devtron Freemium installation.
* Only one Devtron Freemium cluster per organization.
* The license key is uniquely mapped to your installation fingerprint.
-{% endhint %}
-
-{% hint style="danger" %}
-#### Warning
+:::
+:::danger Warning
The license is bound to your Kubernetes cluster and cannot be transferred to another cluster. In case cluster is deleted, you cannot claim freemium license on a new cluster.
In such cases, contact [Devtron Support](mailto:support@devtron.ai).
-{% endhint %}
+:::
5. Go back to your **Devtron Dashboard URL** page and paste your license key under **License Key** field and click **Activate**.
-
+
+
Figure 14: Pasting License Key and Activating
6. **Devtron Freemium** will be activated, and you can log in to **Devtron Dashboard**.
-
-
-{% hint style="info" %}
-#### Facing Issues?
+
+
Figure 15: Log in as Administrator
+:::info Facing Issues?
Visit the [Troubleshoot](freemium.md#troubleshoot-issues) section to identify the issue or connect with [Devtron Support](mailto:support@devtron.ai).
-{% endhint %}
+:::
-***
+---
## Log in to Devtron
1. After successful license activation, you will see the Devtron login page.
-
+
+
Figure 16: Devtron Login Page
2. Initially, log in with the administrator credentials. By default, the username is **admin**. Run the following command to get the admin password:
@@ -320,19 +323,18 @@ kubectl -n devtroncd get secret devtron-secret \
-o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
```
-{% hint style="info" %}
-#### Note
-
+:::info Note
When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
After the initial login, we recommend you set up any [Single Sign-On (SSO) service](../../user-guide/global-configurations/sso-login.md) 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 the Dashboard.
-{% endhint %}
+:::
3. After a successful login, the **Devtron Dashboard** will open, and you can explore all the enterprise features supported by Devtron Freemium.
-
+
+
Figure 17: Devtron Dashboard
-***
+---
## Convert Enterprise Free Trial to Freemium
@@ -340,35 +342,40 @@ You can switch to Devtron Freemium at no cost and no reinstallation is required.
After upgrade, with Devtron Freemium, you will be able to access all Devtron enterprise features for free and forever, with the limit of adding one additional connected cluster (the default cluster where Devtron runs + 1 additional connected cluster).
-{% hint style="warning" %}
-#### Mandatory Action Before Upgrading
-
+:::warning Mandatory Action Before Upgrading
Ensure your Enterprise Free Trial has no more than one additional cluster connected (Devtron Cluster + 1 additional connected cluster). If more than one additional cluster is connected, disconnect the extra clusters before upgrading; otherwise, the upgrade will not proceed.
-{% endhint %}
+:::
1. Open your Devtron dashboard and navigate to **Help** → **About Devtron** → **License**.
- 
+ 
+
3. Navigate to the license dashboard; and you will be automatically redirected to the step 3 (Get License Key).
- 
+ 
+
Figure 20: Devtron License Dashboard
4. Paste the fingerprint you copied earlier and click **Get License Key**.
- 
+ 
+
Figure 21: Pasting Fingerprint
5. Your license will be generated. Copy the license key.
- 
+ 
+
Figure 22: Copying the License Key
6. Navigate back to **Help** → **About Devtron** → **License**, and click **Update License**.
- 
+ 
+
Figure 23: Clicking Update License
7. Paste the new license key you copied earlier and click **Activate**; Devtron Freemium is now activated.
- 
+ 
+
Figure 24: Click Activate
-***
+---
## Additional Actions
@@ -380,34 +387,37 @@ In Devtron, click the **Help** menu (top-right corner) → **About Devtron** to
* Installation fingerprint
* Enterprise version
-
+
+
Figure 25: 'About Devtron' Help Menu
### Update License
If you have a new license key, you can update the license key directly within Devtron, from the **About Devtron** page.
-
+
+
Figure 26: Updating License
### Upgrade License
If you want to add more than one cluster, email us at [enterprise@devtron.ai](mailto:enterprise@devtron.ai) or reach out to your Devtron representative to upgrade your license.
-
+
+
Figure 27: Upgrade License
-***
+---
## Troubleshoot Issues
| Issue | What it means | Where is it shown | Solution |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------ |
-|
| Someone from your organization has already availed a license | License Dashboard | Reach out to [enterprise@devtron.ai](mailto:enterprise@devtron.ai) |
-|
| Someone from your organization has already availed a license | License Dashboard | Reach out to [enterprise@devtron.ai](mailto:enterprise@devtron.ai) |
+|
| You have added more than one cluster | Devtron Dashboard Page or License Dashboard | Reach out to enterprise@devtron.ai for renewal |
+|
License Key Already Exists for Fingerprint Snapshot
| You cannot generate more than 1 license key for 1 fingerprint | License Dashboard (Step-3) | Contact Support |
-***
+---
## FAQs
@@ -459,4 +469,4 @@ If the cluster is deleted, you will not be able to claim a Freemium license on a
If you need help, contact [Devtron Support](mailto:support@devtron.ai).
-
+
\ No newline at end of file
diff --git a/docs/setup/install/ingress-setup.md b/docs/setup/install/ingress-setup.md
old mode 100644
new mode 100755
index e889af66eb..8c0490db4f
--- a/docs/setup/install/ingress-setup.md
+++ b/docs/setup/install/ingress-setup.md
@@ -14,7 +14,7 @@ If you have successfully configured Ingress, refer [Post Ingress Setup](#enable-
## Enabling Ingress during Devtron Installation
-If you are installing Devtron, you can enable Ingress either via [set flag](#using-set-flag) or by using [ingress-values.yaml](#using-ingress-values.yaml) to specify the desired Ingress settings.
+If you are installing Devtron, you can enable Ingress either via [set flag](#using-set-flag) or by using [ingress-values.yaml](#using-ingress-valuesyaml) to specify the desired Ingress settings.
### Using set flag
diff --git a/docs/setup/install/install-devtron-Kubernetes-client.md b/docs/setup/install/install-devtron-Kubernetes-client.md
old mode 100644
new mode 100755
index b2fb32d1bd..c19fef9639
--- a/docs/setup/install/install-devtron-Kubernetes-client.md
+++ b/docs/setup/install/install-devtron-Kubernetes-client.md
@@ -9,11 +9,10 @@ The **Devtron Kubernetes Desktop Client** comes packaged with the following modu
* [Kubernetes Resource Browser](#kubernetes-resource-browser) - To manage all Kubernetes resources in your cluster(s)
* [Clusters](#clusters) - To perform troubleshooting and node operations on the cluster(s) you connect from the Devtron Kubernetes Desktop Client
-{% hint style="success" %}
-
+:::success
Try Devtron Freemium to access all the enterprise features for free and forever, limited to adding one additional cluster. [Install Devtron Freemium](https://license.devtron.ai/dashboard)
-{% endhint %}
+:::
---
@@ -25,10 +24,7 @@ Try Devtron Freemium to access all the enterprise features for free and forever,
wget -O devtron-install.bash https://cdn.devtron.ai/k8s-client/devtron-install.bash && [ -f devtron-install.bash ] && sh devtron-install.bash start
```
-{% hint style="info" %}
-
-### Desktop Client not opening?
-
+:::info Desktop Client not opening?
* In case you closed the Devtron Kubernetes Desktop Client browser tab by mistake, you can reopen it by executing the following command in your terminal:
```bash
@@ -41,7 +37,7 @@ Try Devtron Freemium to access all the enterprise features for free and forever,
rm -rf .devtron/
```
-{% endhint %}
+:::
2. Open your terminal and enter the following command to download and run a bash script for generating the [kubeconfig](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/):
@@ -51,23 +47,23 @@ Try Devtron Freemium to access all the enterprise features for free and forever,
The cluster credentials are displayed in the output of the command.
-{% hint style="info" %}
-
-### Important Note
-
+:::info Important Note
Upon executing the above-mentioned command, if you encounter an error saying that you already have a service account named `cd-user`, change the service account name in the command from `cd-user` to `cd-user1` or `cd-user2`.
-{% endhint %}
+:::
3. Fetch the cluster credentials (`Cluster name`, `Server URL`, `Bearer token`) from the terminal and note them aside.
- 
+ 
+
Figure 1: Fetch Cluster Credentials
-4. Navigate to **Global Configurations** → **Clusters** → **Add cluster** and paste the credentials in their respective fields.
+4. Navigate to **Global Configurations** → **Clusters & Environments** → **Add cluster** and paste the credentials in their respective fields.
- 
+ 
+
5. Click **Save Cluster**. This cluster will now be displayed in the **Kubernetes Resource Browser** page. Refer [Kubernetes Resource Browser](#kubernetes-resource-browser) or [Clusters](#clusters) in the Devtron Kubernetes Desktop Client for more information.
@@ -77,17 +73,14 @@ Upon executing the above-mentioned command, if you encounter an error saying tha
sh devtron-install.bash stop
```
-{% hint style="info" %}
-
-### Note
-
+:::info Note
The next time, if you wish to run the Devtron Kubernetes Desktop Client again, run the following command in your terminal:
```bash
sh devtron-install.bash start
```
-{% endhint %}
+:::
---
@@ -111,17 +104,21 @@ On the left side bar, under the **K8s Resources** tab, the Kubernetes resources
* Custom Resource
-
+
+
Figure 3: Kubernetes Resource Browser
For the convenience of the user, the Resource Browser page comes with a search box and filters to locate resource kinds quickly.
-
+
+
Figure 4: Search Bar
-
+
+
Figure 5: Cluster and Namespace Filters
### Create a Resource
-
+
+
Figure 6: Create a Pod
#### Sample Script for Creating a Pod
@@ -142,15 +139,18 @@ spec:
### View a Resource
-
+
+
Figure 7: View a Pod
### Update a Resource
-
+
+
Figure 8: Update a Live Manifest
### Delete a Resource
-
+
+
Figure 9: Delete a Pod
---
@@ -158,23 +158,28 @@ spec:
Devtron Kubernetes Desktop Client allows you to add multiple clusters and manage all of them from your local machine. The **Clusters** module allows you to view CPU and Memory metrics like CPU Capacity, Memory Capacity, and much more.
-
+
+
Figure 10: Clusters
### Perform Node Operations
You can perform node operations such as [Cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/), [Drain](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/), and [Taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) either from the (⋮) icon displayed against the cluster name or by clicking the cluster itself.
-
+
+
Figure 11a: Peform Node Operations Using the (⋮) Icon
-
+
+
Figure 11b: Peform Node Operations by Clicking the Cluster
### Access Cluster Terminal
At any time, you can debug and troubleshoot any issues in your cluster using the Cluster Terminal. You can access the Cluster Terminal by either clicking **Terminal** option in the Overview page or by clicking the cluster and then clicking the **Debug** option. The same Cluster Terminal will be opened irrespective of the option that you choose.
-
+
+
---
diff --git a/docs/setup/install/install-devtron-helm-3.md b/docs/setup/install/install-devtron-helm-3.md
deleted file mode 100644
index 41484aa372..0000000000
--- a/docs/setup/install/install-devtron-helm-3.md
+++ /dev/null
@@ -1,265 +0,0 @@
-# Install Devtron using Helm
-
-## Before you begin
-
-Install [Helm3](https://helm.sh/docs/intro/install/).
-
-## Installing Devtron using Helm
-
-1. Add Devtron repository
-2. Update Devtron repository
-3. Install Devtron
-
-
-{% tabs %}
-{% tab title="Install with default configurations" %}
-This installation will use Minio for storing build logs and cache.
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd \
---set installer.modules={cicd}
-```
-{% endtab %}
-
-{% tab title="Install with AWS S3 Buckets" %}
-This installation will use AWS s3 buckets for storing build logs and cache. Refer to the `AWS specific` parameters on the [Storage for Logs and Cache](./installation-configuration.md#storage-for-logs-and-cache) page.
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-helm repo update devtron
-helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set configs.BLOB_STORAGE_PROVIDER=S3 \
---set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
---set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1
-```
-{% endtab %}
-
-{% tab title="Install with Azure Blob Storage" %}
-This installation will use Azure Blob Storage for storing build logs and cache.
-Refer to the `Azure specific` parameters on the [Storage for Logs and Cache](./installation-configuration.md#storage-for-logs-and-cache) page.
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-helm repo update devtron
-helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set secrets.AZURE_ACCOUNT_KEY=xxxxxxxxxx \
---set configs.BLOB_STORAGE_PROVIDER=AZURE \
---set configs.AZURE_ACCOUNT_NAME=test-account \
---set configs.AZURE_BLOB_CONTAINER_CI_LOG=ci-log-container \
---set configs.AZURE_BLOB_CONTAINER_CI_CACHE=ci-cache-container
-```
-{% endtab %}
-{% endtabs %}
-
-For those countries/users where Github is blocked, you can use Gitee as the installation source.
-
-{% tabs %}
-{% tab title="Install with Gitee" %}
-```bash
-helm repo add devtron https://helm.devtron.ai
-helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd --set installer.source=gitee
-```
-{% endtab %}
-{% endtabs %}
-
-If you are planning to use Devtron for `production deployments`, please refer to our recommended overrides for [Devtron Installation](override-default-devtron-installation-configs.md).
-
-
-## Installing Devtron (Beta) using Helm
-
-We also release beta versions of devtron every few days before the stable release for people who would like to explore and test beta features before everyone else. If you want to install a fresh devtron from beta release channel, use the chart in our official devtron repository.
-
-This chart is currently not available on the official helm repository therefore you need to download it to install it.
-
-1. Clone Devtron Repository
-2. Upgrade Helm Dependency
-3. Install Devtron
-
-```bash
-$ git clone [https://github.com/devtron-labs/devtron.git](https://github.com/devtron-labs/devtron.git)
-$ cd devtron/charts/devtron
-$ helm dependency up
-$ #modify values in values.yaml
-$ helm install devtron . --create-namespace --namespace devtroncd \
---set installer.modules={cicd}
-
-```
-{% tab title="Install with AWS S3 Buckets" %}
-This installation will use AWS s3 buckets for storing build logs and cache. Refer to the `AWS specific` parameters on the [Storage for Logs and Cache](./installation-configuration.md#storage-for-logs-and-cache) page.
-```bash
-$ git clone [https://github.com/devtron-labs/devtron.git](https://github.com/devtron-labs/devtron.git)
-$ cd devtron/charts/devtron
-$ helm dependency up
-$ #modify values in values.yaml
-$ helm install devtron . --create-namespace --namespace devtroncd \
---set installer.modules={cicd}\
---set configs.BLOB_STORAGE_PROVIDER=S3 \
---set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
---set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1
-```
-
-{% tab title="Install with Azure Blob Storage" %}
-This installation will use Azure Blob Storage for storing build logs and cache.
-Refer to the `Azure specific` parameters on the [Storage for Logs and Cache](./installation-configuration.md#storage-for-logs-and-cache) page.
-
-```bash
-$ git clone [https://github.com/devtron-labs/devtron.git](https://github.com/devtron-labs/devtron.git)
-$ cd devtron/charts/devtron
-$ helm dependency up
-$ #modify values in values.yaml
-$ helm install devtron . --create-namespace --namespace devtroncd \
---set installer.modules={cicd}\
---set secrets.AZURE_ACCOUNT_KEY=xxxxxxxxxx \
---set configs.BLOB_STORAGE_PROVIDER=AZURE \
---set configs.AZURE_ACCOUNT_NAME=test-account \
---set configs.AZURE_BLOB_CONTAINER_CI_LOG=ci-log-container \
---set configs.AZURE_BLOB_CONTAINER_CI_CACHE=ci-cache-container
-```
-
-> Note: There is no option to upgrade to beta on stack manager UI as of now and you may always see upgrade available for latest stable version using which you'll be moved to latest stable version available.
-
-## Check Devtron installation status
-
-The install commands start Devtron-operator, which takes about 20 minutes to spin up all of the Devtron microservices one by one. You can use the following command to check the status of the installation:
-
-```bash
-kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.status}'
-```
-
-The command executes with one of the following output message, indicating the status of the installation:
-
-| Status | Description |
-| :--- | :--- |
-| `Downloaded` | Installer has downloaded all the manifests and installation is in progress. |
-| `Applied` | Installer has successfully applied all the manifests and installation is complete. |
-
-## Check the installer logs
-
-To check the installer logs run the following command:
-
-```bash
-kubectl logs -f -l app=inception -n devtroncd
-```
-
-## Access Devtron dashboard
-
-If you did not provide a **BASE\_URL** during installation or have used the default installation, Devtron creates a load balancer for you on its own. Use the following command to get the dashboard URL.
-
-```bash
-kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
-```
-
-You will get an output similar to the one shown below:
-
-```bash
-[test2@server ~]$ kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
-[map[hostname:aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com]]
-```
-
-The hostname mentioned here `aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com` is the Loadbalancer URL where you can access the Devtron dashboard.
-
-If you don't see any results or receive a message that says "service doesn't exist," it means Devtron is still installing; please check back in 5 minutes.
-
-> Note: 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.
-
-| Host | Type | Points to |
-| ---: | :--- | :--- |
-| devtron.yourdomain.com | CNAME | aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com |
-
-### Devtron Admin credentials
-
-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.
-
-#### For Devtron version v0.6.0 and higher
-
-Use username:`admin` and for password run command mentioned below.
-```bash
-kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
-```
-
-#### For Devtron version less than v0.6.0
-
-Use username:`admin` and for password run command mentioned below.
-```bash
-kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ACD_PASSWORD}' | base64 -d
-```
-
-## Cleaning Devtron Installer Helm3
-
-Please make sure that you do not have anything inside namespaces devtroncd, devtron-cd, devtron-ci, and devtron-demo as the below steps will clean everything inside these namespaces:
-
-```bash
-helm uninstall devtron --namespace devtroncd
-kubectl delete -n devtroncd -f https://raw.githubusercontent.com/devtron-labs/charts/main/charts/devtron/crds/crd-devtron.yaml
-kubectl delete -n argo -f https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/yamls/workflow.yaml
-kubectl delete ns devtroncd devtron-cd devtron-ci devtron-demo
-```
-
-### Cleanup
-
-Run the following commands to delete all the components installed by Devtron:
-
-```bash
-cd devtron-installation-script/
-
-kubectl delete -n devtroncd -f yamls/
-kubectl delete -n devtroncd -f charts/devtron/templates/devtron-installer.yaml
-kubectl delete -n devtroncd -f charts/devtron/templates/install.yaml
-kubectl delete -n devtroncd -f charts/devtron/crds
-kubectl delete ns devtroncd
-```
-
-### FAQs
-
-
- 1. How will I know when the installation is finished?
-
- Run the following command to check the status of the installation:
-
- ```bash
- kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.status}'
- ```
-
- The above command will print `Applied` once the installation process is complete. The installation process could take up to 30 minutes.
-
-
-
- 2. How do I track the progress of the installation?
-
- Run the following command to check the logs of the Pod:
-
- ```bash
- pod=$(kubectl -n devtroncd get po -l app=inception -o jsonpath='{.items[0].metadata.name}')&& kubectl -n devtroncd logs -f $pod
- ```
-
-
-
- 3. How can I restart the installation if the Devtron installer logs contain an error?
-
- First run the below command to clean up components installed by Devtron installer:
-
- ```bash
- cd devtron-installation-script/
- kubectl delete -n devtroncd -f yamls/
- kubectl -n devtroncd patch installer installer-devtron --type json -p '[{"op": "remove", "path": "/status"}]'
- ```
-
- Next, [install Devtron using Helm3](./install-devtron-helm-3.md)
-
-
-
-Still facing issues, please reach out to us on [discord](https://discord.gg/jsRG5qx2gp).
diff --git a/docs/setup/install/install-devtron-in-airgapped-environment.md b/docs/setup/install/install-devtron-in-airgapped-environment.md
old mode 100644
new mode 100755
index fa363d2bc4..d28664164b
--- a/docs/setup/install/install-devtron-in-airgapped-environment.md
+++ b/docs/setup/install/install-devtron-in-airgapped-environment.md
@@ -1,19 +1,18 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
# Devtron Installation in an Airgapped Environment
## Introduction
In certain scenarios, you may need to deploy Devtron to a Kubernetes cluster that isn’t connected to the internet. Such air-gapped environments are used for various reasons, particularly in industries with strict regulatory requirements like healthcare, banking, and finance. This is because air-gapped environments aren't exposed to the public internet; therefore, they create a controlled and secure space for handling sensitive data and operations.
-{% hint style="success" %}
-
+:::success
Try Devtron Freemium to access all the enterprise features for free and forever, limited to adding one additional cluster. [Install Devtron Freemium](https://license.devtron.ai/dashboard)
-{% endhint %}
-
-{% hint style="warning" %}
-
-### Prerequisites
+:::
+:::warning Prerequisites
1. Install `podman` or `docker` on the VM from where you're executing the installation commands.
2. Get the latest image file
@@ -26,7 +25,7 @@ curl -LO https://raw.githubusercontent.com/devtron-labs/devtron/refs/heads/main/
If you are using Docker, the TARGET_REGISTRY should be in the format `docker.io/`
-{% endhint %}
+:::
---
@@ -207,9 +206,9 @@ This would download the tar file of the devtron-operator chart, Make sure to rep
### Installation Commands
-{% tabs %}
+
-{% tab title="Without Integrations" %}
+
Use the below command to install Devtron without any integrations:
@@ -223,9 +222,9 @@ Use the below command to install Devtron without any integrations:
helm install devtron -n devtroncd --set global.containerRegistry="$TARGET_REGISTRY" --set global.imagePullSecrets[0].name=devtron-imagepull --set-string components.devtron.customOverrides.IS_AIR_GAP_ENVIRONMENT=true
```
-{% endtab %}
+
-{% tab title="With CI/CD" %}
+
Use the below command to install Devtron with only the CI/CD module
@@ -239,9 +238,9 @@ Use the below command to install Devtron with only the CI/CD module
helm install devtron -n devtroncd --set installer.modules={cicd} --set global.containerRegistry="$TARGET_REGISTRY" --set global.imagePullSecrets[0].name=devtron-imagepull --set-string components.devtron.customOverrides.IS_AIR_GAP_ENVIRONMENT=true
```
-{% endtab %}
+
-{% tab title="With CI/CD and GitOps (Argo CD)" %}
+
Use the below command to install Devtron with the CI/CD module and Argo CD
@@ -255,9 +254,9 @@ Use the below command to install Devtron with the CI/CD module and Argo CD
helm install devtron --create-namespace -n devtroncd --set installer.modules={cicd} --set argo-cd.enabled=true --set global.containerRegistry="$TARGET_REGISTRY" --set argo-cd.global.image.repository="${TARGET_REGISTRY}/argocd" --set argo-cd.redis.image.repository="${TARGET_REGISTRY}/redis" --set global.imagePullSecrets[0].name=devtron-imagepull --set-string components.devtron.customOverrides.IS_AIR_GAP_ENVIRONMENT=true
```
-{% endtab %}
+
-{% endtabs %}
+
---
@@ -293,7 +292,7 @@ Please wait until the installation is completed.
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.
-**Username**: `admin`
+**Username**: `admin`
**Password**: Run the following command to get the admin password:
```bash
@@ -301,18 +300,14 @@ kubectl -n devtroncd get secret devtron-secret \
-o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
```
-{% hint style="info" %}
-
-### Next Recommended Action
-
+:::info Next Recommended Action
When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
After the initial login, we recommend you set up any [Single Sign-On (SSO)](../../user-guide/global-configurations/sso-login.md) service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (e.g., GitHub) to log in to the Dashboard.
-{% endhint %}
-
-{% hint style="info" %}
+:::
-If you have questions, please let us know on our discord channel. [](https://discord.gg/jsRG5qx2gp)
+:::info
+If you have questions, please let us know on our discord channel. [](https://discord.gg/jsRG5qx2gp)
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/setup/install/install-devtron-with-cicd-with-gitops.md b/docs/setup/install/install-devtron-with-cicd-with-gitops.md
deleted file mode 100644
index ece7210f5b..0000000000
--- a/docs/setup/install/install-devtron-with-cicd-with-gitops.md
+++ /dev/null
@@ -1,297 +0,0 @@
-# Install Devtron with CI/CD along with GitOps (Argo CD)
-
-## Introduction
-
-In this section, we describe the steps in detail on how you can install Devtron with CI/CD by enabling GitOps during the installation.
-
-{% hint style="success" %}
-
-Try Devtron Freemium to access all the enterprise features for free and forever, limited to adding one additional cluster. [Install Devtron Freemium](https://license.devtron.ai/dashboard)
-
-{% endhint %}
-
-{% hint style="warning" %}
-
-### Prerequisites
-
-* Install [Helm](https://helm.sh/docs/intro/install/), if you have not installed it already.
-
-* If you are using EKS version 1.23 or above, you must also install [aws-ebs-csi-driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html). Run the following command to install AWS EBS CSI driver using Helm:
-
-```bash
-helm repo add aws-ebs-csi-driver \
-https://kubernetes-sigs.github.io/aws-ebs-csi-driver \
-helm repo update \
-helm upgrade --install aws-ebs-csi-driver \
---namespace kube-system aws-ebs-csi-driver/aws-ebs-csi-driver
-```
-
-{% endhint %}
-
----
-
-## Install Devtron with CI/CD along with GitOps (Argo CD)
-
-Run the following command to install the latest version of Devtron with CI/CD along with GitOps (Argo CD) module:
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set argo-cd.enabled=true
-```
-
-**Note**: If you want to configure Blob Storage during the installation, refer [Configure Blob Storage During Installation](#configure-blob-storage-during-installation).
-
-
-
-
----
-
-## Configure Blob Storage during 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 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:
-
-{% tabs %}
-
-{% tab title="MinIO Storage" %}
-
-Run the following command to install Devtron along with MinIO for storing logs and cache.
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set minio.enabled=true \
---set argo-cd.enabled=true
-```
-**Note**: Unlike global cloud providers such as AWS S3 Bucket, Azure Blob Storage and Google Cloud Storage, MinIO can be hosted locally also.
-
-{% endtab %}
-
-{% tab title="AWS S3 Bucket" %}
-
-Refer to the `AWS specific` parameters on the [Storage for Logs and Cache](./installation-configuration.md#aws-specific) 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.
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set configs.BLOB_STORAGE_PROVIDER=S3 \
---set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
---set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1 \
---set argo-cd.enabled=true
-```
-
-* Install using access-key and secret-key for AWS S3 authentication:
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set configs.BLOB_STORAGE_PROVIDER=S3 \
---set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
---set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1 \
---set secrets.BLOB_STORAGE_S3_ACCESS_KEY= \
---set secrets.BLOB_STORAGE_S3_SECRET_KEY= \
---set argo-cd.enabled=true
-```
-
-* Install using S3 compatible storages:
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set configs.BLOB_STORAGE_PROVIDER=S3 \
---set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
---set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1 \
---set secrets.BLOB_STORAGE_S3_ACCESS_KEY= \
---set secrets.BLOB_STORAGE_S3_SECRET_KEY= \
---set configs.BLOB_STORAGE_S3_ENDPOINT= \
---set argo-cd.enabled=true
-```
-
-{% endtab %}
-
-{% tab title="Azure Blob Storage" %}
-
-Refer to the `Azure specific` parameters on the [Storage for Logs and Cache](./installation-configuration.md#azure-specific) page.
-
-Run the following command to install Devtron along with Azure Blob Storage for storing build logs and cache:
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set secrets.AZURE_ACCOUNT_KEY=xxxxxxxxxx \
---set configs.BLOB_STORAGE_PROVIDER=AZURE \
---set configs.AZURE_ACCOUNT_NAME=test-account \
---set configs.AZURE_BLOB_CONTAINER_CI_LOG=ci-log-container \
---set configs.AZURE_BLOB_CONTAINER_CI_CACHE=ci-cache-container \
---set argo-cd.enabled=true
-```
-
-{% endtab %}
-
-{% tab title="Google Cloud Storage" %}
-
-Refer to the `Google Cloud specific` parameters on the [Storage for Logs and Cache](./installation-configuration.md#google-cloud-storage-specific) page.
-
-Run the following command to install Devtron along with Google Cloud Storage for storing build logs and cache:
-
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set configs.BLOB_STORAGE_PROVIDER=GCP \
---set secrets.BLOB_STORAGE_GCP_CREDENTIALS_JSON=eyJ0eXBlIjogInNlcnZpY2VfYWNjb3VudCIsInByb2plY3RfaWQiOiAiPHlvdXItcHJvamVjdC1pZD4iLCJwcml2YXRlX2tleV9pZCI6ICI8eW91ci1wcml2YXRlLWtleS1pZD4iLCJwcml2YXRlX2tleSI6ICI8eW91ci1wcml2YXRlLWtleT4iLCJjbGllbnRfZW1haWwiOiAiPHlvdXItY2xpZW50LWVtYWlsPiIsImNsaWVudF9pZCI6ICI8eW91ci1jbGllbnQtaWQ+IiwiYXV0aF91cmkiOiAiaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tL28vb2F1dGgyL2F1dGgiLCJ0b2tlbl91cmkiOiAiaHR0cHM6Ly9vYXV0aDIuZ29vZ2xlYXBpcy5jb20vdG9rZW4iLCJhdXRoX3Byb3ZpZGVyX3g1MDlfY2VydF91cmwiOiAiaHR0cHM6Ly93d3cuZ29vZ2xlYXBpcy5jb20vb2F1dGgyL3YxL2NlcnRzIiwiY2xpZW50X3g1MDlfY2VydF91cmwiOiAiPHlvdXItY2xpZW50LWNlcnQtdXJsPiJ9Cg== \
---set configs.DEFAULT_CACHE_BUCKET=cache-bucket \
---set configs.DEFAULT_BUILD_LOGS_BUCKET=log-bucket \
---set argo-cd.enabled=true
-```
-
-{% endtab %}
-{% endtabs %}
-
----
-
-## Check Status of Devtron Installation
-
-**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:
-
-```bash
-kubectl -n devtroncd get installers installer-devtron \
--o jsonpath='{.status.sync.status}'
-```
-
-The command executes with one of the following output messages, indicating the status of the installation:
-
-| Status | Description |
-| :--- | :--- |
-| `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. |
-
----
-
-## Check the installer logs
-
-Run the following command to check the installer logs:
-
-```bash
-kubectl logs -f -l app=inception -n devtroncd
-```
-
----
-
-## Devtron dashboard
-
-Run the following command to get the Devtron dashboard URL:
-
-```bash
-kubectl get svc -n devtroncd devtron-service \
--o jsonpath='{.status.loadBalancer.ingress}'
-```
-
-You will get an output similar to the example shown below:
-
-```bash
-[map[hostname:aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com]]
-```
-
-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.
-
-| Host | Type | Points to |
-| :--- | :--- | :--- |
-| devtron.yourdomain.com | CNAME | aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com |
-
----
-
-## Devtron Admin credentials
-
-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.
-
-**Username**: `admin`
-**Password**: Run the following command to get the admin password:
-
-```bash
-kubectl -n devtroncd get secret devtron-secret \
--o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
-```
-
-{% hint style="info" %}
-
-### Next Recommended Action
-
-When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
-
-After the initial login, we recommend you set up any [Single Sign-On (SSO)](../../user-guide/global-configurations/sso-login.md) service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (e.g., GitHub) to log in to the Dashboard.
-
-{% endhint %}
-
-{% hint style="info" %}
-
-If you have questions, please let us know on our discord channel. [](https://discord.gg/jsRG5qx2gp)
-
-{% endhint %}
\ No newline at end of file
diff --git a/docs/setup/install/install-devtron-with-cicd.md b/docs/setup/install/install-devtron-with-cicd.md
deleted file mode 100644
index e8d50a05f3..0000000000
--- a/docs/setup/install/install-devtron-with-cicd.md
+++ /dev/null
@@ -1,297 +0,0 @@
-# Install Devtron with CI/CD
-
-In this section, we describe the steps in detail on how you can install Devtron with CI/CD integration.
-
-{% hint style="success" %}
-
-Try Devtron Freemium to access all the enterprise features for free and forever, limited to adding one additional cluster. [Install Devtron Freemium](https://license.devtron.ai/dashboard)
-
-{% endhint %}
-
-{% hint style="warning" %}
-
-### Prerequisites
-
-* Install [Helm](https://helm.sh/docs/intro/install/), if you have not installed it already.
-
-* If you are using EKS version 1.23 or above, you must also install [aws-ebs-csi-driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html). Run the following command to install AWS EBS CSI driver using Helm:
-
-```bash
-helm repo add aws-ebs-csi-driver \
-https://kubernetes-sigs.github.io/aws-ebs-csi-driver \
-helm repo update \
-helm upgrade --install aws-ebs-csi-driver \
---namespace kube-system aws-ebs-csi-driver/aws-ebs-csi-driver
-```
-
-{% endhint %}
-
----
-
-## Command
-
-Run the following command to install the latest version of Devtron along with the CI/CD module:
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd}
-```
-
-{% hint style="info" %}
-
-If you want to configure Blob Storage during the installation, refer [Configure Blob Storage During Installation](#configure-blob-storage-during-installation).
-
-{% endhint %}
-
-
-
----
-
-## Configure Blob Storage during 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 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:
-
-{% tabs %}
-
-{% tab title="MinIO Storage" %}
-
-Run the following command to install Devtron along with MinIO for storing logs and cache.
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set minio.enabled=true
-```
-**Note**: Unlike global cloud providers such as AWS S3 Bucket, Azure Blob Storage and Google Cloud Storage, MinIO can be hosted locally also.
-
-{% endtab %}
-
-{% tab title="AWS S3 Bucket" %}
-
-Refer to the `AWS specific` parameters on the [Storage for Logs and Cache](./installation-configuration.md#aws-specific) 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.
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set configs.BLOB_STORAGE_PROVIDER=S3 \
---set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
---set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1
-```
-
-* Install using access-key and secret-key for AWS S3 authentication:
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set configs.BLOB_STORAGE_PROVIDER=S3 \
---set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
---set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1 \
---set secrets.BLOB_STORAGE_S3_ACCESS_KEY= \
---set secrets.BLOB_STORAGE_S3_SECRET_KEY=
-```
-
-* Install using S3 compatible storages:
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set configs.BLOB_STORAGE_PROVIDER=S3 \
---set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
---set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
---set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1 \
---set secrets.BLOB_STORAGE_S3_ACCESS_KEY= \
---set secrets.BLOB_STORAGE_S3_SECRET_KEY= \
---set configs.BLOB_STORAGE_S3_ENDPOINT=
-```
-
-{% endtab %}
-
-{% tab title="Azure Blob Storage" %}
-
-Refer to the `Azure specific` parameters on the [Storage for Logs and Cache](./installation-configuration.md#azure-specific) page.
-
-Run the following command to install Devtron along with Azure Blob Storage for storing build logs and cache:
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set secrets.AZURE_ACCOUNT_KEY=xxxxxxxxxx \
---set configs.BLOB_STORAGE_PROVIDER=AZURE \
---set configs.AZURE_ACCOUNT_NAME=test-account \
---set configs.AZURE_BLOB_CONTAINER_CI_LOG=ci-log-container \
---set configs.AZURE_BLOB_CONTAINER_CI_CACHE=ci-cache-container
-```
-
-{% endtab %}
-
-{% tab title="Google Cloud Storage" %}
-
-Refer to the `Google Cloud specific` parameters on the [Storage for Logs and Cache](./installation-configuration.md#google-cloud-storage-specific) page.
-
-Run the following command to install Devtron along with Google Cloud Storage for storing build logs and cache:
-
-```bash
-helm repo add devtron https://helm.devtron.ai
-
-helm repo update devtron
-
-helm install devtron devtron/devtron-operator \
---create-namespace --namespace devtroncd \
---set installer.modules={cicd} \
---set configs.BLOB_STORAGE_PROVIDER=GCP \
---set secrets.BLOB_STORAGE_GCP_CREDENTIALS_JSON=eyJ0eXBlIjogInNlcnZpY2VfYWNjb3VudCIsInByb2plY3RfaWQiOiAiPHlvdXItcHJvamVjdC1pZD4iLCJwcml2YXRlX2tleV9pZCI6ICI8eW91ci1wcml2YXRlLWtleS1pZD4iLCJwcml2YXRlX2tleSI6ICI8eW91ci1wcml2YXRlLWtleT4iLCJjbGllbnRfZW1haWwiOiAiPHlvdXItY2xpZW50LWVtYWlsPiIsImNsaWVudF9pZCI6ICI8eW91ci1jbGllbnQtaWQ+IiwiYXV0aF91cmkiOiAiaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tL28vb2F1dGgyL2F1dGgiLCJ0b2tlbl91cmkiOiAiaHR0cHM6Ly9vYXV0aDIuZ29vZ2xlYXBpcy5jb20vdG9rZW4iLCJhdXRoX3Byb3ZpZGVyX3g1MDlfY2VydF91cmwiOiAiaHR0cHM6Ly93d3cuZ29vZ2xlYXBpcy5jb20vb2F1dGgyL3YxL2NlcnRzIiwiY2xpZW50X3g1MDlfY2VydF91cmwiOiAiPHlvdXItY2xpZW50LWNlcnQtdXJsPiJ9Cg== \
---set configs.DEFAULT_CACHE_BUCKET=cache-bucket \
---set configs.DEFAULT_BUILD_LOGS_BUCKET=log-bucket
-```
-
-{% endtab %}
-{% endtabs %}
-
----
-
-## Check Status of Devtron Installation
-
-{% hint style="info" %}
-The installation takes about 15 to 20 minutes to spin up all of the Devtron microservices one by one
-{% endhint %}
-
-Run the following command to check the status of the installation:
-
-```bash
-kubectl -n devtroncd get installers installer-devtron \
--o jsonpath='{.status.sync.status}'
-```
-
-The command executes with one of the following output messages, indicating the status of the installation:
-
-| Status | Description |
-| :--- | :--- |
-| `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. |
-
----
-
-## Check the Installer Logs
-
-Run the following command to check the installer logs:
-
-```bash
-kubectl logs -f -l app=inception -n devtroncd
-```
-
----
-
-## Devtron Dashboard
-
-Run the following command to get the Devtron dashboard URL:
-
-```bash
-kubectl get svc -n devtroncd devtron-service \
--o jsonpath='{.status.loadBalancer.ingress}'
-```
-
-You will get an output similar to the example shown below:
-
-```bash
-[map[hostname:aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com]]
-```
-
-Use the hostname `aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com` (Loadbalancer URL) to access the Devtron dashboard.
-
-{% hint style="info" %}
-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.
-{% endhint %}
-
-{% hint style="info" %}
-You can also use a `CNAME` entry corresponding to your domain/subdomain to point to the Loadbalancer URL to access at a customized domain.
-{% endhint %}
-
-| Host | Type | Points to |
-| :--- | :--- | :--- |
-| devtron.yourdomain.com | CNAME | aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com |
-
----
-
-## Devtron Admin Credentials
-
-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.
-
-**Username**: `admin`
-**Password**: Run the following command to get the admin password:
-
-```bash
-kubectl -n devtroncd get secret devtron-secret \
--o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
-```
-
-{% hint style="info" %}
-
-### Next Recommended Action
-
-When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
-
-After the initial login, we recommend you set up any [Single Sign-On (SSO)](../../user-guide/global-configurations/sso-login.md) service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (e.g., GitHub) to log in to the Dashboard.
-
-{% endhint %}
-
-{% hint style="info" %}
-
-If you have any questions, please let us know on our Discord channel. [](https://discord.gg/jsRG5qx2gp)
-
-{% endhint %}
\ No newline at end of file
diff --git a/docs/setup/install/install-devtron.md b/docs/setup/install/install-devtron.md
old mode 100644
new mode 100755
index 78aa676870..251bac4bdc
--- a/docs/setup/install/install-devtron.md
+++ b/docs/setup/install/install-devtron.md
@@ -1,18 +1,19 @@
---
hidden: true
+hide_table_of_contents: true
---
-{% hint style="info" %}
-
-### Note
+# Get Admin Credentials
+:::info Note
Refer [Install Devtron](./README.md) to know the available tiers and installation options.
+:::
-{% endhint %}
+## Using Own Kubernetes Cluster?
-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.
+When Devtron is installed on your own Kubernetes cluster, it creates a default admin user and password (with unrestricted access to Devtron). You can use that credentials to log in as an administrator.
-**Username**: `admin`
+**Username**: `admin`
**Password**: Run the following command to get the admin password:
```bash
@@ -20,12 +21,21 @@ kubectl -n devtroncd get secret devtron-secret \
-o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
```
-{% hint style="info" %}
+---
+
+## Using Devtron Cloud (SaaS)?
+
+If you are using the 30-day trial version of [Devtron Cloud (SaaS)](../install/devtron-freemium.md#option-3-devtron-cloud-saas), follow the steps below to get the credentials.
-### Next Recommended Action
+1. Go to [Devtron's License Dashboard](https://license.devtron.ai/dashboard/) and sign in using SSO or registered email address used at the time of installation.
+2. Once logged in, the Devtron License Dashboard will show your existing license. Below the license, you will find the Dashboard URL and login password (username will be `admin`).
+
+ 
+
Figure 1: License Page
+
+:::info Next Recommended Action
When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
After the initial login, we recommend you set up any [Single Sign-On (SSO)](../../user-guide/global-configurations/sso-login.md) service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (e.g., GitHub) to log in to the Dashboard.
-
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/setup/install/installation-configuration.md b/docs/setup/install/installation-configuration.md
old mode 100644
new mode 100755
index efe0d86fc7..c18f43cce3
--- a/docs/setup/install/installation-configuration.md
+++ b/docs/setup/install/installation-configuration.md
@@ -1,3 +1,6 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
# Installation Configuration
## Configure Secrets
@@ -124,10 +127,10 @@ In case, if you do not configure the Blob Storage, then:
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.
-{% tabs %}
+
-{% tab title="MinIO Storage" %}
+
Use the following command to configure MinIO for storing logs and cache.
@@ -142,9 +145,9 @@ helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
--set minio.enabled=true
```
-{% endtab %}
+
-{% tab title="AWS S3 Bucket" %}
+
Use the following command to configure AWS S3 bucket for storing build logs and cache. Refer to the `AWS specific` parameters on the [Storage for Logs and Cache](#aws-specific) page.
* **Configure using S3 IAM policy:**
@@ -199,9 +202,9 @@ helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
--set configs.BLOB_STORAGE_S3_ENDPOINT=
```
-{% endtab %}
+
-{% tab title="Azure Blob Storage" %}
+
Use the following command to configure Azure Blob Storage for storing build logs and cache.
Refer to the `Azure specific` parameters on the [Storage for Logs and Cache](#azure-specific) page.
@@ -217,9 +220,9 @@ helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
--set configs.AZURE_BLOB_CONTAINER_CI_CACHE=ci-cache-container
```
-{% endtab %}
+
-{% tab title="Google Cloud Storage" %}
+
Use the following command to configure Google Cloud Storage for storing build logs and cache.
Refer to the `Google Cloud specific` parameters on the [Storage for Logs and Cache](#google-cloud-storage-specific) page.
@@ -235,9 +238,9 @@ helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
--set configs.DEFAULT_BUILD_LOGS_BUCKET=log-bucket
```
-{% endtab %}
+
-{% tab title="S3-compatible Storage" %}
+
Use the following command to configure S3-compatible storage (e.g., Longhorn) for storing build logs and cache.
```bash
@@ -255,8 +258,8 @@ helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
--set configs.BLOB_STORAGE_S3_ENDPOINT=
```
-{% endtab %}
-{% endtabs %}
+
+
---
@@ -379,13 +382,12 @@ Before installing Devtron, create the following databases on your external Postg
4. **casbin** - Authorization and policy database
5. **clairv4** - (*Optional*) Required only if you are using [Clair](../../user-guide/integrations/vulnerability-scanning/clair.md) for image scanning instead of [Trivy](../../user-guide/integrations/vulnerability-scanning/trivy.md)
-{% hint style="warning" %}
-### Not sure how to create a PostgreSQL database?
+:::warning Not sure how to create a PostgreSQL database?
Here’s how you can create databases using popular providers:
* [Amazon RDS instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html)
* [Google Cloud SQL for PostgreSQL](https://cloud.google.com/sql/docs/postgres/create-instance#create-2nd-gen)
* [Azure Database for PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/quickstart-create-server)
-{% endhint %}
+:::
#### Database Creation Commands
@@ -404,10 +406,9 @@ CREATE DATABASE clairv4;
### Devtron Configuration for External DB
-{% hint style="warning" %}
-### Note
+:::warning Note
Ensure the [required databases](#database-creation-commands) exist before proceeding.
-{% endhint %}
+:::
When installing Devtron, you can specify your external PostgreSQL by using either of the following:
* Updating `values.yaml` file
@@ -501,4 +502,4 @@ HIDE_DISCORD=false
|-|-|
|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.|
+|HIDE_DISCORD | Hides discord chatbot from the dashboard.|
\ No newline at end of file
diff --git a/docs/setup/install/override-default-devtron-installation-configs.md b/docs/setup/install/override-default-devtron-installation-configs.md
old mode 100644
new mode 100755
index ee3eb02a46..a036b96077
--- a/docs/setup/install/override-default-devtron-installation-configs.md
+++ b/docs/setup/install/override-default-devtron-installation-configs.md
@@ -82,4 +82,4 @@ In the existing namespace, apply the production overrides as we do it above.
```bash
kubectl apply -f prod-configs -n devtroncd
-```
+```
\ No newline at end of file
diff --git a/docs/setup/install/prod-infra.md b/docs/setup/install/prod-infra.md
old mode 100644
new mode 100755
index b4baae137e..beccbc1959
--- a/docs/setup/install/prod-infra.md
+++ b/docs/setup/install/prod-infra.md
@@ -46,10 +46,9 @@ Use our provided [Terraform scripts](https://github.com/devtron-labs/utilities/t
### Azure (AKS)
Use our provided [Terraform scripts](https://github.com/devtron-labs/utilities/tree/main/terraform/terraform-aks) to set up AKS cluster for Devtron.
-{% hint style="success" %}
-### Next Step
+:::success Next Step
Proceed with the [Devtron installation on your cluster](../install/devtron-oss.md).
-{% endhint %}
+:::
---
@@ -67,10 +66,7 @@ Below are the core components (Devtron microservices) for which you need to allo
| **Kubewatch** | 200m | 300m | 600Mi | 1000Mi |
-{% hint style="info" %}
-
-### Need a YAML template to add resources?
-
+:::info Need a YAML template to add resources?
You can create a resources file similar to this [YAML file](https://github.com/devtron-labs/devtron/blob/main/charts/devtron/resources-small.yaml) and add resources according to your load and requirements for any service you want, and remove those you don’t wish to modify.
Run the following command once the file is ready:
@@ -79,7 +75,7 @@ Run the following command once the file is ready:
helm upgrade devtron devtron/devtron-operator -n devtroncd --reuse-values -f resources-values-file.yaml
```
-{% endhint %}
+:::
---
@@ -89,11 +85,11 @@ helm upgrade devtron devtron/devtron-operator -n devtroncd --reuse-values -f res
To ensure CI workloads run exclusively on the dedicated CI nodes, you need to specify the taints and labels to the node. Then, for the CI build pods, you can add the tolerations and node selectors in the `devtron-custom-cm` (ConfigMap) of `devtroncd` namespace using [these keys](./installation-configuration.md#configure-overrides). These will automatically propagate to CI workloads when they are created.
-If you are following our [Cloud-Specific Setup Guidelines](#id-2.-cloud-specific-setup-guidelines) then set the below values for the keys in `devtron-custom-cm`:
+If you are following our [Cloud-Specific Setup Guidelines](#2-cloud-specific-setup-guidelines) then set the below values for the keys in `devtron-custom-cm`:
``` bash
CI_NODE_LABEL_SELECTOR: purpose=ci
CI_NODE_TAINTS_KEY: dedicated
CI_NODE_TAINTS_VALUE: ci
-```
+```
\ No newline at end of file
diff --git a/docs/setup/install/uninstall-devtron.md b/docs/setup/install/uninstall-devtron.md
old mode 100644
new mode 100755
index 83222b5ddd..ec65f714ed
--- a/docs/setup/install/uninstall-devtron.md
+++ b/docs/setup/install/uninstall-devtron.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Uninstall Devtron
To uninstall Devtron, run the following command:
@@ -16,5 +20,4 @@ kubectl delete ns devtroncd devtron-cd devtron-ci devtron-demo argo
```
-**Note**: If you have questions, please let us know on our discord channel. [](https://discord.gg/jsRG5qx2gp)
-
+**Note**: If you have questions, please let us know on our discord channel. [](https://discord.gg/jsRG5qx2gp)
\ No newline at end of file
diff --git a/docs/setup/start-using.md b/docs/setup/start-using.md
old mode 100644
new mode 100755
index 7fd5959358..e45a351d63
--- a/docs/setup/start-using.md
+++ b/docs/setup/start-using.md
@@ -2,7 +2,7 @@
#### configure docker registry
-Please [setup docker registry](../user-guide/global-configurations/docker-registries.md) before deploying application.
+Please [setup docker registry](../user-guide/global-configurations/container-registries.md) before deploying application.
## Deploying Applications
@@ -10,9 +10,8 @@ Please [setup docker registry](../user-guide/global-configurations/docker-regist
Please use [this spring boot app](https://github.com/nishant-d/demo.git) repo for reference and follow steps described in the video
-{% embed url="https://www.youtube.com/watch?v=Tz01aKDqBAI&feature" caption="" %}
+
### deploy helm chart
-for deploying helm chart follow [helm chart installation guide](../user-guide/deploy-chart/)
-
+for deploying helm chart follow [helm chart installation guide](../user-guide/deploy-chart/)
\ No newline at end of file
diff --git a/docs/setup/upgrade-devtron.md b/docs/setup/upgrade-devtron.md
deleted file mode 100644
index 03e9482ceb..0000000000
--- a/docs/setup/upgrade-devtron.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# Upgrade Devtron
-
diff --git a/docs/setup/upgrade/README.md b/docs/setup/upgrade/README.md
old mode 100644
new mode 100755
index 478931ad44..4fce793b9d
--- a/docs/setup/upgrade/README.md
+++ b/docs/setup/upgrade/README.md
@@ -18,4 +18,4 @@ Devtron can be upgraded in one of the following ways:
## Upgrade Devtron from the UI
- [Update Devtron from Devtron UI](upgrade-devtron-ui.md)
-- [Update Devtron to beta version](devtron-upgrade-to-beta.md)
+- [Update Devtron to beta version](devtron-upgrade-to-beta.md)
\ No newline at end of file
diff --git a/docs/setup/upgrade/devtron-upgrade-0.2.x-0.3.x.md b/docs/setup/upgrade/devtron-upgrade-0.2.x-0.3.x.md
old mode 100644
new mode 100755
diff --git a/docs/setup/upgrade/devtron-upgrade-0.3.x-0.3.x.md b/docs/setup/upgrade/devtron-upgrade-0.3.x-0.3.x.md
old mode 100644
new mode 100755
index 17895d026f..c47930a29c
--- a/docs/setup/upgrade/devtron-upgrade-0.3.x-0.3.x.md
+++ b/docs/setup/upgrade/devtron-upgrade-0.3.x-0.3.x.md
@@ -6,7 +6,7 @@ If you want to check the current version of Devtron you are using, please use th
kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
```
-## Follow the below mentioned steps to upgrade the Devtron version using Helm
+## Upgrade the Devtron version using Helm
1. Fetch the latest Devtron helm chart
@@ -27,7 +27,7 @@ helm upgrade devtron devtron/devtron-operator --namespace devtroncd --set instal
```
-## Follow the below mentioned steps to upgrade the Devtron version using Kubectl
+## Upgrade the Devtron version using Kubectl
1. Input the target Devtron version that you want to upgrade to. You can find the latest releases from Devtron on Github https://github.com/devtron-labs/devtron/releases
diff --git a/docs/setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md b/docs/setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md
old mode 100644
new mode 100755
index 1c85beab45..db384a13f0
--- a/docs/setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md
+++ b/docs/setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md
@@ -6,7 +6,7 @@ If you want to check the current version of Devtron you are using, please use th
kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
```
-## Follow the below mentioned steps to upgrade the Devtron version using Helm
+## Upgrade the Devtron version using Helm
### 1. Check the devtron release name
```bash
@@ -64,4 +64,4 @@ DEVTRON_TARGET_VERSION=v0.4.x
helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
-f https://raw.githubusercontent.com/devtron-labs/devtron/$DEVTRON_TARGET_VERSION/charts/devtron/devtron-bom.yaml \
--set installer.modules={cicd} --reuse-values
-```
+```
\ No newline at end of file
diff --git a/docs/setup/upgrade/devtron-upgrade-0.4.x-0.4.x.md b/docs/setup/upgrade/devtron-upgrade-0.4.x-0.4.x.md
old mode 100644
new mode 100755
index 8fdeb8cc5d..912d9f176a
--- a/docs/setup/upgrade/devtron-upgrade-0.4.x-0.4.x.md
+++ b/docs/setup/upgrade/devtron-upgrade-0.4.x-0.4.x.md
@@ -6,7 +6,7 @@ If you want to check the current version of Devtron you are using, please use th
kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
```
-## Follow the below mentioned steps to upgrade the Devtron version using Helm
+## Upgrade the Devtron version using Helm
### 1. Check the devtron release name
@@ -44,4 +44,4 @@ DEVTRON_TARGET_VERSION=v0.4.x
helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
-f https://raw.githubusercontent.com/devtron-labs/devtron/$DEVTRON_TARGET_VERSION/charts/devtron/devtron-bom.yaml \
--set installer.modules={cicd} --reuse-values
-```
+```
\ No newline at end of file
diff --git a/docs/setup/upgrade/devtron-upgrade-0.4.x-0.5.x.md b/docs/setup/upgrade/devtron-upgrade-0.4.x-0.5.x.md
old mode 100644
new mode 100755
index 5ee8b63f52..a31068593e
--- a/docs/setup/upgrade/devtron-upgrade-0.4.x-0.5.x.md
+++ b/docs/setup/upgrade/devtron-upgrade-0.4.x-0.5.x.md
@@ -6,7 +6,7 @@ If you want to check the current version of Devtron you are using, please use th
kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
```
-## Follow the below mentioned steps to upgrade the Devtron version using Helm
+## Upgrade the Devtron version using Helm
### 1. Apply Prerequisites Patch Job
diff --git a/docs/setup/upgrade/devtron-upgrade-0.5.x-0.6.x.md b/docs/setup/upgrade/devtron-upgrade-0.5.x-0.6.x.md
old mode 100644
new mode 100755
index ab9cca73ba..d1453ed1e3
--- a/docs/setup/upgrade/devtron-upgrade-0.5.x-0.6.x.md
+++ b/docs/setup/upgrade/devtron-upgrade-0.5.x-0.6.x.md
@@ -6,7 +6,7 @@ If you want to check the current version of Devtron you are using, please use th
kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
```
-## Follow the below mentioned steps to upgrade the Devtron version using Helm
+## Upgrade the Devtron version using Helm
### 1. Check the devtron release name
diff --git a/docs/setup/upgrade/devtron-upgrade-0.6.x-0.7.x.md b/docs/setup/upgrade/devtron-upgrade-0.6.x-0.7.x.md
old mode 100644
new mode 100755
index 16cefd8693..f83b3cda1b
--- a/docs/setup/upgrade/devtron-upgrade-0.6.x-0.7.x.md
+++ b/docs/setup/upgrade/devtron-upgrade-0.6.x-0.7.x.md
@@ -52,4 +52,5 @@ helm upgrade devtron devtron/devtron-operator -n devtroncd --reuse-values -f htt
## Expected Command Output
-
+
+
Figure 1: Command Output
\ No newline at end of file
diff --git a/docs/setup/upgrade/devtron-upgrade-1.5.0.md b/docs/setup/upgrade/devtron-upgrade-1.5.0.md
old mode 100644
new mode 100755
index 747c073b51..ba04b81544
--- a/docs/setup/upgrade/devtron-upgrade-1.5.0.md
+++ b/docs/setup/upgrade/devtron-upgrade-1.5.0.md
@@ -138,4 +138,4 @@ helm repo update
```bash
helm upgrade devtron devtron/devtron-operator -n devtroncd --reuse-values -f https://raw.githubusercontent.com/devtron-labs/devtron/refs/tags/v1.5.1/charts/devtron/devtron-bom.yaml --version 0.22.93
-```
+```
\ No newline at end of file
diff --git a/docs/setup/upgrade/devtron-upgrade-to-beta.md b/docs/setup/upgrade/devtron-upgrade-to-beta.md
old mode 100644
new mode 100755
index 36aaf468cd..58c29f0eac
--- a/docs/setup/upgrade/devtron-upgrade-to-beta.md
+++ b/docs/setup/upgrade/devtron-upgrade-to-beta.md
@@ -17,4 +17,4 @@ $ helm upgrade devtron . --reuse-values --namespace devtroncd \
-f devtron-bom.yaml
```
-> Note: There is no option to upgrade to beta on stack manager UI as of now and you may always see upgrade available for latest stable version using which you'll be moved to latest stable version available.
+> Note: There is no option to upgrade to beta on stack manager UI as of now and you may always see upgrade available for latest stable version using which you'll be moved to latest stable version available.
\ No newline at end of file
diff --git a/docs/setup/upgrade/upgrade-devtron-ui.md b/docs/setup/upgrade/upgrade-devtron-ui.md
old mode 100644
new mode 100755
index 6a2a3e9836..13ce370062
--- a/docs/setup/upgrade/upgrade-devtron-ui.md
+++ b/docs/setup/upgrade/upgrade-devtron-ui.md
@@ -1,8 +1,13 @@
+---
+hide_table_of_contents: true
+---
+
# Update Devtron from Devtron UI
-Devtron can be updated from the **Devtron Stack Manager > About Devtron** section.
+Devtron can be updated from the **Devtron Stack Manager → About Devtron** section.
-
+
+
Upgrade Devtron
* Select **Update to Devtron**
@@ -16,4 +21,4 @@ The update process may show one of the following statuses, with details availabl
| Unknown | Status is unknown at the moment and will be updated shortly. |
| Request timed out | The request to install has hit the maximum number of retries. You may retry the installation or [contact support](https://discord.devtron.ai/) for further assistance. |
-> Updating Devtron also updates the installed integrations.
+> Updating Devtron also updates the installed integrations.
\ No newline at end of file
diff --git a/docs/user-guide/Deploy-sample-app/nodejs_app.md b/docs/user-guide/Deploy-sample-app/nodejs_app.md
deleted file mode 100644
index bd4aa87b8c..0000000000
--- a/docs/user-guide/Deploy-sample-app/nodejs_app.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Let's deploy a sample App
-
-Hurray!
-Your Devtron stack is completely setup. Let's get started by deploying a simple application on it.
-
-{% embed url="https://www.youtube.com/watch?v=9u-pKiWV-tM&t=2s" caption="Deploy a Kubernetes Node.js micro-service using Devtron" %}
-
-## Find out the steps here
-
-This is a sample Nodejs application which we are going to deploy using Devtron. For a detailed step-wise procedure, please have a look at the link below -
-
-[Getting Started with Deploying application through devtron](https://github.com/devtron-labs/getting-started-nodejs#getting-started-with-deploying-application-through-devtron)
\ No newline at end of file
diff --git a/docs/user-guide/ai-recommendations/README.md b/docs/user-guide/ai-recommendations/README.md
new file mode 100755
index 0000000000..372c3206c9
--- /dev/null
+++ b/docs/user-guide/ai-recommendations/README.md
@@ -0,0 +1,61 @@
+---
+title: AI Recommendations
+sidebar_label: AI Recommendations
+---
+
+## Introduction
+
+As you scale with Kubernetes, you may come across the dilemma of inefficiency:
+* Over-provisioned clusters
+* Workloads running at, let's say, 20% utilization
+* Soaring cloud bills
+
+Devtron’s AI-powered initiative redefines how Site Reliability Engineers (SREs) and DevOps teams interact with their infrastructure. It monitors, reasons, and acts on cost inefficiencies using explainable AI.
+
+
+
+It operates across two modules to implement rightsizing actions:
+
+1. [**Notifications**](#notifications) - Automated optimization insights of your Kubernetes resources.
+2. [**Runbooks**](#runbooks) - Predefined or AI-generated remediation workflows.
+
+---
+
+## User Personas
+
+| Persona | Role |
+|----------|------|
+| **SRE / DevOps Engineer** | Primary user for AI recommendations and runbook automation. |
+| **Superadmin** | Reviews approvals and monitors audit trails. |
+| **Developer** | Queries workloads and costs through AI Chat. |
+
+---
+
+## Associated Modules
+
+### Notifications
+
+Sends intimation regarding potential optimization across clusters to save costs.
+* Users can **Approve**, **Reject**, or **Revert** recommendations.
+* Each action links to a relevant runbook for remediation.
+
+[Click here](notifications.md) to know more about Notifications.
+
+---
+
+### Runbooks
+Defines YAML-based remediation actions.
+* Supports indefinite and time-bound approvals.
+* Includes per-cluster execution and audit tracking.
+
+[Click here](runbook.md) to know more about Runbooks.
+
+#### Audit Logs
+Maintains a full record of all user and AI-driven actions.
+* Provides audit trail of runbook.
+* Filterable by user, module, and action type.
+
+:::tip Additional Resources:
+* [**Watch Devtron's AI Capabilities**](https://youtu.be/a_dgwYxrAD4).
+* [**Devtron Intelligence**](../devtron-intelligence.md) - An AI agent that helps you will troubleshooting of workloads.
+* **Ask Devtron Expert** - A simple chat interface for queries and analytics (accessible from the top-right of your screen).
\ No newline at end of file
diff --git a/docs/user-guide/ai-recommendations/notifications.md b/docs/user-guide/ai-recommendations/notifications.md
new file mode 100755
index 0000000000..64db0e675f
--- /dev/null
+++ b/docs/user-guide/ai-recommendations/notifications.md
@@ -0,0 +1,86 @@
+# Notifications
+
+The **Notifications** screen lists AI-generated recommendations for your Kubernetes cluster. Each recommendation highlights cost or performance improvement opportunities.
+
+---
+
+## Viewing Recommendations
+
+Go to **AI Recommendations** → **Notifications** to view the list.
+
+
+
Figure 1: 'Notification' Listing
+
+Each recommendation item includes:
+
+| Field | Description |
+|--------|-------------|
+| **Read/Unread Indicator** | Represented by a bulb icon on the left. Unread notifications display a red dot indicator 🔴. Once you read or acknowledge it, the red dot disappears. |
+| **Title** | One-line description of what the AI recommends. |
+| **Description** | Shows why the recommendation is suggested to you. |
+| **Category** | Tags representing the scope of improvement: e.g. `Cost Optimization` or `Performance Improvement`. |
+| **Priority** | Tags representing the importance of the recommendation item: `Low`, `Medium`, `High`, or `Urgent`. |
+| **Potential Savings** | The impact or extent of savings (e.g., “80% resource reduction”). |
+| **Cluster** | The affected cluster you have added to Devtron. |
+| **Status** | Action Pending, Completed, Failed, etc. Check [all possible statuses and their meaning](#notification-feed-statuses). |
+| **Processed By** | Associated runbook or automation. |
+| **Timestamp** | Date and time when the recommendation is generated or updated. |
+| **(⋮) Context Menu** | **Acknowledge** - To mark as read **Revert Change** - To undo the remediation. Only possible when `Status` = `Completed`. |
+
+You can click a recommendation to get its [Detailed View](#detailed-view).
+
+---
+
+## Detailed View
+
+This modal window has two tabs: [Summary](#summary) and [Recommended Change](#recommended-change):
+
+### Summary
+
+
+
Figure 2: Summary of AI Proposal
+
+Apart from the recommendation details seen earlier, this will show additional information, such as:
+
+* **AI Thought Process** - Displays the line-by-line analysis done by AI before suggesting you the recommendation.
+* **Activity Trail** - Shows the actions taken by the AI as well as the approver.
+
+The next step is to [review the recommendation](#recommended-change).
+
+### Recommended Change
+
+
+
Figure 3: Diff of Proposed Changes
+
+This tab shows you the configuration diff for you to compare the existing configuration vs recommended change.
+If the recommended change is yet to be acted upon or depending on the [current status of notification](#notification-feed-statuses), you get **Approve** and **Reject** button for accepting/discarding the recommendation.
+
+AI automatically generates the runbook corresponding to the recommendation. When the user (superadmin) approves a recommendation, it triggers the corresponding runbook and the remediation takes place.
+
+:::info What is a Runbook?
+A [Runbook](./runbook.md) is a predefined action that Devtron runs to apply a change, such as resizing resources or hibernating a namespace.
+When you approve a recommendation, its linked runbook carries out the change with the required safety checks and approvals.
+:::
+
+
+---
+
+## Extras
+
+### Notification Feed Statuses
+
+Each recommendation in the notification feed reflects one of the following backend statuses.
+
+| Status | Description | User Action |
+|---------|--------------|-------------|
+| **ACTION_REQUIRED** | The engine requires user approval before executing the recommendation. | **Approve / Reject** available. |
+| **READY_FOR_TRIGGER** | All preconditions are met, and the recommendation can be triggered or executed. | May show **Approve** if still pending confirmation; otherwise system-handled. |
+| **ACTION_IN_PROGRESS** | The remediation (runbook) linked to the recommendation is currently executing. | No action because execution is underway. |
+| **COMPLETED** | The action has been successfully executed and finalized. | No action. May show **Revert Change** if rollback is supported. |
+| **REJECTED** | The recommendation was explicitly rejected by the user or system. | No further action available unless the recommendation reappears. |
+| **ERRORED** | The process failed due to an exception or invalid configuration. | No direct action. System or admin intervention may be required. |
+| **REVERTED** | The applied change has been undone, returning to the previous state. | No action. Audit entry only. |
+
+:::tip
+You can filter recommendations by status to monitor ongoing discoveries, pending actions, or completed remediations.
+:::
\ No newline at end of file
diff --git a/docs/user-guide/ai-recommendations/runbook.md b/docs/user-guide/ai-recommendations/runbook.md
new file mode 100755
index 0000000000..c7f13f3dc4
--- /dev/null
+++ b/docs/user-guide/ai-recommendations/runbook.md
@@ -0,0 +1,281 @@
+# Runbooks
+
+## Introduction
+
+A [Runbook](./runbook.md) is a predefined action that Devtron runs to apply a change, such as resizing resources or hibernating a namespace. When you approve an [AI recommendation](notifications.md), its linked runbook carries out the change with the required approvals.
+
+### Using AI-generated Runbooks
+
+Whenever AI detects an optimization opportunity, it automatically generates a corresponding runbook to carry out the recommended change once approved. These runbooks are auto-linked from [Notifications](notifications.md) of **AI Recommendations**.
+
+
+
Figure 1: Runbook Listing
+
+:::info Example of Remediation Action
+When AI recommends a cost optimization such as reducing memory allocation, the linked runbook carries out that change.
+For example, scaling down a pod’s memory limit from 6 Gi to 3 Gi across selected clusters.
+:::
+
+:::tip Next Steps
+1. [Verify/Edit Runbook Spec](#add-runbook-spec)
+2. [Approve/Reject Runbook](#approval-types)
+:::
+
+### Using Your Runbook
+
+If you wish to create or modify a runbook beyond what AI generates automatically, Devtron allows you to create one.
+
+:::info
+Follow this section only if you wish to create a runbook different than the one generated by AI.
+:::
+
+1. From the left navigation, go to **AI Recommendations** → **Runbooks**.
+
+2. Click **Create Runbook**.
+
+ 
+
Figure 2: Creating New Runbook
+
+3. Enter the following details:
+ * **Name** - Example: `update-resource-limits`
+ * **Description** - Example: Updates CPU and memory limits for workloads.
+
+4. Click **Create Runbook** to save.
+
+:::tip Next Steps
+1. [Verify/Edit Runbook Spec](#add-runbook-spec)
+2. [Approve/Reject Runbook](#approval-types)
+:::
+
+---
+
+## Add Runbook Spec
+
+You can edit your runbooks here. Each runbook follows a YAML structure that defines its metadata, tags, and executable steps.
+
+
+
Figure 3: Edit Runbook Spec
+
+Use the YAML editor in Devtron to paste and modify this structure.
+
+```yaml
+apiVersion: devtron.ai/v1
+kind: Runbook
+metadata:
+ name:
+ description:
+ tags:
+ -
+ -
+spec:
+ steps:
+ - name:
+ action:
+ type :
+ parameters:
+ param1:
+ param2:
+ onFailure:
+ - nextStep:
+```
+
+Each step in runbook spec represents one operation that can interact with Kubernetes resources, Devtron apps, or external systems. Below are the most commonly used predefined actions supported by Devtron runbooks.
+
+### Example 1: Get Deployment Manifest
+
+Retrieves the manifest of a specified deployment in a Kubernetes cluster.
+
+```yaml
+spec:
+ steps:
+ - name:
+ action: get-k8s-workload-controller-manifest
+ type : kubectl-get
+ parameters:
+ clusterId: "{{.clusterId}}"
+ group: "{{.group}}"
+ version: "{{.version}}"
+ kind: "Deployment"
+ namespace: "{{.namespace}}"
+ resourceName: "{{.resourceName}}"
+```
+
+:::tip When to use
+To inspect the configuration of an existing deployment before applying any changes.
+:::
+
+### Example 2: Update Resource Spec in Deployment Manifest
+
+Updates the CPU and memory requests or limits for a container inside a Kubernetes workload.
+
+```yaml
+spec:
+ steps:
+ - name:
+ action: update-k8s-workload-resource-spec
+ type : kubectl-patch
+ parameters:
+ clusterId: "{{.clusterId}}"
+ group: "{{.group}}"
+ version: "{{.version}}"
+ kind: "Pod"
+ namespace: "{{.namespace}}"
+ resourceName: "{{.resourceName}}"
+ patch:
+ spec:
+ container:
+ name: "{{.containerName}}"
+ resources:
+ requests:
+ cpu: "{{.newCpuRequestValue}}"
+ memory: "{{.newMemoryRequestValue}}"
+ limits:
+ cpu: "{{.newCpuLimitValue}}"
+ memory: "{{.newMemoryLimitValue}}"
+```
+
+:::tip When to use
+To rightsize workload resource consumption and optimize costs.
+:::
+
+
+### Example 3: Update Resource Spec in Devtron Apps Config
+
+Applies resource specification updates within Devtron-managed application configurations.
+
+```yaml
+spec:
+ steps:
+ - name:
+ action: update-resource-spec-devtron-apps-config
+ type : devtron-app-patch
+ parameters:
+ clusterId: "{{.clusterId}}"
+ group: "{{.group}}"
+ version: "{{.version}}"
+ kind: "Pod"
+ namespace: "{{.namespace}}"
+ resourceName: "{{.resourceName}}"
+ patch:
+ spec:
+ container:
+ name: "{{.containerName}}"
+ resources:
+ requests:
+ cpu: "{{.newCpuRequestValue}}"
+ memory: "{{.newMemoryRequestValue}}"
+ limits:
+ cpu: "{{.newCpuLimitValue}}"
+ memory: "{{.newMemoryLimitValue}}"
+```
+
+:::tip When to use
+To modify resource values for Devtron-managed apps directly through the configuration interface.
+:::
+
+### Example 4: Update Resource Spec in Helm Chart Values
+
+Modifies resource settings defined within Helm chart values YAML files.
+
+```yaml
+spec:
+ steps:
+ - name:
+ action: update-resource-spec-helm-chart-values-yaml
+ type : helm-chart-patch
+ parameters:
+ clusterId: "{{.clusterId}}"
+ group: "{{.group}}"
+ version: "{{.version}}"
+ kind: "Pod"
+ namespace: "{{.namespace}}"
+ resourceName: "{{.resourceName}}"
+ patch:
+ spec:
+ container:
+ name: "{{.containerName}}"
+ resources:
+ requests:
+ cpu: "{{.newCpuRequestValue}}"
+ memory: "{{.newMemoryRequestValue}}"
+ limits:
+ cpu: "{{.newCpuLimitValue}}"
+ memory: "{{.newMemoryLimitValue}}"
+```
+
+:::tip When to use
+To synchronize Helm chart values with runtime resource adjustments.
+:::
+
+### Example 5: Webhook to Any Service
+
+Sends a webhook to an external service for integrations such as Slack notifications, monitoring tools, or CI/CD triggers.
+
+```yaml
+spec:
+ steps:
+ - name:
+ action: webhook
+ type : devtron-action
+ parameters:
+ url: <<"url to which the webhook needs to be sent">>
+ headers: <<"headers to be included in the webhook">>
+ httpMethod: <<"HTTP method to be used (GET, POST, etc.)">>
+ body: <<"body of the webhook">>
+```
+
+:::tip When to use
+To notify other systems or trigger automated workflows upon completion of a Devtron runbook.
+:::
+
+---
+
+## Approval Types
+
+Before execution, every AI-generated runbook requires an approval decision. You can approve or reject its execution for specific clusters and different durations.
+
+
+
Figure 4: Approve or Reject Runbook
+
+When you take an action, Devtron applies the following logic:
+
+* If you approve or reject a runbook, the decision auto-applies to all the recommendations linked to that runbook across the selected clusters.
+* If you approve or reject an individual recommendation, the runbook is rejected only for that specific cluster where the recommendation originated.
+
+
+### Approve Options
+
+| Option | Behavior | Example Use Case |
+| ----------- | ------------------------ | ------------------- |
+| **Forever** | All future runs of this runbook stands indefinitely auto-approved. | For dev or sandbox clusters where downtime or failed runs are acceptable and you want continuous savings. |
+| **Till date & time** | Auto-approves until a specific expiry date and time. | During a maintenance window or before a critical demo, so changes are applied automatically until that period ends. |
+| **For duration** | Auto-approves temporarily for a set number of hours. | For short tests or limited-time fixes, such as approving remediation for the next few hours. |
+
+
+### Reject Options
+| Option | Behavior | Example Use Case |
+| ------------ | ----------------------- | -------------------- |
+| **Forever** | Blocks all future runs of this runbook permanently. | For production clusters where any automated remediation is risky or unwanted. |
+| **Till date & time** | Rejects runs until a specific expiry date and time. | When you want the cluster to stay stable (e.g., during a product demo or release). |
+| **For duration** | Rejects runs temporarily for a few hours. | To pause remediation during high-traffic periods or while verifying manual changes. |
+
+:::note What happens when the approval or rejection period expires?
+When any approval or rejection period ends, the runbook status resets to **Action Pending**. The user is expected to take an action again.
+:::
+
+---
+
+## Audit Logs
+
+Every Runbook logs:
+
+* Created / Updated / Approved / Rejected actions
+* User, timestamp, and resource
+* Full JSON payload for traceability
+
+
+
Figure 5: Audit Log
+
+You can access this under **AI Recommendations** → **Runbooks** → **Audit Logs**.
+
+
diff --git a/docs/user-guide/app-configurations/README.md b/docs/user-guide/app-configurations/README.md
new file mode 100755
index 0000000000..926936eaf1
--- /dev/null
+++ b/docs/user-guide/app-configurations/README.md
@@ -0,0 +1,38 @@
+---
+id: README
+title: Configurations
+sidebar_label: Configurations
+description: Manage GitOps, chart repositories, notifications, and build infrastructure settings for applications in Devtron.
+---
+
+The **Configurations** section in Devtron lets you manage all foundational settings that influence how your applications are built, deployed, and updated.
+
+It provides the configuration layer that integrates source code, chart repositories, and notification systems across your organization.
+
+---
+
+## Table of Contents
+
+### 1. [GitOps](../global-configurations/gitops.md)
+Enable and manage GitOps to synchronize application states between Git repositories and Kubernetes clusters.
+
+### 2. [Git Accounts](../global-configurations/git-accounts.md)
+Add and manage Git provider credentials used for fetching codebases and storing Helm chart configurations.
+
+### 3. [External Links](../global-configurations/external-links.md)
+Add supporting quick links to dashboards, documentation, or observability tools within the Devtron apps.
+
+### 4. [Chart Repository](../global-configurations/chart-repo.md)
+Integrate public or private Helm chart repositories for deploying charts.
+
+### 5. [Deployment Charts](../global-configurations/deployment-charts.md)
+Manage custom Helm charts and deployment templates that define the characteristics of your applications.
+
+### 6. [Notifications](../global-configurations/manage-notification.md)
+Configure notification channels (e.g., Slack, Email, Webhooks) to receive real-time deployment and build alerts.
+
+### 7. [Scoped Variables](../global-configurations/scoped-variables.md)
+Define and manage scoped environment variables that can be reused across multiple application and jobs pipelines.
+
+### 8. [Build Infra](../global-configurations/build-infra.md)
+Tweak the resources (CPU, RAM, and many more) as per the needs of your applications.
\ No newline at end of file
diff --git a/docs/user-guide/app-details/README.md b/docs/user-guide/app-details/README.md
old mode 100644
new mode 100755
index a00cdcb51d..fe0844306e
--- a/docs/user-guide/app-details/README.md
+++ b/docs/user-guide/app-details/README.md
@@ -18,7 +18,8 @@ The **App Details** page acts as a comprehensive dashboard that provides a bird'
* Rollback deployments and much more
-
+
+
Figure 1: "App Details" Page
Consider the **App Details** page as the following two sections:
@@ -26,15 +27,12 @@ Consider the **App Details** page as the following two sections:
* [Manage Kubernetes resources](app-resource-management.md) - Where you can manage the logs, manifest, and events of your Kubernetes resources and scan for vulnerabilities.
-{% hint style="warning" %}
-
-### Who can perform this action?
-
+:::caution Who can perform this action?
Anyone with a `View Only` permission can view this page, but only those at the level of `Admin` (with specific app permissions) or above can take actions on this page.
Refer to [User Permissions](../global-configurations/authorization/user-access.md) for more information.
-{% endhint %}
+:::
---
diff --git a/docs/user-guide/app-details/app-resource-management.md b/docs/user-guide/app-details/app-resource-management.md
old mode 100644
new mode 100755
index fb047306a3..fa729bfcc8
--- a/docs/user-guide/app-details/app-resource-management.md
+++ b/docs/user-guide/app-details/app-resource-management.md
@@ -4,7 +4,8 @@
You can check for vulnerabilities, analyze logs, create ephemeral containers, and manage a few resource kinds directly from the **App Details** page.
-
+
+
Figure 1: Resource Management
---
## K8s Resources
@@ -27,27 +28,25 @@ When you choose a Kubernetes resource kind (e.g., pods), you can perform a few a
| **Actions** |**Description**|
|:------------- |:--------------|
-| **Logs** | Choose **Logs** when you want to view the logs of running pods (old and new). The logs that you get when you click **Logs** and the logs you get when you go via **Log Analyzer** are the same. Note: **Logs** are available only for the **Pod** resource kind. |
+| **Logs** | Choose **Logs** when you want to view the logs of running pods (old and new). The logs that you get when you click **Logs** and the logs you get when you go via **Log Analyzer** are the same. Note: **Logs** are available only for the **Pod** resource kind. |
| **Terminal** | Choose **Terminal** when you want to view logs, debug issues, or execute commands directly. Please note that this terminal is different from the cluster terminal that you get on a node level. |
| **Events** | Choose **Events** when you want to view all the activities (create/update/delete) of the selected pod. |
| **Manifest** | Choose **Manifest** when you want to view or edit the configuration of the selected pod. |
-
+
+
Figure 2: Resource Kinds and Available Actions
---
### Check Vulnerabilities
-{% hint style="warning" %}
-
-### Prerequisite
-
+:::caution Prerequisite
To check vulnerabilities, any one of the following integrations must be installed in your Devtron instance:
* [Clair](../../user-guide/integrations/vulnerability-scanning/clair.md)
* [Trivy](../../user-guide/integrations/vulnerability-scanning/trivy.md)
-{% endhint %}
+:::
One of the primary reasons to check for vulnerabilities is to catch problems in images, or code, or in the Kubernetes manifest before they end up in production. While Code Scan and Kubernetes Manifest Scan are a part of Devtron's Enterprise offering, you can, however, check for vulnerabilities in your images directly from the **App Details** page.
@@ -65,7 +64,8 @@ Follow the below steps to check for vulnerabilities:
3. Click **Check Vulnerabilities**. The **Security** page will be displayed.
- 
+ 
+
Figure 3: Security Page
From the **Security** page, you can view the scan results categorized by severity. When you click on the image link, you will get an even more detailed scan results, including CVE ID (Common Vulnerabilities and Exposures) and package (the specific place where the vulnerability is present) information. To know more, refer to [Security](../../user-guide/security-features.md).
@@ -96,13 +96,12 @@ To know more about analyzing logs, refer to [Logs](../resource-browser/pods.md#l
You create [Ephemeral Containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) when you want to add a temporary container to a running pod for troubleshooting and debugging purposes.
-{% hint style="info" %}
-
+:::info
Ephemeral containers are turned on by default in Kubernetes v1.23 and later
-{% endhint %}
+:::
-{% embed url="https://www.youtube.com/watch?v=TnaHRugYvSI" caption="Launching Ephemeral Container from App Details" %}
+
Follow the instructions below to create an ephemeral container from the **App Details** page:
@@ -114,15 +113,18 @@ Follow the instructions below to create an ephemeral container from the **App De
4. Locate the pod you wish to debug. Hover over and click **Terminal**.
- 
+ 
+
Figure 4: Opening a Terminal
5. Click **Launch Ephemeral Container**. The **Launch ephemeral container on pod** page is displayed.
- 
+ 
+
Figure 5: Launching an Ephemeral Container
6. Choose **Basic** to create a bare minimum ephemeral container:
- 
+ 
+
Figure 6: Basic View
* Enter a prefix to your ephemeral container, for e.g., *debug* in the **Container name prefix** field.
@@ -132,7 +134,8 @@ Follow the instructions below to create an ephemeral container from the **App De
7. Choose **Advanced** if you wish to use labels or annotations to create an ephemeral container since it provides additional key-value options. Refer [Ephemeral Container Spec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#ephemeralcontainer-v1-core) to view the supported options.
- 
+ 
+
Figure 7: Advanced View
8. Click **Launch Container**.
diff --git a/docs/user-guide/app-details/application-summary.md b/docs/user-guide/app-details/application-summary.md
old mode 100644
new mode 100755
index 9d417f5330..e1df3ead25
--- a/docs/user-guide/app-details/application-summary.md
+++ b/docs/user-guide/app-details/application-summary.md
@@ -4,15 +4,13 @@
Devtron helps you to view your application summary in the form of [cards](#cards-overview) and [Application Metrics](#application-metrics). It also helps you perform [quick actions](#action-icons) and [manage the most widely used Kubernetes resources](app-resource-management.md) directly from the **App Details** page.
-
-
-{% hint style="warning" %}
-
-### Who can perform this action?
+
+
Figure 1: App Details
+:::caution Who can perform this action?
Anyone with a `View Only` permission can view this page, but only those at the level of `Admin` (with specific app permissions) or above can take actions on this page. Refer to [User Permissions](../global-configurations/authorization/user-access.md) for more information.
-{% endhint %}
+:::
Follow the below steps to access the **App Details** page:
@@ -28,9 +26,21 @@ The icon next to the **Env** drop-down box denotes the application deployment me
* Deployed using FluxCD
-
+
+
Figure 2: Deployment Method and Manifest Status
-Manifest status (whether they are in sync or not) is denoted by [this](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/app-details/manifest-status-icon.jpg) icon. When you click on this icon, the **Live and desired manifest comparison** page is displayed (read-only) allowing you to compare the manifests and view config drifts (if there are any).
+Manifest status (whether they are in sync or not) is denoted by [this](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/devtron-v2/app-management/devtron-apps/app-details/app-summary/manifest-status-icon.jpg) icon. When you click on this icon, the **Live and desired manifest comparison** page is displayed (read-only) allowing you to compare the manifests and view config drifts (if there are any).
+
+---
+## Filtering Environments
+
+If your application is deployed to several environments, you can narrow down the ones you want to focus on using the environment filter available in the **page header**. This filter is present across all the application pages, including **Overview**, **App Details**, **Build & Deploy**, **Build History**, **Deployment History**, **Deployment Metrics**, and **Configurations**.
+
+Open the filter and multi-select the environments you care about. The application then shows only the selected environments wherever the environment list appears, helping you cut through the noise when an application spans many environments.
+
+:::info Persistent selection
+Your environment selection is saved in your browser's local storage on a per-application basis. The next time you open the same application, Devtron automatically restores the environments you had selected, so you don't have to filter them again.
+:::
---
## Cards Overview
@@ -39,13 +49,13 @@ Devtron provides you a quick summary of your application via cards. Refer to the
| **Card Name** |**Description**|
|:------------- |:--------------|
-| **Application Status** | Tells you the application status (e.g., `Healthy` or `Degraded`). The available application statuses in Devtron are:
Degraded
Healthy
Hibernating
Missing
Not Deployed
Progressing
When you click **Details**, all the details about the resource kinds, their statuses, and the message (if any) are displayed. |
-| **Blackout Window** / **Maintenance Window** | Tells you whether the application deployment is blocked or allowed for the chosen environment. This card also displays the upcoming blackout/maintenance window and the remaining time for the blackout/maintenance window to complete. Refer to [Deployment Window](../global-configurations/deployment-window.md) for more information. |
+| **Application Status** | Tells you the application status (e.g., `Healthy` or `Degraded`). The available application statuses in Devtron are:
Degraded
Healthy
Hibernating
Missing
Not Deployed
Progressing
When you click **Details**, all the details about the resource kinds, their statuses, and the message (if any) are displayed. |
+| **Blackout Window** / **Maintenance Window** | Tells you whether the application deployment is blocked or allowed for the chosen environment. This card also displays the upcoming blackout/maintenance window and the remaining time for the blackout/maintenance window to complete. Refer to [Deployment Window](../global-configurations/deployment-window.md) for more information. |
| **Chart Used** (available only for Helm apps) | Displays the chart used to deploy the application. When you hover over the (**?**) icon in the card, you can directly configure the YAML values by clicking the **Go to Configure** option. |
| **Deployed commit** (available only for Devtron apps) | Displays the commit ID of the deployed image. When you click **Details**, the commit ID, repository name, branch name, and the deployed image ID are displayed. |
-| **Deployment Status** | Tells you the deployment status (e.g., `Succeeded` or `Failed`). The available deployment statuses in Devtron are:
Failed
Progressing
Succeeded
Timed Out
Triggered
When you click **Details**, the complete deployment status, from when it was deployed by whom to the current status of it, is displayed. |
-| **Security** (available only for Devtron and Helm apps) | Displays the following security scan results:
Refer to [Security Policies](../security-features/security-policies.md) for more information.|
-| **Rollout Deployment Visibility** |
**Canary Strategy** - Displays the live progress of how many users are being redirected to the new release. Refer to [Canary Deployments](deployment-visibility.md#for-canary-deployments) for more information.
**Blue Green Strategy** - Displays the progress of the Blue Green deployment. You can [swap traffic](deployment-visibility.md#swap-traffic) or [skip and promote full](deployment-visibility.md#skip--promote-full) directly from this card as per your requirement. Refer to [Blue Green Deployments](deployment-visibility.md#for-blue-green-deployments) for more information.
|
+| **Deployment Status** | Tells you the deployment status (e.g., `Succeeded` or `Failed`). The available deployment statuses in Devtron are:
Failed
Progressing
Succeeded
Timed Out
Triggered
When you click **Details**, the complete deployment status, from when it was deployed by whom to the current status of it, is displayed. |
+| **Security** (available only for Devtron and Helm apps) | Displays the following security scan results:
Image Scan
Code Scan
Manifest Scan
Refer to [Security Policies](../security-features/security-policies.md) for more information.|
+| **Rollout Deployment Visibility** |
**Canary Strategy** - Displays the live progress of how many users are being redirected to the new release. Refer to [Canary Deployments](deployment-visibility.md#for-canary-deployments) for more information.
**Blue Green Strategy** - Displays the progress of the Blue Green deployment. You can [swap traffic](deployment-visibility.md#swap-traffic) or [skip and promote full](deployment-visibility.md#skip--promote-full) directly from this card as per your requirement. Refer to [Blue Green Deployments](deployment-visibility.md#for-blue-green-deployments) for more information.
|
---
## Action Icons
@@ -56,9 +66,11 @@ You can perform a variety of actions right from the **App Details** page using t
When you click the **URLs** icon, the **URLs** page is displayed with the [Ingress Host URL](../../reference/glossary.md#ingress-host-url) and the [Load Balancer URL](../../reference/glossary.md#load-balancer-url) (if available).
-
+
+
You can directly copy the URLs (Ingress and Load Balancer) from the **URLs** page instead of searching in the manifest.
@@ -66,65 +78,56 @@ The Ingress Host URL will point to the load balancer of your application, and yo
### Hibernate
-{% hint style="info" %}
-
-### Note
-
+:::info Note
* This functionality is available as **Hibernate/Unhibernate** icons in Devtron apps and as a **Scale Workloads** icon in Helm apps.
* When there is an ongoing blackout or maintenance window for the application, then the option to hibernate or unhibernate that app (**Scale Workloads**, in the case of a Helm app) will be restricted.
-{% endhint %}
+:::
The **Hibernate** icon (**Scale Workloads**, in the case of a Helm app) allows you to hibernate (to rest) your application when not in use by scaling down the pods to nearly zero in that selected environment (e.g., `QA`). The application will automatically unhibernate when you make a new deployment.
However, you can manually unhibernate the application by clicking the **Unhibernate** icon.
-
+
+
Figure 4: Hibernate Your Application
### Restart Workloads
-{% hint style="info" %}
-
-### Note
-
+:::info Note
* The **Restart Workloads** icon is available only for Devtron custom applications.
* When there is an ongoing blackout or maintenance window for the application, then the **Restart Workloads** icon will be restricted.
-{% endhint %}
+:::
When you are facing issues with your application (e.g., crashing of pods) or prefer to use a new configuration, you restart the workloads. When you click the **Restart Workloads** icon, the **Restart Workloads** page is displayed.
-
+
+
Figure 5: Restart Workloads
When you select a workload and click **Restart Workloads**, all the pods for the selected workloads are restarted using the configured deployment strategy (e.g., `Rolling`).
### Rollback
-{% hint style="info" %}
-
-### Note
-
+:::info Note
* The **Rollback** icon is available only for Devtron custom applications.
* You will not be able to rollback your deployment during blackout window and outside maintenance window of the application.
-{% endhint %}
+:::
You can perform a rollback of your deployment directly from the **App Details** page. When you click the **Rollback** icon, the following page is displayed.
-
+
+
Figure 6: Rollback Your Deployment
* Select an image from the available list of previously deployed images in that specific environment.
-{% hint style="info" %}
-
-### Note
-
+:::info Note
When there is an active policy in place for an environment, and there are no approved images, then no images will be displayed in the **Rollback** page.
-{% endhint %}
+:::
* Select one of the following deployment configurations in the **Deploy** drop-down box:
@@ -142,19 +145,17 @@ When there is an active policy in place for an environment, and there are no app
### Deploy
-{% hint style="info" %}
-
-### Note
-
+:::info Note
* The **Deploy** button is available only for Devtron custom applications.
* When there is an ongoing blackout or maintenance window for the application, the **Deploy** button will be changed to **Deployment is Blocked** and you will not be able to deploy during this time period.
-{% endhint %}
+:::
Devtron helps you in deploying images directly from the **App Details** page. When you click the **Deploy** button, the following page is displayed.
-
+
+
Figure 7: Deploy Your Application
Follow the below steps to deploy an image:
@@ -176,41 +177,38 @@ Follow the below steps to deploy an image:
### Environment Configurations
-{% hint style="info" %}
-
-### Note
-
+:::info Note
The **Environment Configuration** icon is available only for Devtron custom applications.
-{% endhint %}
+:::
You can quickly configure Deployment Templates, ConfigMaps and Secrets for the selected environment directly from the **App Details** page. When you click the **Go to Environment Config** icon, the following page is displayed.
-
+
+
Figure 8: Environment Configurations
-To configure enviroment specific Deployment Templates, ConfigMaps, Secrets, refer to [Environment Overrides](../creating-application/environment-overrides.md#environment-overrides).
+To configure enviroment specific Deployment Templates, ConfigMaps, Secrets, refer to [Environment Overrides](../creating-application/environment-overrides.md).
---
## External Links
All your [external links configured](../../user-guide/global-configurations/external-links.md) in the **Configurations** tab are displayed in the **App Details** page. When you hover around an external link (e.g. `Grafana`), a description of the external link is displayed. To know more, refer to [External Links](../global-configurations/external-links.md).
-
-
-{% hint style="info" %}
-
-### Note
+
+
Figure 9: External Links
+:::info Note
If you enable `App admins can edit` in the **External Links** page, then only non super admins can view the selected links on the **App Details** page.
-{% endhint %}
+:::
---
## Application Metrics
Application metrics help you in evaluating the performance and efficiency of your application. The Application Metrics section can be enabled by enabling the checkbox **Show application metrics** while configuring the application. Refer to [Application Metrics](../creating-application/app-metrics.md) for more information.
-
+
+
Figure 10: Application Metrics
---
## Next Steps
diff --git a/docs/user-guide/app-details/application-tags.md b/docs/user-guide/app-details/application-tags.md
new file mode 100644
index 0000000000..af3f794444
--- /dev/null
+++ b/docs/user-guide/app-details/application-tags.md
@@ -0,0 +1,218 @@
+# Application Tags & Special Tag Handling
+
+## Introduction
+
+Application **tags** (also called **labels**) are key–value pairs you attach to a Devtron application. They are used to organize and search applications, to enforce governance through mandatory tags, and—when **propagated**—to add Kubernetes labels to the resources created for the application, including the **build (CI) infrastructure**.
+
+This document explains:
+
+* What application tags are and how to set them.
+* The **Propagate** flag and where propagated tags end up.
+* How tags are used by the **build infrastructure** (CI build pods).
+* **Special and reserved tag handling** — the `devtron.ai/` reserved prefix, and enterprise **Global Tags** (mandatory tags, deployment policies, and value constraints).
+
+:::info
+### What is OSS vs Enterprise
+* **Application tags** and the **Propagate** flag are available in all editions.
+* **Build Infrastructure profiles** are available in all editions; the **Node Selector**, **Tolerations**, **ConfigMap**, and **Secret** options are **Enterprise-only**.
+* **Global Tags** (mandatory tags, deployment policies, value constraints) are an **Enterprise-only** feature.
+:::
+
+---
+
+## Application Tags (Labels)
+
+Each tag on an application has three parts:
+
+| Field | Type | Description |
+| --- | --- | --- |
+| `key` | string | The tag key. **Required.** Must be a valid Kubernetes label key when propagated. |
+| `value` | string | The tag value. Optional when the tag is **not** propagated; **required** when propagated. |
+| `propagate` | boolean | Whether the tag is added as a Kubernetes label on the application's resources. Defaults to `true`. |
+
+You set tags when creating or editing an application (under the application's **Overview / About** section), or via the API. A tag can be added with only a key (no value) as long as it is **not** propagated.
+
+### Tag Validation Rules
+
+Validation depends on whether the tag is propagated:
+
+* **`propagate = false`** — The tag is stored in Devtron only. The key is required; the value may be empty. It is **not** applied to any Kubernetes resource.
+* **`propagate = true`** — The tag becomes a real Kubernetes label, so both key and value must satisfy Kubernetes label rules:
+ * **Key** must be a *qualified name* (optional DNS-subdomain prefix + name, allowed characters, length limits) and cannot be empty.
+ * **Value** must be a valid Kubernetes label value and cannot be empty.
+
+:::info
+If a propagated tag's key or value is not a valid Kubernetes label, Devtron rejects the application create/update with a validation error.
+:::
+
+---
+
+## The Propagate Flag
+
+The `propagate` flag controls whether a tag is merely metadata inside Devtron or a real Kubernetes label on the resources Devtron creates for the application.
+
+* **`propagate = false`** — The tag is kept only in Devtron's database. Use this for organizational/searchable metadata (owner, team, cost-center notes, etc.) that you don't want on cluster objects.
+* **`propagate = true`** — The tag is added as a Kubernetes label to the application's resources. Use this when you want the label to exist on the cluster for selection, cost allocation, network policies, or observability.
+
+You can filter an application's tags by propagation status when reading them (e.g. "show propagated only").
+
+---
+
+## Tags and Build Infrastructure
+
+When you trigger a CI build, the application's tags travel with the build request. Whether the **propagated** tags are applied as Kubernetes labels on the **build pod** (the buildx/CI runner pod) is controlled by a per-application feature flag.
+
+| Feature Flag | Default | Effect |
+| --- | --- | --- |
+| `propagate-labels-in-buildx-pod` | `FALSE` | When enabled for an application, that application's **propagated** tags are added as labels on the CI build (buildx) pod. When disabled, build pods are not labelled with the application's tags. |
+
+This lets platform teams apply governance, cost-allocation, or scheduling-related labels to the ephemeral build pods, consistently with the deployed workload.
+
+:::info
+### Tags do not select the build infra profile
+A common misconception is that tags choose *which* build infrastructure profile a build uses. They do **not**. Build infrastructure profiles are selected by **scope/identifiers** (application, project, environment) — see below. Tags only add **labels** to the build pod; they don't change its CPU/memory/node placement.
+:::
+
+---
+
+## Build Infrastructure Profiles
+
+A **Build Infrastructure profile** defines the resources and runtime settings for CI build pods. Profiles are applied by **scope** using identifiers (application / project / environment), not by tags.
+
+### Configurable Settings
+
+| Setting | API key | Availability |
+| --- | --- | --- |
+| CPU Request | `cpu_request` | All editions |
+| CPU Limit | `cpu_limit` | All editions |
+| Memory Request | `memory_request` | All editions |
+| Memory Limit | `memory_limit` | All editions |
+| Build Timeout | `timeout` | All editions |
+| Node Selector | `node_selector` | Enterprise |
+| Tolerations | `tolerations` | Enterprise |
+| ConfigMap | `cm` | Enterprise |
+| Secret | `cs` | Enterprise |
+
+### Profile Types
+
+| Type | Description |
+| --- | --- |
+| `GLOBAL` / `DEFAULT` | The baseline profile applied when no specific profile is targeted. |
+| `NORMAL` | A custom profile you create and apply to specific identifiers (apps/projects/environments). |
+
+To target build pods to specific nodes (e.g. a dedicated build node pool), use the **Node Selector** and **Tolerations** settings of an Enterprise build infra profile — this is the supported way to control *where* a build runs, as opposed to using tags.
+
+---
+
+## Special & Reserved Tag Handling
+
+### Reserved prefix: `devtron.ai/`
+
+Tag keys beginning with `devtron.ai/` are reserved by the platform. A tag with this prefix **cannot be propagated** — its `propagate` flag must be `false`. Attempting to propagate a `devtron.ai/*` tag is rejected with a validation error.
+
+### Global Tags [](https://devtron.ai/pricing)
+
+**Global Tags** let platform administrators define tag keys centrally and enforce them across applications. They differ from ordinary application tags in that they can be made **mandatory** and can **gate deployments**.
+
+A Global Tag has the following key properties:
+
+| Field | Description |
+| --- | --- |
+| `key` | The tag key (validated as a Kubernetes qualified name). |
+| `description` | Human-readable description of the tag's purpose. |
+| `mandatoryProjectIdsCsv` | Comma-separated list of project IDs for which this tag is mandatory. The special value `-1` makes it mandatory for **all** projects. |
+| `propagate` | Whether the tag should be propagated as a Kubernetes label. |
+| `deploymentPolicy` | How a missing mandatory tag affects deployments (see below). |
+| `valueConstraint` | Optional restriction limiting the allowed values to a predefined choice list. |
+
+#### Deployment Policies
+
+When a Global Tag is mandatory, its **deployment policy** decides what happens if an application is missing that tag:
+
+| Policy | Effect |
+| --- | --- |
+| `allow` | Tag is not enforced at deploy time; deployment proceeds. |
+| `block` | Deployment is **blocked** (for any environment) until the tag is present. |
+| `block-prod` | Deployment to **production** environments is blocked until the tag is present. |
+| `block-non-prod` | Deployment to **non-production** environments is blocked until the tag is present. |
+
+#### Mandatory Tag Validation
+
+For a project where a Global Tag is mandatory, Devtron validates each application's tags and rejects the operation if:
+
+* the mandatory tag **key is missing**, or
+* the mandatory tag's **value is empty**, or
+* the Global Tag is defined as `propagate = true` but the application's tag is **not** set to propagate.
+
+#### Value Constraints
+
+A Global Tag may carry a **value constraint** that restricts which values are acceptable (a predefined choice list). When enforced, a tag value that is not in the allowed list is rejected.
+
+---
+
+## Validation Rules — Quick Reference
+
+| Rule | Applies to | Behavior |
+| --- | --- | --- |
+| Key required | All tags | A tag must have a non-empty key. |
+| Value required | Propagated tags | A propagated tag must have a non-empty value. |
+| Kubernetes label format | Propagated tags | Key must be a qualified name; value must be a valid label value. |
+| `devtron.ai/` not propagatable | Reserved tags | Keys with this prefix must have `propagate = false`. |
+| Mandatory tag present | Enterprise / Global Tags | Mandatory tags must be present with a value; propagate must match the Global Tag definition. |
+| Value within allowed list | Enterprise / Global Tags | If a value constraint exists, the value must be one of the allowed choices. |
+| Deployment policy | Enterprise / Global Tags | A missing mandatory tag can block deployment per its policy. |
+
+---
+
+## API Reference
+
+### Application Tags
+
+| Method | Endpoint | Description |
+| --- | --- | --- |
+| `GET` | `/app/{appId}/labels` | Get an application's tags (supports `showPropagatedOnly=true/false`). |
+| `GET` | `/app/{appId}/meta` | Get application meta info, including tags. |
+| `PUT` | `/app/{appId}` | Update an application, including its tags. |
+
+### Global Tags (Enterprise)
+
+| Method | Endpoint | Description |
+| --- | --- | --- |
+| `GET` | `/global-tag` | List all active global tags. |
+| `GET` | `/global-tag?id={id}` | Get a global tag by ID. |
+| `GET` | `/global-tag/filter?projectId={id}` | Get active global tags for a project (with mandatory flags). |
+| `POST` | `/global-tag` | Create global tags. |
+| `PUT` | `/global-tag` | Update global tags. |
+| `DELETE` | `/global-tag` | Delete global tags. |
+
+### Build Infrastructure Profiles
+
+| Method | Endpoint | Description |
+| --- | --- | --- |
+| `POST` | `/infra/config/profile/alpha1` | Create a profile. |
+| `GET` | `/infra/config/profile/alpha1?name={name}` | Get a profile. |
+| `PUT` | `/infra/config/profile/alpha1?name={name}` | Update a profile. |
+| `GET` | `/infra/config/profile/alpha1/list` | List profiles. |
+| `POST` | `/infra/config/identifier/{identifierType}/apply` | Apply a profile to identifiers (apps/projects/environments). |
+
+---
+
+## Best Practices
+
+* Use **non-propagated** tags for internal/organizational metadata you don't want on cluster objects.
+* Use **propagated** tags only for labels you genuinely need on Kubernetes resources (cost allocation, network policies, observability). Keep keys/values Kubernetes-valid.
+* Reserve **Global Tags** for governance you must enforce (e.g. an `owner` or `cost-center` tag), and pick a **deployment policy** that matches how strictly it must be enforced (`block-prod` is a common choice).
+* To control **where** build pods run, use a build infra profile's **Node Selector / Tolerations** — not tags.
+* Avoid the `devtron.ai/` prefix for your own tags; it is reserved and cannot be propagated.
+
+---
+
+## Troubleshooting
+
+| Symptom | Likely Cause | Resolution |
+| --- | --- | --- |
+| Cannot save a propagated tag | Key/value not Kubernetes-valid, or value empty | Ensure the key is a qualified name and the value is a valid, non-empty label value. |
+| Propagated tag not showing on build pod | `propagate-labels-in-buildx-pod` disabled for the app | Enable the feature flag for the application. |
+| "tag should not be propagated as label" error | Using a `devtron.ai/` key with propagate on | Set `propagate = false` for `devtron.ai/*` tags. |
+| Deployment blocked by a tag | A mandatory Global Tag is missing or empty | Add the mandatory tag with a valid value (and matching propagate setting) to the application. |
+| Build runs on the wrong nodes | Expecting tags to place build pods | Configure Node Selector / Tolerations in the build infra profile instead. |
diff --git a/docs/user-guide/app-details/deployment-visibility.md b/docs/user-guide/app-details/deployment-visibility.md
old mode 100644
new mode 100755
index 2e7dda36fb..8662b16ead
--- a/docs/user-guide/app-details/deployment-visibility.md
+++ b/docs/user-guide/app-details/deployment-visibility.md
@@ -1,6 +1,6 @@
# Deployment Visibility & Actions
-## Introduction 
+## Introduction
Devtron helps you to manage your **Canary** and **Blue-Green** deployments by providing visibility and easy controls to manage how new versions (releases) are shared with users.
@@ -18,23 +18,17 @@ Devtron allows you to:
* Easily rollback deployments (if needed).
-{% hint style="info" %}
-
-### Prerequisites
-
+:::info Prerequisites
The [Deployment Chart Type](../creating-application/base-config/deployment-template.md#select-a-deployment-chart-type) must be set to rollout in order to use Blue-Green or Canary strategies.
Deployment Visibility and Actions is only available for Canary and Blue-Green Strategies. Refer to the [Deployment Strategies](../creating-application/workflow/cd-pipeline.md#deployment-strategies) to learn more.
-{% endhint %}
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
+:::
+:::caution Who Can Perform This Action?
Users need to have Build and Deploy or above (along with access to the environment and application).
-{% endhint %}
+:::
---
@@ -44,20 +38,23 @@ Users need to have Build and Deploy or above (along with access to the environme
After triggering the deployment, navigate to **App Details**, to get a quick overview of your release rollout status.
-You can click the [Manage Traffic](../application-groups.md#managing-traffic) button to view the rollout status and steps involved in the release.
+You can click the [Manage Traffic](../application-groups.md#managing-traffic-) button to view the rollout status and steps involved in the release.
If you wish you can also trigger the next release steps (for example 25%, 50%, 75%) or you can also trigger the full rollout at once according to your use case.
- 
+ 
+
### For Blue Green deployments
Devtron automatically swaps the traffic from the current running release to the new release based on the defined strategy configuration. In case `autoPromotionEnabled` field value is set to `false`, you can manually swap the traffic from the current release to the new release.
-
+
+
Figure 2: autoPromotionEnabled: false
To do so, follow the steps below:
@@ -67,12 +64,14 @@ To do so, follow the steps below:
2. During Blue-Green deployment, click the **Swap Traffic** button to shift the traffic to application's new release.
- 
+ 
+
Figure 3: Selecting Swap Traffic
3. Enter the name of the environment and select **Swap Traffic**
- 
-
+ 
+
Figure 4: Swap Traffic Pop Up
+
4. This will route the end user traffic from the current running release to the new release on a particular environment.
@@ -86,11 +85,13 @@ To do so, follow the below steps:
2. During Blue-Green deployment, click the **Skip & Promote Full** button to shift the traffic to application's new deployment.
- 
+ 
+
Figure 5: Selecting 'Skip & Promote Full'
3. Enter the name of the environment and select **Promote to Full**.
- 
+ 
+
Figure 6: Promote to Full Pop Up
4. This will skip the Blue-Green Strategy and route the end user traffic from the current running release to the new release on a particular environment.
@@ -108,18 +109,22 @@ To perform a rollback from App Details follow the below steps:
* In case of Canary deployments, select **Rollback** under **Canary Strategy**.
- 
+ 
+
Figure 7: Selecting Rollback For Canary Deployment
* In case of Blue Green deployments, select **Rollback** under **Blue Green Strategy**.
- 
+ 
+
Figure 8: Selecting Rollback For Blue Green Deployment
3. Select the image to which you want your release to be rolled back and click **Deploy** to rollback the release.
- 
+ 
+
Figure 9: Selecting the Image
4. If you wish, you can select a different deployment strategy other than the default according to the use case.
- 
+ 
+
Figure 10: Selecting Deployment Strategy
5. The application will be rolled back to the previous release (image) using the selected deployment strategy.
\ No newline at end of file
diff --git a/docs/user-guide/app-details/ephemeral-containers.md b/docs/user-guide/app-details/ephemeral-containers.md
old mode 100644
new mode 100755
index 71a61e98fa..0fe99a04cc
--- a/docs/user-guide/app-details/ephemeral-containers.md
+++ b/docs/user-guide/app-details/ephemeral-containers.md
@@ -22,7 +22,7 @@ You can quickly create an ephemeral container directly from the **App Details**
## Create From Resource Browser
-{% embed url="https://www.youtube.com/watch?v=Ml19i29Ivc4" caption="Launching Ephemeral Containers from Resource Browser" %}
+
To create an ephemeral container from the Resource Browser, refer to [Launching Ephemeral Container](../resource-browser/pods.md#launching-ephemeral-container).
@@ -30,13 +30,12 @@ To create an ephemeral container from the Resource Browser, refer to [Launching
## Create From Cluster Terminal
-{% hint style="warning" %}
-
+:::caution
This is not a recommended method. However, if you still wish to proceed, then this option is available only if you are an [Admin](../global-configurations/authorization/user-access.md).
-{% endhint %}
+:::
-{% embed url="https://www.youtube.com/watch?v=PzB6dFRYe38" caption="Externally Created Ephemeral Container" %}
+
---
@@ -44,10 +43,9 @@ This is not a recommended method. However, if you still wish to proceed, then th
You can remove an ephemeral container from either the **App Details** page or the **Resource Browser**.
-{% hint style="info" %}
-
+:::info
If you had created an ephemeral container using the Kubernetes CLI, then you will not be able to remove the container from the **App Details** page or the **Resource Browser**.
-{% endhint %}
+:::
-{% embed url="https://www.youtube.com/watch?v=tZID0YU0YUU" caption="Deleting Ephemeral Containers" %}
\ No newline at end of file
+
\ No newline at end of file
diff --git a/docs/user-guide/app-labels.md b/docs/user-guide/app-labels.md
old mode 100644
new mode 100755
index cfe53163d7..49e93f3c6f
--- a/docs/user-guide/app-labels.md
+++ b/docs/user-guide/app-labels.md
@@ -17,6 +17,7 @@ values.
Labels are optionals and can be entered `key:values` format. multiple labels can be added without repeating `key` name.
+
Figure 1: Add New APP
### 2. Application meta info
@@ -26,16 +27,18 @@ left button next to application name `?`.
This will open show you the applications meta details like project, labels associated with it.
+
Figure 2: About
### 3. Edit Labels to existing apps
We also add or remove labels for app from here.
+
Figure 3: Edit Labels
### 3. Label Payload
* `id` : integer unique label id
* `appId` : integer application id
* `key` : string key is the part of label stored individually in db.
-* `value` : string value is the part of label stored individually in db.
+* `value` : string value is the part of label stored individually in db.
\ No newline at end of file
diff --git a/docs/user-guide/app-management/README.md b/docs/user-guide/app-management/README.md
new file mode 100755
index 0000000000..af24799524
--- /dev/null
+++ b/docs/user-guide/app-management/README.md
@@ -0,0 +1,65 @@
+---
+id: README
+title: Application Management
+sidebar_label: Application Management
+description: Learn how to create, configure, deploy, and monitor applications using Devtron.
+---
+
+The **Application Management** section helps you understand every stage of the Devtron application lifecycle, from creation and configuration to deployment, monitoring, and governance.
+
+This section provides an end-to-end guide to how Devtron manages applications, integrates CI/CD automation, and ensures consistent, policy-driven deployments across all environments.
+
+---
+
+## Table of Contents
+
+### 1. [Application Overview](./application-overview.md)
+Get a high-level understanding of how applications are structured and managed in Devtron.
+
+### 2. [Applications](../applications.md)
+Learn how to create and manage applications.
+- [Create Application](../create-application.md)
+- [Clone Application](../cloning-application.md)
+- [Use Application Templates](../using-application-templates.md)
+
+#### App Configuration
+- [Git Material](../creating-application/git-material.md)
+- [Docker Build Configuration](../creating-application/docker-build-configuration.md)
+- [Base Configurations](../creating-application/base-config/README.md)
+ - [Deployment Templates](../creating-application/base-config/deployment-template.md)
+ - [Types of Deployment Templates](../creating-application/base-config/deployment-template-types/README.md)
+ - [ConfigMaps](../creating-application/base-config/config-maps.md)
+ - [Secrets](../creating-application/base-config/secrets.md)
+ - [External Secrets (ESO)](../creating-application/base-config/eso/README.md)
+- [GitOps Config](../creating-application/gitops-config.md)
+- [Workflow Editor](../creating-application/workflow/README.md)
+- [Environment Overrides](../creating-application/environment-overrides.md)
+- [Deleting an Application](../deleting-application.md)
+
+#### Build & Deploy
+- [Trigger CI/CD Pipelines](../deploying-application/README.md)
+- [Rollback Deployment](../deploying-application/rollback-deployment.md)
+- [Image Labels & Comments](../deploying-application/image-labels-and-comments.md)
+
+#### App Details
+- [Application Summary](../app-details/application-summary.md)
+- [App Metrics](../creating-application/app-metrics.md)
+- [Deployment Visibility](../app-details/deployment-visibility.md)
+- [Ephemeral Containers](../app-details/ephemeral-containers.md)
+
+### 3. [Application Groups](../application-groups.md)
+Group related applications for unified deployment management.
+
+### 4. [Chart Store](../deploy-chart/README.md)
+Deploy and manage Helm charts.
+- [Chart Deployment](../deploy-chart/deployment-of-charts.md)
+- [Chart Groups](../deploy-chart/chart-group.md)
+
+### 5. [Bulk Updates](../bulk-update.md)
+Apply bulk configuration or template updates across applications.
+
+### 6. [Configurations](../app-configurations/README.md)
+Manage GitOps, chart repositories, notifications, and build infrastructure.
+
+### 7. [Policies](../policies/README.md)
+Define and enforce deployment windows, approvals, and plugin usage rules.
\ No newline at end of file
diff --git a/docs/user-guide/app-management/application-overview.md b/docs/user-guide/app-management/application-overview.md
new file mode 100755
index 0000000000..9842fc96ff
--- /dev/null
+++ b/docs/user-guide/app-management/application-overview.md
@@ -0,0 +1,268 @@
+import SupademoEmbed from '@site/src/components/SupademoEmbed';
+
+# Application Overview
+
+## Introduction
+
+The **Application Overview** page in Devtron gives you a complete view of your Devtron Applications. It includes information about your projects, applications, environments, and pipelines, all in a single view.
+
+It helps you understand how your applications are organized, how your workflows are performing, thus, giving you better visibility and control in a single pane of view.
+
+
+
Figure 1: Application Overview
+
+The **Application Overview** page contains the following sections:
+
+1. [At a Glance](#at-a-glance)
+2. [Workflow Overview](#workflow-overview)
+3. [Triggers & Build Time](#triggers--build-time)
+4. [Most & Least Triggered Pipelines](#most--least-triggered-pipelines)
+5. [Cost Visibility](#cost-visibility-)
+6. [Best Practices](#best-practices-)
+
+---
+
+## At a Glance
+
+The **At a Glance** section displays the total count of Projects, Devtron Applications, Helm Applications, and Environments, giving you an instant view of your overall applications in Devtron.
+
+
+
+
+| **Card** | **Description** |
+|------------------------|----------------|
+| **Projects** | Total number of projects in Devtron |
+| **Devtron Applications** | Total number of Devtron applications across all the clusters |
+| **Helm Applications** | Total number of Helm applications across all the clusters|
+| **Environments** | Total number of Environments in Devtron across all the clusters|
+
+---
+
+## Workflow Overview
+
+The **Workflow Overview** section displays how your CI/CD workflows are functioning in Devtron. It displays important metrics such as the number of build and deployment pipelines, external image sources, and production pipelines. It also shows how many pipelines follow GitOps best practices and have image scanning enabled.
+
+
+
+| **Card** | **Description** |
+|-----------|-----------------|
+| **Build Pipelines** | Shows the total number of build pipelines configured in your Devtron |
+| **Deployment Pipelines** | Shows the total number of deployment pipelines across all applications|
+| **External Image Sources** | Shows the total number of build pipelines which uses external image source |
+| **Scanning Enabled in Workflows** | Shows the percentage of workflows that have scanning enabled for images |
+| **GitOps Compliance (Prod Pipelines)** | Shows how many production pipelines are configured using GitOps for configuration consistency|
+| **Production Pipelines** | Shows the total number of production pipelines defined within your Devtron|
+
+### Build & Deployment Metrics
+
+The **Build & Deployment Metrics** section helps you assess how efficiently your teams deliver software using Devtron pipelines. It uses the industry standard DORA metrics to measure delivery performance and reliability across production deployment pipelines.
+
+
+
+
+You can track four key metrics over a selected time range (for example, the last 30 days).
+
+| **Metric** | **Description** |
+|-------------|-----------------|
+| **Deployment Frequency** |Shows how often your deployment pipelines push new releases to production |
+| **Mean Lead Time** | Shows the average time it takes for a code change to move from commit to production. It helps you understand how quickly your team can deliver new features or fixes|
+| **Change Failure Rate** | Indicates the percentage of deployments that result in a failure or rollback. It helps you measure release stability and identify where improvements can reduce disruptions|
+| **Mean Time to Recovery (MTTR)** | Measures how long it takes to recover from a failed deployment. It helps you assess how effectively your team can respond to and fix issues when they occur|
+| **Pipelines Count by Performance** | Categorizes pipelines into **Elite**, **High**, **Medium**, and **Low** performance based on DORA metrics. Helps identify which pipelines are performing well and which may need improvement |
+
+Each DORA metric in Devtron uses color-coded categories to represent pipeline performance levels. These colors help you quickly interpret how your production deployment pipelines are performing, from **Elite** (best-performing) to **Low** (needs attention).
+
+The meaning for each color vary slightly across different metrics, reflecting how delivery speed, stability, and recovery time are measured in real-world DevOps performance. The table below summarizes what each color means for every DORA metric in Devtron.
+
+| **Metric** | **Color** | **Category** | **Description** | **Range / Criteria** |
+|-------------|------------|---------------|------------------|-----------------------|
+| **Deployment Frequency** | 🟪 **Elite** | Top performing pipelines | Deployed more than once per day | > 1 per day |
+| | 🟩 **High** | High-performing pipelines | Deployed between once per day and once per week | 1 per day – 1 per week |
+| | 🟨 **Medium** | Moderately active pipelines | Deployed between once per week and once per month | 1 per week – 1 per month |
+| | 🟥 **Low** | Infrequently deployed pipelines | Deployed between once per month and once per 6 months | 1 per month – 1 per 6 months |
+| **Mean Lead Time** | 🟪 **Elite** | Top performing pipelines | Mean lead time is less than 1 day | < 1 day |
+| | 🟩 **High** | High-performing pipelines | Mean lead time is between 1 day and 1 week | 1 day - 1 week |
+| | 🟨 **Medium** | Moderately efficient pipelines | Mean lead time is between 1 week and 1 month | 1 week - 1 month |
+| | 🟥 **Low** | Slow pipelines | Mean lead time is between 1 day and 6 months | 1 day - 6 months |
+| **Change Failure Rate** | 🟪 **Elite** | Top performing pipelines | Change failure rate is between 0-15% | 0-15% |
+| | 🟩 **High** | High-performing pipelines | Change failure rate is between 16-30% | 16-30% |
+| | 🟨 **Medium** | Moderately stable pipelines | Change failure rate is between 31–45% | 31–45% |
+| | 🟥 **Low** | Unstable pipelines | Change failure rate is between 46–60% | 46–60% |
+| **Mean Time to Recovery (MTTR)** | 🟪 **Elite** | Top performing pipelines | Mean time to recovery is less than 1 hour | < 1 hour |
+| | 🟩 **High** | High-performing pipelines | Mean time to recovery is between 1 hour and 1 day | 1 hour – 1 day |
+| | 🟨 **Medium** | Moderately resilient pipelines | Mean time to recovery is between 1 day and 1 week | 1 day – 1 week |
+| | 🟥 **Low** | Slow recovery pipelines | Mean time to recovery is more than 1 week | > 1 week |
+
+:::tip Use Case
+
+Suppose your DevOps team is reviewing delivery performance for the last month. You notice that while Deployment Frequency has increased, the Mean Lead Time has also gone up. This suggests that more deployments are happening, but each one is taking longer to reach production. By comparing the Change Failure Rate and Mean Time to Recovery, your team can identify whether the delay is due to testing, approvals, or rollback handling. With these insights, you can fine-tune your workflow or automation to achieve faster and more reliable releases.
+
+:::
+
+---
+
+## Triggers & Build Time
+
+The **Triggers & Build Time** section provides a detailed view of your build and deployment activities in Devtron. It helps you understand how frequently builds and deployments are triggered, how long they take, and how successful they are over time.
+
+
+
+
+At the top, you will see three key indicators:
+
+| **Field** | **Description** |
+|------------|----------------|
+| **Total Build Triggers** | The total number of builds triggered across all pipelines within the selected time period. |
+| **Average Build Time** | The average time taken for a build to complete successfully. |
+| **Total Deployment Triggers** | The total number of deployments triggered during the selected time period. |
+
+Below each indicator, you will also find a corresponding graph that visualizes its trend over selected period of time. You can adjust the **Time Range** in the top-right corner of the graph to analyze workflow trends over different periods.
+
+| Option | Description |
+|:----------------|:-------------|
+| **Today** | Shows build and deployment activity for the current day |
+| **This Week** | Displays data from the current week (Monday-Sunday) |
+| **Last Week** | Displays data from the previous week for comparison |
+| **This Month** | Aggregates data for the ongoing month |
+| **Last Month** | Shows activity from the previous month to help you analyze changes month-over-month|
+| **This Quarter**| Groups workflow data by the current quarter (**April-June**, **July-September**, **October-December**, or **Jan-March**) |
+
+### Build Triggers Graph
+
+This graph displays how build triggers change over time.
+* **Blue line** - Total build triggers
+* **Green line** - Successful builds
+* **Red line** - Failed builds
+
+Hover over any point on the graph to view daily build statistics, including total, successful, and failed builds. This helps you identify trends in build frequency and stability.
+
+### Deployment Triggers Graph
+
+This graph tracks how often deployments are triggered and how many of them succeed or fail.
+
+* **Blue line** - Total deployments triggered
+* **Green line** - Successful deployments
+* **Red line** - Failed deployments
+
+Hover over a specific date to see deployment counts and outcomes, helping you understand deployment frequency and reliability trends.
+
+
+### Average Build Time Graph
+
+This graph shows how the average build duration varies during the selected time range.
+
+* The **blue line** represents the average build time per day (in minutes).
+* The **dotted line** shows the overall average for the selected period.
+
+It helps you identify days when build duration increased significantly, signaling potential issues like resource bottlenecks or slower build steps.
+
+:::success Use Case
+Suppose your team wants to analyze why release cycles slowed down this month.
+You open the **Triggers & Build Time** section and notice that build triggers spiked on October 10, with several failed builds. Deployment triggers show a similar peak on October 8, where 73 deployments ran, and 18 failed. Meanwhile, the Average Build Time graph shows a sudden rise on October 3, where builds took three times longer than usual.
+
+With these insights, your team can connect the dots between build failures, longer build durations, and delayed deployments, helping you take timely corrective action to keep releases smooth and predictable.
+
+:::
+
+---
+
+## Most & Least Triggered Pipelines
+
+This section shows the build and deployment pipelines that were triggered the most and the least within the selected time range.
+It helps you identify which pipelines are most active and where fewer executions might indicate inactive or underused workflows.
+
+
+
+
+The section provides two tabs, **Build Pipelines** and **Deployment Pipelines**, each displaying a bar chart that ranks pipelines based on how frequently they were triggered during the selected time range.
+
+| **Tab** | **Description** |
+|:---------|:----------------|
+| **Build Pipelines** | Displays the most and least triggered build pipelines based on their total build trigger count. Each bar represents a single pipeline, and its length indicates how often the pipeline was triggered. |
+| **Deployment Pipelines** | Displays the most and least triggered deployment pipelines based on their total deployment trigger count. Each bar represents a single deployment pipeline, and its length indicates the number of deployment triggers during the selected time range. |
+
+### Sorting and Filters
+
+| **Control** | **Description** |
+|:--------------|:----------------|
+| **Time Range** | Allows you to choose a time range such as **Today**, **This Week**, **This Month**, **Last Month**, or **This Quarter** to analyze pipeline activity during that period. |
+| **Sorting Order** | Lets you sort the list **High to Low** or **Low to High** based on trigger count, helping you focus on the busiest or least used pipelines. |
+
+---
+
+## Cost Visibility
+
+:::info
+This section provides a quick overview of cost insights within the **Application Overview** dashboard.
+For a more detailed breakdown of cost and usage across clusters, see the full [Cost Visibility](../finops/README.md)
+:::
+
+The **Cost Visibility** section provides a comparison of costs across your applications and build pipelines within Devtron.
+
+
+
Figure 2: Cost Visibility
+
+It shows:
+
+ * **Top 10 Costly Applications** - It shows which deployed applications consume the most resources (such as CPU, memory, or storage) across your clusters.
+
+ * **Top 10 Costly Build Pipelines** - It shows the list of build pipelines that have the highest cost during image builds.
+
+You can use the time range filter (Last 24 Hours, Last 7 Days, Last 30 Days, or Last 90 Days) to select the preferred time range.
+
+:::warning Note
+If a cluster does not have cost tracking enabled, its data will not appear in this section.
+Enable the **Cost Visibility** module for those clusters to view accurate cost insights. Refer [Cost Visibility Configurations](../finops/configurations.md) to learn more.
+
+:::
+
+---
+
+## Best Practices
+
+The **Best Practices** section helps shows you the percentage of production pipelines for which you have enabled approval policies. It gives you a quick view of how many pipelines have checks in place before important configuration changes or deployments go live.
+
+
+
Figure 3: Best Practices
+
+These insights help you ensure that the right governance controls are followed, reducing risks from unreviewed or accidental changes.
+
+| **Field** | **Description** |
+|:-----------|:----------------|
+| **Config Change Approval** | Indicates the percentage of pipelines that require approval before applying configuration changes|
+| **Deployment Approval** | Indicates the percentage of pipelines that require approval before executing a deployment |
+
+## FAQs
+
+
+1. Why do the count of Devtron and Helm applications differs from what I see in my dashboards?
+
+The count displayed in the application overview reflects **all connected clusters** which are reachable. If some applications are missing, verify that the clusters where they are deployed are reachable.
+
+Disconnected clusters or standalone Helm releases won’t appear until Devtron syncs them.
+
+If still you cannot see your applications, contact [Devtron Support](mailto:enterprise@devtron.ai) for assistant.
+
+
+
+2. Why do my triggers or build time graphs look empty?
+
+Graphs may appear blank if:
+* No builds or deployments were triggered during the selected **Time Range**
+* Pipelines were recently created and have no activity yet
+Try expanding the time filter (for example, from **This Week** to **Last 30 Days**) or verifying pipeline execution history.
+
+
+
+3. Why do I see cost data for some applications but not others?
+
+Cost data appears only for applications deployed in clusters where **Cost Visibility** is enabled.
+If a cluster doesn’t have cost visibility enabled, its data won’t appear.
+You can enable it under **Cost Visibility** → **Configurations** to start tracking cost for those applications. Refer [Configurations](../finops/configurations.md) to learn more.
+
+
+
+4. How frequently are these metrics updated?
+
+Metrics on the **Application Overview** page are refreshed automatically every hour.
+
\ No newline at end of file
diff --git a/docs/user-guide/application-groups.md b/docs/user-guide/application-groups.md
old mode 100644
new mode 100755
index 273cbae13f..b709e336c2
--- a/docs/user-guide/application-groups.md
+++ b/docs/user-guide/application-groups.md
@@ -4,37 +4,34 @@
Application groups in Devtron streamline the deployment of microservices by enabling you to build and deploy multiple applications simultaneously. This feature is particularly beneficial when your microservices are interdependent, as a change in one service often triggers the need to redeploy others.
-{% hint style="info" %}
-
-### Note
-
+:::info Note
Only one application group would exist for each [environment](../reference/glossary.md#environment). You cannot group applications belonging to different environments.
-{% endhint %}
+:::
---
## Accessing Application Groups
-{% hint style="info" %}
-
-### Who Can Perform This Action?
-
+:::info Who Can Perform This Action?
Users need to have [View only permission](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to view all the applications within a group.
-{% endhint %}
+:::
1. From the left sidebar, go to **Application Groups**
- 
+ 
+
Figure 1: Application Group (Beta)
2. You will see a list of environments. Select the environment to view the application group.
- 
+ 
+
Figure 2: List of Environments
3. The application group would contain the applications meant for deployment in the chosen environment.
- 
+ 
+
Figure 3: Sample Application Group
As you can see, it has similar options as available under [Applications](./applications.md):
* Overview
@@ -51,67 +48,68 @@ First, we will walk you through the [key features](#key-features) of Application
### Building Application Images
-{% hint style="info" %}
-
-### Who Can Perform This Action?
-
+:::info Who Can Perform This Action?
Users need to have [Build and deploy permission](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to trigger the build.
-{% endhint %}
+:::
The **Build & Deploy** tab of your application group enables you to trigger the [CI builds](../reference/glossary.md#image) of one or more applications in bulk.
1. Select the applications using the checkboxes and click the **Build Image** button present at the bottom.
- 
+ 
+
Figure 4: Build Option
2. The `Build image` screen opens. Select the application and the [commit](../reference/glossary.md#commit-hash) for which you want to trigger the CI build.
- 
+ 
+
Figure 5: Selecting Commit
-{% hint style="info" %}
-### Tip
+:::info Tip
Adding [image labels](./deploying-application/image-labels-and-comments.md) can help you quickly locate the container image from the list of images shown in Application Groups.
-{% endhint %}
+:::
+
+3. Similar to application, you can also [pass build parameters](./deploying-application/triggering-ci.md#passing-build-parameters-) in application groups before triggering the build.
-3. Similar to application, you can also [pass build parameters](./deploying-application/triggering-ci.md#passing-build-parameters) in application groups before triggering the build.
+:::info Note
+Passing build parameters feature is only available in
-{% hint style="info" %}
-### Note
-Passing build parameters feature is only available in
-{% endhint %}
+:::
* Go to the **Parameters** tab.
- 
+ 
+
* Enter your key-value pair as shown below.
- 
+ 
+
Figure 8: Entering Key-Value Pair
* You may follow the above steps for other applications too, and then click **Start Build**.
- 
+ 
+
Figure 10: Passing Build Parameters and Triggering Build
4. The builds will initiate, following which, you can close the `Build image` screen.
- 
+ 
+
Figure 11: Triggered Deployment
### Changing Configurations
-{% hint style="info" %}
-
-### Who Can Perform This Action?
-
+:::info Who Can Perform This Action?
Users need to have [Admin role](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to change their configuration. Please note, you might not be able to change the values of locked keys in deployment template. Refer [Lock Deployment Configuration](./global-configurations/lock-deployment-config.md) to know more.
-{% endhint %}
+:::
The **Configurations** tab of your application group allows you to configure the following:
@@ -121,23 +119,22 @@ The **Configurations** tab of your application group allows you to configure the
As shown below, you can handle the configurations of more than one application from a single screen.
-
+
+
Figure 12: Configurations of each App
### Deploying Applications
-{% hint style="info" %}
-
-### Who Can Perform This Action?
-
+:::info Who Can Perform This Action?
Users need to have [Build and deploy permission](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to initiate the deployment.
-{% endhint %}
+:::
The **Build & Deploy** tab of your application group helps you deploy one or more applications in bulk.
1. Select the applications using the checkboxes.
- 
+ 
+
Figure 13: Deploy Option
2. You can also trigger Pre-deployment stage or Post-deployment stage for your applications in bulk.
@@ -145,52 +142,56 @@ The **Build & Deploy** tab of your application group helps you deploy one or mor
* To trigger Post-deployment stage, click the droupup next to **Deploy** and select **Trigger Post-deployment stage**.
- 
+ 
+
Figure 14: Triggering Pre/Post Stages
-{% hint style="info" %}
-### Note
+:::info Note
* The dropup appears only if your workflow has Pre-deployment stage or Post-deployment stage configured for the selected environment.
* If both stages are configured, the dropup will display options for triggering **Pre-deployment** and **Post-deployment** stages.
* If only one stage is configured, the dropup will show the option for triggering that specific stage.
-{% endhint %}
+:::
3. After selecting the applications, click the **Deploy** button present at the bottom.
- 
+ 
+
Figure 15: Clicking 'Deploy'
4. Select the desired container image that you want to deploy for respective application.
- 
+ 
+
Figure 16: Selecting Image
Repeat the step for other applications too.
- 
+ 
+
Figure 17: Deploying Apps
-5. If you wish, you can deploy all applications in an Application Group using a single deployment strategy, select the preferred deployment strategy for all the applications and click **Deploy**.
By default, all applications will be deployed using their respective default strategies.
+5. If you wish, you can deploy all applications in an Application Group using a single deployment strategy, select the preferred deployment strategy for all the applications and click **Deploy**.
By default, all applications will be deployed using their respective default strategies.
- 
+ 
+
Figure 18: Selecting Deployment Strategy
- * **Deployment feasibility** page will open, in case for any application, the selected deployment strategy is not configured, you can select one of the configured strategies for that application.
If you do not select a configured deployment strategy, deployment will be skipped for that particular application.
+ * **Deployment feasibility** page will open, in case for any application, the selected deployment strategy is not configured, you can select one of the configured strategies for that application.
If you do not select a configured deployment strategy, deployment will be skipped for that particular application.
- 
+ 
+
Figure 19: Deployment Feasibility
6. The deployment will be initiated, following which, you can close the screen as shown below.
- 
+ 
+
Figure 20: Triggered Deployment
7. Once the deployment is successful, the pipelines will show `Succeeded`.
- 
-
-{% hint style="info" %}
-
-### Note
+ 
+
Figure 21: Successful Deployment
+:::info Note
You can go to the **App Details** tab to have a bird's-eye view of your application, view application metrics, and even perform quick actions (e.g., restarting workloads). Refer to [App Details](../user-guide/app-details/README.md) for more information.
-{% endhint %}
+:::
-### Managing Traffic 
+### Managing Traffic
While deployment, Devtron allows you to manage your **Canary** and **Blue-Green** deployments by providing visibility and easy controls to manage how new versions (releases) are shared with users.
@@ -198,7 +199,8 @@ To do so, follow the below steps:
1. Go to **Overview** and click **Manage Traffic**.
- 
+ 
+
Figure 22: Selecting Managing Traffic
2. Select the required applications, a side window will appear displaying all the eligible rollouts.
@@ -206,37 +208,39 @@ To do so, follow the below steps:
* For **Canary Deployments**, you can either choose to initiate the next step or to initiate the full rollout.
- 
+ 
+
Figure 23: Selecting Action for Canary Deployments
* For **Blue Green deployments**, you can either choose to **Swap Traffic**, or you can choose Skip & Promote Full.
* **Swap Traffic**: This will swap the traffic from the current deployment to the application latest deployment.
- 
+ 
+
Figure 24: Selecting 'Swap Traffic'
* **Skip & Promote Full**: While deploying, this will directly deploy the whole traffic to application latest deployment.
- 
+ 
+
Figure 25: Selecting 'Skip & Promote Full'
4. Click **Initiate Eligible Rollouts** to implement the actions.
- 
+ 
+
---
## Additional Features
-### Clone Pipelines [](https://devtron.ai/pricing)
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
+### Clone Pipelines
+:::caution Who Can Perform This Action?
Only a [Super-Admin](../user-guide/global-configurations/authorization/user-access.md#grant-super-admin-permission) can clone pipelines.
-{% endhint %}
+:::
This feature aims at helping the user clone existing CI/CD pipelines for new target environments in multiple applications. The configurations present in the given CI/CD pipeline also get copied to the cloned pipelines (refer the below table).
@@ -244,11 +248,11 @@ This feature aims at helping the user clone existing CI/CD pipelines for new tar
|----------------------------------|--------------------------------------------------------------|
| [**CI Workflow**](../user-guide/creating-application/workflow/ci-pipeline.md) | Clones the source’s workflow CI as it is |
| [**Pipeline Configuration**](../user-guide/creating-application/workflow/pre-post-tasks.md) | Cloned, including Pre-CD and Post-CD scripts/plugins |
-| [**Environment Configuration**](../user-guide/creating-application/README.md#app-configuration) | Cloned, including Deployment Template (DT), ConfigMap (CM), and Secret |
+| [**Environment Configuration**](../user-guide/creating-application/environment-overrides.md) | Cloned, including Deployment Template (DT), ConfigMap (CM), and Secret |
| [**GitOps Configuration**](../user-guide/creating-application/gitops-config.md) | Not cloned |
| [**Environment Policies**](../user-guide/creating-application/environment-overrides.md) | Cloned if at pipeline level,ignored if global |
| [**CD Filter**](../user-guide/global-configurations/filter-condition.md) | Not cloned (handled globally) |
-| [**Protect Configurations**](../user-guide/creating-application/config-approval.md) | Cloned (handled at pipeline level) |
+| [**Protect Configurations**](../user-guide/global-configurations/approval-policy.md) | Cloned (handled at pipeline level) |
| [**Deployment Approvals**](../user-guide/global-configurations/approval-policy.md) | Not cloned (handled globally) |
| [**Lock Configurations**](../user-guide/global-configurations/lock-deployment-config.md) | Not cloned |
| [**Mandatory Plugin**](../user-guide/global-configurations/plugin-policy.md) | Not cloned |
@@ -267,17 +271,20 @@ This feature gives you two methods of cloning:
1. **New Workflow**: Creates a new workflow and clones the source CI and CD pipeline. Gives you the flexibility to tweak the cloned CI (e.g., changing code branch for build) too.
- 
+ 
+
Figure 27: New Workflow
2. **Source Workflow**: Uses the same workflow and clones only the source CD pipeline, thus keeping the original CI pipeline unchanged.
- 
+ 
+
Figure 28: Source Workflow
#### Steps to Clone Pipelines
1. Go to **Application Groups** and click the source environment from the list.
- 
+ 
+
Figure 29: Source Environment Selection
2. Select the applications whose pipelines you wish to clone.
@@ -285,38 +292,36 @@ This feature gives you two methods of cloning:
* Alternatively, you may access **Clone Pipeline Config** from the `⋮` menu next to the application name.
- 
+ 
+
Figure 30: Choosing Applications
4. From the dropdown, select the target environment for which pipelines should be created for selected applications.
- 
+ 
+
Figure 31: Selecting Target Environment
5. Select the workflow where you wish to create deployment pipeline: **New Workflow** or **Workflow as source environment**. Refer [Methods of Cloning](#methods-of-cloning) to know which option will fulfill your requirement.
- 
+ 
+
Figure 32: Creating CD Pipeline in Workflow
6. Click **Clone in new workflow** or **Clone in source workflow** (depending on the option you selected in the previous step).
- 
-
-{% hint style="warning" %}
-
-### Note
+ 
+
Figure 33: Initiating Clone
+:::caution Note
The cloning process will skip if a CD pipeline (for the target environment) already exists in the chosen application's workflow. You can view this in the clone status generated after the above process.
-{% endhint %}
+:::
### Hibernating and Unhibernating Apps
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
+:::caution Who Can Perform This Action?
Users need to have [Build & deploy permission](./global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and application) to hibernate or unhibernate applications.
-{% endhint %}
+:::
Since every application comes with an option to hibernate, the same is true for application groups. Using application group, you can hibernate one or more applications belonging to the same environment if you do not want them to consume resources (replica count will be set to 0).
@@ -330,23 +335,25 @@ In other words, you can hibernate running applications or unhibernate hibernated
* Alternatively, you may access **Hibernate** from the `⋮` menu next to the application name.
- 
+ 
+
Figure 34: Selecting Apps to Hibernate
3. Confirm the hibernation by clicking **Hibernate**.
- 
+ 
+
Figure 35: Confirming Hibernation
4. Hibernation will initiate as shown below. You may close the window.
- 
+ 
+
Figure 36: Initiation Status of Hibernation
Your applications pods would be scaled down and would stop incurring costs.
-{% hint style="warning" %}
-### Note
+:::caution Note
* The hibernation process will show the status as `Skipped` for the applications which are already hibernated.
* The hibernation process will show the status as `Failed` for the applications which have no deployment history.
-{% endhint %}
+:::
#### Unhibernation Process
@@ -356,33 +363,32 @@ Your applications pods would be scaled down and would stop incurring costs.
* Alternatively, you may access **Unhibernate** from the `⋮` menu next to the application name.
- 
+ 
+
Figure 37: Selecting Hibernated Apps to Unhibernate
3. Confirm the unhibernation by clicking **Unhibernate**.
- 
+ 
+
Figure 38: Confirming Unhibernation
4. Unhibernation will initiate as shown below. You may close the window.
- 
+ 
+
Figure 39: Initiation Status of Unhibernation
Your applications would be up and running in some time.
-{% hint style="warning" %}
-### Note
+:::caution Note
* The unhibernation process will show the status as `Skipped` for the applications which are already running.
* The unhibernation process will show the status as `Failed` for the applications which have no deployment history.
-{% endhint %}
+:::
### Restart Workloads
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
+:::caution Who Can Perform This Action?
Users need to have [Build & deploy permission](./global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and application) to restart workloads in bulk.
-{% endhint %}
+:::
Restarting workloads might be necessary if you want your new code or configuration to come into effect, or you are experiencing issues like crashing of pods.
@@ -394,19 +400,26 @@ Using application group, you can select the workloads (i.e., Pod, Deployment, Re
* Alternatively, you may access **Restart Workload** from the `⋮` menu next to the application name.
- 
+ 
+
Figure 40: Selecting Apps to Restart
3. Next to the application, click the workload dropdown to view all the individual workloads of an application. Choose only the ones you wish to restart.
- 
+ 
+
Figure 41: Choosing Workloads
Moreover, you can easily select, deselect, or choose multiple workloads as shown below.
- 
+ 
+
Restarting workloads might take time depending on the number of applications.
@@ -416,32 +429,39 @@ Assume you have multiple applications (maybe 10, 50, 100, or more) showing up in
1. Click the filter next to the application group as shown below.
- 
+ 
+
Figure 44: Filter Option
2. The filter will show all the applications present in the group. Click to select the relevant ones.
- 
+ 
+
Figure 45: All Apps
3. The filter narrows down the list of applications as shown below.
- 
+ 
+
Figure 46: Filtered Apps
+
+ :::info Persistent selection
+ Your filter selection is remembered for each application group. When you reopen the group, Devtron automatically reapplies the applications you had filtered, so you don't have to reselect them every time.
+ :::
-4. (Optional) If required, you can save the filter for future use by clicking **Save selection as filter**.
+4. (Optional) If required, you can save the filter for future use as a named selection by clicking **Save selection as filter**. A saved filter lets you select or deselect an entire group of applications in one click whenever you need it.
- 
+ 
+
Figure 47: Saving a Filter
5. Add a name and description to the filter to help you know its purpose, and click **Save**.
- 
+ 
+
Figure 48: Naming a Filter
Now when you access the application group, your saved filter will be visible on top.
-
-
-{% hint style="info" %}
-
-### Permissions
+
+
Figure 49: Saved Filter
+:::info Permissions
#### 1. Creating a filter
Users can create a filter if they have Admin/Manager access on all selected applications.
@@ -466,40 +486,39 @@ Users can edit a saved filter if they have Admin/Manager access on all applicati
Users can delete a saved filter if they have Admin/Manager access on all applications in the saved filter.
-{% endhint %}
+:::
### Changing Branch
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
+:::caution Who Can Perform This Action?
Users need to have [Admin role](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to update their branch.
-{% endhint %}
+:::
Assume you have a few applications whose [build pipelines](../reference/glossary.md#build-pipeline) fetch from the `main` branch of your code repository. However, you decided to maintain a `master` branch, and you want all the upcoming CI builds to consider the `master` branch as the source. Devtron provides you the option to change the branch at both levels, individual application as well as application group.
1. In the **Build & Deploy** tab of your application group, select the intended applications and click the **Change Branch** button present at the bottom.
- 
+ 
+
Figure 50: Changing Branch
2. Enter the new branch name. If your build pipeline has `Branch Regex` as the Source Type, you must ensure your new branch name matches the regex (regular expression) provided in that build pipeline. Once done, click **Update Branch**.
- 
+ 
+
Figure 51: Updating Branch Name
### Changing Image Source
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have [Admin role](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to update their branch.
-{% endhint %}
+:::
The **Change Image Source** feature in Devtron lets you update the container image source for an application’s workflow without modifying it.
1. In the **Build & Deploy** tab of your application group, select the preferred workflows and click the **Change Image Source** button present at the bottom.
- 
+ 
+
Figure 52: Clicking 'Change Image Source'
2. Select the preferred Workflow template, and enter the required details as per the workflow template. Currently, **Change Image Source** feature for **Application Groups** is only supported for **Build from Source Code** and **Sync with Environment**.
@@ -512,26 +531,32 @@ The **Change Image Source** feature in Devtron lets you update the container ima
* `No cd pipeline found for the selected app and env combination`
* `Invalid request, trying to create self loop, cannot create sync-cd source pipeline with source environment in same workflow`
- 
+ 
+
* A pop-up window will open, enter the **Source Type** and **Branch** under **Select code source**.
- 
+ 
+
Figure 54: Entering Required Details
* Click **Create Pipeline**. A modal window will appear showing the status of the image source change.
- 
+ 
+
Figure 55: Clicking 'Create Pipeline'
2. **Sync with Environment**
* After selecting **Sync with Environment**, a modal window will open.
- 
+ 
+
Figure 56: Selecting Sync With Environment
* Select the environment from which you want to sync your workflow, and then click **Next**.
- 
+ 
+
Figure 57: Selecting Environment
* A feasibility check will run. You can click **Change Image Source** only if the application's feasibility is marked as `Can change`.
@@ -541,11 +566,12 @@ The **Change Image Source** feature in Devtron lets you update the container ima
* `No cd pipeline found for the selected app and env combination`
* `Invalid request, trying to create self loop, cannot create sync-cd source pipeline with source environment in same workflow`
- 
+ 
+
Figure 58: Feasibility Window
* Click **Change Image Source**. A modal window will appear showing the operation status.
- 
+ 
+
Figure 59: Clicking 'Change Image Source'
-3. The image source is applied to all selected workflows where the feasibility check passed.
-
\ No newline at end of file
+3. The image source is applied to all selected workflows where the feasibility check passed.
\ No newline at end of file
diff --git a/docs/user-guide/applications.md b/docs/user-guide/applications.md
old mode 100644
new mode 100755
index b7bf760127..8b94e67388
--- a/docs/user-guide/applications.md
+++ b/docs/user-guide/applications.md
@@ -1,8 +1,13 @@
+---
+id: applications
+title: Applications
+---
+
# Applications
-{% hint style="warning" %}
+
## Introduction
@@ -14,9 +19,10 @@ The **Applications** page helps you create and manage your microservices, and it
### Application Listing
-You can view the app name, its status, environment, namespace, and many more upfront. The apps are segregated into: [Devtron Apps](../reference/glossary.md#devtron-apps), [Helm Apps](../reference/glossary.md#helm-apps), [ArgoCD Apps](../reference/glossary.md#argocd-apps), and [FluxCD Apps](../reference/glossary.md#fluxcd-apps).
+You can view the app name, its status, environment, namespace, and many more upfront.
-
+
+
Figure 1: App Types
### Create Button
@@ -28,146 +34,24 @@ You can use this to:
### Other Options
There are additional options available for you:
-* **Search and filters** to make it easier for you to find applications.
+* **Search and filters** to make it easier for you to find applications. Refer to [Searching and Filtering](#searching-and-filtering) for more information.
* **Export CSV** to download the data of Devtron apps (not supported for Helm apps and Argo CD apps).
* **Sync button** to refresh the app listing.
----
-
-## View External Helm App Listing
-
-{% hint style="tip" %}
-### Want to Manage your Existing Helm Release using Devtron?
-Apart from internal helm apps created in Devtron, you can also view your external Helm app listing. Moreover, you can manage their deployments using Devtron. Read [Migrate Helm Release to Devtron](../user-guide/creating-application/workflow/cd-pipeline.md#migrate-helm-release) to know more.
-{% endhint %}
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users with view only permission or above for an application can view helm app listing.
-{% endhint %}
-
-External Helm apps are Helm applications deployed outside of Devtron.
-
-1. Connect the cluster containing your external Helm apps in [Global Configurations → Cluster & Environments](./global-configurations/cluster-and-environments.md).
-
-2. Use the **Cluster** selection dropdown to choose the external cluster(s). You will see your external Helm apps under the **Helm Apps** tab.
-
- 
-
----
-
-
-## View External ArgoCD App Listing
-
-{% hint style="tip" %}
-### Want to Manage your Existing Argo CD Apps using Devtron?
-You can not only view your ArgoCD app list, but also manage their deployments using Devtron. Read [Migrate ArgoCD Apps to Devtron](../user-guide/creating-application/workflow/cd-pipeline.md#migrate-argo-cd-application) to know more.
-{% endhint %}
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users need super-admin permission to view/enable/disable the ArgoCD listing.
-{% endhint %}
-
-### Preface
-
-In Argo CD, a user manages one dashboard for one ArgoCD instance. Therefore, with multiple ArgoCD instances, the process becomes cumbersome for the user to manage several dashboards.
-
-With Devtron, you get an entire Argo CD app listing in one place. This listing includes:
-* Apps deployed using [GitOps](../reference/glossary.md#gitops) on Devtron
-* Other Argo CD apps present in your cluster
-
-
-
-### Advantages
-
-Devtron also bridges the gap for ArgoCD users by providing additional features as follows:
-
-* **Resource Scanning**: You can scan for vulnerabilities using Devtron's [resource scanning](../user-guide/security-features.md#from-app-details) feature. [](https://devtron.ai/pricing)
-
-* **Single-pane View**: All Argo CD apps will show details such as their app status, environment, cluster, and namespace together in one dashboard.
-
-* **Feature-rich Options**: Clicking an Argo CD app will give you access to its logs, terminal, events, manifest, available resource kinds, pod restart log, and many more.
-
-{% hint style="info" %}
-### Additional References
-[ArgoCD: Standalone Configuration vs Devtron Configuration](https://devtron.ai/blog/argocd-standalone-configuration-vs-devtron-configuration/#argocd-installation-and-configuration)
-{% endhint %}
-
-### Prerequisite
-The cluster in which Argo CD apps exist should be added in **Global Configurations** → **Clusters and Environments**
-
-### Feature Flag
-
-> **`ENABLE_EXTERNAL_ARGO_CD: "true"`**
-
-### Enabling ArgoCD App Listing
-
-{% embed url="https://www.youtube.com/watch?v=4KyYnsAEpqo" caption="Enabling External ArgoCD Listing" %}
-
-1. Go to the **Resource Browser** of Devtron.
-
-2. Select the cluster (in which your Argo CD app exists).
-
-3. Type `ConfigMap` in the 'Jump to Kind' field.
-
-4. Search for `dashboard-cm` using the available search bar and click it.
-
-5. Click **Edit Live Manifest**.
-
-6. Set the feature flag **ENABLE_EXTERNAL_ARGO_CD** to **"true"**
-
-7. Click **Apply Changes**.
-
-8. Go back to the 'Jump to Kind' field and type `Pod`.
-
-9. Search for `dashboard` pod and use the kebab menu (3 vertical dots) to delete the pod.
-
-10. Go to **Applications** and refresh the page. A new tab named **ArgoCD Apps** will be visible.
-
-11. Select the cluster(s) from the dropdown to view the Argo CD apps available in the chosen cluster(s).
-
- 
-
----
-
-## View External FluxCD App Listing
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users need super-admin permission to view/enable/disable the FluxCD listing.
-{% endhint %}
-
-### Preface
-
-Flux CD doesn't have any official dashboard; however, Devtron supports the listing of your [Flux CD](https://fluxcd.io/) apps in one dashboard. Here, the [advantages](#advantages) are same as those of [ArgoCD app listing](#view-external-argocd-app-listing).
-
-
-
-### Prerequisite
-The cluster in which Flux CD apps exist should be added in **Global Configurations** → **Clusters and Environments**
-
-### Feature Flag
-
-> **`FEATURE_EXTERNAL_FLUX_CD_ENABLE: "true"`**
-
-### Enabling FluxCD App Listing
-
-{% hint style="info" %}
-### Tip
-You may refer the steps mentioned in the [Enabling ArgoCD App Listing](#enabling-argocd-app-listing) section since the procedure is similar.
-{% endhint %}
-
-Using Devtron's Resource Browser, add the [feature flag](#feature-flag-1) in the Dashboard ConfigMap as shown below.
+### Searching and Filtering
-
+To help you quickly find the applications you need, the **Applications** page provides a search bar along with a set of filters (such as app status, project, environment, cluster, and namespace).
-After successfully executing all the steps, a new tab named **FluxCD Apps** will be visible. Select the cluster(s) from the dropdown to view the Flux CD apps available in the chosen cluster(s).
+Click **Filters** to open the filter dropdown and select the values you want to filter by. The application list updates to show only the applications matching your selection.
-
+:::tip Keyboard shortcut
+Press the `f` key anywhere on the **Applications** page to open the filter dropdown without using your mouse.
+:::
-(Optional) Once you choose cluster(s), you may use the **Template Type** dropdown to further filter your Flux CD app listing based on its type, i.e., [Kustomization](https://fluxcd.io/flux/components/kustomize/kustomizations/) or [Helmrelease](https://fluxcd.io/flux/components/helm/helmreleases/).
+#### Persistent Filters
-Click any Flux CD app to view its details as shown below.
+Devtron remembers the filters you apply on the **Applications** page. The next time you return to the page — even after refreshing the page or signing in again in a new session — your previously applied filters are automatically reapplied, so you can pick up right where you left off.
-
\ No newline at end of file
+:::info Note
+Filtering by application **tags** is the only filter that is **not** persisted. Every other filter from the dropdown is remembered.
+:::
\ No newline at end of file
diff --git a/docs/user-guide/automation/README.md b/docs/user-guide/automation/README.md
new file mode 100755
index 0000000000..de22dc6530
--- /dev/null
+++ b/docs/user-guide/automation/README.md
@@ -0,0 +1,25 @@
+---
+id: README
+title: Automation & Enablement
+sidebar_label: Automation & Enablement
+description: Learn how to automate operational workflows, job executions, and enable advanced automation capabilities in Devtron.
+hide_table_of_contents: true
+---
+
+The **Automation & Enablement** section in Devtron helps teams build automation pipelines beyond standard CI/CD workflows.
+It enables job creation, configuration, and scheduling for routine operational tasks.
+
+## Table of Contents
+
+* [Jobs](../jobs/README.md)
+ * [Create Job](../jobs/create-job.md)
+ * [Configurations](../jobs/configurations/source-code-job.md)
+ * [Source Code Job](../jobs/configurations/source-code-job.md)
+ * [Workflow Editor for Job](../jobs/configurations/workflow-editor-job.md)
+ * [ConfigMaps & Secrets](../jobs/configurations/configmap-secret/README.md)
+ * [ConfigMap Job](../jobs/configurations/configmap-secret/configmap-job.md)
+ * [Secret Job](../jobs/configurations/configmap-secret/secret-job.md)
+ * [Environment Override Job](../jobs/configurations/environment-override-job.md)
+ * [Triggering Job](../jobs/triggering-job.md)
+ * [Run History Job](../jobs/run-history-job.md)
+ * [Overview Job](../jobs/overview-job.md)
diff --git a/docs/user-guide/automation/alerting.md b/docs/user-guide/automation/alerting.md
new file mode 100755
index 0000000000..24dade02ad
--- /dev/null
+++ b/docs/user-guide/automation/alerting.md
@@ -0,0 +1,3 @@
+# Alerting
+
+WIP
\ No newline at end of file
diff --git a/docs/user-guide/automation/api-portal.md b/docs/user-guide/automation/api-portal.md
new file mode 100755
index 0000000000..c10af1621b
--- /dev/null
+++ b/docs/user-guide/automation/api-portal.md
@@ -0,0 +1,4 @@
+# API Portal
+
+
+WIP
\ No newline at end of file
diff --git a/docs/user-guide/automation/incident-response.md b/docs/user-guide/automation/incident-response.md
new file mode 100755
index 0000000000..52292380f1
--- /dev/null
+++ b/docs/user-guide/automation/incident-response.md
@@ -0,0 +1,3 @@
+# Incident Response
+
+WIP
\ No newline at end of file
diff --git a/docs/user-guide/automation/runbook-automation.md b/docs/user-guide/automation/runbook-automation.md
new file mode 100755
index 0000000000..f2748dbb8f
--- /dev/null
+++ b/docs/user-guide/automation/runbook-automation.md
@@ -0,0 +1,3 @@
+# Runbook Automation
+
+WIP
\ No newline at end of file
diff --git a/docs/user-guide/bulk-update.md b/docs/user-guide/bulk-update.md
old mode 100644
new mode 100755
index 6a80a63fa6..91d5ee3866
--- a/docs/user-guide/bulk-update.md
+++ b/docs/user-guide/bulk-update.md
@@ -1,101 +1,16 @@
-# Bulk Updates
-This feature helps you to update Deployment Template, ConfigMaps & Secrets for multiple apps in one go! You can filter the apps on the basis of environments, global flag, and app names(we provide support for both substrings included and excluded in the app name).
-## Overview
+---
+slug: /user-guide/bulk-update
+---
-Need to make some common changes across multiple devtron applications?
-**Bulk Edit** allows you to do that.
-Eg. You can change the value for `MaxReplicas` in Deployment Templates of multiple Devtron applications or you can add key-value pairs in multiple ConfigMaps & Secrets. However, you might not be able to change the values of locked keys. Refer [Lock Deployment Configuration](./global-configurations/lock-deployment-config.md) to know more.
+# Bulk Edit
-## Support
-Bulk edit is currently supported for:
- - Deployment Template
- - ConfigMaps
- - Secrets
+The **Bulk Edit** feature allows you to update **Deployment Templates**, **ConfigMaps**, and **Secrets** across multiple applications in a single operation.
+This is useful when you need to apply configuration changes, such as updating resource limits, environment variables, or Helm values for several applications at once.
-## Steps:
-
-1. Click on the `Bulk Edit` option in the main navigation. This is where you can write and execute scripts to perform bulk updates in Devtron objects.
-
- 
-
-2. To help you get started, a script template is provided under the `See Samples` section.
-
- 
-
-3. Copy and Paste the `Sample Script` in the code editor and make desired changes. Refer `Payload Configuration` in the Readme to understand the parameters.
-
- 
-
-### Example
-Example below will select all applications having `abc and xyz` present in their name and out of those will exclude applications having `abcd and xyza` in their name. Since global flag is false and envId 23 is provided, it will make changes in envId 23 and not in global deployment template for this application.
-
-If you want to update globally then please set `global: true`. If you have provided an envId but deployment template, ConfigMap or Secret is not overridden for that particular environment then it will not apply the changes.
-Also, of all the provided names of ConfigMaps/secrets, for every app & environment override only the names that are present in them will be considered.
-
-
-### Sample Script
-
-This is the piece of code which works as the input and has to be pasted in the code editor for achieving bulk updation
-task.
-
-```
-apiVersion: batch/v1beta1
-kind: Application
-spec:
- includes:
- names:
- - "%abc%"
- - "%xyz%"
- excludes:
- names:
- - "%abcd%"
- - "%xyza%"
- envIds:
- - 23
- global: false
- deploymentTemplate:
- spec:
- patchJson: '[{ "op": "add", "path": "/MaxSurge", "value": 1 },{"op": "replace","path":"/GracePeriod","value": "30"}]'
- configMap:
- spec:
- names:
- - "configmap1"
- - "configmap2"
- - "configmap3"
- patchJson: '[{ "op": "add", "path": "/{key}", "value": "{value}" },{"op": "replace","path":"/{key}","value": "{value}"}]'
- secret:
- spec:
- names:
- - "secret1"
- - "secret2"
- patchJson: '[{ "op": "add", "path": "/{key}", "value": "{value}" },{"op": "replace","path":"/{key}","value": "{value}"}]'
-```
-
-
-### Payload Configuration
-The following tables list the configurable parameters of the Payload component in the Script and their description along with example. Also, if you do not need to apply updates on all the tasks, i.e. Deployment Template, ConfigMaps & Secrets, leave the Spec object empty for that respective task.
-
-| Parameter | Description | Example |
-| -------------------------- | ---------------------------------- | ---------------------------------------------------------- |
-|`includes.names ` | Will filter apps having exact string or similar substrings | `["app%","%abc", "xyz"]` (will include all apps having `"app%"` **OR** `"%abc"` as one of their substring, example - app1, app-test, test-abc etc. **OR** application with name xyz) |
-| `excludes.names` | Will filter apps not having exact string or similar substrings. | `["%z","%y", "abc"]` (will filter out all apps having `"%z"` **OR** `"%y"` as one of their substring, example - appz, test-app-y etc. **OR** application with name abc) |
-| `envIds` | List of envIds to be updated for the selected applications. | `[1,2,3]` |
-| `global` | Flag to update global deployment template of applications. | `true`,`false` |
-| `deploymentTemplate.spec.patchJson` | String having the update operation(you can apply more than one changes at a time). It supports [JSON patch ](http://jsonpatch.com/) specifications for update. | `'[ { "op": "add", "path": "/MaxSurge", "value": 1 }, { "op": "replace", "path": "/GracePeriod", "value": "30" }]'` |
-| `configMap.spec.names` | Names of all ConfigMaps to be updated. | `configmap1`,`configmap2`,`configmap3` |
-| `secret.spec.names` | Names of all Secrets to be updated. | `secret1`,`secret2`|
-| `configMap.spec.patchJson` / `secret.spec.patchJson` | String having the update operation for ConfigMaps/Secrets(you can apply more than one changes at a time). It supports [JSON patch ](http://jsonpatch.com/) specifications for update. | `'[{ "op": "add", "path": "/{key}", "value": "{value}" },{"op": "replace","path":"/{key}","value": "{value}"}]'`(Replace the `{key}` part to the key you want to perform operation on & the `{value}`is the key's corresponding value |
-
-
-
-4. Once you have modified the script, you can click on the `Show Impacted Objects` button to see the names of all applications that will be modified when the script is `Run`.
-
- 
-
-5. Click on the `Run` button to execute the script. Status/Output of the script execution will be shown in the `Output` section of the bottom drawer.
-
- 
-
+---
+## Table of Contents
+* [**Bulk Update (v1beta1)**](./bulk-update/bulk-edit.md) - This is the standard bulk edit version available for all users.
+* [**Bulk Update (v1beta2)**](./bulk-update/bulk-edit-ent.md) - This is the latest version of **Bulk Edit**, available only to Enterprise users.
\ No newline at end of file
diff --git a/docs/user-guide/bulk-update/bulk-edit-ent.md b/docs/user-guide/bulk-update/bulk-edit-ent.md
new file mode 100755
index 0000000000..e847d73d74
--- /dev/null
+++ b/docs/user-guide/bulk-update/bulk-edit-ent.md
@@ -0,0 +1,667 @@
+# Bulk Edit (v1beta2)
+
+## Introduction
+
+**v1beta2** is the latest YAML script to perform bulk edits to Deployment Templates, ConfigMaps, or Secrets across multiple applications. This version is currently available only to Enterprise users.
+
+The script provides selectors for choosing the project, application, and environment within which you wish to edit the configs (can be used in combo). Moreover, you now have granular control over the update and delete operations you wish to perform on the configs.
+
+> **RBAC**: User needs to have [permissions](../global-configurations/authorization/user-access#grant-specific-permissions) to apps and environments to edit their configs.
+
+### Tree Structure of the Bulk Edit Script
+
+Below is the visual structure of the script. Refer [Examples](#examples-with-full-script) and [YAML Template](#combined-yaml-template) to know more.
+
+```yaml
+v1beta2 Script
+├── apiVersion # (API version is batch/v1beta2)
+├── kind # (Resource kind is Application)
+└── spec # (Main configuration)
+ ├── selectors # (Target apps filter)
+ │ └── match # (Filter logic used in solo or combo)
+ │ ├── project # (Project filters)
+ │ │ ├── includes # (Projects to include)
+ │ │ │ └── names # (Array of project names)
+ │ │ └── excludes # (Projects to exclude)
+ │ │ └── names # (Array of project names)
+ │ │
+ │ ├── app # (Application filters)
+ │ │ ├── includes # (Apps to include)
+ │ │ │ └── names # (Array of app names)
+ │ │ └── excludes # (Apps to exclude)
+ │ │ └── names # (Array of app names)
+ │ │
+ │ └── env # (Environment filters)
+ │ ├── includes # (Envs to include)
+ │ │ └── names # (Array of env names)
+ │ ├── excludes # (Envs to exclude)
+ │ │ └── names # (Array of env names)
+ │ └── type # (prod / non-prod)
+ │
+ ├── deploymentTemplate # (Edit deployment template)
+ │ └── spec # (Template spec)
+ │ ├── match # (Filter for DT)
+ │ │ ├── include-base-config # (true or false)
+ │ │ └── chart # (Filter for charts)
+ │ │ ├── name # (Enter chart type, e.g. Deployment)
+ │ │ ├── custom # (true if it's a user-uploaded custom chart)
+ │ │ └── version # (Filter for chart version)
+ │ │ ├── value # (Enter chart version, e.g. 4.20.0)
+ │ │ └── operator # (EQUAL | LESS | GREATER | LESS_EQUAL | GREATER_EQUAL)
+ │ └── operation # (Edit operation)
+ │ ├── action # (update only)
+ │ ├── field # (values / version)
+ │ ├── patchJson # (Define if operation.field=values)
+ │ └── chartVersion # (Define if operation.field=version)
+ │
+ ├── configMap # (Edit config maps)
+ │ └── spec # (ConfigMap spec)
+ │ ├── match # (Filter for ConfigMaps)
+ │ │ ├── include-base-config # (true or false)
+ │ │ ├── includes # (CMs to include)
+ │ │ │ └── names # (Array of config map names)
+ │ │ └── excludes # (CMs to exclude)
+ │ │ └── names # (Array of config map names)
+ │ │
+ │ └── operation # (Edit operation)
+ │ ├── action # (create/update/delete)
+ │ ├── field # (data)
+ │ ├── patchJson # (JSON patch for update)
+ │ └── value # (Key-values for create/delete)
+ │
+ └── secret # (Edit secrets)
+ └── spec # (Secret spec)
+ ├── match # (Filter for Secrets)
+ │ ├── include-base-config # (true or false)
+ │ ├── includes # (Secrets to include)
+ │ │ └── names # (Array of secret names)
+ │ └── excludes # (Secrets to exclude)
+ │ └── names # (Array of secret names)
+ │
+ └── operation # (Edit operation)
+ ├── action # (create/update/delete)
+ ├── field # (data)
+ ├── patchJson # (JSON patch for update)
+ └── value # (Key-values for create/delete)
+```
+
+We recommend you to perform bulk edits in 4 parts:
+
+1. [Use Selector Block](#step-1-use-selector-block)
+2. [Choose the Configs](#step-2-choose-the-configs)
+3. [Specify the Operation](#step-3-specify-the-operation)
+4. [Run the Script](#step-4-run-the-script)
+
+---
+
+## Step 1: Use Selector Block
+
+In Devtron, configs like Deployment Template, ConfigMaps, and Secrets are specified within application. So you need to determine the target applications initially.
+
+In the first part, we will look at the selector script required to filter the applications. Only the applications that match your selector logic will have their Deployment Template, ConfigMap, or Secret available for edits.
+
+```yaml
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors:
+ match:
+ project:
+ includes:
+ names: ["dev-project", "qa-project"]
+ excludes:
+ names: ["test-project"]
+ app:
+ includes:
+ names: ["%-dashboard"]
+ excludes:
+ names: ["demo-%"]
+ env:
+ includes:
+ names: ["staging", "dev"]
+ excludes:
+ names: ["%qa%"]
+ type: non-prod
+# Next Steps: Add spec.deploymentTemplate, spec.configMap, and/or spec.secret (check Step 2 and 3)
+```
+
+You can use `project`, `app`, `env` selectors with the following lists:
+* `includes.names` - A list to specify the ones we need to edit.
+* `excludes.names` - A list to specify the ones which are not to be edited.
+
+In **includes** and **excludes**, you can give the names of your projects/apps/environments. Additionally, you may use wildcard patterns (like `%-dashboard%`).
+
+---
+
+## Step 2: Choose the Configs
+
+Here you can filter the Deployment Templates, ConfigMaps, and Secrets you wish to edit (refer the block below).
+
+### Deployment Templates
+
+After you add the selector block, add `deploymentTemplate` object.
+
+```yaml
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors: # Add selector logic (check Step 1)
+ deploymentTemplate:
+ spec:
+ match:
+ chart:
+ name: "Deployment" ## Name of the deployment chart
+ custom: false ## Set as true if using your uploaded custom deployment chart
+ version:
+ value: "4.20.0"
+ operator: EQUAL ## Supports "GREATER", "LESS", "GREATER_EQUAL", "LESS_EQUAL"
+ operation: # Add operation object (check Step 3)
+```
+
+#### What you can do?
+* Add or remove Helm values defined in your chart
+* Update the chart version itself
+* When editing deployment templates, you may choose whether to apply changes to only environment-specific overrides or also to the base configuration:
+ * When `true`, your operations apply to base deployment template shared across environments
+ * When `false` or omitted, changes apply only to environment-level deployment templates
+* Combine with `configMap` and `secret` objects in the same script
+
+:::success Next Step
+[Add operations for your Deployment Template(s)](#on-deployment-templates)
+:::
+
+### ConfigMaps
+
+```yaml
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors: # Add selector logic (check Step 1)
+ configMap:
+ spec:
+ match:
+ include-base-config: true
+ includes:
+ names: ["qa-cm-%", "prod-cm-%"]
+ excludes:
+ names: ["%dev%", "%test%"]
+ operation: # Add operation object (check Step 3)
+```
+
+#### What you can do?
+* Add new keys, e.g., `FEATURE_ENABLE_X: true`
+* Update existing keys
+* Delete keys or the entire ConfigMap by name
+* Include Base Configuration
+ * This allows updates to the base-level ConfigMap
+ * Environment-level ConfigMaps remain unaffected if this flag is not set
+* Combine with `deploymentTemplate` and `secret` objects in the same script.
+
+:::success Next Step
+[Add operations for your ConfigMap(s)](#on-configmaps)
+:::
+
+### Secrets
+
+```yaml
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors: # Add selector logic (check Step 1)
+ secret:
+ spec:
+ match:
+ include-base-config: true
+ includes:
+ names: ["qa-secret-%", "prod-secret-%"]
+ excludes:
+ names: ["%dev%", "%test%"]
+ operation: # Add operation object (check Step 3)
+```
+
+#### What you can do?
+* Add or update secret keys, e.g., `API_KEY: efd32tr6tsjbf43765`
+* Delete keys or the entire Secret by name
+* Same usage pattern as ConfigMaps using `action`, `field: data`, and `value`/`patchJson`.
+* Include Base Configuration
+ * Enables edits on base-level Secret
+ * Use this to update secrets across environments from a single source of truth
+* Combine with `deploymentTemplate` and `configMap` objects in the same script
+
+:::success Next Step
+[Add operations for your Secret(s)](#on-secrets)
+:::
+
+---
+
+## Step 3: Specify the Operation
+
+Add the operation to be performed on the selected Deployment Templates, ConfigMaps, and Secrets.
+
+:::caution Supported operations vary by config type
+The supported operations depend on the type of config being edited.
+
+| Config Type | Supported Actions |
+|------------------------|---------------------------|
+| Deployment Templates | `update` only |
+| ConfigMaps | `create`, `update`, `delete` |
+| Secrets | `create`, `update`, `delete` |
+:::
+
+
+### On Deployment Templates
+
+:::info
+Deployment Templates support only `action: update`, along with `field: values` or `field: version`, and the corresponding `patchJson` or `chartVersion`.
+:::
+
+#### Example 1 - Configure memory to `250Mi`
+
+```yaml
+...
+...
+... # Add the following in deploymentTemplate.spec
+ operation:
+ action: update
+ field: values
+ patchJson: '[{ "op": "replace", "path": "/resources/requests/memory", "value": "250Mi" }]'
+```
+
+#### Example 2 - Add a new value `ENABLE_AUTOSCALING: true`
+
+```yaml
+...
+...
+... # Add the following in deploymentTemplate.spec
+ operation:
+ action: update
+ field: values
+ patchJson: '[{ "op": "add", "path": "/ENABLE_AUTOSCALING", "value": true }]'
+```
+
+#### Example 3 - Update deployment chart version to `4.30.1`
+
+```yaml
+...
+...
+... # Add the following in deploymentTemplate.spec
+ operation:
+ action: update
+ field: version
+ chartVersion: "4.30.1"
+```
+
+### On ConfigMaps
+
+#### Example 1 - Add `FEATURE_ENABLE_X` key in existing ConfigMap
+
+```yaml
+...
+...
+... # Add the following in configMap.spec
+ operation:
+ action: update
+ field: data
+ patchJson: '[{ "op": "add", "path": "/FEATURE_ENABLE_X", "value": "true" }]'
+```
+
+#### Example 2 - Update existing key `FEATURE_ENABLE_X`
+
+```yaml
+...
+...
+... # Add the following in configMap.spec
+ operation:
+ action: update
+ field: data
+ patchJson: '[{ "op": "replace", "path": "/FEATURE_ENABLE_X", "value": "false" }]'
+```
+
+#### Example 3 - Remove existing key `FEATURE_ENABLE_X: true` from ConfigMap
+
+```yaml
+...
+...
+... # Add the following in configMap.spec
+ operation:
+ action: update
+ field: data
+ patchJson: '[{ "op": "remove", "path": "/FEATURE_ENABLE_X" }]'
+```
+
+#### Example 4 - Delete ConfigMap
+
+```yaml
+...
+...
+... # Add the following in configMap.spec
+ operation:
+ action: delete
+ field: data
+ value: banking-cm # In 'value', enter the name of the ConfigMap to delete
+```
+
+
+### On Secrets
+
+#### Example 1 - Add `API_TOKEN` key in existing secret
+
+```yaml
+...
+...
+... # Add the following in secret.spec
+ operation:
+ action: update
+ field: data
+ patchJson: '[{ "op": "add", "path": "/API_TOKEN", "value": "u4hg847598fc" }]'
+```
+
+#### Example 2 - Update `DB_PASSWORD` key in secret
+
+```yaml
+...
+...
+... # Add the following in secret.spec
+ operation:
+ action: update
+ field: data
+ patchJson: '[{ "op": "replace", "path": "/DB_PASSWORD", "value": "root@123" }]'
+```
+
+#### Example 3 - Remove `API_KEY` key in secret
+
+```yaml
+...
+...
+... # Add the following in secret.spec
+ operation:
+ action: update
+ field: data
+ patchJson: '[{ "op": "remove", "path": "/API_KEY" }]'
+```
+
+#### Example 4 - Add multiple secret keys
+
+```yaml
+...
+...
+... # Add the following in secret.spec
+ operation:
+ action: update
+ field: data
+ patchJson: '[
+ { "op": "add", "path": "/TOKEN", "value": "shc24235" },
+ { "op": "replace", "path": "/API_KEY", "value": "u4hg847598fc" }
+ ]'
+```
+
+#### Example 5 - Delete Secret
+
+```yaml
+...
+...
+... # Add the following in secret.spec
+ operation:
+ action: delete
+ field: data
+ value: banking-secret # In 'value', enter the name of the secret to delete
+```
+
+---
+
+## Step 4: Run the Script
+
+Before running the script, make sure to check the impacted applications and configs, by clicking the **Show Impacted Objects** button. We recommend you to do this just so you don't end up unintentionally editing any config (Deployment Templates, ConfigMaps, and Secrets).
+
+Next, click **Run** to execute the script. The output of the script execution will be shown in the **Output** tab in the bottom drawer.
+
+---
+
+## Examples (With Full Script)
+
+### Edit Deployment Template
+
+**CASE 1**: Update `replicaCount` in only Base Deployment Templates of `devtron` project
+
+```YAML
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors:
+ match:
+ project:
+ includes:
+ names:
+ - devtron
+ deploymentTemplate:
+ spec:
+ match:
+ include-base-config: true
+ operation:
+ action: update
+ field: values
+ patchJson: '[{ "op": "replace", "path": "/replicaCount", "value": 2 }]'
+```
+
+**CASE 2**: Remove `replicaCount` in only Base Deployment Templates of all applications (names) that end with `-sanity-app`
+
+```YAML
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors:
+ match:
+ app:
+ includes:
+ names:
+ - "%-sanity-app"
+ deploymentTemplate:
+ spec:
+ match:
+ include-base-config: true
+ operation:
+ action: update
+ field: values
+ patchJson: '[{ "op": "remove", "path": "/replicaCount" }]'
+```
+
+**CASE 3**: Add `replicaCount` in both (Base + Env Override) Deployment Templates of all applications (names) having at least one prod environment (excluding any environment name containing `virtual`)
+
+```YAML
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors:
+ match:
+ env:
+ type: prod
+ excludes:
+ names:
+ - "%virtual%"
+ deploymentTemplate:
+ spec:
+ match:
+ include-base-config: true
+ operation:
+ action: update
+ field: values
+ patchJson: '[{ "op": "add", "path": "/replicaCount", "value": 2 }]'
+```
+
+**CASE 4**: Change Deployment Chart Version (Only Env Override) to `4.30.0` for all `non-prod` environments having `Rollout Deployment` chart and version `<= 4.20.0`
+
+```YAML
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors:
+ match:
+ env:
+ type: non-prod
+ deploymentTemplate:
+ spec:
+ match:
+ chart:
+ name: "Rollout Deployment"
+ version:
+ value: 4.20.0
+ operator: LESS_EQUAL
+ operation:
+ action: update
+ field: version
+ chartVersion: 4.30.0
+```
+
+### Edit ConfigMap
+
+**CASE 1**: Update `USE_GIT_CLI` in `orchestrator-cm` in only Base ConfigMap of all projects (names) that starts with `go-lang`
+
+```YAML
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors:
+ match:
+ project:
+ includes:
+ names:
+ - "go-lang%"
+ configMap:
+ spec:
+ match:
+ include-base-config: true
+ operation:
+ action: update
+ field: data
+ patchJson: '[{ "op": "replace", "path": "/USE_GIT_CLI", "value": "true" }]'
+```
+
+**CASE 2**: Remove `USE_GIT_CLI` in `orchestrator-cm` in only Base ConfigMap of all applications, except for the ConfigMaps with name `orchestrator-cm`
+
+```YAML
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors:
+ match:
+ app:
+ includes:
+ names:
+ - "%%" # %% Wildcard for all applications
+ configMap:
+ spec:
+ match:
+ include-base-config: true
+ excludes:
+ names:
+ - orchestrator-cm
+ operation:
+ action: update
+ field: data
+ patchJson: '[{ "op": "remove", "path": "/USE_GIT_CLI" }]'
+```
+
+**CASE 3**: Add `USE_GIT_CLI` in `orchestrator-cm` in both (Base + Env Override) ConfigMaps of all applications (names) having at least one `non-prod` environment (excluding any environment name containing `virtual`)
+
+```YAML
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors:
+ match:
+ env:
+ type: non-prod
+ excludes:
+ names:
+ - "%virtual%"
+ configMap:
+ spec:
+ match:
+ include-base-config: true
+ operation:
+ action: update
+ field: data
+ patchJson: '[{ "op": "add", "path": "/USE_GIT_CLI", "value": "true" }]'
+```
+
+**CASE 4**: Delete a ConfigMap named `orchestrator-cm` (Only From Env Override) from all `non-prod` environments except for the applications with name `orchestrator-app`
+
+```YAML
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors:
+ match:
+ app:
+ excludes:
+ names:
+ - orchestrator-app
+ env:
+ type: non-prod
+ configMap:
+ spec:
+ operation:
+ action: delete
+ value: orchestrator-cm
+```
+
+---
+
+## Combined YAML Template
+
+You can use the below script as a template if you wish to edit Deployment Templates, ConfigMaps, Secrets of one or more apps in bulk.
+
+```yaml
+apiVersion: batch/v1beta2
+kind: Application
+spec:
+ selectors:
+ match:
+ project:
+ includes:
+ names: ["dev"]
+ excludes:
+ names: ["test"]
+ app:
+ includes:
+ names: ["%-dashboard", "%-server"]
+ excludes:
+ names: ["%demo-%", "%test-%"]
+ env:
+ type: non-prod
+ deploymentTemplate:
+ spec:
+ match:
+ include-base-config: true
+ chart:
+ name: "Deployment"
+ custom: false
+ version:
+ value: "4.20.0"
+ operator: LESS_EQUAL
+ configMap:
+ spec:
+ match:
+ include-base-config: true
+ includes:
+ names: ["qa-cm-%", "prod-cm-%"]
+ excludes:
+ names: ["%dev%", "%test%"]
+ operation:
+ action: update
+ field: data
+ patchJson: '[{ "op": "add", "path": "/FEAT_TEST_ENABLE", "value": "true" },{"op": "replace","path":"/LOG_LEVEL","value": "-1"}]'
+ secret:
+ spec:
+ match:
+ include-base-config: true
+ includes:
+ names: ["qa-secret-%", "prod-secret-%"]
+ excludes:
+ names: ["%dev%", "%test%"]
+ operation:
+ action: update
+ field: data
+ patchJson: '[{ "op": "add", "path": "/DB_PASSWORD", "value": "********" },{"op": "replace","path":"/ADMIN_PASSWORD","value": "********"}]'
+```
+
diff --git a/docs/user-guide/bulk-update/bulk-edit.md b/docs/user-guide/bulk-update/bulk-edit.md
new file mode 100755
index 0000000000..11c758c725
--- /dev/null
+++ b/docs/user-guide/bulk-update/bulk-edit.md
@@ -0,0 +1,110 @@
+# Bulk Edit (v1beta1)
+
+This feature helps you to update Deployment Template, ConfigMaps & Secrets for multiple apps in one go! You can filter the apps on the basis of environments, global flag, and app names(we provide support for both substrings included and excluded in the app name).
+## Overview
+
+Need to make some common changes across multiple devtron applications?
+**Bulk Edit** allows you to do that.
+Eg. You can change the value for `MaxReplicas` in Deployment Templates of multiple Devtron applications or you can add key-value pairs in multiple ConfigMaps & Secrets. However, you might not be able to change the values of locked keys. Refer [Lock Deployment Configuration](../global-configurations/lock-deployment-config.md) to know more.
+
+## Support
+Bulk edit is currently supported for:
+ - Deployment Template
+ - ConfigMaps
+ - Secrets
+
+
+## Steps:
+
+1. Click on the `Bulk Edit` option in the main navigation. This is where you can write and execute scripts to perform bulk updates in Devtron objects.
+
+ 
+
Figure 1: Navigating to Bulk Edit
+
+2. To help you get started, click **Refer Sample Payload** to view a script template.
+
+ 
+
+
+3. Copy and Paste the sample script in the code editor and make desired changes. Refer `Payload Configuration` in the Readme to understand the parameters.
+
+ 
+
Figure 3: Bulk Update Script
+
+### Example
+Example below will select all applications having `abc and xyz` present in their name and out of those will exclude applications having `abcd and xyza` in their name. Since global flag is false and envId 23 is provided, it will make changes in envId 23 and not in global deployment template for this application.
+
+If you want to update globally then please set `global: true`. If you have provided an envId but deployment template, ConfigMap or Secret is not overridden for that particular environment then it will not apply the changes.
+Also, of all the provided names of ConfigMaps/secrets, for every app & environment override only the names that are present in them will be considered.
+
+
+### Sample Script
+
+This is the piece of code which works as the input and has to be pasted in the code editor for achieving bulk updation
+task.
+
+```
+apiVersion: batch/v1beta1
+kind: Application
+spec:
+ includes:
+ names:
+ - "%abc%"
+ - "%xyz%"
+ excludes:
+ names:
+ - "%abcd%"
+ - "%xyza%"
+ envIds:
+ - 23
+ global: false
+ deploymentTemplate:
+ spec:
+ patchJson: '[{ "op": "add", "path": "/MaxSurge", "value": 1 },{"op": "replace","path":"/GracePeriod","value": "30"}]'
+ configMap:
+ spec:
+ names:
+ - "configmap1"
+ - "configmap2"
+ - "configmap3"
+ patchJson: '[{ "op": "add", "path": "/{key}", "value": "{value}" },{"op": "replace","path":"/{key}","value": "{value}"}]'
+ secret:
+ spec:
+ names:
+ - "secret1"
+ - "secret2"
+ patchJson: '[{ "op": "add", "path": "/{key}", "value": "{value}" },{"op": "replace","path":"/{key}","value": "{value}"}]'
+```
+
+
+### Payload Configuration
+The following tables list the configurable parameters of the Payload component in the Script and their description along with example. Also, if you do not need to apply updates on all the tasks, i.e. Deployment Template, ConfigMaps & Secrets, leave the Spec object empty for that respective task.
+
+| Parameter | Description | Example |
+| -------------------------- | ---------------------------------- | ---------------------------------------------------------- |
+|`includes.names ` | Will filter apps having exact string or similar substrings | `["app%","%abc", "xyz"]` (will include all apps having `"app%"` **OR** `"%abc"` as one of their substring, example - app1, app-test, test-abc etc. **OR** application with name xyz) |
+| `excludes.names` | Will filter apps not having exact string or similar substrings. | `["%z","%y", "abc"]` (will filter out all apps having `"%z"` **OR** `"%y"` as one of their substring, example - appz, test-app-y etc. **OR** application with name abc) |
+| `envIds` | List of envIds to be updated for the selected applications. | `[1,2,3]` |
+| `global` | Flag to update global deployment template of applications. | `true`,`false` |
+| `deploymentTemplate.spec.patchJson` | String having the update operation(you can apply more than one changes at a time). It supports [JSON patch ](http://jsonpatch.com/) specifications for update. | `'[ { "op": "add", "path": "/MaxSurge", "value": 1 }, { "op": "replace", "path": "/GracePeriod", "value": "30" }]'` |
+| `configMap.spec.names` | Names of all ConfigMaps to be updated. | `configmap1`,`configmap2`,`configmap3` |
+| `secret.spec.names` | Names of all Secrets to be updated. | `secret1`,`secret2`|
+| `configMap.spec.patchJson` / `secret.spec.patchJson` | String having the update operation for ConfigMaps/Secrets(you can apply more than one changes at a time). It supports [JSON patch ](http://jsonpatch.com/) specifications for update. | `'[{ "op": "add", "path": "/{key}", "value": "{value}" },{"op": "replace","path":"/{key}","value": "{value}"}]'`(Replace the `{key}` part to the key you want to perform operation on & the `{value}`is the key's corresponding value |
+
+
+
+4. Once you have modified the script, you can click on the **Show Impacted Objects** button to see the names of all applications that will be modified when the script is executed.
+
+ 
+
Figure 4: Impact Object
+
+5. Click on the **Execute** button to execute the script. Status/Output of the script execution will be shown in the `Output` tab of the bottom drawer.
+
+ 
+
Figure 5: Executing Bulk Edit
+
+
+
diff --git a/docs/user-guide/cloning-application.md b/docs/user-guide/cloning-application.md
old mode 100644
new mode 100755
index 2bdc36d0c6..d27fc97da9
--- a/docs/user-guide/cloning-application.md
+++ b/docs/user-guide/cloning-application.md
@@ -1,12 +1,18 @@
+---
+hide_table_of_contents: true
+---
+
# Cloning Application
Click on `Create New` and the select `Custom app` to create a new application.
-
+
+
Figure 1: Create Button
As soon you click on `Custom app`, you will get a popup window on screen where you have to enter `app name` and `project` for the application. there are two radio buttons present on the popup window, one is for `Blank app` and another one is for `Clone an existing app`. For cloning an existing application, select the second one. After this, one more drop-down will appear on the window from which you can select the application that you want to clone. For this, you will have to type minimum three character to see the matching results in the drop-down. After typing the matching characters, select the application that you want to clone. You also can add additional information about the application (eg. `created by`, `Created on`) using `tags` (only key:value allowed).
-
+
+
Figure 2: Choosing an App to Clone
| Key | Description |
| :--- | :--- |
@@ -17,11 +23,11 @@ Click on `Create New` and the select `Custom app` to create a new application.
Now click on `Clone App` to clone the selected application.
-
+
+
Figure 3: Filling the Details
New application with a duplicate template is created.
-{% hint style="warning" %}
+:::caution
When cloning an application with GitOps configuration, the configuration itself is not copied. To set up the configuration for your new application, refer [GitOps Configuration](./creating-application/gitops-config.md) guide.
-{% endhint %}
-
+:::
\ No newline at end of file
diff --git a/docs/user-guide/command-bar.md b/docs/user-guide/command-bar.md
old mode 100644
new mode 100755
index ab42cda489..0ad6811f76
--- a/docs/user-guide/command-bar.md
+++ b/docs/user-guide/command-bar.md
@@ -6,7 +6,8 @@ hidden: true
## Why command bar?
The command bar is designed to enable you to navigate across the devtron dashboard without having to click around the screen.
-
+
+
Figure 1: Command Bar Sections
Top-level categories (eg. app, chart, security, global-config) are auto-filled depending upon your location on the Devtron dashboard.
@@ -20,15 +21,16 @@ Top-level categories (eg. app, chart, security, global-config) are auto-filled d
| Explore nested options | `→` |
| Navigate to a screen | `Enter` |
-
+
### How to use the command bar (Eg. Navigate to Workflow editor of an App.)
-
+
-
+
+
Figure 2: Command Bar
-
+
### Steps to use
@@ -42,7 +44,8 @@ Top-level categories (eg. app, chart, security, global-config) are auto-filled d
4. In this case, `app / dashboard / configure / workflow-editor` will navigate to the Workflow editor in dashboard application.
-
+
+
Figure 3: Command Bar - Workflow Editor
Similarly, you can use the command bar to navigate around the Devtron dashboard without a click.
diff --git a/docs/user-guide/create-application.md b/docs/user-guide/create-application.md
old mode 100644
new mode 100755
index 682936ee8c..fe558251b7
--- a/docs/user-guide/create-application.md
+++ b/docs/user-guide/create-application.md
@@ -4,7 +4,8 @@
* On the upper-right corner of the screen, click **Create**.
* Select **Custom app** from the drop-down list.
-
+
+
Figure 1: Create Button
A new application can be created from one of the following options:
@@ -16,12 +17,13 @@ A new application can be created from one of the following options:
To create a new application from the custom app, select **Custom app**.
-
+
+
Figure 2: Creating App from Scratch
* In the **Create application** window, enter an **App Name** and select a **Project**.
-* Select either:
**Create from scratch** to create an application from scratch, or
**Clone existing application** to clone an existing application.
-* If you select **Create from scratch**, select the project from the drop-down list. `Note`: You have to add [project under Global Configurations](./global-configurations/projects.md). Only then, it will appear in the drop-down list here.
-* If you select **Clone existing application**, select an app you want to clone from and the project from the drop-down list. `Note`: You have to add [project under Global Configurations](./global-configurations/projects.md). Only then, it will appear in the drop-down list here.
+* Select either:
**Create from scratch** to create an application from scratch
, or
**Clone existing application** to clone an existing application.
+* If you select **Create from scratch**, select the project from the drop-down list. `Note`: You have to [add a project](./global-configurations/projects.md). Only then, it will appear in the drop-down list here.
+* If you select **Clone existing application**, select an app you want to clone from and the project from the drop-down list. `Note`: You have to [add a project](./global-configurations/projects.md). Only then, it will appear in the drop-down list here.
## Tags
@@ -32,10 +34,9 @@ To create a new application from the custom app, select **Custom app**.
When tags are propagated, they are considered as labels to Kubernetes resources. Kubernetes offers integrated support for using these labels to query objects and perform bulk operations e.g., consolidated billing using labels. You can use these tags to filter/identify resources via CLI or in other Kubernetes tools.
+
Figure 3: Propagating Tags
* Click `+ Add tag` to add a new tag.
-* Click the symbol on the left side of your tag to propagate a tag. `Note`: Dark grey colour in symbol specifies that the tags are propagated.
-* To remove the tags from propagation, click the symbol again.
-* Click `Save`.
-
-
+* Click the symbol  on the left side of your tag to propagate a tag. `Note`: Dark grey colour in symbol specifies that the tags are propagated.
+* To remove the tags from propagation, click the symbol  again.
+* Click `Save`.
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/README.md b/docs/user-guide/creating-application/README.md
old mode 100644
new mode 100755
index f5ddacee13..326436aa48
--- a/docs/user-guide/creating-application/README.md
+++ b/docs/user-guide/creating-application/README.md
@@ -1,25 +1,46 @@
-# App Configuration
+---
+hide_table_of_contents: true
+---
-**Please configure Global Configurations before moving ahead with App Configuration**
+# App Configurations
-{% embed url="https://www.youtube.com/watch?v=9u-pKiWV-tM" caption="" %}
+
-**Parts of Documentation**
+This section helps you define how your application is built, deployed, and managed within Devtron. Each part below guides you through the stages of the app configuration process.
-[Git Repository](git-material.md)
+---
-[Build Configuration](docker-build-configuration.md)
+## Table of Contents
-[Base Configurations](./base-config/README.md)
+### [Git Repository](git-material.md)
+Connect your application’s source code to Devtron by adding one or more Git repositories.
+Here you’ll specify the repository URL, and branch or folder paths to pull your manifests and code from.
-[GitOps Configuration](gitops-config.md)
+### [Build Configuration](docker-build-configuration.md)
+Define how your application’s container image is built.
+You can set the Dockerfile path, build context, build arguments, and target Docker registry to generate the image for deployment.
-[Workflow Editor](workflow/README.md)
+### [Base Configurations](./base-config/README.md)
+Set up the fundamental deployment parameters for your application.
+This includes environment variables, secrets, deployment templates, and configuration files that define the behavior of your workloads.
-[External Links](external-links.md)
+### [GitOps Configuration](gitops-config.md)
+Enable GitOps for your application to automatically sync configuration changes from Git to your cluster.
+This ensures your deployments remain consistent with the declared state in your repositories.
-[Environment Overrides](environment-overrides.md)
+### [Workflow Editor](workflow/README.md)
+Use the Workflow Editor to define CI/CD pipelines for your application.
+Here you can create and customize build, test, and deployment stages, and add pre- or post-deployment tasks for full automation.
-[Deleting Application](../deleting-application.md)
+### [External Links](external-links.md)
+Link your application to third-party tools or dashboards such as monitoring, logging, or analytics systems.
+This helps you quickly navigate to related tools directly from Devtron.
-
\ No newline at end of file
+
+### [Environment Overrides](environment-overrides.md)
+Override specific configurations for different environments (e.g., dev, staging, production).
+Environment overrides let you have different parameters like resource limits in deployment template, configmaps, secrets, or URLs without changing the base configuration.
+
+
+### [Deleting Application](../deleting-application.md)
+Learn how to safely delete an application and its related configurations from Devtron when you no longer need it.
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/app-metrics.md b/docs/user-guide/creating-application/app-metrics.md
old mode 100644
new mode 100755
index aba0b7ff18..723bee7aaa
--- a/docs/user-guide/creating-application/app-metrics.md
+++ b/docs/user-guide/creating-application/app-metrics.md
@@ -4,7 +4,8 @@
Application Metrics are the indicators used to evaluate the performance and efficiency of your application. It can be enabled in the Devtron platform to see your application's metrics.
-
+
+
Figure 1: Application Metrics
---
@@ -21,19 +22,17 @@ Application Metrics are the indicators used to evaluate the performance and effi
## Set Up Application Metrics
-{% hint style="warning" %}
-### Note
+:::caution Note
Application metrics can only be enabled if your application is deployed using Devtron Deployment Charts and not [Custom Deployment Charts](../global-configurations/deployment-charts.md).
-{% endhint %}
+:::
### Step 1: Install Monitoring (Grafana) Integration
#### For OSS and Self-Managed Enterprise
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Only super admin users can install Devtron integrations.
-{% endhint %}
+:::
To use the Grafana dashboard, you need to first install the integration from the [Devtron Stack Manager](../integrations/README.md). Refer [Monitoring (Grafana) Integration](../integrations/grafana.md) to learn more.
@@ -44,19 +43,18 @@ If you want to enable Grafana Integration, email us at [enterprise@devtron.ai](m
### Step 2: Install Prometheus
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have [Admin role](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above to deploy a chart.
-{% endhint %}
+:::
-{% hint style="warning" %}
-### Note
+:::caution Note
Ensure [GitOps](../global-configurations/gitops.md) is configured before deploying Prometheus. If not, Prometheus will default to being deployed via Helm.
-{% endhint %}
+:::
1. Go to the **Chart Store** and search for `prometheus`. Use the Prometheus community's `kube-prometheus-stack` chart to deploy Prometheus.
- 
+ 
+
Figure 2: Chart Store
2. After selecting the chart, configure these values as needed before deployment.
@@ -66,20 +64,22 @@ Ensure [GitOps](../global-configurations/gitops.md) is configured before deployi
- pods=[*]
```
-
+
```yaml
serviceMonitorSelectorNilUsesHelmValues: false
podMonitorSelectorNilUsesHelmValues: false
```
-
+
Search for the above parameters, and update them as shown (or customize as needed).
- 
+ 
+
3. Enable `upgradeJob` parameter to install CRDs:
@@ -87,78 +87,79 @@ Ensure [GitOps](../global-configurations/gitops.md) is configured before deployi
In the Prometheus Helm chart settings, locate the `upgradeJob` parameter and set it to `true` if it is `false`.
- 
+ 
+
Figure 4: upgradeJob Parameter
4. After enabling the parameter, click **Deploy Chart**.
-{% hint style="warning" %}
-### Common Pitfall: Prometheus Deployment Timeout due to Failed CRDs
-
+:::caution Common Pitfall: Prometheus Deployment Timeout due to Failed CRDs
While deploying `kube-prometheus-stack` chart, the deployment status may show as **Timed out**, and some CustomResourceDefinitions (CRDs) may appear as **Failed**.
-To solve it, refer [Troubleshoot Issues](#common-pitfall-prometheus-deployment-timeout-due-to-failed-crds)
+To solve it, refer [Troubleshoot Issues](#troubleshoot-issues)
-{% endhint %}
+:::
### Step 3: Set Up Prometheus Endpoint
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Only super admin users can set up Prometheus endpoint in a cluster.
-{% endhint %}
+:::
1. Once Prometheus is installed, go to its **App Details** and navigate to **Networking** → **Service** in the K8s resources. Expand the Prometheus server service to see the endpoints.
2. Copy the URL of the `kube-prometheus` service as shown in the image below.
- 
+ 
+
Figure 5: Prometheus Service
3. To set Prometheus as a data source in Grafana, navigate to **Global Configurations** → **Clusters & Environments**, select your cluster, and edit its settings.
- 
+ 
+
Figure 6: Clusters and Environments
4. Now to set up the Prometheus endpoint:
1. Enable the `See metrics for applications in this cluster` option, as shown in the image below.
2. Paste the copied URL into the Prometheus endpoint field, ensuring it includes `http://`
3. Click **Update Cluster** to save the changes.
- 
+ 
+
Figure 7: Prometheus Endpoint
### Step 4: Enable Application Metrics
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have [Admin role](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above to enable application metrics.
-{% endhint %}
+:::
After adding the endpoint in your preferred cluster, **CPU usage** and **Memory usage** metrics will be visible in the **App Details** page for all the Devtron apps in that cluster (it may take a few minutes).
-
+
+
Figure 8: CPU Usage & Memory Usage
To enable **Throughput** and **Latency** metrics in Devtron, follow these steps:
-{% hint style=“warning” %}
-### Note
+:::caution Note
**Throughput** and **Latency** metrics will only display data if there is active traffic (i.e., incoming requests) to your application. If there is no traffic, these metrics will show `No data`.
-{% endhint %}
+:::
1. Open your Devtron app.
-2. Go to **Configurations** → **Base Configurations** → **Deployment Template**.
+2. Go to its **Configurations** (tab) → **Base Configurations** → **Deployment Template**.
3. Enable **Application Metrics** in the Deployment Template as shown below and save the changes.
- 
+ 
+
Figure 9: Enable Application Metrics
4. Now, you can track all your application metrics by navigating to **Applications** and going to the **App Details** page of your Devtron App as shown below.
- 
+ 
+
Figure 10: Application Metrics
-{% hint style="warning" %}
-### Note
+:::caution Note
If your environment is [Overridden](../creating-application/environment-overrides.md), you need to enable the Application Metrics at the environment override deployment template instead of the base deployment template.
-{% endhint %}
+:::
---
@@ -169,9 +170,11 @@ If your environment is [Overridden](../creating-application/environment-override
While deploying `kube-prometheus-stack` chart, the deployment status may show as **Timed out**, and some CustomResourceDefinitions (CRDs) may appear as **Failed**.
-
+
+
**This behavior is expected and do not require any action from you.**
@@ -194,7 +197,7 @@ kubectl apply -f https://raw.githubusercontent.com/devtron-labs/devtron/main/man
Grafana dashboards not visible in App Details page even after adding prometheus endpoint or Graphs showing error panel with id 2 not found
-If the graphs are not visible check if Prometheus is configured properly. Then go to **Global Configurations** > **Clusters & Environments** > Click on any environment for the cluster where you added Prometheus endpoint and simply click `Update`.
+If the graphs are not visible check if Prometheus is configured properly. Then go to **Global Configurations** → **Clusters & Environments** → Click on any environment for the cluster where you added Prometheus endpoint and simply click `Update`.
If the charts are still not visible, try visiting the URL: `/grafana?orgId=2`
If you see `Not Found` on this page, then follow all the given steps or if the page is accessible, and you are getting `panel with id 2 not found` then follow from step 6:
1. Get Grafana password using `kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.GRAFANA_PASSWORD}' | base64 -d`
@@ -233,7 +236,7 @@ If you see `Not Found` on this page, then follow all the given steps or if the p
5. Now from Devtron UI, update any of the environment again and its data source will be created automatically.
-6. In Grafana UI you need to be logged in and Go to Dashboards > Manage then click `Import` and Import the given dashboards one by one.
+6. In Grafana UI you need to be logged in and Go to Dashboards → Manage then click `Import` and Import the given dashboards one by one.
```
https://grafana.com/api/dashboards/13322/revisions/4/download
diff --git a/docs/user-guide/creating-application/base-config/README.md b/docs/user-guide/creating-application/base-config/README.md
old mode 100644
new mode 100755
index 6bd3e8a6e4..e55aecf81e
--- a/docs/user-guide/creating-application/base-config/README.md
+++ b/docs/user-guide/creating-application/base-config/README.md
@@ -14,7 +14,8 @@ Base Configurations in Devtron consists of:
In Devtron, these are the core settings that dictate an application's behavior.
-
+
+
Figure 1: Base Configurations of Application
## Next Steps
diff --git a/docs/user-guide/creating-application/base-config/config-maps.md b/docs/user-guide/creating-application/base-config/config-maps.md
old mode 100644
new mode 100755
index 18e5a3756d..a173b1dd45
--- a/docs/user-guide/creating-application/base-config/config-maps.md
+++ b/docs/user-guide/creating-application/base-config/config-maps.md
@@ -4,15 +4,20 @@ A ConfigMap stores key-value pairs (non-sensitive data) that your applications c
## Add ConfigMap
-1. Navigate to the **Applications** page and click on your preferred application.
+1. Go to **Application Management** → **Devtron Applications** → (Select Your App)
-2. Go to the **Configurations** → **Base Configurations**.
+ 
+
Figure 1: Navigating to App Configurations
- 
+2. Go to **Configurations** (tab) → **Base Configurations**.
+
+ 
+
Figure 2: Application's 'Configurations' Page
3. Click the **+** button next to **ConfigMaps**.
- 
+ 
+
Figure 3: Adding ConfigMap
4. **Data Type** - Choose between the following data types:
@@ -30,7 +35,8 @@ Follow the instructions below to create a Kubernetes ConfigMap:
2. **Name** - Provide a name to your ConfigMap (cannot be changed later).
- 
+ 
+
Figure 4: Naming the ConfigMap
3. **Mount data as** - Select how you want to mount the ConfigMap:
@@ -42,7 +48,7 @@ Follow the instructions below to create a Kubernetes ConfigMap:
* **GUI mode** – User-friendly interface. Click **+Add** button and enter the **Key** and **Value** fields without quotes.
* **YAML mode** – Raw YAML for entering key-value pairs in the format **`key: value`**. Boolean and numeric values must be wrapped in double quotes.
- {% embed url="https://www.youtube.com/watch?v=QfJqX6KM2lU" %}
+
5. You may [perform a dry run](#perform-a-dry-run) before clicking **Save**.
@@ -65,13 +71,15 @@ Kubernetes External ConfigMap is usually created to reuse a configMap outside th
### Mount ConfigMap Data
-
+
+
Figure 5: Selecting Data Volume Option
In the above example, we have seen how to pass environment variables in your ConfigMap. Additionally, there is an option to mount a ConfigMap by passing its content to a file. The content could be a plain text, json, yaml, bash script, etc. You can do so by selecting the `Data Volume` option in **Mount data as**.
The key of the ConfigMap should be your filename and the value of the ConfigMap should be your file content. In the below example, you `file.json` is the key, and the json content is the value of that ConfigMap (below the pipe (**|**) symbol). This file will be created on your specified [volume mount path](#volume-mount-path).
-
+
+
Figure 6: Adding File Content
### Volume Mount Path
@@ -85,15 +93,12 @@ When mounting multiple files to the same location, you can use the **Set Sub Pat
* If **Set Sub Path** is disabled (unchecked), the system will delete any files already present in the [specified path](#volume-mount-path) and then mount the new files.
-{% hint style="info" %}
-
-### Note
-
+:::info Note
In case of Kubernetes ConfigMap, all keys will be mounted as files on the specified path.
In case of Kubernetes External ConfigMap, manually specify the keys which should be mounted as files.
-{% endhint %}
+:::
### Set File Permission
@@ -125,7 +130,8 @@ Before saving your configured ConfigMap, you can use the **Dry Run** option (as
This feature helps you verify your configurations, detect issues, and ensure correctness.
-
+
+
Figure 7: Performing a Dry Run
Your configurations will appear in the left pane, while the right pane will display a section named `Manifest generated from merged` showing the computed Kubernetes manifest.
@@ -137,12 +143,12 @@ Your configurations will appear in the left pane, while the right pane will disp
2. Modify its values.
3. Click **Update**.
-{% hint style="warning" %}
-### Note
+:::caution Note
You cannot change the name of a ConfigMap. Create a new ConfigMap instead.
-{% endhint %}
+:::
-
+
+
Figure 8: Updating Existing ConfigMap
---
@@ -155,86 +161,13 @@ You may delete a ConfigMap if not in use anymore. Once a ConfigMap is deleted, i
3. Click **Delete**.
4. Confirm the deletion in the dialogbox.
-
+
+
Figure 9: Deleting ConfigMap
---
-## Edit a Protected ConfigMap [](https://devtron.ai/pricing)
-
-Any changes made to the protected base configurations (Deployment Template, ConfigMap, Secret) will require approval if an [approval policy](../../../user-guide/global-configurations/approval-policy.md) is enforced. When you want to edit a protected configuration, you can do it in the following ways:
-
-* [Normal Edit](#normal-edit) - Where changes to the protected configuration are made only after getting approval from the approver(s).
-
-* [Express Edit](#express-edit) - Where you bypass the approval process and directly make changes to the protected configuration.
-
-### Normal Edit
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
-Only a Super-Admin, Manager, or an Admin can edit the configuration values. Refer to [User Permissions](../../global-configurations/authorization/user-access.md) for more information.
-
-{% endhint %}
-
-{% embed url="https://www.youtube.com/watch?v=gY9LKJSVS-g" %}
-
-Follow the below steps to edit a protected ConfigMap:
-
-1. Navigate to the **Applications** page and click on your preferred application.
-
-2. Go to the **Configurations** → **Base Configurations**.
-
-3. Click on **ConfigMaps** and select the ConfigMap you'd like to edit.
-
-4. Modify the values either by using **GUI** or **YAML** editor.
-
-5. Click **Save Changes**. The Base Configurations pop-up page will be displayed.
-
- * **Save as draft** - Select this option if you want to continue making your changes later but save your changes as a draft for now.
-
- * **Propose changes** - Select this option if you want to propose your changes to the approvers. You can then select the approvers to get notified regarding the change from the **Select approvers** to notify drop-down box.
-
-6. Enter your comments (reason for making the changes) in the **Comment** text box.
-
-7. Click **Propose Changes**. The corresponding approver will be notified via email regarding your request.
-
-### Express Edit
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
-Only a Super-Admin (when the [Super admins toggle](../../global-configurations/approval-policy.md#excluding-super-admins) is enabled in the Exceptions tab) or [specific users / user groups](../../global-configurations/approval-policy.md#excluding-specific-users--user-groups--api-tokens) who are added as exceptions in the Approval Policy can make express edits. Refer to [Approval Policy](../../global-configurations/approval-policy.md) for more information.
-
-{% endhint %}
-
-Express edits allow you to bypass the approval process and make direct edits to the configurations. Follow the below steps to make express edits:
-
-1. Navigate to the **Applications** page and click on your preferred application.
-
-2. Go to the **Configurations** → **Base Configurations**.
-
-3. Click on **ConfigMaps** and select the ConfigMap you'd like to edit.
-
-4. Click on the **Edit** button.
-
-{% hint style="info" %}
-
-### Note
-
-The **Edit** button will only be displayed if:
-
-* You are a Super-Admin and the Super admins toggle is enabled in the Approval Policy page
-
-* You are added as an exception in the Approval Policy page.
-
-Refer to [Approval Policy](../../global-configurations/approval-policy.md) for more information.
-
-{% endhint %}
-
-5. Modify the values either by using **GUI** or **YAML** editor.
+## Edit a Protected ConfigMap
-6. Click on **Publish Changes** to direcly publish your changes.
+Any changes made to the protected base configurations (Deployment Template, ConfigMap, Secret) will require approval if an [approval policy](../../../user-guide/global-configurations/approval-policy.md) is enforced.
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/deployment-template-types/README.md b/docs/user-guide/creating-application/base-config/deployment-template-types/README.md
new file mode 100755
index 0000000000..f45ca769b9
--- /dev/null
+++ b/docs/user-guide/creating-application/base-config/deployment-template-types/README.md
@@ -0,0 +1,17 @@
+---
+hide_table_of_contents: true
+---
+
+# Types of Deployment Templates
+
+In Devtron, the following deployment charts are available for you to use for your application:
+
+* [Deployment](deployment.md)
+* [Rollout Deployment](rollout-deployment.md)
+* [Job and Cronjob](job-and-cronjob.md)
+* [StatefulSets](statefulset.md)
+
+
+
Figure 1: Deployment Charts by Devtron
+
+Each template serves a specific purpose; therefore, choose one based on your application’s requirements.
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/deployment-template-types/deployment.md b/docs/user-guide/creating-application/base-config/deployment-template-types/deployment.md
new file mode 100755
index 0000000000..cece37f901
--- /dev/null
+++ b/docs/user-guide/creating-application/base-config/deployment-template-types/deployment.md
@@ -0,0 +1,1133 @@
+# Deployment
+
+This chart creates a deployment that runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive. It does not support Blue/Green and Canary deployments. This is the default deployment chart. You can select `Deployment` chart when you want to use only basic use cases which contain the following:
+
+* Create a Deployment to rollout a ReplicaSet. The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
+* Declare the new state of the Pods. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
+* Rollback to an earlier Deployment revision if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
+* Scale up the Deployment to facilitate more load.
+* Use the status of the Deployment as an indicator that a rollout has stuck.
+* Clean up older ReplicaSets that you do not need anymore.
+
+
+
Figure 1: Choosing 'Deployment' Chart
+
+You can define application behavior by providing information in the following sections:
+
+| Key | Descriptions |
+| :--- | :--- |
+| `Chart version` | Select the Chart Version using which you want to deploy the application. Refer [Chart Version](../../../creating-application/base-config/deployment-template.md#choose-a-chart-version) section for more detail. |
+| `GUI` | You can perform a basic deployment configuration for your application in the **GUI** section instead of configuring the YAML file. Refer [Basic Configuration](../../../creating-application/base-config/deployment-template.md#using-gui) section for more detail.|
+| `YAML` | If you want to do additional configurations, then click **YAML** for modifications. Refer [YAML](#yaml) section for more detail. |
+| `Show application metrics` | You can enable `Show application metrics` to see your application's metrics-CPU Service Monitor usage, Memory Usage, Status, Throughput and Latency. Refer [Application Metrics](../../../creating-application/app-metrics.md) for more detail. |
+
+
+:::caution Note
+Super-admins can lock keys in deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
+:::
+
+---
+
+## YAML
+
+### Container Ports
+
+This defines ports on which application services will be exposed to other services
+
+```yaml
+ContainerPort:
+ - envoyPort: 8799
+ idleTimeout:
+ name: app
+ port: 8080
+ servicePort: 80
+ nodePort: 32056
+ supportStreaming: true
+ useHTTP2: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `envoyPort` | envoy port for the container |
+| `idleTimeout` | the duration of time that a connection is idle before the connection is terminated |
+| `name` | name of the port |
+| `port` | port for the container |
+| `servicePort` | port of the corresponding kubernetes service |
+| `nodePort` | nodeport of the corresponding kubernetes service |
+| `supportStreaming` | Used for high performance protocols like grpc where timeout needs to be disabled |
+| `useHTTP2` | Envoy container can accept HTTP2 requests |
+
+### EnvVariables
+```yaml
+EnvVariables: []
+```
+To set environment variables for the containers that run in the Pod.
+
+### EnvVariablesFromFieldPath
+```yaml
+EnvVariablesFromFieldPath:
+- name: ENV_NAME
+ fieldPath: status.podIP (example)
+```
+To set environment variables for the containers and fetching their values from pod-level fields.
+
+### Liveness Probe
+
+If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
+
+```yaml
+LivenessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the liveness needs to be checked |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for liveliness |
+| `periodSeconds` | It defines the time to check a given container for liveness |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the liveness probe |
+| `timeoutSeconds` | It defines the time for checking timeout |
+| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as live |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers, you can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+
+### MaxUnavailable
+
+```yaml
+ MaxUnavailable: 0
+```
+The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
+
+### MaxSurge
+
+```yaml
+MaxSurge: 1
+```
+The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count.
+The default value of "MaxSurge: " is 25%.
+
+### Min Ready Seconds
+
+```yaml
+MinReadySeconds: 60
+```
+This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
+
+### Readiness Probe
+
+If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
+
+```yaml
+ReadinessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the readiness needs to be checked |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for readiness |
+| `periodSeconds` | It defines the time to check a given container for readiness |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the readiness probe |
+| `timeoutSeconds` | It defines the time for checking timeout |
+| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as ready |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers, you can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+### Pod Disruption Budget
+
+You can create `PodDisruptionBudget` for each application. A PDB limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, an application would like to ensure the number of replicas running is never brought below the certain number.
+
+```yaml
+podDisruptionBudget:
+ minAvailable: 1
+```
+
+or
+
+```yaml
+podDisruptionBudget:
+ maxUnavailable: 50%
+```
+
+You can specify either `maxUnavailable` or `minAvailable` in a PodDisruptionBudget and it can be expressed as integers or as a percentage.
+
+| Key | Description |
+| :--- | :--- |
+| `minAvailable` | Evictions are allowed as long as they leave behind 1 or more healthy pods of the total number of desired replicas. |
+| `maxUnavailable` | Evictions are allowed as long as at most 1 unhealthy replica among the total number of desired replicas. |
+
+### Ambassador Mappings
+
+You can create ambassador mappings to access your applications from outside the cluster. At its core a Mapping resource maps a resource to a service.
+
+```yaml
+ambassadorMapping:
+ ambassadorId: "prod-emissary"
+ cors: {}
+ enabled: true
+ hostname: devtron.example.com
+ labels: {}
+ prefix: /
+ retryPolicy: {}
+ rewrite: ""
+ tls:
+ context: "devtron-tls-context"
+ create: false
+ hosts: []
+ secretName: ""
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable ambassador mapping else set false|
+| `ambassadorId` | used to specify id for specific ambassador mappings controller |
+| `cors` | used to specify cors policy to access host for this mapping |
+| `weight` | used to specify weight for canary ambassador mappings |
+| `hostname` | used to specify hostname for ambassador mapping |
+| `prefix` | used to specify path for ambassador mapping |
+| `labels` | used to provide custom labels for ambassador mapping |
+| `retryPolicy` | used to specify retry policy for ambassador mapping |
+| `corsPolicy` | Provide cors headers on flagger resource |
+| `rewrite` | used to specify whether to redirect the path of this mapping and where |
+| `tls` | used to create or define ambassador TLSContext resource |
+| `extraSpec` | used to provide extra spec values which not present in deployment template for ambassador resource |
+
+### Autoscaling
+
+This is connected to HPA and controls scaling up and down in response to request load.
+
+```yaml
+autoscaling:
+ enabled: false
+ MinReplicas: 1
+ MaxReplicas: 2
+ TargetCPUUtilizationPercentage: 90
+ TargetMemoryUtilizationPercentage: 80
+ extraMetrics: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable autoscaling else set false |
+| `MinReplicas` | Minimum number of replicas allowed for scaling |
+| `MaxReplicas` | Maximum number of replicas allowed for scaling |
+| `TargetCPUUtilizationPercentage` | The target CPU utilization that is expected for a container |
+| `TargetMemoryUtilizationPercentage` | The target memory utilization that is expected for a container |
+| `extraMetrics` | Used to give external metrics for autoscaling |
+
+### Flagger
+
+You can use flagger for canary releases with deployment objects. It supports flexible traffic routing with istio service mesh as well.
+
+```yaml
+flaggerCanary:
+ addOtherGateways: []
+ addOtherHosts: []
+ analysis:
+ interval: 15s
+ maxWeight: 50
+ stepWeight: 5
+ threshold: 5
+ annotations: {}
+ appProtocol: http
+ corsPolicy:
+ allowCredentials: false
+ allowHeaders:
+ - x-some-header
+ allowMethods:
+ - GET
+ allowOrigin:
+ - example.com
+ maxAge: 24h
+ createIstioGateway:
+ annotations: {}
+ enabled: false
+ host: example.com
+ labels: {}
+ tls:
+ enabled: false
+ secretName: example-tls-secret
+ enabled: false
+ gatewayRefs: null
+ headers:
+ request:
+ add:
+ x-some-header: value
+ labels: {}
+ loadtest:
+ enabled: true
+ url: http://flagger-loadtester.istio-system/
+ match:
+ - uri:
+ prefix: /
+ port: 8080
+ portDiscovery: true
+ retries: null
+ rewriteUri: /
+ targetPort: 8080
+ thresholds:
+ latency: 500
+ successRate: 90
+ timeout: null
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable canary releases using flagger else set false |
+| `addOtherGateways` | To provide multiple istio gateways for flagger |
+| `addOtherHosts` | Add multiple hosts for istio service mesh with flagger |
+| `analysis` | Define how the canary release should progress and at what interval |
+| `annotations` | Annotation to add on flagger resource |
+| `labels` | Labels to add on flagger resource |
+| `appProtocol` | Protocol to use for canary |
+| `corsPolicy` | Provide cors headers on flagger resource |
+| `createIstioGateway` | Set to true if you want to create istio gateway as well with flagger |
+| `headers` | Add headers if any |
+| `loadtest` | Enable load testing for your canary release |
+
+
+
+### Fullname Override
+
+```yaml
+fullnameOverride: app-name
+```
+`fullnameOverride` replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses `{app-name}-{environment-name}` as release fullname.
+
+### Image
+
+```yaml
+image:
+ pullPolicy: IfNotPresent
+```
+
+Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
+
+### imagePullSecrets
+
+`imagePullSecrets` contains the docker credentials that are used for accessing a registry.
+
+```yaml
+imagePullSecrets:
+ - regcred
+```
+regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry [https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) .
+
+### serviceAccount
+
+```yaml
+serviceAccount:
+ create: false
+ name: ""
+ annotations: {}
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Determines whether to create a ServiceAccount for pods or not. If set to `true`, a ServiceAccount will be created. |
+| `name` | Specifies the name of the ServiceAccount to use. |
+| `annotations` | Specify annotations for the ServiceAccount. |
+
+### HostAliases
+
+ the hostAliases field is used in a Pod specification to associate additional hostnames with the Pod's IP address. This can be helpful in scenarios where you need to resolve specific hostnames to the Pod's IP within the Pod itself.
+
+```yaml
+ hostAliases:
+ - ip: "192.168.1.10"
+ hostnames:
+ - "hostname1.example.com"
+ - "hostname2.example.com"
+ - ip: "192.168.1.11"
+ hostnames:
+ - "hostname3.example.com"
+```
+
+### Ingress
+
+This allows public access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ className: nginx
+ annotations: {}
+ hosts:
+ - host: example1.com
+ paths:
+ - /example
+ - host: example2.com
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+Legacy deployment-template ingress format
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ path: ""
+ host: ""
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `path` | Path name |
+| `host` | Host name |
+| `tls` | It contains security details |
+
+### Ingress Internal
+
+This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
+
+```yaml
+ingressInternal:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ hosts:
+ - host: example1.com
+ paths:
+ - /example
+ - host: example2.com
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `path` | Path name |
+| `host` | Host name |
+| `tls` | It contains security details |
+
+### Init Containers
+```yaml
+initContainers:
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+
+ - name: nginx
+ image: nginx:1.14.2
+ securityContext:
+ privileged: true
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+```
+Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to `true`.
+
+### Pause For Seconds Before Switch Active
+```yaml
+pauseForSecondsBeforeSwitchActive: 30
+```
+To wait for given period of time before switch active the container.
+
+### Resources
+
+These define minimum and maximum RAM and CPU available to the application.
+
+```yaml
+resources:
+ limits:
+ cpu: "1"
+ memory: "200Mi"
+ requests:
+ cpu: "0.10"
+ memory: "100Mi"
+```
+
+Resources are required to set CPU and memory usage.
+
+#### Limits
+
+Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
+
+#### Requests
+
+Requests are what the container is guaranteed to get.
+
+### Service
+
+This defines annotations and the type of service, optionally can define name also.
+
+```yaml
+ service:
+ type: ClusterIP
+ annotations: {}
+```
+
+### Volumes
+
+```yaml
+volumes:
+ - name: log-volume
+ emptyDir: {}
+ - name: logpv
+ persistentVolumeClaim:
+ claimName: logpvc
+```
+
+It is required when some values need to be read from or written to an external disk.
+
+### Volume Mounts
+
+```yaml
+volumeMounts:
+ - mountPath: /var/log/nginx/
+ name: log-volume
+ - mountPath: /mnt/logs
+ name: logpvc
+ subPath: employee
+```
+
+It is used to provide mounts to the volume.
+
+### Affinity and anti-affinity
+
+```yaml
+Spec:
+ Affinity:
+ Key:
+ Values:
+```
+
+Spec is used to define the desire state of the given container.
+
+Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
+
+Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
+
+#### Key
+
+Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+#### Values
+
+Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+### Tolerations
+
+```yaml
+tolerations:
+ - key: "key"
+ operator: "Equal"
+ value: "value"
+ effect: "NoSchedule|PreferNoSchedule|NoExecute(1.6 only)"
+```
+
+Taints are the opposite, they allow a node to repel a set of pods.
+
+A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
+
+Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
+
+### Arguments
+
+```yaml
+args:
+ enabled: false
+ value: []
+```
+
+This is used to give arguments to command.
+
+### Command
+
+```yaml
+command:
+ enabled: false
+ value: []
+```
+
+It contains the commands for the server.
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | To enable or disable the command |
+| `value` | It contains the commands |
+
+
+### Containers
+Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to `true`.
+
+```yaml
+ containers:
+ - name: nginx
+ image: nginx:1.14.2
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+```
+
+### Container Lifecycle Hooks
+
+Container lifecycle hooks are mechanisms that allow users to define custom actions to be performed at specific stages of a container's lifecycle i.e. PostStart or PreStop.
+
+```yaml
+containerSpec:
+ lifecycle:
+ enabled: false
+ postStart:
+ httpGet:
+ host: example.com
+ path: /example
+ port: 90
+ preStop:
+ exec:
+ command:
+ - sleep
+ - "10"
+```
+
+| Key | Description |
+| :--- | :--- |
+| `containerSpec` | containerSpec to define container lifecycle hooks configuration |
+| `lifecycle` | Lifecycle hooks for the container |
+| `enabled` | Set true to enable lifecycle hooks for the container else set false |
+| `postStart` | The postStart hook is executed immediately after a container is created |
+| `httpsGet` | Sends an HTTP GET request to a specific endpoint on the container |
+| `host` | Specifies the host (example.com) to which the HTTP GET request will be sent |
+| `path` | Specifies the path (/example) of the endpoint to which the HTTP GET request will be sent |
+| `port` | Specifies the port (90) on the host where the HTTP GET request will be sent |
+| `preStop` | The preStop hook is executed just before the container is stopped |
+| `exec` | Executes a specific command, such as pre-stop.sh, inside the cgroups and namespaces of the container |
+| `command` | The command to be executed is sleep 10, which tells the container to sleep for 10 seconds before it is stopped |
+
+### Prometheus
+
+```yaml
+ prometheus:
+ release: monitoring
+```
+
+It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case. It describes the state of the Prometheus.
+
+### rawYaml
+
+```yaml
+rawYaml:
+ - apiVersion: v1
+ kind: Service
+ metadata:
+ name: my-service
+ spec:
+ selector:
+ app: MyApp
+ ports:
+ - protocol: TCP
+ port: 80
+ targetPort: 9376
+ type: ClusterIP
+```
+Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
+
+### Grace Period
+
+```yaml
+GracePeriod: 30
+```
+Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the `GracePeriod`.
+
+A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
+
+There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
+
+
+### Server
+
+```yaml
+server:
+ deployment:
+ image_tag: 1-95a53
+ image: ""
+```
+
+It is used for providing server configurations.
+
+#### Deployment
+
+It gives the details for deployment.
+
+| Key | Description |
+| :--- | :--- |
+| `image_tag` | It is the image tag |
+| `image` | It is the URL of the image |
+
+### Service Monitor
+
+```yaml
+servicemonitor:
+ enabled: true
+ path: /abc
+ scheme: 'http'
+ interval: 30s
+ scrapeTimeout: 20s
+ metricRelabelings:
+ - sourceLabels: [namespace]
+ regex: '(.*)'
+ replacement: myapp
+ targetLabel: target_namespace
+```
+
+It gives the set of targets to be monitored.
+
+### Db Migration Config
+
+```yaml
+dbMigrationConfig:
+ enabled: false
+```
+
+It is used to configure database migration.
+
+### Istio
+
+These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
+
+```yaml
+istio:
+ enable: true
+
+ gateway:
+ enabled: true
+ labels:
+ app: my-gateway
+ annotations:
+ description: "Istio Gateway for external traffic"
+ host: "example.com"
+ tls:
+ enabled: true
+ secretName: my-tls-secret
+
+ virtualService:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio VirtualService for routing"
+ gateways:
+ - my-gateway
+ hosts:
+ - "example.com"
+ http:
+ - match:
+ - uri:
+ prefix: /v1
+ route:
+ - destination:
+ host: my-service-v1
+ subset: version-1
+ - match:
+ - uri:
+ prefix: /v2
+ route:
+ - destination:
+ host: my-service-v2
+ subset: version-2
+
+ destinationRule:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio DestinationRule for traffic policies"
+ subsets:
+ - name: version-1
+ labels:
+ version: "v1"
+ - name: version-2
+ labels:
+ version: "v2"
+ trafficPolicy:
+ connectionPool:
+ tcp:
+ maxConnections: 100
+ outlierDetection:
+ consecutiveErrors: 5
+ interval: 30s
+ baseEjectionTime: 60s
+
+ peerAuthentication:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio PeerAuthentication for mutual TLS"
+ selector:
+ matchLabels:
+ version: "v1"
+ mtls:
+ mode: STRICT
+ portLevelMtls:
+ 8080:
+ mode: DISABLE
+
+ requestAuthentication:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio RequestAuthentication for JWT validation"
+ selector:
+ matchLabels:
+ version: "v1"
+ jwtRules:
+ - issuer: "issuer-1"
+ jwksUri: "https://issuer-1/.well-known/jwks.json"
+
+ authorizationPolicy:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio AuthorizationPolicy for access control"
+ action: ALLOW
+ provider:
+ name: jwt
+ kind: Authorization
+ rules:
+ - from:
+ - source:
+ requestPrincipals: ["*"]
+ to:
+ - operation:
+ methods: ["GET"]
+```
+
+| Key | Description |
+| :--- | :--- |
+| `istio` | Istio enablement. When `istio.enable` set to true, Istio would be enabled for the specified configurations |
+| `authorizationPolicy` | It allows you to define access control policies for service-to-service communication. |
+| `action` | Determines whether to ALLOW or DENY the request based on the defined rules. |
+| `provider` | Authorization providers are external systems or mechanisms used to make access control decisions. |
+| `rules` | List of rules defining the authorization policy. Each rule can specify conditions and requirements for allowing or denying access. |
+| `destinationRule` | It allows for the fine-tuning of traffic policies and load balancing for specific services. You can define subsets of a service and apply different traffic policies to each subset. |
+| `subsets` | Specifies subsets within the service for routing and load balancing. |
+| `trafficPolicy` | Policies related to connection pool size, outlier detection, and load balancing. |
+| `gateway` | Allowing external traffic to enter the service mesh through the specified configurations. |
+| `host` | The external domain through which traffic will be routed into the service mesh. |
+| `tls` | Traffic to and from the gateway should be encrypted using TLS. |
+| `secretName` | Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway. |
+| `peerAuthentication` | It allows you to enforce mutual TLS and control the authentication between services. |
+| `mtls` | Mutual TLS. Mutual TLS is a security protocol that requires both client and server, to authenticate each other using digital certificates for secure communication. |
+| `mode` | Mutual TLS mode, specifying how mutual TLS should be applied. Modes include STRICT, PERMISSIVE, and DISABLE. |
+| `portLevelMtls` | Configures port-specific mTLS settings. Allows for fine-grained control over the application of mutual TLS on specific ports. |
+| `selector` | Configuration for selecting workloads to apply PeerAuthentication. |
+| `requestAuthentication` | Defines rules for authenticating incoming requests. |
+| `jwtRules` | Rules for validating JWTs (JSON Web Tokens). It defines how incoming JWTs should be validated for authentication purposes. |
+| `selector` | Specifies the conditions under which the RequestAuthentication rules should be applied. |
+| `virtualService` | Enables the definition of rules for how traffic should be routed to different services within the service mesh. |
+| `gateways` | Specifies the gateways to which the rules defined in the VirtualService apply. |
+| `hosts` | List of hosts (domains) to which this VirtualService is applied. |
+| `http` | Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies. |
+
+
+### KEDA Autoscaling
+[KEDA](https://keda.sh) is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
+
+Example for autosccaling with KEDA using Prometheus metrics is given below:
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced:
+ restoreToOriginalReplicaCount: true
+ horizontalPodAutoscalerConfig:
+ behavior:
+ scaleDown:
+ stabilizationWindowSeconds: 300
+ policies:
+ - type: Percent
+ value: 100
+ periodSeconds: 15
+ triggers:
+ - type: prometheus
+ metadata:
+ serverAddress: http://:9090
+ metricName: http_request_total
+ query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy",}
+ threshold: "50"
+ triggerAuthentication:
+ enabled: false
+ name:
+ spec: {}
+ authenticationRef: {}
+```
+Example for autosccaling with KEDA based on kafka is given below :
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced: {}
+ triggers:
+ - type: kafka
+ metadata:
+ bootstrapServers: b-2.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-3.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-1.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092
+ topic: Orders-Service-ESP.info
+ lagThreshold: "100"
+ consumerGroup: oders-remove-delivered-packages
+ allowIdleConsumers: "true"
+ triggerAuthentication:
+ enabled: true
+ name: keda-trigger-auth-kafka-credential
+ spec:
+ secretTargetRef:
+ - parameter: sasl
+ name: keda-kafka-secrets
+ key: sasl
+ - parameter: username
+ name: keda-kafka-secrets
+ key: username
+ authenticationRef:
+ name: keda-trigger-auth-kafka-credential
+```
+
+### NetworkPolicy
+
+Kubernetes NetworkPolicies control pod communication by defining rules for incoming and outgoing traffic.
+
+```yaml
+networkPolicy:
+ enabled: false
+ annotations: {}
+ labels: {}
+ podSelector:
+ matchLabels:
+ role: db
+ policyTypes:
+ - Ingress
+ - Egress
+ ingress:
+ - from:
+ - ipBlock:
+ cidr: 172.17.0.0/16
+ except:
+ - 172.17.1.0/24
+ - namespaceSelector:
+ matchLabels:
+ project: myproject
+ - podSelector:
+ matchLabels:
+ role: frontend
+ ports:
+ - protocol: TCP
+ port: 6379
+ egress:
+ - to:
+ - ipBlock:
+ cidr: 10.0.0.0/24
+ ports:
+ - protocol: TCP
+ port: 5978
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable NetworkPolicy. |
+| `annotations` | Additional metadata or information associated with the NetworkPolicy. |
+| `labels` | Labels to apply to the NetworkPolicy.
+| `podSelector` | Each NetworkPolicy includes a podSelector which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty podSelector selects all pods in the namespace.|
+| `policyTypes` | Each NetworkPolicy includes a policyTypes list which may include either Ingress, Egress, or both. |
+| `Ingress` | Controls incoming traffic to pods. |
+| `Egress` | Controls outgoing traffic from pods. |
+
+### Winter-Soldier
+Winter Soldier can be used to
+- cleans up (delete) Kubernetes resources
+- reduce workload pods to 0
+
+**_NOTE:_** After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check [the main repo](https://github.com/devtron-labs/winter-soldier)
+
+Given below is template values you can give in winter-soldier:
+```yaml
+winterSoldier:
+ enabled: false
+ apiVersion: pincher.devtron.ai/v1alpha1
+ action: sleep
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges: []
+ targetReplicas: []
+ fieldSelector: []
+```
+
+| Key | values | Description |
+| :--- | :--- | :--- |
+| `enabled` | `false`,`true` | decide the enabling factor |
+| `apiVersion` | `pincher.devtron.ai/v1beta1`, `pincher.devtron.ai/v1alpha1` | specific api version |
+| `action` | `sleep`,`delete`, `scale` | This specify the action need to perform. |
+| `timeRangesWithZone`:`timeZone` | eg:- `"Asia/Kolkata"`,`"US/Pacific"` | It use to specify the timeZone used. (It uses standard format. please refer [this](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)) |
+| `timeRangesWithZone`:`timeRanges` | array of [ `timeFrom`, `timeTo`, `weekdayFrom`, `weekdayTo`] | It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges. These settings will take `action` on Sat and Sun from 00:00 to 23:59:59, |
+| `targetReplicas` | `[n]` : n - number of replicas to scale. | These is mandatory field when the `action` is `scale` Default value is `[]`. |
+| `fieldSelector` | `- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now()) ` | These value will take a list of methods to select the resources on which we perform specified `action` . |
+
+
+here is an example,
+```yaml
+winterSoldier:
+ apiVersion: pincher.devtron.ai/v1alpha1
+ enabled: true
+ annotations: {}
+ labels: {}
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges:
+ - timeFrom: 00:00
+ timeTo: 23:59:59
+ weekdayFrom: Sat
+ weekdayTo: Sun
+ - timeFrom: 00:00
+ timeTo: 08:00
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ - timeFrom: 20:00
+ timeTo: 23:59:59
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ action: scale
+ targetReplicas: [1,1,1]
+ fieldSelector:
+ - AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '10h'), Now())
+```
+Above settings will take action on `Sat` and `Sun` from 00:00 to 23:59:59, and on `Mon`-`Fri` from 00:00 to 08:00 and 20:00 to 23:59:59. If `action:sleep` then runs hibernate at timeFrom and unhibernate at `timeTo`. If `action: delete` then it will delete workloads at `timeFrom` and `timeTo`. Here the `action:scale` thus it scale the number of resource replicas to `targetReplicas: [1,1,1]`. Here each element of `targetReplicas` array is mapped with the corresponding elements of array `timeRangesWithZone/timeRanges`. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
+
+The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
+
+- ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use `ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')`
+- AddTime - This can be used to add time. For eg `AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h')` ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
+- Now - This can be used to get current time.
+- CpuToNumber - This can be used to compare CPU. For eg `any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')})` will check if any resource.requests is less than 60Mi.
+
+
+### Security Context
+A security context defines privilege and access control settings for a Pod or Container.
+
+To add a security context for main container:
+```yaml
+containerSecurityContext:
+ allowPrivilegeEscalation: false
+```
+
+To add a security context on pod level:
+```yaml
+podSecurityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+```
+
+### Topology Spread Constraints
+You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
+
+```yaml
+topologySpreadConstraints:
+ - maxSkew: 1
+ topologyKey: zone
+ whenUnsatisfiable: DoNotSchedule
+ autoLabelSelector: true
+ customLabelSelector: {}
+```
+
+### Deployment Metrics
+
+It gives the realtime metrics of the deployed applications
+
+| Key | Description |
+| :--- | :--- |
+| `Deployment Frequency` | It shows how often this app is deployed to production |
+| `Change Failure Rate` | It shows how often the respective pipeline fails |
+| `Mean Lead Time` | It shows the average time taken to deliver a change to production |
+| `Mean Time to Recovery` | It shows the average time taken to fix a failed pipeline |
+
+---
+
+## 4. Show Application Metrics
+
+If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
+
+
+
Figure 2: Application Metrics
+
+Once all the Deployment template configurations are done, click on `Save` to save your deployment configuration. Now you are ready to create [Workflow](../../workflow/README.md) to do CI/CD.
+
+### Helm Chart Json Schema
+
+Helm Chart [json schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_5-1-0/schema.json) is used to validate the deployment template values.
+
+### Other Validations in Json Schema
+
+The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
+```
+resources.limits.cpu >= resources.requests.cpu
+resources.limits.memory >= resources.requests.memory
+envoyproxy.resources.limits.cpu >= envoyproxy.resources.requests.cpu
+envoyproxy.resources.limits.memory >= envoyproxy.resources.requests.memory
+```
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/deployment-template-types/job-and-cronjob.md b/docs/user-guide/creating-application/base-config/deployment-template-types/job-and-cronjob.md
new file mode 100755
index 0000000000..64e7a5db24
--- /dev/null
+++ b/docs/user-guide/creating-application/base-config/deployment-template-types/job-and-cronjob.md
@@ -0,0 +1,72 @@
+# Job and CronJob
+
+
+This chart deploys Job & CronJob. A Job is a controller object that represents a finite task and CronJob is used to schedule the creation of Jobs.
+
+ * [Job](#1-job)
+ * [CronJob](#2-cronjob)
+
+
+
Figure 1: Choosing 'Job & CronJob' Chart
+
+## 1. Job
+
+A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created. Suspeding a Job will delete its active Pods until the Job is resumed again.
+
+## **Example:**
+
+```yaml
+kind: Job
+jobConfigs:
+ activeDeadlineSeconds: 120
+ backoffLimit: 6
+ completions: 1
+ parallelism: 1
+ suspend: false
+ ttlSecondsAfterFinished: 100
+```
+
+| Key | Description |
+| :--- | :--- |
+| `activeDeadlineSeconds` | Another way to terminate a Job is by setting an active deadline. Do this by setting the activeDeadlineSeconds field of the Job to a number of seconds. The activeDeadlineSeconds applies to the duration of the job, no matter how many Pods are created. Once a Job reaches activeDeadlineSeconds, all of its running Pods are terminated and the Job status will become type: Failed with reason: DeadlineExceeded. |
+| `backoffLimit` | There are situations where you want to fail a Job after some amount of retries due to a logical error in configuration etc. To do so, set backoffLimit to specify the number of retries before considering a Job as failed. The back-off limit is set by default to 6. Failed Pods associated with the Job are recreated by the Job controller with an exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The back-off count is reset when a Job's Pod is deleted or successful without any other Pods for the Job failing around that time. |
+| `completions` | Jobs with fixed completion count - that is , jobs that have non null completions - can have a completion mode that is specified in completionMode. |
+| `parallelism` | The requested parallelism can be set to any non-negative value. If it is unspecified, it defaults to 1. If it is specified as 0, then the Job is effectively paused until it is increased. |
+| `suspend` | The suspend field is also optional. If it is set to true, all subsequent executions are suspended. This setting does not apply to already started executions. Defaults to false. |
+| `ttlSecondsAfterFinished` | The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean up finished Jobs (either Complete or Failed) automatically by specifying the ttlSecondsAfterFinished field of a Job, as in this example. The TTL controller will assume that a resource is eligible to be cleaned up TTL seconds after the resource has finished, in other words, when the TTL has expired. When the TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete its dependent objects together with it. Note that when the resource is deleted, its lifecycle guarantees, such as finalizers, will be honored. |
+| `kind` | As with all other Kubernetes config, a Job and cronjob needs apiVersion, kind.cronjob and job also needs a section fields which is optional . these fields specify to deploy which job (conjob or job) should be kept. by default, they are set job. |
+
+
+## 2. CronJob
+
+A CronJob creates jobs on a repeating schedule. One Cronjob object is like one line of a crontab (cron table) file. It runs a job periodically on a given schedule, written in Cron format.
+ CronJobs are meant for performing regular scheduled actions such as backups, report generation, and so on. Each task must be configured to recur indefinitely (as an example: once a day / week / month). You can schedule the time within that interval when the job should start.
+
+ ## **Example:**
+
+```yaml
+kind: CronJob
+cronjobConfigs:
+ concurrencyPolicy: Allow
+ failedJobsHistoryLimit: 1
+ restartPolicy: OnFailure
+ schedule: 32 8 * * *
+ startingDeadlineSeconds: 100
+ successfulJobsHistoryLimit: 3
+ suspend: false
+```
+
+| Key | Descriptions |
+| :--- | :--- |
+| `concurrencyPolicy` | A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If concurrencyPolicy is set to Forbid and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed,`Acceptable values: Allow / Forbid`. |
+| `failedJobsHistoryLimit` | The failedJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0 corresponds to keeping none of the corresponding kind of jobs after they finish. |
+| `restartPolicy` | The spec of a Pod has a restartPolicy field with possible values Always, OnFailure, and Never. The default value is Always.The restartPolicy applies to all containers in the Pod. restartPolicy only refers to restarts of the containers by the kubelet on the same node. After containers in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s, 40s, …), that is capped at five minutes. Once a container has executed for 10 minutes without any problems, the kubelet resets the restart backoff timer for that container, `Acceptable values: Always / OnFailure / Never`. |
+| `schedule` | To generate Cronjob schedule expressions, you can also use web tools like https://crontab.guru/. |
+| `startingDeadlineSeconds` | If startingDeadlineSeconds is set to a large value or left unset (the default) and if concurrencyPolicy is set to Allow, the jobs will always run at least once. |
+| `successfulJobsHistoryLimit` | The successfulJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0 corresponds to keeping none of the corresponding kind of jobs after they finish. |
+| `suspend` | The suspend field is also optional. If it is set to true, all subsequent executions are suspended. This setting does not apply to already started executions. Defaults to false. |
+| `kind` | As with all other Kubernetes config, a Job and cronjob needs apiVersion, kind.cronjob and job also needs a section fields which is optional . these fields specify to deploy which job (conjob or job) should be kept. by default, they are set cronjob. |
+
+:::caution Note
+Super-admins can lock keys in Job & CronJob deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
+:::
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/deployment-template-types/rollout-deployment.md b/docs/user-guide/creating-application/base-config/deployment-template-types/rollout-deployment.md
new file mode 100755
index 0000000000..5f18c4213a
--- /dev/null
+++ b/docs/user-guide/creating-application/base-config/deployment-template-types/rollout-deployment.md
@@ -0,0 +1,1209 @@
+
+# Rollout Deployment
+
+The `Rollout Deployment` chart deploys an advanced version of deployment that supports Blue/Green and Canary deployments. For functioning, it requires a rollout controller to run inside the cluster.
+
+
+
Figure 1: Choosing 'Rollout' Chart
+
+You can define application behavior by providing information in the following sections:
+
+| Key | Descriptions |
+| :--- | :--- |
+| `Chart version` | Select the Chart Version using which you want to deploy the application. Refer [Chart Version](../../../creating-application/base-config/deployment-template.md#choose-a-chart-version) section for more detail. |
+| `GUI` | You can perform a basic deployment configuration for your application in the **GUI** section instead of configuring the YAML file. Refer [Basic Configuration](../../../creating-application/base-config/deployment-template.md#using-gui) section for more detail.|
+| `YAML` | If you want to do additional configurations, then click **YAML** for modifications. Refer [YAML](#yaml) section for more detail. |
+| `Show application metrics` | You can enable `Show application metrics` to see your application's metrics-CPU Service Monitor usage, Memory Usage, Status, Throughput and Latency. Refer [Application Metrics](../../../creating-application/app-metrics.md) for more detail. |
+
+:::caution Note
+Super-admins can lock keys in rollout deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
+:::
+
+---
+
+## YAML
+
+### Container Ports
+
+This defines the ports on which application services will be exposed to other services.
+
+```yaml
+ContainerPort:
+ - envoyPort: 8799
+ envoyTimeout: 15s
+ idleTimeout:
+ name: app
+ port: 8080
+ servicePort: 80
+ supportStreaming: true
+ useHTTP2: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `envoyPort` | envoy port for the container. |
+| `envoyTimeout` | envoy Timeout for the container,envoy supports a wide range of timeouts that may need to be configured depending on the deployment.By default the envoytimeout is 15s. |
+| `idleTimeout` | the duration of time that a connection is idle before the connection is terminated. |
+| `name` | name of the port. |
+| `port` | port for the container. |
+| `servicePort` | port of the corresponding kubernetes service. |
+| `supportStreaming` | Used for high performance protocols like grpc where timeout needs to be disabled. |
+| `useHTTP2` | Envoy container can accept HTTP2 requests. |
+
+### EnvVariables
+```yaml
+EnvVariables: []
+```
+`EnvVariables` provide run-time information to containers and allow to customize how the application works and the behavior of the applications on the system.
+
+Here we can pass the list of env variables , every record is an object which contain the `name` of variable along with `value`.
+
+To set environment variables for the containers that run in the Pod.
+
+### Example of EnvVariables
+
+`IMP` Docker image should have env variables, whatever we want to set.
+```yaml
+EnvVariables:
+ - name: HOSTNAME
+ value: www.xyz.com
+ - name: DB_NAME
+ value: mydb
+ - name: USER_NAME
+ value: xyz
+```
+
+But `ConfigMap` and `Secret` are the preferred way to inject env variables. You can create this in **Configurations** page of your app.
+
+### ConfigMap
+
+It is a centralized storage, specific to k8s namespace where key-value pairs are stored in plain text.
+
+
+
Figure 2: ConfigMap
+
+### Secret
+
+It is a centralized storage, specific to k8s namespace where we can store the key-value pairs in plain text as well as in encrypted(`Base64`) form.
+
+
+
Figure 3: Secret
+
+`IMP` All key-values of `Secret` and `CofigMap` will reflect to your application.
+
+### Liveness Probe
+
+If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
+
+```yaml
+LivenessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ command:
+ - python
+ - /etc/app/healthcheck.py
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the liveness needs to be checked. |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for liveliness. |
+| `periodSeconds` | It defines how often (in seconds) to perform the liveness probe. |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfil the liveness probe. |
+| `timeoutSeconds` | The maximum time (in seconds) for the probe to complete. |
+| `failureThreshold` | The number of consecutive failures required to consider the probe as failed. |
+| `command` | The mentioned command is executed to perform the livenessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP. |
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+
+### MaxUnavailable
+
+```yaml
+ MaxUnavailable: 0
+```
+The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
+
+### MaxSurge
+
+```yaml
+MaxSurge: 1
+```
+The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count.
+The default value of "MaxSurge: " is 25%.
+
+### Min Ready Seconds
+
+```yaml
+MinReadySeconds: 60
+```
+This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
+
+### Readiness Probe
+
+If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
+
+```yaml
+ReadinessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ command:
+ - python
+ - /etc/app/healthcheck.py
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the readiness needs to be checked. |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for readiness. |
+| `periodSeconds` | It defines how often (in seconds) to perform the readiness probe. |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the readiness probe. |
+| `timeoutSeconds` | The maximum time (in seconds) for the probe to complete. |
+| `failureThreshold` | The number of consecutive failures required to consider the probe as failed. |
+| `command` | The mentioned command is executed to perform the readinessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP. |
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+
+### Startup Probe
+
+Startup Probe in Kubernetes is a type of probe used to determine when a container within a pod is ready to start accepting traffic. It is specifically designed for applications that have a longer startup time.
+
+```yaml
+StartupProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ command:
+ - python
+ - /etc/app/healthcheck.py
+ tcp: false
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the startup needs to be checked. |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for startup. |
+| `periodSeconds` | It defines how often (in seconds) to perform the startup probe. |
+| `successThreshold` | The number of consecutive successful probe results required to mark the container as ready. |
+| `timeoutSeconds` | The maximum time (in seconds) for the probe to complete. |
+| `failureThreshold` | The number of consecutive failures required to consider the probe as failed. |
+| `command` | The mentioned command is executed to perform the startup probe. If the command returns a non-zero value, it's equivalent to a failed probe. |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+### Autoscaling
+
+This is connected to HPA and controls scaling up and down in response to request load.
+
+```yaml
+autoscaling:
+ enabled: false
+ MinReplicas: 1
+ MaxReplicas: 2
+ TargetCPUUtilizationPercentage: 90
+ TargetMemoryUtilizationPercentage: 80
+ extraMetrics: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable autoscaling else set false.|
+| `MinReplicas` | Minimum number of replicas allowed for scaling. |
+| `MaxReplicas` | Maximum number of replicas allowed for scaling. |
+| `TargetCPUUtilizationPercentage` | The target CPU utilization that is expected for a container. |
+| `TargetMemoryUtilizationPercentage` | The target memory utilization that is expected for a container. |
+| `extraMetrics` | Used to give external metrics for autoscaling. |
+
+### Fullname Override
+
+```yaml
+fullnameOverride: app-name
+```
+`fullnameOverride` replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses `{app-name}-{environment-name}` as release fullname.
+
+### Image
+
+```yaml
+image:
+ pullPolicy: IfNotPresent
+```
+
+Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
+
+### serviceAccount
+
+```yaml
+serviceAccount:
+ create: false
+ name: ""
+ annotations: {}
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Determines whether to create a ServiceAccount for pods or not. If set to `true`, a ServiceAccount will be created. |
+| `name` | Specifies the name of the ServiceAccount to use. |
+| `annotations` | Specify annotations for the ServiceAccount. |
+
+
+### imagePullSecrets
+
+`imagePullSecrets` contains the docker credentials that are used for accessing a registry.
+
+```yaml
+imagePullSecrets:
+ - regcred
+```
+regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry [https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) .
+
+### HostAliases
+
+ the hostAliases field is used in a Pod specification to associate additional hostnames with the Pod's IP address. This can be helpful in scenarios where you need to resolve specific hostnames to the Pod's IP within the Pod itself.
+
+```yaml
+ hostAliases:
+ - ip: "192.168.1.10"
+ hostnames:
+ - "hostname1.example.com"
+ - "hostname2.example.com"
+ - ip: "192.168.1.11"
+ hostnames:
+ - "hostname3.example.com"
+```
+
+### Ingress
+
+This allows public access to the url. Please ensure you are using the right nginx annotation for nginx class.
+The default value is `nginx`.
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ className: nginx
+ annotations: {}
+ hosts:
+ - host: example1.com
+ pathType: "ImplementationSpecific"
+ paths:
+ - /example
+ - host: example2.com
+ pathType: "ImplementationSpecific"
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+Legacy deployment-template ingress format
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ path: ""
+ host: ""
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `host` | Host name |
+| `pathType` | Path in an Ingress is required to have a corresponding path type. Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`. |
+| `path` | Path name |
+| `tls` | It contains security details |
+
+### Ingress Internal
+
+This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
+
+```yaml
+ingressInternal:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ hosts:
+ - host: example1.com
+ pathType: "ImplementationSpecific"
+ paths:
+ - /example
+ - host: example2.com
+ pathType: "ImplementationSpecific"
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `host` | Host name |
+| `pathType` | Path in an Ingress is required to have a corresponding path type. Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`. |
+| `path` | Path name |
+| `pathType` | Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`.|
+| `tls` | It contains security details |
+
+### Init Containers
+```yaml
+initContainers:
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+
+ - name: nginx
+ image: nginx:1.14.2
+ securityContext:
+ privileged: true
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+```
+Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to `true`.
+
+### Pause For Seconds Before Switch Active
+```yaml
+pauseForSecondsBeforeSwitchActive: 30
+```
+To wait for given period of time before switch active the container.
+
+### Resources
+
+These define minimum and maximum RAM and CPU available to the application.
+
+```yaml
+resources:
+ limits:
+ cpu: "1"
+ memory: "200Mi"
+ requests:
+ cpu: "0.10"
+ memory: "100Mi"
+```
+
+Resources are required to set CPU and memory usage.
+
+#### Limits
+
+Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
+
+#### Requests
+
+Requests are what the container is guaranteed to get.
+
+### Service
+
+This defines annotations and the type of service, optionally can define name also.
+
+```yaml
+ service:
+ type: ClusterIP
+ annotations: {}
+```
+| Key | Description |
+| :--- | :--- |
+| `type` | Select the type of service, default `ClusterIP` |
+| `annotations` | Annotations are widely used to attach metadata and configs in Kubernetes. |
+| `name` | Optional field to assign name to service |
+| `loadBalancerSourceRanges` | If service type is `LoadBalancer`, Provide a list of whitelisted IPs CIDR that will be allowed to use the Load Balancer. |
+
+Note - If `loadBalancerSourceRanges` is not set, Kubernetes allows traffic from 0.0.0.0/0 to the LoadBalancer / Node Security Group(s).
+
+
+### Volumes
+
+```yaml
+volumes:
+ - name: log-volume
+ emptyDir: {}
+ - name: logpv
+ persistentVolumeClaim:
+ claimName: logpvc
+```
+
+It is required when some values need to be read from or written to an external disk.
+
+### Volume Mounts
+
+```yaml
+volumeMounts:
+ - mountPath: /var/log/nginx/
+ name: log-volume
+ - mountPath: /mnt/logs
+ name: logpvc
+ subPath: employee
+```
+
+It is used to provide mounts to the volume.
+
+### Affinity and anti-affinity
+
+```yaml
+Spec:
+ Affinity:
+ Key:
+ Values:
+```
+
+Spec is used to define the desire state of the given container.
+
+Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
+
+Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
+
+#### Key
+
+Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+#### Values
+
+Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+### Tolerations
+
+```yaml
+tolerations:
+ - key: "key"
+ operator: "Equal"
+ value: "value"
+ effect: "NoSchedule|PreferNoSchedule|NoExecute(1.6 only)"
+```
+
+Taints are the opposite, they allow a node to repel a set of pods.
+
+A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
+
+Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
+
+### Arguments
+
+```yaml
+args:
+ enabled: false
+ value: []
+```
+
+This is used to give arguments to command.
+
+### Command
+
+```yaml
+command:
+ enabled: false
+ value: []
+ workingDir: {}
+```
+
+It contains the commands to run inside the container.
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | To enable or disable the command. |
+| `value` | It contains the commands. |
+| `workingDir` | It is used to specify the working directory where commands will be executed. |
+
+### Containers
+Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to `true`.
+
+```yaml
+ containers:
+ - name: nginx
+ image: nginx:1.14.2
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+
+```
+
+### Prometheus
+
+```yaml
+ prometheus:
+ release: monitoring
+```
+
+It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case.It describes the state of the prometheus.
+
+### rawYaml
+
+```yaml
+rawYaml:
+ - apiVersion: v1
+ kind: Service
+ metadata:
+ name: my-service
+ spec:
+ selector:
+ app: MyApp
+ ports:
+ - protocol: TCP
+ port: 80
+ targetPort: 9376
+ type: ClusterIP
+```
+Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
+
+### Grace Period
+
+```yaml
+GracePeriod: 30
+```
+Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the `GracePeriod`.
+
+A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
+
+There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
+
+
+### Server
+
+```yaml
+server:
+ deployment:
+ image_tag: 1-95a53
+ image: ""
+```
+
+It is used for providing server configurations.
+
+#### Deployment
+
+It gives the details for deployment.
+
+| Key | Description |
+| :--- | :--- |
+| `image_tag` | It is the image tag |
+| `image` | It is the URL of the image |
+
+### Service Monitor
+
+```yaml
+servicemonitor:
+ enabled: true
+ path: /abc
+ scheme: 'http'
+ interval: 30s
+ scrapeTimeout: 20s
+ metricRelabelings:
+ - sourceLabels: [namespace]
+ regex: '(.*)'
+ replacement: myapp
+ targetLabel: target_namespace
+```
+
+It gives the set of targets to be monitored.
+
+### Db Migration Config
+
+```yaml
+dbMigrationConfig:
+ enabled: false
+```
+
+It is used to configure database migration.
+
+### Istio
+
+These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
+
+
+### Istio
+
+These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
+
+```yaml
+istio:
+ enable: true
+
+ gateway:
+ enabled: true
+ labels:
+ app: my-gateway
+ annotations:
+ description: "Istio Gateway for external traffic"
+ host: "example.com"
+ tls:
+ enabled: true
+ secretName: my-tls-secret
+
+ virtualService:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio VirtualService for routing"
+ gateways:
+ - my-gateway
+ hosts:
+ - "example.com"
+ http:
+ - match:
+ - uri:
+ prefix: /v1
+ route:
+ - destination:
+ host: my-service-v1
+ subset: version-1
+ - match:
+ - uri:
+ prefix: /v2
+ route:
+ - destination:
+ host: my-service-v2
+ subset: version-2
+
+ destinationRule:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio DestinationRule for traffic policies"
+ subsets:
+ - name: version-1
+ labels:
+ version: "v1"
+ - name: version-2
+ labels:
+ version: "v2"
+ trafficPolicy:
+ connectionPool:
+ tcp:
+ maxConnections: 100
+ outlierDetection:
+ consecutiveErrors: 5
+ interval: 30s
+ baseEjectionTime: 60s
+
+ peerAuthentication:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio PeerAuthentication for mutual TLS"
+ selector:
+ matchLabels:
+ version: "v1"
+ mtls:
+ mode: STRICT
+ portLevelMtls:
+ 8080:
+ mode: DISABLE
+
+ requestAuthentication:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio RequestAuthentication for JWT validation"
+ selector:
+ matchLabels:
+ version: "v1"
+ jwtRules:
+ - issuer: "issuer-1"
+ jwksUri: "https://issuer-1/.well-known/jwks.json"
+
+ authorizationPolicy:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio AuthorizationPolicy for access control"
+ action: ALLOW
+ provider:
+ name: jwt
+ kind: Authorization
+ rules:
+ - from:
+ - source:
+ requestPrincipals: ["*"]
+ to:
+ - operation:
+ methods: ["GET"]
+```
+
+| Key | Description |
+| :--- | :--- |
+| `istio` | Istio enablement. When `istio.enable` set to true, Istio would be enabled for the specified configurations |
+| `authorizationPolicy` | It allows you to define access control policies for service-to-service communication. |
+| `action` | Determines whether to ALLOW or DENY the request based on the defined rules. |
+| `provider` | Authorization providers are external systems or mechanisms used to make access control decisions. |
+| `rules` | List of rules defining the authorization policy. Each rule can specify conditions and requirements for allowing or denying access. |
+| `destinationRule` | It allows for the fine-tuning of traffic policies and load balancing for specific services. You can define subsets of a service and apply different traffic policies to each subset. |
+| `subsets` | Specifies subsets within the service for routing and load balancing. |
+| `trafficPolicy` | Policies related to connection pool size, outlier detection, and load balancing. |
+| `gateway` | Allowing external traffic to enter the service mesh through the specified configurations. |
+| `host` | The external domain through which traffic will be routed into the service mesh. |
+| `tls` | Traffic to and from the gateway should be encrypted using TLS. |
+| `secretName` | Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway. |
+| `peerAuthentication` | It allows you to enforce mutual TLS and control the authentication between services. |
+| `mtls` | Mutual TLS. Mutual TLS is a security protocol that requires both client and server, to authenticate each other using digital certificates for secure communication. |
+| `mode` | Mutual TLS mode, specifying how mutual TLS should be applied. Modes include STRICT, PERMISSIVE, and DISABLE. |
+| `portLevelMtls` | Configures port-specific mTLS settings. Allows for fine-grained control over the application of mutual TLS on specific ports. |
+| `selector` | Configuration for selecting workloads to apply PeerAuthentication. |
+| `requestAuthentication` | Defines rules for authenticating incoming requests. |
+| `jwtRules` | Rules for validating JWTs (JSON Web Tokens). It defines how incoming JWTs should be validated for authentication purposes. |
+| `selector` | Specifies the conditions under which the RequestAuthentication rules should be applied. |
+| `virtualService` | Enables the definition of rules for how traffic should be routed to different services within the service mesh. |
+| `gateways` | Specifies the gateways to which the rules defined in the VirtualService apply. |
+| `hosts` | List of hosts (domains) to which this VirtualService is applied. |
+| `http` | Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies. |
+
+### Application Metrics
+
+Application metrics can be enabled to see your application's metrics-CPU Service Monitor usage, Memory Usage, Status, Throughput and Latency.
+
+### Deployment Metrics
+
+It gives the realtime metrics of the deployed applications
+
+| Key | Description |
+| :--- | :--- |
+| `Deployment Frequency` | It shows how often this app is deployed to production |
+| `Change Failure Rate` | It shows how often the respective pipeline fails. |
+| `Mean Lead Time` | It shows the average time taken to deliver a change to production. |
+| `Mean Time to Recovery` | It shows the average time taken to fix a failed pipeline. |
+
+
+## Addon features in Deployment Template Chart version 3.9.0
+
+### Service Account
+
+```yaml
+serviceAccountName: orchestrator
+```
+
+A service account provides an identity for the processes that run in a Pod.
+
+When you access the cluster, you are authenticated by the API server as a particular User Account. Processes in containers inside pod can also contact the API server. When you are authenticated as a particular Service Account.
+
+When you create a pod, if you do not create a service account, it is automatically assigned the default service account in the namespace.
+
+### Pod Disruption Budget
+
+You can create `PodDisruptionBudget` for each application. A PDB limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, an application would like to ensure the number of replicas running is never brought below the certain number.
+
+```yaml
+podDisruptionBudget:
+ minAvailable: 1
+```
+
+or
+
+```yaml
+podDisruptionBudget:
+ maxUnavailable: 50%
+```
+
+You can specify either `maxUnavailable` or `minAvailable` in a PodDisruptionBudget and it can be expressed as integers or as a percentage.
+
+| Key | Description |
+| :--- | :--- |
+| `minAvailable` | Evictions are allowed as long as they leave behind 1 or more healthy pods of the total number of desired replicas. |
+| `maxUnavailable` | Evictions are allowed as long as at most 1 unhealthy replica among the total number of desired replicas. |
+
+### Application metrics Envoy Configurations
+
+```yaml
+envoyproxy:
+ image: envoyproxy/envoy:v1.14.1
+ configMapName: ""
+ resources:
+ limits:
+ cpu: "50m"
+ memory: "50Mi"
+ requests:
+ cpu: "50m"
+ memory: "50Mi"
+```
+
+Envoy is attached as a sidecar to the application container to collect metrics like 4XX, 5XX, Throughput and latency. You can now configure the envoy settings such as idleTimeout, resources etc.
+
+### Prometheus Rule
+
+```yaml
+prometheusRule:
+ enabled: true
+ additionalLabels: {}
+ namespace: ""
+ rules:
+ - alert: TooMany500s
+ expr: 100 * ( sum( nginx_ingress_controller_requests{status=~"5.+"} ) / sum(nginx_ingress_controller_requests) ) > 5
+ for: 1m
+ labels:
+ severity: critical
+ annotations:
+ description: Too many 5XXs
+ summary: More than 5% of the all requests did return 5XX, this require your attention
+```
+
+Alerting rules allow you to define alert conditions based on Prometheus expressions and to send notifications about firing alerts to an external service.
+
+In this case, Prometheus will check that the alert continues to be active during each evaluation for 1 minute before firing the alert. Elements that are active, but not firing yet, are in the pending state.
+
+### Pod Labels
+Labels are key/value pairs that are attached to pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects.
+```yaml
+podLabels:
+ severity: critical
+```
+
+### Pod Annotations
+Pod Annotations are widely used to attach metadata and configs in Kubernetes.
+
+```yaml
+podAnnotations:
+ fluentbit.io/exclude: "true"
+```
+
+### Custom Metrics in HPA
+
+```yaml
+autoscaling:
+ enabled: true
+ MinReplicas: 1
+ MaxReplicas: 2
+ TargetCPUUtilizationPercentage: 90
+ TargetMemoryUtilizationPercentage: 80
+ behavior:
+ scaleDown:
+ stabilizationWindowSeconds: 300
+ policies:
+ - type: Percent
+ value: 100
+ periodSeconds: 15
+ scaleUp:
+ stabilizationWindowSeconds: 0
+ policies:
+ - type: Percent
+ value: 100
+ periodSeconds: 15
+ - type: Pods
+ value: 4
+ periodSeconds: 15
+ selectPolicy: Max
+```
+
+HPA, by default is configured to work with CPU and Memory metrics. These metrics are useful for internal cluster sizing, but you might want to configure wider set of metrics like service latency, I/O load etc. The custom metrics in HPA can help you to achieve this.
+
+### Wait For Seconds Before Scaling Down
+```yaml
+waitForSecondsBeforeScalingDown: 30
+```
+Wait for given period of time before scaling down the container.
+
+
+
+## 4. Show Application Metrics
+
+If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
+
+
+
Figure 4: Application Metrics
+
+Once all the Deployment template configurations are done, click on `Save` to save your deployment configuration. Now you are ready to create [Workflow](../../workflow/README.md) to do CI/CD.
+
+### Helm Chart Json Schema Table
+
+Helm Chart json schema is used to validate the deployment template values.
+
+| Chart Version | Link |
+| :--- | :--- |
+| `reference-chart_3-12-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-12-0/schema.json) |
+| `reference-chart_3-11-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-11-0/schema.json) |
+| `reference-chart_3-10-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-10-0/schema.json) |
+| `reference-chart_3-9-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-9-0/schema.json) |
+
+
+### Other Validations in Json Schema
+
+The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
+```
+resources.limits.cpu >= resources.requests.cpu
+resources.limits.memory >= resources.requests.memory
+envoyproxy.resources.limits.cpu >= envoyproxy.resources.requests.cpu
+envoyproxy.resources.limits.memory >= envoyproxy.resources.requests.memory
+```
+
+## Addon features in Deployment Template Chart version 4.11.0
+
+### KEDA Autoscaling
+
+**Prerequisite:** KEDA controller should be installed in the cluster. To install KEDA controller using Helm, navigate to chart store and search for `keda` chart and deploy it. You can follow this [documentation](../../../deploy-chart/deployment-of-charts.md) for deploying a Helm chart on Devtron.
+
+KEDA Helm repo : https://kedacore.github.io/charts
+
+
+[KEDA](https://keda.sh) is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
+
+
+Example for autoscaling with KEDA using Prometheus metrics is given below:
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced:
+ restoreToOriginalReplicaCount: true
+ horizontalPodAutoscalerConfig:
+ behavior:
+ scaleDown:
+ stabilizationWindowSeconds: 300
+ policies:
+ - type: Percent
+ value: 100
+ periodSeconds: 15
+ triggers:
+ - type: prometheus
+ metadata:
+ serverAddress: http://:9090
+ metricName: http_request_total
+ query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy",}
+ threshold: "50"
+ triggerAuthentication:
+ enabled: false
+ name:
+ spec: {}
+ authenticationRef: {}
+```
+
+Example for autosccaling with KEDA based on kafka is given below :
+
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced: {}
+ triggers:
+ - type: kafka
+ metadata:
+ bootstrapServers: b-2.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-3.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-1.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092
+ topic: Orders-Service-ESP.info
+ lagThreshold: "100"
+ consumerGroup: oders-remove-delivered-packages
+ allowIdleConsumers: "true"
+ triggerAuthentication:
+ enabled: true
+ name: keda-trigger-auth-kafka-credential
+ spec:
+ secretTargetRef:
+ - parameter: sasl
+ name: keda-kafka-secrets
+ key: sasl
+ - parameter: username
+ name: keda-kafka-secrets
+ key: username
+ authenticationRef:
+ name: keda-trigger-auth-kafka-credential
+```
+
+### NetworkPolicy
+
+Kubernetes NetworkPolicies control pod communication by defining rules for incoming and outgoing traffic.
+
+```yaml
+networkPolicy:
+ enabled: false
+ annotations: {}
+ labels: {}
+ podSelector:
+ matchLabels:
+ role: db
+ policyTypes:
+ - Ingress
+ - Egress
+ ingress:
+ - from:
+ - ipBlock:
+ cidr: 172.17.0.0/16
+ except:
+ - 172.17.1.0/24
+ - namespaceSelector:
+ matchLabels:
+ project: myproject
+ - podSelector:
+ matchLabels:
+ role: frontend
+ ports:
+ - protocol: TCP
+ port: 6379
+ egress:
+ - to:
+ - ipBlock:
+ cidr: 10.0.0.0/24
+ ports:
+ - protocol: TCP
+ port: 5978
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable NetworkPolicy. |
+| `annotations` | Additional metadata or information associated with the NetworkPolicy. |
+| `labels` | Labels to apply to the NetworkPolicy.
+| `podSelector` | Each NetworkPolicy includes a podSelector which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty podSelector selects all pods in the namespace.|
+| `policyTypes` | Each NetworkPolicy includes a policyTypes list which may include either Ingress, Egress, or both. |
+| `Ingress` | Controls incoming traffic to pods. |
+| `Egress` | Controls outgoing traffic from pods. |
+
+
+### Winter-Soldier
+Winter Soldier can be used to
+- cleans up (delete) Kubernetes resources
+- reduce workload pods to 0
+
+**_NOTE:_** After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check [the main repo](https://github.com/devtron-labs/winter-soldier)
+
+Given below is template values you can give in winter-soldier:
+```yaml
+winterSoldier:
+ enabled: false
+ apiVersion: pincher.devtron.ai/v1alpha1
+ action: sleep
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges: []
+ targetReplicas: []
+ fieldSelector: []
+```
+
+| Key | values | Description |
+| :--- | :--- | :--- |
+| `enabled` | `false`,`true` | decide the enabling factor |
+| `apiVersion` | `pincher.devtron.ai/v1beta1`, `pincher.devtron.ai/v1alpha1` | specific api version |
+| `action` | `sleep`,`delete`, `scale` | This specify the action need to perform. |
+| `timeRangesWithZone`:`timeZone` | eg:- `"Asia/Kolkata"`,`"US/Pacific"` | It use to specify the timeZone used. (It uses standard format. please refer [this](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)) |
+| `timeRangesWithZone`:`timeRanges` | array of [ `timeFrom`, `timeTo`, `weekdayFrom`, `weekdayTo`] | It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges. These settings will take `action` on Sat and Sun from 00:00 to 23:59:59, |
+| `targetReplicas` | `[n]` : n - number of replicas to scale. | These is mandatory field when the `action` is `scale` Default value is `[]`. |
+| `fieldSelector` | `- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now()) ` | These value will take a list of methods to select the resources on which we perform specified `action` . |
+
+
+here is an example,
+```yaml
+winterSoldier:
+ apiVersion: pincher.devtron.ai/v1alpha1
+ enabled: true
+ annotations: {}
+ labels: {}
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges:
+ - timeFrom: 00:00
+ timeTo: 23:59:59
+ weekdayFrom: Sat
+ weekdayTo: Sun
+ - timeFrom: 00:00
+ timeTo: 08:00
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ - timeFrom: 20:00
+ timeTo: 23:59:59
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ action: scale
+ targetReplicas: [1,1,1]
+ fieldSelector:
+ - AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '10h'), Now())
+```
+
+Above settings will take action on `Sat` and `Sun` from 00:00 to 23:59:59, and on `Mon`-`Fri` from 00:00 to 08:00 and 20:00 to 23:59:59. If `action:sleep` then runs hibernate at timeFrom and unhibernate at `timeTo`. If `action: delete` then it will delete workloads at `timeFrom` and `timeTo`. Here the `action:scale` thus it scale the number of resource replicas to `targetReplicas: [1,1,1]`. Here each element of `targetReplicas` array is mapped with the corresponding elements of array `timeRangesWithZone/timeRanges`. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
+
+The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
+
+- ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use `ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')`
+- AddTime - This can be used to add time. For eg `AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h')` ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
+- Now - This can be used to get current time.
+- CpuToNumber - This can be used to compare CPU. For eg `any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')})` will check if any resource.requests is less than 60Mi.
+
+
+
+### Security Context
+A security context defines privilege and access control settings for a Pod or Container.
+
+To add a security context for main container:
+```yaml
+containerSecurityContext:
+ allowPrivilegeEscalation: false
+```
+
+To add a security context on pod level:
+```yaml
+podSecurityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+```
+
+### Topology Spread Constraints
+You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
+
+```yaml
+topologySpreadConstraints:
+ - maxSkew: 1
+ topologyKey: zone
+ whenUnsatisfiable: DoNotSchedule
+ autoLabelSelector: true
+ customLabelSelector: {}
+```
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/deployment-template-types/statefulset.md b/docs/user-guide/creating-application/base-config/deployment-template-types/statefulset.md
new file mode 100755
index 0000000000..4ad66e1530
--- /dev/null
+++ b/docs/user-guide/creating-application/base-config/deployment-template-types/statefulset.md
@@ -0,0 +1,993 @@
+# StatefulSet
+
+The StatefulSet chart in Devtron allows you to deploy and manage stateful applications. StatefulSet is a Kubernetes resource that provides guarantees about the ordering and uniqueness of Pods during deployment and scaling.
+
+
+
Figure 1: Choosing 'StatefulSet' Chart
+
+It supports only `ONDELETE` and `ROLLINGUPDATE` deployment strategy.
+
+
+
Figure 2: Selecting Deployment Strategy
+
+
+You can select `StatefulSet` chart when you want to use only basic use cases which contain the following:
+
+* **Managing Stateful Applications:** StatefulSets are ideal for managing stateful applications, such as databases or distributed systems, that require stable network identities and persistent storage for each Pod.
+
+* **Ordered Pod Management:** StatefulSets ensure ordered and predictable management of Pods by providing each Pod with a unique and stable hostname based on a defined naming convention and ordinal index.
+
+* **Updating and Scaling Stateful Applications:** StatefulSets support updating and scaling stateful applications by creating new versions of the StatefulSet and performing rolling updates or scaling operations in a controlled manner, ensuring minimal disruption to the application.
+
+* **Persistent Storage:** StatefulSets have built-in mechanisms for handling persistent volumes, allowing each Pod to have its own unique volume claim and storage. This ensures data persistence even when Pods are rescheduled or restarted.
+
+* **Maintaining Pod Identity:** StatefulSets guarantee consistent identity for each Pod throughout its lifecycle. This stability is maintained even if the Pods are rescheduled, allowing applications to rely on stable network identities.
+
+* **Rollback Capability:** StatefulSets provide the ability to rollback to a previous version in case the current state of the application is unstable or encounters issues, ensuring a known working state for the application.
+
+* **Status Monitoring:** StatefulSets offer status information that can be used to monitor the deployment, including the current version, number of replicas, and the readiness of each Pod. This helps in tracking the health and progress of the StatefulSet deployment.
+
+* **Resource Cleanup:** StatefulSets allow for easy cleanup of older versions by deleting StatefulSets and their associated Pods and persistent volumes that are no longer needed, ensuring efficient resource utilization.
+
+:::caution Note
+Super-admins can lock keys in StatefulSet deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
+:::
+
+
+## 1. Yaml File
+
+### Container Ports
+
+This defines ports on which application services will be exposed to other services
+
+```yaml
+ContainerPort:
+ - envoyPort: 8799
+ idleTimeout:
+ name: app
+ port: 8080
+ servicePort: 80
+ nodePort: 32056
+ supportStreaming: true
+ useHTTP2: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `envoyPort` | envoy port for the container. |
+| `idleTimeout` | the duration of time that a connection is idle before the connection is terminated. |
+| `name` | name of the port. |
+| `port` | port for the container. |
+| `servicePort` | port of the corresponding kubernetes service. |
+| `nodePort` | nodeport of the corresponding kubernetes service. |
+| `supportStreaming` | Used for high performance protocols like grpc where timeout needs to be disabled. |
+| `useHTTP2` | Envoy container can accept HTTP2 requests. |
+
+### EnvVariables
+```yaml
+EnvVariables: []
+```
+
+### EnvVariablesFromSecretKeys
+```yaml
+EnvVariablesFromSecretKeys:
+ - name: ENV_NAME
+ secretName: SECRET_NAME
+ keyName: SECRET_KEY
+
+```
+ It is used to get the name of Environment Variable name, Secret name and the Key name from which we are using the value in that corresponding Environment Variable.
+
+ ### EnvVariablesFromConfigMapKeys
+```yaml
+EnvVariablesFromConfigMapKeys:
+ - name: ENV_NAME
+ configMapName: CONFIG_MAP_NAME
+ keyName: CONFIG_MAP_KEY
+
+```
+ It is used to get the name of Environment Variable name, Config Map name and the Key name from which we are using the value in that corresponding Environment Variable.
+
+To set environment variables for the containers that run in the Pod.
+### StatefulSetConfig
+These are all the configuration settings for the StatefulSet.
+```yaml
+statefulSetConfig:
+ labels:
+ app: my-statefulset
+ environment: production
+ annotations:
+ example.com/version: "1.0"
+ serviceName: "my-statefulset-service"
+ podManagementPolicy: "Parallel"
+ revisionHistoryLimit: 5
+ mountPath: "/data"
+ volumeClaimTemplates:
+ - apiVersion: v1
+ kind: PersistentVolumeClaim
+ metadata:
+ labels:
+ app: my-statefulset
+ spec:
+ accessModes:
+ - ReadWriteOnce
+ dataSource:
+ kind: Snapshot
+ apiGroup: snapshot.storage.k8s.io
+ name: my-snapshot
+ resources:
+ requests:
+ storage: 5Gi
+ limits:
+ storage: 10Gi
+ storageClassName: my-storage-class
+ selector:
+ matchLabels:
+ app: my-statefulset
+ volumeMode: Filesystem
+ volumeName: my-pv
+ - apiVersion: v1
+ kind: PersistentVolumeClaim
+ metadata:
+ name: pvc-logs
+ labels:
+ app: myapp
+ spec:
+ accessModes:
+ - ReadWriteMany
+ dataSourceRef:
+ kind: Secret
+ apiGroup: v1
+ name: my-secret
+ resources:
+ requests:
+ storage: 5Gi
+ storageClassName: my-storage-class
+ selector:
+ matchExpressions:
+ - {key: environment, operator: In, values: [production]}
+ volumeMode: Block
+ volumeName: my-pv
+
+```
+Mandatoryfields in statefulSetConfig is
+```
+statefulSetConfig:
+ mountPath: /tmp
+ volumeClaimTemplates:
+ - spec:
+ accessModes:
+ - ReadWriteOnce
+ resources:
+ requests:
+ storage: 2Gi
+```
+Here is an explanation of each field in the statefulSetConfig :
+
+
+| Key | Description |
+| :--- | :--- |
+| `labels` | set of key-value pairs used to identify the StatefulSet . |
+| `annotations` | A map of key-value pairs that are attached to the stateful set as metadata. |
+| `serviceName` | The name of the Kubernetes Service that the StatefulSet should create. |
+| `podManagementPolicy` | A policy that determines how Pods are created and deleted by the StatefulSet. In this case, the policy is set to "Parallel", which means that all Pods are created at once. |
+| `revisionHistoryLimit` | The number of revisions that should be stored for each replica of the StatefulSet. |
+| `updateStrategy` | The update strategy used by the StatefulSet when rolling out changes. |
+| `mountPath` | The path where the volume should be mounted in the container. |
+
+volumeClaimTemplates: An array of volume claim templates that are used to create persistent volumes for the StatefulSet. Each volume claim template specifies the storage class, access mode, storage size, and other details of the persistent volume.
+
+
+| Key | Description |
+| :--- | :--- |
+| `apiVersion` | The API version of the PVC . |
+| `kind` | The type of object that the PVC is. |
+| `metadata` | Metadata that is attached to the resource being created. |
+| `labels` | A set of key-value pairs used to label the object for identification and selection. |
+| `spec` | The specification of the object, which defines its desired state and behavior.|
+| `accessModes` | A list of access modes for the PersistentVolumeClaim, such as "ReadWriteOnce" or "ReadWriteMany". |
+| `dataSource` | A data source used to populate the PersistentVolumeClaim, such as a Snapshot or a StorageClass. |
+| `kind`| specifies the kind of the snapshot, in this case Snapshot.|
+| `apiGroup`| specifies the API group of the snapshot API, in this case snapshot.storage.k8s.io.|
+| `name`| specifies the name of the snapshot, in this case my-snapshot.|
+| `dataSourceRef` | A reference to a data source used to create the persistent volume. In this case, it's a secret. |
+| `updateStrategy` | The update strategy used by the StatefulSet when rolling out changes. |
+| `resources` | The resource requests and limits for the PersistentVolumeClaim, which define the minimum and maximum amount of storage it can use. |
+| `requests` | The amount of storage requested by the PersistentVolumeClaim. |
+| `limits` | The maximum amount of storage that the PersistentVolumeClaim can use. |
+| `storageClassName` | The name of the storage class to use for the persistent volume. |
+| `selector` | The selector used to match a persistent volume to a persistent volume claim. |
+| `matchLabels` | a map of key-value pairs to match the labels of the corresponding PersistentVolume.|
+| `matchExpressions` |A set of requirements that the selected object must meet to be considered a match. |
+| `key` | The key of the label or annotation to match.|
+| `operator` | The operator used to compare the key-value pairs (in this case, "In" specifies a set membership test).|
+| `values` | A list of values that the selected object's label or annotation must match.|
+| `volumeMode` | The mode of the volume, either "Filesystem" or "Block". |
+| `volumeName` | The name of the PersistentVolume that is created for the PersistentVolumeClaim. |
+
+
+### Liveness Probe
+
+If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
+
+```yaml
+LivenessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the liveness needs to be checked. |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for liveliness. |
+| `periodSeconds` | It defines the time to check a given container for liveness. |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfil the liveness probe. |
+| `timeoutSeconds` | It defines the time for checking timeout. |
+| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as live. |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+
+### MaxUnavailable
+
+```yaml
+ MaxUnavailable: 0
+```
+The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
+
+### MaxSurge
+
+```yaml
+MaxSurge: 1
+```
+The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count.
+The default value of "MaxSurge: " is 25%.
+
+### Min Ready Seconds
+
+```yaml
+MinReadySeconds: 60
+```
+This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
+
+### Readiness Probe
+
+If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
+
+```yaml
+ReadinessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the readiness needs to be checked. |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for readiness. |
+| `periodSeconds` | It defines the time to check a given container for readiness. |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the readiness probe. |
+| `timeoutSeconds` | It defines the time for checking timeout. |
+| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as ready. |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+### Ambassador Mappings
+
+You can create ambassador mappings to access your applications from outside the cluster. At its core a Mapping resource maps a resource to a service.
+
+```yaml
+ambassadorMapping:
+ ambassadorId: "prod-emissary"
+ cors: {}
+ enabled: true
+ hostname: devtron.example.com
+ labels: {}
+ prefix: /
+ retryPolicy: {}
+ rewrite: ""
+ tls:
+ context: "devtron-tls-context"
+ create: false
+ hosts: []
+ secretName: ""
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable ambassador mapping else set false.|
+| `ambassadorId` | used to specify id for specific ambassador mappings controller. |
+| `cors` | used to specify cors policy to access host for this mapping. |
+| `weight` | used to specify weight for canary ambassador mappings. |
+| `hostname` | used to specify hostname for ambassador mapping. |
+| `prefix` | used to specify path for ambassador mapping. |
+| `labels` | used to provide custom labels for ambassador mapping. |
+| `retryPolicy` | used to specify retry policy for ambassador mapping. |
+| `corsPolicy` | Provide cors headers on flagger resource. |
+| `rewrite` | used to specify whether to redirect the path of this mapping and where. |
+| `tls` | used to create or define ambassador TLSContext resource. |
+| `extraSpec` | used to provide extra spec values which not present in deployment template for ambassador resource. |
+
+### Autoscaling
+
+This is connected to HPA and controls scaling up and down in response to request load.
+
+```yaml
+autoscaling:
+ enabled: false
+ MinReplicas: 1
+ MaxReplicas: 2
+ TargetCPUUtilizationPercentage: 90
+ TargetMemoryUtilizationPercentage: 80
+ extraMetrics: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable autoscaling else set false.|
+| `MinReplicas` | Minimum number of replicas allowed for scaling. |
+| `MaxReplicas` | Maximum number of replicas allowed for scaling. |
+| `TargetCPUUtilizationPercentage` | The target CPU utilization that is expected for a container. |
+| `TargetMemoryUtilizationPercentage` | The target memory utilization that is expected for a container. |
+| `extraMetrics` | Used to give external metrics for autoscaling. |
+
+### Fullname Override
+
+```yaml
+fullnameOverride: app-name
+```
+`fullnameOverride` replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses `{app-name}-{environment-name}` as release fullname.
+
+### Image
+
+```yaml
+image:
+ pullPolicy: IfNotPresent
+```
+
+Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
+
+### imagePullSecrets
+
+`imagePullSecrets` contains the docker credentials that are used for accessing a registry.
+
+```yaml
+imagePullSecrets:
+ - regcred
+```
+regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry [https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) .
+
+### Ingress
+
+This allows public access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ className: nginx
+ annotations: {}
+ hosts:
+ - host: example1.com
+ paths:
+ - /example
+ - host: example2.com
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+Legacy deployment-template ingress format
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ path: ""
+ host: ""
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `path` | Path name |
+| `host` | Host name |
+| `tls` | It contains security details |
+
+### Ingress Internal
+
+This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
+
+```yaml
+ingressInternal:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ hosts:
+ - host: example1.com
+ paths:
+ - /example
+ - host: example2.com
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `path` | Path name |
+| `host` | Host name |
+| `tls` | It contains security details |
+
+### Init Containers
+```yaml
+initContainers:
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+
+ - name: nginx
+ image: nginx:1.14.2
+ securityContext:
+ privileged: true
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+```
+Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to `true`.
+
+### Istio
+
+Istio is a service mesh which simplifies observability, traffic management, security and much more with it's virtual services and gateways.
+
+```yaml
+istio:
+ enable: true
+ gateway:
+ annotations: {}
+ enabled: false
+ host: example.com
+ labels: {}
+ tls:
+ enabled: false
+ secretName: example-tls-secret
+ virtualService:
+ annotations: {}
+ enabled: false
+ gateways: []
+ hosts: []
+ http:
+ - corsPolicy:
+ allowCredentials: false
+ allowHeaders:
+ - x-some-header
+ allowMethods:
+ - GET
+ allowOrigin:
+ - example.com
+ maxAge: 24h
+ headers:
+ request:
+ add:
+ x-some-header: value
+ match:
+ - uri:
+ prefix: /v1
+ - uri:
+ prefix: /v2
+ retries:
+ attempts: 2
+ perTryTimeout: 3s
+ rewriteUri: /
+ route:
+ - destination:
+ host: service1
+ port: 80
+ timeout: 12s
+ - route:
+ - destination:
+ host: service2
+ labels: {}
+```
+
+| Key | Description |
+| :--- | :--- |
+| `istio` | Istio enablement. When `istio.enable` set to true, Istio would be enabled for the specified configurations |
+| `gateway` | Allowing external traffic to enter the service mesh through the specified configurations. |
+| `host` | The external domain through which traffic will be routed into the service mesh. |
+| `tls` | Traffic to and from the gateway should be encrypted using TLS. |
+| `secretName` | Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway. |
+| `virtualService` | Enables the definition of rules for how traffic should be routed to different services within the service mesh. |
+| `gateways` | Specifies the gateways to which the rules defined in the VirtualService apply. |
+| `hosts` | List of hosts (domains) to which this VirtualService is applied. |
+| `http` | Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies. |
+| `corsPolicy` | Cross-Origin Resource Sharing (CORS) policy configuration. |
+| `headers` | Additional headers to be added to the HTTP request. |
+| `match` | Conditions that need to be satisfied for this route to be used. |
+| `uri` | This specifies a match condition based on the URI of the incoming request. |
+| `prefix` | It specifies that the URI should have the specified prefix. |
+| `retries` | Retry configuration for failed requests. |
+| `attempts` | It specifies the number of retry attempts for failed requests. |
+| `perTryTimeout` | sets the timeout for each individual retry attempt. |
+| `rewriteUri` | Rewrites the URI of the incoming request. |
+| `route` | List of destination rules for routing traffic. |
+
+### Pause For Seconds Before Switch Active
+```yaml
+pauseForSecondsBeforeSwitchActive: 30
+```
+To wait for given period of time before switch active the container.
+
+### Resources
+
+These define minimum and maximum RAM and CPU available to the application.
+
+```yaml
+resources:
+ limits:
+ cpu: "1"
+ memory: "200Mi"
+ requests:
+ cpu: "0.10"
+ memory: "100Mi"
+```
+
+Resources are required to set CPU and memory usage.
+
+#### Limits
+
+Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
+
+#### Requests
+
+Requests are what the container is guaranteed to get.
+
+### Service
+
+This defines annotations and the type of service, optionally can define name also.
+
+```yaml
+ service:
+ type: ClusterIP
+ annotations: {}
+```
+
+### Volumes
+
+```yaml
+volumes:
+ - name: log-volume
+ emptyDir: {}
+ - name: logpv
+ persistentVolumeClaim:
+ claimName: logpvc
+```
+
+It is required when some values need to be read from or written to an external disk.
+
+### Volume Mounts
+
+```yaml
+volumeMounts:
+ - mountPath: /var/log/nginx/
+ name: log-volume
+ - mountPath: /mnt/logs
+ name: logpvc
+ subPath: employee
+```
+
+It is used to provide mounts to the volume.
+
+### Affinity and anti-affinity
+
+```yaml
+Spec:
+ Affinity:
+ Key:
+ Values:
+```
+
+Spec is used to define the desire state of the given container.
+
+Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
+
+Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
+
+#### Key
+
+Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+#### Values
+
+Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+### Tolerations
+
+```yaml
+tolerations:
+ - key: "key"
+ operator: "Equal"
+ value: "value"
+ effect: "NoSchedule|PreferNoSchedule|NoExecute(1.6 only)"
+```
+
+Taints are the opposite, they allow a node to repel a set of pods.
+
+A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
+
+Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
+
+### Arguments
+
+```yaml
+args:
+ enabled: false
+ value: []
+```
+
+This is used to give arguments to command.
+
+### Command
+
+```yaml
+command:
+ enabled: false
+ value: []
+```
+
+It contains the commands for the server.
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | To enable or disable the command. |
+| `value` | It contains the commands. |
+
+
+### Containers
+Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to `true`.
+
+```yaml
+ containers:
+ - name: nginx
+ image: nginx:1.14.2
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+```
+
+### Prometheus
+
+```yaml
+ prometheus:
+ release: monitoring
+```
+
+It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case.It describes the state of the prometheus.
+
+### rawYaml
+
+```yaml
+rawYaml:
+ - apiVersion: v1
+ kind: Service
+ metadata:
+ name: my-service
+ spec:
+ selector:
+ app: MyApp
+ ports:
+ - protocol: TCP
+ port: 80
+ targetPort: 9376
+ type: ClusterIP
+```
+Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
+
+### Grace Period
+
+```yaml
+GracePeriod: 30
+```
+Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the `GracePeriod`.
+
+A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
+
+There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
+
+
+### Server
+
+```yaml
+server:
+ deployment:
+ image_tag: 1-95a53
+ image: ""
+```
+
+It is used for providing server configurations.
+
+#### Deployment
+
+It gives the details for deployment.
+
+| Key | Description |
+| :--- | :--- |
+| `image_tag` | It is the image tag |
+| `image` | It is the URL of the image |
+
+### Service Monitor
+
+```yaml
+servicemonitor:
+ enabled: true
+ path: /abc
+ scheme: 'http'
+ interval: 30s
+ scrapeTimeout: 20s
+ metricRelabelings:
+ - sourceLabels: [namespace]
+ regex: '(.*)'
+ replacement: myapp
+ targetLabel: target_namespace
+```
+
+It gives the set of targets to be monitored.
+
+### Db Migration Config
+
+```yaml
+dbMigrationConfig:
+ enabled: false
+```
+
+It is used to configure database migration.
+
+
+### KEDA Autoscaling
+[KEDA](https://keda.sh) is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
+
+Example for autosccaling with KEDA using Prometheus metrics is given below:
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced:
+ restoreToOriginalReplicaCount: true
+ horizontalPodAutoscalerConfig:
+ behavior:
+ scaleDown:
+ stabilizationWindowSeconds: 300
+ policies:
+ - type: Percent
+ value: 100
+ periodSeconds: 15
+ triggers:
+ - type: prometheus
+ metadata:
+ serverAddress: http://:9090
+ metricName: http_request_total
+ query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy",}
+ threshold: "50"
+ triggerAuthentication:
+ enabled: false
+ name:
+ spec: {}
+ authenticationRef: {}
+```
+Example for autosccaling with KEDA based on kafka is given below :
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced: {}
+ triggers:
+ - type: kafka
+ metadata:
+ bootstrapServers: b-2.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-3.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-1.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092
+ topic: Orders-Service-ESP.info
+ lagThreshold: "100"
+ consumerGroup: oders-remove-delivered-packages
+ allowIdleConsumers: "true"
+ triggerAuthentication:
+ enabled: true
+ name: keda-trigger-auth-kafka-credential
+ spec:
+ secretTargetRef:
+ - parameter: sasl
+ name: keda-kafka-secrets
+ key: sasl
+ - parameter: username
+ name: keda-kafka-secrets
+ key: username
+ authenticationRef:
+ name: keda-trigger-auth-kafka-credential
+```
+### Winter-Soldier
+Winter Soldier can be used to
+- cleans up (delete) Kubernetes resources
+- reduce workload pods to 0
+
+**_NOTE:_** After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check [the main repo](https://github.com/devtron-labs/winter-soldier)
+
+Given below is template values you can give in winter-soldier:
+```yaml
+winterSoilder:
+ enable: false
+ apiVersion: pincher.devtron.ai/v1alpha1
+ action: sleep
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges: []
+ targetReplicas: []
+ fieldSelector: []
+```
+Here,
+| Key | values | Description |
+| :--- | :--- | :--- |
+| `enable` | `false`,`true` | decide the enabling factor |
+| `apiVersion` | `pincher.devtron.ai/v1beta1`, `pincher.devtron.ai/v1alpha1` | specific api version |
+| `action` | `sleep`,`delete`, `scale` | This specify the action need to perform. |
+| `timeRangesWithZone`:`timeZone` | eg:- `"Asia/Kolkata"`,`"US/Pacific"` | It use to specify the timeZone used. (It uses standard format. please refer [this](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)) |
+| `timeRangesWithZone`:`timeRanges` | array of [ `timeFrom`, `timeTo`, `weekdayFrom`, `weekdayTo`] | It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges. These settings will take `action` on Sat and Sun from 00:00 to 23:59:59, |
+| `targetReplicas` | `[n]` : n - number of replicas to scale. | These is mandatory field when the `action` is `scale` Default value is `[]`. |
+| `fieldSelector` | `- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now()) ` | These value will take a list of methods to select the resources on which we perform specified `action` . |
+
+
+here is an example,
+```yaml
+winterSoilder:
+ apiVersion: pincher.devtron.ai/v1alpha1
+ enable: true
+ annotations: {}
+ labels: {}
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges:
+ - timeFrom: 00:00
+ timeTo: 23:59:59
+ weekdayFrom: Sat
+ weekdayTo: Sun
+ - timeFrom: 00:00
+ timeTo: 08:00
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ - timeFrom: 20:00
+ timeTo: 23:59:59
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ action: scale
+ targetReplicas: [1,1,1]
+ fieldSelector:
+ - AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '10h'), Now())
+```
+Above settings will take action on `Sat` and `Sun` from 00:00 to 23:59:59, and on `Mon`-`Fri` from 00:00 to 08:00 and 20:00 to 23:59:59. If `action:sleep` then runs hibernate at timeFrom and unhibernate at `timeTo`. If `action: delete` then it will delete workloads at `timeFrom` and `timeTo`. Here the `action:scale` thus it scale the number of resource replicas to `targetReplicas: [1,1,1]`. Here each element of `targetReplicas` array is mapped with the corresponding elements of array `timeRangesWithZone/timeRanges`. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
+
+The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
+
+- ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use `ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')`
+- AddTime - This can be used to add time. For eg `AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h')` ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
+- Now - This can be used to get current time.
+- CpuToNumber - This can be used to compare CPU. For eg `any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')})` will check if any resource.requests is less than 60Mi.
+
+
+
+### Security Context
+A security context defines privilege and access control settings for a Pod or Container.
+
+To add a security context for main container:
+```yaml
+containerSecurityContext:
+ allowPrivilegeEscalation: false
+```
+
+To add a security context on pod level:
+```yaml
+podSecurityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+```
+
+### Topology Spread Constraints
+You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
+
+```yaml
+topologySpreadConstraints:
+ - maxSkew: 1
+ topologyKey: zone
+ whenUnsatisfiable: DoNotSchedule
+ autoLabelSelector: true
+ customLabelSelector: {}
+```
+
+### Deployment Metrics
+
+It gives the realtime metrics of the deployed applications
+
+| Key | Description |
+| :--- | :--- |
+| `Deployment Frequency` | It shows how often this app is deployed to production |
+| `Change Failure Rate` | It shows how often the respective pipeline fails. |
+| `Mean Lead Time` | It shows the average time taken to deliver a change to production. |
+| `Mean Time to Recovery` | It shows the average time taken to fix a failed pipeline. |
+
+## 2. Show application metrics
+
+If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
+
+
+
Figure 3: Application Metrics
+
+Once all the Deployment template configurations are done, click on `Save` to save your deployment configuration. Now you are ready to create [Workflow](../../workflow/README.md) to do CI/CD.
+
+### Helm Chart Json Schema
+
+Helm Chart [json schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_5-1-0/schema.json) is used to validate the deployment template values.
+
+### Other Validations in Json Schema
+
+The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
+```
+resources.limits.cpu >= resources.requests.cpu
+resources.limits.memory >= resources.requests.memory
+envoyproxy.resources.limits.cpu >= envoyproxy.resources.requests.cpu
+envoyproxy.resources.limits.memory >= envoyproxy.resources.requests.memory
+```
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/deployment-template.md b/docs/user-guide/creating-application/base-config/deployment-template.md
old mode 100644
new mode 100755
index e8d1fd7f03..c0bcefeed7
--- a/docs/user-guide/creating-application/base-config/deployment-template.md
+++ b/docs/user-guide/creating-application/base-config/deployment-template.md
@@ -2,7 +2,8 @@
## Introduction
-
+
+
Figure 1: Deployment Template
In Devtron, a [Deployment Template](../../../reference/glossary.md#deployment-template) defines how your application should run by defining its specifications. Devtron uses [Helm charts](../../../reference/glossary.md#helm-chartspackages) to manage these deployments, allowing you to control everything from [Resource Allocation](../../../reference/glossary.md#resource-allocation) to environment variables.
@@ -20,77 +21,71 @@ This guide covers how to:
* [Perform a Dry Run](#perform-a-dry-run)
-* [Extra: Edit a Protected Deployment Configuration](#edit-a-protected-deployment-template) [](https://devtron.ai/pricing)
+* [Extra: Edit a Protected Deployment Configuration](#edit-a-protected-deployment-template-)
---
## Select a Deployment Chart Type
-{% hint style="warning" %}
+:::caution Who Can Perform This Action?
+Users need to have [Admin role](../../../user-guide/global-configurations/authorization/user-access.md#roles-available-for-devtron-apps) or above to select a chart.
-### Who Can Perform This Action?
-
-Users need to have [Admin role](../../../user-guide/global-configurations/user-access.md#role-based-access-levels) or above to select a chart.
-
-{% endhint %}
+:::
1. Go to the **Configurations** page of your application.
- 
+ 
+
Figure 2: Application's 'Configurations' Page
2. Click **Base Configuration** → **Deployment Template**.
- 
+ 
+
Figure 3: Navigating to Base Configurations
3. Select the **Chart** drop-down box. The following tabs are displayed:
- * [Charts by Devtron](./deployment-template/README.md) - Displays the default deployment charts provided by Devtron
+ * [Charts by Devtron](./deployment-template-types/README.md) - Displays the default deployment charts provided by Devtron
* [Custom charts](../../global-configurations/deployment-charts.md) - Displays your custom deployment charts (if available). To create a custom deployment chart, refer to [Deployment Charts](../../global-configurations/deployment-charts.md).
- 
-
- 
-
-{% hint style="danger" %}
+ 
+
Figure 4a: Charts by Devtron
-### Important Note
+ 
+
Figure 4b: Custom Charts
+:::danger Important Note
After you select and save a chart type for a given application, you won't be able to change it later. Make sure to choose the correct chart type before saving.
-{% endhint %}
+:::
---
## Choose a Chart Version
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
+:::caution Who Can Perform This Action?
Users need to have [Admin role](../../../user-guide/global-configurations/authorization/user-access.md#roles-available-for-devtron-apps) or above to select a chart version.
-{% endhint %}
+:::
Devtron maintains multiple chart versions for each chart type. Additionally, each chart version has a supporting README file that you can use to know more about the features and variables.
-
+
+
Figure 5: Accessing the README file
Once you [select a deployment chart](#select-a-deployment-chart-type), choose a chart version with which you wish to deploy your application from the **Version** drop-down box. By default, the latest version of the helm chart is selected.
-
+
+
Figure 6: Choosing the Chart Version
---
## Configure the Deployment Template
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
+:::caution Who Can Perform This Action?
Users need to have [Admin role](../../../user-guide/global-configurations/authorization/user-access.md#roles-available-for-devtron-apps) or above to configure a deployment template. However, super-admins can lock keys in deployment template to prevent non-super-admins from modifying them. Refer [Lock Deployment Configuration](../../global-configurations/lock-deployment-config.md) to know more.
-{% endhint %}
+:::
You can edit a deployment template using the following two ways:
@@ -102,7 +97,8 @@ You can edit a deployment template using the following two ways:
If you prefer to use a simple way to configure your chosen deployment chart, select **GUI**.
-
+
+
Figure 7: GUI Option
By default, the following fields are commonly available for you to modify in the **GUI** section of most charts:
@@ -129,27 +125,22 @@ By default, the following fields are commonly available for you to modify in the
If you wish to perform additional configurations, click the **Switch to Advanced** button or **YAML** button. Or [perform a dry run](#perform-a-dry-run) before saving your configuration.
-
-
-{% hint style="info" %}
-
-### Note
+
+
Figure 8: Switch to Advanced (YAML Method)
+:::info Note
* If you change any values in the **GUI**, then the corresponding values will change in **YAML** too.
* Users who are not super-admins will land on **GUI** section when they visit **Deployment Template** page; whereas super-admins will land on **YAML** section. This is just a default behavior, they can still navigate to the other section if needed.
-{% endhint %}
+:::
-#### Customize the GUI [](https://devtron.ai/pricing)
+#### Customize the GUI
-{% hint style="warning" %}
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../../global-configurations/authorization/user-access.md#grant-super-admin-permission) can customize the GUI section.
-### Who Can Perform This Action?
-
-Only a [Super-Admin](../../global-configurations/user-access.md#assign-super-admin-permissions) can customize the GUI section.
-
-{% endhint %}
+:::
By default, the **GUI** section comes with multiple predefined fields as seen earlier [in the table](#using-gui). However, if you wish to display a different set of fields to your team, you can modify the whole section as per your requirement.
@@ -165,11 +156,11 @@ This is useful in scenarios where:
There are two ways you can customize the GUI, use any one of the following:
-1. From [Deployment Charts](../../global-configurations/deployment-charts.md#editing-gui-schema-of-deployment-charts) section
+1. From [Deployment Charts](../../global-configurations/deployment-charts.md#editing-gui-schema-of-deployment-charts-) section
2. Using APIs (explained below)
-{% embed url="https://www.youtube.com/watch?v=09VP1I-WvUs" caption="JSON-driven Deployment Schema" %}
+
You can pass a custom JSON (deployment schema) of your choice through the following API. You may need to run the API with the `POST` method if you are doing it for the first time.
@@ -177,9 +168,7 @@ You can pass a custom JSON (deployment schema) of your choice through the follow
PUT {{DEVTRON_BASEURL}}/orchestrator/deployment/template/schema
```
-{% code title="Sample API Request Body" overflow="wrap" lineNumbers="true" %}
-
-```json
+```json title="Sample API Request Body" showLineNumbers
{
"name": "schema-1",
"type": "JSON",
@@ -229,7 +218,7 @@ PUT {{DEVTRON_BASEURL}}/orchestrator/deployment/template/schema
}
```
-{% endcode %}
+
1. In the `name` field, give a name to your schema, e.g., *schema-1*
@@ -261,19 +250,20 @@ PUT {{DEVTRON_BASEURL}}/orchestrator/deployment/template/schema
If you prefer to perform additional configurations in your chosen deployment template, select **YAML**.
-
+
+
Figure 9: YAML Option
Every chart version has its own YAML file that provides specifications for your application. To make it easy to use, we have created templates for the YAML file and added some variables inside the YAML. You can provide or change the values of these variables as per your requirement.
Refer the respective templates to view the YAML details.
-* [Deployment](./deployment-template/deployment.md)
+* [Deployment](./deployment-template-types/deployment.md)
-* [Rollout Deployment](./deployment-template/rollout-deployment.md)
+* [Rollout Deployment](./deployment-template-types/rollout-deployment.md)
-* [Job & CronJob](./deployment-template/job-and-cronjob.md)
+* [Job & CronJob](./deployment-template-types/job-and-cronjob.md)
-* [StatefulSet](./deployment-template/statefulset.md)
+* [StatefulSet](./deployment-template-types/statefulset.md)
Before saving your configuration in YAML, make sure to [perform a dry run](#perform-a-dry-run).
@@ -290,19 +280,17 @@ The availability of application metrics depends on the selected chart type and v
To enable this, turn on the **Show application metrics** toggle.
-
+
+
Figure 10: Enabling Application Metrics
Once enabled, you can view the application metrics on the **App Details** page.
-
-
-{% hint style="info" %}
-
-### Important
+
+
Figure 11: Application metrics on 'App Details' page
+:::info Important
Enabling application metrics adds a sidecar container to your main container, which may require additional configuration. We recommend running a load test in a non-production environment before enabling it in production.
-
-{% endhint %}
+:::
---
@@ -312,51 +300,43 @@ Before saving your configured deployment template, you can use the **Dry Run** o
This feature helps you verify your configurations, detect issues, and ensure correctness before actual deployment.
-
+
+
Figure 12: Show application metrics
Your configurations will appear in the left pane, while the right pane will display a section named `Manifest generated from merged` showing the computed Kubernetes manifests, each representing a separate resource after merging all your changes.
---
-## Edit a Protected Deployment Template [](https://devtron.ai/pricing)
-
-{% hint style="info" %}
-
-### Who Can Perform This Action?
+## Edit a Protected Deployment Template
+:::info Who Can Perform This Action?
Only a super-admin, manager, and admin can edit the configuration values.
-{% endhint %}
+:::
Any changes made to the deployment template will require approval if an approval policy is enforced. To check if your deployment template is protected, check the stamp/approve symbol as shown below.
-
+
+
Figure 13: Checking Protected Configuration
-When you want to edit a protected configuration, you can do it in the following ways:
-
-* [Normal Edit](#normal-edit) - Where changes to the protected configuration can be proposed or pushed as a draft, but published only after getting approval from the approver(s).
-
-* [Express Edit](#express-edit) - Where you bypass the approval process and directly make changes to the protected configuration.
-
-### Normal Edit
+### Request Approval for Changes
Let's assume you are the application admin and your deployment template in **Base Configurations** is protected from edits.
1. In the YAML editor of the deployment template, modify the values.
- 
+ 
+
Figure 14: Selecting Values to Change
2. You can change the value of a key to a desired value as shown below. Once done, click the **Save Changes** button.
- 
-
-{% hint style="info" %}
-
-### What if the keys are locked from editing?
+ 
+
Figure 15: Changing Values
+:::info What if the keys are locked from editing?
You cannot modify locked keys in deployment template unless you are a super-admin. Refer [Lock Deployment Configuration](../../global-configurations/lock-deployment-config.md) to know more.
-{% endhint %}
+:::
3. Since the deployment configuration is protected, your changes won't be published right away. You can do either of the following:
@@ -366,82 +346,37 @@ You cannot modify locked keys in deployment template unless you are a super-admi
Since we are proposing the changes immediately, click **Propose Changes**.
- 
+ 
+
Figure 16: Proposing Changes
4. You can also view the approval status if you wish.
- 
-
-{% hint style="info" %}
-
-### Can I approve my own changes?
+ 
+
Figure 17: Viewing the Approval Status
+:::info Can I approve my own changes?
No, the one who performs the edits cannot approve their own changes. A different user has to review and approve.
-{% endhint %}
+:::
Only one draft can exist at time and you cannot create multiple drafts. In the top-right corner, you have the option to discard the draft if you don't wish to proceed with the edits you made.
-
-
-### Express Edit
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
-Only a Super-Admin (when the [Super admins toggle](../../global-configurations/approval-policy.md#excluding-super-admins) is enabled in the Exceptions tab) or [specific users / user groups](../../global-configurations/approval-policy.md#excluding-specific-users-user-groups-api-tokens) who are added as exceptions in the Approval Policy can make express edits. Refer to [Approval Policy](../../global-configurations/approval-policy.md) for more information.
-
-{% endhint %}
-
-Express edits allow you to bypass the approval process and make direct edits to the configurations. Follow the below steps to make express edits:
-
-1. Navigate to the **Applications** page and click on your preferred application.
-
-2. Go to the **Configurations** → **Base Configurations**.
-
-3. Click on **Deployment Template**.
-
-4. Click on the **Edit** button.
-
-{% hint style="info" %}
-
-### Note
-
-The **Edit** button will only be displayed if:
-
-* You are a Super-Admin and the Super admins toggle is enabled in the Approval Policy page
-
-* You are added as an exception in the Approval Policy page.
-
-Refer to [Approval Policy](../../global-configurations/approval-policy.md) for more information.
-
-{% endhint %}
-
-5. Modify the values either by using **GUI** or **YAML** editor.
-
-6. Click on **Publish Changes** to direcly publish your changes.
-
-
+
+
Figure 18: Discarding the Draft
### Grant Approval for Changes
-{% hint style="info" %}
-
-### Who Can Perform This Action?
-
+:::info Who Can Perform This Action?
Only a valid approver or a Super-Admin can approve the changes made to the deployment configuration. Refer to [Approval Policy](../../global-configurations/approval-policy.md) for more information.
-{% endhint %}
+:::
Go to the edited configuration file to review and approve the changes as shown below.
-
-
-{% hint style="info" %}
-
-### Note
+
+
Figure 19: Approving the Changes
+:::info Note
If [SES/SMTP](../../global-configurations/manage-notification.md) is configured in Devtron, the approver gets notified via email. Therefore, the approver can take an action directly from the mail as shown below. Once the approver validates and approves your configuration changes, you can proceed to deploy your application with the updated configuration.
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/deployment-template/README.md b/docs/user-guide/creating-application/base-config/deployment-template/README.md
deleted file mode 100644
index 578a2c88e4..0000000000
--- a/docs/user-guide/creating-application/base-config/deployment-template/README.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# Types of Deployment Templates
-
-In Devtron, the following deployment charts are available for you to use for your application:
-
-* [Deployment](deployment.md)
-* [Rollout Deployment](rollout-deployment.md)
-* [Job and Cronjob](job-and-cronjob.md)
-* [StatefulSets](statefulset.md)
-
-
-
-Each template serves a specific purpose; therefore, choose one based on your application’s requirements.
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/deployment-template/deployment.md b/docs/user-guide/creating-application/base-config/deployment-template/deployment.md
deleted file mode 100644
index dc3672b0f2..0000000000
--- a/docs/user-guide/creating-application/base-config/deployment-template/deployment.md
+++ /dev/null
@@ -1,1140 +0,0 @@
-# Deployment
-
-This chart creates a deployment that runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive. It does not support Blue/Green and Canary deployments. This is the default deployment chart. You can select `Deployment` chart when you want to use only basic use cases which contain the following:
-
-* Create a Deployment to rollout a ReplicaSet. The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
-* Declare the new state of the Pods. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
-* Rollback to an earlier Deployment revision if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
-* Scale up the Deployment to facilitate more load.
-* Use the status of the Deployment as an indicator that a rollout has stuck.
-* Clean up older ReplicaSets that you do not need anymore.
-
-
-
-You can define application behavior by providing information in the following sections:
-
-| Key | Descriptions |
-| :--- | :--- |
-| `Chart version` | Select the Chart Version using which you want to deploy the application. Refer [Chart Version](../../../creating-application/base-config/deployment-template.md#choose-a-chart-version) section for more detail. |
-| `GUI` | You can perform a basic deployment configuration for your application in the **GUI** section instead of configuring the YAML file. Refer [Basic Configuration](../../../creating-application/base-config/deployment-template.md#using-gui) section for more detail.|
-| `YAML` | If you want to do additional configurations, then click **YAML** for modifications. Refer [YAML](#yaml) section for more detail. |
-| `Show application metrics` | You can enable `Show application metrics` to see your application's metrics-CPU Service Monitor usage, Memory Usage, Status, Throughput and Latency. Refer [Application Metrics](../../../creating-application/app-metrics.md) for more detail. |
-
-
-{% hint style="warning" %}
-### Note
-Super-admins can lock keys in deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
-{% endhint %}
-
-
-
----
-
-## YAML
-
-### Container Ports
-
-This defines ports on which application services will be exposed to other services
-
-```yaml
-ContainerPort:
- - envoyPort: 8799
- idleTimeout:
- name: app
- port: 8080
- servicePort: 80
- nodePort: 32056
- supportStreaming: true
- useHTTP2: true
-```
-
-| Key | Description |
-| :--- | :--- |
-| `envoyPort` | envoy port for the container |
-| `idleTimeout` | the duration of time that a connection is idle before the connection is terminated |
-| `name` | name of the port |
-| `port` | port for the container |
-| `servicePort` | port of the corresponding kubernetes service |
-| `nodePort` | nodeport of the corresponding kubernetes service |
-| `supportStreaming` | Used for high performance protocols like grpc where timeout needs to be disabled |
-| `useHTTP2` | Envoy container can accept HTTP2 requests |
-
-### EnvVariables
-```yaml
-EnvVariables: []
-```
-To set environment variables for the containers that run in the Pod.
-
-### EnvVariablesFromFieldPath
-```yaml
-EnvVariablesFromFieldPath:
-- name: ENV_NAME
- fieldPath: status.podIP (example)
-```
-To set environment variables for the containers and fetching their values from pod-level fields.
-
-### Liveness Probe
-
-If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
-
-```yaml
-LivenessProbe:
- Path: ""
- port: 8080
- initialDelaySeconds: 20
- periodSeconds: 10
- successThreshold: 1
- timeoutSeconds: 5
- failureThreshold: 3
- httpHeaders:
- - name: Custom-Header
- value: abc
- scheme: ""
- tcp: true
-```
-
-| Key | Description |
-| :--- | :--- |
-| `Path` | It define the path where the liveness needs to be checked |
-| `initialDelaySeconds` | It defines the time to wait before a given container is checked for liveliness |
-| `periodSeconds` | It defines the time to check a given container for liveness |
-| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the liveness probe |
-| `timeoutSeconds` | It defines the time for checking timeout |
-| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as live |
-| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers, you can override the default headers by defining .httpHeaders for the probe. |
-| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
-| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
-
-
-### MaxUnavailable
-
-```yaml
- MaxUnavailable: 0
-```
-The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
-
-### MaxSurge
-
-```yaml
-MaxSurge: 1
-```
-The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count.
-The default value of "MaxSurge: " is 25%.
-
-### Min Ready Seconds
-
-```yaml
-MinReadySeconds: 60
-```
-This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
-
-### Readiness Probe
-
-If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
-
-```yaml
-ReadinessProbe:
- Path: ""
- port: 8080
- initialDelaySeconds: 20
- periodSeconds: 10
- successThreshold: 1
- timeoutSeconds: 5
- failureThreshold: 3
- httpHeaders:
- - name: Custom-Header
- value: abc
- scheme: ""
- tcp: true
-```
-
-| Key | Description |
-| :--- | :--- |
-| `Path` | It define the path where the readiness needs to be checked |
-| `initialDelaySeconds` | It defines the time to wait before a given container is checked for readiness |
-| `periodSeconds` | It defines the time to check a given container for readiness |
-| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the readiness probe |
-| `timeoutSeconds` | It defines the time for checking timeout |
-| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as ready |
-| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers, you can override the default headers by defining .httpHeaders for the probe. |
-| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
-| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
-
-### Pod Disruption Budget
-
-You can create `PodDisruptionBudget` for each application. A PDB limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, an application would like to ensure the number of replicas running is never brought below the certain number.
-
-```yaml
-podDisruptionBudget:
- minAvailable: 1
-```
-
-or
-
-```yaml
-podDisruptionBudget:
- maxUnavailable: 50%
-```
-
-You can specify either `maxUnavailable` or `minAvailable` in a PodDisruptionBudget and it can be expressed as integers or as a percentage.
-
-| Key | Description |
-| :--- | :--- |
-| `minAvailable` | Evictions are allowed as long as they leave behind 1 or more healthy pods of the total number of desired replicas. |
-| `maxUnavailable` | Evictions are allowed as long as at most 1 unhealthy replica among the total number of desired replicas. |
-
-### Ambassador Mappings
-
-You can create ambassador mappings to access your applications from outside the cluster. At its core a Mapping resource maps a resource to a service.
-
-```yaml
-ambassadorMapping:
- ambassadorId: "prod-emissary"
- cors: {}
- enabled: true
- hostname: devtron.example.com
- labels: {}
- prefix: /
- retryPolicy: {}
- rewrite: ""
- tls:
- context: "devtron-tls-context"
- create: false
- hosts: []
- secretName: ""
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Set true to enable ambassador mapping else set false|
-| `ambassadorId` | used to specify id for specific ambassador mappings controller |
-| `cors` | used to specify cors policy to access host for this mapping |
-| `weight` | used to specify weight for canary ambassador mappings |
-| `hostname` | used to specify hostname for ambassador mapping |
-| `prefix` | used to specify path for ambassador mapping |
-| `labels` | used to provide custom labels for ambassador mapping |
-| `retryPolicy` | used to specify retry policy for ambassador mapping |
-| `corsPolicy` | Provide cors headers on flagger resource |
-| `rewrite` | used to specify whether to redirect the path of this mapping and where |
-| `tls` | used to create or define ambassador TLSContext resource |
-| `extraSpec` | used to provide extra spec values which not present in deployment template for ambassador resource |
-
-### Autoscaling
-
-This is connected to HPA and controls scaling up and down in response to request load.
-
-```yaml
-autoscaling:
- enabled: false
- MinReplicas: 1
- MaxReplicas: 2
- TargetCPUUtilizationPercentage: 90
- TargetMemoryUtilizationPercentage: 80
- extraMetrics: []
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Set true to enable autoscaling else set false |
-| `MinReplicas` | Minimum number of replicas allowed for scaling |
-| `MaxReplicas` | Maximum number of replicas allowed for scaling |
-| `TargetCPUUtilizationPercentage` | The target CPU utilization that is expected for a container |
-| `TargetMemoryUtilizationPercentage` | The target memory utilization that is expected for a container |
-| `extraMetrics` | Used to give external metrics for autoscaling |
-
-### Flagger
-
-You can use flagger for canary releases with deployment objects. It supports flexible traffic routing with istio service mesh as well.
-
-```yaml
-flaggerCanary:
- addOtherGateways: []
- addOtherHosts: []
- analysis:
- interval: 15s
- maxWeight: 50
- stepWeight: 5
- threshold: 5
- annotations: {}
- appProtocol: http
- corsPolicy:
- allowCredentials: false
- allowHeaders:
- - x-some-header
- allowMethods:
- - GET
- allowOrigin:
- - example.com
- maxAge: 24h
- createIstioGateway:
- annotations: {}
- enabled: false
- host: example.com
- labels: {}
- tls:
- enabled: false
- secretName: example-tls-secret
- enabled: false
- gatewayRefs: null
- headers:
- request:
- add:
- x-some-header: value
- labels: {}
- loadtest:
- enabled: true
- url: http://flagger-loadtester.istio-system/
- match:
- - uri:
- prefix: /
- port: 8080
- portDiscovery: true
- retries: null
- rewriteUri: /
- targetPort: 8080
- thresholds:
- latency: 500
- successRate: 90
- timeout: null
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Set true to enable canary releases using flagger else set false |
-| `addOtherGateways` | To provide multiple istio gateways for flagger |
-| `addOtherHosts` | Add multiple hosts for istio service mesh with flagger |
-| `analysis` | Define how the canary release should progress and at what interval |
-| `annotations` | Annotation to add on flagger resource |
-| `labels` | Labels to add on flagger resource |
-| `appProtocol` | Protocol to use for canary |
-| `corsPolicy` | Provide cors headers on flagger resource |
-| `createIstioGateway` | Set to true if you want to create istio gateway as well with flagger |
-| `headers` | Add headers if any |
-| `loadtest` | Enable load testing for your canary release |
-
-
-
-### Fullname Override
-
-```yaml
-fullnameOverride: app-name
-```
-`fullnameOverride` replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses {app-name}-{environment-name} as release fullname.
-
-### Image
-
-```yaml
-image:
- pullPolicy: IfNotPresent
-```
-
-Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
-
-### imagePullSecrets
-
-`imagePullSecrets` contains the docker credentials that are used for accessing a registry.
-
-```yaml
-imagePullSecrets:
- - regcred
-```
-regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry [https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) .
-
-### serviceAccount
-
-```yaml
-serviceAccount:
- create: false
- name: ""
- annotations: {}
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Determines whether to create a ServiceAccount for pods or not. If set to `true`, a ServiceAccount will be created. |
-| `name` | Specifies the name of the ServiceAccount to use. |
-| `annotations` | Specify annotations for the ServiceAccount. |
-
-### HostAliases
-
- the hostAliases field is used in a Pod specification to associate additional hostnames with the Pod's IP address. This can be helpful in scenarios where you need to resolve specific hostnames to the Pod's IP within the Pod itself.
-
-```yaml
- hostAliases:
- - ip: "192.168.1.10"
- hostnames:
- - "hostname1.example.com"
- - "hostname2.example.com"
- - ip: "192.168.1.11"
- hostnames:
- - "hostname3.example.com"
-```
-
-### Ingress
-
-This allows public access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
-
-```yaml
-ingress:
- enabled: false
- # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
- className: nginx
- annotations: {}
- hosts:
- - host: example1.com
- paths:
- - /example
- - host: example2.com
- paths:
- - /example2
- - /example2/healthz
- tls: []
-```
-Legacy deployment-template ingress format
-
-```yaml
-ingress:
- enabled: false
- # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
- ingressClassName: nginx-internal
- annotations: {}
- path: ""
- host: ""
- tls: []
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Enable or disable ingress |
-| `annotations` | To configure some options depending on the Ingress controller |
-| `path` | Path name |
-| `host` | Host name |
-| `tls` | It contains security details |
-
-### Ingress Internal
-
-This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
-
-```yaml
-ingressInternal:
- enabled: false
- # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
- ingressClassName: nginx-internal
- annotations: {}
- hosts:
- - host: example1.com
- paths:
- - /example
- - host: example2.com
- paths:
- - /example2
- - /example2/healthz
- tls: []
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Enable or disable ingress |
-| `annotations` | To configure some options depending on the Ingress controller |
-| `path` | Path name |
-| `host` | Host name |
-| `tls` | It contains security details |
-
-### Init Containers
-```yaml
-initContainers:
- - reuseContainerImage: true
- securityContext:
- runAsUser: 1000
- runAsGroup: 3000
- fsGroup: 2000
- volumeMounts:
- - mountPath: /etc/ls-oms
- name: ls-oms-cm-vol
- command:
- - flyway
- - -configFiles=/etc/ls-oms/flyway.conf
- - migrate
-
- - name: nginx
- image: nginx:1.14.2
- securityContext:
- privileged: true
- ports:
- - containerPort: 80
- command: ["/usr/local/bin/nginx"]
- args: ["-g", "daemon off;"]
-```
-Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to `true`.
-
-### Pause For Seconds Before Switch Active
-```yaml
-pauseForSecondsBeforeSwitchActive: 30
-```
-To wait for given period of time before switch active the container.
-
-### Resources
-
-These define minimum and maximum RAM and CPU available to the application.
-
-```yaml
-resources:
- limits:
- cpu: "1"
- memory: "200Mi"
- requests:
- cpu: "0.10"
- memory: "100Mi"
-```
-
-Resources are required to set CPU and memory usage.
-
-#### Limits
-
-Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
-
-#### Requests
-
-Requests are what the container is guaranteed to get.
-
-### Service
-
-This defines annotations and the type of service, optionally can define name also.
-
-```yaml
- service:
- type: ClusterIP
- annotations: {}
-```
-
-### Volumes
-
-```yaml
-volumes:
- - name: log-volume
- emptyDir: {}
- - name: logpv
- persistentVolumeClaim:
- claimName: logpvc
-```
-
-It is required when some values need to be read from or written to an external disk.
-
-### Volume Mounts
-
-```yaml
-volumeMounts:
- - mountPath: /var/log/nginx/
- name: log-volume
- - mountPath: /mnt/logs
- name: logpvc
- subPath: employee
-```
-
-It is used to provide mounts to the volume.
-
-### Affinity and anti-affinity
-
-```yaml
-Spec:
- Affinity:
- Key:
- Values:
-```
-
-Spec is used to define the desire state of the given container.
-
-Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
-
-Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
-
-#### Key
-
-Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
-
-#### Values
-
-Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
-
-### Tolerations
-
-```yaml
-tolerations:
- - key: "key"
- operator: "Equal"
- value: "value"
- effect: "NoSchedule|PreferNoSchedule|NoExecute(1.6 only)"
-```
-
-Taints are the opposite, they allow a node to repel a set of pods.
-
-A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
-
-Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
-
-### Arguments
-
-```yaml
-args:
- enabled: false
- value: []
-```
-
-This is used to give arguments to command.
-
-### Command
-
-```yaml
-command:
- enabled: false
- value: []
-```
-
-It contains the commands for the server.
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | To enable or disable the command |
-| `value` | It contains the commands |
-
-
-### Containers
-Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to `true`.
-
-```yaml
- containers:
- - name: nginx
- image: nginx:1.14.2
- ports:
- - containerPort: 80
- command: ["/usr/local/bin/nginx"]
- args: ["-g", "daemon off;"]
- - reuseContainerImage: true
- securityContext:
- runAsUser: 1000
- runAsGroup: 3000
- fsGroup: 2000
- volumeMounts:
- - mountPath: /etc/ls-oms
- name: ls-oms-cm-vol
- command:
- - flyway
- - -configFiles=/etc/ls-oms/flyway.conf
- - migrate
-```
-
-### Container Lifecycle Hooks
-
-Container lifecycle hooks are mechanisms that allow users to define custom actions to be performed at specific stages of a container's lifecycle i.e. PostStart or PreStop.
-
-```yaml
-containerSpec:
- lifecycle:
- enabled: false
- postStart:
- httpGet:
- host: example.com
- path: /example
- port: 90
- preStop:
- exec:
- command:
- - sleep
- - "10"
-```
-
-| Key | Description |
-| :--- | :--- |
-| `containerSpec` | containerSpec to define container lifecycle hooks configuration |
-| `lifecycle` | Lifecycle hooks for the container |
-| `enabled` | Set true to enable lifecycle hooks for the container else set false |
-| `postStart` | The postStart hook is executed immediately after a container is created |
-| `httpsGet` | Sends an HTTP GET request to a specific endpoint on the container |
-| `host` | Specifies the host (example.com) to which the HTTP GET request will be sent |
-| `path` | Specifies the path (/example) of the endpoint to which the HTTP GET request will be sent |
-| `port` | Specifies the port (90) on the host where the HTTP GET request will be sent |
-| `preStop` | The preStop hook is executed just before the container is stopped |
-| `exec` | Executes a specific command, such as pre-stop.sh, inside the cgroups and namespaces of the container |
-| `command` | The command to be executed is sleep 10, which tells the container to sleep for 10 seconds before it is stopped |
-
-### Prometheus
-
-```yaml
- prometheus:
- release: monitoring
-```
-
-It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case. It describes the state of the Prometheus.
-
-### rawYaml
-
-```yaml
-rawYaml:
- - apiVersion: v1
- kind: Service
- metadata:
- name: my-service
- spec:
- selector:
- app: MyApp
- ports:
- - protocol: TCP
- port: 80
- targetPort: 9376
- type: ClusterIP
-```
-Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
-
-### Grace Period
-
-```yaml
-GracePeriod: 30
-```
-Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the `GracePeriod`.
-
-A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
-
-There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
-
-
-### Server
-
-```yaml
-server:
- deployment:
- image_tag: 1-95a53
- image: ""
-```
-
-It is used for providing server configurations.
-
-#### Deployment
-
-It gives the details for deployment.
-
-| Key | Description |
-| :--- | :--- |
-| `image_tag` | It is the image tag |
-| `image` | It is the URL of the image |
-
-### Service Monitor
-
-```yaml
-servicemonitor:
- enabled: true
- path: /abc
- scheme: 'http'
- interval: 30s
- scrapeTimeout: 20s
- metricRelabelings:
- - sourceLabels: [namespace]
- regex: '(.*)'
- replacement: myapp
- targetLabel: target_namespace
-```
-
-It gives the set of targets to be monitored.
-
-### Db Migration Config
-
-```yaml
-dbMigrationConfig:
- enabled: false
-```
-
-It is used to configure database migration.
-
-### Istio
-
-These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
-
-```yaml
-istio:
- enable: true
-
- gateway:
- enabled: true
- labels:
- app: my-gateway
- annotations:
- description: "Istio Gateway for external traffic"
- host: "example.com"
- tls:
- enabled: true
- secretName: my-tls-secret
-
- virtualService:
- enabled: true
- labels:
- app: my-service
- annotations:
- description: "Istio VirtualService for routing"
- gateways:
- - my-gateway
- hosts:
- - "example.com"
- http:
- - match:
- - uri:
- prefix: /v1
- route:
- - destination:
- host: my-service-v1
- subset: version-1
- - match:
- - uri:
- prefix: /v2
- route:
- - destination:
- host: my-service-v2
- subset: version-2
-
- destinationRule:
- enabled: true
- labels:
- app: my-service
- annotations:
- description: "Istio DestinationRule for traffic policies"
- subsets:
- - name: version-1
- labels:
- version: "v1"
- - name: version-2
- labels:
- version: "v2"
- trafficPolicy:
- connectionPool:
- tcp:
- maxConnections: 100
- outlierDetection:
- consecutiveErrors: 5
- interval: 30s
- baseEjectionTime: 60s
-
- peerAuthentication:
- enabled: true
- labels:
- app: my-service
- annotations:
- description: "Istio PeerAuthentication for mutual TLS"
- selector:
- matchLabels:
- version: "v1"
- mtls:
- mode: STRICT
- portLevelMtls:
- 8080:
- mode: DISABLE
-
- requestAuthentication:
- enabled: true
- labels:
- app: my-service
- annotations:
- description: "Istio RequestAuthentication for JWT validation"
- selector:
- matchLabels:
- version: "v1"
- jwtRules:
- - issuer: "issuer-1"
- jwksUri: "https://issuer-1/.well-known/jwks.json"
-
- authorizationPolicy:
- enabled: true
- labels:
- app: my-service
- annotations:
- description: "Istio AuthorizationPolicy for access control"
- action: ALLOW
- provider:
- name: jwt
- kind: Authorization
- rules:
- - from:
- - source:
- requestPrincipals: ["*"]
- to:
- - operation:
- methods: ["GET"]
-```
-
-| Key | Description |
-| :--- | :--- |
-| `istio` | Istio enablement. When `istio.enable` set to true, Istio would be enabled for the specified configurations |
-| `authorizationPolicy` | It allows you to define access control policies for service-to-service communication. |
-| `action` | Determines whether to ALLOW or DENY the request based on the defined rules. |
-| `provider` | Authorization providers are external systems or mechanisms used to make access control decisions. |
-| `rules` | List of rules defining the authorization policy. Each rule can specify conditions and requirements for allowing or denying access. |
-| `destinationRule` | It allows for the fine-tuning of traffic policies and load balancing for specific services. You can define subsets of a service and apply different traffic policies to each subset. |
-| `subsets` | Specifies subsets within the service for routing and load balancing. |
-| `trafficPolicy` | Policies related to connection pool size, outlier detection, and load balancing. |
-| `gateway` | Allowing external traffic to enter the service mesh through the specified configurations. |
-| `host` | The external domain through which traffic will be routed into the service mesh. |
-| `tls` | Traffic to and from the gateway should be encrypted using TLS. |
-| `secretName` | Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway. |
-| `peerAuthentication` | It allows you to enforce mutual TLS and control the authentication between services. |
-| `mtls` | Mutual TLS. Mutual TLS is a security protocol that requires both client and server, to authenticate each other using digital certificates for secure communication. |
-| `mode` | Mutual TLS mode, specifying how mutual TLS should be applied. Modes include STRICT, PERMISSIVE, and DISABLE. |
-| `portLevelMtls` | Configures port-specific mTLS settings. Allows for fine-grained control over the application of mutual TLS on specific ports. |
-| `selector` | Configuration for selecting workloads to apply PeerAuthentication. |
-| `requestAuthentication` | Defines rules for authenticating incoming requests. |
-| `jwtRules` | Rules for validating JWTs (JSON Web Tokens). It defines how incoming JWTs should be validated for authentication purposes. |
-| `selector` | Specifies the conditions under which the RequestAuthentication rules should be applied. |
-| `virtualService` | Enables the definition of rules for how traffic should be routed to different services within the service mesh. |
-| `gateways` | Specifies the gateways to which the rules defined in the VirtualService apply. |
-| `hosts` | List of hosts (domains) to which this VirtualService is applied. |
-| `http` | Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies. |
-
-
-### KEDA Autoscaling
-[KEDA](https://keda.sh) is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
-
-Example for autosccaling with KEDA using Prometheus metrics is given below:
-```yaml
-kedaAutoscaling:
- enabled: true
- minReplicaCount: 1
- maxReplicaCount: 2
- idleReplicaCount: 0
- pollingInterval: 30
- advanced:
- restoreToOriginalReplicaCount: true
- horizontalPodAutoscalerConfig:
- behavior:
- scaleDown:
- stabilizationWindowSeconds: 300
- policies:
- - type: Percent
- value: 100
- periodSeconds: 15
- triggers:
- - type: prometheus
- metadata:
- serverAddress: http://:9090
- metricName: http_request_total
- query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy",}
- threshold: "50"
- triggerAuthentication:
- enabled: false
- name:
- spec: {}
- authenticationRef: {}
-```
-Example for autosccaling with KEDA based on kafka is given below :
-```yaml
-kedaAutoscaling:
- enabled: true
- minReplicaCount: 1
- maxReplicaCount: 2
- idleReplicaCount: 0
- pollingInterval: 30
- advanced: {}
- triggers:
- - type: kafka
- metadata:
- bootstrapServers: b-2.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-3.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-1.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092
- topic: Orders-Service-ESP.info
- lagThreshold: "100"
- consumerGroup: oders-remove-delivered-packages
- allowIdleConsumers: "true"
- triggerAuthentication:
- enabled: true
- name: keda-trigger-auth-kafka-credential
- spec:
- secretTargetRef:
- - parameter: sasl
- name: keda-kafka-secrets
- key: sasl
- - parameter: username
- name: keda-kafka-secrets
- key: username
- authenticationRef:
- name: keda-trigger-auth-kafka-credential
-```
-
-### NetworkPolicy
-
-Kubernetes NetworkPolicies control pod communication by defining rules for incoming and outgoing traffic.
-
-```yaml
-networkPolicy:
- enabled: false
- annotations: {}
- labels: {}
- podSelector:
- matchLabels:
- role: db
- policyTypes:
- - Ingress
- - Egress
- ingress:
- - from:
- - ipBlock:
- cidr: 172.17.0.0/16
- except:
- - 172.17.1.0/24
- - namespaceSelector:
- matchLabels:
- project: myproject
- - podSelector:
- matchLabels:
- role: frontend
- ports:
- - protocol: TCP
- port: 6379
- egress:
- - to:
- - ipBlock:
- cidr: 10.0.0.0/24
- ports:
- - protocol: TCP
- port: 5978
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Enable or disable NetworkPolicy. |
-| `annotations` | Additional metadata or information associated with the NetworkPolicy. |
-| `labels` | Labels to apply to the NetworkPolicy.
-| `podSelector` | Each NetworkPolicy includes a podSelector which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty podSelector selects all pods in the namespace.|
-| `policyTypes` | Each NetworkPolicy includes a policyTypes list which may include either Ingress, Egress, or both. |
-| `Ingress` | Controls incoming traffic to pods. |
-| `Egress` | Controls outgoing traffic from pods. |
-
-### Winter-Soldier
-Winter Soldier can be used to
-- cleans up (delete) Kubernetes resources
-- reduce workload pods to 0
-
-**_NOTE:_** After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check [the main repo](https://github.com/devtron-labs/winter-soldier)
-
-Given below is template values you can give in winter-soldier:
-```yaml
-winterSoldier:
- enabled: false
- apiVersion: pincher.devtron.ai/v1alpha1
- action: sleep
- timeRangesWithZone:
- timeZone: "Asia/Kolkata"
- timeRanges: []
- targetReplicas: []
- fieldSelector: []
-```
-
-| Key | values | Description |
-| :--- | :--- | :--- |
-| `enabled` | `false`,`true` | decide the enabling factor |
-| `apiVersion` | `pincher.devtron.ai/v1beta1`, `pincher.devtron.ai/v1alpha1` | specific api version |
-| `action` | `sleep`,`delete`, `scale` | This specify the action need to perform. |
-| `timeRangesWithZone`:`timeZone` | eg:- `"Asia/Kolkata"`,`"US/Pacific"` | It use to specify the timeZone used. (It uses standard format. please refer [this](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)) |
-| `timeRangesWithZone`:`timeRanges` | array of [ `timeFrom`, `timeTo`, `weekdayFrom`, `weekdayTo`] | It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges. These settings will take `action` on Sat and Sun from 00:00 to 23:59:59, |
-| `targetReplicas` | `[n]` : n - number of replicas to scale. | These is mandatory field when the `action` is `scale` Default value is `[]`. |
-| `fieldSelector` | `- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now()) ` | These value will take a list of methods to select the resources on which we perform specified `action` . |
-
-
-here is an example,
-```yaml
-winterSoldier:
- apiVersion: pincher.devtron.ai/v1alpha1
- enabled: true
- annotations: {}
- labels: {}
- timeRangesWithZone:
- timeZone: "Asia/Kolkata"
- timeRanges:
- - timeFrom: 00:00
- timeTo: 23:59:59
- weekdayFrom: Sat
- weekdayTo: Sun
- - timeFrom: 00:00
- timeTo: 08:00
- weekdayFrom: Mon
- weekdayTo: Fri
- - timeFrom: 20:00
- timeTo: 23:59:59
- weekdayFrom: Mon
- weekdayTo: Fri
- action: scale
- targetReplicas: [1,1,1]
- fieldSelector:
- - AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '10h'), Now())
-```
-Above settings will take action on `Sat` and `Sun` from 00:00 to 23:59:59, and on `Mon`-`Fri` from 00:00 to 08:00 and 20:00 to 23:59:59. If `action:sleep` then runs hibernate at timeFrom and unhibernate at `timeTo`. If `action: delete` then it will delete workloads at `timeFrom` and `timeTo`. Here the `action:scale` thus it scale the number of resource replicas to `targetReplicas: [1,1,1]`. Here each element of `targetReplicas` array is mapped with the corresponding elements of array `timeRangesWithZone/timeRanges`. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
-
-The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
-
-- ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')
-- AddTime - This can be used to add time. For eg AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h') ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
-- Now - This can be used to get current time.
-- CpuToNumber - This can be used to compare CPU. For eg any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')}) will check if any resource.requests is less than 60Mi.
-
-
-### Security Context
-A security context defines privilege and access control settings for a Pod or Container.
-
-To add a security context for main container:
-```yaml
-containerSecurityContext:
- allowPrivilegeEscalation: false
-```
-
-To add a security context on pod level:
-```yaml
-podSecurityContext:
- runAsUser: 1000
- runAsGroup: 3000
- fsGroup: 2000
-```
-
-### Topology Spread Constraints
-You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
-
-```yaml
-topologySpreadConstraints:
- - maxSkew: 1
- topologyKey: zone
- whenUnsatisfiable: DoNotSchedule
- autoLabelSelector: true
- customLabelSelector: {}
-```
-
-### Deployment Metrics
-
-It gives the realtime metrics of the deployed applications
-
-| Key | Description |
-| :--- | :--- |
-| `Deployment Frequency` | It shows how often this app is deployed to production |
-| `Change Failure Rate` | It shows how often the respective pipeline fails |
-| `Mean Lead Time` | It shows the average time taken to deliver a change to production |
-| `Mean Time to Recovery` | It shows the average time taken to fix a failed pipeline |
-
----
-
-## 4. Show Application Metrics
-
-If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
-
-
-
-Once all the Deployment template configurations are done, click on `Save` to save your deployment configuration. Now you are ready to create [Workflow](../../workflow/README.md) to do CI/CD.
-
-### Helm Chart Json Schema
-
-Helm Chart [json schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_5-1-0/schema.json) is used to validate the deployment template values.
-
-### Other Validations in Json Schema
-
-The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
-```
-resources.limits.cpu >= resources.requests.cpu
-resources.limits.memory >= resources.requests.memory
-envoyproxy.resources.limits.cpu >= envoyproxy.resources.requests.cpu
-envoyproxy.resources.limits.memory >= envoyproxy.resources.requests.memory
-```
diff --git a/docs/user-guide/creating-application/base-config/deployment-template/job-and-cronjob.md b/docs/user-guide/creating-application/base-config/deployment-template/job-and-cronjob.md
deleted file mode 100644
index be8c454a1c..0000000000
--- a/docs/user-guide/creating-application/base-config/deployment-template/job-and-cronjob.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# Job and CronJob
-
-
-This chart deploys Job & CronJob. A Job is a controller object that represents a finite task and CronJob is used to schedule the creation of Jobs.
-
- * [Job](#id-1.-job)
- * [CronJob](#id-2.-cronjob)
-
-
-
-## 1. Job
-
-A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created. Suspeding a Job will delete its active Pods until the Job is resumed again.
-
-## **Example:**
-
-```yaml
-kind: Job
-jobConfigs:
- activeDeadlineSeconds: 120
- backoffLimit: 6
- completions: 1
- parallelism: 1
- suspend: false
- ttlSecondsAfterFinished: 100
-```
-
-| Key | Description |
-| :--- | :--- |
-| `activeDeadlineSeconds` | Another way to terminate a Job is by setting an active deadline. Do this by setting the activeDeadlineSeconds field of the Job to a number of seconds. The activeDeadlineSeconds applies to the duration of the job, no matter how many Pods are created. Once a Job reaches activeDeadlineSeconds, all of its running Pods are terminated and the Job status will become type: Failed with reason: DeadlineExceeded. |
-| `backoffLimit` | There are situations where you want to fail a Job after some amount of retries due to a logical error in configuration etc. To do so, set backoffLimit to specify the number of retries before considering a Job as failed. The back-off limit is set by default to 6. Failed Pods associated with the Job are recreated by the Job controller with an exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The back-off count is reset when a Job's Pod is deleted or successful without any other Pods for the Job failing around that time. |
-| `completions` | Jobs with fixed completion count - that is , jobs that have non null completions - can have a completion mode that is specified in completionMode. |
-| `parallelism` | The requested parallelism can be set to any non-negative value. If it is unspecified, it defaults to 1. If it is specified as 0, then the Job is effectively paused until it is increased. |
-| `suspend` | The suspend field is also optional. If it is set to true, all subsequent executions are suspended. This setting does not apply to already started executions. Defaults to false. |
-| `ttlSecondsAfterFinished` | The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean up finished Jobs (either Complete or Failed) automatically by specifying the ttlSecondsAfterFinished field of a Job, as in this example. The TTL controller will assume that a resource is eligible to be cleaned up TTL seconds after the resource has finished, in other words, when the TTL has expired. When the TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete its dependent objects together with it. Note that when the resource is deleted, its lifecycle guarantees, such as finalizers, will be honored. |
-| `kind` | As with all other Kubernetes config, a Job and cronjob needs apiVersion, kind.cronjob and job also needs a section fields which is optional . these fields specify to deploy which job (conjob or job) should be kept. by default, they are set job. |
-
-
-## 2. CronJob
-
-A CronJob creates jobs on a repeating schedule. One Cronjob object is like one line of a crontab (cron table) file. It runs a job periodically on a given schedule, written in Cron format.
- CronJobs are meant for performing regular scheduled actions such as backups, report generation, and so on. Each task must be configured to recur indefinitely (as an example: once a day / week / month). You can schedule the time within that interval when the job should start.
-
- ## **Example:**
-
-```yaml
-kind: CronJob
-cronjobConfigs:
- concurrencyPolicy: Allow
- failedJobsHistoryLimit: 1
- restartPolicy: OnFailure
- schedule: 32 8 * * *
- startingDeadlineSeconds: 100
- successfulJobsHistoryLimit: 3
- suspend: false
-```
-
-| Key | Descriptions |
-| :--- | :--- |
-| `concurrencyPolicy` | A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If concurrencyPolicy is set to Forbid and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed,`Acceptable values: Allow / Forbid`. |
-| `failedJobsHistoryLimit` | The failedJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0 corresponds to keeping none of the corresponding kind of jobs after they finish. |
-| `restartPolicy` | The spec of a Pod has a restartPolicy field with possible values Always, OnFailure, and Never. The default value is Always.The restartPolicy applies to all containers in the Pod. restartPolicy only refers to restarts of the containers by the kubelet on the same node. After containers in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s, 40s, …), that is capped at five minutes. Once a container has executed for 10 minutes without any problems, the kubelet resets the restart backoff timer for that container, `Acceptable values: Always / OnFailure / Never`. |
-| `schedule` | To generate Cronjob schedule expressions, you can also use web tools like https://crontab.guru/. |
-| `startingDeadlineSeconds` | If startingDeadlineSeconds is set to a large value or left unset (the default) and if concurrencyPolicy is set to Allow, the jobs will always run at least once. |
-| `successfulJobsHistoryLimit` | The successfulJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0 corresponds to keeping none of the corresponding kind of jobs after they finish. |
-| `suspend` | The suspend field is also optional. If it is set to true, all subsequent executions are suspended. This setting does not apply to already started executions. Defaults to false. |
-| `kind` | As with all other Kubernetes config, a Job and cronjob needs apiVersion, kind.cronjob and job also needs a section fields which is optional . these fields specify to deploy which job (conjob or job) should be kept. by default, they are set cronjob. |
-
-{% hint style="warning" %}
-### Note
-Super-admins can lock keys in Job & CronJob deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
-{% endhint %}
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/deployment-template/rollout-deployment.md b/docs/user-guide/creating-application/base-config/deployment-template/rollout-deployment.md
deleted file mode 100644
index 7d7431f694..0000000000
--- a/docs/user-guide/creating-application/base-config/deployment-template/rollout-deployment.md
+++ /dev/null
@@ -1,1206 +0,0 @@
-
-# Rollout Deployment
-
-The `Rollout Deployment` chart deploys an advanced version of deployment that supports Blue/Green and Canary deployments. For functioning, it requires a rollout controller to run inside the cluster.
-
-
-
-You can define application behavior by providing information in the following sections:
-
-| Key | Descriptions |
-| :--- | :--- |
-| `Chart version` | Select the Chart Version using which you want to deploy the application. Refer [Chart Version](../../../creating-application/base-config/deployment-template.md#choose-a-chart-version) section for more detail. |
-| `GUI` | You can perform a basic deployment configuration for your application in the **GUI** section instead of configuring the YAML file. Refer [Basic Configuration](../../../creating-application/base-config/deployment-template.md#using-gui) section for more detail.|
-| `YAML` | If you want to do additional configurations, then click **YAML** for modifications. Refer [YAML](#yaml) section for more detail. |
-| `Show application metrics` | You can enable `Show application metrics` to see your application's metrics-CPU Service Monitor usage, Memory Usage, Status, Throughput and Latency. Refer [Application Metrics](../../../creating-application/app-metrics.md) for more detail. |
-
-{% hint style="warning" %}
-### Note
-Super-admins can lock keys in rollout deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
-{% endhint %}
-
----
-
-## YAML
-
-### Container Ports
-
-This defines the ports on which application services will be exposed to other services.
-
-```yaml
-ContainerPort:
- - envoyPort: 8799
- envoyTimeout: 15s
- idleTimeout:
- name: app
- port: 8080
- servicePort: 80
- supportStreaming: true
- useHTTP2: true
-```
-
-| Key | Description |
-| :--- | :--- |
-| `envoyPort` | envoy port for the container. |
-| `envoyTimeout` | envoy Timeout for the container,envoy supports a wide range of timeouts that may need to be configured depending on the deployment.By default the envoytimeout is 15s. |
-| `idleTimeout` | the duration of time that a connection is idle before the connection is terminated. |
-| `name` | name of the port. |
-| `port` | port for the container. |
-| `servicePort` | port of the corresponding kubernetes service. |
-| `supportStreaming` | Used for high performance protocols like grpc where timeout needs to be disabled. |
-| `useHTTP2` | Envoy container can accept HTTP2 requests. |
-
-### EnvVariables
-```yaml
-EnvVariables: []
-```
-`EnvVariables` provide run-time information to containers and allow to customize how the application works and the behavior of the applications on the system.
-
-Here we can pass the list of env variables , every record is an object which contain the `name` of variable along with `value`.
-
-To set environment variables for the containers that run in the Pod.
-
-### Example of EnvVariables
-
-`IMP` Docker image should have env variables, whatever we want to set.
-```yaml
-EnvVariables:
- - name: HOSTNAME
- value: www.xyz.com
- - name: DB_NAME
- value: mydb
- - name: USER_NAME
- value: xyz
-```
-
-But `ConfigMap` and `Secret` are the preferred way to inject env variables. You can create this in **Configurations** page of your app.
-
-### ConfigMap
-
-It is a centralized storage, specific to k8s namespace where key-value pairs are stored in plain text.
-
-
-
-### Secret
-
-It is a centralized storage, specific to k8s namespace where we can store the key-value pairs in plain text as well as in encrypted(`Base64`) form.
-
-
-
-`IMP` All key-values of `Secret` and `CofigMap` will reflect to your application.
-
-### Liveness Probe
-
-If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
-
-```yaml
-LivenessProbe:
- Path: ""
- port: 8080
- initialDelaySeconds: 20
- periodSeconds: 10
- successThreshold: 1
- timeoutSeconds: 5
- failureThreshold: 3
- command:
- - python
- - /etc/app/healthcheck.py
- httpHeaders:
- - name: Custom-Header
- value: abc
- scheme: ""
- tcp: true
-```
-
-| Key | Description |
-| :--- | :--- |
-| `Path` | It define the path where the liveness needs to be checked. |
-| `initialDelaySeconds` | It defines the time to wait before a given container is checked for liveliness. |
-| `periodSeconds` | It defines how often (in seconds) to perform the liveness probe. |
-| `successThreshold` | It defines the number of successes required before a given container is said to fulfil the liveness probe. |
-| `timeoutSeconds` | The maximum time (in seconds) for the probe to complete. |
-| `failureThreshold` | The number of consecutive failures required to consider the probe as failed. |
-| `command` | The mentioned command is executed to perform the livenessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
-| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
-| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP. |
-| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
-
-
-### MaxUnavailable
-
-```yaml
- MaxUnavailable: 0
-```
-The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
-
-### MaxSurge
-
-```yaml
-MaxSurge: 1
-```
-The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count.
-The default value of "MaxSurge: " is 25%.
-
-### Min Ready Seconds
-
-```yaml
-MinReadySeconds: 60
-```
-This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
-
-### Readiness Probe
-
-If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
-
-```yaml
-ReadinessProbe:
- Path: ""
- port: 8080
- initialDelaySeconds: 20
- periodSeconds: 10
- successThreshold: 1
- timeoutSeconds: 5
- failureThreshold: 3
- command:
- - python
- - /etc/app/healthcheck.py
- httpHeaders:
- - name: Custom-Header
- value: abc
- scheme: ""
- tcp: true
-```
-
-| Key | Description |
-| :--- | :--- |
-| `Path` | It define the path where the readiness needs to be checked. |
-| `initialDelaySeconds` | It defines the time to wait before a given container is checked for readiness. |
-| `periodSeconds` | It defines how often (in seconds) to perform the readiness probe. |
-| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the readiness probe. |
-| `timeoutSeconds` | The maximum time (in seconds) for the probe to complete. |
-| `failureThreshold` | The number of consecutive failures required to consider the probe as failed. |
-| `command` | The mentioned command is executed to perform the readinessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
-| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
-| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP. |
-| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
-
-
-### Startup Probe
-
-Startup Probe in Kubernetes is a type of probe used to determine when a container within a pod is ready to start accepting traffic. It is specifically designed for applications that have a longer startup time.
-
-```yaml
-StartupProbe:
- Path: ""
- port: 8080
- initialDelaySeconds: 20
- periodSeconds: 10
- successThreshold: 1
- timeoutSeconds: 5
- failureThreshold: 3
- httpHeaders:
- - name: Custom-Header
- value: abc
- command:
- - python
- - /etc/app/healthcheck.py
- tcp: false
-```
-
-| Key | Description |
-| :--- | :--- |
-| `Path` | It define the path where the startup needs to be checked. |
-| `initialDelaySeconds` | It defines the time to wait before a given container is checked for startup. |
-| `periodSeconds` | It defines how often (in seconds) to perform the startup probe. |
-| `successThreshold` | The number of consecutive successful probe results required to mark the container as ready. |
-| `timeoutSeconds` | The maximum time (in seconds) for the probe to complete. |
-| `failureThreshold` | The number of consecutive failures required to consider the probe as failed. |
-| `command` | The mentioned command is executed to perform the startup probe. If the command returns a non-zero value, it's equivalent to a failed probe. |
-| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
-| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
-
-### Autoscaling
-
-This is connected to HPA and controls scaling up and down in response to request load.
-
-```yaml
-autoscaling:
- enabled: false
- MinReplicas: 1
- MaxReplicas: 2
- TargetCPUUtilizationPercentage: 90
- TargetMemoryUtilizationPercentage: 80
- extraMetrics: []
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Set true to enable autoscaling else set false.|
-| `MinReplicas` | Minimum number of replicas allowed for scaling. |
-| `MaxReplicas` | Maximum number of replicas allowed for scaling. |
-| `TargetCPUUtilizationPercentage` | The target CPU utilization that is expected for a container. |
-| `TargetMemoryUtilizationPercentage` | The target memory utilization that is expected for a container. |
-| `extraMetrics` | Used to give external metrics for autoscaling. |
-
-### Fullname Override
-
-```yaml
-fullnameOverride: app-name
-```
-`fullnameOverride` replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses {app-name}-{environment-name} as release fullname.
-
-### Image
-
-```yaml
-image:
- pullPolicy: IfNotPresent
-```
-
-Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
-
-### serviceAccount
-
-```yaml
-serviceAccount:
- create: false
- name: ""
- annotations: {}
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Determines whether to create a ServiceAccount for pods or not. If set to `true`, a ServiceAccount will be created. |
-| `name` | Specifies the name of the ServiceAccount to use. |
-| `annotations` | Specify annotations for the ServiceAccount. |
-
-
-### imagePullSecrets
-
-`imagePullSecrets` contains the docker credentials that are used for accessing a registry.
-
-```yaml
-imagePullSecrets:
- - regcred
-```
-regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry [https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) .
-
-### HostAliases
-
- the hostAliases field is used in a Pod specification to associate additional hostnames with the Pod's IP address. This can be helpful in scenarios where you need to resolve specific hostnames to the Pod's IP within the Pod itself.
-
-```yaml
- hostAliases:
- - ip: "192.168.1.10"
- hostnames:
- - "hostname1.example.com"
- - "hostname2.example.com"
- - ip: "192.168.1.11"
- hostnames:
- - "hostname3.example.com"
-```
-
-### Ingress
-
-This allows public access to the url. Please ensure you are using the right nginx annotation for nginx class.
-The default value is `nginx`.
-
-```yaml
-ingress:
- enabled: false
- # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
- className: nginx
- annotations: {}
- hosts:
- - host: example1.com
- pathType: "ImplementationSpecific"
- paths:
- - /example
- - host: example2.com
- pathType: "ImplementationSpecific"
- paths:
- - /example2
- - /example2/healthz
- tls: []
-```
-Legacy deployment-template ingress format
-
-```yaml
-ingress:
- enabled: false
- # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
- ingressClassName: nginx-internal
- annotations: {}
- path: ""
- host: ""
- tls: []
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Enable or disable ingress |
-| `annotations` | To configure some options depending on the Ingress controller |
-| `host` | Host name |
-| `pathType` | Path in an Ingress is required to have a corresponding path type. Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`. |
-| `path` | Path name |
-| `tls` | It contains security details |
-
-### Ingress Internal
-
-This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
-
-```yaml
-ingressInternal:
- enabled: false
- # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
- ingressClassName: nginx-internal
- annotations: {}
- hosts:
- - host: example1.com
- pathType: "ImplementationSpecific"
- paths:
- - /example
- - host: example2.com
- pathType: "ImplementationSpecific"
- paths:
- - /example2
- - /example2/healthz
- tls: []
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Enable or disable ingress |
-| `annotations` | To configure some options depending on the Ingress controller |
-| `host` | Host name |
-| `pathType` | Path in an Ingress is required to have a corresponding path type. Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`. |
-| `path` | Path name |
-| `pathType` | Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`.|
-| `tls` | It contains security details |
-
-### Init Containers
-```yaml
-initContainers:
- - reuseContainerImage: true
- securityContext:
- runAsUser: 1000
- runAsGroup: 3000
- fsGroup: 2000
- volumeMounts:
- - mountPath: /etc/ls-oms
- name: ls-oms-cm-vol
- command:
- - flyway
- - -configFiles=/etc/ls-oms/flyway.conf
- - migrate
-
- - name: nginx
- image: nginx:1.14.2
- securityContext:
- privileged: true
- ports:
- - containerPort: 80
- command: ["/usr/local/bin/nginx"]
- args: ["-g", "daemon off;"]
-```
-Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to `true`.
-
-### Pause For Seconds Before Switch Active
-```yaml
-pauseForSecondsBeforeSwitchActive: 30
-```
-To wait for given period of time before switch active the container.
-
-### Resources
-
-These define minimum and maximum RAM and CPU available to the application.
-
-```yaml
-resources:
- limits:
- cpu: "1"
- memory: "200Mi"
- requests:
- cpu: "0.10"
- memory: "100Mi"
-```
-
-Resources are required to set CPU and memory usage.
-
-#### Limits
-
-Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
-
-#### Requests
-
-Requests are what the container is guaranteed to get.
-
-### Service
-
-This defines annotations and the type of service, optionally can define name also.
-
-```yaml
- service:
- type: ClusterIP
- annotations: {}
-```
-| Key | Description |
-| :--- | :--- |
-| `type` | Select the type of service, default `ClusterIP` |
-| `annotations` | Annotations are widely used to attach metadata and configs in Kubernetes. |
-| `name` | Optional field to assign name to service |
-| `loadBalancerSourceRanges` | If service type is `LoadBalancer`, Provide a list of whitelisted IPs CIDR that will be allowed to use the Load Balancer. |
-
-Note - If `loadBalancerSourceRanges` is not set, Kubernetes allows traffic from 0.0.0.0/0 to the LoadBalancer / Node Security Group(s).
-
-
-### Volumes
-
-```yaml
-volumes:
- - name: log-volume
- emptyDir: {}
- - name: logpv
- persistentVolumeClaim:
- claimName: logpvc
-```
-
-It is required when some values need to be read from or written to an external disk.
-
-### Volume Mounts
-
-```yaml
-volumeMounts:
- - mountPath: /var/log/nginx/
- name: log-volume
- - mountPath: /mnt/logs
- name: logpvc
- subPath: employee
-```
-
-It is used to provide mounts to the volume.
-
-### Affinity and anti-affinity
-
-```yaml
-Spec:
- Affinity:
- Key:
- Values:
-```
-
-Spec is used to define the desire state of the given container.
-
-Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
-
-Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
-
-#### Key
-
-Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
-
-#### Values
-
-Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
-
-### Tolerations
-
-```yaml
-tolerations:
- - key: "key"
- operator: "Equal"
- value: "value"
- effect: "NoSchedule|PreferNoSchedule|NoExecute(1.6 only)"
-```
-
-Taints are the opposite, they allow a node to repel a set of pods.
-
-A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
-
-Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
-
-### Arguments
-
-```yaml
-args:
- enabled: false
- value: []
-```
-
-This is used to give arguments to command.
-
-### Command
-
-```yaml
-command:
- enabled: false
- value: []
- workingDir: {}
-```
-
-It contains the commands to run inside the container.
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | To enable or disable the command. |
-| `value` | It contains the commands. |
-| `workingDir` | It is used to specify the working directory where commands will be executed. |
-
-### Containers
-Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to `true`.
-
-```yaml
- containers:
- - name: nginx
- image: nginx:1.14.2
- ports:
- - containerPort: 80
- command: ["/usr/local/bin/nginx"]
- args: ["-g", "daemon off;"]
- - reuseContainerImage: true
- securityContext:
- runAsUser: 1000
- runAsGroup: 3000
- fsGroup: 2000
- volumeMounts:
- - mountPath: /etc/ls-oms
- name: ls-oms-cm-vol
- command:
- - flyway
- - -configFiles=/etc/ls-oms/flyway.conf
- - migrate
-
-```
-
-### Prometheus
-
-```yaml
- prometheus:
- release: monitoring
-```
-
-It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case.It describes the state of the prometheus.
-
-### rawYaml
-
-```yaml
-rawYaml:
- - apiVersion: v1
- kind: Service
- metadata:
- name: my-service
- spec:
- selector:
- app: MyApp
- ports:
- - protocol: TCP
- port: 80
- targetPort: 9376
- type: ClusterIP
-```
-Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
-
-### Grace Period
-
-```yaml
-GracePeriod: 30
-```
-Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the `GracePeriod`.
-
-A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
-
-There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
-
-
-### Server
-
-```yaml
-server:
- deployment:
- image_tag: 1-95a53
- image: ""
-```
-
-It is used for providing server configurations.
-
-#### Deployment
-
-It gives the details for deployment.
-
-| Key | Description |
-| :--- | :--- |
-| `image_tag` | It is the image tag |
-| `image` | It is the URL of the image |
-
-### Service Monitor
-
-```yaml
-servicemonitor:
- enabled: true
- path: /abc
- scheme: 'http'
- interval: 30s
- scrapeTimeout: 20s
- metricRelabelings:
- - sourceLabels: [namespace]
- regex: '(.*)'
- replacement: myapp
- targetLabel: target_namespace
-```
-
-It gives the set of targets to be monitored.
-
-### Db Migration Config
-
-```yaml
-dbMigrationConfig:
- enabled: false
-```
-
-It is used to configure database migration.
-
-### Istio
-
-These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
-
-
-### Istio
-
-These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
-
-```yaml
-istio:
- enable: true
-
- gateway:
- enabled: true
- labels:
- app: my-gateway
- annotations:
- description: "Istio Gateway for external traffic"
- host: "example.com"
- tls:
- enabled: true
- secretName: my-tls-secret
-
- virtualService:
- enabled: true
- labels:
- app: my-service
- annotations:
- description: "Istio VirtualService for routing"
- gateways:
- - my-gateway
- hosts:
- - "example.com"
- http:
- - match:
- - uri:
- prefix: /v1
- route:
- - destination:
- host: my-service-v1
- subset: version-1
- - match:
- - uri:
- prefix: /v2
- route:
- - destination:
- host: my-service-v2
- subset: version-2
-
- destinationRule:
- enabled: true
- labels:
- app: my-service
- annotations:
- description: "Istio DestinationRule for traffic policies"
- subsets:
- - name: version-1
- labels:
- version: "v1"
- - name: version-2
- labels:
- version: "v2"
- trafficPolicy:
- connectionPool:
- tcp:
- maxConnections: 100
- outlierDetection:
- consecutiveErrors: 5
- interval: 30s
- baseEjectionTime: 60s
-
- peerAuthentication:
- enabled: true
- labels:
- app: my-service
- annotations:
- description: "Istio PeerAuthentication for mutual TLS"
- selector:
- matchLabels:
- version: "v1"
- mtls:
- mode: STRICT
- portLevelMtls:
- 8080:
- mode: DISABLE
-
- requestAuthentication:
- enabled: true
- labels:
- app: my-service
- annotations:
- description: "Istio RequestAuthentication for JWT validation"
- selector:
- matchLabels:
- version: "v1"
- jwtRules:
- - issuer: "issuer-1"
- jwksUri: "https://issuer-1/.well-known/jwks.json"
-
- authorizationPolicy:
- enabled: true
- labels:
- app: my-service
- annotations:
- description: "Istio AuthorizationPolicy for access control"
- action: ALLOW
- provider:
- name: jwt
- kind: Authorization
- rules:
- - from:
- - source:
- requestPrincipals: ["*"]
- to:
- - operation:
- methods: ["GET"]
-```
-
-| Key | Description |
-| :--- | :--- |
-| `istio` | Istio enablement. When `istio.enable` set to true, Istio would be enabled for the specified configurations |
-| `authorizationPolicy` | It allows you to define access control policies for service-to-service communication. |
-| `action` | Determines whether to ALLOW or DENY the request based on the defined rules. |
-| `provider` | Authorization providers are external systems or mechanisms used to make access control decisions. |
-| `rules` | List of rules defining the authorization policy. Each rule can specify conditions and requirements for allowing or denying access. |
-| `destinationRule` | It allows for the fine-tuning of traffic policies and load balancing for specific services. You can define subsets of a service and apply different traffic policies to each subset. |
-| `subsets` | Specifies subsets within the service for routing and load balancing. |
-| `trafficPolicy` | Policies related to connection pool size, outlier detection, and load balancing. |
-| `gateway` | Allowing external traffic to enter the service mesh through the specified configurations. |
-| `host` | The external domain through which traffic will be routed into the service mesh. |
-| `tls` | Traffic to and from the gateway should be encrypted using TLS. |
-| `secretName` | Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway. |
-| `peerAuthentication` | It allows you to enforce mutual TLS and control the authentication between services. |
-| `mtls` | Mutual TLS. Mutual TLS is a security protocol that requires both client and server, to authenticate each other using digital certificates for secure communication. |
-| `mode` | Mutual TLS mode, specifying how mutual TLS should be applied. Modes include STRICT, PERMISSIVE, and DISABLE. |
-| `portLevelMtls` | Configures port-specific mTLS settings. Allows for fine-grained control over the application of mutual TLS on specific ports. |
-| `selector` | Configuration for selecting workloads to apply PeerAuthentication. |
-| `requestAuthentication` | Defines rules for authenticating incoming requests. |
-| `jwtRules` | Rules for validating JWTs (JSON Web Tokens). It defines how incoming JWTs should be validated for authentication purposes. |
-| `selector` | Specifies the conditions under which the RequestAuthentication rules should be applied. |
-| `virtualService` | Enables the definition of rules for how traffic should be routed to different services within the service mesh. |
-| `gateways` | Specifies the gateways to which the rules defined in the VirtualService apply. |
-| `hosts` | List of hosts (domains) to which this VirtualService is applied. |
-| `http` | Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies. |
-
-### Application Metrics
-
-Application metrics can be enabled to see your application's metrics-CPU Service Monitor usage, Memory Usage, Status, Throughput and Latency.
-
-### Deployment Metrics
-
-It gives the realtime metrics of the deployed applications
-
-| Key | Description |
-| :--- | :--- |
-| `Deployment Frequency` | It shows how often this app is deployed to production |
-| `Change Failure Rate` | It shows how often the respective pipeline fails. |
-| `Mean Lead Time` | It shows the average time taken to deliver a change to production. |
-| `Mean Time to Recovery` | It shows the average time taken to fix a failed pipeline. |
-
-
-## Addon features in Deployment Template Chart version 3.9.0
-
-### Service Account
-
-```yaml
-serviceAccountName: orchestrator
-```
-
-A service account provides an identity for the processes that run in a Pod.
-
-When you access the cluster, you are authenticated by the API server as a particular User Account. Processes in containers inside pod can also contact the API server. When you are authenticated as a particular Service Account.
-
-When you create a pod, if you do not create a service account, it is automatically assigned the default service account in the namespace.
-
-### Pod Disruption Budget
-
-You can create `PodDisruptionBudget` for each application. A PDB limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, an application would like to ensure the number of replicas running is never brought below the certain number.
-
-```yaml
-podDisruptionBudget:
- minAvailable: 1
-```
-
-or
-
-```yaml
-podDisruptionBudget:
- maxUnavailable: 50%
-```
-
-You can specify either `maxUnavailable` or `minAvailable` in a PodDisruptionBudget and it can be expressed as integers or as a percentage.
-
-| Key | Description |
-| :--- | :--- |
-| `minAvailable` | Evictions are allowed as long as they leave behind 1 or more healthy pods of the total number of desired replicas. |
-| `maxUnavailable` | Evictions are allowed as long as at most 1 unhealthy replica among the total number of desired replicas. |
-
-### Application metrics Envoy Configurations
-
-```yaml
-envoyproxy:
- image: envoyproxy/envoy:v1.14.1
- configMapName: ""
- resources:
- limits:
- cpu: "50m"
- memory: "50Mi"
- requests:
- cpu: "50m"
- memory: "50Mi"
-```
-
-Envoy is attached as a sidecar to the application container to collect metrics like 4XX, 5XX, Throughput and latency. You can now configure the envoy settings such as idleTimeout, resources etc.
-
-### Prometheus Rule
-
-```yaml
-prometheusRule:
- enabled: true
- additionalLabels: {}
- namespace: ""
- rules:
- - alert: TooMany500s
- expr: 100 * ( sum( nginx_ingress_controller_requests{status=~"5.+"} ) / sum(nginx_ingress_controller_requests) ) > 5
- for: 1m
- labels:
- severity: critical
- annotations:
- description: Too many 5XXs
- summary: More than 5% of the all requests did return 5XX, this require your attention
-```
-
-Alerting rules allow you to define alert conditions based on Prometheus expressions and to send notifications about firing alerts to an external service.
-
-In this case, Prometheus will check that the alert continues to be active during each evaluation for 1 minute before firing the alert. Elements that are active, but not firing yet, are in the pending state.
-
-### Pod Labels
-Labels are key/value pairs that are attached to pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects.
-```yaml
-podLabels:
- severity: critical
-```
-
-### Pod Annotations
-Pod Annotations are widely used to attach metadata and configs in Kubernetes.
-
-```yaml
-podAnnotations:
- fluentbit.io/exclude: "true"
-```
-
-### Custom Metrics in HPA
-
-```yaml
-autoscaling:
- enabled: true
- MinReplicas: 1
- MaxReplicas: 2
- TargetCPUUtilizationPercentage: 90
- TargetMemoryUtilizationPercentage: 80
- behavior:
- scaleDown:
- stabilizationWindowSeconds: 300
- policies:
- - type: Percent
- value: 100
- periodSeconds: 15
- scaleUp:
- stabilizationWindowSeconds: 0
- policies:
- - type: Percent
- value: 100
- periodSeconds: 15
- - type: Pods
- value: 4
- periodSeconds: 15
- selectPolicy: Max
-```
-
-HPA, by default is configured to work with CPU and Memory metrics. These metrics are useful for internal cluster sizing, but you might want to configure wider set of metrics like service latency, I/O load etc. The custom metrics in HPA can help you to achieve this.
-
-### Wait For Seconds Before Scaling Down
-```yaml
-waitForSecondsBeforeScalingDown: 30
-```
-Wait for given period of time before scaling down the container.
-
-
-
-## 4. Show Application Metrics
-
-If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
-
-
-
-Once all the Deployment template configurations are done, click on `Save` to save your deployment configuration. Now you are ready to create [Workflow](../../workflow/README.md) to do CI/CD.
-
-### Helm Chart Json Schema Table
-
-Helm Chart json schema is used to validate the deployment template values.
-
-| Chart Version | Link |
-| :--- | :--- |
-| `reference-chart_3-12-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-12-0/schema.json) |
-| `reference-chart_3-11-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-11-0/schema.json) |
-| `reference-chart_3-10-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-10-0/schema.json) |
-| `reference-chart_3-9-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-9-0/schema.json) |
-
-
-### Other Validations in Json Schema
-
-The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
-```
-resources.limits.cpu >= resources.requests.cpu
-resources.limits.memory >= resources.requests.memory
-envoyproxy.resources.limits.cpu >= envoyproxy.resources.requests.cpu
-envoyproxy.resources.limits.memory >= envoyproxy.resources.requests.memory
-```
-
-## Addon features in Deployment Template Chart version 4.11.0
-
-### KEDA Autoscaling
-
-**Prerequisite:** KEDA controller should be installed in the cluster. To install KEDA controller using Helm, navigate to chart store and search for `keda` chart and deploy it. You can follow this [documentation](../../../deploy-chart/deployment-of-charts.md) for deploying a Helm chart on Devtron.
-
-KEDA Helm repo : https://kedacore.github.io/charts
-
-
-[KEDA](https://keda.sh) is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
-
-
-Example for autoscaling with KEDA using Prometheus metrics is given below:
-```yaml
-kedaAutoscaling:
- enabled: true
- minReplicaCount: 1
- maxReplicaCount: 2
- idleReplicaCount: 0
- pollingInterval: 30
- advanced:
- restoreToOriginalReplicaCount: true
- horizontalPodAutoscalerConfig:
- behavior:
- scaleDown:
- stabilizationWindowSeconds: 300
- policies:
- - type: Percent
- value: 100
- periodSeconds: 15
- triggers:
- - type: prometheus
- metadata:
- serverAddress: http://:9090
- metricName: http_request_total
- query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy",}
- threshold: "50"
- triggerAuthentication:
- enabled: false
- name:
- spec: {}
- authenticationRef: {}
-```
-
-Example for autosccaling with KEDA based on kafka is given below :
-
-```yaml
-kedaAutoscaling:
- enabled: true
- minReplicaCount: 1
- maxReplicaCount: 2
- idleReplicaCount: 0
- pollingInterval: 30
- advanced: {}
- triggers:
- - type: kafka
- metadata:
- bootstrapServers: b-2.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-3.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-1.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092
- topic: Orders-Service-ESP.info
- lagThreshold: "100"
- consumerGroup: oders-remove-delivered-packages
- allowIdleConsumers: "true"
- triggerAuthentication:
- enabled: true
- name: keda-trigger-auth-kafka-credential
- spec:
- secretTargetRef:
- - parameter: sasl
- name: keda-kafka-secrets
- key: sasl
- - parameter: username
- name: keda-kafka-secrets
- key: username
- authenticationRef:
- name: keda-trigger-auth-kafka-credential
-```
-
-### NetworkPolicy
-
-Kubernetes NetworkPolicies control pod communication by defining rules for incoming and outgoing traffic.
-
-```yaml
-networkPolicy:
- enabled: false
- annotations: {}
- labels: {}
- podSelector:
- matchLabels:
- role: db
- policyTypes:
- - Ingress
- - Egress
- ingress:
- - from:
- - ipBlock:
- cidr: 172.17.0.0/16
- except:
- - 172.17.1.0/24
- - namespaceSelector:
- matchLabels:
- project: myproject
- - podSelector:
- matchLabels:
- role: frontend
- ports:
- - protocol: TCP
- port: 6379
- egress:
- - to:
- - ipBlock:
- cidr: 10.0.0.0/24
- ports:
- - protocol: TCP
- port: 5978
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Enable or disable NetworkPolicy. |
-| `annotations` | Additional metadata or information associated with the NetworkPolicy. |
-| `labels` | Labels to apply to the NetworkPolicy.
-| `podSelector` | Each NetworkPolicy includes a podSelector which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty podSelector selects all pods in the namespace.|
-| `policyTypes` | Each NetworkPolicy includes a policyTypes list which may include either Ingress, Egress, or both. |
-| `Ingress` | Controls incoming traffic to pods. |
-| `Egress` | Controls outgoing traffic from pods. |
-
-
-### Winter-Soldier
-Winter Soldier can be used to
-- cleans up (delete) Kubernetes resources
-- reduce workload pods to 0
-
-**_NOTE:_** After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check [the main repo](https://github.com/devtron-labs/winter-soldier)
-
-Given below is template values you can give in winter-soldier:
-```yaml
-winterSoldier:
- enabled: false
- apiVersion: pincher.devtron.ai/v1alpha1
- action: sleep
- timeRangesWithZone:
- timeZone: "Asia/Kolkata"
- timeRanges: []
- targetReplicas: []
- fieldSelector: []
-```
-
-| Key | values | Description |
-| :--- | :--- | :--- |
-| `enabled` | `false`,`true` | decide the enabling factor |
-| `apiVersion` | `pincher.devtron.ai/v1beta1`, `pincher.devtron.ai/v1alpha1` | specific api version |
-| `action` | `sleep`,`delete`, `scale` | This specify the action need to perform. |
-| `timeRangesWithZone`:`timeZone` | eg:- `"Asia/Kolkata"`,`"US/Pacific"` | It use to specify the timeZone used. (It uses standard format. please refer [this](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)) |
-| `timeRangesWithZone`:`timeRanges` | array of [ `timeFrom`, `timeTo`, `weekdayFrom`, `weekdayTo`] | It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges. These settings will take `action` on Sat and Sun from 00:00 to 23:59:59, |
-| `targetReplicas` | `[n]` : n - number of replicas to scale. | These is mandatory field when the `action` is `scale` Default value is `[]`. |
-| `fieldSelector` | `- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now()) ` | These value will take a list of methods to select the resources on which we perform specified `action` . |
-
-
-here is an example,
-```yaml
-winterSoldier:
- apiVersion: pincher.devtron.ai/v1alpha1
- enabled: true
- annotations: {}
- labels: {}
- timeRangesWithZone:
- timeZone: "Asia/Kolkata"
- timeRanges:
- - timeFrom: 00:00
- timeTo: 23:59:59
- weekdayFrom: Sat
- weekdayTo: Sun
- - timeFrom: 00:00
- timeTo: 08:00
- weekdayFrom: Mon
- weekdayTo: Fri
- - timeFrom: 20:00
- timeTo: 23:59:59
- weekdayFrom: Mon
- weekdayTo: Fri
- action: scale
- targetReplicas: [1,1,1]
- fieldSelector:
- - AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '10h'), Now())
-```
-
-Above settings will take action on `Sat` and `Sun` from 00:00 to 23:59:59, and on `Mon`-`Fri` from 00:00 to 08:00 and 20:00 to 23:59:59. If `action:sleep` then runs hibernate at timeFrom and unhibernate at `timeTo`. If `action: delete` then it will delete workloads at `timeFrom` and `timeTo`. Here the `action:scale` thus it scale the number of resource replicas to `targetReplicas: [1,1,1]`. Here each element of `targetReplicas` array is mapped with the corresponding elements of array `timeRangesWithZone/timeRanges`. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
-
-The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
-
-- ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')
-- AddTime - This can be used to add time. For eg AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h') ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
-- Now - This can be used to get current time.
-- CpuToNumber - This can be used to compare CPU. For eg any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')}) will check if any resource.requests is less than 60Mi.
-
-
-
-### Security Context
-A security context defines privilege and access control settings for a Pod or Container.
-
-To add a security context for main container:
-```yaml
-containerSecurityContext:
- allowPrivilegeEscalation: false
-```
-
-To add a security context on pod level:
-```yaml
-podSecurityContext:
- runAsUser: 1000
- runAsGroup: 3000
- fsGroup: 2000
-```
-
-### Topology Spread Constraints
-You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
-
-```yaml
-topologySpreadConstraints:
- - maxSkew: 1
- topologyKey: zone
- whenUnsatisfiable: DoNotSchedule
- autoLabelSelector: true
- customLabelSelector: {}
-```
diff --git a/docs/user-guide/creating-application/base-config/deployment-template/statefulset.md b/docs/user-guide/creating-application/base-config/deployment-template/statefulset.md
deleted file mode 100644
index a628890375..0000000000
--- a/docs/user-guide/creating-application/base-config/deployment-template/statefulset.md
+++ /dev/null
@@ -1,991 +0,0 @@
-# StatefulSet
-
-The StatefulSet chart in Devtron allows you to deploy and manage stateful applications. StatefulSet is a Kubernetes resource that provides guarantees about the ordering and uniqueness of Pods during deployment and scaling.
-
-
-
-It supports only `ONDELETE` and `ROLLINGUPDATE` deployment strategy.
-
-
-
-
-You can select `StatefulSet` chart when you want to use only basic use cases which contain the following:
-
-* **Managing Stateful Applications:** StatefulSets are ideal for managing stateful applications, such as databases or distributed systems, that require stable network identities and persistent storage for each Pod.
-
-* **Ordered Pod Management:** StatefulSets ensure ordered and predictable management of Pods by providing each Pod with a unique and stable hostname based on a defined naming convention and ordinal index.
-
-* **Updating and Scaling Stateful Applications:** StatefulSets support updating and scaling stateful applications by creating new versions of the StatefulSet and performing rolling updates or scaling operations in a controlled manner, ensuring minimal disruption to the application.
-
-* **Persistent Storage:** StatefulSets have built-in mechanisms for handling persistent volumes, allowing each Pod to have its own unique volume claim and storage. This ensures data persistence even when Pods are rescheduled or restarted.
-
-* **Maintaining Pod Identity:** StatefulSets guarantee consistent identity for each Pod throughout its lifecycle. This stability is maintained even if the Pods are rescheduled, allowing applications to rely on stable network identities.
-
-* **Rollback Capability:** StatefulSets provide the ability to rollback to a previous version in case the current state of the application is unstable or encounters issues, ensuring a known working state for the application.
-
-* **Status Monitoring:** StatefulSets offer status information that can be used to monitor the deployment, including the current version, number of replicas, and the readiness of each Pod. This helps in tracking the health and progress of the StatefulSet deployment.
-
-* **Resource Cleanup:** StatefulSets allow for easy cleanup of older versions by deleting StatefulSets and their associated Pods and persistent volumes that are no longer needed, ensuring efficient resource utilization.
-
-{% hint style="warning" %}
-### Note
-Super-admins can lock keys in StatefulSet deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
-{% endhint %}
-
-
-## 1. Yaml File
-
-### Container Ports
-
-This defines ports on which application services will be exposed to other services
-
-```yaml
-ContainerPort:
- - envoyPort: 8799
- idleTimeout:
- name: app
- port: 8080
- servicePort: 80
- nodePort: 32056
- supportStreaming: true
- useHTTP2: true
-```
-
-| Key | Description |
-| :--- | :--- |
-| `envoyPort` | envoy port for the container. |
-| `idleTimeout` | the duration of time that a connection is idle before the connection is terminated. |
-| `name` | name of the port. |
-| `port` | port for the container. |
-| `servicePort` | port of the corresponding kubernetes service. |
-| `nodePort` | nodeport of the corresponding kubernetes service. |
-| `supportStreaming` | Used for high performance protocols like grpc where timeout needs to be disabled. |
-| `useHTTP2` | Envoy container can accept HTTP2 requests. |
-
-### EnvVariables
-```yaml
-EnvVariables: []
-```
-
-### EnvVariablesFromSecretKeys
-```yaml
-EnvVariablesFromSecretKeys:
- - name: ENV_NAME
- secretName: SECRET_NAME
- keyName: SECRET_KEY
-
-```
- It is used to get the name of Environment Variable name, Secret name and the Key name from which we are using the value in that corresponding Environment Variable.
-
- ### EnvVariablesFromConfigMapKeys
-```yaml
-EnvVariablesFromConfigMapKeys:
- - name: ENV_NAME
- configMapName: CONFIG_MAP_NAME
- keyName: CONFIG_MAP_KEY
-
-```
- It is used to get the name of Environment Variable name, Config Map name and the Key name from which we are using the value in that corresponding Environment Variable.
-
-To set environment variables for the containers that run in the Pod.
-### StatefulSetConfig
-These are all the configuration settings for the StatefulSet.
-```yaml
-statefulSetConfig:
- labels:
- app: my-statefulset
- environment: production
- annotations:
- example.com/version: "1.0"
- serviceName: "my-statefulset-service"
- podManagementPolicy: "Parallel"
- revisionHistoryLimit: 5
- mountPath: "/data"
- volumeClaimTemplates:
- - apiVersion: v1
- kind: PersistentVolumeClaim
- metadata:
- labels:
- app: my-statefulset
- spec:
- accessModes:
- - ReadWriteOnce
- dataSource:
- kind: Snapshot
- apiGroup: snapshot.storage.k8s.io
- name: my-snapshot
- resources:
- requests:
- storage: 5Gi
- limits:
- storage: 10Gi
- storageClassName: my-storage-class
- selector:
- matchLabels:
- app: my-statefulset
- volumeMode: Filesystem
- volumeName: my-pv
- - apiVersion: v1
- kind: PersistentVolumeClaim
- metadata:
- name: pvc-logs
- labels:
- app: myapp
- spec:
- accessModes:
- - ReadWriteMany
- dataSourceRef:
- kind: Secret
- apiGroup: v1
- name: my-secret
- resources:
- requests:
- storage: 5Gi
- storageClassName: my-storage-class
- selector:
- matchExpressions:
- - {key: environment, operator: In, values: [production]}
- volumeMode: Block
- volumeName: my-pv
-
-```
-Mandatoryfields in statefulSetConfig is
-```
-statefulSetConfig:
- mountPath: /tmp
- volumeClaimTemplates:
- - spec:
- accessModes:
- - ReadWriteOnce
- resources:
- requests:
- storage: 2Gi
-```
-Here is an explanation of each field in the statefulSetConfig :
-
-
-| Key | Description |
-| :--- | :--- |
-| `labels` | set of key-value pairs used to identify the StatefulSet . |
-| `annotations` | A map of key-value pairs that are attached to the stateful set as metadata. |
-| `serviceName` | The name of the Kubernetes Service that the StatefulSet should create. |
-| `podManagementPolicy` | A policy that determines how Pods are created and deleted by the StatefulSet. In this case, the policy is set to "Parallel", which means that all Pods are created at once. |
-| `revisionHistoryLimit` | The number of revisions that should be stored for each replica of the StatefulSet. |
-| `updateStrategy` | The update strategy used by the StatefulSet when rolling out changes. |
-| `mountPath` | The path where the volume should be mounted in the container. |
-
-volumeClaimTemplates: An array of volume claim templates that are used to create persistent volumes for the StatefulSet. Each volume claim template specifies the storage class, access mode, storage size, and other details of the persistent volume.
-
-
-| Key | Description |
-| :--- | :--- |
-| `apiVersion` | The API version of the PVC . |
-| `kind` | The type of object that the PVC is. |
-| `metadata` | Metadata that is attached to the resource being created. |
-| `labels` | A set of key-value pairs used to label the object for identification and selection. |
-| `spec` | The specification of the object, which defines its desired state and behavior.|
-| `accessModes` | A list of access modes for the PersistentVolumeClaim, such as "ReadWriteOnce" or "ReadWriteMany". |
-| `dataSource` | A data source used to populate the PersistentVolumeClaim, such as a Snapshot or a StorageClass. |
-| `kind`| specifies the kind of the snapshot, in this case Snapshot.|
-| `apiGroup`| specifies the API group of the snapshot API, in this case snapshot.storage.k8s.io.|
-| `name`| specifies the name of the snapshot, in this case my-snapshot.|
-| `dataSourceRef` | A reference to a data source used to create the persistent volume. In this case, it's a secret. |
-| `updateStrategy` | The update strategy used by the StatefulSet when rolling out changes. |
-| `resources` | The resource requests and limits for the PersistentVolumeClaim, which define the minimum and maximum amount of storage it can use. |
-| `requests` | The amount of storage requested by the PersistentVolumeClaim. |
-| `limits` | The maximum amount of storage that the PersistentVolumeClaim can use. |
-| `storageClassName` | The name of the storage class to use for the persistent volume. |
-| `selector` | The selector used to match a persistent volume to a persistent volume claim. |
-| `matchLabels` | a map of key-value pairs to match the labels of the corresponding PersistentVolume.|
-| `matchExpressions` |A set of requirements that the selected object must meet to be considered a match. |
-| `key` | The key of the label or annotation to match.|
-| `operator` | The operator used to compare the key-value pairs (in this case, "In" specifies a set membership test).|
-| `values` | A list of values that the selected object's label or annotation must match.|
-| `volumeMode` | The mode of the volume, either "Filesystem" or "Block". |
-| `volumeName` | The name of the PersistentVolume that is created for the PersistentVolumeClaim. |
-
-
-### Liveness Probe
-
-If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
-
-```yaml
-LivenessProbe:
- Path: ""
- port: 8080
- initialDelaySeconds: 20
- periodSeconds: 10
- successThreshold: 1
- timeoutSeconds: 5
- failureThreshold: 3
- httpHeaders:
- - name: Custom-Header
- value: abc
- scheme: ""
- tcp: true
-```
-
-| Key | Description |
-| :--- | :--- |
-| `Path` | It define the path where the liveness needs to be checked. |
-| `initialDelaySeconds` | It defines the time to wait before a given container is checked for liveliness. |
-| `periodSeconds` | It defines the time to check a given container for liveness. |
-| `successThreshold` | It defines the number of successes required before a given container is said to fulfil the liveness probe. |
-| `timeoutSeconds` | It defines the time for checking timeout. |
-| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as live. |
-| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
-| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
-| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
-
-
-### MaxUnavailable
-
-```yaml
- MaxUnavailable: 0
-```
-The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
-
-### MaxSurge
-
-```yaml
-MaxSurge: 1
-```
-The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count.
-The default value of "MaxSurge: " is 25%.
-
-### Min Ready Seconds
-
-```yaml
-MinReadySeconds: 60
-```
-This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
-
-### Readiness Probe
-
-If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
-
-```yaml
-ReadinessProbe:
- Path: ""
- port: 8080
- initialDelaySeconds: 20
- periodSeconds: 10
- successThreshold: 1
- timeoutSeconds: 5
- failureThreshold: 3
- httpHeaders:
- - name: Custom-Header
- value: abc
- scheme: ""
- tcp: true
-```
-
-| Key | Description |
-| :--- | :--- |
-| `Path` | It define the path where the readiness needs to be checked. |
-| `initialDelaySeconds` | It defines the time to wait before a given container is checked for readiness. |
-| `periodSeconds` | It defines the time to check a given container for readiness. |
-| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the readiness probe. |
-| `timeoutSeconds` | It defines the time for checking timeout. |
-| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as ready. |
-| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
-| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
-| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
-
-### Ambassador Mappings
-
-You can create ambassador mappings to access your applications from outside the cluster. At its core a Mapping resource maps a resource to a service.
-
-```yaml
-ambassadorMapping:
- ambassadorId: "prod-emissary"
- cors: {}
- enabled: true
- hostname: devtron.example.com
- labels: {}
- prefix: /
- retryPolicy: {}
- rewrite: ""
- tls:
- context: "devtron-tls-context"
- create: false
- hosts: []
- secretName: ""
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Set true to enable ambassador mapping else set false.|
-| `ambassadorId` | used to specify id for specific ambassador mappings controller. |
-| `cors` | used to specify cors policy to access host for this mapping. |
-| `weight` | used to specify weight for canary ambassador mappings. |
-| `hostname` | used to specify hostname for ambassador mapping. |
-| `prefix` | used to specify path for ambassador mapping. |
-| `labels` | used to provide custom labels for ambassador mapping. |
-| `retryPolicy` | used to specify retry policy for ambassador mapping. |
-| `corsPolicy` | Provide cors headers on flagger resource. |
-| `rewrite` | used to specify whether to redirect the path of this mapping and where. |
-| `tls` | used to create or define ambassador TLSContext resource. |
-| `extraSpec` | used to provide extra spec values which not present in deployment template for ambassador resource. |
-
-### Autoscaling
-
-This is connected to HPA and controls scaling up and down in response to request load.
-
-```yaml
-autoscaling:
- enabled: false
- MinReplicas: 1
- MaxReplicas: 2
- TargetCPUUtilizationPercentage: 90
- TargetMemoryUtilizationPercentage: 80
- extraMetrics: []
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Set true to enable autoscaling else set false.|
-| `MinReplicas` | Minimum number of replicas allowed for scaling. |
-| `MaxReplicas` | Maximum number of replicas allowed for scaling. |
-| `TargetCPUUtilizationPercentage` | The target CPU utilization that is expected for a container. |
-| `TargetMemoryUtilizationPercentage` | The target memory utilization that is expected for a container. |
-| `extraMetrics` | Used to give external metrics for autoscaling. |
-
-### Fullname Override
-
-```yaml
-fullnameOverride: app-name
-```
-`fullnameOverride` replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses {app-name}-{environment-name} as release fullname.
-
-### Image
-
-```yaml
-image:
- pullPolicy: IfNotPresent
-```
-
-Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
-
-### imagePullSecrets
-
-`imagePullSecrets` contains the docker credentials that are used for accessing a registry.
-
-```yaml
-imagePullSecrets:
- - regcred
-```
-regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry [https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) .
-
-### Ingress
-
-This allows public access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
-
-```yaml
-ingress:
- enabled: false
- # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
- className: nginx
- annotations: {}
- hosts:
- - host: example1.com
- paths:
- - /example
- - host: example2.com
- paths:
- - /example2
- - /example2/healthz
- tls: []
-```
-Legacy deployment-template ingress format
-
-```yaml
-ingress:
- enabled: false
- # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
- ingressClassName: nginx-internal
- annotations: {}
- path: ""
- host: ""
- tls: []
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Enable or disable ingress |
-| `annotations` | To configure some options depending on the Ingress controller |
-| `path` | Path name |
-| `host` | Host name |
-| `tls` | It contains security details |
-
-### Ingress Internal
-
-This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
-
-```yaml
-ingressInternal:
- enabled: false
- # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
- ingressClassName: nginx-internal
- annotations: {}
- hosts:
- - host: example1.com
- paths:
- - /example
- - host: example2.com
- paths:
- - /example2
- - /example2/healthz
- tls: []
-```
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | Enable or disable ingress |
-| `annotations` | To configure some options depending on the Ingress controller |
-| `path` | Path name |
-| `host` | Host name |
-| `tls` | It contains security details |
-
-### Init Containers
-```yaml
-initContainers:
- - reuseContainerImage: true
- securityContext:
- runAsUser: 1000
- runAsGroup: 3000
- fsGroup: 2000
- volumeMounts:
- - mountPath: /etc/ls-oms
- name: ls-oms-cm-vol
- command:
- - flyway
- - -configFiles=/etc/ls-oms/flyway.conf
- - migrate
-
- - name: nginx
- image: nginx:1.14.2
- securityContext:
- privileged: true
- ports:
- - containerPort: 80
- command: ["/usr/local/bin/nginx"]
- args: ["-g", "daemon off;"]
-```
-Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to `true`.
-
-### Istio
-
-Istio is a service mesh which simplifies observability, traffic management, security and much more with it's virtual services and gateways.
-
-```yaml
-istio:
- enable: true
- gateway:
- annotations: {}
- enabled: false
- host: example.com
- labels: {}
- tls:
- enabled: false
- secretName: example-tls-secret
- virtualService:
- annotations: {}
- enabled: false
- gateways: []
- hosts: []
- http:
- - corsPolicy:
- allowCredentials: false
- allowHeaders:
- - x-some-header
- allowMethods:
- - GET
- allowOrigin:
- - example.com
- maxAge: 24h
- headers:
- request:
- add:
- x-some-header: value
- match:
- - uri:
- prefix: /v1
- - uri:
- prefix: /v2
- retries:
- attempts: 2
- perTryTimeout: 3s
- rewriteUri: /
- route:
- - destination:
- host: service1
- port: 80
- timeout: 12s
- - route:
- - destination:
- host: service2
- labels: {}
-```
-
-| Key | Description |
-| :--- | :--- |
-| `istio` | Istio enablement. When `istio.enable` set to true, Istio would be enabled for the specified configurations |
-| `gateway` | Allowing external traffic to enter the service mesh through the specified configurations. |
-| `host` | The external domain through which traffic will be routed into the service mesh. |
-| `tls` | Traffic to and from the gateway should be encrypted using TLS. |
-| `secretName` | Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway. |
-| `virtualService` | Enables the definition of rules for how traffic should be routed to different services within the service mesh. |
-| `gateways` | Specifies the gateways to which the rules defined in the VirtualService apply. |
-| `hosts` | List of hosts (domains) to which this VirtualService is applied. |
-| `http` | Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies. |
-| `corsPolicy` | Cross-Origin Resource Sharing (CORS) policy configuration. |
-| `headers` | Additional headers to be added to the HTTP request. |
-| `match` | Conditions that need to be satisfied for this route to be used. |
-| `uri` | This specifies a match condition based on the URI of the incoming request. |
-| `prefix` | It specifies that the URI should have the specified prefix. |
-| `retries` | Retry configuration for failed requests. |
-| `attempts` | It specifies the number of retry attempts for failed requests. |
-| `perTryTimeout` | sets the timeout for each individual retry attempt. |
-| `rewriteUri` | Rewrites the URI of the incoming request. |
-| `route` | List of destination rules for routing traffic. |
-
-### Pause For Seconds Before Switch Active
-```yaml
-pauseForSecondsBeforeSwitchActive: 30
-```
-To wait for given period of time before switch active the container.
-
-### Resources
-
-These define minimum and maximum RAM and CPU available to the application.
-
-```yaml
-resources:
- limits:
- cpu: "1"
- memory: "200Mi"
- requests:
- cpu: "0.10"
- memory: "100Mi"
-```
-
-Resources are required to set CPU and memory usage.
-
-#### Limits
-
-Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
-
-#### Requests
-
-Requests are what the container is guaranteed to get.
-
-### Service
-
-This defines annotations and the type of service, optionally can define name also.
-
-```yaml
- service:
- type: ClusterIP
- annotations: {}
-```
-
-### Volumes
-
-```yaml
-volumes:
- - name: log-volume
- emptyDir: {}
- - name: logpv
- persistentVolumeClaim:
- claimName: logpvc
-```
-
-It is required when some values need to be read from or written to an external disk.
-
-### Volume Mounts
-
-```yaml
-volumeMounts:
- - mountPath: /var/log/nginx/
- name: log-volume
- - mountPath: /mnt/logs
- name: logpvc
- subPath: employee
-```
-
-It is used to provide mounts to the volume.
-
-### Affinity and anti-affinity
-
-```yaml
-Spec:
- Affinity:
- Key:
- Values:
-```
-
-Spec is used to define the desire state of the given container.
-
-Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
-
-Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
-
-#### Key
-
-Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
-
-#### Values
-
-Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
-
-### Tolerations
-
-```yaml
-tolerations:
- - key: "key"
- operator: "Equal"
- value: "value"
- effect: "NoSchedule|PreferNoSchedule|NoExecute(1.6 only)"
-```
-
-Taints are the opposite, they allow a node to repel a set of pods.
-
-A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
-
-Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
-
-### Arguments
-
-```yaml
-args:
- enabled: false
- value: []
-```
-
-This is used to give arguments to command.
-
-### Command
-
-```yaml
-command:
- enabled: false
- value: []
-```
-
-It contains the commands for the server.
-
-| Key | Description |
-| :--- | :--- |
-| `enabled` | To enable or disable the command. |
-| `value` | It contains the commands. |
-
-
-### Containers
-Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to `true`.
-
-```yaml
- containers:
- - name: nginx
- image: nginx:1.14.2
- ports:
- - containerPort: 80
- command: ["/usr/local/bin/nginx"]
- args: ["-g", "daemon off;"]
- - reuseContainerImage: true
- securityContext:
- runAsUser: 1000
- runAsGroup: 3000
- fsGroup: 2000
- volumeMounts:
- - mountPath: /etc/ls-oms
- name: ls-oms-cm-vol
- command:
- - flyway
- - -configFiles=/etc/ls-oms/flyway.conf
- - migrate
-```
-
-### Prometheus
-
-```yaml
- prometheus:
- release: monitoring
-```
-
-It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case.It describes the state of the prometheus.
-
-### rawYaml
-
-```yaml
-rawYaml:
- - apiVersion: v1
- kind: Service
- metadata:
- name: my-service
- spec:
- selector:
- app: MyApp
- ports:
- - protocol: TCP
- port: 80
- targetPort: 9376
- type: ClusterIP
-```
-Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
-
-### Grace Period
-
-```yaml
-GracePeriod: 30
-```
-Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the `GracePeriod`.
-
-A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
-
-There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
-
-
-### Server
-
-```yaml
-server:
- deployment:
- image_tag: 1-95a53
- image: ""
-```
-
-It is used for providing server configurations.
-
-#### Deployment
-
-It gives the details for deployment.
-
-| Key | Description |
-| :--- | :--- |
-| `image_tag` | It is the image tag |
-| `image` | It is the URL of the image |
-
-### Service Monitor
-
-```yaml
-servicemonitor:
- enabled: true
- path: /abc
- scheme: 'http'
- interval: 30s
- scrapeTimeout: 20s
- metricRelabelings:
- - sourceLabels: [namespace]
- regex: '(.*)'
- replacement: myapp
- targetLabel: target_namespace
-```
-
-It gives the set of targets to be monitored.
-
-### Db Migration Config
-
-```yaml
-dbMigrationConfig:
- enabled: false
-```
-
-It is used to configure database migration.
-
-
-### KEDA Autoscaling
-[KEDA](https://keda.sh) is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
-
-Example for autosccaling with KEDA using Prometheus metrics is given below:
-```yaml
-kedaAutoscaling:
- enabled: true
- minReplicaCount: 1
- maxReplicaCount: 2
- idleReplicaCount: 0
- pollingInterval: 30
- advanced:
- restoreToOriginalReplicaCount: true
- horizontalPodAutoscalerConfig:
- behavior:
- scaleDown:
- stabilizationWindowSeconds: 300
- policies:
- - type: Percent
- value: 100
- periodSeconds: 15
- triggers:
- - type: prometheus
- metadata:
- serverAddress: http://:9090
- metricName: http_request_total
- query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy",}
- threshold: "50"
- triggerAuthentication:
- enabled: false
- name:
- spec: {}
- authenticationRef: {}
-```
-Example for autosccaling with KEDA based on kafka is given below :
-```yaml
-kedaAutoscaling:
- enabled: true
- minReplicaCount: 1
- maxReplicaCount: 2
- idleReplicaCount: 0
- pollingInterval: 30
- advanced: {}
- triggers:
- - type: kafka
- metadata:
- bootstrapServers: b-2.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-3.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-1.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092
- topic: Orders-Service-ESP.info
- lagThreshold: "100"
- consumerGroup: oders-remove-delivered-packages
- allowIdleConsumers: "true"
- triggerAuthentication:
- enabled: true
- name: keda-trigger-auth-kafka-credential
- spec:
- secretTargetRef:
- - parameter: sasl
- name: keda-kafka-secrets
- key: sasl
- - parameter: username
- name: keda-kafka-secrets
- key: username
- authenticationRef:
- name: keda-trigger-auth-kafka-credential
-```
-### Winter-Soldier
-Winter Soldier can be used to
-- cleans up (delete) Kubernetes resources
-- reduce workload pods to 0
-
-**_NOTE:_** After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check [the main repo](https://github.com/devtron-labs/winter-soldier)
-
-Given below is template values you can give in winter-soldier:
-```yaml
-winterSoilder:
- enable: false
- apiVersion: pincher.devtron.ai/v1alpha1
- action: sleep
- timeRangesWithZone:
- timeZone: "Asia/Kolkata"
- timeRanges: []
- targetReplicas: []
- fieldSelector: []
-```
-Here,
-| Key | values | Description |
-| :--- | :--- | :--- |
-| `enable` | `false`,`true` | decide the enabling factor |
-| `apiVersion` | `pincher.devtron.ai/v1beta1`, `pincher.devtron.ai/v1alpha1` | specific api version |
-| `action` | `sleep`,`delete`, `scale` | This specify the action need to perform. |
-| `timeRangesWithZone`:`timeZone` | eg:- `"Asia/Kolkata"`,`"US/Pacific"` | It use to specify the timeZone used. (It uses standard format. please refer [this](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)) |
-| `timeRangesWithZone`:`timeRanges` | array of [ `timeFrom`, `timeTo`, `weekdayFrom`, `weekdayTo`] | It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges. These settings will take `action` on Sat and Sun from 00:00 to 23:59:59, |
-| `targetReplicas` | `[n]` : n - number of replicas to scale. | These is mandatory field when the `action` is `scale` Default value is `[]`. |
-| `fieldSelector` | `- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now()) ` | These value will take a list of methods to select the resources on which we perform specified `action` . |
-
-
-here is an example,
-```yaml
-winterSoilder:
- apiVersion: pincher.devtron.ai/v1alpha1
- enable: true
- annotations: {}
- labels: {}
- timeRangesWithZone:
- timeZone: "Asia/Kolkata"
- timeRanges:
- - timeFrom: 00:00
- timeTo: 23:59:59
- weekdayFrom: Sat
- weekdayTo: Sun
- - timeFrom: 00:00
- timeTo: 08:00
- weekdayFrom: Mon
- weekdayTo: Fri
- - timeFrom: 20:00
- timeTo: 23:59:59
- weekdayFrom: Mon
- weekdayTo: Fri
- action: scale
- targetReplicas: [1,1,1]
- fieldSelector:
- - AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '10h'), Now())
-```
-Above settings will take action on `Sat` and `Sun` from 00:00 to 23:59:59, and on `Mon`-`Fri` from 00:00 to 08:00 and 20:00 to 23:59:59. If `action:sleep` then runs hibernate at timeFrom and unhibernate at `timeTo`. If `action: delete` then it will delete workloads at `timeFrom` and `timeTo`. Here the `action:scale` thus it scale the number of resource replicas to `targetReplicas: [1,1,1]`. Here each element of `targetReplicas` array is mapped with the corresponding elements of array `timeRangesWithZone/timeRanges`. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
-
-The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
-
-- ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')
-- AddTime - This can be used to add time. For eg AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h') ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
-- Now - This can be used to get current time.
-- CpuToNumber - This can be used to compare CPU. For eg any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')}) will check if any resource.requests is less than 60Mi.
-
-
-
-### Security Context
-A security context defines privilege and access control settings for a Pod or Container.
-
-To add a security context for main container:
-```yaml
-containerSecurityContext:
- allowPrivilegeEscalation: false
-```
-
-To add a security context on pod level:
-```yaml
-podSecurityContext:
- runAsUser: 1000
- runAsGroup: 3000
- fsGroup: 2000
-```
-
-### Topology Spread Constraints
-You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
-
-```yaml
-topologySpreadConstraints:
- - maxSkew: 1
- topologyKey: zone
- whenUnsatisfiable: DoNotSchedule
- autoLabelSelector: true
- customLabelSelector: {}
-```
-
-### Deployment Metrics
-
-It gives the realtime metrics of the deployed applications
-
-| Key | Description |
-| :--- | :--- |
-| `Deployment Frequency` | It shows how often this app is deployed to production |
-| `Change Failure Rate` | It shows how often the respective pipeline fails. |
-| `Mean Lead Time` | It shows the average time taken to deliver a change to production. |
-| `Mean Time to Recovery` | It shows the average time taken to fix a failed pipeline. |
-
-## 2. Show application metrics
-
-If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
-
-
-
-Once all the Deployment template configurations are done, click on `Save` to save your deployment configuration. Now you are ready to create [Workflow](../../workflow/README.md) to do CI/CD.
-
-### Helm Chart Json Schema
-
-Helm Chart [json schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_5-1-0/schema.json) is used to validate the deployment template values.
-
-### Other Validations in Json Schema
-
-The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
-```
-resources.limits.cpu >= resources.requests.cpu
-resources.limits.memory >= resources.requests.memory
-envoyproxy.resources.limits.cpu >= envoyproxy.resources.requests.cpu
-envoyproxy.resources.limits.memory >= envoyproxy.resources.requests.memory
-```
diff --git a/docs/user-guide/creating-application/base-config/eso/README.md b/docs/user-guide/creating-application/base-config/eso/README.md
old mode 100644
new mode 100755
index c37f70c4af..38a9955144
--- a/docs/user-guide/creating-application/base-config/eso/README.md
+++ b/docs/user-guide/creating-application/base-config/eso/README.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Types of External Secrets
Apart from the provision to add Secrets, Devtron supports the addition of External Secrets too including:
@@ -7,6 +11,7 @@ Apart from the provision to add Secrets, Devtron supports the addition of Extern
* [HashiCorp Vault](hashicorp-eso.md)
* Azure Secrets Manager
-
+
+
List of External Secrets
However make sure to install [ESO chart](install-eso.md) to your cluster before adding any of the above external secrets.
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/eso/aws-eso.md b/docs/user-guide/creating-application/base-config/eso/aws-eso.md
old mode 100644
new mode 100755
index 6c7273b9ff..ee6686924d
--- a/docs/user-guide/creating-application/base-config/eso/aws-eso.md
+++ b/docs/user-guide/creating-application/base-config/eso/aws-eso.md
@@ -1,9 +1,8 @@
# AWS Secrets Manager
-{% hint style="warning" %}
-### Prerequisite
+:::caution Prerequisite
Install [External Secret Operator (ESO)](install-eso.md).
-{% endhint %}
+:::
To add secrets from **AWS Secrets Manager**, we need to create a generic Kubernetes secret for AWS authentication.
@@ -11,17 +10,20 @@ Create a Kubernetes secret in the namespace in which the application is to be de
**Note**: You don't have to create the Kubernetes secret every time you create external secret for the respective namespace.
-
+
+
Figure 1: Create Kubernetes Secret for AWS Authentication
After creating the generic secret, navigate to `Secrets` section of the application and follow the steps mentioned below :
1. Click `Add Secret` to add a new secret
- 
+ 
+
Figure 2: Add a New Secret
2. Select `AWS Secret Manager` under `External Secret Operator` (ESO) from the dropdown of `Data type`
- 
+ 
+
Figure 3: Select AWS Secrets Manager
3. Configure the secret.
@@ -36,9 +38,11 @@ After creating the generic secret, navigate to `Secrets` section of the applicat
| `key` | AWS Secrets Manager secret name |
| `property` | AWS Secrets Manager secret key |
- 
+ 
+
4. Save the secret.
@@ -56,19 +60,22 @@ To setup ESO AWS secrets manager with Devtron using ClusterSecretsStore, follow
Create a Kubernetes secret in any namespace using base64 encoded AWS access-key and secret-access-key. You can use the devtron generic chart for this.
-
+
+
Figure 6: Use Generic Chart
**2. Create a `ClusterSecretStore`**
Create a `ClusterSecretStore` using the secret created for AWS authentication in step 1.
-
+
+
Figure 7: Create ClusterSecretStore
**3. Create a secret in the application using ESO AWS Secrets Manager**
Go to the application where you want to create an external secret. Navigate to secrets section under application configuration and create a secret using ESO AWS Secrets Manager.
-
+
+
Figure 8: Create Secret
\ No newline at end of file
+
+
Figure 11: Application Secrets
-->
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/eso/gcp-eso.md b/docs/user-guide/creating-application/base-config/eso/gcp-eso.md
old mode 100644
new mode 100755
index 435dabd294..8e550869c7
--- a/docs/user-guide/creating-application/base-config/eso/gcp-eso.md
+++ b/docs/user-guide/creating-application/base-config/eso/gcp-eso.md
@@ -1,47 +1,59 @@
+---
+hide_table_of_contents: true
+---
+
# Google Secrets Manager
-{% hint style="warning" %}
-### Prerequisite
+:::caution Prerequisite
Install [External Secret Operator (ESO)](install-eso.md).
-{% endhint %}
+:::
To add secrets from **Google Secrets Manager**, follow the steps mentioned below :
1. Go to Google cloud console and create a Service Account.
- 
+ 
+
Figure 1a: Create Service Account
- 
+ 
+
Figure 1b: Service Account Creation
2. Assign roles to the service account.
- 
+ 
+
Figure 2: Assign Service Account Roles
3. Add and create a new key.
- 
+ 
+
Figure 3a: Add Service Account Key
- 
+ 
+
Figure 3b: Create Service Account Key
4. Create a Kubernetes secret in the namespace in which the application is to be deployed using base64 encoded service account key.
You can use devtron generic chart for this.
- 
+ 
+
Figure 4: Create Kubernetes Secret
5. After creating the generic secret, navigate to `Secrets` section of the application and click `Add Secret` to add a new secret.
- 
+ 
+
Figure 5: Add New Secret
6. Select `Google Secrets Manager` under `External Secret Operator` (ESO) from the dropdown of `Data type`.
- 
+ 
+
8. Save secret.
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/base-config/eso/hashicorp-eso.md b/docs/user-guide/creating-application/base-config/eso/hashicorp-eso.md
old mode 100644
new mode 100755
index 7b706f2364..8cac4d8585
--- a/docs/user-guide/creating-application/base-config/eso/hashicorp-eso.md
+++ b/docs/user-guide/creating-application/base-config/eso/hashicorp-eso.md
@@ -1,9 +1,12 @@
+---
+hide_table_of_contents: true
+---
+
# HashiCorp Vault
-{% hint style="warning" %}
-### Prerequisite
+:::caution Prerequisite
Install [External Secret Operator (ESO)](install-eso.md).
-{% endhint %}
+:::
To incorporate secrets from **HashiCorp Vault**, you need to create a generic Kubernetes secret that will be used for vault authentication. This involves creating a Kubernetes secret in the specific namespace where your application will be deployed.
The secret should store the base64-encoded password or token obtained from vault. To simplify the process, you can utilize the Devtron generic chart. An example yaml is given below:
@@ -27,19 +30,22 @@ Once you have created the generic secret, follow these steps in the application'
To add a new secret to the application, go to the **Configurations** page of the application. Then, navigate to the left pane and select the `Secrets` option and click the **Add Secret** button.
-
+
+
Figure 1: Add a New Secret
**2. Select `HashiCorp Vault` as the External Secret Operator**
After clicking the **Add Secret** button, select `HashiCorp Vault` from the dropdown menu for the `Data type` option. Provide a name for the secret you are creating, and then proceed to configure the external secret as described in the next step.
-
+
+
Figure 2: Select HashiCorp Vault as External Secret Operator
**3. Configure the secret**
To configure the external secret that will be fetched from HashiCorp Vault for your application, you will need to provide specific details using the following key-value pairs:
-
+
+
| Key | Description |
@@ -52,9 +58,11 @@ To configure the external secret that will be fetched from HashiCorp Vault for y
| `key` | Enter the name of the secret in Vault |
| `property` | Specify the key within the Vault secret |
-
+
+
**4. Save the secret**
diff --git a/docs/user-guide/creating-application/base-config/eso/install-eso.md b/docs/user-guide/creating-application/base-config/eso/install-eso.md
old mode 100644
new mode 100755
index e191d2fa3e..1613b5f010
--- a/docs/user-guide/creating-application/base-config/eso/install-eso.md
+++ b/docs/user-guide/creating-application/base-config/eso/install-eso.md
@@ -1,12 +1,15 @@
# Install ESO
-{% hint style="info" %}
-### Prerequisites
+:::info Prerequisites
Chart version should be > 4.14.0
-{% endhint %}
+:::
+
+## Introduction
External Secrets Operator is a Kubernetes operator that integrates external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault and many more. The operator reads information from external APIs and automatically injects the values into a Kubernetes Secret.
+---
+
## Install External Secret Operator
Before creating any external secrets on Devtron, `External Secret Operator` must be installed on the target cluster. `External Secret Operator` allows you to use external secret management systems (e.g., AWS Secrets Manager, Hashicorp Vault, Azure Secrets Manager, Google Secrets Manager etc.) to securely inject secrets in Kubernetes.
@@ -16,7 +19,8 @@ You can install `External Secrets Operator` using charts store:
1. Go to the **Charts Store**.
2. Search the chart named `external-secrets`.
-
+
+
Figure 1: External Secrets Chart
3. If you don't find any chart with this name i.e `external-secrets`, add chart repository using repository url ` https://charts.external-secrets.io`. Please follow this [documentation](../../../global-configurations/chart-repo.md#add-chart-repository) for adding chart repository.
diff --git a/docs/user-guide/creating-application/base-config/eso/secrets.md b/docs/user-guide/creating-application/base-config/eso/secrets.md
old mode 100644
new mode 100755
index 2262b83e31..8d273890ca
--- a/docs/user-guide/creating-application/base-config/eso/secrets.md
+++ b/docs/user-guide/creating-application/base-config/eso/secrets.md
@@ -8,11 +8,13 @@ Simply put, if a [ConfigMap](../config-maps.md) is a recipe card in the kitchen,
1. Go to the **Configurations** → **Base Configurations**.
- 
+ 
+
Figure 1: Application's 'Configurations' Page
2. Click the **+** button next to **Secrets**.
- 
+ 
+
Figure 2: Add Button
3. **Data Type** - Choose between the following data types:
* [Kubernetes Secret](#kubernetes-secret)
@@ -27,17 +29,18 @@ Simply put, if a [ConfigMap](../config-maps.md) is a recipe card in the kitchen,
2. **Name** - Provide a name to your Secret (cannot be changed later).
- 
+ 
+
Figure 3: Naming the Secret
3. **Mount data as** - Select how you want to mount the Secret:
* **Environment Variable** – Select this option if you want to inject Environment Variables in pods using Secret.
- * **Data Volume** – Select this option, if you want to configure a Data Volume that is accessible to Containers running in a pod and provide a Volume mount path. Go to [Data Volume](#mount-data-as-data-valume) to know more.
+ * **Data Volume** – Select this option, if you want to configure a Data Volume that is accessible to Containers running in a pod and provide a Volume mount path. Go to [Data Volume](#mount-data-as-data-volume) to know more.
4. Enter data in:
- **GUI mode** – User-friendly interface. Click **+Add** button and enter the **Key** and **Value** fields without quotes.
- **YAML mode** – Raw YAML for entering key-value pairs in the format **`key: value`**. Boolean and numeric values must be wrapped in double quotes.
- {% embed url="https://www.youtube.com/watch?v=x6IIr6pDZig" %}
+
5. You may [perform a dry run](#perform-a-dry-run) before clicking **Save**.
@@ -49,7 +52,7 @@ Use this option to mount an existing Kubernetes Secret in your application pods.
2. **Name** - Make sure you give the same name as the existing secret. Otherwise, it might result in an error during the build.
-3. Mount data as: **Environment Variable** or [Data Volume](#mount-data-as-data-valume)
+3. Mount data as: **Environment Variable** or [Data Volume](#mount-data-as-data-volume)
4. Click **Save**.
@@ -61,17 +64,20 @@ Use this option to mount an existing Kubernetes Secret in your application pods.
In the above example, we have seen how to pass environment variables in your Secret. Additionally, there is an option to mount a Secret by passing its content to a file. The content could be a plain text, json, yaml, bash script, etc. You can do so by selecting the `Data Volume` option in **Mount data as**.
-
+
+
Figure 4: Naming the Secret
The key of the Secret should be your filename and the value of the Secret should be your file content. In the below example, you `file.json` is the key, and the json content is the value of that Secret (below the pipe (**|**) symbol). This file will be created on your specified [volume mount path](#volume-mount-path).
-
+
+
Figure 5: Adding File Content
### Volume Mount Path
Enter the folder path where the data volume should be mounted for it to be accessible to the containers running in a pod. Your keys will be mounted as files to that volume.
-
+
+
Figure 6: Selecting Data Volume Option
### Set Sub Path
@@ -81,11 +87,10 @@ When mounting multiple files to the same location, you can use the **Set Sub Pat
* If **Set Sub Path** is disabled (unchecked), the system will delete any files already present in the [specified path](#volume-mount-path) and then mount the new files.
-{% hint style="info" %}
-### Note
+:::info Note
In case of Kubernetes Secrets, all keys will be mounted as files on the specified path.
In case of External Secrets, manually specify the keys which should be mounted as files.
-{% endhint %}
+:::
### Set File Permission
@@ -117,7 +122,8 @@ Before saving your configured Secret, you can use the **Dry Run** option (as sho
This feature helps you verify your configurations, detect issues, and ensure correctness.
-
+
+
Figure 7: Performing a Dry Run
Your configurations will appear in the left pane, while the right pane will display a section named `Manifest generated from merged` showing the computed Kubernetes manifest.
@@ -129,12 +135,12 @@ Your configurations will appear in the left pane, while the right pane will disp
2. Modify its values.
3. Click **Update**.
-{% hint style="warning" %}
-### Note
+:::caution Note
You cannot change the name of a Secret. Create a new Secret instead.
-{% endhint %}
+:::
-
+
+
Figure 8: Updating Existing Secret
---
@@ -147,24 +153,24 @@ You may delete a Secret if not in use anymore. Once a Secret is deleted, it will
3. Click **Delete**.
4. Confirm the deletion in the dialogbox.
-
+
+
Figure 9: Deleting Secret
---
-## Edit a Protected Secret [](https://devtron.ai/pricing)
+## Edit a Protected Secret
Any changes made to the protected base configurations (Deployment Template, ConfigMap, Secret) will require approval if an [approval policy](../../../global-configurations/approval-policy.md) is enforced.
-{% embed url="https://www.youtube.com/watch?v=pJPX-rJNb_o" %}
+
---
## External Secret Operator (ESO)
-{% hint style="info" %}
-### Prerequisite
+:::info Prerequisite
Chart version should be > 4.14.0
-{% endhint %}
+:::
### Purpose
@@ -182,16 +188,17 @@ External Secrets Operator (ESO) is a Kubernetes component that integrates with e
2. Search for the `external-secrets` chart.
- 
+ 
+
Figure 10: Searching External Secrets Chart
-{% hint style="info" %}
-### What if external-secrets chart is not found?
+:::info What if external-secrets chart is not found?
Manually add the following chart repository URL in Devtron: `https://charts.external-secrets.io`. Follow this [guide](../../../global-configurations/chart-repo.md#add-chart-repository) to know the steps.
-{% endhint %}
+:::
3. Give a name to the helm app that will be created from the chart. Also enter the project and environment where you wish to install the chart.
- 
+ 
+
Figure 11: Adding Details
4. Click **Deploy Chart**.
diff --git a/docs/user-guide/creating-application/base-config/secrets.md b/docs/user-guide/creating-application/base-config/secrets.md
old mode 100644
new mode 100755
index 0c5395ab0d..3057edb1a4
--- a/docs/user-guide/creating-application/base-config/secrets.md
+++ b/docs/user-guide/creating-application/base-config/secrets.md
@@ -1,60 +1,59 @@
# Secrets
-### Introduction
-
Secrets and configmaps both are used to store environment variables but there is one major difference between them: Configmap stores key-values in normal text format while secrets store them in base64 encrypted form. Devtron hides the data of secrets for the normal users and it is only visible to the users having edit permission.
Secret objects let you store and manage sensitive information, such as passwords, authentication tokens, and ssh keys. Embedding this information in secrets is safer and more flexible than putting it verbatim in a Pod definition or in a container image.
----
+## Add Secret
-## Configure Secret
+1. Go to **Application Management** → **Devtron Applications** → (Select Your App)
-
+ 
+
Figure 1: Navigating to App Configurations
-Click `Add Secret` to add a new secret.
+2. Go to **Configurations** (tab) → **Base Configurations**.
-
+ 
+
Figure 2: Application's 'Configurations' Page
-| Key | Description |
-| :--- | :--- |
-| `Name` | Provide a name to your Secret |
-| `Data Type` | Provide the Data Type of your secret. To know about different Data Types available click on [Data Types](secrets.md#data-types) |
-| `Data Volume` | Specify if there is a need to add a volume that is accessible to the Containers running in a pod. |
-| `Use secrets as Environment Variable` | Select this option if you want to inject Environment Variables in your pods using Secrets. |
-| `Use secrets as Data Volume` | Select this option if you want to configure a Data Volume that is accessible to Containers running in a pod. Ensure that you provide a Volume mount path for the same. |
-| `Key-Value` | Provide a key and the corresponding value of the provided key. |
+3. Click the **+** button next to **ConfigMaps**.
----
+ 
+
Figure 3: Adding Secret
+
+ | Key | Description |
+ | :--- | :--- |
+ | `Name` | Provide a name to your Secret |
+ | `Data Type` | Provide the Data Type of your secret. To know about different Data Types available click on [Data Types](secrets.md#data-types) |
+ | `Data Volume` | Specify if there is a need to add a volume that is accessible to the Containers running in a pod. |
+ | `Use secrets as Environment Variable` | Select this option if you want to inject Environment Variables in your pods using Secrets. |
+ | `Use secrets as Data Volume` | Select this option if you want to configure a Data Volume that is accessible to Containers running in a pod. Ensure that you provide a Volume mount path for the same. |
+ | `Key-Value` | Provide a key and the corresponding value of the provided key. |
+
+4. Enter data in:
+ * **GUI mode** – User-friendly interface. Click **+Add** button and enter the **Key** and **Value** fields without quotes.
+ * **YAML mode** – Raw YAML for entering key-value pairs in the format **`key: value`**. Boolean and numeric values must be wrapped in double quotes.
+
+ 
+
Figure 4: Entering the Details
+
+5. You may perform a dry run before clicking **Save**.
## Volume Mount Path
Specify the volume mount folder path in `Volume Mount Path`, a path where the data volume needs to be mounted. This volume will be accessible to the containers running in a pod.
-
-
----
+
+
Figure 5: Entering Volume Mount Path
## Sub Path
For multiple files mount at the same location you need to check sub path `bool` field, it will use the file name (key) as sub path.
Sub Path feature is not applicable in case of external configmap except
AWS Secret Manager, AWS System Manager and Hashi Corp Vault, for these cases `Name (Secret key)` as sub path will be picked up automatically.
----
-
## File Permission
+File permission will be provide at the configmap level not on the each key of the configmap. it will take 3 digit standard permission for the file.
-File permission will be provided at the ConfigMap level not on the each key of the ConfigMap. it will take 3 digit standard permission for the file.
-
-Click `Save Secret` to save the secret.
-
-
-
-You can see the Secret is added.
-
-
-
----
## Update Secrets
@@ -62,99 +61,17 @@ You can update your secrets anytime later, but you cannot change the name of you
To update secrets, click the secret you wish to update.
-
+
+
Figure 6: Updating Existing Secret
Click `Update Secret` to update your secret.
----
-
## Delete Secret
You can delete your secret. Click your secret and click the `delete sign` to delete your secret.
-
-
----
-
-## Edit a Protected Secret [](https://devtron.ai/pricing)
-
-Any changes made to the protected base configurations (Deployment Template, ConfigMap, Secret) will require approval if an [approval policy](../../../user-guide/global-configurations/approval-policy.md) is enforced. When you want to edit a protected configuration, you can do it in the following ways:
-
-* [Normal Edit](#normal-edit) - Where changes to the protected configuration can be proposed or pushed as a draft, but published only after getting approval from the approver(s).
-
-* [Express Edit](#express-edit) - Where you bypass the approval process and directly make changes to the protected configuration.
-
-### Normal Edit
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
-Only a Super-Admin, Manager, or an Admin can edit the configuration values. Refer to [User Permissions](../../global-configurations/authorization/user-access.md) for more information.
-
-{% endhint %}
-
-Follow the below steps to edit a protected Secret:
-
-1. Navigate to the **Applications** page and click on your preferred application.
-
-2. Go to the **Configurations** → **Base Configurations**.
-
-3. Click on **Secrets** and select the Secret you'd like to edit.
-
-4. Modify the values either by using **GUI** or **YAML** editor.
-
-5. Click **Save Changes**. The Base Configurations pop-up page will be displayed.
-
- * **Save as draft** - Select this option if you want to continue making your changes later but save your changes as a draft for now.
-
- * **Propose changes** - Select this option if you want to propose your changes to the approvers. You can then select the approvers to get notified regarding the change from the **Select approvers** to notify drop-down box.
-
-6. Enter your comments (reason for making the changes) in the **Comment** text box.
-
-7. Click **Propose Changes**. The corresponding approver will be notified via email regarding your request.
-
-### Express Edit
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
-Only a Super-Admin (when the [Super admins toggle](../../global-configurations/approval-policy.md#excluding-super-admins) is enabled in the Exceptions tab) or [specific users / user groups](../../global-configurations/approval-policy.md#excluding-specific-users--user-groups--api-tokens) who are added as exceptions in the Approval Policy can make express edits. Refer to [Approval Policy](../../global-configurations/approval-policy.md) for more information.
-
-{% endhint %}
-
-Express edits allow you to bypass the approval process and make direct edits to the configurations. Follow the below steps to make express edits:
-
-1. Navigate to the **Applications** page and click on your preferred application.
-
-2. Go to the **Configurations** → **Base Configurations**.
-
-3. Click on **Secrets** and select the Secret you'd like to edit.
-
-4. Click on the **Edit** button.
-
-{% hint style="info" %}
-
-### Note
-
-The **Edit** button will only be displayed if:
-
-* You are a Super-Admin and the Super admins toggle is enabled in the Approval Policy page
-
-* You are added as an exception in the Approval Policy page.
-
-Refer to [Approval Policy](../../global-configurations/approval-policy.md) for more information.
-
-{% endhint %}
-
-5. Modify the values either by using **GUI** or **YAML** editor.
-
-6. Click on **Publish Changes** to direcly publish your changes.
-
-
-
----
+
+
Figure 7: Deleting a Secret
## Data Types
@@ -209,14 +126,16 @@ $ helm install my-release external-secrets/kubernetes-external-secrets --set sec
To add secrets from AWS secret manager, navigate to `Secrets` of the application and follow the steps mentioned below :
-
-
1. Click `Add Secret` to add a new secret.
-
+ 
+
Figure 8: Adding New Secret
2. Select `AWS Secret Manager` from dropdown of `Data type`.
+ 
+
Figure 9: Choosing AWS Secrets Manager
+
3. Provide a name to your secret.
4. Select how you want to use the secret. You may leave it selected as environment variable and also you may leave `Role ARN` empty.
@@ -240,4 +159,5 @@ To add secrets in AWS secret manager, do the following steps :
2. Click `Store a new secret`.
3. Add and save your secret.
-
\ No newline at end of file
+ 
+
Figure 10: Storing Secret in AWS Secrets Manager
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/config-approval.md b/docs/user-guide/creating-application/config-approval.md
deleted file mode 100644
index 5b880ce399..0000000000
--- a/docs/user-guide/creating-application/config-approval.md
+++ /dev/null
@@ -1,134 +0,0 @@
-# Protect Configuration
-
-## Introduction [](https://devtron.ai/pricing)
-
-Since resources are created according to the configurations you enter, it's essential to restrict such configurations from direct modifications. For critical environments like production, it becomes necessary to introduce an approval flow for any edits made to the configuration files.
-
-In Devtron, these configurations are present in the **App Configuration** tab of your application.
-
-Any changes made to the following configurations will require approval if enabled:
-
-- Deployment Template
-- ConfigMaps
-- Secrets
-
-This stands true for both: base configuration and respective environment-level configuration.
-
-
-
-
-
----
-
-## Tutorial
-
-{% embed url="https://www.youtube.com/watch?v=TVLEbY850hI" caption="Protect Configuration and Approval" %}
-
----
-
-## Changing the Configuration Values
-
-{% hint style="info" %}
-Only a super-admin, manager, and admin can edit the configuration values.
-{% endhint %}
-
-Let's assume you are the application admin and you wish to edit the deployment template of your environment (as an override).
-
-1. Go to the `App Configuration` tab.
-
-2. In Environment Overrides → (choose your environment) → Deployment Template
-
- 
-
-3. You can change the value of a key to a desired value as shown below. Once done, click the **Save Changes…** button.
-
- 
-
-{% hint style="info" %}
-If you are not a super-admin, you cannot modify the locked keys in deployment template. Refer [Lock Deployment Configuration](../global-configurations/lock-deployment-config.md) to know more.
-{% endhint %}
-
-4. If the configuration is protected, your changes won't be published right away. You can do either of the following:
-
- * **Save as draft** : Selecting this option will save your file as a draft. You and other users can view and edit the saved draft and propose it further for approval.
- * **Save & Propose Changes** : Selecting this option will propose your changes to a configuration approver for a review.
-
- Since we are proposing the changes immediately, click **Propose Changes**.
-
- 
-
-5. You can also view the approver(s) if you wish.
-
- 
-
-{% hint style="info" %}
-The one who performs the edits cannot approve their own changes. A different user has to review and approve.
-{% endhint %}
-
-Only one draft can exist at time and you cannot create multiple drafts. In the top-right corner, you have the option to discard the draft if you don't wish to proceed with the edits you made.
-
----
-
-## Approving the Configuration
-
-{% hint style="info" %}
-Only a different super-admin user or someone (who is not amongst the editors of the draft), having `Configuration approver` access, can approve the changes made to the configuration files.
-{% endhint %}
-
-Go to the edited configuration file to review and approve the changes as shown below.
-
-
-
-A super-admin can check whether a user has approval rights by going to **Global Configurations** → **Authorization** (dropdown) → **User Permissions**.
-
-
-
-
----
-
-## Deploying with New Configuration Values
-
-Once the approver validates and approves your configuration changes, you can proceed to deploy your application with the updated configuration.
-
-1. Go to the **Build & Deploy** tab of your application.
-
-2. Click **Select Image** in the deployment flow.
-
- 
-
-3. You can view an indicator at the bottom `Config Diff from Last Deployed`. Click **Review** to view the changes.
-
- 
-
-{% hint style="info" %}
-If the new configuration is not yet approved, the changes made to the config would not be visible during deployment, it would show `No Config Diff from Last Deployed` at the bottom. In that case, check whether your changes are present in the live config or not. If your changes are absent, chances are your draft is either pending for approval or rejected (discarded).
-{% endhint %}
-
-4. Once you have verified the changes, you can click **Deploy**.
-
- 
-
-{% hint style="info" %}
-If you don't wish to deploy with the new changes, you can choose `Last deployed config` from the available drop-down.
-{% endhint %}
-
----
-
-## Enabling/Disabling Config Protection
-
-{% hint style="info" %}
-Only a super-admin can enable or disable the config protection.
-{% endhint %}
-
-1. Go to the `App Configuration` tab.
-
-2. Click `Protect Configuration`.
-
-3. Use the toggle button to enable the protection for the configuration of your choice (base/environment level). A protection badge would appear next to the chosen configuration.
-
-Alternatively, unprotecting the configuration will lead to the discarding of unapproved drafts (if any).
-
-
-
-
-
diff --git a/docs/user-guide/creating-application/container-registry-override.md b/docs/user-guide/creating-application/container-registry-override.md
old mode 100644
new mode 100755
index bf1bf57286..bb019844c7
--- a/docs/user-guide/creating-application/container-registry-override.md
+++ b/docs/user-guide/creating-application/container-registry-override.md
@@ -4,8 +4,10 @@ Within the same application, you can override a `container registry`, `container
+
To override a container registry, container image or target platform:
@@ -22,5 +24,6 @@ To override a container registry, container image or target platform:
The overridden container registry/container image location/target platform will be reflected on the [Build Configuration](docker-build-configuration.md) page. You can also see the number of build pipelines for which the container registry/container image location/target platform is overridden.
+
Figure 3: Build Configuration Overridden
diff --git a/docs/user-guide/creating-application/deployment-template.md b/docs/user-guide/creating-application/deployment-template.md
deleted file mode 100644
index dcc861fd1d..0000000000
--- a/docs/user-guide/creating-application/deployment-template.md
+++ /dev/null
@@ -1,241 +0,0 @@
-# Base Deployment Template
-
-
-A deployment configuration is a manifest of the application. It defines the runtime behavior of the application.
-You can select one of the default deployment charts or custom deployment charts which are created by super admin.
-
-To configure a deployment chart for your application, do the following steps:
-
-* Go to **Applications** and create a new application.
-* Go to **App Configuration** page and configure your application.
-* On the **Base Deployment Template** page, select the drop-down under **Chart type**.
-
-
-
----
-
-## Selecting a Chart Type
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users need to have [Admin role](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above to select a chart.
-{% endhint %}
-
-{% hint style="warning" %}
-### Note
-After you select and save a chart type for a given application, you won't be able to change it later. Make sure to choose the correct chart type before saving. You can select a chart from [Devtron Charts](#from-devtron-charts) or other [Deployment Charts](#from-deployment-charts).
-{% endhint %}
-
-### From Devtron Charts
-
-You can select a default deployment chart from the following options:
-
-1. [Deployment](../creating-application/base-config/deployment-template/deployment.md) (Recommended)
-2. [Rollout Deployment](../creating-application/base-config/deployment-template/rollout-deployment.md)
-3. [Job & CronJob](../creating-application/base-config/deployment-template/job-and-cronjob.md)
-4. [StatefulSet](../creating-application/base-config/deployment-template/statefulset.md)
-
-
-
-### From Deployment Charts
-
-{% hint style="warning" %}
-This option will be available only if a custom chart exists. If it doesn't, a user with `super admin` permission may upload one in [Global Configurations → Deployment Charts](../global-configurations/deployment-charts.md).
-{% endhint %}
-
-You can select an available custom chart as shown below. You can also view the description of the custom charts in the list.
-
-
-
----
-
-## Selecting a Chart Version
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users need to have [Admin role](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above to select a chart version.
-{% endhint %}
-
-Once you select a chart type, choose a chart version using which you wish to deploy the application.
-
-
-
-Devtron uses helm charts for deployments and it maintains multiple chart versions based on the features it supports.
-
-One can see available chart versions in the drop-down. You can select any chart version as per your requirements. By default, the latest version of the helm chart is selected.
-
-Every chart version has its own YAML file that provides specifications for your application. To make it easy to use, we have created templates for the YAML file and have added some variables inside the YAML. You can provide or change the values of these variables as per your requirement.
-
----
-
-## Configuring the Chart
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users need to have [Admin role](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above to configure a chart. However, super-admins can lock keys in base deployment template to prevent non-super-admins from modifying them. Refer [Lock Deployment Configuration](../global-configurations/lock-deployment-config.md) to know more.
-{% endhint %}
-
-### Using Basic GUI
-
-If you are not an advanced user, you may use the **Basic (GUI)** section to configure your chosen chart.
-
-
-
-By default, the following fields are available for you to modify in the **Basic (GUI)** section:
-
-| Fields | Description |
-| :--- | :--- |
-| **Arguments** | Enable the `Arguments` to pass one or more argument values. By default, it is in the `disabled` state. |
-| **Command** | Enable the `Command` to pass one or more command values. By default, it is in the `disabled` state. |
-| **HTTP Request Routes** | Enable the `HTTP Request Routes` to define `Host`, and `Path`. By default, it is in the `disabled` state.
**Host**: Domain name of the server.
**Path**: Path of the specific component in the host that the HTTP wants to access.
You can define multiple paths as required by clicking **Add path**.|
-| **Resources** | Here, you can tweak the requests and limits of the CPU resource and RAM resource as per the application. |
-| **Autoscaling** | Define the autoscaling parameters to automatically scale your application's deployment based on resource utilization.
**Maximum Replicas**: The maximum number of replicas your application can scale up to.
**Minimum Replicas**: The minimum number of replicas your application should run at any time.
**Target CPU Utilization Percentage**: The average CPU utilization across all pods that will trigger scaling.
**Target Memory Utilization Percentage**: The average memory utilization across all pods that will trigger scaling.
You can define multiple env variables by clicking **Add EnvironmentVariables**. |
-| **Container Port** | The internal port on which the container listens for HTTP requests. Specify the container port and optionally the service port that maps to it. |
-| **Service** | Configure the service that exposes your application to the network.
**Type**: Specify the type of service (e.g., ClusterIP, NodePort, LoadBalancer).
**Annotations**: Add custom annotations to the service for additional configuration.
|
-| **Readiness Probe** | Define the readiness probe to determine when a container is ready to start accepting traffic.
**Path**: The HTTP path that the readiness probe will access.
**Port**: The port on which the readiness probe will access the application.
|
-| **Liveness Probe** | Define the liveness probe to check if the container is still running and to restart it if it is not.
**Path**: The HTTP path that the liveness probe will access.
**Port**: The port on which the liveness probe will access the application.
|
-| **Tolerations** | Define tolerations to allow the pods to be scheduled on nodes with matching taints.
**Key**: The key of the taint to tolerate.
**Operator**: The relationship between the key and the value (e.g., Exists, Equal).
**Value**: The value of the taint to match.
**Effect**: The effect of the taint to tolerate (e.g., NoSchedule, NoExecute).
|
-| **ServiceAccount** | Specify the service account for the deployment to use, allowing it to access Kubernetes API resources.
**Create**: Toggle to create a new service account.
**Name**: The name of the service account to use.
|
-
-Click **Save Changes**. If you want to do additional configurations, then click the **Switch to Advanced** button or **Advanced (YAML)** button for modifications.
-
-{% hint style="warning" %}
-### Note
-* If you change any values in the 'Basic (GUI)', then the corresponding values will change in 'Advanced (YAML)' too.
-* Users who are not super-admins will land on 'Basic (GUI)' section when they visit **Base Deployment Template** page; whereas super-admins will land on 'Advanced (YAML)' section. This is just a default behavior; therefore, they can still navigate to the other section if needed.
-{% endhint %}
-
-#### Customize Basic GUI [](https://devtron.ai/pricing)
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Superadmin can define and apply custom deployment schema.
-{% endhint %}
-
-By default, the `Basic (GUI)` section comes with multiple predefined fields as seen earlier [in the table](#using-basic-gui). However, if you wish to display a different set of fields to your team, you can modify the whole section as per your requirement.
-
-This is useful in scenarios where:
-* Your team members find it difficult to understand and edit the [Advanced (YAML)](#using-advanced-yaml) section.
-* You frequently edit certain fields in Advanced (YAML), which you expect to remain easily accessible in Basic (GUI) section.
-* You don't require some fields in Basic (GUI) section.
-* You need the autonomy to keep the Basic (GUI) unique for applications/clusters/environments/charts, or display the same Basic (GUI) everywhere.
-
-{% hint style="info" %}
-There are two ways you can customize the Basic GUI, use any one of the following:
-1. From [Deployment Charts](../global-configurations/deployment-charts.md#editing-gui-schema-of-deployment-charts) section
-2. Using APIs (explained below)
-{% endhint %}
-
-{% embed url="https://www.youtube.com/watch?v=09VP1I-WvUs" caption="JSON-driven Deployment Schema" %}
-
-You can pass a custom JSON (deployment schema) of your choice through the following API. You may need to run the API with the `POST` method if you are doing it for the first time.
-
-```
-PUT {{DEVTRON_BASEURL}}/orchestrator/deployment/template/schema
-```
-
-{% code title="Sample API Request Body" overflow="wrap" lineNumbers="true" %}
-
-```json
-{
- "name": "schema-1",
- "type": "JSON",
- "schema": "{\"type\":\"object\",\"properties\":{\"args\":{\"type\":\"object\",\"title\":\"Arguments\",\"properties\":{\"value\":{\"type\":\"array\",\"items\":{\"type\":\"string\"},\"title\":\"Value\"},\"enabled\":{\"type\":\"boolean\",\"title\":\"Enabled\"}}},\"command\":{\"type\":\"object\",\"title\":\"Command\",\"properties\":{\"value\":{\"type\":\"array\",\"items\":{\"type\":\"string\"},\"title\":\"Value\"},\"enabled\":{\"type\":\"boolean\",\"title\":\"Enabled\"}}},\"resources\":{\"type\":\"object\",\"title\":\"Resources(CPU&RAM)\",\"properties\":{\"limits\":{\"type\":\"object\",\"required\":[\"cpu\",\"memory\"],\"properties\":{\"cpu\":{\"type\":\"string\"},\"memory\":{\"type\":\"string\"}}},\"requests\":{\"type\":\"object\",\"properties\":{\"cpu\":{\"type\":\"string\"},\"memory\":{\"type\":\"string\"}}}}},\"autoscaling\":{\"type\":\"object\",\"title\":\"Autoscaling\",\"properties\":{\"MaxReplicas\":{\"type\":[\"integer\",\"string\"],\"title\":\"MaximumReplicas\",\"pattern\":\"^[a-zA-Z0-9-+\\\\/*%_\\\\\\\\s]+$\"},\"MinReplicas\":{\"type\":[\"integer\",\"string\"],\"title\":\"MinimumReplicas\",\"pattern\":\"^[a-zA-Z0-9-+\\\\/*%_\\\\\\\\s]+$\"},\"TargetCPUUtilizationPercentage\":{\"type\":[\"integer\",\"string\"],\"title\":\"TargetCPUUtilizationPercentage\",\"pattern\":\"^[a-zA-Z0-9-+\\\\/*%_\\\\\\\\s]+$\"},\"TargetMemoryUtilizationPercentage\":{\"type\":[\"integer\",\"string\"],\"title\":\"TargetMemoryUtilizationPercentage\",\"pattern\":\"^[a-zA-Z0-9-+\\\\/*%_\\\\\\\\s]+$\"}}},\"EnvVariables\":{\"type\":\"array\",\"items\":{\"type\":\"object\",\"properties\":{\"key\":{\"type\":\"string\"},\"value\":{\"type\":\"string\"}}},\"title\":\"EnvironmentVariables\"},\"ContainerPort\":{\"type\":\"array\",\"items\":{\"type\":\"object\",\"properties\":{\"port\":{\"type\":\"integer\"}}},\"title\":\"ContainerPort\"}}}",
- "selectors": [
- {
- "attributeSelector": {
- "category": "APP",
- "appNames": ["my-demo-app"]
- }
- },
- {
- "attributeSelector": {
- "category": "ENV",
- "envNames": ["env1", "env2", "env3"]
- }
- },
- {
- "attributeSelector": {
- "category": "CLUSTER",
- "clusterNames": ["cluster1", "cluster2", "cluster3"]
- }
- },
- {
- "attributeSelector": {
- "category": "CHART_REF",
- "chartVersions": [
- {
- "type": "Deployment",
- "version": "1.0.0"
- }
- ]
- }
- },
- {
- "attributeSelector": {
- "category": "APP_ENV",
- "appEnvNames": [
- {
- "appName": "my-demo-app",
- "envName": "devtron"
- }
- ]
- }
- }
- ]
-}
-
-```
-{% endcode %}
-
-1. In the `name` field, give a name to your schema, e.g., *schema-1*
-2. Enter the `type` as JSON.
-3. The `schema` field is for entering your custom deployment schema. Perform the following steps:
- * To create a custom schema of your choice, you may use [RJSF JSON Schema Tool](https://rjsf-team.github.io/react-jsonschema-form/).
- * Copy the final JSON and stringify it using any free online tool.
- * Paste the stringified JSON in the `schema` field of the API request body.
- * Send the API request. If your schema already exists, use the `PUT` method instead of `POST` in the API call.
-4. The `attributeSelector` object helps you choose the scope at which your custom deployment schema will take effect.
- | Priority | Category Scope | Description |
- |----------|-----------------|----------------------------------------------------------------------------|
- | 1 (High) | APP_ENV | Specific to an application and its environment |
- | 2 | APP | Applies at the application level if no specific environment is defined |
- | 3 | ENV | Applies to specific deployment environment |
- | 4 | CHART_REF | Applies to all applications using a specific chart type and version |
- | 5 | CLUSTER | Applies across all applications and environments within a specific cluster |
- | 6 | GLOBAL | Universally applies if no other more specific schemas are defined |
-
-
-### Using Advanced (YAML)
-
-If you are an advanced user wishing to perform additional configurations, you may switch to **Advanced (YAML)** for modifications.
-
-
-
-Refer the respective templates to view the YAML details.
-* [Deployment](./base-config/deployment-template/deployment.md)
-* [Rollout Deployment](./base-config/deployment-template/rollout-deployment.md)
-* [Job & CronJob](./base-config/deployment-template/job-and-cronjob.md)
-* [StatefulSet](./base-config/deployment-template/statefulset.md)
-
----
-
-## Application Metrics
-
-Depending on the chart type and version you select, application metrics of your application may be viewed.
-This includes:
-* Status codes 2xx, 3xx, 5xx
-* Throughput
-* Latency
-...and many more
-
-Enable **Show application metrics** toggle to view the application metrics on the **App Details** page.
-
-
-
-> **IMPORTANT**: Enabling application metrics introduces a sidecar container to your main container which may require some additional configuration adjustments. We recommend you to do load test after enabling it in a non-production environment before enabling it in production environment.
-
-Select **Save & Next** to save your configurations.
-
-
diff --git a/docs/user-guide/creating-application/deployment-visibility.md b/docs/user-guide/creating-application/deployment-visibility.md
old mode 100644
new mode 100755
index b156e2c1eb..cd49d43ce8
--- a/docs/user-guide/creating-application/deployment-visibility.md
+++ b/docs/user-guide/creating-application/deployment-visibility.md
@@ -1,17 +1,15 @@
# Deployment Visibility & Actions
-{% hint style="info" %}
-### Prerequisites
+:::info Prerequisites
The [Deployment Chart Type](../creating-application/base-config/deployment-template.md#select-a-deployment-chart-type) must be set to Rollout in order to use Blue-Green or Canary strategies.
Deployment Visibility and Actions is only available for Canary and Blue-Green Strategies. Refer to the [Deployment Strategies](../creating-application/workflow/cd-pipeline.md#deployment-strategies) to learn more.
-{% endhint %}
+:::
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have Build and Deploy or above (along with access to the environment and application).
-{% endhint %}
+:::
Devtron helps you to manage your **Canary** and **Blue-Green** deployments by providing visibility and easy controls to manage how new versions (releases) are shared with users.
@@ -39,16 +37,19 @@ You can select the **Manage Traffic** button to view the rollout status and step
If you wish you can also trigger the next release steps (for example 25%, 50%, 75%) or you can also trigger the full rollout at once according to your use case.
- 
+ 
+
### For Blue Green deployments
Devtron automatically swaps the traffic from the current running release to the new release based on the defined strategy configuration. In case `autoPromotionEnabled` field value is set to `false`, you can manually swap the traffic from the current release to the new release.
-
+
+
Figure 2: autoPromotionEnabled: false
To do so, follow the steps below:
@@ -58,11 +59,13 @@ To do so, follow the steps below:
2. During Blue-Green deployment, click the **Swap Traffic** button to shift the traffic to application's new release.
- 
+ 
+
Figure 3: Selecting Swap Traffic
3. Enter the name of the environment and select **Swap Traffic**
- 
+ 
+
Figure 4: Swap Traffic Pop Up
4. This will route the end user traffic from the current running release to the new release on a particular environment.
@@ -77,11 +80,13 @@ To do so, follow the below steps:
2. During Blue-Green deployment, click the **Skip & Promote Full** button to shift the traffic to application's new deployment.
- 
+ 
+
Figure 5: Selecting 'Skip & Promote Full'
3. Enter the name of the environment and select **Promote to Full**.
- 
+ 
+
Figure 6: Promote to Full Pop Up
4. This will skip the Blue-Green Strategy and route the end user traffic from the current running release to the new release on a particular environment.
@@ -99,18 +104,22 @@ To perform a rollback from App Details follow the below steps:
* In case of Canary deployments, select **Rollback** under **Canary Strategy**.
- 
+ 
+
Figure 7: Selecting Rollback For Canary Deployment
* In case of Blue Green deployments, select **Rollback** under **Blue Green Strategy**.
- 
+ 
+
Figure 8: Selecting Rollback For Blue Green Deployment
3. Select the image to which you want your release to be rolled back and click **Deploy** to rollback the release.
- 
+ 
+
Figure 9: Selecting the Image
4. If you wish, you can select a different deployment strategy other than the default according to the use case.
- 
+ 
+
Figure 10: Selecting Deployment Strategy
5. The application will be rolled back to the previous release (image) using the selected deployment strategy.
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/docker-build-configuration.md b/docs/user-guide/creating-application/docker-build-configuration.md
old mode 100644
new mode 100755
index 94b044cd6d..ccf05e9f9d
--- a/docs/user-guide/creating-application/docker-build-configuration.md
+++ b/docs/user-guide/creating-application/docker-build-configuration.md
@@ -12,22 +12,25 @@ For **build configuration**, you must provide information in the sections as giv
* [Build the Container Image](#build-the-container-image)
* [Advanced Options](#advanced-options)
-
+
+
Figure 1: Build Configuration Section
## Store Container Image
The following fields are provided on the **Store Container Image** section:
-
+
+
Figure 2: Entering Docker Repo Details
| Field | Description |
| --- | --- |
| **Container Registry** | Select the container registry from the drop-down list or you can click **Add Container Registry**. This registry will be used to [store docker images](../global-configurations/container-registries.md). |
| **Container Repository** | Enter the name of your container repository, preferably in the format `username/repo-name`. The repository that you specify here will store a collection of related docker images. Whenever an image is added here, it will be stored with a new tag version. |
-**If you are using docker hub account, you need to enter the repository name along with your username. For example - If my username is *kartik579* and repo name is *devtron-trial*, then enter kartik579/devtron-trial instead of only devtron-trial.**
+> If you are using Docker Hub account, you need to enter the repository name along with your username. For example, if your username is *nightdocker* and repo name is *banking-nxt-frontend*, then enter `nightdocker/banking-nxt-frontend` instead of only `banking-nxt-frontend`.
-
+
+
Figure 3: Example Docker Repo
## Build the Container Image
@@ -43,7 +46,8 @@ You can choose one of the following options to build your container image:
A `Dockerfile` is a text document that contains all the commands which you can call on the command line to build an image.
-
+
+
Figure 4: Marking Dockerfile as Available
| Field | Description |
| --- | --- |
@@ -54,24 +58,26 @@ A `Dockerfile` is a text document that contains all the commands which you can c
With the option **Create Dockerfile**, you can create a `Dockerfile` from the available templates. You can edit any selected Dockerfile template as per your build configuration requirements.
-
+
+
Figure 5: Creating a Dockerfile
| Field | Description |
| --- | --- |
-| **Language** | Select the programming language (e.g., `Java`, `Go`, `Python`, `Node` etc.) from the drop-down list you want to create a dockerfile as per compatibility to your system. **Note** We will be adding other programming languages in the future releases.|
-| **Framework** | Select the framework (e.g., `Maven`, `Gradle` etc.) of the selected programming language. **Note** We will be adding other frameworks in the future releases.|
+| **Language** | Select the programming language (e.g., `Java`, `Go`, `Python`, `Node` etc.) from the drop-down list you want to create a dockerfile as per compatibility to your system. **Note** We will be adding other programming languages in the future releases.|
+| **Framework** | Select the framework (e.g., `Maven`, `Gradle` etc.) of the selected programming language. **Note** We will be adding other frameworks in the future releases.|
### Build Docker Image without Dockerfile
With the option **Build without Dockerfile**, you can use Buildpacks to automatically build the image for your preferred language and framework.
-
+
+
Figure 6: Building without Dockerfile
| Field | Description |
| --- | --- |
| **Select repository containing code** | Select your code repository. This repository is the same which you defined on the [Git Repository](../creating-application/git-material.md) section.|
| **Project Path (Relative)** | In case of monorepo, specify the path of the project from your Git repository.|
-| **Language** | Select the programming language (e.g., `Java`, `Go`, `Python`, `Node`, `Ruby`, `PHP` etc.) from the drop-down list you want to build your container image as per the compatibility to your system. **Note**: We will be adding other programming languages in the future releases.|
+| **Language** | Select the programming language (e.g., `Java`, `Go`, `Python`, `Node`, `Ruby`, `PHP` etc.) from the drop-down list you want to build your container image as per the compatibility to your system. **Note**: We will be adding other programming languages in the future releases.|
| **Version** | Select a language version from the drop-down list. If you do not find the version you need, then you can update the language version in `Build Env Arguments`. You can also select **Autodetect** in case if you want `Builder` to detect version by itself or its default version.|
| **Select a builder** | A builder is an image that contains a set of buildpacks which provide your app's dependencies, a stack, and the OS layer for your app image. Select a buildpack provider from the following options:
**Heroku**: It compiles your deployed code and creates a slug, which is a compressed and pre-packaged copy of your app and also the runtime which is optimized for distribution to the dyno (Linux containers) manager. [Learn more](https://devcenter.heroku.com/articles/buildpacks).
**GCR**: GCR builder is a general purpose builder that creates container images designed to run on most platforms (e.g. Kubernetes / Anthos, Knative / Cloud Run, Container OS, etc.). It auto-detects the language of your source code, and can also build functions compatible with the Google Cloud Function Framework. [Learn more](https://github.com/GoogleCloudPlatform/buildpacks).
**Paketo**: Paketo buildpacks provide production-ready buildpacks for the most popular languages and frameworks to easily build your apps. Based on your application needs, you can select from `Full`, `Base` and `Tiny`. [Learn more](https://paketo.io/docs/).
|
@@ -82,7 +88,7 @@ You can add Key/Value pair by clicking **Add argument**.
| Field | Description |
| --- | --- |
-| **Key** | Define the key parameter as per your selected language and builder. E.g., By default `GOOGLE_RUNTIME_VERSION` for GCR buildpack. **Note**: If you want to define `env arguments` for `PHP` and `Ruby` languages after selecting `Heroku` builder, please make sure to refer respective [Heroku Ruby Support](https://devcenter.heroku.com/articles/ruby-support) and [Heroku PHP Support](https://devcenter.heroku.com/articles/php-support) documentation for runtime information.|
+| **Key** | Define the key parameter as per your selected language and builder. E.g., By default `GOOGLE_RUNTIME_VERSION` for GCR buildpack. **Note**: If you want to define `env arguments` for `PHP` and `Ruby` languages after selecting `Heroku` builder, please make sure to refer respective [Heroku Ruby Support](https://devcenter.heroku.com/articles/ruby-support) and [Heroku PHP Support](https://devcenter.heroku.com/articles/php-support) documentation for runtime information.|
| **Value** | Define the value for the specified key. E.g. Version no. |
@@ -95,9 +101,11 @@ You can add Key/Value pair by clicking **Add argument**.
Using this option, you can build images for a specific or multiple **architectures and operating systems (target platforms)**. You can select the target platform from the drop-down list or can type to select a customized target platform.
-
+
+
Figure 7a: Selecting Target Platform from Drop-down
Before selecting a customized target platform, please ensure that the architecture and the operating system are supported by the `registry type` you are using, otherwise build will fail. Devtron uses BuildX to build images for multiple target Platforms, which requires higher CI worker resources. To allocate more resources, you can increase value of the following parameters in the `devtron-cm` configmap in `devtroncd` namespace.
@@ -120,9 +128,9 @@ The Target Platform feature might not work in minikube & microk8s clusters as of
* Key
* Value
-
+
+
Figure 8: Entering Docker Build Arguments
These fields will contain the key parameter and the value for the specified key for your [docker build](https://docs.docker.com/engine/reference/commandline/build/#options). This field is Optional. If required, this can be overridden at [CI step](../deploying-application/triggering-ci.md).
-Click **Save Configuration**.
-
+Click **Save Configuration**.
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/environment-overrides.md b/docs/user-guide/creating-application/environment-overrides.md
old mode 100644
new mode 100755
index 2e0a60bfaa..d5d412d5de
--- a/docs/user-guide/creating-application/environment-overrides.md
+++ b/docs/user-guide/creating-application/environment-overrides.md
@@ -2,7 +2,8 @@
You can view all environments associated with an application under the **Environment Overrides** section.
-
+
+
Figure 1: Environment Overrides Section
The Environment Overrides section allows you to customize the **Deployment Template**, **ConfigMaps**, and **Secrets** for different environments such as development, testing, staging, and production.
@@ -16,25 +17,27 @@ The Environment Overrides section allows you to customize the **Deployment Templ
## Environment Configurations Page
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have [Admin role](../global-configurations/authorization/user-access.md#roles-available-for-devtron-apps) or above (along with access to the environment and applications) to perform environment override.
-{% endhint %}
+:::
-1. In your application, go to **Configurations** → **Environment Overrides**.
+1. In your Devtron app, go to **Configurations** (tab) → **Environment Overrides**.
- 
+ 
+
Figure 2: Accessing Environment Overrides
2. Select an environment whose configurations you wish to modify.
- 
+ 
+
Figure 3: Selecting Environment
3. You will get the following options (similar to the **Base Configurations** page):
* [Deployment Template](#override-deployment-template)
* [ConfigMaps](#override-configmap--secret)
* [Secrets](#override-configmap--secret)
- 
+ 
+
Figure 4: Configuration Options
Let's visit each of the configuration files and see how to override their values for the selected environment (say *banking-final*).
@@ -50,24 +53,26 @@ As you can see, the Deployment Template for the *banking-final* environment show
1. Go to the **Inherited** tab. This will show the inherited configuration in a read-only YAML editor. You cannot edit any values here.
- 
+ 
+
Figure 5: Inherited Deployment Template
2. Clicking **No override** to override the inherited configuration (if not done already).
- 
+ 
+
Figure 6: No Override Tab
3. Click the **Create Override** button.
- 
+ 
+
Figure 7: Creat Override Button
4. In the same tab (now labelled as **Override**), you can choose any one mode for changing the configuration values:
- * **YAML** - This mode has a YAML based editor intended for advanced users. [Click here](../creating-application/base-config/deployment-template/deployment.md#yaml) to know more about each key-value pair within the `YAML` section.
+ * **YAML** - This mode has a YAML based editor intended for advanced users. [Click here](../creating-application/base-config/deployment-template-types/deployment.md#yaml) to know more about each key-value pair within the `YAML` section.
* **GUI** - This mode has a user-friendly interface intended for beginner to advanced users. [Click here](../creating-application/base-config/deployment-template.md#using-gui) to know more about each field within the `GUI` section.
-{% hint style="info" %}
-### Note
+:::info Note
Users who are not super-admins will land on GUI mode when they override; whereas super-admins will land on YAML mode. This is just the default behavior, users can still toggle the mode if needed.
-{% endhint %}
+:::
Let's choose YAML mode for now and proceed. If you prefer GUI mode, go to [Override Deployment Template using GUI](#override-deployment-template-using-gui) section.
@@ -93,16 +98,14 @@ Suppose you want to update only one field (e.g., `"username" = "johndoe"`) in a
If you know the fields you wish to change, simply enter the changed key-value fields along with indentation (if any).
-{% embed url="https://www.youtube.com/watch?v=phhv1_2eStI" %}
+
### Using Replace Strategy
-{% embed url="https://youtu.be/xF0Ar4rHqWo" %}
-
Suppose you update your deployment chart version (e.g., from `4.0.0` to `4.0.1`). Although the new chart version contains new features and key-value pairs, if you prefer to keep a few configurations unchanged regardless of the new key-value pairs added in the new chart version, you can use the replace strategy.
* The entire configuration is replaced with your new environment-specific settings.
@@ -117,22 +120,32 @@ Suppose you update your deployment chart version (e.g., from `4.0.0` to `4.0.1`)
| logLevel | "info" | *(Not specified)* | *(Removed)* |
| timeout | (Not specified) | 30s | 30s (Added) |
-{% hint style="info" %}
-### What if some keys are locked from editing?
+:::info What if some keys are locked from editing?
You cannot modify locked keys in an environment's deployment template unless you are a super-admin. Refer [Lock Deployment Configuration](../global-configurations/lock-deployment-config.md) to know more.
-{% endhint %}
+:::
### Override Deployment Template using GUI
-{% embed url="https://youtu.be/fkF29-H3plk" %}
+Follow the below steps to override your deployment template using GUI:
+
+1. Navigate to **Application Management** → **Applications** and click your Devtron application.
+
+2. Go to **Configurations** (tab) → **Base Configurations** → **Environment Overrides** and click on your preferred environment to override deployment template.
+
+3. Click on the **No Override** option and then click on **Create Override**.
+
+4. Click on the **GUI** option. The available fields will be displayed on the right side of the page.
-{% hint style="info" %}
+5. Select your preferred fields and enter the values to override.
-### Want to customize the deployment template values displayed on GUI? [](https://devtron.ai/pricing)
+6. Select your preferred merge strategy from the **Merge Strategy** drop-down box.
-The GUI mode shows limited number of fields as specified by the super-admin in the GUI schema. Refer [Customize GUI](../creating-application/base-config/deployment-template.md#customize-the-gui) to know more.
+7. Click on **Save Changes**.
-{% endhint %}
+:::info Want to customize the deployment template values displayed on GUI?
+The GUI mode shows limited number of fields as specified by the super-admin in the GUI schema. Refer [Customize GUI](../creating-application/base-config/deployment-template.md#customize-the-gui-) to know more.
+
+:::
---
@@ -144,23 +157,18 @@ The process to override both ConfigMaps and Secrets is similar to [Override Depl
### Patch Strategy
-{% embed url="https://youtu.be/drqF4N3w8IE" %}
-
-{% hint style="info" %}
-
-### Impact of Patch strategy on Base Configuration's CM/Secret?
-
+:::info Impact of Patch strategy on Base Configuration's CM/Secret?
You cannot delete a ConfigMap or Secret in **Base Configurations** if you have used 'Patch' strategy for overridding ConfigMap or Secret at your environment-level. This happens because they are still dependent and inheriting their values from Base Configurations.
-{% endhint %}
+:::
### Replace Strategy
-{% embed url="https://www.youtube.com/watch?v=lSoj8wwOej0" %}
+
### Override ConfigMaps and Secrets using GUI
-{% embed url="https://www.youtube.com/watch?v=UOTKLVuSkDg" %}
+
---
@@ -172,86 +180,33 @@ This action will discard the current overrides and the base configuration file (
2. Click **Delete Override**.
3. Confirm the deletion in the dialogbox.
-
+
+
Figure 8: Delete Override Option
---
-## Protected Environment Configurations [](https://devtron.ai/pricing)
+## Protected Environment Configurations
-Any changes made to the protected environment configurations (Deployment Template, ConfigMap, Secret) will require approval if an [approval policy](../global-configurations/approval-policy.md) is enforced. When you want to edit a protected configuration, you can do it in the following ways:
+Any changes made to the protected environment configurations (Deployment Template, ConfigMap, Secret) will require approval if an [approval policy](../global-configurations/approval-policy.md) is enforced.
-* [Normal Edit](#normal-edit) - Where changes to the protected configuration are made only after getting approval from the approver(s).
+Follow the below steps to make changes to a protected environment:
-* [Express Edit](#express-edit) - Where you bypass the approval process and directly make changes to the protected configuration.
+1. Navigate to **Application Management** → **Applications** and click on your preferred application.
-### Normal Edit
+2. Go to **Configurations** (tab) → **Base Configurations** → **Environment Overrides** and click on your preferred environment.
-{% hint style="warning" %}
+3. Click on the **No Override** option and then click on **Create Override**.
-### Who Can Perform This Action?
+4. Select your preferred merge strategy from the **Merge Strategy** drop-down box.
-Only a Super-Admin, Manager, or an Admin can edit the configuration values. Refer to [User Permissions](../global-configurations/authorization/user-access.md) for more information.
+5. Make changes to the key-value pairs in the **Patch data** section.
-{% endhint %}
-
-{% embed url="https://youtu.be/eseckdmpdls" %}
-
-Follow the below steps to edit a protected configuration:
-
-1. Navigate to the **Applications** page and click on your preferred application.
-
-2. Go to the **Configurations** → **Base Configurations**.
-
-3. Click on your preferred configuration (e.g., **ConfigMaps**) and select the ConfigMap you'd like to edit.
-
-4. Modify the values either by using **GUI** or **YAML** editor.
-
-5. Click **Save Changes**. The Base Configurations pop-up page will be displayed.
+6. Click **Save Changes**. The **Save as draft** pop-up page will be displayed.
* **Save as draft** - Select this option if you want to continue making your changes later but save your changes as a draft for now.
- * **Propose changes** - Select this option if you want to propose your changes to the approvers. You can then select the approvers to get notified regarding the change from the **Select approvers** to notify drop-down box.
-
-6. Enter your comments (reason for making the changes) in the **Comment** text box.
-
-7. Click **Propose Changes**. The corresponding approver will be notified via email regarding your request.
-
-### Express Edit
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
-Only a Super-Admin (when the [Super admins toggle](../global-configurations/approval-policy.md#excluding-super-admins) is enabled in the Exceptions tab) or [specific users / user groups](../global-configurations/approval-policy.md#excluding-specific-users--user-groups--api-tokens) who are added as exceptions in the Approval Policy can make express edits. Refer to [Approval Policy](../global-configurations/approval-policy.md) for more information.
-
-{% endhint %}
-
-Express edits allow you to bypass the approval process and make direct edits to the configurations. Follow the below steps to make express edits:
-
-1. Navigate to the **Applications** page and click on your preferred application.
-
-2. Go to the **Configurations** → **Base Configurations**.
-
-3. Click on your preferred configuration (e.g., **ConfigMaps**) and select the ConfigMap you'd like to edit.
-
-4. Click on the **Edit** button.
-
-{% hint style="info" %}
-
-### Note
-
-The **Edit** button will only be displayed if:
-
-* You are a Super-Admin and the Super admins toggle is enabled in the Approval Policy page
-
-* You are added as an exception in the Approval Policy page.
-
-Refer to [Approval Policy](../global-configurations/approval-policy.md) for more information.
-
-{% endhint %}
-
-5. Modify the values either by using **GUI** or **YAML** editor.
+ * **Save & Propose changes** - Select this option if you want to save and propose your changes to the approvers. You can then select the approvers to get notified regarding the change from the **Select approvers to notify** drop-down box.
-6. Click on **Publish Changes** to direcly publish your changes.
+7. Enter your comments (reason for making the changes) in the **Comment** text box.
-
\ No newline at end of file
+8. Click **Propose Changes**. The corresponding approver will be notified via email regarding your request.
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/external-links.md b/docs/user-guide/creating-application/external-links.md
old mode 100644
new mode 100755
index 3dbc4037f7..383a3559e0
--- a/docs/user-guide/creating-application/external-links.md
+++ b/docs/user-guide/creating-application/external-links.md
@@ -1,7 +1,7 @@
# External Links
-This is similar to [External Links](../global-configurations/external-links.md) present under Global Configurations.
+This is similar to [External Links](../global-configurations/external-links.md) present under **Application Management** → **Configurations**.
-The only difference is that in **App Configuration** → **External Links**, only the links editable by application admins and manager are displayed. You can also configure external links separately for your application.
+The only difference is that in **External Links**, only the links editable by application admins and manager are displayed. You can also configure external links separately for your application.
-Whereas, in **Global Configurations** → **External Links**, you can configure the external links for all applications in a cluster or for specific applications.
\ No newline at end of file
+Whereas, in **Application Management** → **Configurations** → **External Links**, you can configure the external links for all applications in a cluster or for specific applications.
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/fluxcd.md b/docs/user-guide/creating-application/fluxcd.md
old mode 100644
new mode 100755
index db846b8dbf..f7bb5ea805
--- a/docs/user-guide/creating-application/fluxcd.md
+++ b/docs/user-guide/creating-application/fluxcd.md
@@ -1,15 +1,12 @@
# Enable GitOps Deployments with FluxCD
-{% hint style="info" %}
-### Prerequisite
-
+:::info Prerequisite
Make sure to install:
1. [Build and Deploy (CI/CD) integration](../integrations/build-and-deploy-ci-cd.md)
2. [GitOps (ArgoCD) integration](../integrations/argocd.md)
-
-{% endhint %}
+:::
Devtron supports FluxCD to enable GitOps-based deployments. With FluxCD, you can:
@@ -24,13 +21,12 @@ Your Git repository becomes the single source of truth for your Kubernetes workl
## Installation
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
The user must have permissions to:
* Edit the ConfigMaps of 'default-cluster'
* Restart the pods
-{% endhint %}
+:::
To enable deployments through GitOps via FluxCD, you need to enable a specific feature flag for the `default_cluster` in Devtron.
|Feature|Flag|Description|
@@ -38,48 +34,51 @@ To enable deployments through GitOps via FluxCD, you need to enable a specific f
|**Deployments via FluxCD**|`FEATURE_FLUX_DEPLOYMENTS_ENABLE: "true"`|This flag will enable deployments through GitOps via FluxCD.
After enabling this flag, you also need to install FluxCD controller in order to deploy applications successfully. Refer [Installing FluxCD Controller](#installing-fluxcd-controller-only-for-deployments) to know more.
|
|**Migrating existing FluxCD applications**|`FEATURE_LINK_EXTERNAL_FLUX_ENABLE: "true"`|This flag will enable migrations for external FluxCD apps into Devtron.|
- {% hint style="warning" %}
- ### Deployment Strategies for FluxCD Deployments
-
+ :::caution Deployment Strategies for FluxCD Deployments
Application deployments through GitOps (via FluxCD) are supported only when using the `Deployment` or `Rollout` deployment strategies with the latest chart versions. Other deployment strategies are currently not supported.
- {% endhint %}
+:::
### Enabling Feature Flags
1. Navigate to Devtron's **Resource Browser**.
- 
+ 
+
Figure 1: Navigating to Resource Browser
2. Select the `default_cluster` to enable the feature flags.
- 
+ 
+
Figure 2: Selecting 'default_cluster'
3. Go to Config & Storage → ConfigMap, and click `dashboard-cm` ConfigMap
- 
+ 
+
Figure 3: Clicking 'dashboard-cm'
4. Edit the `dashboard-cm` ConfigMap by clicking **Edit live manifest**.
- 
- 1. To enable deployments via FluxCD, check if the below entries are present in the ConfigMap (create one if it doesn't exist) and select **Apply changes**.
+ 
+
Figure 4: Editing Live Manifest
+ 1. To enable deployments via FluxCD, check if the below entries are present in the ConfigMap (create one if it doesn't exist) and select **Apply changes**.
```yaml
FEATURE_FLUX_DEPLOYMENTS_ENABLE: "true"
```
- 2. To enable migration for external FluxCD applications, check if the below entries are present in the ConfigMap (create one if it doesn't exist) and select **Apply changes**.
+ 2. To enable migration for external FluxCD applications, check if the below entries are present in the ConfigMap (create one if it doesn't exist) and select **Apply changes**.
```yaml
FEATURE_LINK_EXTERNAL_FLUX_ENABLE: "true"
```
-
+
- 
+ 
+
Figure 5: Adding Feature Flags
5. Restart the deployment:
1. **For OSS Users:**
- 1. Navigate to Devtron's Resource Browser.
+ 1. Navigate to Devtron's [Resource Browser](../resource-browser/).
2. Select the cluster for which you have enabled the feature flags.
@@ -91,13 +90,15 @@ To enable deployments through GitOps via FluxCD, you need to enable a specific f
kubectl rollout restart deployment dashboard -n devtroncd
```
- 
+ 
+
Figure 6: Restarting Deployment
2. **For Enterprise Users:**
- 1. Go to **Resource Browser** → (select the cluster in which you have enabled the feature flags) → **Workloads** → **Deployment**
+ 1. Go to **Infrastructure Management** → **Resource Browser** → (select the cluster in which you have enabled the feature flags) → **Workloads** → **Deployment**
2. Click the checkbox next to the `dashboard` Deployment workloads and restart them using the `⟳` button.
- 
+ 
+
6. Perform a hard refresh of the browser to clear the cache:
@@ -130,7 +131,8 @@ You can install FluxCD Controller by any of the following ways:
kubectl apply -f https://github.com/fluxcd/flux2/releases/download/v0.35.0/install.yaml
```
- 
+ 
+
Figure 8: Installing FluxCD Controller
5. After the command is executed successfully, you can deploy or migrate your applications in that cluster through GitOps (via FluxCD).
@@ -140,19 +142,23 @@ To install FluxCD controller via Chart Store, follow the below steps.
1. Add FluxCD controller repository, `https://fluxcd-community.github.io/helm-charts` in the chart repositories (if not already added) in Global Configurations. Refer [Chart Repositories](../global-configurations/chart-repo.md#add-chart-repository) to learn more.
- 
+ 
+
Figure 9: Adding FluxCD Chart Repository
- 2. Add a new environment in the cluster in which you want to deploy the application via FluxCD linked to namespace as `flux-system`. Refer [Clusters and Environments](../global-configurations/cluster-and-environments.md#add-environment-to-a-cluster) to lean more.
+ 2. Add a new environment in the cluster in which you want to deploy the application via FluxCD linked to namespace as `flux-system`. Refer [Clusters and Environments](../global-configurations/clusters/manage-environments.md#add-environment-to-a-cluster) to lean more.
- 
+ 
+
Figure 10: Adding Environment linked to 'flux-system' namespace
3. Navigate to **Chart Store** and select the `flux2` chart.
- 
+ 
+
5. Configure the following configurations:
@@ -162,7 +168,8 @@ To install FluxCD controller via Chart Store, follow the below steps.
|**Project**|Select a project from the dropdown|
|**Deploy to Environment**|Select the environment which you have created in your preferred cluster linked to `flux-system` namespace.|
- 
+ 
+
Figure 13: Configuring 'flux2' Chart
6. Click **Deploy** and the chart will be deployed.
diff --git a/docs/user-guide/creating-application/git-material.md b/docs/user-guide/creating-application/git-material.md
old mode 100644
new mode 100755
index 92dcb1a818..6fa0b0fd94
--- a/docs/user-guide/creating-application/git-material.md
+++ b/docs/user-guide/creating-application/git-material.md
@@ -6,7 +6,8 @@ During the [CI process](../deploying-application/triggering-ci.md), the applicat
Devtron also supports multiple Git repositories (be it from one Git account or multiple Git accounts) in a single deployment.
-
+
+
Figure 1: Adding Git Repository
Therefore, this doc is divided into 2 sections, read the one that caters to your application:
* [Single Repo Application](#single-repo-application)
@@ -18,7 +19,7 @@ Therefore, this doc is divided into 2 sections, read the one that caters to your
Follow the below steps if the source code of your application is hosted on a single Git repository.
-In your application, go to **App Configuration** → **Git Repository**. You will get the following fields and options:
+In your Devtron app, go to **Configuration** (tab) → **Git Repository**. You will get the following fields and options:
1. [Git Account](#git-account)
2. [Git Repo URL](#git-repo-url)
@@ -31,11 +32,12 @@ In your application, go to **App Configuration** → **Git Repository**. You wil
This is a dropdown that shows the list of Git accounts added to your organization on Devtron. If you haven't done already, we recommend you to first [add your Git account](../global-configurations/git-accounts.md) (especially when the repository is private).
-
+
+
Figure 2: Selecting Git Account
-{% hint style="info" %}
+:::info
If the authentication type of your Git account is anonymous, only public Git repositories in that account will be accessible. Whereas, adding a user auth or SSH key will make both public and private repositories accessible.
-{% endhint %}
+:::
### Git Repo URL
@@ -44,27 +46,30 @@ In this field, you have to provide your code repository’s URL, for e.g., `http
You can find this URL by clicking on the **Code** button available on your repository page as shown below:
-
+
+
Figure 3: Getting Repo URL
-{% hint style="info" %}
+:::info
* Copy the HTTPS/SSH portion of the URL too
* Make sure you've added your [Dockerfile](https://docs.docker.com/engine/reference/builder/) in the repo
-{% endhint %}
+:::
### Exclude specific file/folder in this repo
Not all repository changes are worth triggering a new [CI build](../deploying-application/triggering-ci.md). If you enable this checkbox, you can define the file(s) or folder(s) whose commits you wish to use in the CI build.
-
+
+
Figure 4: Sample Exclusion Rule
In other words, if a given commit contains changes only in file(s) present in your exclusion rule, the commit won't show up while selecting the [Git material](../../reference/glossary.md#material), which means it will not be eligible for build. However, if a given commit contains changes in other files too (along with the excluded file), the commit won't be excluded and it will definitely show up in the list of commits.
-
+
+
Figure 5: Excludes commits made to README.md
Devtron allows you to create either an exclusion rule, an inclusion rule, or a combination of both. In case of multiple files or folders, you can list them in new lines.
-To exclude a path, use **!** as the prefix, e.g. `!path/to/file`
+To exclude a path, use **!** as the prefix, e.g. `!path/to/file`
To include a path, don't use any prefix, e.g. `path/to/file`
@@ -74,7 +79,7 @@ To include a path, don't use any prefix, e.g. `path/to/file`
| Sample Values | Description |
|---|---|
| `!README.md` | **Exclusion of a single file in root folder:** Commits containing changes made only in README.md file will not be shown |
-| `!README.md` `!index.js` | **Exclusion of multiple files in root folder:** Commits containing changes made only in README.md or/and index.js files will not be shown |
+| `!README.md` `!index.js` | **Exclusion of multiple files in root folder:** Commits containing changes made only in README.md or/and index.js files will not be shown |
| `README.md` | **Inclusion of a single file in root folder:** Commits containing changes made only in README.md file will be shown. Rest all will be excluded. |
| `!src/extensions/printer/code2.py` | **Exclusion of a single file in a folder tree:** Commits containing changes made specifically to code2.py file will not be shown |
| `!src/*` | **Exclusion of a single folder and all its files:** Commits containing changes made specifically to files within src folder will not be shown |
@@ -82,13 +87,10 @@ To include a path, don't use any prefix, e.g. `path/to/file`
| `!README.md` `README.md` | **Exclusion and inclusion of conflicting files:** If conflicting paths are defined in the rule, the one defined later will be considered. In this case, commits containing changes made only in README.md will be shown. |
-You may use the **Learn how** link (as shown below) to understand the syntax of defining an exclusion or inclusion rule.
-
-
-
Since file paths can be long, Devtron supports regex too for writing the paths. To understand it better, you may click the **How to use** link as shown below.
-
+
+
Figure 6: Regex Support
#### How to view excluded commits?
@@ -96,11 +98,14 @@ As we saw earlier in fig. 4 and 5, commits containing the changes of only `READM
However, Devtron gives you the option to view the excluded commits too. There's a döner menu at the top-right (beside the `Search by commit hash` search bar).
-
+
+
Figure 7a: Döner Menu Icon
-
+
+
Figure 7b: Show Excluded Commits
-
+
+
Figure 7c: Commits Unavailable for Build
The **EXCLUDED** label (in red) indicates that the commits contain changes made only to the excluded file, and hence they are unavailable for build.
@@ -111,7 +116,8 @@ After clicking the checkbox, a field titled `clone directory path` appears. It i
This field is optional for a single Git repository application and you can leave the path as default. Devtron assigns a directory by itself when the field is left blank. The default value of this field is `./`
-
+
+
Figure 8: Clone Directory Option
### Pull submodules recursively
@@ -128,9 +134,9 @@ Repeat the process for every new git repository you add. The clone directory pat
Whenever a change is pushed to any of the configured repositories, CI will be triggered and a new Docker image file will be built (based on the latest commits of the configured repositories). Next, the image will be pushed to the container registry you configured in Devtron.
-{% hint style="info" %}
+:::info
Even if you add multiple repositories, only one image will be created based on the Dockerfile as shown in the [docker build config](docker-build-configuration.md)
-{% endhint %}
+:::
### Why do you need Multi-Git support?
diff --git a/docs/user-guide/creating-application/gitops-config.md b/docs/user-guide/creating-application/gitops-config.md
old mode 100644
new mode 100755
index 211d1c75e4..755ad0f9c2
--- a/docs/user-guide/creating-application/gitops-config.md
+++ b/docs/user-guide/creating-application/gitops-config.md
@@ -1,12 +1,12 @@
# GitOps Configuration
-{% hint style="warning" %}
-The 'GitOps Configuration' page appears only if the super-admin has enabled 'Allow changing git repository for application' in [Global Configurations → GitOps](../global-configurations/gitops.md).
-{% endhint %}
+:::caution
+The 'GitOps Configuration' page appears only if the super-admin has opted for **Ask git repository for each application** in [Application Management → Configurations → GitOps](../global-configurations/gitops.md).
+:::
## Introduction
-This configuration is an extension of the [GitOps](../global-configurations/gitops.md) settings present in [Global Configurations](../global-configurations/README.md) of Devtron. Therefore, make sure you read it before making any changes to your app configuration.
+This configuration is an extension of the [GitOps](../global-configurations/gitops.md) settings present in [Application Management → Configurations](../global-configurations/README.md) of Devtron. Therefore, make sure you read it before making any changes to your app configuration.
The application-level GitOps configuration offers the flexibility to add a custom Git repo (as opposed to Devtron auto-creating a repo for your application).
@@ -14,16 +14,16 @@ The application-level GitOps configuration offers the flexibility to add a custo
## Adding Custom Git Repo for GitOps
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have [Admin permission](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and application) to configure user-defined Git repo.
-{% endhint %}
+:::
### For Devtron Apps
-1. Go to **Applications** → **Devtron Apps** (tab) → (choose your app) → **App Configuration** (tab) → **GitOps Configuration**.
+1. Go to **Application Management** → **Devtron Apps** → (choose your app) → **Configurations** (tab) → **GitOps Configuration**.
- 
+ 
+
Figure 1: App-level GitOps Config
2. Assuming a GitOps repo was not added to your application earlier, you get 2 options:
@@ -31,20 +31,23 @@ Users need to have [Admin permission](../global-configurations/authorization/use
* **Commit manifests to a desired repository** - Select this option if you wish to add a custom repo that is already created with your [Git provider](../global-configurations/gitops.md#supported-git-providers). Enter its link in the `Git Repo URL` field.
- 
+ 
+
Figure 2: Repo Creation
-{% hint style="warning" %}
+:::caution
GitOps repositories, whether auto-created by Devtron or added manually, are immutable. This means they cannot be modified after creation. The same is true if you have an existing CD pipeline that uses/used GitOps for deployment.
-{% endhint %}
+:::
3. Click **Save**.
- 
+ 
+
Figure 3: Saved GitOps Config
-**Note**: In case you skipped the GitOps configuration for your application and proceeded towards the [creation of a new CD pipeline](../creating-application/workflow/cd-pipeline.md#creating-cd-pipeline) (that uses GitOps), you will be prompted to configure GitOps as shown below:
+**Note**: In case you skipped the GitOps configuration for your application and proceeded towards the [creation of a new CD pipeline](../creating-application/workflow/cd-pipeline.md) (that uses GitOps), you will be prompted to configure GitOps as shown below:
-
+
+
Figure 4: Incomplete GitOps Config
### For Helm Apps
@@ -53,34 +56,40 @@ You can [deploy a helm chart](../deploy-chart/deployment-of-charts.md#configure-
1. Select the helm chart from the [Chart Store](../deploy-chart/README.md).
- 
+ 
+
-3. After you enter the `App Name`, `Project`, and `Environment`; an option to choose the deployment approach (i.e., Helm or GitOps) would appear. Select **GitOps**.
+3. After you enter the `App Name`, `Project`, and `Environment`; an option to choose the deployment approach (i.e., Helm or GitOps (Via ArgoCD)) would appear. Select **GitOps (Via ArgoCD)**.
-{% hint style="info" %}
-The option to choose between 'Helm' or 'GitOps' is only available in
-{% endhint %}
+:::info
+The option to choose between 'Helm' or 'GitOps' is only available in
+:::
-
+
+
4. A modal window will appear for you to enter a Git repository. Just like [Devtron Apps](#for-devtron-apps) (step 2), you get two options:
* Auto-create repository
* Commit manifests to a desired repository
- 
+ 
+
Figure 8: Adding a Repo
5. Enter your custom Git Repo URL, and click **Save**.
- 
+ 
+
Figure 9: Saved GitOps Config for Helm App
Next, you may proceed to deploy the chart.
-{% hint style="warning" %}
+:::caution
Once you deploy a helm app with GitOps, you cannot change its GitOps repo.
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/overview.md b/docs/user-guide/creating-application/overview.md
old mode 100644
new mode 100755
index 3cf97142f9..f51a7250bf
--- a/docs/user-guide/creating-application/overview.md
+++ b/docs/user-guide/creating-application/overview.md
@@ -5,9 +5,12 @@ The Overview page provides a centralized view of an application’s details with
The **Overview** page contains three main sections:
* [**About**](#about): Contains application metadata such as name, description, project, creator, tags, and connected code source. It also includes options to manage tags and [Configure PVCs](#configure-persistentvolumeclaim-pvc).
* [**Environments**](#environments): Displays all environments where the application is deployed, along with their current status and quick access to associated workflows.
-* [**Dependencies**](#dependencies): Shows which Devtron applications this application depends on, and which other Devtron applications depend on it, thus helping visualize microservices dependency.
+* [**Dependencies**](#dependencies-): Shows which Devtron applications this application depends on, and which other Devtron applications depend on it, thus helping visualize microservices dependency.
-
+
+
Figure 1: Overview Tab
+
+---
## About
@@ -20,7 +23,8 @@ The **About** section allows you to:
The left side of the **About** section displays essential information about the application.
-
+
+
Figure 2: About Section
The table below captures all the key elements presented in this section, along with their descriptions and whether they can be edited by the user.
@@ -28,11 +32,11 @@ The left side of the **About** section displays essential information about the
| :--------- | :--------------- |:--------- |
| **Application Name** | No |Displays the name of the application (e.g., backend-healthcare-app).|
| **Short Description**|Yes|A short, optional description to summarize the application's purpose.|
-| **Project** |Yes|Indicates the current project under which the application is organized. You can change the project directly from this section.
Click the **Edit** icon next to the current project.
In the **Change Project** window, select the new project from the dropdown.
Click **Save**.
Changing the project will revoke access for existing users and grant access only to those who have permissions in the newly selected project.|
+| **Project** |Yes|Indicates the current project under which the application is organized. You can change the project directly from this section.
Click the **Edit** icon next to the current project.
In the **Change Project** window, select the new project from the dropdown.
Click **Save**.
Changing the project will revoke access for existing users and grant access only to those who have permissions in the newly selected project.|
| **Created on** |No|Shows the exact date and time when the application was created.|
| **Created by**|No|Displays the email address of the user who created the application.|
| **Code Source** |No|Shows the connected Git repository or template used for the application.|
-| **Part of release track** |No|Lists all release track names linked to the app.
Clicking a release opens its detailed view in the Software Distribution Hub.
This is an enterprise-only feature available as part of Devtron's SDH offering.
|
+| **Part of release track** |No|Lists all release track names linked to the app.
Clicking a release opens its detailed view in the Software Release Management.
This is an enterprise-only feature available as part of Devtron's SDH offering.
|
| **Tags** |Yes| Refer [Manage Tags](#manage-tags) |
@@ -43,11 +47,13 @@ Tags are key-value pairs used to identify and organize applications effectively.
1. Click the **Edit** icon next to **Tags**.
2. On the **Manage Tags** page, click **+ Add tag** to create a new tag.
3. To delete a tag, click the **X** icon next to it.
-4. To propagate a tag as a Kubernetes label, click the **Propagation** icon .
+4. To propagate a tag as a Kubernetes label, click the **Propagation** icon 
+
propagation icon
.
- The icon turns dark grey when propagation is enabled.
- Click again if you wish to disable propagation.
- 
+ 
+
Figure 3: Snapshot of Manage Tags
5. Click **Save**. The configured tags will appear under the **Tags** in the **About** section immediately.
@@ -57,7 +63,8 @@ Tags are key-value pairs used to identify and organize applications effectively.
### Readme
The right side of the **About** section contains a **Readme** area where you can maintain application-specific notes or documentation. The **Readme** supports Markdown formatting, making it easy to include formatted text, instructions, or important context related to the application.
-
+
+
Figure 4: Readme
To add or update the **Readme**:
1. Click the **Edit** button in the Readme section.
@@ -66,13 +73,14 @@ To add or update the **Readme**:
4. Preview the content using the **Preview** tab.
5. Click **Save** to update the Readme.
-
+
+
Figure 5: Editing Readme
-{% hint style="info" %}
- After saving, the system displays the email address of the user who last updated the README, along with the date and time. This information appears in the header of the Readme section, beside the title.
-{% endhint %}
+:::info
+After saving, the system displays the email address of the user who last updated the README, along with the date and time. This information appears in the header of the Readme section, beside the title.
+:::
-### Deployment Window [](https://devtron.ai/pricing)
+### Deployment Window
The **Deployment Window** in the **About** section displays all Blackout Windows and Maintenance Windows configured for your application’s environments.
@@ -84,21 +92,23 @@ These windows are defined by Super-Admins to control when deployments and relate
You can expand each environment row to view detailed information like window name, duration, and frequency.
-
+
+
Figure 6: Deployment Window
-{% hint style=“info” %}
+:::info
This section is view-only and does not require any configuration at the application level.
-{% endhint %}
+:::
> To learn how to configure deployment windows, refer to the [Deployment Window documentation](../global-configurations/deployment-window.md).
-### Catalog [](https://devtron.ai/pricing)
+### Catalog
-The **Catalog** in the **About** section displays information about your application, such as documentation references, ownership details, and technical specifications. This data is managed using [Devtron’s Catalog Framework](../global-configurations/catalog-framework.md).
+The **Catalog** in the **About** section displays information about your application, such as documentation references, ownership details, and technical specifications. You can manage this data using the **Manage Schema** option, which defines the structure of your catalog. Refer the [Manage Schema Documentation](../global-configurations/catalog-framework.md#managing-a-schema) to learn more.
-
+
+
Figure 7: Catalog
-You can use the **Catalog framework** to maintain information about your application, such as Documentation (e.g., API contract, service documentation), ownership details, technical attributes, etc. This makes it easier for others to understand, manage, and use your application.
+You can use the **Catalog** to maintain information about your application, such as Documentation (e.g., API contract, service documentation), ownership details, technical attributes, etc. This makes it easier for others to understand, manage, and use your application.
Super-Admins define a custom JSON schema that determines what fields are shown in the catalog form. This schema is specific to each resource type, such as Devtron applications.
@@ -108,15 +118,17 @@ When you click the **Edit** icon, a form appears based on the defined schema. As
* Code owners and on-call responsibilities
* Service attributes (e.g., internet-facing flag, communication method, framework, language)
-
+
+
Figure 8: Catalog Form
-{% hint style= "info" %}
-The structure and labels in the catalog form are entirely configurable by your platform team via JSON schema in **Catalog Framework**. Field names and sections may vary depending on how the schema was defined by your organization.
-{% endhint %}
+:::info
+The structure and labels in the catalog form are entirely configurable by your platform team via JSON schema in **Catalog**. Field names and sections may vary depending on how the schema was defined by your organization. Refer [Manage Schema](../global-configurations/catalog-framework.md#managing-a-schema) documentation to learn more.
+:::
Once saved, this information is displayed in a readable format within the Catalog subsection and is accessible to all users who have permission to view the application.
-
+
+
Figure 9: Catalog Final View
### Configure PersistentVolumeClaim (PVC)
@@ -134,8 +146,7 @@ Before you can configure an Application to use a PVC, you need to make sure the
The following is a sample PVC YAML configuration. You can modify it as needed based on your storage class, access mode, and resource requirements:
-{% code title="pvc.yaml" overflow="wrap" lineNumbers="true" %}
-```bash
+```bash title="pvc.yaml" showLineNumbers
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
@@ -149,13 +160,13 @@ spec:
requests:
storage: 30Gi
```
-{% endcode %}
+
You can apply this configuration using Devtron’s **Resource Browser**
**Apply using Devtron’s Resource Browser**
-1. Navigate to [Resource Browser](../resource-browser/README.md) in the Devtron sidebar.
+1. Navigate to **Infrastructure Management** → [Resource Browser](../resource-browser/README.md)..
2. Select the Cluster where your CI pipelines run.
3. Click **Create Resource**.
4. Paste the YAML into the editor and click **Create**.
@@ -165,7 +176,7 @@ You can apply this configuration using Devtron’s **Resource Browser**
Once PVC is created and in the Bound state, the next step is to configure it within your application using tags from the **About** section.
-Devtron allows you to define special tags as key-value pairs. These tags act as instructions for Devtron to mount the specified PVC to the Pod where the CI pipeline runs, making the storage available during pipeline execution.
+Devtron allows you to define special tag as key-value pair. This tag act as instructions for Devtron to mount the specified PVC to the Pod where the CI pipeline runs, making the storage available during pipeline execution.
You can choose to mount the PVC for all pipelines in the application or for a specific pipeline, depending on your use case. The configuration remains the same in both cases, the only difference lies in the tag key used to define the scope of the PVC.
@@ -173,7 +184,8 @@ Follow the steps below to apply the PVC to all or specific pipelines
1. Navigate to your application’s **Overview** → **About** section.
2. Click the **Edit** icon next to the Tags section.
-
+
+
Figure 10: Clicking Edit Icon
3. Add one of the following key-value tags depending on how you want the PVC to be applied
* To mount the PVC across all pipelines in the application
@@ -182,24 +194,29 @@ Follow the steps below to apply the PVC to all or specific pipelines
|:--- |:--- |
|devtron.ai/ci-pvc-all | cache-pvc |
-
+
+
Figure 11: Mounting PVC across all pipelines
* To mount the PVC for a specific pipeline only in the application
| Key | Value|
|:--- |:--- |
-|devtron.ai/ci-pvc-| cache-pvc |
+|devtron.ai/ci-pvc-``| cache-pvc |
-
+
+
Figure 12a: Finding Pipeline name
-
+
+
Figure 12b: Mounting PVC to a specific pipeline
-> Replace with the exact name of the CI pipeline (visible in the Workflow Editor).
+> Replace `` with the exact name of the CI pipeline (visible in the Workflow Editor).
4. Click **Save** to apply the tag.
After saving, Devtron will automatically mount the PVC into your CI pipeline Pod, allowing it to use the configured persistent storage for caching purposes. No further manual configuration is required.
+---
+
## Environments
The Environments section provides a detailed view of all environments where the application is configured. For each environment, it displays
@@ -212,9 +229,12 @@ The Environments section provides a detailed view of all environments where the
| **Commit**|Displays the Git commit hash associated with the last deployment.|
| **Deployed At**|Indicates who deployed the application and when, it is shown as the email ID of the user along with a relative timestamp (e.g.,9 days ago).|
-
+
+
Figure 13: Environments List
+
+---
-## Dependencies [](https://devtron.ai/pricing)
+## Dependencies
The Dependencies section displays the relationship of the current application with other Devtron-managed applications in the form of upstream and downstream dependencies.
@@ -228,24 +248,29 @@ Upstream dependencies are other Devtron applications that your current applicati
To add upstream dependencies:
1. Click the **Add Dependency** button in the **Dependencies** section. If dependencies already exist, click the **Edit Dependency** button on the right instead.
-
+
+
Figure 14: Dependencies Section
2. In the right-side panel, under Upstream Dependency, click **+ Add Dependency**.
-
+
+
Figure 15: Adding Dependency
3. Use the search bar to find and select one or more applications that your app depends on.
-
+
+
Figure 16: Selecting dependency
4. Click **Map Environments** to associate each selected application with a specific environment.
* This helps Devtron understand where your dependencies are running. By mapping environments, you can view the correct deployment details (like image, commit, and status) for each dependency.
-
+
+
Figure 17: Mapping Environments
5. Once you’ve mapped the environments, click **Save** to confirm and apply the upstream dependencies.
-
+
+
Figure 18: Selecting environments for each dependency
6. After saving:
* The selected applications will appear under **Dependent Applications** above your current application as Upstream Dependencies.
@@ -253,7 +278,8 @@ To add upstream dependencies:
* You can switch the environment of your current application using the dropdown next to its name under **Environment**. This allows you to view the upstream and downstream dependencies specific to that environment. The table will refresh to show deployment details for the selected environment.
* Any applications that have added your app as an upstream will automatically be listed below your app as Downstream Dependencies.
-
+
+
Figure 19: Dependencies List
### Downstream Dependencies
@@ -265,4 +291,4 @@ For every downstream application listed, a **Map Environment** link appears besi
* Clicking this link redirects you to that application’s Dependencies section, where your app will appear in the upstream list.
-* From there, you can assign or update the environment mapping for your app in the context of that downstream application.
+* From there, you can assign or update the environment mapping for your app in the context of that downstream application.
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/workflow/README.md b/docs/user-guide/creating-application/workflow/README.md
old mode 100644
new mode 100755
index 636bd165bb..4335c8aeef
--- a/docs/user-guide/creating-application/workflow/README.md
+++ b/docs/user-guide/creating-application/workflow/README.md
@@ -6,7 +6,8 @@ After configuring the **Build Configurations** and **Base Configurations**, the
In Devtron, a **Workflow** is a logical sequence of different stages(pipelines) used for continuous integration and continuous deployment of an application.
- 
+ 
+
Figure 1: Workflow Editor
---
@@ -18,11 +19,13 @@ To create a quick workflow with both build and deployment pipelines, follow the
1. Click **New Workflow** in the workflow editor.
- 
+ 
+
Figure 2: Selecting 'New Workflow'
2. Select **Build and Deploy from Source Code**; a window appears.
- 
+ 
+
Figure 3: Selecting 'Build and Deploy from Source Code'
3. Enter the required information in the following fields.
@@ -33,7 +36,8 @@ To create a quick workflow with both build and deployment pipelines, follow the
| `Environment` | Required |Select the environment where you want to deploy your application |
| `Namespace`| Required (Auto Filled)| Automatically populated based on the selected environment |
- 
+ 
+
Figure 4: Entering Information
**Source Types**
@@ -46,7 +50,8 @@ To create a quick workflow with both build and deployment pipelines, follow the
4. Click **Create Workflow**; a workflow with both build and deployment pipelines will be created.
- 
+ 
+
Figure 5: Clicking 'Create Workflow'
5. If you want to configure advanced configurations in the build pipeline, such as Custom image tag pattern, Vulnerability Scanning, etc., refer to the [CI Pipeline](./ci-pipeline.md#configuring-advanced-options) page to learn more.
@@ -60,14 +65,15 @@ To create a quick workflow with both build and deployment pipelines, follow the
Apart from configuring advanced options, you can create five types of CI pipelines depending on your use case.
-* [Build from Source Code](./ci-pipeline.md#id-1.-build-from-source-code): Choose this option if you want Devtron to build the image of the source code.
+* [Build from Source Code](./ci-pipeline.md#1-build-from-source-code): Choose this option if you want Devtron to build the image of the source code.
-* [Linked Build Pipeline](./ci-pipeline.md#id-2.-linked-build-pipeline): Choose this option if you want to use an image created by an existing CI pipeline in Devtron.
+* [Linked Build Pipeline](./ci-pipeline.md#2-linked-build-pipeline): Choose this option if you want to use an image created by an existing CI pipeline in Devtron.
-* [Deploy Image from External Service](./ci-pipeline.md#id-3.-deploy-image-from-external-service): Choose this if you want to build your image outside Devtron; it will receive a Docker image from an external source via the incoming webhook.
+* [Deploy Image from External Service](./ci-pipeline.md#3-deploy-image-from-external-service): Choose this if you want to build your image outside Devtron; it will receive a Docker image from an external source via the incoming webhook.
-* [Sync with Environment](./ci-pipeline.md#id-4.-sync-with-environment) [](https://devtron.ai/pricing)
+* [Sync with Environment](./ci-pipeline.md#4-sync-with-environment-)
-* [Create a Job](./ci-pipeline.md#id-5.-create-a-job)
+* [Create a Job](./ci-pipeline.md#5-create-a-job)
-
\ No newline at end of file
+
+
Figure 6: Selecting an Image Source
\ No newline at end of file
diff --git a/docs/user-guide/creating-application/workflow/automated-test.md b/docs/user-guide/creating-application/workflow/automated-test.md
old mode 100644
new mode 100755
index 6cc7b00ce6..7d08335343
--- a/docs/user-guide/creating-application/workflow/automated-test.md
+++ b/docs/user-guide/creating-application/workflow/automated-test.md
@@ -5,6 +5,7 @@ Users can run the test case using the Devtron dashboard or by including the test
The test cases given in the script will run before the test cases given in the devtron.ci.yaml
+
Figure 1: Yaml
| Field | Description |
| :--- | :--- |
diff --git a/docs/user-guide/creating-application/workflow/cd-pipeline.md b/docs/user-guide/creating-application/workflow/cd-pipeline.md
old mode 100644
new mode 100755
index 6bf1d8dd2c..daea26c83d
--- a/docs/user-guide/creating-application/workflow/cd-pipeline.md
+++ b/docs/user-guide/creating-application/workflow/cd-pipeline.md
@@ -1,19 +1,20 @@
# CD Pipeline
-{% hint style="warning" %}
-### Prerequisites
+:::caution Prerequisites
A [CI pipeline](./ci-pipeline.md) created in your workflow.
-{% endhint %}
+:::
After your CI pipeline is ready, you can start building your CD pipeline. Devtron enables you to design your CD pipeline in a way that fully automates your deployments. Images from Build stage can be deployed to one or more environments through dedicated CD pipelines.
Click the '**+**' sign on CI Pipeline to attach a CD Pipeline to it.
-
+
+
Figure 1: Adding CD Pipeline
A basic `Create deployment pipeline` window will pop up.
-
+
+
Figure 2: Creating CD Pipeline
Here, you get two tabs:
* [New Deployment](#new-deployment) - Use this option to create a new Helm/GitOps deployment.
@@ -37,40 +38,38 @@ This section expects four inputs from you:
| ----------- | ---------------------------------------------------------- | ------------------------- |
| Environment | Select the environment where you want to deploy your application | (List of available environments) |
| Namespace | Automatically populated based on the selected environment | Not Applicable |
-| Trigger | When to execute the deployment pipeline | **Automatic**: Deployment triggers automatically when a new image completes the previous stage (build pipeline or another deployment pipeline) **Manual**: Deployment is not initiated automatically. You can trigger deployment with a desired image. |
-| Deployment Approach [](https://devtron.ai/pricing) | How to deploy the application | **Helm**, [GitOps(ArgoCD)](../../integrations/argocd.md) or [Gitops (FluxCD)](../../creating-application/fluxcd.md) Refer [GitOps](../../global-configurations/gitops.md) to learn more |
+| Trigger | When to execute the deployment pipeline | **Automatic**: Deployment triggers automatically when a new image completes the previous stage (build pipeline or another deployment pipeline) **Manual**: Deployment is not initiated automatically. You can trigger deployment with a desired image. |
+| Deployment Approach | How to deploy the application | **Helm**, [GitOps(ArgoCD)](../../integrations/argocd.md) or [Gitops (FluxCD)](../../creating-application/fluxcd.md) Refer [GitOps](../../global-configurations/gitops.md) to learn more |
-{% hint style="warning" %}
- ### FluxCD Deployment Failed
+:::caution FluxCD Deployment Failed
* Make sure that the FluxCD controller is installed in the cluster in which you want to deploy the application. Refer [Enable GitOps Deployments with FluxCD](../../creating-application/fluxcd.md#installing-fluxcd-controller-only-for-deployments) to learn more.
* Application deployments through GitOps (via FluxCD) are supported only when using the `Deployment` or `Rollout` deployment strategies with the latest chart versions. Other deployment strategies are currently not supported.
-{% endhint %}
+:::
-{% hint style="info" %}
-
-### Deploying to an Isolated Environment?
-
-In case you are choosing an [isolated environment](../../global-configurations/cluster-and-environments.md#add-isolated-cluster) for deployment, you will get two additional options to choose from in the 'Deploy to Environment' window ([check snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/use-cases/oci-push/create-cd2.jpg)):
+:::info Deploying to an Isolated Environment?
+In case you are choosing an [isolated environment](../../global-configurations/clusters/add-clusters.md#add-isolated-cluster-) for deployment, you will get two additional options to choose from in the 'Deploy to Environment' window ([check snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/use-cases/oci-push/create-cd2.jpg)):
* **Do not push** - A link to download the helm package will be available after the deployment. However, it will not push the helm package to the OCI registry.
* **Push to registry** - This will generate and [push the helm package to the OCI registry](../../global-configurations/container-registries.md#push-helm-packages). Upon selecting this option, you will get two more fields:
* **Registry** - Choose the OCI registry to which the helm chart package must be pushed. Only those registries that have `Push helm packages` enabled will be shown in the dropdown.
* **Repository** - Enter the repository name. You can find the username from your registry provider account (e.g., Docker Hub).
-{% endhint %}
+:::
### Deployment Strategy
Devtron supports multiple deployment strategies depending on the [deployment chart type](../../creating-application/base-config/deployment-template.md#select-a-deployment-chart-type).
-
+
+
Figure 3: Strategies Supported by Chart Type
Refer to [Deployment Strategies](#deployment-strategies) to know more about each strategy in depth.
The next section is [Advanced Options](#advanced-options) and it comes with additional capabilities. This option is available at the bottom of the `Create deployment pipeline` window. However, if you don't need them, you may proceed with a basic CD pipeline and click **Create Pipeline**.
-
+
+
-{% hint style="info" %}
-### Note
+:::info Note
You can create or edit a deployment strategy in Advanced Options. Remember, only the default strategy will be used for deployment, so use the **SET DEFAULT** button to mark your preferred strategy as default after creating it.
-{% endhint %}
+:::
### Pre-Deployment Stage
If your deployment requires prior actions like DB migration, code quality check (QC), etc., you can use the `Pre-Deployment stage` to configure such tasks. Refer [Pre/Post tasks](./pre-post-tasks.md) to configure tasks in `Pre-Deployment stage`.
-
+
+
Figure 6: Pre-Deployment Stage
@@ -170,17 +171,18 @@ Make sure your cluster has [devtron-agent](../../global-configurations/cluster-a
The pipeline name will be auto-generated; however, you are free to modify the name as per your requirement.
-
+
+
+
+You can view and analyze costs across multiple scopes such as [Clusters](../../reference/glossary.md#cluster), [Projects](../global-configurations/projects.md), [Environments](../../reference/glossary.md#environment), [Applications](../../reference/glossary.md#devtron-apps), and Infrastructure Resources. Devtron automatically tracks the spend on CPU, Memory, Storage, and GPU, giving you a clear picture of how different resources contribute to your overall cost and where most of your spend is concentrated.
+
+The dashboard highlights recommended costs and potential savings, helping you identify over-provisioned resources and opportunities for optimization.
+
+You can choose your preferred currency to view all cost data consistently across different time periods, such as daily, monthly, quarterly, or custom ranges. This helps you move seamlessly from a high-level overview to a granular analysis of costs within a specific category.
\ No newline at end of file
diff --git a/docs/user-guide/finops/configurations.md b/docs/user-guide/finops/configurations.md
new file mode 100755
index 0000000000..c4dd3b4ed9
--- /dev/null
+++ b/docs/user-guide/finops/configurations.md
@@ -0,0 +1,324 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Configurations
+
+The **Configurations** page lets you manage configurations for Cost Visibility in Devtron. You can:
+
+ * Set the default currency for all cost-related data.
+ * Enable or disable cost tracking for your connected clusters.
+
+---
+
+## Currency (Default)
+
+You can select your preferred currency as default.
+
+---
+
+## Enable Cost Tracking
+
+To enable cost visibility for a cluster, follow the below steps:
+
+1. Choose your preferred cluster, and click on **Off/Enabled**. An **Edit Cluster** modal window will open.
+
+2. Enable the toggle next to **Enable cost tracking**.
+
+3. Select the cloud provider in which you have created your cluster.
+
+4. Based on the cloud provider you need to do the following configurations:
+
+
+
+
+
+To enable cost visibility for Google Cloud in Devtron, you need to generate an API key and use it to connect Devtron with your GCP account.
+
+1. Generate the API key using standard [Google Cloud API key documentation](https://cloud.google.com/docs/authentication/api-keys#gcloud).
+
+2. Now go back to the **Edit cluster** modal window, and enter the API key in the **Cloud Provider API Key** field.
+
+:::info
+If you face any issues while enabling or configuring the **Cost Visibility** module, reach out to [Devtron Support Team](mailto:enterprise@devtron.ai) for assistance.
+
+:::
+
+
+
+
+
+To enable cost visibility for your Azure clusters in Devtron, you need to allow Devtron to access your billing data securely. This requires two steps:
+ 1. Create a custom role in Azure with billing access.
+ 2. Create a service principal (an identity) that Devtron can use to fetch cost details.
+
+ #### Step 1: Creating Custom Role
+
+ 1. Open a text editor and copy the following JSON:
+
+ ```json
+{
+ "Name": "OpenCostRole",
+ "IsCustom": true,
+ "Description": "Rate Card query role",
+ "Actions": [
+ "Microsoft.Compute/virtualMachines/vmSizes/read",
+ "Microsoft.Resources/subscriptions/locations/read",
+ "Microsoft.Resources/providers/read",
+ "Microsoft.ContainerService/containerServices/read",
+ "Microsoft.Commerce/RateCard/read"
+ ],
+ "AssignableScopes": [
+ "/subscriptions/YOUR_SUBSCRIPTION_ID"
+ ]
+}
+ ```
+
+2. Replace `YOUR_SUBSCRIPTION_ID` with your actual subscription ID.
+
+3. Save the file as `myrole.json`.
+
+4. Run the following command in your terminal:
+
+```bash
+az role definition create --verbose --role-definition @myrole.json
+```
+
+This creates a role called `OpenCostRole` with just enough access to read pricing information.
+
+#### Step 2: Create a Service Principal
+
+1. Run the command below, again replacing `YOUR_SUBSCRIPTION_ID` with your subscription ID:
+
+```bash
+az ad sp create-for-rbac \
+ --name "OpenCostAccess" \
+ --role "OpenCostRole" \
+ --scope "/subscriptions/YOUR_SUBSCRIPTION_ID" \
+ --output json
+```
+
+2. You’ll get an output like this:
+
+```json
+{
+ "appId": "1d9b1532-abe4-4e08-b172-adfa5384da1",
+ "displayName": "OpenCostAccess",
+ "password": "3XxxxxxxxxxxxxxxxxxxX3",
+ "tenant": "aee9b2ed-7ecc-4cb2-bfed-60d71c0e957"
+}
+```
+
+3. Note this information as you need to enter this in Devtron.
+
+#### Step 3: Enter Details in Devtron
+
+Now go back to the **Edit cluster** modal window, and fill the following fields:
+
+* **Subscription ID** - Your Azure subscription ID
+* **App ID** - Value of `appId` from the output
+* **Display Name** - Value of `displayName` from the output
+* **Password** - Value of `password` from the output
+* **Tenant** - Value of `tenant` from the output
+* **Billing Account** - Optional (fill if available)
+* **Offer ID** - Optional (fill if available)
+
+:::info
+If you face any issues while enabling or configuring the **Cost Visibility** module, reach out to [Devtron Support Team](mailto:enterprise@devtron.ai) for assistance.
+
+:::
+
+
+
+
+
+If you have spot node instances in your AWS cluster, then only you need to do the below additional configurations for your AWS cluster, else you can skip the below configurations
+
+#### Step 1: Set up a Spot Instance Data Feed
+
+1. Create an S3 bucket
+
+2. Assign full access permissions to the AWS Spot Data Feed service
+
+```json
+{
+ "Version": "2012-10-17",
+ "Statement": [
+ {
+ "Effect": "Allow",
+ "Principal": {
+ "Service": "spot.amazonaws.com"
+ },
+ "Action": "*",
+ "Resource": "arn:aws:s3:::devtron-spot-feed/*"
+ },
+ {
+ "Effect": "Allow",
+ "Principal": {
+ "Service": "spot.amazonaws.com"
+ },
+ "Action": "*",
+ "Resource": "arn:aws:s3:::devtron-spot-feed"
+ }
+ ]
+}
+```
+
+3. Run the following command to subscribe to the data feed using the AWS CLI
+
+```bash
+aws ec2 create-spot-datafeed-subscription \
+ --bucket devtron-spot-feed --prefix cost
+```
+:::warning Note
+You can subscribe to the Spot Data Feed for only one S3 bucket at a time. Running the command again updates the feed to the latest bucket.
+:::
+
+
+#### Step 2: Create an IAM Role or Use Access Keys
+
+You can connect Devtron to AWS cost data using either of the following methods:
+
+#### IAM Role (Recommended)
+
+Create a Web Identity IAM role for your EKS/EC2 cluster with permissions to access the Spot Data Feed bucket. Attach the following policy (replace CHANGE-ME with your bucket name)
+
+```json
+{
+ "Version": "2012-10-17",
+ "Statement": [
+ {
+ "Action": [
+ "s3:ListAllMyBuckets",
+ "s3:ListBucket",
+ "s3:Get*"
+ ],
+ "Resource": [
+ "arn:aws:s3:::CHANGE-ME",
+ "arn:aws:s3:::CHANGE-ME/*"
+ ],
+ "Effect": "Allow"
+ }
+ ]
+}
+
+```
+
+#### Access Keys (Alternative)
+
+Provide an Access Key and Secret Key with permissions `s3:ListBucket` and `s3:GetObject` for the Spot Data Feed bucket.
+
+#### Step 3: Configure in Devtron
+
+Now go back to the **Edit cluster** modal window, and fill the following fields:
+
+* **Spot Data Bucket** - Name of the S3 bucket storing Spot Instance Data Feed
+* **Spot Data Region** - AWS region of the Spot Data Feed
+* **Spot Data Prefix** - Prefix (if any) used for the Spot Data Feed
+* **Project ID** - Your AWS Account ID
+* **Access Key** - (Optional) AWS Access Key with S3 read permissions
+* **Secret Access Key** - (Optional) AWS Secret Access Key with S3 read permissions
+* **IAM Role** - (Recommended) IAM role ARN assigned to the EKS/EC2 cluster for bucket access
+
+
+
+
+
+5. Enter Prometheus endpoint of your cluster. Refer [Fetching Prometheus Endpoint](#fetching-prometheus-endpoint) to learn more.
+
+:::warning
+Prometheus endpoint should be publicly exposed for the cost visibility to work.
+
+:::
+
+6. Click **Save**, cost visibility will be enabled for the cluster.
+
+:::info Note
+After enabling cost visibility, you will see your cluster information after 1 hour in cost visibility module.
+:::
+
+---
+
+## Fetching Prometheus Endpoint
+
+:::warning Note
+Ensure [GitOps](../global-configurations/gitops.md) is configured before deploying Prometheus. If not, Prometheus will default to being deployed via Helm.
+:::
+
+### Installing Prometheus
+
+1. Go to the **Chart Store** and search for `prometheus`. Use the Prometheus community's `kube-prometheus-stack` chart to deploy Prometheus.
+
+ 
+
Figure 1: Chart Store
+
+2. After selecting the chart, configure these values as needed before deployment.
+
+ ```yaml
+ kube-state-metrics:
+ metricLabelsAllowlist:
+ - pods=[*]
+ ```
+
+
+
+ ```yaml
+ serviceMonitorSelectorNilUsesHelmValues: false
+ podMonitorSelectorNilUsesHelmValues: false
+ ```
+
+
+
+ Search for the above parameters, and update them as shown (or customize as needed).
+
+ 
+
+
+3. Enable `upgradeJob` parameter to install CRDs:
+
+ Since Helm does not automatically apply CRDs, you need to enable the `upgradeJob` parameter in the Helm chart to ensure CRDs are applied before deploying Prometheus.
+
+ In the Prometheus Helm chart settings, locate the `upgradeJob` parameter and set it to `true` if it is `false`.
+
+ 
+
Figure 3: upgradeJob Parameter
+
+4. After enabling the parameter, click **Deploy Chart**.
+
+ While deploying `kube-prometheus-stack` chart, the deployment status may show as **Timed out**, and some CustomResourceDefinitions (CRDs) may appear as **Failed**. This behavior is expected and does not require any action from you.
+
+ 
+
+
+ This occurs because certain Prometheus CRDs are large in size, which can lead to temporary sync issues during deployment, but, this does not impact the functionality of the Prometheus components.
+
+ ArgoCD handles such cases automatically and the `kube-prometheus-stack` will continue to function as expected.
+
+5. After the chart is deployed successfully, you need to expose the Prometheus endpoint publicly.
+
+:::info
+If you face any issues while enabling or configuring the **Cost Visibility** module, please contact the [Devtron Support Team](mailto:enterprise@devtron.ai) for assistance.
+:::
+
+
\ No newline at end of file
diff --git a/docs/user-guide/finops/cost-breakdown.md b/docs/user-guide/finops/cost-breakdown.md
new file mode 100755
index 0000000000..1ede20126d
--- /dev/null
+++ b/docs/user-guide/finops/cost-breakdown.md
@@ -0,0 +1,216 @@
+import SupademoEmbed from '@site/src/components/SupademoEmbed';
+
+# Cost Breakdown
+
+## Introduction
+
+While the **Overview** section gives you a quick summary of overall spending, the **Cost Breakdown** page lets you analyze deeper into where those costs come from. It helps you analyze costs within a selected category (**Clusters**, **Applications**, **Environments**, or **Projects**), for a specific time range.
+
+
+
Figure 1: Cost Breakdown Overview
+
+ You can apply filters in the top-right corner to adjust the view. Selecting the right filters helps you to focus on the most relevant cost information for your preferred analysis.
+
+For example, you might want to analyze your most recent infrastructure spend across production clusters. In that case, you can set the Clusters Scope filter to `Production` and select a Time Range of Last 30 Days. This will give you a focused view of active workloads and recent spending trends, without including cost from other clusters.
+
+:::success Use Case
+Imagine your team is reviewing this month’s cloud spends and wants to focus only on production clusters. You open the Cost Breakdown page, set the **Clusters Scope** to `Production`, choose your preferred Currency, and adjust the Time Range to Last 30 Days. Instantly, the data updates to show just the relevant costs, providing you a clear picture of active environments and helps you spot any unusual spending patterns. With these quick filters, your team can focus on costs within the defined scope, ensuring the analysis stays relevant to your current objective.
+
+
+:::
+
+| Filter | Description |
+|------------------|-----------------------------------------------------------------------------|
+| **Cluster Scope** | Choose whether to view costs across all clusters or environments, or limit the view to only production or non-production clusters or environments |
+| **Currency** | Displays all cost values in the currency of your choice. |
+| **Time Range** | Defines the time range for data displayed |
+
+---
+
+## Inspecting Different Categories
+
+For the chosen category type (**Clusters**, **Applications**, **Environments**, or **Projects**), it shows the following:
+
+For example, if you select the Clusters category, you can view the total cost across all clusters, the recommended cost based on actual usage, and the potential savings if resources were optimized. This gives you a quick, high-level view of how efficiently each cluster is utilizing its allocated resources.
+
+:::success Use Case
+Imagine your team is analyzing monthly infrastructure expenses for multiple clusters. You notice that the **Total Cost** for one cluster is significantly higher than the others. When you check the **Recommended Cost**, it’s much lower, showing that this cluster is over-provisioned. The Potential Savings metric confirms this, showing how much of your current spend could be reduced by aligning resource allocation with actual usage. With this insight, your team adjusts resource requests to improve overall cost efficiency without impacting performance. By the next billing cycle, costs come down, while the performance remains stable.
+
+
+:::
+
+| Field | Description |
+|:--------------------------- |:----------------------------------------------------------------------------|
+| **Total Cost** | The actual spend for the selected category type (e.g., all clusters). |
+| **Recommended Cost** | The estimated cost calculated from actual resource usage instead of allocated capacity|
+| **Potential Savings** | The amount which you could have saved, for the selected time period|
+| **Estimated cost reduction**| The percentage of your current spend that could be saved, for the selected time period |
+| **Top 10 Costly Resources** | A ranked list of 10 highest cost resources of the selected category|
+
+You will also find a complete list of all the resources for the selected category at the bottom, helping you identify where most of your spending is concentrated.
+
+For example, if you’re viewing the Cluster category, the list displays each cluster along with its CPU, Memory, Storage, and GPU costs. You can quickly compare clusters and identify which ones have higher spend or greater potential savings.
+
+:::success Use Case
+Suppose you’re reviewing costs within the Clusters category. As you go through the list, you notice one cluster’s **Total Cost** is higher than others. You look across its row and notice that both Memory Cost and Storage (PV) Cost are also on the higher side. The **Potential Savings** column then shows a clear opportunity to optimize usage within that cluster. With this focused view, you get a clear understanding of where your resources are being used most and which clusters might need attention, all from a single, organized view. You can then check the detailed view for those clusters to investigate further.
+
+
+:::
+
+
+Each row in the list shows the following for the specific resource of the selected category:
+
+| Field | Available For Categories | Description |
+|:-----------------------|:--------------------------------|:-------------------------------------------------------------------- |
+| **Provider** | Clusters | Shows the cloud provider or infrastructure source for each cluster |
+| **Type** | Clusters, Environments | Shows whether each cluster or environment is **Production** or **Non-Production** |
+| **Applications Count** | Environments, Projects | Shows the number of applications linked to each environment or project |
+| **Environments** | Applications | Shows the number of environments where each application is deployed |
+| **Memory Cost** | All categories | Shows the cost of memory usage for each resource in the selected category |
+| **CPU Cost** | All categories | Shows the cost of CPU usage for each resource in the selected category |
+| **Storage (PV) Cost** | All categories | Shows the cost of persistent volume (storage) usage for each resource in the selected category |
+| **GPU Cost** | All categories | Shows the cost of GPU usage for each resource in the selected category |
+| **Total Cost** | All categories | Shows the total cost of each resource |
+| **Potential Savings** | All categories | Shows the cost and percentage of your current spend that could be saved for each resource |
+
+
+
+
+
+### Inspecting Specific Resource
+
+Clicking on any resource in the Cost Breakdown list opens its detailed cost breakdown view. Based on the category you will see the following:
+
+For example, after identifying a high cost Cluster in the previous section, you can click on that cluster to open its detailed breakdown. In the detailed breakdown view of the cluster, you can see which Namespaces and Applications contribute most to its total cost, and how resource types (like CPU, Memory, and Storage) are distributed.
+
+:::tip Use Case
+
+Continuing from the earlier scenario, you open the detailed cost breakdown for the cluster that showed unusually high costs. In the **Top 10 Costly Namespaces** section, one namespace clearly dominates the cost chart. You then look at the Cost Breakdown by Resource Kind graph, where it becomes evident that most of this cost comes from CPU usage.
+
+Investigating further, you discover that a few workloads in that namespace are utilizing higher memory than their actual usage. This explains the cost spike you noticed earlier. With this insight, your team can adjust resource requests and limits for those workloads to optimize cluster performance and reduce unnecessary costs.
+
+:::
+
+| Field | Description |
+|:---|:---|
+| **Total Cost** | Shows the overall cost for the selected resource, along with a cost trend graph for the chosen time range |
+| **CPU** | Shows the total spend on CPU resources, along with the potential savings |
+| **Memory** | Shows the total cost for memory resources, along with the potential savings |
+| **Storage**| Shows the total cost for persistent volume (storage), along with potential savings |
+| **GPU** | Shows the total cost for GPU resources, along with potential savings |
+|**Top 10 costly :
Namespaces
Applications
Deployments
**| A ranked list of 10 highest cost **namespaces**, or **applications**, or **deployments** within a specific cluster|
+|**Cost Breakdown by:
Namespace
Application
Resource Kind
Deployment
**|Shows the distribution of costs across **Namespaces**, or **Applications**, or **Resource Kinds**, or **Deployments** within the selected cluster.
Each bar represents a **Namespace**, or **Application**, or **Resource Kind**, or **Deployment**, segmented by CPU, Memory, GPU, and Storage costs
|
+
+
+
+
+
+
+
+### Custom Views
+
+**Custom Views** allows you to define your own filtered view of cluster costs. Instead of looking at costs for the entire cluster, you can create a focused view based on propagated tags (for example, filter by team, environment, or application tag).
+
+:::warning Note
+This feature is available only under the Clusters category.
+
+:::
+
+
+For example, if your production workloads are labeled with `environment=production`, you can create a custom view to track cost of production workloads only.
+By creating a custom view with:
+
+**Key**: `environment`
+**Operator** : `:`
+**Value** : `production`
+
+This helps you quickly analyze how much your production workloads are costing without manually filtering every time. As long as your workloads have the right labels, Devtron automatically groups and updates the data in your custom view, giving you a consistent and focused view of your use case.
+
+:::tip Use Case
+
+Imagine your organization runs workloads for multiple teams, frontend, backend, and logistics, all within the same cluster. Each team’s workloads have propagated tags (labels) (for example, workloads of logistic team have `team=logistics` propagated tag).
+
+Your team often needs to check the monthly cloud spend for the logistics workloads, instead of applying filters for workloads every time, you create a custom view once using that label.
+
+Now, whenever you open Cost Visibility, you simply select the “Logistics Team View” from the sidebar to instantly see total cost, usage patterns, and potential savings specific to that team because the workloads are already labeled, the data stays accurate, and your analysis remains consistent, saving time and effort each time you review costs.
+
+:::
+
+:::warning Note
+Custom Views are dependent on propagated tags (labels). If tags are not mentioned and propagated in the workloads, some resources may not appear in the view. Ensure that you have added and propagated tags for the workloads you want to include in the custom view.
+
+:::
+
+#### Creating a Custom View
+
+To create a custom view:
+
+1. Go to **Cost Visibility** → **Cost Breakdown** → **Cluster**.
+
+2. In the sidebar, click `+` icon next to **Custom Views**.
+
+3. Enter a **Name** and an optional **Description** for your view.
+
+4. Enter one or more label-based filters using **Key**, **Operator**, and **Value**.
+
+5. Click **Apply Changes**.
+
+Once applied, a Custom View works just like any other category breakdown in Cost Visibility.
+
+#### Filters
+
+| **Field** | **Description** |
+|--------------|---------------------------------------------------------------------------------|
+| **Key** | The label key applied to your Kubernetes resources (for example, `app`, `team`). |
+| **Operator** | Defines the comparison logic between the key and value. |
+| **Value** | The label value to match against (for example, `logistics`, `prod`). |
+
+#### Operators
+
+| **Operator** | **Meaning** | **Example** |
+|--------------|--------------------------|--------------------------------------------|
+| `:` | Equals to | `app : frontend` → selects resources where `app=frontend`. |
+| `!:` | Not Equals To | `team !: dev` → excludes resources with `team=dev`. |
+| `~:` | Contains | `name ~: api` → selects resources where label contains `api`. |
+| `!~` | Not Contains | `app !~: test` → excludes resources where label contains `test`. |
+| `<~` | Contains Prefix | `env <~: prod` → selects resources where label starts with `prod`. |
+| `!<~` | Not Contains Prefix | `env !<~: staging` → excludes resources where label starts with `staging`. |
+
+---
+
+## FAQs
+
+
+1. Why does Cost Visibility show data for some clusters but not others?
+
+Cost data appears only for clusters where **Cost Visibility** is enabled.
+If a cluster doesn’t show cost insights, verify that the **Cost Visibility** module is active for that cluster.
+
+Refer [Configurations](./configurations.md) to learn more.
+
+
+
+2. What does **Connection Failed** mean in Cluster Health Status?
+
+**Connection Failed** means Devtron could not reach the cluster’s API server or retrieve data from it.
+This can happen due to:
+* Network or firewall restrictions
+* Expired or invalid Kubernetes credentials
+* Misconfigured cluster agent
+
+Try revalidating credentials or redeploying the Devtron agent to restore connectivity.
+
+
+
+3. Why does a cluster show **Not Detected** under Autoscaler in Node Counts?
+
+This means Devtron couldn’t identify any predefined autoscaling configuration, it can be a custom autoscaler.
+
+
+
+4. How often is the infrastructure data updated?
+
+Infrastructure data (including metrics, cost, and health status) is refreshed automatically every hour.
+
\ No newline at end of file
diff --git a/docs/user-guide/finops/overview-cost-visibility.md b/docs/user-guide/finops/overview-cost-visibility.md
new file mode 100755
index 0000000000..5f022e9ec3
--- /dev/null
+++ b/docs/user-guide/finops/overview-cost-visibility.md
@@ -0,0 +1,217 @@
+import SupademoEmbed from '@site/src/components/SupademoEmbed';
+
+# Overview
+
+:::warning Prerequisites
+Make sure that Cost Visibility is enabled for your clusters.
+If it is not enabled, no cost data or insights will appear on the overview page.
+Refer to [Cost Visibility Configurations](./configurations.md) for setup instructions.
+:::
+
+## Introduction
+
+The **Overview** page provides a summary of infrastructure costs across your Applications, Clusters, Environments, Projects, and Infra Components in Devtron. It highlights overall spend, resource-level distribution, and opportunities for optimization (Potential Savings).
+
+At the top, you can choose your preferred currency time and time duration to set the context for your usage costs. This makes sure all costs on the **Overview** page are displayed in the correct currency and time range.
+
+
+
Figure 1: Cost Visibility Overview
+
+Cost Overview has the following sections:
+
+1. [At a Glance](#at-a-glance)
+2. [Potential Savings](#potential-savings)
+3. [Track Performance](#track-performance)
+4. [Actions and Insights](#actions-and-insights)
+
+### How is the cost calculated?
+
+* Devtron calculates and updates cost data **every hour** based on the resource usage metrics collected from **Prometheus**.
+* Prometheus gathers real-time data for **CPU**, **Memory**, **GPU**, and **Storage (PV)** from your connected clusters.
+* Devtron then processes this data every hour to display accurate and up-to-date cost insights across your infrastructure.
+
+---
+
+## At a Glance
+
+The **At a Glance** displays **Total Cost**, **CPU Cost**, **RAM Cost**, **PV Cost**, and **GPU Cost** cards. Each card shows the cost of its specific component, its percentage contribution to the overall spend, and a cost trend graph for the selected time period.
+
+
+
+
+
+
+
+---
+
+## Potential Savings
+
+The **Potential Savings** section estimates how much cost can be saved by comparing the resources you have provisioned with the resources you have actually used. It also shows the percentage of current spend that could be saved.
+
+
+
+
+| Field | Description |
+|:---------------------- |:------------------------------------------------------------------------------------------------ |
+| **Recommended Cost** | The estimated cost calculated from actual resource usage instead of allocated capacity |
+| **Potential Savings** | The amount which you could have saved, for the selected time period|
+| **Estimated cost reduction** | The percentage of your current spend that could be saved, for the selected time period |
+
+
+---
+
+## Track Performance
+
+The **Track Performance** section helps you understand costs in more detail by breaking them down across different views and time ranges. It includes two charts, **Cost Breakdown** and **Cost Trend**.
+
+### Cost Trend Line Chart
+
+The **Cost Trend** line chart helps you understand, how your total and individual resource usage costs change over time. It helps you analyze spending patterns and identify which resources contribute most to your overall cost.
+
+
+
+
+Each colored line represents a specific infrastructure component, CPU, Memory, Storage, or GPU, while the Total line combines all costs. Hovering over any point on the graph displays the exact cost breakdown for that day.
+
+You can change the time range (for example, Last 24 hours, Last 7 Days, Last 30 Days, or Last 90 Days) to view trends for a specific period.
+
+:::info Color Schema
+You can check the color codes for each cost type directly below the chart in the Devtron UI.
+Each color label (like CPU Cost, Memory Cost, or GPU Cost) helps you quickly identify which color represents which resource.
+:::
+
+### Cost Breakdown Bar Chart
+
+The **Cost Breakdown** Bar Chart helps you see how costs are distributed across different infrastructure components for the selected time period.
+
+
+
+
+Each bar represents one [Application](../../reference/glossary.md#devtron-apps), [Cluster](../../reference/glossary.md#cluster), [Environment](../../reference/glossary.md#environment), or [Project](../global-configurations/projects.md), and the colored segments in the bar show the share of different infrastructure components. This makes it easy to compare categories and see which infrastructure components are contributing most to their total cost.
+
+You can:
+
+ * Change the time range (for example, Last 24 hours, Last 7 Days, Last 30 Days, or Last 90 Days) to view trends for a specific period.
+
+ * Filter the cost data by Application, Cluster, Environment, or Project to see how costs are distributed across each scope.
+
+ * Sort the cost data by cost (high to low or low to high) or name (A to Z or Z to A) to quickly find the highest spenders or locate specific items.
+
+:::info Color Schema
+You can check the color codes for each cost type directly below the chart in the Devtron UI.
+Each color label (like CPU Cost, Memory Cost, or GPU Cost) helps you quickly identify which color represents which resource.
+:::
+
+### Most Cost Efficient
+
+The **Most Cost Efficient** section helps you identify which resources are utilizing costs most effectively across different scopes, such as Cluster, Application, Environment, or Project.
+
+
+
+
+Each row in the list displays
+
+| **Field** | **Description** |
+|------------|-----------------|
+| **Name** | The name of the selected category (for example, a project, application, cluster, or environment)|
+| **Total Cost** | The total cost incurred by that category within the selected time range |
+| **Cost Efficiency (%)** | Indicates how efficiently the resource utilizes its allocated cost compared to others. Higher values represent better cost efficiency |
+
+You can use the dropdown menus to customize your view:
+
+| **Filter** | **Description** |
+|-------------|-----------------|
+| **Scope Selector** | Lets you choose whether to view cost efficiency by **Cluster**, **Application**, **Environment**, or **Project**. |
+| **Time Range** | Allows you to select the time range, **Last 24 Hours**, **Last 7 Days**, **Last 30 Days**, or **Last 90 Days**. |
+
+
+### Most Expensive
+
+The **Most Expensive** section highlights the clusters, applications, environments, or projects that contribute the highest costs over a selected time range. This helps you quickly identify where your infrastructure expenses are concentrated and which components may require optimization.
+
+
+
+
+Each row in the list displays:
+
+| **Field** | **Description** |
+|------------|-----------------|
+| **Name** | The name of the selected category, such as a **Cluster**, **Application**, **Environment**, or **Project** |
+| **Cost Type** | The selected cost type, such as **CPU**, **Memory**, **Storage**, **GPU**, or **Total Cost** |
+| **Total Cost** | The total cost incurred by that category for the chosen cost type within the specified time period |
+
+You can customize the view using the following filters:
+
+| **Filter** | **Description** |
+|-------------|-----------------|
+| **Scope Selector** | Lets you choose for which category (**Cluster**, **Application**, **Environment**, or **Project**), you want to view the most expensive resources |
+| **Time Range** | Allows you to choose the time period for cost evaluation, **Last 24 Hours**, **Last 7 Days**, **Last 30 Days**, or **Last 90 Days**. |
+| **Cost Type** | Enables you to filter costs by specific categories such as **CPU Cost**, **Memory Cost**, **Storage Cost**, **GPU Cost**, or **Total Cost**. |
+
+---
+
+## Actions and Insights
+
+The **Actions & Insights** section highlights where you can achieve the highest cost savings. It shows the categories with the largest cost saving opportunities, based on the difference between allocated resources and your actual usage.
+
+
+
+
+It also shows the cost visibility status, which displays the number of clusters where cost visibility is enabled, failed, in progress, or not enabled. This helps you understand for which clusters cost data is currently being tracked and if you want you can enable/disable cost tracking for the cluster by clicking on **Go to configurations** button. Refer [configurations](./configurations.md) to learn more.
+
+Each category in the **Top saving opportunities** will show
+
+| Field | Description |
+|:-----------------------|:------------|
+| **Name** | The name of the category (for example, a cluster, application, or environment) with the largest savings opportunities |
+| **Potential Savings (%)** | The percentage of your current spend that could be saved, for the selected time range |
+| **Estimated Savings** | The estimated cost you could save in that category, based on the difference between provisioned and used resources, for the selected time range|
+
+Clicking on any item in this list takes you to its detailed Cost Breakdown page. Refer [Cost Breakdown](./cost-breakdown.md) to learn more.
+
+---
+
+## FAQs
+
+
+1. Why am I not seeing cost data on the Overview page?
+
+Cost Visibility is only supported for **Devtron** and **Helm** applications.
+If you’re only using **Argo CD** or **Flux** apps, their cost data won’t appear.
+Also, ensure that **Cost Visibility** is enabled for your cluster, refer [Configurations](./configurations.md) to learn more.
+
+
+
+2. What should I do if the graphs look empty or incomplete?
+
+This usually happens when cost tracking is not enabled for certain clusters or when there’s no activity in the selected time range.
+Try expanding the time range.
+
+
+
+3. Can I compare costs across different clusters or applications?
+
+Yes. The **Cost Breakdown**, let you compare spend across **Clusters**, **Applications**, **Environments**, or **Projects**.
+You can also use filters and sorting options to focus on a specific scope or resource type.
+
+
+
+4. What does Potential Savings mean in simple terms?
+
+It shows how much you could save if your resources were right-sized, i.e, it’s the difference between what you’ve **allocated** and what you actually **use**.
+
+
+
+5. How often is the cost data updated?
+
+Cost data is refreshed **automatically every hour**, based on the latest metrics from Prometheus.
+
\ No newline at end of file
diff --git a/docs/user-guide/global-configurations/README.md b/docs/user-guide/global-configurations/README.md
old mode 100644
new mode 100755
index 40ece23ee9..6335b30633
--- a/docs/user-guide/global-configurations/README.md
+++ b/docs/user-guide/global-configurations/README.md
@@ -1,55 +1,50 @@
-# Global Configurations
+---
+id: README
+title: Global Configurations
+sidebar_label: Global Configurations
+description: Manage cluster-level, authorization, and integration settings that apply across all Devtron modules.
+---
-A global configuration allows you to easily share common configuration between multiple repositories without copy/pasting it to these repositories.
+The **Global Configurations** section defines system-wide settings that govern clusters, environments, container registries, authentication, and integrations across Devtron.
-Before you start creating an application, we recommend to provide basic information in different sections of Global Configurations available in `Devtron`.
+Before you start creating an application, we recommend to you to complete the Global Configurations.
-[Host URL](host-url.md)
+These configurations act as the foundation for all application, deployment, and policy operations.
-[GitOps](gitops.md)
+---
-[Projects](projects.md)
+## Table of Contents
-[Clusters & Environments](cluster-and-environments.md)
+### 1. SSO Login Services
+* [Google](./authorization/sso/google.md)
+* [GitHub](./authorization/sso/github.md)
+* [GitLab](./authorization/sso/gitlab.md)
+* [Microsoft](./authorization/sso/microsoft.md)
+* [LDAP](./authorization/sso/ldap.md)
+* [OIDC](./authorization/sso/oidc.md)
+* [Keycloak](./authorization/sso/keycloak.md)
+* [Okta](./authorization/sso/okta.md)
+* [OpenShift](./authorization/sso/openshift.md)
-[Git Accounts](git-accounts.md)
+### 2. [Host URL](./host-url.md)
+Define the base URL for accessing the Devtron dashboard and related services.
-[Container/OCI Registry](container-registries.md)
+### 3. [Cluster and Environments](./cluster-and-environments.md)
+Register and manage Kubernetes clusters and deployment environments available to applications.
-[Chart Repositories](chart-repo.md)
+### 4. [Container/OCI Registry](./container-registries.md)
+Configure Docker or OCI registries where your build artifacts are stored and fetched from during deployment.
-[Deployment Charts](deployment-charts.md)
+### 5. [Authorization](./authorization/README.md)
+Control user access and authentication mechanisms (RBAC).
-[Authorization](authorization/README.md)
+* [User Permissions](./authorization/user-access.md)
+* [Permission Groups](./authorization/permission-groups.md)
+* [API Tokens](./authorization/api-tokens.md)
-[Notifications](manage-notification.md)
-
-[Deployment Window](deployment-window.md)
-
-[Approval Policy](approval-policy.md)
-
-[External Links](external-links.md)
-
-[Catalog Framework](catalog-framework.md)
-
-[Scoped Variables](scoped-variables.md)
-
-[Plugin Policy](plugin-policy.md)
-
-[Pull Image Digest](pull-image-digest.md)
-
-[Tags Policy](tags-policy.md)
-
-[Filter Condition](filter-condition.md)
-
-[Lock Deployment Configuration](lock-deployment-config.md)
-
-[Image Promotion Policy](image-promotion-policy.md)
-
-[Build Infra](build-infra.md)
+ -->
diff --git a/docs/user-guide/global-configurations/application-template.md b/docs/user-guide/global-configurations/application-template.md
old mode 100644
new mode 100755
index 4a1561d00e..70b63e5169
--- a/docs/user-guide/global-configurations/application-template.md
+++ b/docs/user-guide/global-configurations/application-template.md
@@ -1,29 +1,40 @@
+---
+id: application-template
+title: Application Templates
+sidebar_label: Application Templates
+slug: /user-guide/app-management/application-template
+---
+
# Application Templates
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
Application Templates in Devtron allows you to create Devtron application quickly and consistently. An application template in Devtron is created from an existing application. It captures the configuration (workflows, ConfigMaps, Secrets, Build Configurations, Source Repository, etc.) of that application, so the same setup can be reused to create new applications.
Let's assume you have already created a microservice (Devtron Application) with all the required configurations, Git Repository, Build configurations, CI/CD workflows, deployment configurations, etc. Now, instead of repeating the same setup to create a similar Devtron app, you can create an Application Template from your existing Devtron app. This template can then be used to quickly create new microservices (Devtron applications) with the same trusted setup.
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to create Application Templates.
-{% endhint %}
+:::
---
## Creating an Application Template
-1. Navigate to **Global Configurations** → **Application Templates**.
+1. Navigate to **Application Management** → **Application Templates**.
+
+ 
+
Figure 1: Navigating to Application Templates
2. Click **+ Create Template**; a modal window will appear.
- 
+ 
+
Figure 2: Clicking 'Create Template'
3. Select the Application from which you want to create the Application Template; you can also search for the preferred application from the search bar.
- 
+ 
+
Figure 3: Selecting Application
4. Enter the information required by the following fields.
@@ -34,7 +45,8 @@ Users need to have super-admin permission to create Application Templates.
| **Description** | Optional | Provide a short description for the application template |
- 
+ 
+
Figure 4: Entering required details
5. Click **Create Template**; application template will be created.
@@ -44,7 +56,7 @@ Users need to have super-admin permission to create Application Templates.
After you create an application template, you can view the configurations it inherited (Git, Build, Chart, Pipeline config) from the source application. If you wish, you may modify those configurations according to your use cases.
-1. Navigate to **Global Configurations** → **Application Templates**.
+1. Navigate to **Application Management** → **Application Templates**.
2. Select your preferred application template.
@@ -54,18 +66,20 @@ After you create an application template, you can view the configurations it inh
| :------------------------ | :------------------------------------------- |
| **Git Repository** | The source code repository linked to the application.|
| **Build Configurations** | Build configuration is used to create and push docker images in the container registry of your application; refer [Build Configurations](../creating-application/docker-build-configuration.md) to learn more. |
- | **Base Configurations** | Base Configurations let you define the following configurations:
Deployment Template; refer [Base Deployment Template](../creating-application/base-config/deployment-template.md) to learn more.
ConfigMaps; refer [ConfigMaps](../creating-application/base-config/config-maps.md) to learn more.
Secrets; refer [Secrets](../creating-application/base-config/secrets.md) to learn more
|
+ | **Base Configurations** | Base Configurations let you define the following configurations:
**Deployment Template**; refer [Base Deployment Template](../creating-application/base-config/deployment-template.md) to learn more.
**ConfigMaps**; refer [ConfigMaps](../creating-application/base-config/config-maps.md) to learn more.
**Secrets**; refer [Secrets](../creating-application/base-config/secrets.md) to learn more
|
| **CI/CD Workflows**| Define and manage your build and deployment pipelines using Workflow Editor; refer [Workflow Editor](../creating-application/workflow/README.md) to learn more.|
| **Environment Overrides** | Environment Overrides lets you define custom configurations for different environments without changing the base configurations; refer [Environment Overrides](../creating-application/environment-overrides.md) to learn more.|
- 
+ 
+
Figure 5: Customizing Application Template
4. (Optional) You can also define a README for your Application Template
1. Click the **Edit** button in the **Readme** section.
- 
+ 
+
Figure 6: Clicking 'Edit' button
2. A Markdown editor will appear where you can write or modify content under the Write tab.
@@ -75,7 +89,8 @@ After you create an application template, you can view the configurations it inh
5. Click Save to update the **Readme**.
- 
+ 
+
Figure 7: Creating Readme
---
@@ -87,19 +102,20 @@ You can use an application template to create an application. Refer [Creating Ap
## Deleting an Application Template
-1. Navigate to **Global Configurations** → **Application Templates**.
+1. Navigate to **Application Management** → **Application Templates**.
2. Select your preferred application template.
3. Click **Delete Template** in the bottom right corner under **Configurations** tab
- 
+ 
+
Figure 8: Deleting Application
4. A modal window will appear, click **Delete**; application template will be deleted.
- 
+ 
+
Figure 9: Confirming Delete Action
-{% hint style="success" %}
-### Note
+:::tip Note
Deleting an Application Template does not affect any applications, neither the application used to create that template, nor the applications created using that template.
-{% endhint %}
+:::
diff --git a/docs/user-guide/global-configurations/approval-policy.md b/docs/user-guide/global-configurations/approval-policy.md
old mode 100644
new mode 100755
index cb8d77a811..f91ff935a4
--- a/docs/user-guide/global-configurations/approval-policy.md
+++ b/docs/user-guide/global-configurations/approval-policy.md
@@ -1,6 +1,13 @@
+---
+id: approval-policy
+title: Approval Policy
+sidebar_label: Approval Policy
+slug: /user-guide/app-management/policies/approval-policy
+---
+
# Approval Policy
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
When it comes to critical environments (let's say, production), you as a super-admin might want to introduce an approval flow for application deployment or changes made to the configuration files. Enforcing such restrictions will prevent unwanted deployments and direct modifications to sensitive configurations.
@@ -11,70 +18,73 @@ The **Approval Policy** feature in Devtron lets you introduce an approval mechan
- Changes in ConfigMap
- Changes in Secret
-
+
+
Figure 1a: Approval for Deployment
-
+
+
Figure 1b: Approval for Configuration Change
---
## Create an Approval Policy
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permissions to create an approval policy.
-{% endhint %}
+:::
-1. Go to **Global Configurations** → **Approval Policy**.
+1. Go to **Application Management** → **Policies** → **Approval Policy**.
- 
+ 
+
3. Give a name to the policy, e.g., *`banking-prod-approval`*, and add a description (optional) preferably explaining what it does.
- 
+ 
+
Figure 4: Entering Policy Details
4. Additionally, you can decide who can grant approval from the following 3 options:
* **Option 1**: Choose **Any Approver** if you want to allow any user with `Image Approver` permissions and/or `Configuration Approver` permissions to approve 'Deployment' request and 'Configuration Change' respectively. Choose the number of approvals your users must get to proceed with their changes. The permissible limit ranges from one approval (minimum) to six approvals (maximum).
- 
+ 
+
Figure 5: Allowing Any Approver
* **Option 2**: Choose **Specific Approver** → **User Group** → **Add Criteria** to choose one or more [user groups](./authorization/user-access.md#add-users) who can provide the requisite number of approvals. The permissible limit is [1 to 6] for each user group you add. From the selected group(s), only the users having `Image Approver` and/or `Configuration Approver` permissions can approve.
- 
+ 
+
Figure 6: Allowing Approvers from a User Group
* **Option 3**: Choose **Specific Approver** → **Specific Users (dropdown)** to cherry-pick the names of the user(s) who can provide an approval. Here, there is no upper limit to the approvals (unlike the above options), so the user must obtain approvals from all the specific members you add to the policy.
- 
+ 
+
Figure 7: Allowing Specific Users
-{% hint style="warning" %}
-### Caution
+:::caution Caution
* The dropdown lists all users available in Devtron. Some users (except super-admins) may not have the necessary approver permissions, i.e, **Config Approver** or **Deployment approver**. These users cannot approve requests until the required permissions are assigned to them.
* Super-admins have approver permissions by default.
* Refer [User Permissions](./authorization/user-access.md#roles-available-for-devtron-apps) to learn more.
-{% endhint %}
+:::
-{% hint style="info" %}
-### How do approvals of User Groups work?
+:::info How do approvals of User Groups work?
If a user belongs to multiple groups (see Option 2 above), their approval is considered and counted for each group. For example, if you mandate 2 approvals: 1 from DevOps group and 1 from Compliance group; an approval from a common user (belonging to both groups) will count as 2 approvals.
However, once a group's required approvals are met, extra approvals won’t count. For example, if a request needs 2 Security and 3 QA approvals and already has 2 Security and 2 QA approvals, an approval from a user in both teams will count only for QA. The user appears in both lists but doesn’t add to Security’s count.
-{% endhint %}
+:::
-{% hint style="info" %}
-### Can super-admins approve the requests?
+:::info Can super-admins approve the requests?
Yes, apart from the users having approver access, super-admins can also approve the requests (provided the requests are not their own).
-{% endhint %}
+:::
-{% hint style="warning" %}
-### What happens if a specific user mentioned in the policy gets deleted from Devtron or has their permissions revoked?
+:::caution What happens if a specific user mentioned in the policy gets deleted from Devtron or has their permissions revoked?
Even if the user mentioned in the policy no longer exists, the approval conditions will remain unchanged. Therefore, to prevent unfulfilled approval conditions because of an absent user, it's best to remove that specific user from the policy.
-{% endhint %}
+:::
5. Click **Save Changes**.
@@ -82,55 +92,63 @@ Even if the user mentioned in the policy no longer exists, the approval conditio
## Apply an Approval Policy
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permissions to apply an approval policy.
-{% endhint %}
+:::
1. After you create an approval policy, you can apply it. Click **Apply Profile** on the same screen.
- 
+ 
+
Figure 8: Apply Profile Button
2. From the **Select profiles to apply** dropdown, choose the policy you wish to apply. You also have the option to select more than one policy (if they exist) using the checkbox.
- 
+ 
+
Figure 9: Selecting Profiles
3. Choose the scope from the dropdown given next to **Use selected policy for approval of**. Here you can decide whether your policy is for:
* **Approval of Deployment** - Select 'Deployments' from the dropdown.
* **Approval of Configuration Change** - Select 'Configuration change' from the dropdown. You can further select: `Deployment template`, `ConfigMaps`, `Secrets`. Select the ones to which your policy should apply so that any change to your chosen configurations will require an approval.
- 
+ 
+
Figure 10: Choosing Scope
4. Under **Apply to**, you get the following options to choose from:
- * **Specific Criteria** - Select this option to apply your policy to specific environment(s) of specific applications.
+ * **Specific Criteria** - Select this option to apply your policy to specific environment(s) of specific applications.
**Example**: In case of Deployment
- 
+ 
+
Figure 11a: Specific Criteria for 'Deployment' Approval
**Example**: In case of Configuration Change
- 
+ 
+
Figure 11b: Specific Criteria for 'Configuration Change' Approval
- * **By match criteria** - Select this option to use a combination of filters to create criteria. Your policy will only apply to target pipelines/configurations fulfilling your criteria (including existing and future ones). (Optional) You may also write a note for your other team members to understand the intent and context of your policy.
+ * **By match criteria** - Select this option to use a combination of filters to create criteria. Your policy will only apply to target pipelines/configurations fulfilling your criteria (including existing and future ones). (Optional) You may also write a note for your other team members to understand the intent and context of your policy.
**Example**: In case of Deployment
- 
+ 
+
Figure 12a: Match Criteria for 'Deployment' Approval
**Example**: In case of Configuration Change
- 
+ 
+
Figure 12b: Match Criteria for 'Configuration Change' Approval
- * **Global** - Select this option to apply your chosen policies to every deployment pipeline or configurations (existing and future) of all applications in all clusters.
+ * **Global** - Select this option to apply your chosen policies to every deployment pipeline or configurations (existing and future) of all applications in all clusters.
**Example**: In case of Deployment
- 
+ 
+
Figure 13a: Global Scope for 'Deployment' Approval
**Example**: In case of Configuration Change
- 
+ 
+
Figure 13b: Global Scope for 'Configuration Change' Approval
5. Click **Save Changes**.
@@ -139,10 +157,9 @@ Users need to have super-admin permissions to apply an approval policy.
## Apply Multiple Policies
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permissions to apply more policies to a scope.
-{% endhint %}
+:::
As shown in step 2 of [Apply an Approval Policy](#apply-an-approval-policy), you can choose multiple policies and apply them to a scope (e.g., Global, Cluster, Application, Environment, Base Configuration). However, if you have already applied and now you wish to apply more policies to the same scope, you may do so by following either of the below steps:
@@ -158,7 +175,8 @@ As shown in step 2 of [Apply an Approval Policy](#apply-an-approval-policy), you
5. Use the **Select profiles to apply** dropdown and tick the policy/policies you wish to apply.
6. Click **Save Changes**.
- 
+ 
+
Figure 14: Applying More Policy
### Apply More Policies in Bulk
@@ -168,14 +186,14 @@ As shown in step 2 of [Apply an Approval Policy](#apply-an-approval-policy), you
4. Use the **Select profile to apply** dropdown and tick the policy/policies you wish to apply in bulk.
5. Review the changes if needed, and click **Save Changes**.
- 
+ 
+
Figure 15: Applying More Policy in Bulk
-{% hint style="warning" %}
-### How do multiple policies work if applied together?
-If you apply multiple policies together, the user has to meet the approval conditions of all the applied policies.
-**Example 1**: if 'Policy A' demands 3 approvals specifically from John, Jane, and Jessy; and if 'Policy B' requires 1 approval from 'Product User Group', the user will have to get 4 approvals.
+:::caution How do multiple policies work if applied together?
+If you apply multiple policies together, the user has to meet the approval conditions of all the applied policies.
+**Example 1**: if 'Policy A' demands 3 approvals specifically from John, Jane, and Jessy; and if 'Policy B' requires 1 approval from 'Product User Group', the user will have to get 4 approvals.
**Example 2**: if 'Policy A' demands 3 approvals specifically from John, Jane, and Jessy; and if 'Policy B' requires 2 approvals from anyone, the user will still have to get 3 approvals from John, Jane, and Jessy. In short, the stricter conditions from the policies are enforced first and they have to be fulfilled.
-{% endhint %}
+:::
---
@@ -193,7 +211,7 @@ You can choose to:
You can configure whether super-admins are required to follow approval policies or bypass them.
-1. Navigate to **Approval Policy** → **Exceptions**.
+1. Navigate to **Application Management** → **Policies** → **Approval Policy** → **Exceptions**.
2. Choose the scope, for which you want super admins to not require approval.The available scopes are:
@@ -207,18 +225,19 @@ You can configure whether super-admins are required to follow approval policies
* When disabled, super-admins follow same approval policies as other users.
- 
+ 
+
Figure 16: Enabling Super Admins Exception
-{% hint style="info" %}
-### Note
+:::info Note
Super-admins can approve requests even if the toggle is turned off.
-{% endhint %}
+:::
### Excluding Specific Users / User Groups / API Tokens
-1. Navigate to **Approval Policy** → **Exceptions**.
+1. Navigate to **Application Management** → **Policies** → **Approval Policy** → **Exceptions**.
- 
+ 
+
Figure 17: Exceptions Tab
2. Choose the scope for which specific users / user groups / API tokens do not require approval. The available scopes are:
@@ -226,9 +245,10 @@ Super-admins can approve requests even if the toggle is turned off.
* **Deployment:** Exempts the selected users, user groups, and API tokens to deploy images to an environment without requiring approvals.
- 
+ 
+
Figure 18: Selecting Scope
-{% hint style="info"%}
+:::info
### Note
The list of users is fetched from [User Permissions](../global-configurations/authorization/user-access.md), and the list of [API tokens](../global-configurations/authorization/api-tokens.md) is sourced from API Tokens.
@@ -236,46 +256,48 @@ You cannot enter a new email ID or token directly.
* Refer [Add Users (User Permissions)](../global-configurations/authorization/user-access.md#add-users) to add a new user.
* Refer [API token](../global-configurations/authorization/api-tokens.md#generate-api-token) to create a new API token.
-{% endhint %}
+:::
3. Click the **Add**/**Edit** button next to **Specific Users / User Groups**. A pop-up modal window will appear.
- 
+ 
+
Figure 19: Clicking 'Add/Edit'
4. You can do either of the following:
1. You can select specific **Users** or **API Tokens** from **Add Users** dropdown.
- 
+ 
+
Figure 20a: Selecting Specific Users
- 
+ 
+
Figure 20b: Selecting Specific API Tokens
2. You can select specific **Users Groups** from **Add user groups** dropdown.
- 
+ 
+
Figure 21: Selecting Specific User Groups
-{% hint style="warning" %}
-### Caution
+:::caution Caution
* The dropdown lists all users and API tokens or user-groups, available in Devtron. Some users or API tokens may have only view permissions or lack build, deploy, or admin permissions. Such users cannot bypass approval policies until the required permissions are assigned.
* Refer [User Permissions](./authorization/user-access.md#roles-available-for-devtron-apps) to learn more.
-{% endhint %}
+:::
5. Click **Save**. The selected users or user groups will no longer require approvals for the selected scope.
- 
+ 
+
Figure 22: Clicking 'Save'
-{% hint style="warning" %}
-### Caution
+:::caution Caution
By default, approvers cannot approve their own deployments or base configuration edits, but, if an approver is added as an exception, this restriction does not apply, and that approver can trigger their own deployments or edit base configurations without any approvals.
-{% endhint %}
+:::
After configuring exceptions, super-admins and specific users / user groups can make configuration changes and trigger deployments without requiring any approval.
#### Triggering Deployments
-{% hint style="warning" %}
-### Do exceptions bypass blackout or maintenance windows?
+:::caution Do exceptions bypass blackout or maintenance windows?
Approval Policy exceptions do not bypass a blackout or a maintenance window:
* During a blackout window, exception users cannot trigger deployments, unless you add them to the list of users, who are allowed to take action during the blackout window.
@@ -283,41 +305,44 @@ Approval Policy exceptions do not bypass a blackout or a maintenance window:
* Outside a maintenance window, exception users cannot trigger deployments, unless you add them to the list of users, who are allowed to take action outside the maintenance window
* Refer [Deployment Window](../global-configurations/deployment-window.md#configuring-deployment-window) to learn more.
-{% endhint %}
+:::
-{% hint style="info" %}
-### Note
+:::info Note
An exception user can still follow the normal flow of requesting an image approval and getting it approved, and also has the option to deploy images without approvals.
-{% endhint %}
+:::
-
+
+
Figure 23a: Deploying an Image without an Approval
#### Editing Base Configurations
-{% hint style="info" %}
-### Note
+:::info Note
* An exception user can still follow the normal flow of submitting a configuration change draft for approval, and getting it approved.
* Any existing draft is discarded once the exception user updates the configuration using express edit.
-{% endhint %}
+:::
-
+
+
Figure 24a: Editing Deployment Template without an Approval
-
+
+
Figure 24b: Creating/Editing ConfigMap without an Approval
-
+
+
Figure 24c: Creating/Editing Secret without an Approval
---
## Remove Applied Policies
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permissions to remove an applied approval policy.
-{% endhint %}
+:::
If you have already applied policies and wish to remove some of them from a scope, follow the steps below. The approval conditions of the removed policy will no longer apply to the given scope, and the conditions of other policies (if applied to the same scope) will remain.
@@ -333,7 +358,8 @@ If you have already applied policies and wish to remove some of them from a scop
5. In the **Select profiles to apply** dropdown, click '**x**' next to the policy/policies you wish to remove.
6. Click **Save Changes**.
- 
+ 
+
Figure 25: Remove Applied Policy from a Scope
### Remove Applied Policies in Bulk
@@ -343,21 +369,20 @@ If you have already applied policies and wish to remove some of them from a scop
4. In the **Remove Approval Policy** dropdown, click '**x**' next to the policy/policies you wish to remove.
5. Review the changes if needed, and click **Save Changes**.
- 
+ 
+
Figure 26: Removing Policies in Bulk
-{% hint style="warning" %}
-### Note
+:::caution Note
At least one policy must remain applied to a scope, so you cannot remove all the policies from a scope. You may use the [delete procedure](#delete-applied-policies) instead.
-{% endhint %}
+:::
---
## Delete Applied Policies
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permissions to delete an applied policy.
-{% endhint %}
+:::
If you have already applied policies to a scope (e.g., Global, Cluster, Application) and wish to delete all of them from that given scope, follow the steps below. **Note**: This will not [delete the approval policy](#delete-an-approval-policy) you originally created. Moreover, deployment pipelines may still continue inheriting profiles from higher scopes (e.g., Global, Cluster, Application).
@@ -365,23 +390,27 @@ If you have already applied policies to a scope (e.g., Global, Cluster, Applicat
2. Use the filters to find the applied profile(s).
3. Click the **Delete** option in the context menu or use the checkboxes to select multiple scopes for deletion.
- 
+ 
+
---
## Delete an Approval Policy
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permissions to delete an approval policy.
-{% endhint %}
+:::
If you no longer require a given approval policy, you may delete it. This action will automatically remove its rules enforced earlier for both, deployments and configuration change.
1. Go to **Profiles** tab.
2. Click the delete icon next to the profile you wish to delete.
- 
+ 
+
Figure 28: Deleting Approval Policy
---
@@ -391,38 +420,58 @@ If you no longer require a given approval policy, you may delete it. This action
Assume you created a policy (shown below) that blocks the deployment of a banking application to an environment unless there are two approvals. No user can trigger the deployment unless the images are approved.
-
+
+
Figure 29: Example
1. The user first requests approval of the intended image. Only those with the necessary permissions will show up in the approver list. Moreover, the user can also opt to notify all users apart from the approvers.
- 
+ 
+
Figure 30: Request Approval for Deployment
2. Only those with `Image Approver` permissions can then approve the request.
- 
+ 
+
Figure 31: User with 'Image Approver' Permissions granting approval
+
+
+ A super-admin can check or modify a user permissions with approval rights by going to Global Configurations → Authorization (dropdown) → User Permissions.
+
+ 
+
Figure 32: Checking Permissions
If [SES/SMTP](../global-configurations/manage-notification.md) is configured in Devtron, the approver gets notified via email. This enables the approver to take an action directly from the mail, such as `View Request` and `Approve Request`.
- 
+ 
+
Figure 33: Approval via Email
3. The user can then proceed with deploying the approved image.
- 
+ 
+
Figure 34: Deployment of Approved Image
### Approving Configuration Change Request
Assume you created a policy (shown below) that prevents direct changes to the configuration files (Deployment Template, ConfigMaps, Secrets) of a banking application unless there is one approval.
-
+
+
Figure 35: Example
1. The user first requests approval for pushing a configuration change in Deployment Template/ConfigMap/Secret.
- 
+ 
+
Figure 36: Request Approval for Configuration Change
2. Only those with `Configuration Approver` permissions can then approve the request.
- 
+ 
+
Figure 37: User with 'Configuration Approver' permissions granting approval
+
+ A super-admin can check or modify a user permissions with approval rights by going to Global Configurations → Authorization (dropdown) → User Permissions.
+
+ 
+
Figure 38: Checking Permissions
If [SES/SMTP](../global-configurations/manage-notification.md) is configured in Devtron, the approver gets notified via email. Therefore, the approver can take an action directly from the mail as shown below.
- 
\ No newline at end of file
+ 
+
Figure 39: Config Approval via Email
\ No newline at end of file
diff --git a/docs/user-guide/global-configurations/authorization/README.md b/docs/user-guide/global-configurations/authorization/README.md
old mode 100644
new mode 100755
index 6962cfe937..097c47a004
--- a/docs/user-guide/global-configurations/authorization/README.md
+++ b/docs/user-guide/global-configurations/authorization/README.md
@@ -1,8 +1,10 @@
-`Authorization` section describes how to authenticate and authorize access to resources, also managing role-based access levels in Devtron.
+---
+hide_table_of_contents: true
+---
-Access can be granted to a user via:
+**Authorization** section describes how to authenticate and authorize access to resources, also managing role-based access levels in Devtron.
-* [SSO Login Services](../sso-login.md)
+Access can be granted to a user via:
* [User Permissions](user-access.md)
diff --git a/docs/user-guide/global-configurations/authorization/api-tokens.md b/docs/user-guide/global-configurations/authorization/api-tokens.md
old mode 100644
new mode 100755
index 5b60c39d39..cf9432b2fc
--- a/docs/user-guide/global-configurations/authorization/api-tokens.md
+++ b/docs/user-guide/global-configurations/authorization/api-tokens.md
@@ -6,18 +6,21 @@ API tokens are the access tokens for authentication. Instead of using username a
To generate API tokens, go to `Global Configurations -> Authorization -> API tokens` and click `Generate New Token`.
-
+
+
Figure 1: Generating API 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).
-
+
+
Figure 2: Configuring Token Expiry
* 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.
-
+
+
Figure 3: Configuring Custom Expiry
* You can assign permission to the token either with:
@@ -27,14 +30,16 @@ To generate API tokens, go to `Global Configurations -> Authorization -> API tok
* **Specific permissions**: Selecting `Specific permissions` option allows you to generate a token with a specific role for:
* Click `Generate Token`.
A pop-up window will appear on the screen from where you can copy the API token.
-
+
+
Figure 5: Copying Generated Token
## Use API Token
@@ -42,16 +47,19 @@ Once Devtron API token has been generated, you can use this token to request Dev
Open Postman. Enter the request URL with `POST` method and under HEADERS, enter the API token as shown in the image below.
-
+
+
Figure 6: Entering 'RequestURL' in Postman
In the `Body` section, provide the API payload as shown below and click `Send`.
-
+
+
Figure 7: Entering API Payload
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.
-
+
+
Figure 8: Clicking 'Send'
## Update API Token
@@ -59,23 +67,27 @@ As soon as you click `Send`, the created application API will be triggered and a
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.
-
+
+
Figure 9: Editing API Token
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.
-
+
+
Figure 10: Regenerating Token
Select a new expiration date and click `Regenerate token`.
-
+
+
Figure 11: Configuring Expiry for Regenerating the 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 update API token permissions, give the permissions as you want to and click `Update Token`.
-
+
+
Figuring 12: Updating API Token
## Delete API Token
diff --git a/docs/user-guide/global-configurations/authorization/permission-groups.md b/docs/user-guide/global-configurations/authorization/permission-groups.md
old mode 100644
new mode 100755
index 5c91270cf8..c46b56e034
--- a/docs/user-guide/global-configurations/authorization/permission-groups.md
+++ b/docs/user-guide/global-configurations/authorization/permission-groups.md
@@ -4,21 +4,23 @@ Using the `Permission groups`, you can assign a user to a particular group and a
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.
-{% hint style="info" %}
+:::info
The [User permissions](../../global-configurations/authorization/user-access.md) 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.
-{% endhint %}
+:::
## Add Group
Go to **Global Configurations** → **Authorization** → **Permissions groups** → **Add group**.
-
+
+
Figure 1: Navigate to Permission Groups
Enter the `Group Name` and `Description`.
-
+
+
Figure 2: Entering Basic Details
-You can either grant [super-admin](../../global-configurations/authorization/user-access.md#role-based-access-levels) permission to a user group or specific permissions to manage access for:
+You can either grant [super-admin](../../global-configurations/authorization/user-access.md#grant-super-admin-permission) permission to a user group or specific permissions to manage access for:
* [Devtron Apps](#devtron-apps-permissions)
* [Helm Apps](#helm-apps-permissions)
@@ -30,21 +32,22 @@ You can either grant [super-admin](../../global-configurations/authorization/use
In `Devtron Apps` option, you can provide access to a group to manage permission for custom apps created using Devtron.
-{% hint style="info" %}
+:::info
The `Devtron Apps` option will be available only if you install [CI/CD integration](../../integrations/build-and-deploy-ci-cd.md).
-{% endhint %}
+:::
Provide the information in the following fields:
-
+
+
Figure 3: Configuring Permissions for Devtron Apps
| Dropdown | Description |
| --- | --- |
-| **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** | Select one of the [roles](#role-based-access-levels) to which you want to give permission to the user:
`View only`
`Build and Deploy`
`Admin`
`Manager`
|
+| **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** | Select one of the [roles](#devtron-apps-permissions) to which you want to give permission to the user:
`View only`
`Build and Deploy`
`Admin`
`Manager`
|
You can add multiple rows for `Devtron Apps` permission.
@@ -56,16 +59,17 @@ In `Helm Apps` option, you can provide access to a group to manage permission fo
Provide the information in the following fields:
-
+
+
Figure 4: Configuring Permissions for Helm Apps
| Dropdown | Description |
| --- | --- |
-| **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** | Select one of the [roles](#role-based-access-levels) to which you want to give permission to the user:
`View only`
`View & Edit`
`Admin`
|
+| **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** | Select one of the [roles](#helm-apps-permissions) to which you want to give permission to the user:
`View only`
`View & Edit`
`Admin`
|
-You can add multiple rows for Devtron app permission.
+You can add multiple rows for Helm app permission.
Once you have finished assigning the appropriate permissions for the groups, Click **Save**.
@@ -75,15 +79,16 @@ In `Jobs` option, you can provide access to a group to manage permission for job
Provide the information in the following fields:
-
+
+
Figure 5: Configuring Permissions for Jobs
| Dropdown | Description |
| --- | --- |
-| **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** | Select one of the [roles](#role-based-access-levels) to which you want to give permission to the user:
`View only`
`Run job`
`Admin`
|
+| **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** | Select one of the roles to which you want to give permission to the user:
`View only`
`Run job`
`Admin`
|
You can add multiple rows for `Jobs` permission.
@@ -94,27 +99,29 @@ Once you have finished assigning the appropriate permissions for the groups, Cli
In `Kubernetes Resources` option, you can provide permission to view, inspect, manage, and delete resources in your clusters from [Kubernetes Resource Browser](../../../user-guide/resource-browser/README.md) page in Devtron. You can also create resources from the `Kubernetes Resource Browser` page.
-{% hint style="info" %}
+:::info
Only super admin users will be able to see `Kubernetes Resources` tab and provide permission to other users to access `Resource Browser`.
-{% endhint %}
+:::
To provide Kubernetes resource permission, click `Add permission`.
-
+
+
Figure 6: Configuring Permissions for Kubernetes Resources
On the `Kubernetes resource permission`, provide the information in the following fields:
-
+
+
Figure 7: Adding Kubernetes Resource
| Dropdown | Description |
| --- | --- |
-| **Cluster** | Select a cluster from the drop-down list to which you want to give permission to the user. You can select only one cluster at a time. Note: To add another cluster, then click `Add another`. |
+| **Cluster** | Select a cluster from the drop-down list to which you want to give permission to the user. You can select only one cluster at a time. Note: To add another cluster, then click `Add another`. |
| **Namespace** | Select the namespace from the drop-down list. |
| **API Group** | Select the specific API group or `All API groups` from the drop-down list corresponding to the K8s resource. |
**Kind** | Select the kind or `All kind` from the drop-down list corresponding to the K8s resource. |
**Resource name** | Select the resource name or `All resources` from the drop-down list to which you want to give permission to the user. |
-| **Role** | Select one of the [roles](#role-based-access-levels) to which you want to give permission to the user and click `Done`:
`View`
`Admin`
|
+| **Role** | Select one of the [roles](#kubernetes-resources-permissions) to which you want to give permission to the user and click `Done`:
`View`
`Admin`
|
You can add multiple rows for Kubernetes resource permission.
@@ -124,15 +131,16 @@ Once you have finished assigning the appropriate permissions for the groups, Cli
In `Chart group permission` option, you can manage the access of groups for Chart Groups in your project.
-{% hint style="info" %}
+:::info
The `Chart group permission` option will be available only if you install [CI/CD integration](../../integrations/build-and-deploy-ci-cd.md).
-{% endhint %}
+:::
-
+
+
Figure 8: Configuring Permissions for Chart Groups
-{% hint style="info" %}
+:::info
You can only give users the ability to `create` or `edit`, not both.
-{% endhint %}
+:::
| Action | Permissions |
| :--- | :--- |
@@ -147,11 +155,13 @@ Click **Save** once you have configured all the required permissions for the gro
You can edit the permission groups by clicking the `downward arrow.`
-
+
+
Figure 9: Editing Permissions Groups
Edit the permission group.
-
+
+
Figure 10: Saving Permission Group
Once you are done editing the permission group, click **Save**.
diff --git a/docs/user-guide/global-configurations/authorization/sso/github.md b/docs/user-guide/global-configurations/authorization/sso/github.md
old mode 100644
new mode 100755
index 4f56c2ccd6..aed12ee2a1
--- a/docs/user-guide/global-configurations/authorization/sso/github.md
+++ b/docs/user-guide/global-configurations/authorization/sso/github.md
@@ -23,15 +23,20 @@ Getting the redirectURI from Devtron is a crucial component of the authenticatio
1. Navigate to **Global Configurations** → **Authorization** → **SSO Login Services**. The SSO Login Service page is displayed.
- 
+ 
+
Figure 1: Select Github
2. Select **GitHub** from the list of available SSO login services.
-3. Click the URL suggested in green color next to the **Click to use** label to update the **URL** field. Update the **URL** field only if the host URL displayed in the **URL** field is incorrect.
+3. Click the URL suggested in green color next to the **Click to use** label to update the **URL** field.
-4. Click the **Update** button.
+ When you populate **URL** field, the redirectURI (or callbackURI) is updated automatically in the purple block displayed at the top of the SSO Login Service screen. This redirectURI is essential, as it is required while setting up the OAuth credentials in GitHub.
+
+4. Copy the redirectURI from the purple block.
+
+ 
+
Figure 2: Copy Redirect URI
-When you populate the Host URL in the **URL** field, the redirectURI (or callbackURI) is updated automatically in the purple block displayed at the top of the SSO Login Service screen. This redirectURI is essential, as it is required while setting up the OAuth credentials in GitHub.
---
@@ -45,7 +50,8 @@ Open Authentication (OAuth) allows you to authorize one application to sign in t
2. Select your preferred OAuth app and click **Edit**.
- 
+ 
+
Figure 3: Client ID and Client Secret
3. Click the **Generate a new client secret** button to create a new client secret. The client secret is created and displayed in the **Client Secrets** section. The Client ID is created by default and can be found in the **Client ID** field.
@@ -65,7 +71,8 @@ To configure the GitHub SSO in Devtron, follow the below steps of instructions:
2. Select the **Configuration** section available below the **URL** field.
- 
+ 
+
Figure 4: Configuration Section
3. Update the `clientID` attribute with the Client ID generated in the OAuth application on GitHub.
@@ -75,14 +82,19 @@ To configure the GitHub SSO in Devtron, follow the below steps of instructions:
6. Click **Update** to save the configuration. GitHub SSO is now successfully configured.
-
+
+
Figure 5: Sign in with GitHub
----
+:::tip Common error: "Some required field are missing"
-{% hint style="warning" %}
+If you see this error while saving the GitHub SSO configuration, ensure that you have set the **URL** field above the configuration editor.
-### Important: Enable User Access After SSO Setup
+Click the **Click to use** link shown below the URL field to auto-populate the correct Devtron URL, or manually enter it before saving.
+:::
+
+---
+:::caution Important: Enable User Access After SSO Setup
Although GitHub SSO is now configured, you will not be able to sign in with GitHub unless you add yourself as a user with the necessary permissions and manage other user permissions as well in Devtron. For detailed steps on managing user permissions, refer to the [User Permissions Documentation](../user-access.md).
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/user-guide/global-configurations/authorization/sso/gitlab.md b/docs/user-guide/global-configurations/authorization/sso/gitlab.md
old mode 100644
new mode 100755
index 85b7153d54..058afe5836
--- a/docs/user-guide/global-configurations/authorization/sso/gitlab.md
+++ b/docs/user-guide/global-configurations/authorization/sso/gitlab.md
@@ -11,7 +11,7 @@ Setting up GitLab SSO enables you to authenticate using your GitLab account, ens
To configure GitLab SSO in Devtron, you need:
* Super Admin permissions
- * Only a [Super Admin](../../user-access.md) in Devtron can configure SSO. You can use the [Admin credentials](../../../../setup/install/devtron-oss.md#install-devtron-oss) provided during the initial setup, if you’re setting up Devtron for the first time.
+ * Only a [Super Admin](../user-access.md) in Devtron can configure SSO. You can use the [Admin credentials](../../../../setup/install/devtron-oss.md#step-4-log-in-to-devtron) provided during the initial setup, if you’re setting up Devtron for the first time.
* A GitLab account to create and manage OAuth credentials. If you do not have a GitLab account, you must create it first on GitLab.
@@ -25,15 +25,19 @@ Getting the redirectURI from Devtron is a crucial component of the authenticatio
1. Navigate to **Global Configurations** → **Authorization** → **SSO Login Services**. The SSO Login Service page is displayed.
- 
+ 
+
Figure 1: Select Gitlab
2. Select **GitLab** from the list of available SSO login services.
-3. Click the URL suggested in green color next to the **Click to use** label to update the **URL** field. Update the **URL** field only if the host URL displayed in the **URL** field is incorrect.
+3. Click the URL suggested in green color next to the **Click to use** label to update the **URL** field.
-4. Click the **Save** button.
+ When you populate **URL** field, the redirectURI (or callbackURI) is updated automatically in the purple block displayed at the top of the SSO Login Service screen. This redirectURI is essential, as it is required while setting up the OAuth credentials in GitHub.
-When you populate the Host URL in the **URL** text box, the redirectURI (or callbackURI) is updated automatically in the purple block at the top of the SSO Login Service screen. This redirectURI is essential, as it is required while setting up the OAuth credentials in GitLab.
+4. Copy the redirectURI from the purple block.
+
+ 
+
Figure 2: Copy Redirect URI
---
@@ -47,7 +51,8 @@ Open Authentication (OAuth) allows you to authorize one application to sign in t
2. Select your preferred OAuth app and click **Edit**.
- 
+ 
+
Figure 3: GitLab OAuth Applications List
3. Update the **Redirect URI** field with the redirectURI created in Devtron.
@@ -55,7 +60,8 @@ Open Authentication (OAuth) allows you to authorize one application to sign in t
5. Click the **Save Application** button. The following page is displayed.
- 
+ 
+
Figure 4: GitLab OAuth Application
The client ID is displayed in the **Application ID** field.
@@ -71,7 +77,8 @@ To configure the GitLab SSO in Devtron, follow the below steps of instructions:
2. Select the **Configuration** section available next to the **URL** field.
- 
+ 
+
Figure 5: GitLab SSO Configuration
3. Update the `clientID` attribute with the Client ID generated in the OAuth application on GitLab.
@@ -81,15 +88,20 @@ To configure the GitLab SSO in Devtron, follow the below steps of instructions:
6. Click **Update** button to save the configuration. GitLab SSO is now successfully configured.
-
+
+
Figure 6: Login with GitLab
+
+:::tip Common error: "Some required field are missing"
-{% hint style="warning" %}
+If you see this error while saving the GitLab SSO configuration, ensure that you have set the **URL** field above the configuration editor.
-### Important Note
+Click the **Click to use** link shown below the URL field to auto-populate the correct Devtron URL, or manually enter it before saving.
+:::
+:::caution Important Note
Although GitLab SSO is now configured, you will not be able to sign in with GitLab unless you add yourself as a user with the necessary permissions and manage other user permissions as well in Devtron. It is highly recommended to create [User Permissions](../user-access.md).
-{% endhint %}
+:::
---
diff --git a/docs/user-guide/global-configurations/authorization/sso/google.md b/docs/user-guide/global-configurations/authorization/sso/google.md
old mode 100644
new mode 100755
index c165ad0879..9dbd562f38
--- a/docs/user-guide/global-configurations/authorization/sso/google.md
+++ b/docs/user-guide/global-configurations/authorization/sso/google.md
@@ -4,10 +4,7 @@
Integrating Google as your Single Sign-On (SSO) provider enables users to authenticate with their Google accounts, ensuring secure and streamlined access to Devtron. This document walks you through setting up Google SSO in Devtron, ensuring users can log in smoothly.
-{% hint style="info" %}
-
-### Prerequisites
-
+:::info Prerequisites
To configure Google SSO in Devtron, you will need:
* Super Admin permissions
@@ -16,7 +13,7 @@ To configure Google SSO in Devtron, you will need:
* A Google Cloud account to create and manage OAuth credentials. If you don’t have one, you must create it at the [Google Cloud Console](https://console.cloud.google.com/).
-{%endhint%}
+:::
## Get the Redirect URI from Devtron
@@ -30,7 +27,7 @@ Before configuring Google as an SSO provider,
* Click the URL next to **Click to use** in green color. The URL field will be automatically populated with the URL next to **Click to use**; this is essential to generate the correct **Redirect URI**.
* Copy the **Redirect URI** displayed in this section. You will need to enter this in Google Cloud.
- {% embed url="https://www.youtube.com/watch?v=QvufIzUSNpg" caption="Getting the Redirect URI" %}
+
## Configure OAuth in Google Cloud Console
@@ -45,33 +42,36 @@ The next step is to configure OAuth credentials in Google Cloud Console. This in
* Paste the Redirect URI (copied from Devtron) under Authorized Redirect URIs.
* Click **Create** to generate the Client ID and Client Secret.
-{% hint style="warning" %}
+:::caution
### Google SSO Requires a Valid Domain with HTTPS
Google does not support IP addresses as valid redirect URIs. You must use a valid domain name ([FQDN](https://en.wikipedia.org/wiki/Fully_qualified_domain_name)) accessible over HTTPS.
Examples of valid URIs:
-✅ https://devtron.example.com/api/dex/callback
+✅ `https://devtron.example.com/api/dex/callback`
-✅ https://auth.yourcompany.com/callback
+✅ `https://auth.yourcompany.com/callback`
Examples of invalid URIs:
-❌ http://localhost:8080/callback
+❌ `http://localhost:8080/callback`
-❌ http://192.168.1.10/callback
-{% endhint %}
+❌ `http://192.168.1.10/callback`
+:::
-
+
+
Figure 1: Creating OAuth Client
You can see a new client ID is created in the **APIs & Services** → **Credentials**, under **OAuth 2.0 Client IDs** section. To obtain Client ID and Client Secret, click on the name (devtron-sso in our case) of the **OAuth 2.0 Client IDs**
-
+
+
Figure 2: Client ID Created
Copy the Client ID and Client Secret, as they will be required in Devtron’s SSO configuration.
-
+
+
Figure 3: Get the Client ID and Client Secret
For a detailed step-by-step guide, refer to Google’s official documentation: [Get Google API Client ID](https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid).
@@ -79,9 +79,13 @@ For a detailed step-by-step guide, refer to Google’s official documentation: [
The next step is to configure Devtron to use these credentials for authentication. For this, navigate back to **Global Configurations → SSO Login Services**, here you can already find a configuration template.
+
+
In the configuration,
@@ -95,9 +99,16 @@ In the configuration,
* Copy the Redirect URI displayed in Devtron and paste the value in the `redirectURI` field.
* Click **Update** to save the configuration, once saved, Google SSO is successfully configured
-{% hint style="warning" %}
+:::tip Common error: "Some required field are missing"
+
+If you see this error while saving the Google SSO configuration, ensure that you have set the **URL** field above the configuration editor.
+
+Click the **Click to use** link shown below the URL field to auto-populate the correct Devtron URL, or manually enter it before saving.
+:::
+
+:::caution
Although Google SSO is now set up, users will not be able to sign in unless they are explicitly added to Devtron with the necessary permissions.
-{% endhint %}
+:::
## Important: Enable User Access After SSO Setup
@@ -106,13 +117,16 @@ To ensure users can log in:
* Go to **Global Configurations** → **Authorization** → **User Permissions**.
* Click **Add User**.
-
+
+
Figure 6: Adding User with required permissions
* Enter their email (matching their Google account).
* Assign the required role.
* Click **Save** to complete the setup.
-
+
+
+
Figure 7: Configuring User Permissions
Once saved, Devtron will use Google OAuth for authentication, allowing users to log in using their Google accounts.
diff --git a/docs/user-guide/global-configurations/authorization/sso/keycloak.md b/docs/user-guide/global-configurations/authorization/sso/keycloak.md
old mode 100644
new mode 100755
index ba0b491976..48c1d0c2af
--- a/docs/user-guide/global-configurations/authorization/sso/keycloak.md
+++ b/docs/user-guide/global-configurations/authorization/sso/keycloak.md
@@ -7,6 +7,26 @@
---
+## Get the redirectURI from Devtron
+
+1. Navigate to **Global Configurations** → **Authorization** → **SSO Login Services**. The SSO Login Service page is displayed.
+
+ 
+
Figure 1: Select OIDC
+
+2. Select **OIDC** from the list of available SSO login services.
+
+3. Click the URL suggested in green color next to the **Click to use** label to update the **URL** field.
+
+ When you populate **URL** field, the redirectURI (or callbackURI) is updated automatically in the purple block displayed at the top of the SSO Login Service screen. This redirectURI is essential, as it is required while setting up the OAuth credentials in GitHub.
+
+4. Copy the redirectURI from the purple block.
+
+ 
+
Figure 2: Copy Redirect URI
+
+---
+
## Steps on Keycloak Admin Console
### Creating a Client
@@ -15,27 +35,29 @@ Here, we will add Devtron as a client for using Keycloak SSO.
1. In the Admin Console, go to **Clients** and click **Create client**.
- 
+ 
+
Figure 3: Creating Client on Keycloak
2. Within **General Settings**:
* Enter `devtron` in the **Client ID** field. We will use this ID while configuring SSO later in Devtron.
* Enter `Devtron` in the **Name** field.
- 
+ 
+
Figure 4: Client ID and Name
3. Within **Capability config**, turn on **Client Authentication**.
- 
+ 
+
Figure 5: Enabling Client Authentication Toggle
-4. Within **Login settings**, enter `https:///orchestrator/api/dex/callback` in the following fields.
+4. Within **Login settings**, enter the `redirectURI` you have copied earlier in the following fields.
* **Valid redirect URIs**
* **Valid post logout redirect URIs**
* **Web origins**
- [Click here](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/global-configurations/sso-login-service/keycloak/base-url.jpg) to know where to find `DEVTRON_BASE_URL`.
-
- 
+ 
+
Figure 6: Entering Callback/Redirect URIs
5. Click **Save**.
@@ -45,7 +67,8 @@ Here, we will obtain the secret we need while configuring SSO in Devtron.
1. Go to the **Credentials** tab of the client you created.
- 
+ 
+
Figure 7: Obtaining Client Secret
2. Use the copy button next to the **Client Secret** field and paste it somewhere for future reference.
@@ -57,13 +80,15 @@ Here, we will create a user that can log in to Devtron via SSO. We will assign a
2. Give a username (e.g., *usertest*) in the **Username** field and enter the user's email address (e.g., *usertest@example.com*) in the **Email** field.
- 
+ 
+
Figure 8: Creating User Data
3. Click **Create**. Your user creation will be successful.
4. Go to the **Credentials** tab of the user you created.
- 
+ 
+
Figure 9: Adding User Password
5. Click **Set password**.
@@ -79,11 +104,13 @@ Here, we will obtain the Issuer URL we need while configuring SSO in Devtron.
2. In the **General** tab, scroll down to the **Endpoints** field, and click the **OpenID Endpoint Configuration** link.
- 
+ 
+
Figure 10: OpenID Endpoint Configuration Link
3. This will open a new page, copy the value of the key named `issuer`, and paste it somewhere for future reference.
- 
+ 
+
Figure 11: Locating Issuer URL
---
@@ -91,37 +118,30 @@ Here, we will obtain the Issuer URL we need while configuring SSO in Devtron.
### Configuring OIDC SSO
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to configure SSO.
-{% endhint %}
+:::
Here, we will set up an OIDC SSO and enter the values we obtained in the [previous section](#steps-on-keycloak-admin-console).
1. Go to **Global Configurations** → **SSO Login Services** → **OIDC**.
- 
-
-2. Below the URL field, take the help of the **Click to use** option to populate the exact URL if the displayed one is incorrect.
-
- 
-
-3. In the **Configuration** editor, do the following:
+2. In the **Configuration** editor, do the following:
* In the `issuer` field, paste the URL you got while [retrieving issuer URL](#retrieving-issuer-url).
* In the `clientID` field, paste the ID you entered while [creating the client](#creating-a-client).
* In the `clientSecret` field, paste the secret you got under [client credentials tab](#getting-client-secret).
* In the `redirectURI` field, make sure to enter the same redirect URI you gave in step 4 of [client creation](#creating-a-client).
- 
+ 
+
Figure 12: Sample Keycloak SSO Config
-4. Click **Save** or **Update** to activate Keycloak SSO login.
+3. Click **Save** or **Update** to activate Keycloak SSO login.
### Adding Users
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to add users.
-{% endhint %}
+:::
Here, we will add the user we created in the Keycloak Admin Console. If this step is skipped, the user might not be able to log in to Devtron via Keycloak.
@@ -129,11 +149,13 @@ Here, we will add the user we created in the Keycloak Admin Console. If this ste
2. Click **+ Add Users**.
- 
+ 
+
Figure 13: Adding Users to Devtron
3. In the **Email addresses** field, enter the email address of the user you created in Keycloak.
- 
+ 
+
Figure 14: Entering User Data and Permissions
4. Assign necessary permissions to this new user. Refer [user permissions](../user-access.md) to know more.
@@ -141,12 +163,13 @@ Here, we will add the user we created in the Keycloak Admin Console. If this ste
Now, you may log out and test the Keycloak OIDC login method using the [user credentials](#creating-users). Clicking the **Login with Oidc** button will land you on Keycloak's login page.
-
+
+
-{% hint style="warning" %}
-### Note
+:::caution Note
Kindly get in touch with us if you encounter any issues while logging out of Keycloak on Devtron as it might be buggy.
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/user-guide/global-configurations/authorization/sso/ldap.md b/docs/user-guide/global-configurations/authorization/sso/ldap.md
old mode 100644
new mode 100755
index b123711585..502a74cb28
--- a/docs/user-guide/global-configurations/authorization/sso/ldap.md
+++ b/docs/user-guide/global-configurations/authorization/sso/ldap.md
@@ -3,16 +3,31 @@
## Sample Configuration
+
Figure 1: LDAP Configurations
---
+
+
## Values to fetch from LDAP
Devtron provides a sample configuration out of the box. Here are some values you need to fetch from your LDAP.
-* bindDN
-* bindPW
-* baseDN
+| Field | Explanation | Example |
+| ------------------------------------ | ----------- | --------------------------------------------- |
+| `host` | LDAP server hostname with port | `ad.example.com:636` | |
+| `bindDN` | DN of the LDAP service account used by Devtron to query users and groups. This is not the user logging in. | `cn=Administrator,cn=users,dc=example,dc=com` |
+| `bindPW` | Password of the bindDN account | `admin0!` |
+| `userSearch.baseDN` | Directory path under which Devtron searches for LDAP users | `cn=Users,dc=example,dc=com` |
+| `userSearch.username` | LDAP attribute used as the login username | `userPrincipalName` |
+
+:::tip Common error: "Some required field are missing"
+
+If you see this error while saving the LDAP configuration, ensure that you have set the **URL** field above the configuration editor.
+
+Click the **Click to use** link shown below the URL field to auto-populate the correct Devtron URL, or manually enter it before saving.
+:::
+
---
@@ -22,29 +37,21 @@ Devtron provides a sample configuration out of the box. Here are some values you
---
-## Auto-assign Permissions [](https://devtron.ai/pricing)
+## Auto-assign Permissions
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 [Permission Groups](../permission-groups.md) during single sign-on (SSO) login.
-
+
+
Figure 2: Enabling Permission Auto-assignment
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 [individual permissions for users](../user-access.md) mapped to a permission group.
-{% hint style="warning" %}
+:::caution
SSO login requires exact matching between Devtron permission group names and LDAP user groups. Any discrepancies or missing groups will prevent successful login.
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 [Permission Groups](../permission-groups.md) linked to LDAP user groups.
-{% endhint %}
+:::
-{% hint style="info" %}
+:::info
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.
-{% endhint %}
-
-
-
-
-
-
-
-
-
+:::
\ No newline at end of file
diff --git a/docs/user-guide/global-configurations/authorization/sso/microsoft.md b/docs/user-guide/global-configurations/authorization/sso/microsoft.md
old mode 100644
new mode 100755
index b18ce5977d..9bbc6ad5dc
--- a/docs/user-guide/global-configurations/authorization/sso/microsoft.md
+++ b/docs/user-guide/global-configurations/authorization/sso/microsoft.md
@@ -3,6 +3,7 @@
## Sample Configuration
+
Figure 1: Sample Configurations
---
@@ -16,19 +17,23 @@ Devtron provides a sample configuration out of the box. There are some values th
* tenantID (required only if you want to use Azure AD for auto-assigning permissions)
- 
+ 
+
### Values to Provide
* redirectURI (provided in SSO Login Services by Devtron)
- 
+ 
+
---
@@ -40,31 +45,26 @@ Devtron provides a sample configuration out of the box. There are some values th
---
-## Auto-assign Permissions [](https://devtron.ai/pricing)
+## Auto-assign Permissions
-{% hint style="info" %}
+:::info
Make sure to add tenantID in the SSO configuration field without fail.
-{% endhint %}
+:::
Since Microsoft supports Active Directory (AD)
, 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 [Permission Groups](../permission-groups.md) during single sign-on (SSO) login.
-
+
+
Figure 6: Enabling Permission Auto-assignment
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 [individual permissions for users](../user-access.md) mapped to a permission group.
-{% hint style="warning" %}
+:::caution
SSO login requires exact matching between Devtron permission group names and AD groups. Any discrepancies or missing groups will prevent successful login.
Once you save the configuration with this feature enabled, existing user permissions will be cleared and the future permissions will be managed through [permission groups](../permission-groups.md) linked to Azure Active Directory (Microsoft Entra ID) groups.
-{% endhint %}
+:::
-{% hint style="info" %}
+:::info
If your AD permissions aren't reflecting in Devtron, a quick sign-out and sign-in can resolve the issue.
-{% endhint %}
-
-
-
-
-
-
+:::
\ No newline at end of file
diff --git a/docs/user-guide/global-configurations/authorization/sso/oidc.md b/docs/user-guide/global-configurations/authorization/sso/oidc.md
old mode 100644
new mode 100755
index 68c4cec1d4..571ca04f7c
--- a/docs/user-guide/global-configurations/authorization/sso/oidc.md
+++ b/docs/user-guide/global-configurations/authorization/sso/oidc.md
@@ -3,6 +3,7 @@
## Sample Configuration
+
Figure 1: Sample Configuration
---
@@ -16,15 +17,18 @@ Devtron provides a sample configuration out of the box. There are some values th
* clientSecret
- 
+ 
+
Figure 2: Fetching Client ID and Secret
### Values to Provide
* redirectURI (provided in SSO Login Services by Devtron)
- 
+ 
+
---
@@ -36,16 +40,4 @@ Devtron provides a sample configuration out of the box. There are some values th
* [Configure Okta SSO](../sso/okta.md)
-* [View Dex IdP Documentation](https://dexidp.io/docs/connectors/oidc/)
-
-
-
-
-
-
-
-
-
-
-
-
+* [View Dex IdP Documentation](https://dexidp.io/docs/connectors/oidc/)
\ No newline at end of file
diff --git a/docs/user-guide/global-configurations/authorization/sso/okta.md b/docs/user-guide/global-configurations/authorization/sso/okta.md
old mode 100644
new mode 100755
index dd063a8484..340a2e41e4
--- a/docs/user-guide/global-configurations/authorization/sso/okta.md
+++ b/docs/user-guide/global-configurations/authorization/sso/okta.md
@@ -6,14 +6,13 @@ A verified account on [Okta](https://www.okta.com/). Okta activates your account
Here's a reference guide to set up your Okta org and application: [Link](https://developer.okta.com/docs/guides/oie-embedded-common-org-setup/go/main/)
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Only super admin users can set up SSO providers.
-{% endhint %}
+:::
## Tutorial
-{% embed url="https://www.youtube.com/watch?v=i-7IWkg6Ipk" caption="Okta App Setup" %}
+
## Steps on Okta Admin Console
@@ -31,7 +30,7 @@ Once your Okta org is set up, create an app integration on Okta to get a Client
* 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).
+ * 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**.
@@ -57,15 +56,14 @@ Once your Okta org is set up, create an app integration on Okta to get a Client
### Sample Configuration
-
+
+
Figure 1: Sample Configuration
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.
-## Auto-assign Permissions [](https://devtron.ai/pricing)
-
-{% hint style="warning" %}
-### Prerequisites
+## Auto-assign Permissions
+:::caution Prerequisites
In order to auto-assign feature to work
1. A groups claim is configured in the authorization server, so that group information is included in the token. Refer to [Add a groups claim in Okta](https://developer.okta.com/docs/guides/customize-tokens-groups-claim/main/#add-a-groups-claim-for-the-org-authorization-server) to learn more.
@@ -74,7 +72,7 @@ In order to auto-assign feature to work
3. Relevant users are added to these groups. Refer [Add Users to Okta groups](https://support.okta.com/help/s/article/adding-users-to-okta-groups?language=en_US) to learn more.
-{% endhint %}
+:::
Since Okta provides centralized user management through its Universal Directory, this feature further simplifies the onboarding process of organizations with a large number of users. It also eliminates repetitive permission assignment by automatically mapping your Okta groups to Devtron’s Permission Groups during single sign-on (SSO) login.
@@ -90,16 +88,15 @@ If you’ve defined groups in your Okta Universal Directory, you can create corr
4. Click **Update**.
-
+
+
Figure 2: Sample Configuration for Auto -assign Permission
-{% hint style="warning" %}
-### Note
+:::caution Note
SSO login requires exact matching between Devtron permission group names and Okta groups. Any discrepancies or missing groups will prevent successful login.
Once you save the configuration with this feature enabled, existing user permissions will be cleared and the future permissions will be managed through [permission groups](../permission-groups.md) linked to Okta groups.
-{% endhint %}
+:::
-{% hint style="info" %}
-### Tip
+:::info Tip
If your Okta groups permissions aren't reflecting in Devtron, a quick sign-out and sign-in can resolve the issue.
-{% endhint %}
+:::
diff --git a/docs/user-guide/global-configurations/authorization/sso/openshift.md b/docs/user-guide/global-configurations/authorization/sso/openshift.md
old mode 100644
new mode 100755
index 00a598c77e..2cdafe75e5
--- a/docs/user-guide/global-configurations/authorization/sso/openshift.md
+++ b/docs/user-guide/global-configurations/authorization/sso/openshift.md
@@ -3,6 +3,7 @@
## Sample Configuration
+
Figure 1: Sample Configuration
---
@@ -14,19 +15,23 @@ Devtron provides a sample configuration out of the box. There are some values th
* clientID
- 
+ 
+
### Values to Provide
* redirectURI (already provided in SSO Login Services by Devtron)
- 
+ 
+
---
@@ -34,11 +39,4 @@ Devtron provides a sample configuration out of the box. There are some values th
* [View Openshift Documentation](https://docs.openshift.com/container-platform/4.14/authentication/configuring-oauth-clients.html)
-* [View Dex IdP Documentation](https://dexidp.io/docs/connectors/openshift/)
-
-
-
-
-
-
-
+* [View Dex IdP Documentation](https://dexidp.io/docs/connectors/openshift/)
\ No newline at end of file
diff --git a/docs/user-guide/global-configurations/authorization/user-access.md b/docs/user-guide/global-configurations/authorization/user-access.md
old mode 100644
new mode 100755
index db11b239b4..259326e3c6
--- a/docs/user-guide/global-configurations/authorization/user-access.md
+++ b/docs/user-guide/global-configurations/authorization/user-access.md
@@ -4,43 +4,47 @@
Here you can manage who can access your Devtron instance and what actions they can perform. Use this section to add team members, assign them roles, and control their access by granting fine-grained permissions. Moreover, you can also download all user data in a CSV format.
-
+
+
Figure 1: User Permissions - Example
---
## Add Users
-{% hint style="danger" %}
-### Mandatory Action
+:::danger Mandatory Action
This is a mandatory step after configuring SSO in Devtron; otherwise, your users won't be able to log in to Devtron via SSO.
-{% endhint %}
+:::
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Only managers and super-admins can add users.
-{% endhint %}
+:::
1. Go to **Global Configurations** → **Authorization** → **User Permissions**.
- 
+ 
+
Figure 2: User Permissions in Global Configurations
3. In the **Email addresses** field, type the email address of the user you wish to add. You may add more than one email address.
- 
+ 
+
Figure 4: Adding Email Addresses of Users
4. (Optional) From the **Assign user groups** dropdown, you may assign one or more user groups to the user. This helps in identifying the group/team to which the user belongs (e.g., Security Team, Frontend Team, Department Leads) especially when adding larger teams.
- 
+ 
+
Figure 5: Assigning User Group(s)
5. There are two types of permissions in Devtron (click the links below to learn more):
* [Super admin permission](#grant-super-admin-permission) for granting full access.
* [Specific permissions](#grant-specific-permissions) for granting cherry-picked access.
- 
+ 
+
Figure 6: Granting Specific or Superadmin Access
6. Click **Save**. You have successfully added your user(s).
@@ -48,7 +52,8 @@ Only managers and super-admins can add users.
## Grant Super Admin Permission
-
+
+
Figure 7: Granting Superadmin Access
Super-Admins have unrestricted access to all Devtron resources. They can create, modify, delete, and manage any resource, including user access, Git repositories, container registries, clusters, and environments. Before assigning this permission, please note:
@@ -62,7 +67,8 @@ Super-Admins have unrestricted access to all Devtron resources. They can create,
## Grant Specific Permissions
-
+
+
Figure 8: Granting Specific Access
### Permission Groups
@@ -70,16 +76,14 @@ Super-Admins have unrestricted access to all Devtron resources. They can create,
The **Permission Groups** drop-down box allows you to select from a list of permission groups already created in the [Permission Groups](../authorization/permission-groups.md) page.
-
+
+
Figure 9: Permission Groups
You can select one or more permission groups, and the user will automatically inherit all the permissions to the projects and resources defined for those groups. Once you select permission group(s), assigning direct permissions can be skipped (unless you wish to grant additional permissions).
-You can also make users [Active/Inactive](#making-users-activeinactive) at permission group-level.
-
-{% hint style="info" %}
-
-### What happens when a user has direct permissions as well as permissions inherited from a group?
+You can also make users [Active/Inactive](#making-users-activeinactive-) at permission group-level.
+:::info What happens when a user has direct permissions as well as permissions inherited from a group?
If you assign a permission group as well as direct permissions, the user will have the combined permissions of both.
**For example**:
@@ -90,29 +94,27 @@ If you assign a permission group as well as direct permissions, the user will ha
* Now, the user will have both **Build & Deploy** and **View only** permissions for those three apps, and just **View only** for the other two.
-{% endhint %}
+:::
### Devtron Apps permissions
-{% hint style="warning" %}
-
-### Note
-
+:::caution Note
The **Devtron Apps** tab is displayed only when the [Build and Deploy (CI/CD)](../../integrations/build-and-deploy-ci-cd.md) module is installed in your Devtron instance.
-{% endhint %}
+:::
The **Devtron Apps** tab allows you to grant user permissions for Devtron applications.
-
+
+
Figure 10: Granting Devtron Apps Permissions
| Field | Description |
| --- | --- |
-| **Project** | Select your preferred project from the drop-down box to grant the user access. You can select only one project at a time. **Note**: If you want to select more than one project, then click **Add Permission**. |
-| **Environment** | Select a specific environment or all environments from the drop-down box as per your requirement. **Note**: If you select `All environments`, the user will have access to all the current environments and any new environment which gets associated with the application in the future. |
-| **Application** | Select a specific application or all applications from the drop-down box that is associated with the environment(s) selected in the **Environment** drop-down box, as per your requirement. **Note**: If you select `All applications`, the user will have access to all the current and future applications associated with the project. Moreover, user with access to all applications, can create new applications too. |
-| **Role** | Available Roles:
[Click here](#roles-available-for-devtron-apps) to learn more about the role you wish to assign to the user. |
-| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) [](https://devtron.ai/pricing) |
+| **Project** | Select your preferred project from the drop-down box to grant the user access. You can select only one project at a time. **Note**: If you want to select more than one project, then click **Add Permission**. |
+| **Environment** | Select a specific environment or all environments from the drop-down box as per your requirement. **Note**: If you select `All environments`, the user will have access to all the current environments and any new environment which gets associated with the application in the future. |
+| **Application** | Select a specific application or all applications from the drop-down box that is associated with the environment(s) selected in the **Environment** drop-down box, as per your requirement. **Note**: If you select `All applications`, the user will have access to all the current and future applications associated with the project. Moreover, user with access to all applications, can create new applications too. |
+| **Role** | Available Roles:
`Base Role`
`Additional Roles`
`Access Manager`
[Click here](#roles-available-for-devtron-apps) to learn more about the role you wish to assign to the user. |
+| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) |
#### Roles available for Devtron Apps
@@ -128,7 +130,7 @@ The role-based access for Devtron Apps are as follows:
* **Manager**: In addition to **Admin** permission, users can also grant or revoke user access for applications and environments that they manage. The **Manager** role for enterprise users will be deprecated and removed soon. Therefore, we recommend using the **Access Manager** role instead of **Manager** going forward.
-* **Additional Roles** [](https://devtron.ai/pricing)
+* **Additional Roles**
**Additional Roles** allows you to assign specific permissions to a user beyond their **Base Role**. For example, you can grant a user both the **Build and Deploy** (Base Role) and **Config Approver** permissions (Additional Role). This allows the user to build and deploy images, while also being responsible for approving configuration change requests.
@@ -140,7 +142,7 @@ The role-based access for Devtron Apps are as follows:
* **Deployment Approver**: You can approve the deployment requests for the selected applications and environments.
-You also have the provision of granting Access Manager role to a user. Refer [Access Manager](#access-manager) to know more.
+You also have the provision of granting Access Manager role to a user. Refer [Access Manager](#access-manager-) to know more.
#### Roles and Scopes
@@ -160,15 +162,16 @@ You also have the provision of granting Access Manager role to a user. Refer [Ac
Here you can grant your user the permissions for Helm apps deployed from Devtron or outside Devtron.
-
+
+
Figure 11: Granting Helm Apps Permissions
| Field | Description |
| --- | --- |
-| **Project** | Select a project from the dropdown list to grant the user access. You can select only one project at a time. **Note**: If you want to select more than one project, then click **Add Permission**. |
-| **Environment or Cluster/Namespace** | Select a specific environment from the dropdown list. **Note**: If you select `All existing + future environments in cluster`, then the user will get access to all the current environments including any new environment which gets associated with the application later. |
-| **Application** | Select a specific helm application or all helm apps from the dropdown list corresponding to your selected environments. **Note**: If `All applications` is selected, the user will have access to all current and future applications associated with the project. |
+| **Project** | Select a project from the dropdown list to grant the user access. You can select only one project at a time. **Note**: If you want to select more than one project, then click **Add Permission**. |
+| **Environment or Cluster/Namespace** | Select a specific environment from the dropdown list. **Note**: If you select `All existing + future environments in cluster`, then the user will get access to all the current environments including any new environment which gets associated with the application later. |
+| **Application** | Select a specific helm application or all helm apps from the dropdown list corresponding to your selected environments. **Note**: If `All applications` is selected, the user will have access to all current and future applications associated with the project. |
| **Permission** | Available Permissions:
`View only`
`View & Edit`
`Admin`
[Click here](#roles-available-for-helm-apps) to learn more about the permission you wish to assign the user. |
-| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) [](https://devtron.ai/pricing) |
+| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) |
#### Roles available for Helm Apps
@@ -189,16 +192,17 @@ There are three role-based access levels for Helm Apps:
Here you can grant your user the permissions to access the jobs created in Devtron.
-
+
+
Figure 12: Granting Jobs Permissions
| Field | Description |
| --- | --- |
-| **Project** | Select a project from the dropdown list to grant the user access. You can select only one project at a time. **Note**: If you want to select more than one project, then click **Add Permission**. |
+| **Project** | Select a project from the dropdown list to grant the user access. You can select only one project at a time. **Note**: If you want to select more than one project, then click **Add Permission**. |
| **Job Name** | Select a specific job or choose `All jobs` to grant access to all available jobs within the project. |
| **Workflow** | Select a specific workflow or `All workflows` to grant access to the workflows containing the job pipelines. |
| **Environment** | Select a specific environment or `All environments` to grant access to the environments associated with the job(s). |
| **Role** | Available Roles:
`View only`
`Run job`
`Admin`
[Click here](#roles-available-for-jobs) to learn more about the role you wish to assign the user.|
-| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) [](https://devtron.ai/pricing) |
+| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) |
#### Roles available for Jobs
@@ -219,29 +223,30 @@ There are three role-based access levels for Jobs:
### Kubernetes Resources permissions
-{% hint style="warning" %}
-### Note
+:::caution Note
The 'Kubernetes Resources' tab will be available only if you have super-admin permissions.
-{% endhint %}
+:::
Here you can provide permission to view, inspect, manage, and delete resources in your clusters from [Devtron's Resource Browser](../../resource-browser/README.md).
To grant Kubernetes resource permission, click **Add permission**.
-
+
+
Figure 13a: Adding Permissions for Kubernetes Resources
-
+
+
Figure 13b: Granting Permissions for Kubernetes Resources
| Field | Description |
| --- | --- |
-| **Cluster** | Select a cluster from the dropdown list to which you want to give permission to the user. You can select only one cluster at a time. **Note**: To add another cluster, click **Add another**. |
+| **Cluster** | Select a cluster from the dropdown list to which you want to give permission to the user. You can select only one cluster at a time. **Note**: To add another cluster, click **Add another**. |
| **Namespace** | Select a namespace from the dropdown list. |
| **API Group** | Select a specific API group or `All API groups` from the dropdown list corresponding to the Kubernetes resource. |
| **Kind** | Select a kind or `All kind` from the dropdown list corresponding to the Kubernetes resource. |
| **Resource name** | Select a resource name or `All resources` from the dropdown list to which you want to give permission to the user. |
| **Role** | Available Roles:
`View`
`Admin`
[Click here](#roles-available-for-kubernetes-resources) to learn more about the role you wish to assign the user. |
-| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) [](https://devtron.ai/pricing) |
+| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) |
#### Roles available for Kubernetes Resources
@@ -258,14 +263,14 @@ There are two role-based access levels for Kubernetes Resources:
### Chart Groups permissions
-{% hint style="warning" %}
-### Note
+:::caution Note
The 'Chart Groups' tab will be available only if the [CI/CD module](../../integrations/build-and-deploy-ci-cd.md) is installed.
-{% endhint %}
+:::
Here you can grant your user the permissions for accessing Chart Groups. Note that you can only give users the permission to either create chart groups or edit them, but not both.
-
+
+
Figure 14: Granting Chart Group Permissions
| Action | Permissions |
| :--- | :--- |
@@ -288,53 +293,43 @@ Here you can grant your user the permissions for accessing Chart Groups. Note th
---
-## Access Manager [](https://devtron.ai/pricing)
+## Access Manager
### Can Manage Access For All Roles (Toggle)
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
+:::caution Who Can Perform This Action?
Only a [Super Admin](#grant-super-admin-permission) can enable the **Can manage access for all roles** toggle for other users.
-{% endhint %}
+:::
-
+
+
Figure 15: 'Can manage access for all roles' Toggle
By enabling the **Can manage access for all roles** toggle, you can grant a user the permission to manage access for all roles across Devtron apps, Helm Apps, Jobs, Kubernetes Resources, and Chart Groups. However, they cannot create new users.
By default, this toggle is disabled.
-{% hint style="warning" %}
-
-### Important Note
-
+:::caution Important Note
If you enable the **Can manage access for all roles** toggle for a user, then that user can modify permissions of all the users including super-admins.
-{% endhint %}
+:::
### Access Manager (Devtron Apps)
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
+:::caution Who Can Perform This Action?
Only [Super-Admins](#grant-super-admin-permission) can grant an **Access Manager** role.
-{% endhint %}
+:::
-
+
+
Figure 16: Access Manager
Enabling **Access Manager** for a user allows that user to further grant or change permissions of existing users.
-{% hint style="warning" %}
-
-### Important Note
-
+:::caution Important Note
An Access Manager cannot create other Access Managers or add new users. Creation of new users and Access Manager is restricted only to Super-Admins.
-{% endhint %}
+:::
A user who is an Access Manager can grant or change permissions for other existing users only within the permissions assigned to them under the **Access Manager** role in the **Role** drop-down box. For example, refer to the tables below to understand what an Access Manager (User A) is allowed and not allowed to do with the permissions of an existing user (User B).
@@ -345,16 +340,13 @@ A user who is an Access Manager can grant or change permissions for other existi
| What's Allowed | What's Not Allowed |
|:----|:------|
-| **For User A:** Changing User B's **Manager** role to **View Only** role (Manager → View Only) |
Reverting to User B's **Manager** role (View Only → Manager)
Changing User B's **Manager** role to any other role, except for **View Only**
Performing operations beyond the base role (i.e., **Admin**)
Modifying Super-Admin permissions
|
-| **For User B:** Perform the operations under the scope of **Manager** role across Devtron |
Manage user access for other users
Perform operations beyond the base role (i.e., **Manager**)
Modifying Super-Admin permissions
|
-
-{% hint style="info" %}
-
-### Note
+| **For User A:** Changing User B's **Manager** role to **View Only** role (Manager → View Only) |
Reverting to User B's **Manager** role (View Only → Manager)
Changing User B's **Manager** role to any other role, except for **View Only**
Performing operations beyond the base role (i.e., **Admin**)
Modifying Super-Admin permissions
|
+| **For User B:** Perform the operations under the scope of **Manager** role across Devtron |
Manage user access for other users
Perform operations beyond the base role (i.e., **Manager**)
Modifying Super-Admin permissions
|
+:::info Note
If you need to grant someone global control over modifying the roles of other users, enable the [Can manage access for all roles](#can-manage-access-for-all-roles-toggle) toggle instead.
-{% endhint %}
+:::
When enabling the **Access Manager** toggle, make sure to select at least one permission from the checkboxes displayed beneath the toggle to ensure the role is active.
@@ -376,31 +368,28 @@ The following permissions are currently available in the Access Manager role:
|-----------------------|:----:|:------:|:----:|:------:|:--------------:|:--------------:|:--------------:|:----------------:|:----------------:|
| **Access Manager** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
-{% hint style="info" %}
-
-### Note
-
+:::info Note
[Raise a feature request on GitHub](https://github.com/devtron-labs/devtron/issues) if:
* You would like to see the **Deployment approver** permission also within the **Access Manager** role.
* You would like to have the app-specific **Access Manager** role (currently available only for Devtron Apps) for Helm apps, Jobs, Kubernetes Resources, or Chart Groups as well.
-{% endhint %}
+:::
---
-## Making Users Active/Inactive [](https://devtron.ai/pricing)
+## Making Users Active/Inactive
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
* Super-admins can activate or deactivate users.
* Managers can activate or deactivate users only if the users has the same or fewer permissions than the manager.
-{% endhint %}
+:::
When working with multiple collaborators in Devtron, you may need to deactivate users who no longer require access and reactivate them when needed. This applies to users of Devtron Apps, Helm Apps, Jobs, and Kubernetes Resources.
-
+
+
Figure 17: Active/Inactive Options
You can manage a user's active status at three levels:
* [User-level](#at-user-level)
@@ -410,7 +399,8 @@ You can manage a user's active status at three levels:
### At User level
-
+
+
Figure 18: Active/Inactive User
* **Active/Activate** - Use this option to activate a deactivated user while retaining their previous roles and permissions.
* **Inactive/Inactivate** - Use this option to deactivate an existing active user and save the changes. If the user has an ongoing session, they will be logged out permanently on their next action or refresh.
@@ -418,7 +408,8 @@ You can manage a user's active status at three levels:
### At Permission Group level
-
+
+
Figure 19: Active/Inactive User from Permission Group
* **Active/Activate** - Use this option to allow permissions from the group to take effect for the user.
* **Inactive/Inactivate** - Use this option to prevent permissions from the group from taking effect for the user. However, they can still log in/log out of Devtron if [active at the user-level](#at-user-level).
@@ -426,7 +417,8 @@ You can manage a user's active status at three levels:
### At Direct Permissions level
-
+
+
Figure 20: Active/Inactive User for Project Access
* **Active/Activate** - Use this option to grant the project/resource access to the user.
* **Inactive/Inactivate** - Use this option to revoke the project/resource access from the user. **Note**: The user will still be able to log in/log out of Devtron if [active at user-level](#at-user-level).
@@ -436,20 +428,19 @@ You can manage a user's active status at three levels:
## Edit User Permissions
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
* Super-admins can edit user permissions.
* Managers can edit user permissions only if the user has the same or fewer permissions than the manager.
-{% endhint %}
+:::
-{% hint style="warning" %}
-### Note
+:::caution Note
Direct user permissions cannot be edited if you're using [LDAP](./sso/ldap.md)/[Microsoft](./sso/microsoft.md) for SSO with 'auto-assign permission' enabled. Permissions can only be [managed via permission groups](./permission-groups.md#edit-permissions-groups) in such a scenario.
-{% endhint %}
+:::
You can edit the user permissions by clicking the edit icon. Click **Save** after editing the permissions.
-
+
+
Figure 21: Editing User Permissions
---
@@ -464,20 +455,21 @@ You may download the user data of current users and deleted users in a CSV forma
* Role
* Timestamps for User Addition, Updation, and Deletion
-
+
+
Figure 22: Exporting User Data
---
## Delete Users
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
* Super-admins can delete users.
* Managers can delete users only if the user has the same or fewer permissions than the manager.
-{% endhint %}
+:::
If you want to delete a user, click **Delete**.
-
+
+
Figure 23: Deleting a User
This will remove the user from the system along with all the permissions granted earlier. The user will no longer be able to log in to Devtron unless added again.
\ No newline at end of file
diff --git a/docs/user-guide/global-configurations/build-infra.md b/docs/user-guide/global-configurations/build-infra.md
old mode 100644
new mode 100755
index 3ca52b2e32..e5e7e8e45f
--- a/docs/user-guide/global-configurations/build-infra.md
+++ b/docs/user-guide/global-configurations/build-infra.md
@@ -1,3 +1,10 @@
+---
+id: build-infra
+title: Build Infra
+sidebar_label: Build Infra
+slug: /user-guide/app-management/configurations/build-infra
+---
+
# Build Infra
## Introduction
@@ -8,26 +15,27 @@ Therefore, applying a common infra configuration to all applications is not opti
With the 'Build Infra' feature, Devtron makes it possible for you to tweak the resources as per the needs of your applications. The build (ci-runner) pod will be scheduled on an available node (considering applied taints and tolerations) in the cluster on which 'Devtron' is installed.
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to configure Build Infra.
-{% endhint %}
+:::
---
## Configure Build Infra
-From the left sidebar, go to **Global Configurations** → **Build Infra**.
+From the left sidebar, go to **Application Management** → **Configurations** → **Build Infra**.
-
+
+
Figure 1: Global Configurations - Build Infra
-Under **Profiles** tab, you will see the [Global Profile](#global-profile) and a list of [Custom Profiles](#creating-custom-profile) (if they exist). Setting up profiles makes it easier for you to manage the build infra configurations, ensuring its reusability in the long term.
+Under **Profiles** tab, you will see the [Global Profile](#global-profile) and a list of [Custom Profiles](#creating-custom-profile-) (if they exist). Setting up profiles makes it easier for you to manage the build infra configurations, ensuring its reusability in the long term.
### Global Profile
This contains the default infra configuration applicable to all the applications, be it large or small.
-
+
+
Figure 2: Global Profile
You may click it to modify the following:
@@ -36,17 +44,17 @@ You may click it to modify the following:
|**CPU**|Processor core allocated to the build process. See [CPU units](#cpu-units).|
|**Memory**|RAM allocated to the build process. See [memory units](#memory-units).|
|**Build Timeout**|Max. time limit allocated to the build process. See [timeout units](#timeout-units).|
-|**Node Selector** |Node Selector are key-value pair labels to match Pods with Nodes. To learn more, refer to [nodeSelector](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) page.|
-|**Toleration** |A Toleration allow a pod to be scheduled on a Node that has a matching Taint. To learn more, refer to [Taints and Toleration](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) page.|
-|**ConfigMaps** |Key Value pairs to store non-sensitive configurations. Refer to [ConfigMaps](../creating-application/base-config/config-maps.md).|
-|**Secrets** |Key Value pairs to store sensitive configurations. Refer to [Secrets](../creating-application/base-config/secrets.md).|
+|**Node Selector** |Node Selector are key-value pair labels to match Pods with Nodes. To learn more, refer to [nodeSelector](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) page.|
+|**Toleration** |A Toleration allow a pod to be scheduled on a Node that has a matching Taint. To learn more, refer to [Taints and Toleration](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) page.|
+|**ConfigMaps** |Key Value pairs to store non-sensitive configurations. Refer to [ConfigMaps](../creating-application/base-config/config-maps.md).|
+|**Secrets** |Key Value pairs to store sensitive configurations. Refer to [Secrets](../creating-application/base-config/secrets.md).|
-{% hint style="info" %}
-### Note
+:::info Note
ConfigMaps and Secrets defined here will be used at the time of build, not during deployment.
-{% endhint %}
+:::
-
+
+
Figure 3: Editing Global Profile
Furthermore, CPU and Memory have 2 fields each:
@@ -56,29 +64,34 @@ Furthermore, CPU and Memory have 2 fields each:
| **Limit** | This field is use to set the maximum amount of CPU/Memory resources the build process can use, even if there is a lot available in the cluster.|
-### Creating Custom Profile [](https://devtron.ai/pricing)
+### Creating Custom Profile
Instead of global profile, you can create custom profiles having different infra configurations. Example: One profile for Python apps, a second profile for large apps, and a third profile for small apps, and many more.
1. Click **Create Profile**.
- 
+ 
+
Figure 4: Creating Custom Profile
2. Enter a name for the profile along with a brief description (optional) and click **Create** button.
- 
+ 
+
Figure 5: Entering Details
3. Your custom profile will appear under the list of custom profiles as shown below.
- 
+ 
+
Figure 6: Profile Created
4. Click on your custom profile; a new page will open displaying the custom runner configuration which is inherited from global profile by default.
- 
+ 
+
Figure 7: Editing Profile
5. To modify a specific configuration, click the **edit** icon next to that configuration, and turn off the **Inherit** toggle; this will stop that configuration from being inherited from global profile.
- 
+ 
+
Figure 8: Configuring Profile
6. Modify the resources according to your use case and click **Save**.
@@ -86,11 +99,11 @@ Instead of global profile, you can create custom profiles having different infra
---
-## Adding Platform Specific Configurations [](https://devtron.ai/pricing)
+## Adding Platform Specific Configurations
-Modern applications often need to run on different hardware platforms (architectures), such as `amd64` (x86_64) and `arm64` to support cross-platform compatibility.
+Modern applications often need to run on different hardware platforms (architectures), such as `amd64` (x86_64) and `arm64`, to support cross-platform compatibility.
-[Multi-architecture (multi-arch) builds](https://docs.docker.com/build/building/multi-platform/) enables you to build container images that work seamlessly across multiple platforms.
+[Multi-architecture (multi-arch) builds](https://docs.docker.com/build/building/multi-platform/) enable you to build container images that work seamlessly across multiple platforms.
Optimizing your CI builds for each platform ensures:
@@ -98,36 +111,59 @@ Optimizing your CI builds for each platform ensures:
* **Resource efficiency**: Prevents over or under-provisioning, saving costs and improving reliability.
-Each platform may have unique requirements for resources like CPU and memory, or they may benefit from different configuration of resources. Thus, Devtron allows defining platform specific configurations within a build infra profile. This ensures each build is executed with the right configurations specific to the target platform.
+Each platform may have unique requirements for resources like CPU and memory, or it may benefit from a different configuration of resources. Thus, Devtron allows defining platform specific configurations within a build infra profile. This ensures each build is executed with the right configurations specific to the target platform.
+
+### How the Configurations Are Applied
+
+A build infra profile has two levels of configuration:
+
+* **Runner configuration**: The base CPU, memory, and build timeout for the build (ci-runner) pod. This applies to every build using the profile.
+
+* **Platform specific configuration**: An optional set of resources (CPU and memory) defined for an individual target platform such as `linux/amd64` or `linux/arm64`. When you build for that platform, Devtron uses these resources instead of the base runner configuration.
-{% hint style="info" %}
-### K8s Driver v/s Container Driver
- **Platform specific configurations** are only supported for builds executed using the k8s driver.
-
- When you use the K8s driver, each build for a target platform runs as its own pod within your Kubernetes cluster. This allows you to assign different CPU, memory, and other configurations for each target platform like `amd64` or `arm64`.
-
- If you use the container driver, all builds run inside a single CI runner pod and share the same configuration, regardless of the target platform while K8s driver.
+:::info K8s Driver v/s Container Driver
+**Platform specific configurations** are only supported for builds executed using the K8s driver.
- {% endhint %}
+When you use the **K8s driver**, each build for a target platform runs as its own pod within your Kubernetes cluster. This allows you to assign different CPU, memory, and other configurations for each target platform, such as `linux/amd64` or `linux/arm64`.
+
+When you use the **container driver**, all platform builds run inside a single CI runner pod and share the same configuration, regardless of the target platform.
+:::
To configure platform specific configurations:
-1. From the left sidebar, go to **Global Configurations** → **Build Infra**.
+1. From the left sidebar, go to **Application Management** → **Configurations** → **Build Infra**.
2. Select the profile for which you want to configure platform specific configurations.
-3. Check the **Use K8s driver for build** and click **+Add Target Platform**; a modal window will open.
+3. Enable the **Use K8s driver for build** toggle, then click **+ Add Target Platform**; a modal window will open.
+
+ 
+
Enabling K8s Driver and Adding a Target Platform
-4. Under **Select a target platform**, select the platform for which you want to define platform specific configurations.
+4. Under **Select a target platform**, choose the platform for which you want to define platform specific configurations.
1. You can choose from `linux/amd64` or `linux/arm64`.
- 2. You can also type to add a new platform.
+ 2. You can also type to add a custom platform.
+
+ 
+
Selecting a Target Platform
5. Configure the resources for the specific platform and click **Save**.
-6. The platform specific configuration will be available below the runner configuration.
+ :::caution
+ For both CPU and Memory, the **Limit** must be greater than or equal to the **Request**. See [CPU units](#cpu-units) and [memory units](#memory-units).
+ :::
+
+ 
+
Configuring Platform Specific Resources
+
+6. The platform specific configuration will be available below the runner configuration. You can add more target platforms by repeating steps 3–5, and remove a platform using its delete icon.
+
+:::info Note
+If a target platform does not have its own platform specific configuration, the build for that platform falls back to the base runner configuration.
+:::
-{% embed url="https://www.youtube.com/watch?v=5nFJfai125U" caption="Platform Specific Configurations" %}
+
---
@@ -137,27 +173,31 @@ Once you create a profile, attach it to the intended applications, or else the [
1. Go to the **Applications** tab.
- 
+ 
+
Figure 9: Applications Tab
2. Choose an application and click the dropdown below it.
- 
+ 
+
Figure 10: Profile Dropdown
3. Choose the profile you wish to apply from the dropdown.
- 
+ 
+
Figure 11: Selecting a Profile
4. Click **Change** to apply the profile to your application.
- 
+ 
+
Figure 12: Confirming Profile Change
-{% hint style="success" %}
-### Tip
+:::tip Tip
If you missed creating a profile but selected your application(s), you can use the 'Create Profile' button. This will quickly open a new tab for creating a profile. Once done, you can return and click the refresh icon as shown below.
-{% endhint %}
+:::
-
+
+
Figure 13: Quick Profile Creation
### Performing Bulk Action
@@ -165,15 +205,18 @@ If you wish to apply a profile to multiple applications at once, you can do that
Simply use the checkboxes to select the applications. You can do this even if there are many applications spanning multiple pages. You will see a draggable floating widget as shown below.
-
+
+
Figure 14: Floating Widget
Select the profile you wish to apply from the dropdown and confirm the changes.
-
+
+
Figure 15: Selecting a Profile
Once you apply a profile, it will show the count of applications attached to it.
-
+
+
Figure 16: Count of Applications
---
@@ -181,11 +224,13 @@ Once you apply a profile, it will show the count of applications attached to it.
You can edit or delete a custom profile using the respective icons as shown below.
-
+
+
Figure 17: Edit and Delete Icons
If you delete a profile attached to one or more applications, the [global profile](#global-profile) will apply from the next build.
-
+
+
Figure 18: Confirm Profile Deletion
### Need More Options?
diff --git a/docs/user-guide/global-configurations/catalog-framework.md b/docs/user-guide/global-configurations/catalog-framework.md
old mode 100644
new mode 100755
index 35a77eea82..f06f939ae2
--- a/docs/user-guide/global-configurations/catalog-framework.md
+++ b/docs/user-guide/global-configurations/catalog-framework.md
@@ -1,91 +1,107 @@
-# Catalog Framework
+# Manage Schema
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
-Ideally, all resources such as microservices, clusters, jobs, pods, etc. should contain detailed information so that its users know what each of those resources do, how to use them, as well as all their technical specs. Access to such data makes it easier for engineers to quickly discover and understand the relevant resources.
+Ideally, all resources such as microservices, clusters, jobs, and pods should include detailed information, so users know what each resource does, how to use it, and its technical specifications.
-To achieve this, Devtron supports a feature known as **Catalog Framework**. Using this, you as a [super-admin](../global-configurations/authorization/user-access.md#devtron-apps-permissions) can decide the data you expect from the managers of different resource types. In other words, you can create a custom JSON schema that would ultimately render a form for the resource owners to fill. Once the form is filled, a GUI output will appear as shown below.
+To achieve this, Devtron provides a feature called **Catalog**, which lets a [super-admin](../global-configurations/authorization/user-access.md#devtron-apps-permissions) define a custom JSON schema that renders a form for resource owners to fill. After defining a schema, it generates a form that users can fill out, and the entered data appears in a clear GUI format.
-
-
-Currently, Devtron supports catalog framework for the following resource types (a.k.a. resource kind):
+Currently, Devtron supports catalog for the following resource types (a.k.a. resource kind):
* [Devtron applications](../../reference/glossary.md#devtron-apps)
* [Helm applications](../../reference/glossary.md#helm-apps)
* [Clusters](../../reference/glossary.md#cluster)
* [Jobs](../../reference/glossary.md#job)
+
+
Figure 1: Sample Catalog Data
+
There are two parts involved in the creation of a desirable resource catalog:
-1. [Defining a Schema](#defining-a-schema)
+1. [Managing a Schema](#managing-a-schema)
2. [Filling the Schema-Generated Form](#filling-the-schema-generated-form)
---
-## Defining a Schema
+## Managing a Schema
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Only a super-admin can create/edit a schema.
-{% endhint %}
+:::
+
+:::caution Note
+The **Catalog** schema you define applies to all resources of that type. For example, managing the schema for one Devtron application updates the catalog for every Devtron app in your system.
+:::
+1. Go to the **Overview** tab of your resource (for example, a **Devtron App**, or **Helm App**, or **Job**, or **Cluster**) and locate the **Catalog** section.
-1. Go to **Global Configurations** → **Catalog Framework**.
+:::caution Note
+Here, we’re defining schema for a **Devtron application** as an example. You can define schemas for all other supported resource types (**Helm App**, or **Job**, or **Cluster**) in exactly the same way.
+:::
-2. Choose a resource type, for which you wish to define a schema, for e.g., Devtron applications.
+2. Click **Manage Schema**. A new page will open.
- 
+ 
+
Figure 2: Clicking 'Manage Schema'
-3. You can edit the schema name and description.
+3. Enter a **Name** and **Description** (optional). The **Kind** field is automatically filled with the resource type (such as **Devtron application**, **Helm application**, **cluster**, or **job**) based on where you opened **Manage Schema**.
-4. There is a sample schema available for you to create your own customized schema. Using this schema, you can decide the input types that renders within the form, for e.g., a dropdown of enum values, a boolean toggle button, text field, label, and many more.
+ 
+
Figure 3: Entering Details
- 
+4. There is a sample schema available for you to create your own customized schema. Using this schema, you can decide the input types that render within the form, for e.g., a dropdown of enum values, a boolean toggle button, text field, label, and many more.
- 
+ 
+
5. After defining your schema, click **Review Changes**.
6. You get a side-by-side comparison (diff) highlighting the changes you made.
- 
+ 
+
-Similarly, you can define schemas for other resource types.
+7. Click **Save**.
**Note**: If you edit a field (of an existing schema) for which users have already filled the data, that data will be erased. You will receive a prompt (as shown below) to confirm whether you want to proceed with the changes.
-
-
+
+
Figure 6: Indication of Existing Data
---
## Filling the Schema-Generated Form
-Once a catalog schema exists for a resource type, its corresponding form would be available in the overview section of that resource type.
+Once a schema is defined, the form generated from it appears in the **Overview** section of that resource.
-1. Since we defined a schema for Devtron applications in the above example, go to the **Overview** tab of your application (any Devtron application). Click the **Edit** button within the `About` section.
+1. Since we defined a schema for **Devtron applications** in the above example, go to the **Overview** tab of your application (any Devtron application). Click the **Edit** button within the `About` section.
- 
+ 
+
Figure 7: Clicking 'Edit'
2. The schema created for Devtron applications would render into an empty form as shown below.
- 
+ 
+
Figure 8: Rendered Empty Form
3. Fill as many details as an application owner to the best of your knowledge and click **Save**.
- 
+ 
+
Figure 9: Filled Form
4. Your saved data would be visible in a GUI format (and also in JSON format) as shown below.
- 
-
-This catalog data would be visible to all the users who have access to the application, but its data can be edited only by the resource owners (in this case, application admin/managers).
-
-
-
-
+ 
+
+This catalog data would be visible to all the users who have access to the application, but its data can be edited only by the resource owners (in this case, application admin/managers).
\ No newline at end of file
diff --git a/docs/user-guide/global-configurations/chart-repo.md b/docs/user-guide/global-configurations/chart-repo.md
old mode 100644
new mode 100755
index f80c593341..a095fbe5e6
--- a/docs/user-guide/global-configurations/chart-repo.md
+++ b/docs/user-guide/global-configurations/chart-repo.md
@@ -1,3 +1,10 @@
+---
+id: chart-repo
+title: Chart Repository
+sidebar_label: Chart Repository
+slug: /user-guide/app-management/configurations/chart-repo
+---
+
# Chart Repository
## Introduction
@@ -8,13 +15,10 @@ You can add one ore more chart repositories to Devtron. Once added, the charts f
By default, Devtron automatically includes a set of built-in chart repositories during installation.
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
+:::caution Who Can Perform This Action?
Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant-super-admin-permission) can add, update, delete chart repositories.
-{% endhint %}
+:::
---
@@ -22,7 +26,10 @@ Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant
To add a chart repository, follow the steps below:
-1. Navigate to **Global Configurations** → **Chart Repositories**.
+1. Navigate to **Application Management** → **Configurations** → **Chart Repository**.
+
+ 
+
Figure 1: Adding a Chart Repository
2. Click **Add repository**.
@@ -30,7 +37,8 @@ To add a chart repository, follow the steps below:
3. Provide below information in the following fields:
- 
+ 
+
Figure 2: Entering Repository Details
| Fields | Description |
| --- | --- |
@@ -45,21 +53,19 @@ To add a chart repository, follow the steps below:
To update a chart repository, follow the below steps:
-1. Navigate back to **Chart Repositories* page.
+1. Navigate back to **Chart Repositories** page.
2. Select the repository you prefer to update.
- 
+ 
+
Figure 3: Updating a Chart Repository
3. Modify the repository as per your requirements.
-{% hint style="info" %}
-
-### Perform Dry Run
-
+:::info Perform Dry Run
If you prefer to perform a dry run to validate the chart repository configurations, click **Validate**.
-{% endhint %}
+:::
4. Click **Update**.
@@ -73,7 +79,8 @@ If you are using an chart repository as your chart source and prefer to delete i
1. Navigate back to **Chart Repositories**.
- 
+ 
+
Figure 4: Deleting a Chart Repository
2. Select your preferred chart repository.
diff --git a/docs/user-guide/global-configurations/cluster-and-environments.md b/docs/user-guide/global-configurations/cluster-and-environments.md
old mode 100644
new mode 100755
index 8983a2efca..59ea254cc8
--- a/docs/user-guide/global-configurations/cluster-and-environments.md
+++ b/docs/user-guide/global-configurations/cluster-and-environments.md
@@ -1,608 +1,27 @@
-# Clusters and Environments
-
-## Introduction
-
-Devtron allows you to connect and manage your existing Kubernetes clusters by adding them to its platform. Once a cluster is added, you can create different environments within it, making it possible to deploy your applications.
-
-You can add any of the following cluster types:
-* [Kubernetes Cluster](#add-kubernetes-cluster) - If you have access to the cluster, use this option.
-* [Isolated Cluster](#add-isolated-cluster) - For air-gapped use-cases, use this option.
-
---
-
-## Add Kubernetes Cluster
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users need to have super-admin permission to add a Kubernetes cluster to Devtron.
-{% endhint %}
-
-
-1. Go to **Global Configurations** → **Clusters & Environments** → **Connect Cluster** (button); a **New Cluster** modal window will appear.
-
- 
-
-2. Select **Connect Cluster**.
-
- 
-
-3. You can choose to add your Kubernetes cluster using either of the following methods:
-
- | Method | Description |
- | :----------------------------------------------------------------------- | :------------------------------------------------ |
- | [Server URL & Bearer Token](#add-cluster-using-server-url--bearer-token) | Use Server URL and Bearer Token to add a cluster. |
- | [Kubeconfig](#add-cluster-using-kubeconfig) | Use `Kubeconfig` file to add a cluster. |
-
- 
-
-4. Click **Save Cluster** and your cluster will be connected to Devtron.
-
-### Add Cluster Using Server URL & Bearer Token
-
-{% hint style="info" %}
-### Note
-Refer to [Get Cluster Credentials](#get-cluster-credentials) to learn the process of getting the Server URL and bearer token.
-{% endhint %}
-
-1. To add a Kubernetes cluster on Devtron using Server URL and Bearer Token, provide the following information:
-
- | Field | Description |
- | :--- | :--- |
- | **Name** | Enter the name of your cluster. |
- | **Server URL** | Enter the Server URL of your cluster (with https) **Note**: We recommend using a [self-hosted URL](#benefits-of-self-hosted-url) instead of a cloud-hosted URL. |
- | **Bearer Token** | Paste the bearer token of your cluster |
-
- 
-
-2. Complete the remaining steps (optional):
- * [Choose Connection Type](#choose-method-of-connection)
- * [Use Secure TLS Connection](#use-secure-tls-connection)
- * [Configure Prometheus](#configure-prometheus-enable-application-metrics)
- * [Assign a Category](#assign-category-to-a-cluster)
-
-{% hint style="tip" %}
-### Tip
-If you have a **kubeconfig** file ready, you may skip the above process and refer to [Add Cluster Using Kubeconfig](#add-cluster-using-kubeconfig) instead.
-{% endhint %}
-
-### Add Cluster Using Kubeconfig
-
-In case you prefer to add clusters using kubeconfig, follow these steps:
-
-1. Copy and paste your kubeconfig file into the editor. Alternatively, you may browse and select the file as well.
-
- 
-
-2. Click the **Get Cluster** button. This action will display the cluster details alongside the kubeconfig.
-
- 
-
-3. If your kubeconfig file lists multiple clusters, they will be displayed in the window. Use the checkboxes to select the desired cluster(s) and click **Save**.
-
- 
-
-4. Click the saved cluster, and complete the remaining steps (optional):
- * [Choose Connection Type](#choose-method-of-connection)
- * [Use Secure TLS Connection](#use-secure-tls-connection)
- * [Configure Prometheus](#configure-prometheus-enable-application-metrics)
- * [Assign a category](#assign-category-to-a-cluster)
-
-{% hint style="warning" %}
-### Note
-Ensure that the **kubeconfig** file 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.
-{% endhint %}
-
-### Assign Category to a Cluster
-
-Devtron allows you to assign a category (for e.g. Prod, QA, Dev, or Stage) to your clusters. This enables category-based filtering in the UI, allowing you to determine whether an application is deployed to the Prod, QA, Dev, or Stage environment.
-
-Before assigning a category, you must first add the category. To add a category, refer to the [Adding a Category](#add-category) section to learn more.
-
-To assign a category to a cluster, follow the steps below:
-
-1. Select a category from the dropdown under **Assign Category** and click **Update Cluster**.
-
- 
-
-2. The selected category will be assigned to the cluster.
-
- 
-
-
-### Choose Method of Connection [](https://devtron.ai/pricing)
-
-When adding a new cluster to Devtron, you must choose how Devtron will connect to it. There are three connection options available:
-
-#### Direct Connection
-Clusters with a directly accessible API server endpoint, either publicly or via private peering, can be added as Direct Connection clusters.
-* Devtron connects directly without an intermediary.
-* Recommended when the cluster is publicly accessible or has a direct network route from Devtron.
-
-
-
-#### Via Proxy [](https://devtron.ai/pricing)
-
-For security reasons, some Kubernetes clusters are deployed behind a proxy. In this setup, Devtron routes all communication through the specified proxy URL.
-* Use this option when network restrictions require traffic to go through a proxy server.
-* Requires specifying a **Proxy URL** (e.g., `http://proxy.example.org:3128`).
-* **Limitation**: Deployments via [GitOps (ArgoCD)](../../reference/glossary.md#gitops) are not recommended for clusters connected via proxy.
-
-
-
-#### Via SSH Tunnel [](https://devtron.ai/pricing)
-
-When a direct connection isn't possible, Devtron can connect to the Kubernetes cluster through an SSH tunnel, ensuring secure and encrypted communication.
-* Requires:
- * **SSH Server URL** (e.g., `http://proxy.example.org`).
- * **Username** for authentication.
- * **Authentication Method**:
- * Password
- * SSH Private Key
- * Both Password & SSH Private Key
-* **Limitation**: Deployments via [GitOps (ArgoCD)](../../reference/glossary.md#gitops) are **not recommended** for clusters connected via SSH Tunnel.
-
-
-
-
-### Use Secure TLS Connection
-
-For a secure cluster connection, you can opt for TLS connection, where you need to provide Certificate Authority Data, a TLS Key, and a TLS Certificate.
-
-If your cluster is managed (e.g., [EKS](https://aws.amazon.com/eks/), [AKS](https://learn.microsoft.com/en-us/azure/aks/), [GKE](https://cloud.google.com/kubernetes-engine)), you might need to download these certificates from your cloud provider’s dashboard or API.
-
-| Field | Description |
-|--------|------------|
-| **Certificate Authority (CA) Data** | The CA certificate (see: [example](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/global-configurations/cluster-and-environments/kubeconfig-entry.jpg)) used to verify the Kubernetes API server’s identity. |
-| **TLS Key** | The private key associated with the client certificate for authentication. |
-| **TLS Certificate** | The client certificate used to authenticate with the Kubernetes API server. |
-
-
-
-
-### Configure Prometheus (Enable Application Metrics)
-
-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.
-
-Enable application metrics to configure Prometheus as shown below. In case it is not available, make sure to install the **Monitoring (Grafana)** integration from [Devtron Stack Manager](../stack-manager.md) to configure Prometheus.
-
-
-
-Provide the information in the following fields:
-
-| Field | Description |
-| :--- | :--- |
-| **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** | These fields are optional and can be used when you use a customized URL. |
-
-Click **Save Cluster** to save your cluster on Devtron.
-
+title: Clusters and Environments
+sidebar_label: Clusters and Environments
---
-## Create Kubernetes Cluster [](https://devtron.ai/pricing)
-
-### Prerequisites
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
-Only a [Super-Admin](../global-configurations/user-access.md#assign-super-admin-permissions) can add an OCI Registry in Devtron.
-
-{% endhint %}
-
-To create an EKS cluster, you need:
-
-* [OpenTofu](#install-opentofu) (`tofu-controller`) chart installed in your Devtron instance.
-
- Refer to [Getting Started with OpenTofu](https://opentofu.org/docs/intro/) for more information.
-
-* [FluxCD controller](#install-fluxcd-controller) (`flux2`) chart installed in your Devtron instance
-
-* [Secret](#create-a-secret) containing AWS credentials
-
-#### Install OpenTofu
-
-Follow the steps mentioned below to install OpenTofu:
-
-1. Navigate to **Global Configurations** → **Container/OCI Registry**.
-
-2. Refer to the following table and enter the information in the appropriate fields:
-
- | Field | Value |
- | :--- | :--- |
- | **Registry provider** | Other |
- | **Registry type** | Public Registry |
- | **Name** | `tofu` |
- | **Registry URL** | `ghcr.io` |
- | **List of repositories** | `flux-iac/charts/tofu-controller` |
-
-
-
- 
-
-3. Click **Save**. The `tofu-controller` chart will be displayed in the [Chart Store](../../user-guide/deploy-chart/README.md) page.
-
-4. Navigate to **Chart Store** and search for `tofu-controller` in the search box.
-
-5. Select the chart and click **Configure & Deploy**. The following page will be displayed.
-
- 
-
-6. Enter the app name (e.g., `tofu-controller`) in the **App Name** field.
-
-7. Select your project in the **Project** drop-down box.
-
-8. Select the environment where you want to deploy the chart in the **Deploy to Environment** drop-down box.
-
-{% hint style="warning" %}
-
-### Important Note
-
-The environment/namespace where you install OpenTofu must be the same environment/namespace where the FluxCD controller will be installed (the next step) to create the cluster.
-
-{% endhint %}
-
-9. Choose either **Helm** or **GitOps** [if configured](../../user-guide/global-configurations/gitops.md) as the deployment method.
-
-10. Click **Deploy Chart**. OpenTofu will be installed in your Devtron instance.
-
-Now that OpenTofu is installed, you can [install the FluxCD controller](#install-fluxcd-controller) in your Devtron instance.
-
-#### Install FluxCD Controller
-
-Follow the steps mentioned below to install OpenTofu:
-
-1. Navigate to [Chart Store](../../user-guide/deploy-chart/README.md) and search for `flux2` in the search box.
-
- 
-
-2. Select the chart and click **Deploy**.
-
-3. Enter the app name (e.g., `tofu2`) in the **App Name** field.
-
-4. Select your project in the **Project** drop-down box.
-
-5. Select the environment where you want to deploy the chart in the **Deploy to Environment** drop-down box.
-
-{% hint style="warning" %}
-
-### Important Note
-
-The environment/namespace where you install the FluxCD controller must be the same environment/namespace where OpenTofu was installed to create the cluster.
-
-{% endhint %}
-
-6. Choose either **Helm** or **GitOps** [if configured](../../user-guide/global-configurations/gitops.md) as the deployment method.
-
-7. Click **Deploy Chart**. FluxCD controller will be installed in your Devtron instance.
-
-Now that FluxCD controller is installed, the final prerequisite is to [create a secret](#create-a-secret) containing your AWS credentials.
-
-#### Create a Secret
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
+The **Clusters and Environments** section helps you connect Kubernetes clusters to Devtron and set up the environments where your applications will be deployed.
-User needs to be an [Admin](../../user-guide/global-configurations/authorization/user-access.md#kubernetes-resources-permissions) of the Kubernetes resource or a [Super-Admin](../../user-guide/global-configurations/authorization/user-access.md#kubernetes-resources-permissions) to create a Secret.
+This section provides a clear guide for onboarding clusters, structuring environments, and keeping them all organized.
-{% endhint %}
-
-Follow the steps mentioned below to create a secret containing your AWS credentials:
-
-1. Navigate to **Resource Browser**.
-
-2. Click the **default_cluster**.
-
-3. Click **Create Resource**.
-
-4. Copy the YAML snippet given below and paste it in the **Create Kubernetes Resource** page.
-
- ```yaml
- apiVersion: v1
- data:
- AWS_ACCESS_KEY_ID: SDKDI382DKD0=
- AWS_SECRET_ACCESS_KEY: YVZsSIEOwcFRSMjlvM2xaUjSIE823J3PT0=
- kind: Secret
- metadata:
- name: tf-aws-creds
- namespace: your-namespace
- type: Opaque
- ```
-
-{% hint style="warning" %}
-
-### Important Note
-
-* It is recommended to keep the `name` attribute to `tf-aws-creds`. Changing this value might make the secret go unrecognized.
-
-* The secret must be created in the same namespace where OpenTofu and FluxCD controller are installed.
-
-* When creating a secret, kindly ensure that your `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are encoded in base64. Go to [Devtron Base64 Encoder](https://strings.devtron.ai/base64-encoder) to encode your AWS credentials.
-
-{% endhint %}
-
-5. Enter your AWS access key against the `AWS_ACCESS_KEY_ID` attribute and AWS secret key against the `AWS_SECRET_ACCESS_KEY` attribute. Refer to [Create New Access Keys](https://docs.aws.amazon.com/keyspaces/latest/devguide/create.keypair.html) for more information.
-
-6. Click **Apply**. The secret will be created.
-
-Now that all the prerequisites are met, you can proceed to create a cluster from the **Create Kubernetes Cluster** page.
-
-### Steps
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
-Only a [Super-Admin](../global-configurations/user-access.md#assign-super-admin-permissions) can create a Kubernetes cluster.
-
-{% endhint %}
-
-* Navigate to **Global Configurations** → **Clusters & Environments** → **New Cluster** → **Create Kubernetes Cluster**.
-
-* Refer the following table (containing **mandatory** fields) and enter the details in the corresponding fields:
-
- | Field | Description |
- | :--- | :--- |
- | `Cluster Provider` | Select the type of cluster you'd like to create based on your requirement |
- | `Name` | Enter the name of your Kubernetes cluster (e.g., `eks-cluster-nonprod` in the case of EKS and `rancher-cluster-qa` in the case of Rancher) |
- | `Region` | Select the region where your cluster is hosted (e.g., `us-east-1` in the case of EKS and `ap-south-3` in the case of Rancher) Refer to [View cluster details using the AWS Management Console](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-view-clusters.html#emr-view-cluster-console) for more information|
- | `VPC CIDR` | Enter the [VPC CIDR](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) value. This value determines the number of [pods](../../reference/glossary.md#pod), [nodes](../../reference/glossary.md#nodes), or services your cluster can host (e.g., `10.0.1.6/16`)|
- | `Authentication Mode` | Select the authentication mode you wish to perform for the cluster
**API_AND_CONFIG_MAP** - Select this if you want to use both the API and the ConfigMap to authenticate who can access the cluster. This option is recommended if you are migrating from the old `aws-auth` ConfigMap method (which is deprecated) to the new API method. Refer to [Grant IAM users access to Kubernetes with EKS access entries](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) for more information.
**API** - Select this if you want to manage access using a single API. This option is recommended as this is the best practice for EKS cluster creation. Refer to [Manage User Access with API](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) for more information.
**CONFIG MAP** - Select this if you want to rely on the original (but deprecated) way of authentication using `aws-auth` ConfigMap. This option is not recommended anymore. Refer to [Grant IAM users access to Kubernetes. with a ConfigMap.](https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html) for more information.
|
- | `Enable IRSA` | Turn on this IRSA toggle (IAM Roles for [Service Accounts](https://kubernetes.io/docs/concepts/security/service-accounts/)) if you want your application to securely connect to other AWS services using a service account|
- | `Allow public access` | Turn on this toggle if you want to allow your [EKS control plane](https://docs.aws.amazon.com/eks/latest/best-practices/control-plane.html) endpoint to be accessed publicly from anywhere without the VPC. It is recommended to keep this toggle disabled |
- | `Cluster Version` | Select your preferred Kubernetes cluster version. If you are running a live application in a production environment, it is recommended that you select a stable version instead of the latest version |
-
-
-
- 
-
-
-
-* Refer the following table (containing **optional** fields) and enter the details in the corresponding fields:
-
- | Field | Description |
- | :--- | :--- |
- | `Team` | Select the team whose tag you want to attach to the cluster resources. For example, when you select `qa-team`, it means that the cluster resources (pods, ConfigMaps, etc.) created with this cluster are owned by the QA team |
- | `Environment` | Select the environment. For example, when you select `qa`, it means that this cluster is a part of the QA environment |
- | `Availability Zones` | Select availability zones (e.g., `us-east-2b` and `ap-west-1a`) if you prefer to distribute your worker nodes across multiple zones to make your cluster highly available. This means that even if one availability zone goes down (e.g., `us-east-2b`), the other zones (e.g., `ap-west-1a`) keep your cluster up and running |
- | `Private access CIDRs` | Enter the private access CIDRs (IP addresses that are allowed to reach the API server). If you had turned off the **Allow public access** toggle, then your EKS control plane endpoint would be private. It then becomes crucial to enter the private access CIDRs so that the API server recognizes them and allows them to access the endpoint |
-
-* Click **Create Cluster**.
+
+
Figure 1: Navigating to Clusters & Environments
---
-## Add Isolated Cluster [](https://devtron.ai/pricing)
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users need to have super-admin permission to add an isolated/air-gapped cluster to Devtron.
-{% endhint %}
-
-For air-gapped Kubernetes clusters with restricted inbound and outbound traffic, Devtron enables seamless management using isolated clusters. While these are not actual clusters with API endpoints, they provide a convenient way to deploy applications in such environments.
-
-1. On the **New Cluster** modal window, select **Add Isolated Cluster**.
-
- 
-
-2. Add a cluster name (e.g. *banking-airgapped-cluster*) and click **Save Cluster**.
-
- 
-
-You have successfully configured an isolated cluster.
-
-
-
-{% hint style="info" %}
-### Note
-When you deploy to an isolated environment, Devtron automatically packages application manifests and images into a [Helm chart](../../reference/glossary.md#helm-chartspackages). You can then either:
-* Download and install manually in a fully air-gapped setup.
-* Push it to an [OCI registry](../global-configurations/container-registries.md) (provided pushing of helm package is enabled), allowing manifests to be pulled manually or automatically via Devtron on an air-gapped cluster (if pull access to the OCI registry is available).
-{% endhint %}
-
----
-
-## Add Environment to a Cluster
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users need to have super-admin permission to add an environment to a cluster.
-{% endhint %}
-
-After adding a cluster to Devtron ([Kubernetes Cluster](#add-kubernetes-cluster), [Isolated Cluster](#add-isolated-cluster), and a newly created cluster), initially it has no environments.
-
-1. Select the Cluster to which you want to add an Environment and click **Add Environment**. Alternatively you can also hover over the cluster and click `+` icon (Add Environment icon); an **Add Environment** modal window appears.
-
- 
-
- 
-
-2. Fill the following details within the **Add Environment** modal window.
-
- | Field | Description |
- | :--- | :--- |
- | **Environment Name** | Enter a name for your environment. |
- | **Enter Namespace** | Enter a namespace corresponding to your environment. **Note**: If this namespace does not exist in your cluster, Devtron will create it. If it already exists, Devtron will map the environment to it. |
- | **Environment Type** | Select your environment type:
`Production`
`Non-production`
Note: Devtron shows deployment metrics (DORA metrics) for environments tagged as `Production` only. |
-
- 
-
-3. **Assign a Category to environment** [](https://devtron.ai/pricing) - Devtron allows you to assign a category (for e.g. Prod, QA, Dev, or Stage) to your environments. This enables category-based filtering in the UI, allowing you to determine whether an application is deployed to Prod, QA, Dev, or Stage environment.
- To assign a category to your environment, follow the steps below:
- 1. Select a category from the dropdown under **Assign Category** and click **Update**.
-
- 
-
- 2. The selected category will be assigned to the environment.
-
- 
-
- **Note:** Before assigning a category, you must first add the category. To add a category, refer to [Adding a Category](#add-category) section to learn more.
-
-4. **Add/Edit labels to namespace** [](https://devtron.ai/pricing) - You can attach labels to your specified namespace in the Kubernetes cluster. Using labels will help you filter and identify resources via CLI or other Kubernetes tools. [Click here](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to know more about labels.
-
- 
-
-5. Click **Save**. Your new environment will be visible in your cluster as shown below.
-
- 
-
----
-
-## Edit Environment
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users need to have super-admin permission to edit an environment in a cluster.
-{% endhint %}
-
-You can also make edits to an existing environment if needed.
-
-1. Navigate to **Environments** tab.
-
-2. Hover over the environment you wish to edit, and click the **edit** icon.
-
-
-
-3. Edit the environment fields.
-
-| Feature | Editable? |
-| :----------------------------------- | :-------- |
-| **Production/Non-Production Option** | ✅ Yes |
-| **Description** | ✅ Yes |
-| **Labels for Namespace** | ✅ Yes |
-| **Assign a category** | ✅ Yes |
-| **Environment Name** | ❌ No |
-| **Namespace Name** | ❌ No |
-
-4. Click **Update** to save your changes.
-
-
-
----
-
-## Delete Environment
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users need to have super-admin permission to delete an environment from a cluster.
-{% endhint %}
-
-If an environment is no longer needed, you can delete it by following these steps:
-
-1. Navigate to **Environments** tab.
-
-2. Hover over the environment you wish to remove, and click the **delete** icon.
-
- 
-
-{% hint style="warning" %}
-### Important
-Environment deletion is not allowed if any application has a CD pipeline corresponding to the environment. In such a case, go to [Workflow Editor](../creating-application/workflow/README.md) and delete the deployment pipeline first, and then return to delete the environment. This action is irreversible, so make sure no critical applications or resources depend on the environment before deleting.
-{% endhint %}
-
-2. A confirmation dialog will appear. Click **Delete** to permanently delete the environment.
-
- 
-
----
-
-## Add Category
-
-Before assigning a category, you must first add the category. To add a category, follow the steps below:
-
-1. Go to **Global Configurations**.
-
- 
-
-2. Select **Clusters and Environments** and click **Manage Categories**, a modal window will open.
-
- 
-
-3. Enter the name of the category in the **CATEGORIES** field and provide a description in the **DESCRIPTION** field.
-
- {% hint style="info" %}
- ### Note:
- * The category name must be unique and cannot be changed once defined. It should be a minimum of 3 characters.
- * It can contain alphanumeric characters, but cannot start with a number.
- * The name should be in lowercase only.
- {% endhint %}
-
- 
-
-4. If you wish to add more categories, click **Add Category**, a new row will appear, enter the name and description of the new category.
-
- 
-
-5. Click **Update** and your categories will be added.
-
- 
-
-
-## Delete Category
-
-To delete a category, follow the steps below:
-
-1. Go to **Global Configurations**.
-
- 
-
-2. Select **Clusters and Environments** and click **Manage Categories**, a modal window will open.
-
- 
-
-3. Select the `x` icon next to the categories you want to delete.
-
- **Note**: You cannot delete a category if it is assigned to a cluster or environment.
-
- 
-
-4. Click **Update** to delete the categories.
----
-
-## Extras
-
-### Get Cluster Credentials
-
-{% hint style="info" %}
-### Prerequisite
-[kubectl](https://kubernetes.io/docs/tasks/tools/) must be installed on the bastion.
-{% endhint %}
-
-{% hint style="info" %}
-### Note
-We recommend using a self-hosted URL instead of a cloud-hosted URL. Refer to the benefits of a [self-hosted URL](#benefits-of-self-hosted-url).
-{% endhint %}
-
-You can get the **Server URL** and **Bearer Token** by running the following command, depending on the cluster provider:
-
-{% tabs %}
-{% tab title="k8s Cluster Providers" %}
-If you are using EKS, AKS, GKE, Kops, Digital Ocean managed Kubernetes, run the following command to generate the server URL and bearer token:
-```bash
-curl -O https://raw.githubusercontent.com/devtron-labs/utilities/main/kubeconfig-exporter/kubernetes_export_sa.sh && bash kubernetes_export_sa.sh cd-user devtroncd
-```
-{% endtab %}
-{% tab title="Microk8s Cluster" %}
-If you are using a **`microk8s cluster`**, run the following command to generate the server URL and bearer token:
-
-```bash
-curl -O https://raw.githubusercontent.com/devtron-labs/utilities/main/kubeconfig-exporter/kubernetes_export_sa.sh && sed -i 's/kubectl/microk8s kubectl/g' \
-kubernetes_export_sa.sh && bash kubernetes_export_sa.sh cd-user \
-devtroncd
-```
-{% endtab %}
-{% endtabs %}
-
-
+## Table of Contents
-### Benefits of Self-hosted URL
+### 1. [Add Clusters](./clusters/add-clusters.md)
+Learn how to connect an existing Kubernetes cluster, create a new managed cluster, or add an isolated air gapped cluster.
+Covers all connection methods, TLS configuration, Prometheus setup, and assigning categories.
-* **Disaster Recovery**:
- * You cannot 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.
+### 2. [Manage Environments](./clusters/manage-environments.md)
+Create and manage environments inside your clusters.
+Assign namespaces, define environment type, add labels, and update or delete environments when needed.
-* **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 belongs to a single hosted domain independent of the cloud provider.
+### 3. [Manage Categories](./clusters/manage-categories.md)
+Create and organize categories like dev, QA, stage, or prod.
+Use categories to group clusters and environments for easy filtering in the Devtron UI.
diff --git a/docs/user-guide/global-configurations/clusters/add-clusters.md b/docs/user-guide/global-configurations/clusters/add-clusters.md
new file mode 100644
index 0000000000..c83f6c51ca
--- /dev/null
+++ b/docs/user-guide/global-configurations/clusters/add-clusters.md
@@ -0,0 +1,443 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Add Clusters
+
+Connecting your Kubernetes clusters to Devtron is the foundation for deploying, observing, and managing applications across your infrastructure. This page walks you through the different ways to add a cluster, whether you are connecting an existing cluster, using a kubeconfig file, or working with isolated and air-gapped setups. You will also learn how to configure connection types, set up TLS, enable application metrics, and assign categories for better organization.
+
+## Connect Your Existing Kubernetes Cluster
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to add a Kubernetes cluster to Devtron.
+:::
+
+
+1. Go to **Global Configurations** → **Clusters & Environments** → **Add Cluster**.
+
+ 
+
+
+3. You can choose to add your Kubernetes cluster using either of the following methods:
+
+ | Method | Description |
+ | :----------------------------------------------------------------------- | :------------------------------------------------ |
+ | [Server URL & Bearer Token](#method-1-add-cluster-using-server-url--bearer-token) | Use Server URL and Bearer Token to add a cluster. |
+ | [Kubeconfig](#method-2-add-cluster-using-kubeconfig) | Use `Kubeconfig` file to add a cluster. |
+
+ 
+
Figure 3: Choosing a Method
+
+4. Click **Save Cluster** and your cluster will be connected to Devtron.
+
+### Method 1: Add Cluster Using Server URL & Bearer Token
+
+:::info Note
+Refer to [Get Cluster Credentials](#get-cluster-credentials) to learn the process of getting the Server URL and bearer token.
+:::
+
+1. To add a Kubernetes cluster on Devtron using Server URL and Bearer Token, provide the following information:
+
+ | Field | Description |
+ | :--- | :--- |
+ | **Name** | Enter the name of your cluster. |
+ | **Server URL** | Enter the Server URL of your cluster (with https) **Note**: We recommend using a [self-hosted URL](#benefits-of-self-hosted-url) instead of a cloud-hosted URL. |
+ | **Bearer Token** | Paste the bearer token of your cluster |
+
+ 
+
Figure 4: Enter Cluster Credentials
+
+2. Complete the remaining steps (optional):
+ * [Choose Connection Type](#choose-method-of-connection-)
+ * [Use Secure TLS Connection](#use-secure-tls-connection)
+ * [Configure Prometheus](#configure-prometheus-enable-application-metrics)
+ * [Assign a Category](#assign-category-to-a-cluster)
+
+:::tip Tip
+If you have a **kubeconfig** file ready, you may skip the above process and refer to [Add Cluster Using Kubeconfig](#method-2-add-cluster-using-kubeconfig) instead.
+:::
+
+### Method 2: Add Cluster Using Kubeconfig
+
+In case you prefer to add clusters using kubeconfig, follow these steps:
+
+1. Copy and paste your kubeconfig file into the editor. Alternatively, you may browse and select the file as well.
+
+ 
+
Figure 5: Choosing Kubeconfig Option
+
+2. Click the **Get Cluster** button. This action will display the cluster details alongside the kubeconfig.
+
+ 
+
Figure 6: Get Cluster List from Kubeconfig
+
+3. If your kubeconfig file lists multiple clusters, they will be displayed in the window. Use the checkboxes to select the desired cluster(s) and click **Save**.
+
+ 
+
Figure 7: Clicking Save
+
+4. Click the saved cluster, and complete the remaining steps (optional):
+ * [Choose Connection Type](#choose-method-of-connection-)
+ * [Use Secure TLS Connection](#use-secure-tls-connection)
+ * [Configure Prometheus](#configure-prometheus-enable-application-metrics)
+ * [Assign a Category](#assign-category-to-a-cluster)
+
+:::caution Note
+Ensure that the **kubeconfig** file 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.
+:::
+
+---
+
+## Create Kubernetes Cluster
+
+### Prerequisites
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../../global-configurations/authorization/user-access.md#grant-super-admin-permission) can add an OCI Registry in Devtron.
+:::
+
+To create an EKS cluster, you need:
+
+* [OpenTofu](#install-opentofu) (`tofu-controller`) chart installed in your Devtron instance. Refer to [Getting Started with OpenTofu](https://opentofu.org/docs/intro/) for more information.
+
+* [FluxCD controller](#install-fluxcd-controller) (`flux2`) chart installed in your Devtron instance
+
+* [Secret](#create-a-secret) containing AWS credentials
+
+#### Install OpenTofu
+
+Follow the steps mentioned below to install OpenTofu:
+
+1. Navigate to **Global Configurations** → **Container/OCI Registry**.
+
+2. Refer to the following table and enter the information in the appropriate fields:
+
+ | Field | Value |
+ | :--- | :--- |
+ | **Registry provider** | Other |
+ | **Registry type** | Public Registry |
+ | **Name** | `tofu` |
+ | **Registry URL** | `ghcr.io` |
+ | **List of repositories** | `flux-iac/charts/tofu-controller` |
+
+
+
+ 
+
Figure 8: Container/OCI Registry
+
+3. Click **Save**. The `tofu-controller` chart will be displayed in the [Chart Store](../../../user-guide/deploy-chart/README.md) page.
+
+4. Navigate to **Chart Store** and search for `tofu-controller` in the search box.
+
+5. Select the chart and click **Configure & Deploy**. The following page will be displayed.
+
+ 
+
Figure 9: Tofu Controller Chart
+
+6. Enter the app name (e.g., `tofu-controller`) in the **App Name** field.
+
+7. Select your project in the **Project** drop-down box.
+
+8. Select the environment where you want to deploy the chart in the **Deploy to Environment** drop-down box.
+
+:::caution Important Note
+The environment/namespace where you install OpenTofu must be the same environment/namespace where the FluxCD controller will be installed (the next step) to create the cluster.
+:::
+
+9. Choose either **Helm** or **GitOps** [if configured](../../../user-guide/global-configurations/gitops.md) as the deployment method.
+
+10. Click **Deploy Chart**. OpenTofu will be installed in your Devtron instance.
+
+Now that OpenTofu is installed, you can [install the FluxCD controller](#install-fluxcd-controller) in your Devtron instance.
+
+#### Install FluxCD Controller
+
+Follow the steps mentioned below to install OpenTofu:
+
+1. Navigate to [Chart Store](../../../user-guide/deploy-chart/README.md) and search for `flux2` in the search box.
+
+ 
+
Figure 10: "flux2" Chart
+
+2. Select the chart and click **Deploy**.
+
+3. Enter the app name (e.g., `tofu2`) in the **App Name** field.
+
+4. Select your project in the **Project** drop-down box.
+
+5. Select the environment where you want to deploy the chart in the **Deploy to Environment** drop-down box.
+
+:::caution Important Note
+The environment/namespace where you install the FluxCD controller must be the same environment/namespace where OpenTofu was installed to create the cluster.
+:::
+
+6. Choose either **Helm** or **GitOps** [if configured](../../../user-guide/global-configurations/gitops.md) as the deployment method.
+
+7. Click **Deploy Chart**. FluxCD controller will be installed in your Devtron instance.
+
+Now that FluxCD controller is installed, the final prerequisite is to [create a secret](#create-a-secret) containing your AWS credentials.
+
+#### Create a Secret
+
+:::caution Who Can Perform This Action?
+User needs to be an [Admin](../../../user-guide/global-configurations/authorization/user-access.md#kubernetes-resources-permissions) of the Kubernetes resource or a [Super-Admin](../../../user-guide/global-configurations/authorization/user-access.md#kubernetes-resources-permissions) to create a Secret.
+
+:::
+
+Follow the steps mentioned below to create a secret containing your AWS credentials:
+
+1. Navigate to **Resource Browser**.
+
+2. Click the **default_cluster**.
+
+3. Click **Create Resource**.
+
+4. Copy the YAML snippet given below and paste it in the **Create Kubernetes Resource** page.
+
+ ```yaml
+ apiVersion: v1
+ data:
+ AWS_ACCESS_KEY_ID: SDKDI382DKD0=
+ AWS_SECRET_ACCESS_KEY: YVZsSIEOwcFRSMjlvM2xaUjSIE823J3PT0=
+ kind: Secret
+ metadata:
+ name: tf-aws-creds
+ namespace: your-namespace
+ type: Opaque
+ ```
+
+:::caution Important Note
+* It is recommended to keep the `name` attribute to `tf-aws-creds`. Changing this value might make the secret go unrecognized.
+
+* The secret must be created in the same namespace where OpenTofu and FluxCD controller are installed.
+
+* When creating a secret, kindly ensure that your `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are encoded in base64. Go to [Devtron Base64 Encoder](https://strings.devtron.ai/base64-encoder) to encode your AWS credentials.
+
+:::
+
+5. Enter your AWS access key against the `AWS_ACCESS_KEY_ID` attribute and AWS secret key against the `AWS_SECRET_ACCESS_KEY` attribute. Refer to [Create New Access Keys](https://docs.aws.amazon.com/keyspaces/latest/devguide/create.keypair.html) for more information.
+
+6. Click **Apply**. The secret will be created.
+
+Now that all the prerequisites are met, you can proceed to create a cluster from the **Create Kubernetes Cluster** page.
+
+### Steps
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../../global-configurations/authorization/user-access.md#grant-super-admin-permission) can create a Kubernetes cluster.
+:::
+
+* Navigate to **Global Configurations** → **Clusters & Environments** → **New Cluster** → **Create Kubernetes Cluster**.
+
+* Refer the following table (containing **mandatory** fields) and enter the details in the corresponding fields:
+
+ | Field | Description |
+ | :--- | :--- |
+ | `Cluster Provider` | Select the type of cluster you'd like to create based on your requirement |
+ | `Name` | Enter the name of your Kubernetes cluster (e.g., `eks-cluster-nonprod` in the case of EKS and `rancher-cluster-qa` in the case of Rancher) |
+ | `Region` | Select the region where your cluster is hosted (e.g., `us-east-1` in the case of EKS and `ap-south-3` in the case of Rancher) Refer to [View cluster details using the AWS Management Console](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-view-clusters.html#emr-view-cluster-console) for more information|
+ | `VPC CIDR` | Enter the [VPC CIDR](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) value. This value determines the number of [pods](../../../reference/glossary.md#pod), [nodes](../../../reference/glossary.md#nodes), or services your cluster can host (e.g., `10.0.1.6/16`)|
+ | `Authentication Mode` | Select the authentication mode you wish to perform for the cluster
**API_AND_CONFIG_MAP** - Select this if you want to use both the API and the ConfigMap to authenticate who can access the cluster. This option is recommended if you are migrating from the old `aws-auth` ConfigMap method (which is deprecated) to the new API method. Refer to [Grant IAM users access to Kubernetes with EKS access entries](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) for more information.
**API** - Select this if you want to manage access using a single API. This option is recommended as this is the best practice for EKS cluster creation. Refer to [Manage User Access with API](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) for more information.
**CONFIG MAP** - Select this if you want to rely on the original (but deprecated) way of authentication using `aws-auth` ConfigMap. This option is not recommended anymore. Refer to [Grant IAM users access to Kubernetes. with a ConfigMap.](https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html) for more information.
|
+ | `Enable IRSA` | Turn on this IRSA toggle (IAM Roles for [Service Accounts](https://kubernetes.io/docs/concepts/security/service-accounts/)) if you want your application to securely connect to other AWS services using a service account|
+ | `Allow public access` | Turn on this toggle if you want to allow your [EKS control plane](https://docs.aws.amazon.com/eks/latest/best-practices/control-plane.html) endpoint to be accessed publicly from anywhere without the VPC. It is recommended to keep this toggle disabled |
+ | `Cluster Version` | Select your preferred Kubernetes cluster version. If you are running a live application in a production environment, it is recommended that you select a stable version instead of the latest version |
+
+
+
+ 
+
Figure 11: Create Kubernetes Cluster
+
+
+
+* Refer the following table (containing **optional** fields) and enter the details in the corresponding fields:
+
+ | Field | Description |
+ | :--- | :--- |
+ | `Team` | Select the team whose tag you want to attach to the cluster resources. For example, when you select `qa-team`, it means that the cluster resources (pods, ConfigMaps, etc.) created with this cluster are owned by the QA team |
+ | `Environment` | Select the environment. For example, when you select `qa`, it means that this cluster is a part of the QA environment |
+ | `Availability Zones` | Select availability zones (e.g., `us-east-2b` and `ap-west-1a`) if you prefer to distribute your worker nodes across multiple zones to make your cluster highly available. This means that even if one availability zone goes down (e.g., `us-east-2b`), the other zones (e.g., `ap-west-1a`) keep your cluster up and running |
+ | `Private access CIDRs` | Enter the private access CIDRs (IP addresses that are allowed to reach the API server). If you had turned off the **Allow public access** toggle, then your EKS control plane endpoint would be private. It then becomes crucial to enter the private access CIDRs so that the API server recognizes them and allows them to access the endpoint |
+
+* Click **Create Cluster**.
+
+---
+
+## Add Isolated Cluster
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to add an isolated/air-gapped cluster to Devtron.
+:::
+
+For air-gapped Kubernetes clusters with restricted inbound and outbound traffic, Devtron enables seamless management using isolated clusters. While these are not actual clusters with API endpoints, they provide a convenient way to deploy applications in such environments.
+
+1. On the **New Cluster** modal window, select **Add Isolated Cluster**.
+
+ 
+
Figure 12: Selecting Isolated Cluster
+
+2. Add a cluster name (e.g. *banking-airgapped-cluster*) and click **Save Cluster**.
+
+ 
+
Figure 13: Saving Isolated Cluster
+
+You have successfully configured an isolated cluster.
+
+
+
Figure 14: New Isolated Cluster
+
+:::info Note
+When you deploy to an isolated environment, Devtron automatically packages application manifests and images into a [Helm chart](../../../reference/glossary.md#helm-chartspackages). You can then either:
+* Download and install manually in a fully air-gapped setup.
+* Push it to an [OCI registry](../../global-configurations/container-registries.md) (provided pushing of helm package is enabled), allowing manifests to be pulled manually or automatically via Devtron on an air-gapped cluster (if pull access to the OCI registry is available).
+:::
+
+---
+
+## Extras
+
+### Assign Category to a Cluster
+
+Devtron allows you to assign a category (for e.g. Prod, QA, Dev, or Stage) to your clusters. This enables category-based filtering in the UI, allowing you to determine whether an application is deployed to the Prod, QA, Dev, or Stage environment.
+
+Before assigning a category, you must first add the category. To add a category, refer to the [Adding a Category](manage-categories.md#add-category) section to learn more.
+
+To assign a category to a cluster, follow the steps below:
+
+1. Select a category from the dropdown under **Assign Category** and click **Update Cluster**.
+
+ 
+
Figure 15: Assigning Category
+
+2. The selected category will be assigned to the cluster.
+
+ 
+
Figure 16: Category Assigned
+
+
+### Choose Method of Connection
+
+When adding a new cluster to Devtron, you must choose how Devtron will connect to it. There are three connection options available:
+
+#### Direct Connection
+Clusters with a directly accessible API server endpoint, either publicly or via private peering, can be added as Direct Connection clusters.
+* Devtron connects directly without an intermediary.
+* Recommended when the cluster is publicly accessible or has a direct network route from Devtron.
+
+
+
+
+#### Via Proxy
+
+For security reasons, some Kubernetes clusters are deployed behind a proxy. In this setup, Devtron routes all communication through the specified proxy URL.
+* Use this option when network restrictions require traffic to go through a proxy server.
+* Requires specifying a **Proxy URL** (e.g., `http://proxy.example.org:3128`).
+* **Limitation**: Deployments via [GitOps (ArgoCD)](../../../reference/glossary.md#gitops) are not recommended for clusters connected via proxy.
+
+
+
Figure 18: Choosing 'Via Proxy'
+
+#### Via SSH Tunnel
+
+When a direct connection isn't possible, Devtron can connect to the Kubernetes cluster through an SSH tunnel, ensuring secure and encrypted communication.
+* Requires:
+ * **SSH Server URL** (e.g., `http://proxy.example.org`).
+ * **Username** for authentication.
+ * **Authentication Method**:
+ * Password
+ * SSH Private Key
+ * Both Password & SSH Private Key
+* **Limitation**: Deployments via [GitOps (ArgoCD)](../../../reference/glossary.md#gitops) are **not recommended** for clusters connected via SSH Tunnel.
+
+
+
Figure 19: Choosing 'Via SSH Tunnel'
+
+
+### Use Secure TLS Connection
+
+For a secure cluster connection, you can opt for TLS connection, where you need to provide Certificate Authority Data, a TLS Key, and a TLS Certificate.
+
+If your cluster is managed (e.g., [EKS](https://aws.amazon.com/eks/), [AKS](https://learn.microsoft.com/en-us/azure/aks/), [GKE](https://cloud.google.com/kubernetes-engine)), you might need to download these certificates from your cloud provider’s dashboard or API.
+
+| Field | Description |
+|--------|------------|
+| **Certificate Authority (CA) Data** | The CA certificate (see: [example](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/devtron-v2/global-configurations/clusterenv/kubeconfig-entry.jpg)) used to verify the Kubernetes API server’s identity. |
+| **TLS Key** | The private key associated with the client certificate for authentication. |
+| **TLS Certificate** | The client certificate used to authenticate with the Kubernetes API server. |
+
+
+
+
+### Configure Prometheus (Enable Application Metrics)
+
+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.
+
+Enable application metrics to configure Prometheus as shown below. In case it is not available, make sure to install the **Monitoring (Grafana)** integration from [Devtron Stack Manager](../../stack-manager.md) to configure Prometheus.
+
+
+
Figure 21: Enabling Application Metrics
+
+Provide the information in the following fields:
+
+| Field | Description |
+| :--- | :--- |
+| **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** | These fields are optional and can be used when you use a customized URL. |
+
+Click **Save Cluster** to save your cluster on Devtron.
+
+### Get Cluster Credentials
+
+:::info Prerequisite
+[kubectl](https://kubernetes.io/docs/tasks/tools/) must be installed on the bastion.
+:::
+
+:::info Note
+We recommend using a self-hosted URL instead of a cloud-hosted URL. Refer to the benefits of a [self-hosted URL](#benefits-of-self-hosted-url).
+:::
+
+You can get the **Server URL** and **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:
+```bash
+curl -O https://raw.githubusercontent.com/devtron-labs/utilities/main/kubeconfig-exporter/kubernetes_export_sa.sh && bash kubernetes_export_sa.sh cd-user devtroncd
+```
+
+
+If you are using a **`microk8s cluster`**, run the following command to generate the server URL and bearer token:
+
+```bash
+curl -O https://raw.githubusercontent.com/devtron-labs/utilities/main/kubeconfig-exporter/kubernetes_export_sa.sh && sed -i 's/kubectl/microk8s kubectl/g' \
+kubernetes_export_sa.sh && bash kubernetes_export_sa.sh cd-user \
+devtroncd
+```
+
+
+
+
+
Figure 22: Generating Cluster Credentials
+
+#### Benefits of Self-hosted URL
+
+* **Disaster Recovery**:
+ * You cannot 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 belongs to a single hosted domain independent of the cloud provider.
diff --git a/docs/user-guide/global-configurations/clusters/manage-categories.md b/docs/user-guide/global-configurations/clusters/manage-categories.md
new file mode 100644
index 0000000000..94e19b2146
--- /dev/null
+++ b/docs/user-guide/global-configurations/clusters/manage-categories.md
@@ -0,0 +1,57 @@
+# Manage Categories
+
+Categories help you group and classify both clusters and environments based on your organization’s standards. Teams commonly use categories like prod, QA, dev, or stage for quick filtering and visual clarity across the Devtron UI. This page guides you through creating, updating, and deleting categories, along with the rules that govern naming and usage.
+
+## Add Category
+
+Before assigning a category, you must first add the category. To add a category, follow the steps below:
+
+1. Go to **Global Configurations** and click **Clusters and Environments**.
+
+ 
+
Figure 1: Navigating to Global Configurations
+
+2. Click **Manage Categories**, a modal window will open.
+
+ 
+
Figure 2: Clicking Manage Categories
+
+3. Click **Add Category**, a new row will appear, enter the name and description of the new category.
+
+:::info Note:
+* The category name must be unique and cannot be changed once defined. It should be a minimum of 3 characters.
+* It can contain alphanumeric characters, but cannot start with a number.
+* The name should be in lowercase only.
+:::
+
+ 
+
Figure 3: Adding More Categories
+
+5. Click **Update** and your categories will be added.
+
+ 
+
Figure 4: Categories Added
+
+
+## Delete Category
+
+To delete a category, follow the steps below:
+
+1. Go to **Global Configurations** and click **Clusters and Environments**.
+
+ 
+
Figure 5: Navigating to Global Configurations
+
+2. Click **Manage Categories**, a modal window will open.
+
+ 
+
Figure 6: Clicking Manage Categories
+
+3. Select the `x` icon next to the categories you want to delete.
+
+ **Note**: You cannot delete a category if it is assigned to a cluster or environment.
+
+ 
+
Figure 7: Clicking 'x' icon
+
+4. Click **Update** to delete the categories.
diff --git a/docs/user-guide/global-configurations/clusters/manage-environments.md b/docs/user-guide/global-configurations/clusters/manage-environments.md
new file mode 100644
index 0000000000..6784540a4b
--- /dev/null
+++ b/docs/user-guide/global-configurations/clusters/manage-environments.md
@@ -0,0 +1,113 @@
+# Manage Environments
+
+Environments allow you to structure your deployment stages inside Devtron by mapping logical stages like dev, QA, staging, or production to actual namespaces within your clusters. Once a cluster is added, you can create environments, define their type, attach labels, and assign categories for cleaner filtering. This page explains how to add, edit, and delete environments.
+
+## Add Environment to a Cluster
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to add an environment to a cluster.
+:::
+
+After adding a cluster to Devtron ([existing Kubernetes cluster](./add-clusters.md#connect-your-existing-kubernetes-cluster), [Isolated cluster](./add-clusters.md#add-isolated-cluster-), or a [newly created cluster](./add-clusters.md#create-kubernetes-cluster-)), initially it has no environments.
+
+1. Select the cluster to which you want to add an Environment and click **Add Environment**. Alternatively you can also hover over the cluster and click `+` icon (Add Environment icon); an **Add Environment** modal window appears.
+
+ 
+
+
+2. Fill the following details within the **Add Environment** modal window.
+
+ | Field | Description |
+ | :--- | :--- |
+ | **Environment Name** | Enter a name for your environment. |
+ | **Enter Namespace** | Enter a namespace corresponding to your environment. **Note**: If this namespace does not exist in your cluster, Devtron will create it. If it already exists, Devtron will map the environment to it. |
+ | **Environment Type** | Select your environment type:
`Production`
`Non-production`
Note: Devtron shows deployment metrics (DORA metrics) for environments tagged as `Production` only. |
+
+ 
+
Figure 2: Saving an Environment
+
+3. **Assign a Category to environment** - Devtron allows you to assign a category (for e.g. Prod, QA, Dev, or Stage) to your environments. This enables category-based filtering in the UI, allowing you to determine whether an application is deployed to Prod, QA, Dev, or Stage environment.
+ To assign a category to your environment, follow the steps below:
+ 1. Select a category from the dropdown under **Assign Category** and click **Update**.
+
+ 
+
Figure 3: Assigning Category
+
+ 2. The selected category will be assigned to the environment.
+
+ 
+
Figure 4: Category Assigned
+
+ **Note:** Before assigning a category, you must first add the category. To add a category, refer to [Adding a Category](./manage-categories.md#add-category) section to learn more.
+
+4. **Add/Edit labels to namespace** - You can attach labels to your specified namespace in the Kubernetes cluster. Using labels will help you filter and identify resources via CLI or other Kubernetes tools. [Click here](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to know more about labels.
+
+ 
+
Figure 5: Adding Labels to Namespace
+
+5. Click **Save**. Your new environment will be visible in your cluster as shown below.
+
+ 
+
Figure 6: Newly Created Environment in the Cluster
+
+---
+
+## Edit Environment
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to edit an environment in a cluster.
+:::
+
+You can also make edits to an existing environment if needed.
+
+1. Navigate to **Environments** tab.
+
+2. Hover over the environment you wish to edit, and click the **edit** icon.
+
+
+
Figure 7: Editing Environment in the Cluster
+
+3. Edit the environment fields.
+
+| Feature | Editable? |
+| :----------------------------------- | :-------- |
+| **Production/Non-Production Option** | ✅ Yes |
+| **Description** | ✅ Yes |
+| **Labels for Namespace** | ✅ Yes |
+| **Assign a category** | ✅ Yes |
+| **Environment Name** | ❌ No |
+| **Namespace Name** | ❌ No |
+
+4. Click **Update** to save your changes.
+
+
+
Figure 8: Updating Environment in the Cluster
+
+---
+
+## Delete Environment
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to delete an environment from a cluster.
+:::
+
+If an environment is no longer needed, you can delete it by following these steps:
+
+1. Navigate to **Environments** tab.
+
+2. Hover over the environment you wish to remove, and click the **delete** icon.
+
+ 
+
Figure 9: Deleting Environment
+
+:::caution Important
+Environment deletion is not allowed if any application has a CD pipeline corresponding to the environment. In such a case, go to [Workflow Editor](../../creating-application/workflow/README.md) and delete the deployment pipeline first, and then return to delete the environment. This action is irreversible, so make sure no critical applications or resources depend on the environment before deleting.
+:::
+
+2. A confirmation dialog will appear. Click **Delete** to permanently delete the environment.
+
+ 
+
Figure 10: Confirming Environment Deletion
diff --git a/docs/user-guide/global-configurations/container-registries.md b/docs/user-guide/global-configurations/container-registries.md
old mode 100644
new mode 100755
index 6ca1076ca3..b52c93cc3f
--- a/docs/user-guide/global-configurations/container-registries.md
+++ b/docs/user-guide/global-configurations/container-registries.md
@@ -2,7 +2,7 @@
## Introduction
-While [container registries](../../reference/glossary.md#container-registry) are typically used for storing [images](../../reference/glossary.md#image) built by the CI Pipeline, an OCI registry can store container images as well as other artifacts such as [helm charts](../../reference/glossary.md#helm-charts-packages). In other words, all container registries are OCI registries, but not all OCI registries are container registries.
+While [container registries](../../reference/glossary.md#containeroci-registry) are typically used for storing [images](../../reference/glossary.md#image) built by the CI Pipeline, an OCI registry can store container images as well as other artifacts such as [helm charts](../../reference/glossary.md#helm-chartspackages). In other words, all container registries are OCI registries, but not all OCI registries are container registries.
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.
@@ -14,11 +14,13 @@ You can configure a container registry using any registry provider of your choic
1. From the left sidebar, go to **Global Configurations** → **Container/OCI Registry**.
- 
+ 
+
3. Choose a provider from the **Registry provider** dropdown. View the [Supported Registry Providers](#supported-registry-providers).
@@ -35,7 +37,7 @@ You can configure a container registry using any registry provider of your choic
| **Authentication Type** | The credential input fields may differ depending on the registry provider, check [Registry Providers](#supported-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](#registry-credential-access). |
| **Push helm packages** | Tick this checkbox if you wish to [push helm charts to your OCI registry](#push-helm-packages) |
- | **Use as chart repository** | Tick this checkbox if you want Devtron to [pull helm charts from your registry and display them on chart store](#use-as-chart-repository). Also, you will have to provide a list of repositories (present within your registry) for Devtron to successfully pull the helm charts. |
+ | **Use as chart repository** | Tick this checkbox if you want Devtron to pull helm charts from your registry and display them on 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 |
6. Click **Save**.
@@ -44,25 +46,21 @@ You can configure a container registry using any registry provider of your choic
Upon enabling this option, Devtron supports the pushing of helm charts to your OCI registry.
-This is possible through [isolated clusters](../global-configurations/cluster-and-environments.md#add-isolated-cluster) that facilitate air-gapped deployments. In other words, it generates a helm package that you can use to deploy your application in air-gapped clusters.
+This is possible through [isolated clusters](../global-configurations/clusters/add-clusters#add-isolated-cluster-) that facilitate air-gapped deployments. In other words, it generates a helm package that you can use to deploy your application in air-gapped clusters.
-If you have [configured your CD pipeline](../creating-application/workflow/cd-pipeline.md#deploying-to-an-isolated-environment) to push the helm package to your OCI registry, you can view the pushed helm package in your registry as shown below:
+If you have [configured your CD pipeline](../creating-application/workflow/cd-pipeline.md) to push the helm package to your OCI registry, you can view the pushed helm package in your registry as shown below:
-
+
+
-{% hint style="warning" %}
-
-### Use as Chart Repository
-
-{% hint style="info" %}
-
-### Prerequisite
+:::info Prerequisite
OCI registry with `Use as chart repository` option enabled.
-{% endhint %}
+:::
Unlike Helm repos, OCI registries do not have an index file to discover all the charts. If you have helm packages pushed to your OCI registry, you can that registry as a chart repository.
@@ -70,7 +68,7 @@ Upon enabling this option, Devtron can use your OCI registry as the chart source
#### Tutorial
-{% embed url="https://www.youtube.com/watch?v=9imC5MMz9gs" caption="Pulling Charts from an OCI Registry to Devtron" %}
+
#### Steps
@@ -94,7 +92,7 @@ Provide the following additional information apart from the common fields:
| Fields | Description |
| --- | --- |
| **Registry URL** | Example of URL format: `xxxxxxxxxxxx.dkr.ecr..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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/get-set-up-for-amazon-ecr.html).
`Access key ID`: Your AWS access key
`Secret access key`: Your AWS secret access key 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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/get-set-up-for-amazon-ecr.html).
`Access key ID`: Your AWS access key
`Secret access key`: Your AWS secret access key ID
|
### Docker
@@ -124,9 +122,9 @@ Provide the following additional information apart from the common fields:
JSON key file authentication method can be used to authenticate with username and service account JSON file. Visit this [link](https://cloud.google.com/artifact-registry/docs/docker/authentication#json-key) to get the username and service account JSON file for this registry.
-{% hint style="warning" %}
+:::caution
Remove all the white spaces from JSON key and wrap it in a single quote before pasting it in `Service Account JSON File` field
-{% endhint %}
+:::
Provide the following additional information apart from the common fields:
@@ -140,9 +138,9 @@ Provide the following additional information apart from the common fields:
JSON key file authentication method can be used to authenticate with username and service account JSON file. Please follow [link](https://cloud.google.com/container-registry/docs/advanced-authentication#json-key) to get the username and service account JSON file for this registry.
-{% hint style="warning" %}
+:::caution
Remove all the white spaces from JSON key and wrap it in single quote before pasting it in `Service Account JSON File` field
-{% endhint %}
+:::
### Quay
@@ -163,11 +161,11 @@ Provide below information if you select the registry type as `Other`.
| **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)
**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)
|
-{% hint style="info" %}
+:::info
You can use any registry which can be authenticated using `docker login -u -p `. However these registries might provide a more secured way for authentication, which we will support later.
-{% endhint %}
+:::
## Registry Credential Access
@@ -196,14 +194,16 @@ If you select **Use Registry Credentials**, the clusters will be auto-injected w
Click **Save**.
-
+
+
Figure 4: Using Registry Credentials
### Specify Image Pull Secret
You can create a Secret by providing credentials on the command line.
-
+
+
Figure 5: Using Image Pull Secret
Create this Secret and name it `regcred` (let's say):
@@ -214,16 +214,16 @@ kubectl create -n secret docker-registry regcred --docker-server=Figure 6: Delete an OCI Registry
2. Select your preferred OCI registry.
3. Click the **Delete** button. The OCI registry will be deleted.
-{% hint style="warning" %}
-
-### Important Note
-
+:::caution Important Note
If you used an OCI registry as a chart source, deleting the OCI registry will remove all its associated charts from the Chart Store.
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/user-guide/global-configurations/deployment-charts.md b/docs/user-guide/global-configurations/deployment-charts.md
old mode 100644
new mode 100755
index b8acf0b66f..04665e3ca9
--- a/docs/user-guide/global-configurations/deployment-charts.md
+++ b/docs/user-guide/global-configurations/deployment-charts.md
@@ -1,3 +1,10 @@
+---
+id: deployment-charts
+title: Deployment Charts
+sidebar_label: Deployment Charts
+slug: /user-guide/app-management/configurations/deployment-charts
+---
+
# Deployment Charts
## Introduction
@@ -6,13 +13,14 @@ Devtron Apps leverage helm charts to carry out deployment of your images and con
For any use case not addressed by the default Helm charts, you can upload your own Helm chart and use it as a deployment chart in Devtron.
-
+
+
Figure 1: Deployment Charts
### Tutorial
This video contains a quick walkthrough of the steps mentioned in the [Preparing a Deployment Chart](#preparing-a-deployment-chart) section of this page and the subsequent uploading of the deployment chart on Devtron.
-{% embed url="https://www.youtube.com/watch?v=jzMZa7bSiyA" caption="How to Upload your Deployment Chart in Devtron" %}
+
---
@@ -38,10 +46,9 @@ helm create my-custom-chart
| `Version` | This is the chart version. Update this value for each new version of the chart (Required). |
| `Description` | Give a description to your chart (Optional). |
-{% hint style="info" %}
-### Example of Chart.yaml
+:::info Example of Chart.yaml
[Click here](https://devtron-public-asset.s3.us-east-2.amazonaws.com/custom-charts/chart-yaml-file.jpg) to view a sample 'Chart.yaml' file.
-{% endhint %}
+:::
### 2. Create an Image Descriptor Template File
@@ -55,7 +62,8 @@ The Image Descriptor Template file is a GO template that produces a valid JSON f
* Ensure the above file is created in the directory where the main `Chart.yaml` exists (as shown below):
- 
+ 
+
Figure 2: Filepath of Image Descriptor Template
* Paste the following content in `.image_descriptor_template.json` file:
@@ -87,10 +95,9 @@ The Image Descriptor Template file is a GO template that produces a valid JSON f
}
```
-{% hint style="warning" %}
-### Got a JSON Error?
+:::caution Got a JSON Error?
If your code editor highlights a syntax error (property or EOF error) in the above JSON, ignore it.
-{% endhint %}
+:::
+
+---
+
+## Scanning an Image with AWS Inspector
+
+Once AWS Inspector is enabled:
+
+1. Go to your application's **Configurations** → **Workflow Editor** and edit (or create) the **build pipeline**.
+
+2. In the build pipeline's advanced options, enable **Scan for vulnerabilities**.
+
+ :::info
+ If image scanning is enforced globally by your administrator, the scan runs on every build and this toggle may be locked on.
+ :::
+
+3. Trigger the build. After the image is built, Devtron generates the SBOM and scans it via Amazon Inspector as described in [How AWS Inspector Scanning Works](#how-aws-inspector-scanning-works).
+
+---
+
+## Viewing Scan Results
+
+Once an image is scanned, the vulnerabilities detected by Amazon Inspector appear in the **Security** tab of the build/app, alongside the scan tool name and a severity breakdown (Critical/High/Medium/Low). Based on these results, [Security Policies](../../security-features/security-policies.md) can automatically allow or block deployments.
+
+
+
+Refer to [Security Features](../../security-features.md) to learn more about viewing scan results and enforcing policies.
+
+---
+
+## Integrating Your Own Scan Tool
+
+Devtron's scanning is built on a generic scan-tool framework, so AWS Inspector, Trivy, and Clair are all integrated the **same way**. You can register your own scanning tool by supplying two things in a single registration request: **scan tool metadata** and a **scan plugin**.
+
+:::caution Who Can Perform This Action?
+Registering a scan tool is a **global** operation and can only be performed by a **super-admin**.
+:::
+
+### 1. Scan Tool Metadata
+
+This describes the tool to Devtron and how to interpret its output.
+
+| Field | Required | Description |
+| :--- | :--- | :--- |
+| `name` | Yes | Name of the scanning tool, e.g., `AWS INSPECTOR`. The `name` + `version` combination must be unique. |
+| `version` | Yes | Version of the tool, e.g., `V1`. |
+| `scanTarget` | Yes | What the tool scans. Currently `IMAGE` is supported. |
+| `resultDescriptorTemplate` | Yes | A template that maps the tool's raw output into the standard result format Devtron uses to render vulnerabilities. |
+| `scanToolUrl` | No | Icon/logo URL shown next to the tool in Devtron's UI. |
+| `serverBaseUrl` | No | Base URL of the scanning service, if the tool talks to an external server. |
+| `toolMetaData` | No | Any additional tool-specific metadata. |
+
+### 2. Scan Plugin
+
+This is the executable logic that actually runs the scan. It is built on Devtron's base plugin `devtron-image-scanning-integrator`, and defines the steps and input variables (such as image reference, credentials, or region) required to run your scanner. The plugin runs during the pipeline, and its output is converted into Devtron's standard scan result using the `resultDescriptorTemplate` from the metadata.
+
+| Field | Required | Description |
+| :--- | :--- | :--- |
+| `name` | Yes | Display name of the plugin (3–100 characters). |
+| `pluginIdentifier` | Yes | Unique identifier for the plugin (3–100 characters). |
+| `pluginVersion` | Yes | Version of the plugin (3–50 characters). |
+| `description` | No | Brief description of what the plugin does (max 300 characters). |
+| `pluginSteps` | Yes | The ordered steps (and their input variables) the plugin executes to perform the scan. |
+
+### Registration API
+
+Scan tools are registered through the following super-admin API:
+
+```
+POST /orchestrator/scan-tool/register
+```
+
+Example request body:
+
+```json
+{
+ "scanToolMetadata": {
+ "name": "AWS INSPECTOR",
+ "version": "V1",
+ "scanTarget": "IMAGE",
+ "scanToolUrl": "https://cdn.devtron.ai/images/ic-aws-inspector.webp",
+ "resultDescriptorTemplate": ""
+ },
+ "scanToolPluginMetadata": {
+ "name": "AWS Inspector Scanner",
+ "pluginIdentifier": "aws-inspector-scanner",
+ "pluginVersion": "1.0.0",
+ "description": "Scans container images using Amazon Inspector",
+ "pluginSteps": [
+ {
+ "...": "plugin step definition, based on devtron-image-scanning-integrator"
+ }
+ ]
+ }
+}
+```
+
+:::info Preset vs. custom tools
+Devtron-provided tools such as **Trivy** and **Clair** are marked as **preset** tools (`is_preset = true`). Tools you register yourself are marked as **custom** tools (`is_preset = false`). Both behave identically once integrated; the flag only distinguishes tools shipped by Devtron from those added by users.
+:::
+
+
+
+### Notes and Limitations
+
+* `scanTarget` currently supports **`IMAGE`** scanning.
+* The `name` + `version` pair must be unique across all registered scan tools.
+* The quality of the rendered results depends on your `resultDescriptorTemplate` correctly mapping the tool's output fields (such as CVE ID, severity, and package) to Devtron's standard format.
+
+To integrate a custom scanning tool for your organization, reach out to [support@devtron.ai](mailto:support@devtron.ai).
diff --git a/docs/user-guide/integrations/vulnerability-scanning/clair.md b/docs/user-guide/integrations/vulnerability-scanning/clair.md
old mode 100644
new mode 100755
index e26e7f1304..a38410dde5
--- a/docs/user-guide/integrations/vulnerability-scanning/clair.md
+++ b/docs/user-guide/integrations/vulnerability-scanning/clair.md
@@ -1,11 +1,10 @@
# Security Integration (Clair)
- {% hint style="warning" %}
- ### Prerequisite
+ :::caution Prerequisite
**For OSS users**: Please ensure that [Build and Deploy (CI/CD)](../../integrations/build-and-deploy-ci-cd.md) integration is installed.
**For Enterprise Users**: **Build and Deploy (CI/CD)** integration is installed by default.
- {% endhint %}
+ :::
Clair integration enables you to scan the vulnerabilities of the images during the time of image build only.
@@ -24,15 +23,15 @@ In case you are self-managing the Devtron Enterprise, refer to the steps mention
To install **Clair** integration, follow the steps:
-1. On the **Devtron Stack Manager > Discover** page, click the **Vulnerability Scanning (Clair)**.
+1. On the **Devtron Stack Manager** → **Discover** page, click the **Vulnerability Scanning (Clair)**.
2. On the **Discover Integrations/Vulnerability Scanning (Clair)** page, click **Install**.
-{% embed url="https://www.youtube.com/watch?v=gyrhIhJA9VM" caption="Installing Clair in OSS" %}
+
**Note:** In case, **Trivy** is already installed, you also need to enable **Clair** integration after installation.
-{% embed url="https://www.youtube.com/watch?v=tyvbulE-RMU" caption="Enabling Clair in OSS" %}
+
The installation status may be one of the following:
@@ -45,7 +44,7 @@ The installation status may be one of the following:
| `Installed` | The integration is successfully installed and available on the **Installed** page. |
| `Request timed out` | The request to install has hit the maximum number of retries. You may retry the installation or [contact support](https://discord.devtron.ai/) for further assistance. |
-> A list of installed integrations can be viewed on the **Devtron Stack Manager > Installed** page.
+> A list of installed integrations can be viewed on the **Devtron Stack Manager** → **Installed** page.
To update an installed integration, please [update Devtron](../../../setup/upgrade/upgrade-devtron-ui.md).
@@ -56,4 +55,4 @@ To update an installed integration, please [update Devtron](../../../setup/upgra
* If you set security policies to `block`, it blocks the deployment of the application.
* Ability to define hierarchical security policy (Global / Cluster / Environment / Application) to allow / block vulnerabilities based on criticality (High / Moderate / Low).
* Compares the vulnerabilities against a whitelist.
-* Shows security vulnerabilities detected in the deployed applications.
+* Shows security vulnerabilities detected in the deployed applications.
\ No newline at end of file
diff --git a/docs/user-guide/integrations/vulnerability-scanning/trivy.md b/docs/user-guide/integrations/vulnerability-scanning/trivy.md
old mode 100644
new mode 100755
index ff02c64112..62034acba6
--- a/docs/user-guide/integrations/vulnerability-scanning/trivy.md
+++ b/docs/user-guide/integrations/vulnerability-scanning/trivy.md
@@ -1,11 +1,10 @@
# Security Integration (Trivy)
- {% hint style="warning" %}
- ### Prerequisite
+ :::caution Prerequisite
**For OSS users**: Please ensure that [Build and Deploy (CI/CD)](../../integrations/build-and-deploy-ci-cd.md) integration is installed.
**For Enterprise Users**: **Build and Deploy (CI/CD)** integration is installed by default.
- {% endhint %}
+ :::
Trivy integration enables you to scan the vulnerabilities for images, code, and manifests during the execution of build and deployment pipelines. Refer to [Vulnerability Scanning](./README.md) to know more about **Trivy**.
@@ -26,11 +25,11 @@ To install **Trivy** integration, follow the steps:
2. On the **Discover Integrations/Vulnerability Scanning (Trivy)** page, click **Install**.
-{% embed url="https://www.youtube.com/watch?v=KMx4Xv-NSzw" caption="Installing Trivy in OSS" %}
+
**Note:** In case, **Clair** is already installed, you also need to enable **Trivy** integration after installation.
-{% embed url="https://www.youtube.com/watch?v=UJlaGEj9dSc" caption="Enabling Trivy in OSS" %}
+
The installation status may be one of the following:
@@ -43,7 +42,7 @@ The installation status may be one of the following:
| `Installed` | The integration is successfully installed and available on the **Installed** page. |
| `Request timed out` | The request to install has hit the maximum number of retries. You may retry the installation or [contact support](https://discord.devtron.ai/) for further assistance. |
-> A list of installed integrations can be viewed on the **Devtron Stack Manager > Installed** page.
+> A list of installed integrations can be viewed on the **Devtron Stack Manager** → **Installed** page.
To update an installed integration, please [update Devtron](../../../setup/upgrade/upgrade-devtron-ui.md).
@@ -57,13 +56,13 @@ Trivy can provide 3 types of scans based on the type of the application, i.e., I
| Type of scan | Description |
| :--- |:---|
-| `Image Scan` | Scans build images for
Vulnerabilities
License Risks
|
-| `Manifest Scan` | Scans Kubernetes [manifests](../../../reference/glossary.md#manifest) to identify
Misconfigurations
Exposed Secrets
|
-| `Code Scan`
(requires **Code Scan** Plugin)| The **Code Scan** plugin of Devtron uses Trivy to scan your source code for
Vulnerabilities
License Risks
Misconfigurations
Exposed Secrets
|
+| `Image Scan` | Scans build images for
Vulnerabilities
License Risks
|
+| `Manifest Scan` | Scans Kubernetes [manifests](../../../reference/glossary.md#manifest) to identify
Misconfigurations
Exposed Secrets
|
+| `Code Scan`
(requires **Code Scan** Plugin)| The **Code Scan** plugin of Devtron uses Trivy to scan your source code for
Vulnerabilities
License Risks
Misconfigurations
Exposed Secrets
|
Refer to the table below to see which type of scans are supported across different application types in Devtron.
-| Application Type | Image Scan | Code Scan (Requires Plugin) | Manifest Scan |
+| Application Type | Image Scan | Code Scan (Requires Plugin) | Manifest Scan |
| :--- |:--- | :--- | :--- |
| `Devtron Apps` | ✅ | ✅ | ✅ |
| `Helm Apps` | ✅ | **Not Applicable** | ✅ |
@@ -84,18 +83,18 @@ Refer to the table below to see which type of scans are supported across differe
### Enable 'Scan for vulnerabilities' option
- {% hint style="warning" %}
- ### Who Can Perform This Action?
+ :::caution Who Can Perform This Action?
Users need to have Admin permission or above (along with access to the environment and application) to enable the **Scan for vulnerabilities** option.
- {% endhint %}
+ :::
- Devtron's CI pipeline provides a [**Scan for vulnerabilities**](../../creating-application/workflow/ci-pipeline.md#scan-for-vulnerabilities) option as shown below. Once you enable this option, it will automatically scan the image and Kubernetes manifests for vulnerabilities.
+ Devtron's CI pipeline provides a **Scan for vulnerabilities** option as shown below. Once you enable this option, it will automatically scan the image and Kubernetes manifests for vulnerabilities.
Follow the steps below to enable the **Scan for vulnerabilities** option.
- 
+ 
+
Figure 1: Scan for vulnerabilities
- 1. Navigate to **Configurations** → **Workflow Editor** of your Devtron App.
+ 1. Navigate to **Configurations** (tab) → **Workflow Editor** of your Devtron App.
2. Select the specific build pipeline for which you want to enable scanning, and a **Edit deployment pipeline** modal window will appear.
@@ -109,18 +108,18 @@ Refer to the table below to see which type of scans are supported across differe
* After the build image (artifact) is deployed, you can also access the scan results from the **App Details** page. Refer to the [Accessing the scan results](#accessing-the-scans-results) section to learn more.
-{% hint style="info" %}
- After deploying your application, scan results are also available in the Security section under **Security Scans**.
+:::info
+After deploying your application, scan results are also available in the Security section under **Security Scans**.
Refer [Security Features](../../security-features.md) to know more.
-{% endhint %}
+:::
-### Enable Code Scan Plugin [](https://devtron.ai/pricing)
+### Enable Code Scan Plugin
To enable code scan for **Devtron Apps**, you can configure the code scan plugin as a pre-build task in your **Devtron App**
To configure **Code Scan** as a pre-build task, follow the steps below:
- 1. Navigate to **Configurations** → **Workflow Editor** of your Devtron App.
+ 1. Navigate to **Configurations** (tab) → **Workflow Editor** of your Devtron App.
2. Select the specific build pipeline for which you want to enable scanning, and a **Edit deployment pipeline** modal window will appear.
@@ -130,7 +129,7 @@ To configure **Code Scan** as a pre-build task, follow the steps below:
5. Select **Update Pipeline** and the code scan plugin is now configured and will scan the code when the next build is triggered.
- {% embed url="https://www.youtube.com/watch?v=WvC_zmJ2MoE" caption="Enabling Code Scan" %}
+
### Accessing the scan's results
@@ -161,16 +160,15 @@ To access the scan results
You can inspect each type of scan to view the specific type of vulnerabilities that the scan supports. Refer to the video below
- {% embed url="https://www.youtube.com/watch?v=RkwdoOIlI-E" caption="Accessing Devtron Apps Scan Results in 'Security' Card" %}
+
#### K8s Resources Sub Tab
By clicking on the **Security** card you can access the Image scan results for the latest build image that is deployed, but if you want to inspect Image scan results for specific K8s resources (Deployments, ReplicaSet and Pods), then you can inspect them in **Workloads** dropdown under **K8s Resources**.
- {% hint style="info" %}
- ### Note
+ :::info Note
In case you have enabled the vulnerability scanning after the application has already been built and deployed, you can still initiate the image scan for existing Kubernetes resources.
- {% endhint %}
+ :::
To access or initiate **Image scan** results for specific resources, follow the steps below
@@ -184,7 +182,7 @@ To access the scan results
5. Select the image in the **Security** modal window to view the list of vulnerabilities.
- {% embed url="https://www.youtube.com/watch?v=0uVpfYvz3M0" caption="Accessing Devtron Apps Scan Results in K8s Resources Sub Tab" %}
+
#### From Resource Browser
@@ -196,7 +194,8 @@ To access the scan results
4. Select the **Check vulnerabilities** option from the kebab menu (⋮) to access the scan results.
- 
+ 
+
Figure 2: Scanning Workloads - Resource Browser
#### From 'Build & Deploy' Page
@@ -212,7 +211,7 @@ To access the scan results
5. Click on the scan to open a new **Security** modal window, which will display the scan results in detail.
- {% embed url="https://www.youtube.com/watch?v=nQDNtOpCXZo" caption="Accessing Devtron Apps Scan Results Before Deployments" %}
+
#### From 'Build History' Page
@@ -225,9 +224,9 @@ To access the scan results
3. Click on the specific scan to open a new **Security** modal window, which will display the scan results in detail.
- {% embed url="https://www.youtube.com/watch?v=oXKvVdnaoaI" caption="Accessing Devtron Apps Scan Results In Build History" %}
+
-## Vulnerability Scanning in Helm Apps [](https://devtron.ai/pricing)
+## Vulnerability Scanning in Helm Apps
### Where to Initiate the Scan for Helm Apps
@@ -237,7 +236,7 @@ To enable scanning for **Helm Apps**, follow the steps below:
2. Enable the **Security Scan** option to enable vulnerability scanning.
-{% embed url="https://www.youtube.com/watch?v=X1Rh5BDJ2oc" caption="Enabling Security Scan For Helm Apps" %}
+
### Accessing the scan's results
@@ -262,14 +261,13 @@ To access the scan results
You can inspect each type of scan to view the specific type of vulnerabilities that the scan supports. Refer to the video below
- {% embed url="https://www.youtube.com/watch?v=ohX0tMcGlUM" caption=" Accessing Helm Apps Scan Results In 'Security' Card" %}
+
#### K8s Resources Sub Tab
- {% hint style="info" %}
- ### Note
+ :::info Note
In case you have enabled the vulnerability scanning after the application has already been built and deployed, you can still initiate the image scan for existing Kubernetes resources.
- {% endhint %}
+ :::
To access or initiate **Image scan** for specific resources, follow the steps below
@@ -277,7 +275,7 @@ To access the scan results
2. On the right-hand side, select **Check vulnerabilities** from the kebab menu (⋮) to access security scans.
- {% embed url="https://www.youtube.com/watch?v=zsA_iaaXLaQ" caption="Accessing Helm Apps Scan Results in K8s Resources Sub Tab" %}
+
#### From 'Deployment History' Page
@@ -291,9 +289,9 @@ To access the scan results
3. Click on the specific scan to open a new **Security** modal window, which will display the scan results in detail.
- {% embed url="https://www.youtube.com/watch?v=iOKdzJzlzF4" caption="Accessing Helm Apps Scan Results in Deployment History" %}
+
-## ArgoCD and FluxCD Apps [](https://devtron.ai/pricing)
+## ArgoCD and FluxCD Apps
### Where to Initiate the Scan for Helm Apps
@@ -317,10 +315,9 @@ To access the scan results
#### K8s Resources Sub Tab
- {% hint style="info" %}
- ### Note
+ :::info Note
In case you have enabled the vulnerability scanning after the application has already been built and deployed, you can still initiate the image scan for existing Kubernetes resources.
- {% endhint %}
+ :::
To access or initiate **Image scan** for specific resources, follow the steps below
@@ -328,7 +325,7 @@ To access the scan results
2. On the right-hand side, select **Check vulnerabilities** from the kebab menu (⋮) to access security scans.
- {% embed url="https://www.youtube.com/watch?v=0ANzcJaviYc" caption="Accessing Devtron Apps Scan Results Before Deployments" %}
+
## Security Policies
diff --git a/docs/user-guide/jobs/README.md b/docs/user-guide/jobs/README.md
old mode 100644
new mode 100755
index 4b7e605551..ba36cd65b9
--- a/docs/user-guide/jobs/README.md
+++ b/docs/user-guide/jobs/README.md
@@ -1,30 +1,22 @@
+---
+hide_table_of_contents: true
+---
+
# Jobs
Devtron Jobs provides a streamlined way to execute specific tasks or a set of tasks defined by the user within the user's application environment.
-To learn more about how Jobs work, see the sections below
-
+To learn more about how Jobs work, see the sections below:
* [What is Jobs](./what-is-job.md)
-
* [Creating a Job](./create-job.md)
-
* [Configurations](./configurations/README.md)
-
* [Source Code](./configurations/source-code-job.md)
-
* [Workflow Editor](./configurations/workflow-editor-job.md)
-
* [ConfigMaps & Secrets](./configurations/configmap-secret/README.md)
-
* [ConfigMaps](./configurations/configmap-secret/configmap-job.md)
-
* [Secrets](./configurations/configmap-secret/secret-job.md)
-
* [Environments Override](./configurations/environment-override-job.md)
-
* [Trigger Job ](./triggering-job.md)
-
* [Run History](./run-history-job.md)
-
-* [Job Overview](./overview-job.md)
+* [Job Overview](./overview-job.md)
\ No newline at end of file
diff --git a/docs/user-guide/jobs/configurations/README.md b/docs/user-guide/jobs/configurations/README.md
old mode 100644
new mode 100755
index 564a7d9556..9d451a0bf5
--- a/docs/user-guide/jobs/configurations/README.md
+++ b/docs/user-guide/jobs/configurations/README.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Configurations
After you have created a Job, the next step is to configure the job. This means specifying the source code and using the Workflow Editor to create and configure the job pipeline, which includes defining tasks such as code scanning, vulnerability checks, or data migrations, and configuring the sequence in which these tasks should be executed.
@@ -8,4 +12,4 @@ In the following sections, we will explore how you can configure your Job, which
2. Creating and configuring the job pipeline through [Workflow Editor](./workflow-editor-job.md).
-3. Defining [ConfigMaps](./configmap-secret/configmap-job.md) & [Secrets](./configmap-secret/secret-job.md), and [Environment Overrides](./environment-override-job.md) for the job.
+3. Defining [ConfigMaps](./configmap-secret/configmap-job.md) & [Secrets](./configmap-secret/secret-job.md), and [Environment Overrides](./environment-override-job.md) for the job.
\ No newline at end of file
diff --git a/docs/user-guide/jobs/configurations/configmap-secret/README.md b/docs/user-guide/jobs/configurations/configmap-secret/README.md
old mode 100644
new mode 100755
index 6b218b6c19..632d701c40
--- a/docs/user-guide/jobs/configurations/configmap-secret/README.md
+++ b/docs/user-guide/jobs/configurations/configmap-secret/README.md
@@ -12,4 +12,4 @@ To configure a ConfigMap for your job pipeline, refer to the [ConfigMaps](./conf
Secrets and ConfigMaps are both used to store configurations, but there is one major difference between them: ConfigMaps store key-values in normal text format, whereas secrets store them in base64 encrypted form. Devtron hides the data of secrets for the normal users, and it is only visible to the users having edit permission.
-To configure a Secret for your job pipeline, refer to the [Secrets](./secret-job.md) section.
+To configure a Secret for your job pipeline, refer to the [Secrets](./secret-job.md) section.
\ No newline at end of file
diff --git a/docs/user-guide/jobs/configurations/configmap-secret/configmap-job.md b/docs/user-guide/jobs/configurations/configmap-secret/configmap-job.md
old mode 100644
new mode 100755
index f5363c32d3..2d25241882
--- a/docs/user-guide/jobs/configurations/configmap-secret/configmap-job.md
+++ b/docs/user-guide/jobs/configurations/configmap-secret/configmap-job.md
@@ -6,25 +6,27 @@ A ConfigMap stores key-value pairs that your jobs can use as environment variabl
## Add ConfigMap
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../../../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
-1. Go to **Configurations** → **ConfigMaps & Secrets**.
+1. Go to **Configurations** (tab) → **ConfigMaps & Secrets**.
- 
+ 
+
Figure 1: ConfigMaps & Secrets
2. Click the **+** button next to **ConfigMaps**.
- 
+ 
+
Figure 2: Creating ConfigMap
3. Enter a name for the ConfigMap (Once defined, the name cannot be changed later).
**Note**: In case you are using an External Kubernetes ConfigMap, the name should be exactly the same as the name given using the `kubectl create configmap ` command.
- 
+ 
+
Figure 3: Entering ConfigMap Name
4. **Data Type** - Choose between the following data types:
@@ -32,15 +34,17 @@ Refer the [User permissions](../../../global-configurations/authorization/user-a
* **Kubernetes External ConfigMap**: Select the Data Type as Kubernetes External ConfigMap if you have already created a ConfigMap using the kubectl command and want to use that in Devtron.
- 
+ 
+
Figure 4: ConfigMap Data Type
-5. After selecting the data type, you can choose how to mount the data of your ConfigMap. Devtron allows you to mount ConfigMap Data in the following ways:
**Mount data as** - Select how you want to mount the ConfigMap:
+5. After selecting the data type, you can choose how to mount the data of your ConfigMap. Devtron allows you to mount ConfigMap Data in the following ways:
**Mount data as** - Select how you want to mount the ConfigMap:
* [**Environment Variable**](#mount-data-as-environment-variables) – Select this option if you want to inject Environment Variables in pods using ConfigMap.
* [**Data Volume**](#mount-data-as-data-volume) – Select this option if you want to configure a Data Volume that is accessible to Containers running in a pod and provide a Volume mount path. Go to [Data Volume](#mount-data-as-data-volume) to know more.
- 
+ 
+
Figure 5: Mounting Data as
6. Select **Save** to create a ConfigMap.
@@ -50,33 +54,38 @@ This will pass your ConfigMap data into your Job pod as environment variables, t
#### For Kubernetes ConfigMap
-If you have selected Data type as `Kubernetes ConfigMap` and mount data as `Environment Variable`, then you also need to enter the required data (key-value pairs) in the **Data** field
Enter data in:
+If you have selected Data type as `Kubernetes ConfigMap` and mount data as `Environment Variable`, then you also need to enter the required data (key-value pairs) in the **Data** field
Enter data in:
* **GUI mode** – User-friendly interface. Click the **+Add** button and enter the **Key** and **Value** fields without quotes.
-
+
+
Figure 6: Entering Data in 'GUI' Mode
* **YAML mode** – Raw YAML for entering key-value pairs in the format **`key: value`**. Boolean and numeric values must be wrapped in double quotes.
-
+
+
Figure 7: Entering Data in 'YAML' Mode
#### For Kubernetes External ConfigMap
If you have selected Data type as `Kubernetes External ConfigMap`, then no data is required, as devtron will fetch the external ConfigMap data and use it to create a ConfigMap.
-
+
+
Figure 8: Kubernetes External ConfigMap for 'Environment Variable'
### Mount Data as Data Volume
This option allows you to create a ConfigMap by passing the content of a file. The content could be plain text, json, yaml, bash script, etc.
-
+
+
Figure 9: Mounting Data as Data Volume
### Volume Mount Path
Enter the folder path where the data volume should be mounted for it to be accessible to the containers running in a pod. Your keys will be mounted as files to that volume.
-
+
+
Figure 10: Volume Mount Path
### Set Sub Path
@@ -86,19 +95,20 @@ When mounting multiple files to the same location, you can use the **Set Sub Pat
* If **Set Sub Path** is disabled (unchecked), the system will delete any files already present in the [specified path](#volume-mount-path) and then mount the new files.
-
+
+
Figure 11: Setting Sub Path
-{% hint style="info" %}
-### Note
+:::info Note
In case of Kubernetes ConfigMap, all keys will be mounted as files on the specified path.
In case of Kubernetes External ConfigMap, manually specify the keys that should be mounted as files.
-{% endhint %}
+:::
### Set File Permission
The **Set File Permission** option applies permissions at the ConfigMap level, not to individual keys within the ConfigMap. Enabling this option will let you enter a 3-digit standard permission value to control access to the file.
-
+
+
Figure 12: Setting File Permission
The 3-digit numeric value represents the permission settings for the file:
@@ -129,27 +139,29 @@ Enter data in:
* **GUI mode** – User-friendly interface. Click the **+Add** button and enter the **Key** and **Value** fields without quotes.
-
+
+
Figure 13: Entering Data in 'GUI' Mode
* **YAML mode** – Raw YAML for entering key-value pairs in the format **`key: value`**. Boolean and numeric values must be wrapped in double quotes.
-
+
+
Figure 14: Entering Data in 'YAML' Mode
#### For Kubernetes External ConfigMap
If you have selected Data type as `Kubernetes External ConfigMap`, then no data is required as devtron will fetch the external ConfigMap along with any volumes attach with it and use it to create a ConfigMap.
-
+
+
Figure 15: Kubernetes External ConfigMap for 'Data Volume'
---
## Update ConfigMap
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../../../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
1. Click your ConfigMap available inside the list of **ConfigMaps** inside **ConfigMaps & Secrets**.
@@ -157,22 +169,21 @@ Refer the [User permissions](../../../global-configurations/authorization/user-a
3. Click **Save Changes**.
-
+
+
Figure 16: Updating ConfigMap
-{% hint style="warning" %}
-### Note
+:::caution Note
You cannot change the name of a ConfigMap. Create a new ConfigMap instead.
-{% endhint %}
+:::
---
## Delete ConfigMap
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../../../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
You may delete a ConfigMap if not in use anymore. Once a ConfigMap is deleted, it will not be used in future deployments.
@@ -184,7 +195,8 @@ You may delete a ConfigMap if not in use anymore. Once a ConfigMap is deleted, i
4. Confirm the deletion in the dialog box.
-
+
+
Figure 17: Deleting ConfigMap
---
@@ -194,4 +206,4 @@ After configuring ConfigMaps
* Refer the [Environment Override](../environment-override-job.md) section to configure Environment Overrides.
-* Refer the [Trigger Job](../../triggering-job.md) section to trigger the job-pipeline.
+* Refer the [Trigger Job](../../triggering-job.md) section to trigger the job-pipeline.
\ No newline at end of file
diff --git a/docs/user-guide/jobs/configurations/configmap-secret/secret-job.md b/docs/user-guide/jobs/configurations/configmap-secret/secret-job.md
old mode 100644
new mode 100755
index 1bda8599fd..7913e14621
--- a/docs/user-guide/jobs/configurations/configmap-secret/secret-job.md
+++ b/docs/user-guide/jobs/configurations/configmap-secret/secret-job.md
@@ -8,47 +8,51 @@ Secret objects let you store and manage sensitive information, such as passwords
## Add Secret
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../../../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
-1. Go to the **Configurations** → **Base Configurations**.
+1. Go to the **Configurations** (tab) → **Base Configurations**.
- 
+ 
+
Figure 1: ConfigMaps & Secrets
2. Click the **+** button next to **Secrets**.
- 
+ 
+
Figure 2: Creating Secret
3. Enter a name for the Secret (Once defined, the name cannot be changed later).
**Note:** In case you are mounting an existing Kubernetes Secret, the name should be exactly the same as the name given using the `kubectl create secret ` command.
- 
+ 
+
Figure 3: Entering Secret Name
4. **Data Type** - Choose between the following data types:
* **Kubernetes Secret**: Select the Data Type as Kubernetes Secret, if you wish to create and use the Secret using Devtron.
- * **Mount Existing Kubernetes Secret**: Select the Data Type as Existing Kubernetes Secret if you have already created a Secret using the kubectl command and want to use that in Devtron.
+ * **Mount Existing Kubernetes Secret**: Select the Data Type as Existing Kubernetes Secret if you have already created a Secret using the kubectl command and want to use that in Devtron.
* **External Secret Operator (ESO)**: External Secrets Operator (ESO) is a Kubernetes component that integrates with external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, and more. It retrieves secrets from these external sources and injects them into Kubernetes Secrets automatically.
**Note:** `external-secrets` helm chart should be installed before setting up ESO; otherwise, the External Secret Operator (ESO) will not appear. Refer to the [External Secret Operator (ESO)](#external-secret-operator-eso) section to set up ESO
- 
+ 
+
Figure 4: Secret Data Type
**Note**: Devtron automatically converts secrets from various data types to Kubernetes Secrets. Regardless of the original data type, once the conversion is complete, the Pods can access the secrets in the same way as native Kubernetes Secrets.
-5. After selecting the data type, you can choose how to mount the data of your Secret. Devtron allows you to mount Secret data in the following ways:
**Mount data as** - Select how you want to mount the Secret:
+5. After selecting the data type, you can choose how to mount the data of your Secret. Devtron allows you to mount Secret data in the following ways:
**Mount data as** - Select how you want to mount the Secret:
* [**Environment Variable**](#mount-data-as-environment-variables) – Select this option if you want to inject Secret data(key-value pairs) as Environment Variables in pods using Secret.
* [**Data Volume**](#mount-data-as-data-volume) – Select this option if you want to configure a Data Volume that is accessible to Containers running in a pod and provide a Volume mount path. Go to [Data Volume](#mount-data-as-data-volume) to know more.
- 
+ 
+
Figure 5: Mount Data as
6. Select **Save** to create a Secret.
@@ -58,15 +62,17 @@ This will pass your secret data into your Job pod as environment variables, thus
#### For Kubernetes Secret
-If you have selected Data type as `Kubernetes Secret` and mount data as `Environment Variable`, then you also need to enter the required data (key-value pairs) in the **Data** field
Enter data in:
+If you have selected Data type as `Kubernetes Secret` and mount data as `Environment Variable`, then you also need to enter the required data (key-value pairs) in the **Data** field
Enter data in:
* **GUI mode** – User-friendly interface. Click the **+Add** button and enter the **Key** and **Value** fields without quotes.
- 
+ 
+
Figure 6: Entering Data in 'GUI' Mode
* **YAML mode** – Raw YAML for entering key-value pairs in the format **`key: value`**. Boolean and numeric values must be wrapped in double quotes.
- 
+ 
+
Figure 7: Entering Data in 'YAML' Mode
### Mount Existing Kubernetes Secrets
@@ -74,41 +80,45 @@ This option allows you to mount an existing Kubernetes Secret in your job pods.
If you have selected Data type as `Mount Existing Kubernetes Secrets`, then no data is required, as Devtron will fetch the existing Secret data and use it to create a Secret.
-
+
+
Figure 8: Mounting Existing Kubernetes Secrets for 'Environment Variable'
### Mount Data as Data Volume
This option allows you to create a Secret by passing the content of a file. The content could be plain text, JSON, YAML, bash script, etc.
-
+
+
Figure 9: Mounting Data as Data Volume
### Volume Mount Path
Enter the folder path where the data volume should be mounted for it to be accessible to the containers running in a pod. Your keys will be mounted as files to that volume.
-
+
+
Figure 10: Volume Mount Path
### Set Sub Path
When mounting multiple files to the same location, you can use the **Set Sub Path** option to control how the files are handled. This setting allows you to control whether existing files are overwritten or preserved when mounting new files.
-
+
+
Figure 11: Setting Sub Path
* If **Set Sub Path** is enabled, the system will preserve existing files in the [specified path](#volume-mount-path) and append the new file using the file name as a sub-path.
* If **Set Sub Path** is disabled (unchecked), the system will delete any files already present in the [specified path](#volume-mount-path) and then mount the new files.
-{% hint style="info" %}
- ### Note
+:::info Note
In case of Kubernetes Secrets, all keys will be mounted as files on the specified path.
In case of External Secrets, manually specify the keys that should be mounted as files.
-{% endhint %}
+:::
### Set File Permission
The **Set File Permission** option applies permissions at the Secret level, not to its individual secret keys. Enabling this option will let you enter a 3-digit standard permission value to control access to the file.
-
+
+
Figure 12: Setting File Permission
The 3-digit numeric value represents the permission settings for the file:
@@ -138,27 +148,29 @@ Enter data in:
* **GUI mode** – User-friendly interface. Click the **+Add** button and enter the **Key** and **Value** fields without quotes.
- 
+ 
+
Figure 13: Entering Data in 'GUI' Mode
* **YAML mode** – Raw YAML for entering key-value pairs in the format **`key: value`**. Boolean and numeric values must be wrapped in double quotes.
- 
+ 
+
Figure 14: Entering Data in 'YAML' Mode
#### For Mount Existing Kubernetes Secrets
-This option allows you to mount an existing Kubernetes Secret in your job pods as data volumes. A Secret will not be created by the system, so please ensure that the secret with the same name already exists within the namespace. Otherwise, the deployment will fail.
If you have selected Data type as `Mount Existing Kubernetes Secrets`, then no data is required as Devtron will fetch the existing Secret data and use it to create a Secret.
+This option allows you to mount an existing Kubernetes Secret in your job pods as data volumes. A Secret will not be created by the system, so please ensure that the secret with the same name already exists within the namespace. Otherwise, the deployment will fail.
If you have selected Data type as `Mount Existing Kubernetes Secrets`, then no data is required as Devtron will fetch the existing Secret data and use it to create a Secret.
-
+
+
Figure 15: Mounting Existing Kubernetes Secrets for 'Data Volume'
---
## Update Secret
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../../../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
1. Click your Secret available inside the list of **Secrets** inside **ConfigMaps & Secrets**.
@@ -166,22 +178,21 @@ Refer the [User permissions](../../../global-configurations/authorization/user-a
3. Click **Save Changes**.
-
+
+
Figure 16: Updating Secret
-{% hint style="warning" %}
-### Note
+:::caution Note
You cannot change the name of a Secret. Create a new Secret instead.
-{% endhint %}
+:::
---
## Delete Secret
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../../../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
You may delete a Secret if not in use anymore. Once a Secret is deleted, it will not be used in future deployments.
@@ -193,16 +204,16 @@ You may delete a Secret if not in use anymore. Once a Secret is deleted, it will
4. Confirm the deletion in the dialog box.
-
+
+
Figure 17: Deleting Secret
---
## External Secret Operator (ESO)
-{% hint style="info" %}
-### Prerequisite
+:::info Prerequisite
Chart version should be > 4.14.0
-{% endhint %}
+:::
### Purpose
@@ -216,22 +227,31 @@ External Secrets Operator (ESO) is a Kubernetes component that integrates with e
### Installation Steps
-1. Go to the **Chart Store**.
+1. Go to the **Infrastructure Management** → **Chart Store**.
+
+ 
+
Figure 18: Searching External Secrets Chart
2. Search for the `external-secrets` chart.
- 
+ 
+
Figure 19: Searching External Secrets Chart
-{% hint style="info" %}
-### What if the external-secrets chart is not found?
+:::info What if the external-secrets chart is not found?
Manually add the following chart repository URL in Devtron: `https://charts.external-secrets.io`. Follow this [guide](../../../global-configurations/chart-repo.md#add-chart-repository) to know the steps.
-{% endhint %}
+:::
+
+3. A page displaying the complete information for the `external-secrets` chart will open. Click **Deploy Chart**.
+
+ 
+
Figure 20: Information Page
-3. Give a name to the helm app that will be created from the chart. Also, enter the project and environment where you wish to install the chart.
+4. Give a name to the helm app that will be created from the chart. Also, enter the project and environment where you wish to install the chart.
- 
+ 
+
Figure 21: Adding Details
-4. Click **Deploy Chart**.
+4. Click **Deploy**.
After deploying the Chart, refer to the [ESO Documentation](/docs/user-guide/creating-application/base-config/eso/README.md) to setup ESO for different providers.
@@ -243,4 +263,4 @@ After configuring Secrets
* Refer the [Environment Override](../environment-override-job.md) section to configure Environment Overrides.
-* Refer the [Trigger Job](../../triggering-job.md) section to trigger the job-pipeline.
+* Refer the [Trigger Job](../../triggering-job.md) section to trigger the job-pipeline.
\ No newline at end of file
diff --git a/docs/user-guide/jobs/configurations/environment-override-job.md b/docs/user-guide/jobs/configurations/environment-override-job.md
old mode 100644
new mode 100755
index 034ef638b1..d7f6bdf174
--- a/docs/user-guide/jobs/configurations/environment-override-job.md
+++ b/docs/user-guide/jobs/configurations/environment-override-job.md
@@ -12,23 +12,25 @@ The Environment Overrides section allows you to customize the **ConfigMaps**, an
## Environment Configurations Page
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
-1. In your job, go to **Configurations** → **Environment Overrides**.
+1. In your job, go to **Configurations** (tab) → **Environment Overrides**.
- 
+ 
+
Figure 1: Environment Override
2. Click **Add Environment** and select an environment from the dropdown for which you want your configurations to be modified.
- 
+ 
+
Figure 2: Adding Environment
3. The environment will be added under **Environment Override**. If you wish, you can add more environments by clicking **Add Environment**.
- 
+ 
+
Figure 3: Selecting Environment
4. Click on the environment you have added under **Environment Override**, you will get the following options (similar to the **ConfigMaps & Secrets** page):
@@ -36,7 +38,8 @@ Refer the [User permissions](../../global-configurations/authorization/user-acce
* **Secrets**
- 
+ 
+
Figure 4: ConfigMaps & Secrets
5. You can now do one of the following:
@@ -54,17 +57,20 @@ If you want to have environment-specific **ConfigMaps & Secrets**, use **Environ
1. Under the selected environment, select the **ConfigMap** or **Secret** you wish to override; by default, the ConfigMap or Secret is inherited from the base configuration.
- 
+ 
+
Figure 5: Selecting ConfigMap or Secrets
2. To create Override, select the **No Override** tab and click the **Create Override** button.
- 
+ 
+
Figure 6: Creating Override
3. In the same tab (now labelled as **Override**), you can now change the configuration of your ConfigMap or Secret that will be specific to the selected environment.
**Note** Except `Name` cannot be changed for ConfigMaps & Secrets that are inherited from the base configuration.
- 
+ 
+
Figure 7: Overriding ConfigMap or Secret
4. Override the data values using [Replace](#replace-strategy) merge strategy.
@@ -92,7 +98,8 @@ To create additional ConfigMaps & Secrets, follow the given steps
1. Under the selected environment, click the `+` button next to ConfigMap or Secret.
- 
+ 
+
Figure 8: Adding ConfigMap or Secret
2. A configuration tab will open (which was previously named override) to add a new **ConfigMap** or **Secret**.
@@ -102,11 +109,13 @@ To create additional ConfigMaps & Secrets, follow the given steps
* [Add Secrets](./configmap-secret/secret-job.md)
- 
+ 
+
Figure 9: Configuring ConfigMap or Secret
3. Once created, a new ConfigMap or Secret will be added with a label `Created at environment` under its name, in the left section under ConfigMap or Secret, respectively.
- 
+ 
+
Figure 10: ConfigMap or Secret added
---
@@ -118,12 +127,14 @@ This action will discard the current overrides, and the base configuration file
2. Click **Delete Override**.
- 
+ 
+
Figure 11: Deleting Override
3. Confirm the deletion in the dialog box.
- 
+ 
+
Figure 12: Confirming Delete Override
---
-After setting up **Environment Overrides**, you can refer to the [Trigger Job](../triggering-job.md) section to trigger your job pipeline in different environments.
+After setting up **Environment Overrides**, you can refer to the [Trigger Job](../triggering-job.md) section to trigger your job pipeline in different environments.
\ No newline at end of file
diff --git a/docs/user-guide/jobs/configurations/source-code-job.md b/docs/user-guide/jobs/configurations/source-code-job.md
old mode 100644
new mode 100755
index 4dd5aa52b5..9b0aa2e9ee
--- a/docs/user-guide/jobs/configurations/source-code-job.md
+++ b/docs/user-guide/jobs/configurations/source-code-job.md
@@ -2,11 +2,10 @@
In Devtron, the Source Code configuration is used to specify the repository that contains your scripts, Terraform files, YAML configurations, or other resources. The repository acts as a central location for these files, allowing you to reference and execute them in your job without needing to rewrite the scripts in the Workflow Editor each time.
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
To configure the Source Code, follow these steps:
@@ -14,21 +13,25 @@ To configure the Source Code, follow these steps:
2. Select the **Source Code** tab from the left sidebar.
- 
+ 
+
Figure 1: Selecting Source Code
3. Under **Add Git Repository**, select the **Git Account** from the dropdown menu. You can also select `GitHub Public` from the same dropdown to configure a public repository that does not require authentication.
- 
+ 
+
Figure 2: Adding Git Account
4. Enter the **Repository URL** in the Git Repo `URL` field, corresponding to the selected Git account. If `GitHub Public` is selected, you can enter the URL of any public repository, as no authentication is required.
- 
+ 
+
Figure 3: Adding Git Repository
5. Configure the [Additional Options](#configure-additional-options-optional) for the job as per your requirements.
6. Click on the **Save** button to save the changes.
- 
+ 
+
Figure 4: Saving Source Code
---
@@ -46,14 +49,15 @@ To define the exclusion or inclusion rules, follow these steps:
1. Check the **Exclude specific file/folder in this repo** checkbox.
- 
+ 
+
Figure 5: Excluding Specific File/Folder
2. Enter the exclusion or inclusion rules in the **Enter file or folder paths to be included or excluded** field.
| Sample Rules | Description | Impact on Commits |
|:---|:---|:---|
| `!README.md` | **Exclusion of a single file in root folder** | Commits containing changes made only in the README.md file will not be shown |
- | `!README.md` `!index.js` | **Exclusion of multiple files in root folder** | Commits containing changes made only in README.md or/and index.js files will not be shown |
+ | `!README.md` `!index.js` | **Exclusion of multiple files in root folder** | Commits containing changes made only in README.md or/and index.js files will not be shown |
| `README.md` | **Inclusion of a single file in root folder** | Commits containing changes made only in the README.md file will be shown. Rest all will be excluded. |
| `!src/extensions/printer/code2.py` | **Exclusion of a single file in a folder tree** |Commits containing changes made specifically to code2.py file will not be shown |
| `!src/*` | **Exclusion of a single folder and all its files:** |Commits containing changes made specifically to files within the `src` folder will not be shown |
@@ -63,11 +67,13 @@ To define the exclusion or inclusion rules, follow these steps:
You may use the **Learn how** link (as shown below) to understand the syntax of defining an exclusion or inclusion rule.
- 
+ 
+
Figure 6: 'Learn how' Button
Since file paths can be long, Devtron supports regex too for writing the paths. To understand it better, you may click the **How to use** link as shown below.
- 
+ 
+
Figure 7: Regex Support
### Set Checkout Path
@@ -86,7 +92,8 @@ To set the checkout path, follow these steps:
|`./src`|Checkout the repository to the src folder|
|`./src/app`|Checkout the repository to the app folder inside the src folder|
- 
+ 
+
Figure 8: Checkout Path
### Pull Submodules Recursively
@@ -94,10 +101,11 @@ This checkbox is used for pulling [git submodules](https://git-scm.com/book/en/v
To pull the submodules recursively, check the **Pull submodules recursively** checkbox.
-
+
+
Figure 9: Pulling Submodules Recursively
---
After configuring **Source Code**, the next step is to create and configure job pipelines.
-Refer to the [Workflow editor](./workflow-editor-job.md) section to create and configure job pipelines.
+Refer to the [Workflow editor](./workflow-editor-job.md) section to create and configure job pipelines.
\ No newline at end of file
diff --git a/docs/user-guide/jobs/configurations/workflow-editor-job.md b/docs/user-guide/jobs/configurations/workflow-editor-job.md
old mode 100644
new mode 100755
index 7378aef67d..462266e154
--- a/docs/user-guide/jobs/configurations/workflow-editor-job.md
+++ b/docs/user-guide/jobs/configurations/workflow-editor-job.md
@@ -7,29 +7,33 @@ It provides a visual interface to create and configure job pipelines, define bas
To create and configure the Job Pipeline, follow the steps below:
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
1. Navigate to the **Workflow Editor** in the left sidebar of the **Configurations** page.
- 
+ 
+
Figure 1: Selecting Workflow Editor
2. Click **+ Job Pipeline** to create a new Job workflow. A pop-up **Create job workflow** will appear, asking you to enter a name for your Job workflow.
- 
+ 
+
Figure 2: Adding Job Workflow
3. Enter the name for your Job workflow and click on the **Create Workflow** button. A new Job workflow will be created, in which you can add a job pipeline.
- 
+ 
+
Figure 3: Entering Job Workflow Name
4. To add a job pipeline to your workflow, click anywhere in the **Add job pipeline to this workflow** area under the job workflow name. This opens the **Create job pipeline** Window in which you can create and configure your job.
- 
+ 
+
---
@@ -47,7 +51,8 @@ It includes 2 stages
This stage allows you to define primary configurations such as **Pipeline name**, **Source Type**, **Branch Name**, and how the job should be triggered. Refer to the following table to configure each field.
-
+
+
Figure 6: Configuring Job Pipeline
| Field Name|Description|
| :--- |:--- |
@@ -55,7 +60,7 @@ This stage allows you to define primary configurations such as **Pipeline name**
| `Pipeline Name` | Assign a name to your job pipeline|
| `Source type` | Source type to trigger the job pipeline. Available options: Branch Fixed, Branch Regex, Pull Request, Tag Creation|
| `Branch Name`| Branch that triggers the CI build|
-| `Use remote cache`|
Enable this option to use the Docker cache from previous builds. Docker's layer caching mechanism allows unchanged docker images layers to be reused across pipeline runs, thus drastically reducing execution times
The globe toggle, next to Docker Layer Caching means that the configuration is inherited from global
Enabled: Inherits the caching settings defined globally.
Disabled: Allows you to define a pipeline-level configuration specific to this job.
|
+| `Use remote cache`|
Enable this option to use the Docker cache from previous builds. Docker's layer caching mechanism allows unchanged docker images layers to be reused across pipeline runs, thus drastically reducing execution times
The globe toggle, next to Docker Layer Caching means that the configuration is inherited from global
Enabled: Inherits the caching settings defined globally.
Disabled: Allows you to define a pipeline-level configuration specific to this job.
|
### Tasks to be Executed
@@ -69,11 +74,13 @@ To create a task:
2. Click **Add Task** to add a task in your job pipeline.
- 
+ 
+
Figure 7: Adding Task
3. A new task will be added (on the left side of the 'Create job pipeline' window). You can configure the task either by selecting one of the available [preset plugins](#create-task-using-preset-plugins) or by [Executing a custom script](#create-task-using-custom-script)
- 
+ 
+
Figure 8: Type of Tasks
### Create Task Using Preset Plugins
@@ -93,11 +100,13 @@ To create a task using the **GKE Provisioner** plugin, follow the steps below:
* The right-side panel will display the fields specific to the **GKE Provisioner** plugin, which are required to be configured.
- 
+ 
+
Figure 9: Searching 'GKE Provisioner' Plugin
- * The left-side panel will now show a task under **Tasks (IN ORDER OF EXECUTION)**, named after the selected plugin(by default), along with its logo. You can change the task's name using the **Task name** field, but plugin's logo will remain indicating that it is a preset plugin.
+ * The left-side panel will now show a task under **Tasks (IN ORDER OF EXECUTION)**, named after the selected plugin(by default), along with its logo. You can change the task's name using the **Task name** field, but plugin's logo will remain indicating that it is a preset plugin.
- 
+ 
+
Figure 10: Gke Provisioner Plugin
4. Refer the [GKE Provisioner](/docs/user-guide/plugins/gke-provisioner.md) documentation to configure the **GKE Provisioner** fields with appropriate values. You may explore [Plugins documentation](/docs/user-guide/plugins/README.md) to configure any of the available plugins.
@@ -107,7 +116,8 @@ To create a task using the **GKE Provisioner** plugin, follow the steps below:
In Devtron, you can also define a task using a custom script to meet specific requirements. To create a task a task using a custom script, follow the steps below:
-
+
+
Figure 11: Executing Custom Task
1. After configuring the basic configurations, select the **Tasks to be executed** Tab.
@@ -146,13 +156,12 @@ Let's take an example of a **Shell task** for a job that allows you to extract a
| `Task Description`| `This task extract all the environment variables available to the job pod at runtime and saves it as a file` | Optional | Short description for the task|
| `Task Type` | `Shell`| Optional| Select the preferred task type |
| `Script`| Refer the [Script](#script) below| Required| Custom script for executing Job tasks|
-| `Output variables`| Refer to the [output variable](#output-variables) table| Optional|
Output variables store the output as variables, and these variables can be used as input variables for the next task.|
+| `Output variables`| Refer to the [output variable](#output-variables) table| Optional| Output variables store the output as variables, and these variables can be used as input variables for the next task.|
#### Script
-{% code title="Custom Script" overflow="wrap" lineNumbers="true" %}
-```bash
+```bash title="Custom Script" showLineNumbers
#!/bin/sh
set -e
@@ -168,7 +177,7 @@ ls -l "$ARTIFACT_DIR"
# Export output variable
echo "ENV_FILE=$FILE"
```
-{% endcode %}
+
#### Output Variables
@@ -190,7 +199,7 @@ Let's take an example of a **Shell task** for a job that allows you to back up a
| `Task Name`| `pg-backup-task`| Required| Enter a name for the task|
| `Task Description`| `This task performs a backup of a specific PostgreSQL database and saves it as a file, and stores the file path as an output variable.` | Optional | Short description for the task|
| `Task Type` | `Shell`| Optional| Select the preferred task type |
-| `Input variables`| Refer the [Input Variable table](#input-variable-table) below | Optional|
These variables provide dynamic values to the script at the time of execution and are defined directly in the UI.
Variable name: Alphanumeric chars and (_) only
Source or input value: The variable's value can be global, output from the previous task, or a custom value. Accepted data types include: STRING
These variables provide dynamic values to the script at the time of execution and are defined directly in the UI.
Variable name: Alphanumeric chars and (_) only
Source or input value: The variable's value can be global, output from the previous task, or a custom value. Accepted data types include: STRING
|
| `Trigger/Skip condition` | `Trigger If: DB_NAME == prod-db`| Optional| A conditional statement to execute or skip the task|
| `Script`| Refer the [Script](#script-1) below| Required| Custom script for executing Job tasks|
| `Output directory path` | `/backups`| Optional| Directory path where output files such as logs, errors, etc., will be available after the execution.|
@@ -207,22 +216,24 @@ Let's take an example of a **Shell task** for a job that allows you to back up a
* To add an input variable, click **+ Add Variable** next to the **Input Variable**, a new table appears asking you to enter the variable and its required information.
-* You can click `+` icon next to **Variable** header field to add more rows to the input variable table.
+* You can click `+` icon next to **Variable** header field to add more rows to the input variable table.
- 
+ 
+
Figure 12: Variable configuration
* You can click the slider icon next to each variable name to make its value required and add a description for it.
- 
+ 
+
Figure 13: Value configuration
* You can click the slider icon next to each variable value to add choices, allow custom input, and ask value at runtime.
- 
+ 
+
Figure 14: Adding choices
#### Script
-{% code title="Custom Script" overflow="wrap" lineNumbers="true" %}
-```bash
+```bash title="Custom Script" showLineNumbers
#!/bin/sh
set -eo pipefail
#set -v ## uncomment this to debug the script
@@ -230,14 +241,13 @@ set -eo pipefail
echo "Taking database backup"
bash ./scripts/backup.sh --db-host "$DB_HOST" --db-user "$DB_USER" --db-name "$DB_NAME" --backup-path "$BACKUP_PATH"
```
-{% endcode %}
+
In the above script, instead of writing the entire script for the backup task, we have referenced the `backup.sh` script from the Github Repository configured as Source code. This approach avoids the need to rewrite the same script again and again for each task, thus making it reusable and efficient across multiple jobs.
**backup.sh Script (Stored in Github repository)**
-{% code title="backup.sh" overflow="wrap" lineNumbers="true" %}
-```bash
+```bash title="backup.sh" showLineNumbers
#!/bin/bash
# Input variables for database connection
@@ -265,7 +275,7 @@ else
exit 1
fi
```
-{% endcode %}
+
#### Output Variables
@@ -292,7 +302,7 @@ Let's take an example of a **Container Image Task** for a job that test if a giv
| `Task name`| `check-endpoint`| Required|Enter a name for the task|
| `Description`|`Checks API endpoint`|
| `Task type`| `Container Image`| Optional| Allows you to execute commands and scripts inside a custom Docker container|
-| `Input variables`| Refer the [Input Variable table](#input-variable-table-1) below | Optional|
These variables provide dynamic values to the script and are defined directly in the UI.
Variable name: Alphanumeric chars and (_) only
Source or input value: The variable's value can be global, output from the previous task, or a custom value. Accepted data types include: STRING
These variables provide dynamic values to the script and are defined directly in the UI.
Variable name: Alphanumeric chars and (_) only
Source or input value: The variable's value can be global, output from the previous task, or a custom value. Accepted data types include: STRING
|
| `Trigger/Skip condition`| `No`| Optional| Execute or skip the task based on the condition provided.|
| `Container image`| `alpine:3.2.0`| Required| Select an image from the drop-down list or enter a custom value in the format `:`|
| `Mount custom code`| Refer below [Mount custom code](#mount-custom-code) section| Optional|
Enable to mount the custom code in the container. Enter the script in the box below.
**Mount above code at** (required): Path where the code should be mounted, i.e., `/run.sh` (for this example only)
|
@@ -311,8 +321,7 @@ Let's take an example of a **Container Image Task** for a job that test if a giv
#### Mount Custom Code
-{% code title="Custom Script" overflow="wrap" lineNumbers="true" %}
-```bash
+```bash title="Custom Script" showLineNumbers
#!/bin/sh
set -e
@@ -331,7 +340,7 @@ fi
echo "STATUS_FILE=$FILE"
```
-{% endcode %}
+
You can provide the URL at runtime, and the after the job execution completed, you can access the generated file by navigating to **Run History** → **Artifacts**.
@@ -346,7 +355,7 @@ Let's take an example of a **Container Image Task** for a job that provisions an
| `Task name`| `provision-s3-bucket`| Required|Enter a name for the task|
| `Description`| Provision an S3 bucket with Terraform| Optional| A descriptive message for the task|
| `Task type`| `Container Image`| Optional| Allows you to execute commands and scripts inside a custom Docker container|
-| `Input variables`| Refer the [Input Variable table](#input-variable-table-2) below | Optional|
These variables provide dynamic values to the script and are defined directly in the UI.
Variable name: Alphanumeric chars and (_) only
Source or input value: The variable's value can be global, output from the previous task, or a custom value. Accepted data types include: STRING
These variables provide dynamic values to the script and are defined directly in the UI.
Variable name: Alphanumeric chars and (_) only
Source or input value: The variable's value can be global, output from the previous task, or a custom value. Accepted data types include: STRING
|
| `Trigger/Skip condition`| `TF_ENV == "prod"`| Optional| Execute or skip the task based on the condition provided.|
| `Container image`| `hashicorp/terraform:1.5.0`| Required| Select an image from the drop-down list or enter a custom value in the format `:`|
| `Mount custom code`| Refer below [Mount custom code](#mount-custom-code-1) section| Optional|
Enable to mount the custom code in the container. Enter the script in the box below.
**Mount above code at** (required): Path where the code should be mounted
|
@@ -366,22 +375,24 @@ Let's take an example of a **Container Image Task** for a job that provisions an
* To add an input variable, click **+ Add Variable** next to the `Input Variable`, a new table appears asking you to enter the variable and its required information.
-* You can click `+` icon next to **Variable** header field to add more rows to the input variable table.
+* You can click `+` icon next to **Variable** header field to add more rows to the input variable table.
- 
+ 
+
Figure 15: Variable configuration
* You can click the slider icon next to each variable name to make its value required and add a description for it.
- 
+ 
+
Figure 16: Value configuration
* You can click the slider icon next to each variable value to add choices, allow custom input, and ask value at runtime.
- 
+ 
+
Figure 17: Adding choice
#### Mount Custom Code
-{% code title="Custom Script" overflow="wrap" lineNumbers="true" %}
-```bash
+```bash title="Custom Script" showLineNumbers
#!/bin/sh
set -eo pipefail
@@ -398,14 +409,13 @@ terraform apply -auto-approve \
# Capture the bucket name output
echo "S3_BUCKET_NAME=$(terraform output -raw bucket_name)"
```
-{% endcode %}
+
In the above script, instead of writing the entire Terraform script for provisioning the S3 bucket, we have stored the script `main.tf` and `variable.tf` in the Github Repository configured as Source code. By enabling `mount code to container`, the source code (configured Git Repository) is now mounted inside the container as well and available at `/sourcecode`. This approach avoids the need to rewrite the same scripts multiple times for each task, thus making the scripts reusable and efficient across multiple jobs.
**main.tf Script (Stored in Github repository)**
-{% code title="main.tf" overflow="wrap" lineNumbers="true" %}
-```bash
+```bash title="main.tf" showLineNumbers
provider "aws" {
region = var.region
}
@@ -424,12 +434,11 @@ resource "aws_s3_bucket_versioning" "this" {
}
}
```
-{% endcode %}
+
**variables.tf Script (Stored in Github repository)**
-{% code title="variables.tf" overflow="wrap" lineNumbers="true" %}
-```bash
+```bash title="variables.tf" showLineNumbers
variable "bucket_name" {
description = "The name of the S3 bucket"
type = string
@@ -440,7 +449,7 @@ variable "region" {
type = string
}
```
-{% endcode %}
+
After adding this S3 provisioner task, you can add more tasks as well, for example, you can add a task to add a bucket policy or send a notification to slack or email that s3 bucket is provisioned successfully.
@@ -448,51 +457,54 @@ After adding this S3 provisioner task, you can add more tasks as well, for examp
## Update Job Pipeline
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
You can update the configurations of an existing Job Pipeline except for the pipeline's name.
To update your job pipeline
-1. Navigate to **Configurations** → **Workflow Editor** of the specific job you want to update.
+1. Navigate to **Configurations** (tab) → **Workflow Editor** of the specific job you want to update.
2. Select the **Job pipeline** you wish to update, a **Edit job pipeline** modal window will appear.
- 
+ 
+
Figure 18: Selecting Job Pipeline
3. Change the required configurations as per your requirements and select **Update Pipeline** to update the pipeline
- 
+ 
+
Figure 19: Updating Job Pipeline
---
## Delete Job Pipeline
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
To delete a job pipeline
-1. Navigate to **Configurations** → **Workflow Editor** for the job you want to delete.
+1. Navigate to **Configurations** (tab) → **Workflow Editor** for the job you want to delete.
2. Select the **Job pipeline** you wish to delete, a **Edit job pipeline** modal window will appear.
- 
+ 
+
Figure 20: Selecting Job Pipeline
3. Select **Delete Pipeline** at the bottom left corner of the **Edit job pipeline** modal window to delete the job pipeline.
- 
+ 
+
Figure 21: Deleting Job Pipeline
4. A pop-up window will appear asking you to confirm the **Delete Pipeline** action.
- 
+ 
+
Figure 22: Confirming Delete Job Pipeline
---
-After creating the pipeline, you can configure [ConfigMaps](./configmap-secret/configmap-job.md) (optional) and [Secrets](./configmap-secret/secret-job.md) (optional) and [Environment overrides](./environment-override-job.md) (optional) before triggering it.
+After creating the pipeline, you can configure [ConfigMaps](./configmap-secret/configmap-job.md) (optional) and [Secrets](./configmap-secret/secret-job.md) (optional) and [Environment overrides](./environment-override-job.md) (optional) before triggering it.
\ No newline at end of file
diff --git a/docs/user-guide/jobs/create-job.md b/docs/user-guide/jobs/create-job.md
old mode 100644
new mode 100755
index 8c6d8f79b6..55895e310b
--- a/docs/user-guide/jobs/create-job.md
+++ b/docs/user-guide/jobs/create-job.md
@@ -1,4 +1,4 @@
-# Create Job
+# Create a New Job
In Devtron, jobs can be created in two ways:
@@ -10,23 +10,24 @@ In Devtron, jobs can be created in two ways:
## Create a Blank Job
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
To create a new **Blank Job** in Devtron, follow these steps:
-1. Navigate to **Devtron Dashboard** → **Jobs**.
+1. Navigate to **Automation & Enablement** → **Jobs**.
- 
+ 
+
Figure 1: Job's Page
2. Click **Create** button in the top-right corner and select **Job** from the drop-down list.
- 
+ 
+
Figure 2: Selecting Job
-3. The **Create Job** page opens. From the left panel, select **Blank job**, then enter the required details as listed in the table below.
+3. The **Create Job** page opens. From the left panel, select **Create from Scratch**, then enter the required details as listed in the table below.
| Fields| Description|
|:---|:---|
@@ -35,7 +36,8 @@ To create a new **Blank Job** in Devtron, follow these steps:
| `Description` | Enter the description for the job.|
| `Tags`| Key-value pairs used for identifying and organizing the application and can be propagated as Kubernetes labels. To learn more refer [Tags](#tags) section.|
- 
+ 
+
Figure 3: Creating Blank Job
4. Click **Create Job**. The job will be created, and you will be automatically redirected to the [Configurations page](/docs/user-guide/jobs/configurations/README.md) to continue setting up the job pipeline.
@@ -43,19 +45,25 @@ To create a new **Blank Job** in Devtron, follow these steps:
## Create a Clone Job
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have [Admin role](../global-configurations/authorization/user-access.md#roles-available-for-jobs) or above (along with access to the environment and applications) to perform environment override.
-{% endhint %}
+:::
To create a new **Clone Job** in Devtron, follow these steps:
1. From the Devtron Dashboard, navigate to **Jobs**.
+
2. Click the **Create** button in the top-right corner and select **Job** from the drop-down list.
- 
+ 
+
Figure 4: Selecting Job
+
+3. The **Create Job** page opens. From the left panel, select **Clone Job** and then choose a job to clone.
+
+ 
+
Figure 5: Choosing a Job to Clone
-3. The **Create Job** page opens. From the left panel, select **Clone Job**, then enter the required details as listed in the table below.
+4. Enter the required details as listed in the table below.
| Fields| Description|
|:---|:--- |
@@ -64,7 +72,8 @@ To create a new **Clone Job** in Devtron, follow these steps:
| `Description`| Enter the description of a job.|
| `Tags`| Key-value pairs used for identifying and organizing the application and can be propagated as Kubernetes labels. To learn more refer [Tags](#tags) section.|
- 
+ 
+
Figure 6: Creating Clone Job
4. Click **Create Job**. The **Clone job** will be created, and you will be automatically redirected to the [Configurations page](/docs/user-guide/jobs/configurations/README.md), where the configuration will be pre-populated based on the selected source job. You may review and modify these settings as required.
@@ -72,36 +81,40 @@ To create a new **Clone Job** in Devtron, follow these steps:
## Delete Job
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
To delete a job, you have to first delete any configured pipelines in that job workflow.
-1. Navigate to **Jobs** → **Select the job** → **Configurations** → **Workflow Editor**.
+1. Navigate to **Automation & Enablement** → **Jobs** → **Select the job** → **Configurations** → **Workflow Editor**.
2. Select the job pipeline you wish to delete, and an edit job pipeline modal window will appear.
- 
+ 
+
Figure 7: Selecting Job Pipeline
-3. Select **Delete Pipeline** at the bottom left corner of the edit job pipeline modal window to delete the job pipeline.
+3. Select **Delete Pipeline** in the bottom left corner of the edit job pipeline modal window to delete the job pipeline.
- 
+ 
+
Figure 8: Deleting Job Pipeline
4. A pop-up window will appear asking you to confirm the **Delete Pipeline** action.
- 
+ 
+
Figure 9: Confirming Delete Job Pipeline
5. After deleting any configured pipelines in a job workflow, select **Delete Job** to delete the job.
- 
+ 
+
Figure 10: Deleting Job
6. A pop-up window will appear asking you to confirm the **Delete Job** action.
- 
+ 
+
Figure 11: Confirming Delete Job
---
@@ -119,6 +132,8 @@ Tags are Key-value pairs used for identifying and organizing the application. Us
3. You can click `X` icon to delete an existing tag.
-4. You can click the **propagation icon** to propagate a tag (turns dark grey when propagated), click again to remove propagation.
+4. You can click the **propagation icon** 
+ to propagate a tag (turns dark grey when propagated), click again to remove propagation.
-
+
+
Figure 12: Tags
\ No newline at end of file
diff --git a/docs/user-guide/jobs/overview-job.md b/docs/user-guide/jobs/overview-job.md
old mode 100644
new mode 100755
index 8deefebc3d..8d5a7c4e9b
--- a/docs/user-guide/jobs/overview-job.md
+++ b/docs/user-guide/jobs/overview-job.md
@@ -1,8 +1,9 @@
# Overview
-The Overview page provides a centralized view of a job’s details within Devtron. It allows users to quickly access information about the job, manage tags, and view job pipelines — all in a single, organized interface.
+The Overview page provides a centralized view of a job’s details within Devtron. It allows users to quickly access information about the job, manage tags, and view job pipelines all in a single, organized interface.
-
+
+
Figure 1: Job's Overview
The **Overview** page contains three main sections:
@@ -22,7 +23,8 @@ The **About** section allows you to:
The left side of the **About** section displays essential information about the job.
-
+
+
Figure 2: Job's Basic Info
The table below captures all the key elements presented in this section, along with their descriptions and whether they can be edited by the user.
@@ -30,7 +32,7 @@ The table below captures all the key elements presented in this section, along w
| :--------- | :--------------- |:--------- |
| `Job Name` | No |Displays the name of the application (e.g., backend-healthcare-app).|
| `Short Description`|Yes|A short, optional description to summarize the application's purpose.|
-| `Project` |Yes|Indicates the current project under which the application is organized. You can change the project directly from this section.
Click the `Edit` icon next to the current project.
In the `Change Project` window, select the new project from the dropdown.
Click `Save`.
Changing the project will revoke access for existing users and grant access only to those who have permissions in the newly selected project.|
+| `Project` |Yes|Indicates the current project under which the application is organized. You can change the project directly from this section.
Click the `Edit` icon next to the current project.
In the `Change Project` window, select the new project from the dropdown.
Click `Save`.
Changing the project will revoke access for existing users and grant access only to those who have permissions in the newly selected project.|
| `Created on` |No|Shows the exact date and time when the application was created.|
| `Created by`|No|Displays the email address of the user who created the application.|
| `Tags` |Yes|Key-value pairs used for identifying and organizing the application and can be propagated as Kubernetes labels. To learn more refer [Tags](#tags) section.|
@@ -45,17 +47,62 @@ Tags are Key-value pairs used for identifying and organizing the application. Us
3. You can click `X` icon to delete an existing tag.
-4. You can click the **propagation icon** to propagate a tag (turns dark grey when propagated), click again to remove propagation.
+4. You can click the **propagation icon** 
+
propagation icon
to propagate a tag (turns dark grey when propagated), click again to remove propagation.
5. Click **Save**, configured Tags will reflect immediately under **Tags** in **About** Section
- 
+ 
+
Figure 3: Tags
+
+### Configure nodeSelector For Job Workloads
+
+In some cases, you want your job workloads to run only on specific nodes, such as nodes with SSDs, high memory, or isolated workloads.
+
+Devtron allows you to configure a node selector using a special tag `devtron.ai/node-selector`. This tag acts as an instruction for Devtron to apply the nodeSelector to the Pods created for your job workloads.
+
+#### Apply nodeSelector for Job Workloads
+
+Before applying the `nodeSelector`, make sure you know the label assigned to the nodes where you want your CI builds to run as this label is used as the value for the `devtron.ai/node-selector` tag.
+
+Once you have identified the label, follow the steps below to apply the `nodeSelector`:
+
+1. Navigate to your **Automation & Enablement** → **Jobs**.
+
+
+
Figure 4: Navigating To Jobs
+
+2. Select your preferred job, and navigate to **Overview** tab.
+
+3. Click the **Edit** icon next to the Tags section.
+
+
+
+
+4. Click **Save** to apply the configuration
+
### Readme
The right side of the **About** section contains a **README** area where you can maintain job-specific notes or documentation. The `Readme` supports Markdown formatting, making it easy to include formatted text, instructions, or important context related to the application.
-
+
+
Figure 7: Readme
To add or update the **Readme**:
1. Click the **Edit** button in the Readme section.
@@ -64,19 +111,21 @@ To add or update the **Readme**:
4. Preview the content using the **Preview** tab.
5. Click **Save** to update the README.
-
+
+
Figure 8: Editing Readme
-{% hint style="info" %}
- After saving, the system displays the email address of the user who last updated the README, along with the date and time. This information appears in the header of the Readme section, beside the title.
-{% endhint %}
+:::info
+After saving, the system displays the email address of the user who last updated the README, along with the date and time. This information appears in the header of the Readme section, beside the title.
+:::
-### Catalog [](https://devtron.ai/pricing)
+### Catalog
-The **Catalog** in the **About** section displays information about your job, such as Container port, Environment Variables, Arguments, Resources(CPU and RAM). This data is managed using [Devtron’s Catalog Framework](../global-configurations/catalog-framework.md).
+The **Catalog** in the **About** section displays information about your job, such as Container port, Environment Variables, Arguments, Resources(CPU and RAM). You can manage this data using the **Manage Schema** option, which defines the structure of your catalog. Refer the [Manage Schema](../global-configurations/catalog-framework.md#managing-a-schema) documentation to learn more.
-
+
+
Figure 9: Catalog
-You can use the **Catalog framework** to maintain information about your job, such as Environment Variables, Resources(CPU and RAM), service documentation, etc. This makes it easier for others to understand, manage, and use your job.
+You can use the **Catalog** to maintain information about your job, such as Environment Variables, Resources(CPU and RAM), service documentation, etc. This makes it easier for others to understand, manage, and use your job.
`Super-Admins` define a custom JSON schema that determines what fields are shown in the catalog form. This schema is specific to each resource type, such as Devtron jobs.
@@ -86,15 +135,17 @@ When you click the **Edit** icon, a form appears based on the defined schema. As
* Arguments
* Resources(CPU and RAM)
-
+
+
Figure 10: Editing Catalog
-{% hint style= "info" %}
-The structure and labels in the catalog form are entirely configurable by your platform team via JSON schema in **Catalog Framework**. Field names and sections may vary depending on how the schema was defined by your organization.
-{% endhint %}
+:::info
+The structure and labels in the catalog form are entirely configurable by your platform team via JSON schema in **Catalog**. Field names and sections may vary depending on how the schema was defined by your organization.
+:::
Once saved, this information is displayed in a readable format within the Catalog subsection and is accessible to all users who have permission to view the job.
-
+
+
Figure 11: Catalog Overview
---
@@ -109,4 +160,5 @@ The Job Pipelines section provides a detailed view of all job pipelines. For eac
| Run in environment | Displays the name of the environment in which the job is executed. |
| Last Run At| Displays how long ago the job was last triggered.|
-
+
+
Figure 12: Job Pipelines
\ No newline at end of file
diff --git a/docs/user-guide/jobs/run-history-job.md b/docs/user-guide/jobs/run-history-job.md
old mode 100644
new mode 100755
index 79bd59e3a8..b3a2622ec8
--- a/docs/user-guide/jobs/run-history-job.md
+++ b/docs/user-guide/jobs/run-history-job.md
@@ -4,21 +4,22 @@ The run history allows you to review every execution of job pipelines. Here you
## Accessing Run History for Specific Pipeline
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
Either you have just executed the job and want to inspect the live execution, or you just want to check previous executions of a job pipeline
1. Navigate to the **Run History** tab of your job, and all the executions will appear in a reverse chronological order under the pipeline name. In case you have configured multiple job pipelines within a job, you need to select the pipeline from the **Select Pipeline** dropdown in the top-left corner.
- 
+ 
+
Figure 1: Selecting Pipeline
2. Select the specific execution you want to inspect. By default, the latest execution is selected.
- 
+ 
+
Figure 2: Selecting Specific Execution
3. After selecting the execution, the right section of the page will display the details about that particular execution.
@@ -30,7 +31,8 @@ Either you have just executed the job and want to inspect the live execution, or
|`Execution succeeded`|Timestamp marking when the job finished successfully.|
|`Worker status`|Final outcome of the worker performing the job (e.g., Succeeded or Failed). On failure, the error message is also shown|
- 
+ 
+
Figure 3: Execution's details
Apart from these details, you can also inspect logs, source code, security, and download artifacts (if any).
@@ -40,7 +42,8 @@ Apart from these details, you can also inspect logs, source code, security, and
* You can expand/collapse each pipeline stage to view specific logs related to that stage. Use the `Expand/collapse all stages` button near the search bar to expand or collapse all stages at once.
* Select the fullscreen button in the bottom-right corner to view logs in fullscreen.
- 
+ 
+
Figure 4: Logs
### Source
@@ -54,7 +57,8 @@ The source tab shows which commit is from the source code (configured Git reposi
|`Author`|Name & email of the committer.|
|`Date & time`|When that commit was authored|
-
+
+
Figure 5: Source
### Artifacts
@@ -66,4 +70,4 @@ The source tab shows which commit is from the source code (configured Git reposi
---
-After inspecting the run history, you can also set up the [Job Overview](./overview-job.md) so that others can easily know more about the job.
+After inspecting the run history, you can also set up the [Job Overview](./overview-job.md) so that others can easily know more about the job.
\ No newline at end of file
diff --git a/docs/user-guide/jobs/triggering-job.md b/docs/user-guide/jobs/triggering-job.md
old mode 100644
new mode 100755
index 3f7e506344..05cd39845e
--- a/docs/user-guide/jobs/triggering-job.md
+++ b/docs/user-guide/jobs/triggering-job.md
@@ -1,41 +1,51 @@
+---
+hide_table_of_contents: true
+---
+
# Triggering Job Pipeline
After creating the job pipeline, the next step is to trigger the job pipeline. This is the step where the job will be executed in the selected environment.
To trigger the job pipeline:
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have the **Admin role** or the **Super Admin role**.
Refer the [User permissions](../global-configurations/authorization/user-access.md#roles-available-for-jobs).
-{% endhint %}
+:::
1. Navigate to the **Trigger Job** tab of your job, which lists all configured pipelines.
- 
+ 
+
Figure 1: Triggering job
2. Click **Select Material** for the job pipeline you wish to execute. A modal window will open, under the **Code-source** tab, this window lists all recent commits along with their hash, author, date, and message from your configured source repository.
- 
+ 
+
Figure 2: Selecting Material for Specific Pipeline
3. Select the commit you want to use in the job execution. You can use the search bar to filter the commit hash, and you can also click the kebab menu to reveal excluded commits. If a recent commit isn’t displayed, click the Refresh icon to reload the commit list from your Git repository.
- 
+ 
+
Figure 3: Selecting Commit
4. Select the **Parameters** tab to configure pipeline runtime inputs(if any). The Key and Type columns are read‑only; enter values for each required parameter (denoted by *). Optional parameters can be configured as needed or left blank.
- 
+ 
+
Figure 4: Configuring Runtime Parameters
5. After selecting the commit and configuring runtime parameters, pick the target environment from the **Execute job in** dropdown at the bottom.
- 
+ 
+
Figure 5: Select Environment for Job's Execution
6. Select **Run Job** to execute your pipeline.
- 
+ 
+
Figure 6: Run Job
---
After executing your pipeline, the pipeline will now be in running state, and you can monitor the pipeline execution (such as logs, source, artifacts) in [run-history](./run-history-job.md) either by navigating to **Run History** tab or by clicking `details` above the **Select Material** of the specific pipeline.
-
+
+
Figure 7: Job Status
diff --git a/docs/user-guide/jobs/what-is-job.md b/docs/user-guide/jobs/what-is-job.md
old mode 100644
new mode 100755
index 639c4afaa3..0e4385ae2b
--- a/docs/user-guide/jobs/what-is-job.md
+++ b/docs/user-guide/jobs/what-is-job.md
@@ -1,4 +1,8 @@
-# What is Jobs?
+---
+hide_table_of_contents: true
+---
+
+# What is Job?
Devtron Jobs provides a streamlined way to execute specific tasks or a set of tasks defined by the user within the user's application environment.
@@ -16,4 +20,4 @@ Jobs can be configured to run as:
Devtron Jobs supports executing custom tasks or predefined operations using integrated pipeline plugins. These plugins extend job functionality by enabling tasks such as code scanning, image signing, vulnerability patching, container image copying, and external automation through tools like Ansible and Bitbucket Runners. To explore the full list of supported plugins and their configuration options, refer to the [Devtron Plugin Documentation](/docs/user-guide/plugins/README.md).
-To learn how to create a new Job in Devtron, continue to the [Create a new job](./create-job.md) section.
+To learn how to create a new Job in Devtron, continue to the [Create a new job](./create-job.md) section.
\ No newline at end of file
diff --git a/docs/user-guide/namespaces-and-environments.md b/docs/user-guide/namespaces-and-environments.md
old mode 100644
new mode 100755
index 1dc8be7a04..6491e84377
--- a/docs/user-guide/namespaces-and-environments.md
+++ b/docs/user-guide/namespaces-and-environments.md
@@ -15,6 +15,4 @@ One of the advantages that Kubernetes provides is the ability to manage various
Environments in Devtron can be accessed from `Global Configurations->Clusters & Environments`
-
-
-
+
Figure 1: Cluster and Environments
\ No newline at end of file
diff --git a/docs/user-guide/operations/edit-gui-schema.md b/docs/user-guide/operations/edit-gui-schema.md
old mode 100644
new mode 100755
index 4dd294d276..1c005de699
--- a/docs/user-guide/operations/edit-gui-schema.md
+++ b/docs/user-guide/operations/edit-gui-schema.md
@@ -1,16 +1,13 @@
# Configure GUI Schema for Editing Manifest
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
-In Devtron, you can create [CRDs](../../reference/glossary.md#crd) for defining the GUI schema. Your GUI schema will be used to determine the fields displayed to the user when they [edit the manifest in GUI mode](../resource-browser/manage-resources.md#edit-using-gui).
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
+In Devtron, you can create [CRDs](../../reference/glossary.md#crd) for defining the GUI schema. Your GUI schema will be used to determine the fields displayed to the user when they [edit the manifest in GUI mode](../resource-browser/manage-resources.md#edit-using-gui-).
+:::caution Who Can Perform This Action?
Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant-super-admin-permission) can configure GUI Schema.
-{% endhint %}
+:::
---
@@ -20,19 +17,23 @@ Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant
2. Use the searchbox labelled 'Jump to Kind' and search for `Guischema`.
- 
+ 
+
Figure 1: Searching GUI Schema
3. Click the GUI schema you wish to edit. In case no GUI schema exists, you may [create a GUI schema](#create-your-own-gui-schema) for your resource kind.
- 
+ 
+
Figure 2: Click GUI Schema
4. Click **Edit Live Manifest** to modify the YAML.
- 
+ 
+
Figure 3: Edit Live Manifest
5. Locate the `schema` object and customize it according to your requirements.
- 
+ 
+
Figure 4: Modifying Schema
6. Click **Apply Changes**.
@@ -46,9 +47,7 @@ Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant
3. Use the following template and define your schema in the `schema` object, also specify the resource kinds in `applyTo`. Once done, click **Apply**.
-{% code title="GUI Schema for Pod Manifest" overflow="wrap" lineNumbers="true" %}
-
-```yml
+```yml title="GUI Schema for Pod Manifest" showLineNumbers
apiVersion: crd.devtron.ai/alpha1
kind: GuiSchema
metadata:
@@ -137,6 +136,4 @@ schema: |
}
}
}
-```
-
-{% endcode %}
\ No newline at end of file
+```
\ No newline at end of file
diff --git a/docs/user-guide/operations/edit-lock-schema.md b/docs/user-guide/operations/edit-lock-schema.md
old mode 100644
new mode 100755
index f347aa9017..3543d635be
--- a/docs/user-guide/operations/edit-lock-schema.md
+++ b/docs/user-guide/operations/edit-lock-schema.md
@@ -1,16 +1,13 @@
# Configure Lock Schema
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
In Devtron, you can create [CRDs](../../reference/glossary.md#crd) for defining lock schema. Your lock schema will be used to determine the fields (in the resource manifest) that cannot be added/updated/deleted by non-superadmins. This is especially useful for preventing unwanted edits to the manifests of pod, deployment, configmap, and many more.
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
-
+:::caution Who Can Perform This Action?
Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant-super-admin-permission) can configure Lock Schema.
-{% endhint %}
+:::
---
@@ -20,19 +17,23 @@ Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant
2. Use the searchbox labelled 'Jump to Kind' and search for `LockSchema`.
- 
+ 
+
Figure 1: Searching Lock Schema
3. Click the Lock Schema you wish to edit. In case no Lock Schema exists, you may [create a Lock Schema](#create-your-own-lock-schema) for your resource kind.
- 
+ 
+
Figure 2: Click Lock Schema
4. Click **Edit Live Manifest** to modify the YAML.
- 
+ 
+
Figure 3: Edit Live Manifest
5. Locate the `lockedPaths` list and specify the fields/paths you wish to lock from unwanted edits by non-superadmins in the manifest.
- 
+ 
+
Figure 4: Modifying Schema
6. Click **Apply Changes**.
@@ -46,9 +47,7 @@ Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant
3. Use the following template and specify the fields/paths you wish to lock in the `lockedPaths` list, also specify the resource kinds in `applyTo`. Once done, click **Apply**.
-{% code title="Lock Schema for ConfigMap" overflow="wrap" lineNumbers="true" %}
-
-```yml
+```yml title="Lock Schema for ConfigMap" showLineNumbers
apiVersion: crd.devtron.ai/alpha1
kind: LockSchema
name: devtron-cm-lock-schema
@@ -59,6 +58,4 @@ applyTo:
version: v1
lockedPaths:
- data.ENABLE_CI_JOB
-```
-
-{% endcode %}
\ No newline at end of file
+```
\ No newline at end of file
diff --git a/docs/user-guide/plugins/README.md b/docs/user-guide/plugins/README.md
old mode 100644
new mode 100755
index 491029b20c..258517c853
--- a/docs/user-guide/plugins/README.md
+++ b/docs/user-guide/plugins/README.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Pipeline Plugins
Pipeline plugins (a.k.a. preset plugins) are micro tools that allow you to enhance and refine the [CI/CD workflow](../creating-application/workflow/README.md) of your application by adding new features, integrating with external tools, and automating tasks.
@@ -6,5 +10,4 @@ Unlike [custom scripts](../creating-application/workflow/pre-post-tasks.md#execu
Some plugins are meant for pre-build/post-build, while some are meant for pre-deployment/post-deployment.
-From this section, you can know more about the individual plugins and its purpose.
-
+From this section, you can know more about the individual plugins and its purpose.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/ansible-runner.md b/docs/user-guide/plugins/ansible-runner.md
old mode 100644
new mode 100755
index 1c5f71f0bd..6d9571c896
--- a/docs/user-guide/plugins/ansible-runner.md
+++ b/docs/user-guide/plugins/ansible-runner.md
@@ -50,5 +50,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Ansible Runner plugin will not be generating an output variable.
-Click **Update Pipeline**.
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/bitbucket-runner-trigger.md b/docs/user-guide/plugins/bitbucket-runner-trigger.md
old mode 100644
new mode 100755
index f75714513d..02789a6b87
--- a/docs/user-guide/plugins/bitbucket-runner-trigger.md
+++ b/docs/user-guide/plugins/bitbucket-runner-trigger.md
@@ -9,15 +9,15 @@ Before integrating the **Bitbucket Runner Trigger** plugin, ensure you have a Bi
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **Build and Deploy from Source Code**.
5. Fill the required fields in the **Create build pipeline** window and navigate to the **Pre-Build stage**.
-{% hint style="warning" %}
+:::caution
If you have already configured workflow, edit the build pipeline, and navigate to **Pre-Build stage**.
-{% endhint %}
+:::
6. Under 'TASKS', click the **+ Add task** button.
7. Select the **Bitbucket Runner Trigger** plugin.
@@ -54,7 +54,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Bitbucket Runner Trigger will not be generating an output variable.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/codacy.md b/docs/user-guide/plugins/codacy.md
old mode 100644
new mode 100755
index 08365e8afd..8a3a08e93f
--- a/docs/user-guide/plugins/codacy.md
+++ b/docs/user-guide/plugins/codacy.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Codacy
Codacy is an automated code analysis/quality tool that helps developers to ship better software in a faster manner.
@@ -13,7 +17,7 @@ Codacy is an automated code analysis/quality tool that helps developers to ship
2. Enter a descriptive message for the task in the `Description` field. It is an optional field.
- 3. Provide a value for the input variable. **Note:** The value may be any of the values from the previous build stages, a global variable, or a custom value.
+ 3. Provide a value for the input variable. **Note:** The value may be any of the values from the previous build stages, a global variable, or a custom value.
| Variable | Format | Description |
| ---- | ---- | ---- |
| CodacyEndpoint | String | API endpoint for Codacy |
diff --git a/docs/user-guide/plugins/code-scan.md b/docs/user-guide/plugins/code-scan.md
old mode 100644
new mode 100755
index ee8a4ae53e..ae6f9336ff
--- a/docs/user-guide/plugins/code-scan.md
+++ b/docs/user-guide/plugins/code-scan.md
@@ -9,15 +9,15 @@ Before integrating the **Code Scan** plugin, install the [Vulnerability Scanning
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **Build and Deploy from Source Code**.
5. Fill the required fields in the **Create build pipeline** window and navigate to the **Pre-build stage**.
-{% hint style="warning" %}
+:::caution
If you have already configured workflow, edit the build pipeline, and navigate to **Pre-build stage**.
-{% endhint %}
+:::
6. Under 'TASKS', click the **+ Add task** button.
7. Select the **Code Scan** plugin.
@@ -43,6 +43,4 @@ No input variables are required for the Code Scan plugin.
### Output Variables
Code Scan will not be generating an output variable.
-Click **Update Pipeline**.
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/container-image-exporter.md b/docs/user-guide/plugins/container-image-exporter.md
old mode 100644
new mode 100755
index 38edfd3b4b..586606e7f9
--- a/docs/user-guide/plugins/container-image-exporter.md
+++ b/docs/user-guide/plugins/container-image-exporter.md
@@ -9,15 +9,15 @@ Before integrating the Container Image Exporter plugin, you need to properly con
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **Build and Deploy from Source Code**.
5. Fill the required fields in the **Create build pipeline** window and navigate to the **Post-Build stage**.
-{% hint style="warning" %}
+:::caution
If you have already configured workflow, edit the build pipeline, and navigate to **Post-Build stage**.
-{% endhint %}
+:::
6. Under 'TASKS', click the **+ Add task** button.
7. Select the **Container Image Exporter** plugin.
@@ -60,7 +60,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Container Image Exporter will not be generating an output variable.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/copacetic.md b/docs/user-guide/plugins/copacetic.md
old mode 100644
new mode 100755
index 148a015235..cd46626f61
--- a/docs/user-guide/plugins/copacetic.md
+++ b/docs/user-guide/plugins/copacetic.md
@@ -10,15 +10,15 @@ Before integrating the **Copacetic** plugin, install the [Vulnerability Scanning
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **Build and Deploy from Source Code**.
5. Fill the required fields in the **Create build pipeline** window and navigate to the **Post-build stage**.
-{% hint style="info" %}
+:::info
If you have already configured workflow, edit the build pipeline, and navigate to **Pre-build stage**.
-{% endhint %}
+:::
6. Under 'TASKS', click the **+ Add task** button.
7. Click the **Copacetic** plugin.
@@ -51,6 +51,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Copacetic will not be generating an output variable.
-Click **Update Pipeline**.
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/copy-container-image.md b/docs/user-guide/plugins/copy-container-image.md
old mode 100644
new mode 100755
index 6e6f590804..3ed983c2f0
--- a/docs/user-guide/plugins/copy-container-image.md
+++ b/docs/user-guide/plugins/copy-container-image.md
@@ -14,19 +14,23 @@ The plugin can be used at post CI, pre-CD, and post-CD. Moreover, you can also [
2. Select **Workflow Editor** and click your deployment pipeline.
- 
+ 
+
Figure 1: CD Pipeline
3. In this example, we will be adding the plugin in pre-CD stage; therefore, go to **Pre-Deployment stage** tab of your deployment pipeline and click **Add task**.
- 
+ 
+
Figure 2: Pre Deployment Tab
4. From the list of plugins, choose **Copy container image**.
- 
+ 
+
Figure 3: Copy Container Image
5. Add the image destination in the field given for **DESTINATION_INFO** variable. The format is `registry-name | username/repository-name`.
- 
+ 
+
Figure 4: Image Destination
* **registry-name** is the name you gave to your container registry while adding it in [Global Configuration → OCI/Container Registry](../global-configurations/container-registries.md#add-container-registry).
@@ -38,36 +42,29 @@ The plugin can be used at post CI, pre-CD, and post-CD. Moreover, you can also [
7. Go to the **Build & Deploy** tab of your application and click **Select Image** in the pre-deployment stage.
- 
+ 
+
Figure 5: Select Image
8. Choose a CI image that you wish to copy to the destination and click **Trigger Stage**.
- 
+ 
+
Figure 6: Trigger Pre-CD
9. The copying process will initiate, and once it is successful, the [tag for the copied image](../creating-application/workflow/cd-pipeline.md#custom-image-tag-pattern) would reflect at all relevant screens:
* **Destination Repository**
- 
+ 
+
-{% hint style="info" %}
+:::info
You can also filter out specific images (of target repository) from deployment. Refer [Filter Condition](../global-configurations/filter-condition.md) to know the process.
-{% endhint %}
-
-
-
-
-
-
-
-
-
-
-
-
+:::
\ No newline at end of file
diff --git a/docs/user-guide/plugins/cosign.md b/docs/user-guide/plugins/cosign.md
old mode 100644
new mode 100755
index d91fbb2d3e..39aad0065f
--- a/docs/user-guide/plugins/cosign.md
+++ b/docs/user-guide/plugins/cosign.md
@@ -9,15 +9,15 @@ Before integrating the Cosign plugin, ensure that you have configured the [Cosig
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **Build and Deploy from Source Code**.
5. Fill the required fields in the **Create build pipeline** window and navigate to the **Post-build stage**.
-{% hint style="warning" %}
+:::caution
If you have already configured workflow, edit the build pipeline, and navigate to **Post-build stage**.
-{% endhint %}
+:::
6. Under 'TASKS', click the **+ Add task** button.
7. Click the **Cosign** plugin.
@@ -44,7 +44,7 @@ e.g., `The Cosign plugin is integrated for ensuring the authenticity of contain
| PostCommand | STRING | Command to run after image is signed by Cosign | cosign verify $DOCKER_IMAGE |
| ExtraArguments | STRING | Arguments for Cosign command | --certificate-identity=name@example.com |
| CosignPassword | STRING | Password for Cosign private key | S3cur3P@ssw0rd123! |
-| VariableAsPrivateKey | STRING | base64 encoded private-key | @{{COSIGN_PRIVATE_KEY}} |
+| VariableAsPrivateKey | STRING | base64 encoded private-key | `@{{COSIGN_PRIVATE_KEY}}` |
| PreCommand | STRING | Command to get the required conditions to execute Cosign command | curl -sLJO https://raw.githubusercontent.com/devtron-labs/sampleRepo/branchName/private |
### Trigger/Skip Condition
@@ -53,7 +53,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Cosign will not be generating an output variable.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/crane-copy.md b/docs/user-guide/plugins/crane-copy.md
old mode 100644
new mode 100755
index 7b7de1e0f2..b2178d9441
--- a/docs/user-guide/plugins/crane-copy.md
+++ b/docs/user-guide/plugins/crane-copy.md
@@ -9,15 +9,15 @@ No prerequisites are required for integrating the **CraneCopy** plugin.
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **Build and Deploy from Source Code**.
5. Fill the required fields in the **Create build pipeline** window and navigate to the **Post-build stage**.
-{% hint style="warning" %}
+:::caution
If you have already configured workflow, edit the build pipeline, and navigate to **Post-build stage**.
-{% endhint %}
+:::
6. Under 'TASKS', click the **+ Add task** button.
7. Click the **CraneCopy** plugin.
@@ -52,7 +52,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
CraneCopy will not be generating an output variable.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/create-plugin.md b/docs/user-guide/plugins/create-plugin.md
old mode 100644
new mode 100755
index ce4b317a04..be58c8c48f
--- a/docs/user-guide/plugins/create-plugin.md
+++ b/docs/user-guide/plugins/create-plugin.md
@@ -19,59 +19,63 @@ There are two parts to creating a plugin:
### Part 1: Create a Custom Task
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Only superadmins can create plugins.
-{% endhint %}
+:::
-{% hint style="info" %}
-### Prerequisite
+:::info Prerequisite
A build or deployment pipeline must exist in the **Workflow Editor** of your app.
-{% endhint %}
+:::
In the following example, we are creating a plugin named 'Secret Management Validator'.
1. Go to **Applications** and select your app from the **Devtron Apps** tab.
- 
+ 
+
Figure 1: Choosing your App
2. From the **Configurations** tab, go to **Workflow Editor**.
- 
+ 
+
4. Go to the **Pre** or **Post** stage of your pipeline, e.g., `Pre-build stage`.
- 
+ 
+
Figure 4: Selecting Stage
5. Click **+ Add Task** to create a plugin from scratch or click an existing task.
- 
+ 
+
Figure 5: Adding a Task
6. On the **Execute Custom Task** page, fill the following details:
* **Task Name** - Give a name to the task, e.g., `Secret Management Validator Task`.
* **Description** - Write the purpose of the task in brief.
- * **Task Type** - Choose `Shell` if the task consists of shell commands or choose `Container Image` in case of complex operations that require a specific container environment (refer ['Container Image' task](../creating-application/workflow/pre-post-tasks.md#example-3-container-image-task)).
+ * **Task Type** - Choose `Shell` if the task consists of shell commands or choose `Container Image` in case of complex operations that require a specific container environment (refer ['Container Image' task](../creating-application/workflow/pre-post-tasks.md#example-3---container-image-task)).
* **Input Variables** - Add one or more input variables to accept values from the user. Give a name to your input variable along with a description and input type (String/Number/Boolean/Date).
* **Trigger Skip Condition** - Here you can set conditions to execute or skip the task. You can select **Set trigger conditions** to execute the task, or **Set skip conditions** to skip the task.
* **Script** - Enter the script to be executed.
* **Output directory path** - Enter the directory where your script will write/produce output files (e.g., test report, zip files).
* **Output Variables** - Similar to input variables, you can create variables whose values will be generated as output after task execution.
- 
+ 
+
-{% hint style="success" %}
-### Next Steps
+:::tip Next Steps
Go to the **Build & Deploy** tab of your application and run the pipeline having your custom task. If the custom task executes correctly and the script performs as expected, you may proceed to [save your custom task as a plugin](#part-2-convert-custom-task-to-a-plugin).
-{% endhint %}
+:::
---
@@ -79,7 +83,8 @@ Go to the **Build & Deploy** tab of your application and run the pipeline having
1. Go to your custom task that you have tried and tested, and click **Save as Plugin**.
- 
+ 
+
Figure 8: 'Save as Plugin' Option
2. In the **New plugin** tab, fill the following details:
@@ -93,44 +98,50 @@ Go to the **Build & Deploy** tab of your application and run the pipeline having
| **Description** | Enter a brief description of your plugin explaining what the plugin does |
| **Tags** | Select one or more tags from the list or create your own tag. This tag helps in identifying and classifying the plugin, e.g., `Compliance` `Secrets` `Security`.|
- 
+ 
+
Figure 8: Entering New Plugin Details
3. You have the option of marking the input variables (defined in step 6 earlier) as mandatory/optional. Enabling the toggle will make the input variable mandatory for your users.
- 
+ 
+
Figure 9: Marking Variables as Mandatory or Optional
4. Since you created the plugin from a custom task, you get an option to replace the original task with your plugin (in the task list).
- 
+ 
+
6. Your new plugin would appear in the list of plugins.
- 
+ 
+
Figure 12: List of Plugins
---
## Create a New Version of Plugin
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Only superadmins can create new versions of a plugin.
-{% endhint %}
+:::
You may create incremental versions of your plugin (e.g., `1.0.0` → `1.0.1` or `2.0.0`). The old version(s) of your plugins will still be available to your users.
-1. Follow steps 1-7 from the [Create a New Plugin](#create-a-new-plugin) section of this document.
+1. Follow steps 1-7 from the [Create a New Plugin](#part-1-create-a-custom-task) section of this document.
2. From the **New version of existing plugin** tab, select the plugin for which you want to create a new version from the **Existing Plugin** dropdown.
- 
+ 
+
Figure 13: Selecting Existing Plugin for Versioning
3. Specify the new version in the **New version** field.
- 
+ 
+
Figure 14: Creating New Version
4. Verify the details in the remaining fields that got auto-populated from your existing plugin and modify if required.
@@ -138,16 +149,16 @@ You may create incremental versions of your plugin (e.g., `1.0.0` → `1.0.1` or
6. You can view and use the available plugin versions as shown below.
- 
+ 
+
Figure 15: Selecting a Version
-->
+Refer the [spec file](https://github.com/devtron-labs/devtron/blob/main/specs/global-plugin.yaml) for detailed definition of each field present in the request/response body of the API. -->
\ No newline at end of file
diff --git a/docs/user-guide/plugins/dependency-track-maven-gradle.md b/docs/user-guide/plugins/dependency-track-maven-gradle.md
old mode 100644
new mode 100755
index 7e0ea97a96..b4b3e76972
--- a/docs/user-guide/plugins/dependency-track-maven-gradle.md
+++ b/docs/user-guide/plugins/dependency-track-maven-gradle.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Dependency Track for Maven & Gradle
Configuring `Dependency Track for NodeJs` in pre-build or post build task creates a bill of materials from Maven & Gradle projects and environments and uploads it to D-track for [Component Analysis](https://owasp.org/www-community/Component_Analysis) to identify and reduce risk in the software supply chain.
@@ -12,7 +16,7 @@ Configuring `Dependency Track for NodeJs` in pre-build or post build task create
* Enter a relevant name in the `Task name` field. It is a mandatory field.
* Enter a descriptive message for the task in the `Description` field. It is an optional field.
-* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
+* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
| Variable | Format | Description |
| ---- | ---- | ---- |
diff --git a/docs/user-guide/plugins/dependency-track-nodejs.md b/docs/user-guide/plugins/dependency-track-nodejs.md
old mode 100644
new mode 100755
index 0b37a467dd..b68124ba2f
--- a/docs/user-guide/plugins/dependency-track-nodejs.md
+++ b/docs/user-guide/plugins/dependency-track-nodejs.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Dependency Track for NodeJs
Configuring `Dependency Track for NodeJs` in pre-build or post build task creates a bill of materials from NodeJs projects and environments and uploads it to D-track for [Component Analysis](https://owasp.org/www-community/Component_Analysis) to identify and reduce risk in the software supply chain.
@@ -13,7 +17,7 @@ Configuring `Dependency Track for NodeJs` in pre-build or post build task create
* Enter a relevant name in the `Task name` field. It is a mandatory field.
* Enter a descriptive message for the task in the `Description` field. It is an optional field.
-* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
+* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
| Variable | Format | Description |
| ---- | ---- | ---- |
diff --git a/docs/user-guide/plugins/dependency-track-python.md b/docs/user-guide/plugins/dependency-track-python.md
old mode 100644
new mode 100755
index bd6dc0a9db..365d2ad03d
--- a/docs/user-guide/plugins/dependency-track-python.md
+++ b/docs/user-guide/plugins/dependency-track-python.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Dependency Track for Python
Configuring `Dependency Track for Python` in pre-build or post build task creates a bill of materials from Python projects and environments and uploads it to D-track for [Component Analysis](https://owasp.org/www-community/Component_Analysis) to identify and reduce risk in the software supply chain.
@@ -12,7 +16,7 @@ Configuring `Dependency Track for Python` in pre-build or post build task create
* Enter a relevant name in the `Task name` field. It is a mandatory field.
* Enter a descriptive message for the task in the `Description` field. It is an optional field.
-* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
+* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
| Variable | Format | Description |
| ---- | ---- | ---- |
diff --git a/docs/user-guide/plugins/devtron-cd-trigger.md b/docs/user-guide/plugins/devtron-cd-trigger.md
old mode 100644
new mode 100755
index 8f7cbfcd7d..7ddc0a6b3a
--- a/docs/user-guide/plugins/devtron-cd-trigger.md
+++ b/docs/user-guide/plugins/devtron-cd-trigger.md
@@ -9,16 +9,16 @@ Before integrating the Devtron CD Trigger plugin, you need to properly configure
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **Build and Deploy from Source Code**.
5. Fill the required fields in the **Create build pipeline** window and navigate to the **Create deployment pipeline**.
6. Fill the required fields in the **Deployment Stage** window and navigate to the **Post-Deployment stage**.
-{% hint style="warning" %}
+:::caution
If you have already configured workflow, edit the deployment pipeline, and navigate to **Post-Deployment stage**.
-{% endhint %}
+:::
6. Under 'TASKS', click the **+ Add task** button.
7. Select the **Devtron CD Trigger** plugin.
@@ -55,7 +55,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Devtron CD Trigger will not be generating an output variable.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/devtron-ci-trigger.md b/docs/user-guide/plugins/devtron-ci-trigger.md
old mode 100644
new mode 100755
index fd7f601cea..5d3e6859d8
--- a/docs/user-guide/plugins/devtron-ci-trigger.md
+++ b/docs/user-guide/plugins/devtron-ci-trigger.md
@@ -9,16 +9,16 @@ Before integrating the Devtron CI Trigger plugin, you need to properly configure
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **Build and Deploy from Source Code**.
5. Fill the required fields in the **Create build pipeline** window and navigate to the **Create deployment pipeline**.
6. Fill the required fields in the **Deployment Stage** window and navigate to the **Pre-Deployment stage**.
-{% hint style="warning" %}
+:::caution
If you have already configured workflow, edit the deployment pipeline, and navigate to **Pre-Deployment stage**.
-{% endhint %}
+:::
6. Under 'TASKS', click the **+ Add task** button.
7. Select the **Devtron CI Trigger** plugin.
@@ -55,7 +55,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Devtron CI Trigger will not be generating an output variable.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/devtron-job-trigger.md b/docs/user-guide/plugins/devtron-job-trigger.md
old mode 100644
new mode 100755
index 19b38b7703..647ca33386
--- a/docs/user-guide/plugins/devtron-job-trigger.md
+++ b/docs/user-guide/plugins/devtron-job-trigger.md
@@ -9,16 +9,16 @@ Before integrating the Devtron Job Trigger plugin, you need to properly configur
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **Build and Deploy from Source Code**.
5. Fill the required fields in the **Create build pipeline** window and navigate to the **Create deployment pipeline**.
6. Fill the required fields in the **Deployment Stage** window and navigate to the **Pre-Deployment stage**.
-{% hint style="warning" %}
+:::caution
If you have already configured workflow, edit the deployment pipeline, and navigate to **Pre-Deployment stage**.
-{% endhint %}
+:::
6. Under 'TASKS', click the **+ Add task** button.
7. Select the **Devtron Job Trigger** plugin.
@@ -55,7 +55,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Devtron Job Trigger will not be generating an output variable.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/docker-slim.md b/docs/user-guide/plugins/docker-slim.md
old mode 100644
new mode 100755
index 897cae9d14..4a4e7f58cd
--- a/docs/user-guide/plugins/docker-slim.md
+++ b/docs/user-guide/plugins/docker-slim.md
@@ -3,9 +3,9 @@
## Introduction
The **DockerSlim** plugin by Devtron helps you to optimize your container deployments by reducing Docker image size. Now with these lighter Docker images, you can perform faster deployments and enhance overall system efficiency.
-{% hint style="warning" %}
+:::caution
Support for Docker buildx images will be added soon.
-{% endhint %}
+:::
### Prerequisites
No prerequisites are required for integrating the **DockerSlim** plugin.
@@ -13,15 +13,15 @@ No prerequisites are required for integrating the **DockerSlim** plugin.
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **Build and Deploy from Source Code**.
5. Fill the required fields in the **Create build pipeline** window and navigate to the **Post-build stage**.
-{% hint style="warning" %}
+:::caution
If you have already configured workflow, edit the build pipeline, and navigate to **Post-build stage**.
-{% endhint %}
+:::
6. Under 'TASKS', click the **+ Add task** button.
7. Click the **DockerSlim** plugin.
@@ -42,9 +42,9 @@ e.g., `The DockerSlim plugin is integrated for reducing the size of Docker image
### Input Variables
-{% hint style="warning" %}
+:::caution
At `IncludePathFile` input variable list down the file path of essential files from your Dockerfile. Files for which the path is not listed at `IncludePathFile` will may be excluded from the Docker image to reduce size.
-{% endhint %}
+:::
| Variable | Format | Description | Sample Value |
| ------------------------ | ------------ | ----------- | ------------ |
@@ -57,7 +57,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
DockerSlim will not be generating an output variable.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/eks-create-cluster.md b/docs/user-guide/plugins/eks-create-cluster.md
old mode 100644
new mode 100755
index 73d5ec0309..dbde8104c1
--- a/docs/user-guide/plugins/eks-create-cluster.md
+++ b/docs/user-guide/plugins/eks-create-cluster.md
@@ -67,5 +67,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
| EKSKubeConfigPath | STRING | File path of the generated EKS cluster kubeconfig |
-Click **Update Pipeline**.
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/gcs-create-bucket.md b/docs/user-guide/plugins/gcs-create-bucket.md
old mode 100644
new mode 100755
index dd1a581559..4647fac39f
--- a/docs/user-guide/plugins/gcs-create-bucket.md
+++ b/docs/user-guide/plugins/gcs-create-bucket.md
@@ -63,7 +63,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
Here you can define when a task should be marked as passed or failed. You can select `Set pass conditions` to define success criteria or `Set failure conditions` to specify failure scenarios.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/github-pull-request-updater.md b/docs/user-guide/plugins/github-pull-request-updater.md
old mode 100644
new mode 100755
index d3c0899267..9f3dfcc14b
--- a/docs/user-guide/plugins/github-pull-request-updater.md
+++ b/docs/user-guide/plugins/github-pull-request-updater.md
@@ -9,15 +9,15 @@ Before integrating the **GitHub Pull Request Updater** plugin, ensure you have a
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **Build and Deploy from Source Code**.
5. Fill the required fields in the **Create build pipeline** window and navigate to the **Post-build stage**.
-{% hint style="warning" %}
+:::caution
If you have already configured workflow, edit the build pipeline, and navigate to **Post-build stage**.
-{% endhint %}
+:::
6. Under 'TASKS', click the **+ Add task** button.
7. Click the **GitHub Pull Request Updater** plugin.
@@ -52,7 +52,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
The GitHub Pull Request Updater plugin will not be generating an output variable.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/gke-provisioner.md b/docs/user-guide/plugins/gke-provisioner.md
old mode 100644
new mode 100755
index f929e0563e..7f868ed4b4
--- a/docs/user-guide/plugins/gke-provisioner.md
+++ b/docs/user-guide/plugins/gke-provisioner.md
@@ -3,9 +3,9 @@
## Introduction
This plugin streamlines the creation and configuration of a Google Kubernetes Engine (GKE) cluster on your Google Cloud Platform (GCP). It automates the provisioning process while implementing essential security measures, including a preconfigured firewall that allows access to SSH, HTTP (port 80), 8080, and Kubernetes NodePorts. By automating the GKE provisioning process through this plugin, you can save time, ensure consistency in cluster setup, maintain security standards, and provide a Kubernetes-ready environment for deploying your containerized applications.
-{% hint style="warning" %}
+:::caution
The **GKE Provisioner** plugin creates a [Standard GKE Cluster](https://cloud.google.com/kubernetes-engine/docs/how-to/creating-a-zonal-cluster), not an Autopilot GKE cluster.
-{% endhint %}
+:::
### Prerequisites
Before integrating the **GKE Provisioner** plugin make sure that you have a GCP account with valid permissions to provision GKE.
@@ -63,5 +63,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
| ------------------------ | ------------ | ----------- |
| GkeKubeconfigFilePath | STRING | File path of the generated GKE cluster kubeconfig |
-Click **Update Pipeline**.
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/golang-migrate.md b/docs/user-guide/plugins/golang-migrate.md
old mode 100644
new mode 100755
index 20ddefce56..280a6fb0b4
--- a/docs/user-guide/plugins/golang-migrate.md
+++ b/docs/user-guide/plugins/golang-migrate.md
@@ -1,11 +1,15 @@
+---
+hide_table_of_contents: true
+---
+
# GoLang-migrate
Migrate reads migrations from sources file and applies them in correct order to a database.
**Prerequisite**: Make sure you have SQL files in format used by the golang-migrate tool.
-**official-documentation**: https://github.com/golang-migrate/migrate
-**postgres-example**: https://github.com/golang-migrate/migrate/tree/master/database/postgres
+**Official-documentation**: https://github.com/golang-migrate/migrate
+**Postgres-example**: https://github.com/golang-migrate/migrate/tree/master/database/postgres
1. On the **Edit build pipeline** page, select the **Pre-Build Stage** (or Post-Build Stage). or
2. Click **+ Add task**.
@@ -14,7 +18,7 @@ Migrate reads migrations from sources file and applies them in correct order to
* Enter a relevant name in the `Task name` field. It is a mandatory field.
* Enter a descriptive message for the task in the `Description` field. It is an optional field.
-* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
+* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
| Variable | Format | Description |
| ---- | ---- | ---- |
@@ -43,4 +47,4 @@ Migrate reads migrations from sources file and applies them in correct order to
POST_COMMAND:
docker run -v $PWD:$PWD $MIGRATE_IMAGE -path $PWD/$SCRIPT_LOCATION -database " goto $MIGRATE_TO_VERSION;
```
-- use `DB_PASSWORD` with `scope-variable` feature for more security.
+- use `DB_PASSWORD` with `scope-variable` feature for more security.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/jenkins.md b/docs/user-guide/plugins/jenkins.md
old mode 100644
new mode 100755
index f449379168..4205ec7b4d
--- a/docs/user-guide/plugins/jenkins.md
+++ b/docs/user-guide/plugins/jenkins.md
@@ -12,9 +12,9 @@ Before integrating the Jenkins plugin, ensure that you have properly configured
---
## Steps
-1. Go to Applications → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click on your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **CREATE JOB PIPELINE**.
5. Enter the required fields in the **Basic configuration** window.
6. Under 'TASKS', click the **+ Add task** button.
@@ -51,6 +51,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Jenkins will not be generating an output variable.
-Click **Update Pipeline**.
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/jira-updater.md b/docs/user-guide/plugins/jira-updater.md
old mode 100644
new mode 100755
index 0721ba1df4..46d6c9a6e0
--- a/docs/user-guide/plugins/jira-updater.md
+++ b/docs/user-guide/plugins/jira-updater.md
@@ -47,11 +47,8 @@ The Jira Issue Updater plugin extends the capabilities of Devtron CI by allowing
## Results
-
-
-
-
-
-
-
+
+
Figure 2: Comments added by the Plugin on the Jira Issue
\ No newline at end of file
diff --git a/docs/user-guide/plugins/jira-validator.md b/docs/user-guide/plugins/jira-validator.md
old mode 100644
new mode 100755
index 488f72eee9..cc71fb923f
--- a/docs/user-guide/plugins/jira-validator.md
+++ b/docs/user-guide/plugins/jira-validator.md
@@ -47,8 +47,10 @@ The Jira Issue Validator plugin extends the filtering capabilities of the Devtro
**Case 1**: If Jira issue exists and the same is found in the PR title
-
+
+
Figure 1: Jira Issue Match
**Case 2**: If Jira issue is not found
-
+
+
Figure 2: Error in Finding Jira Issue
\ No newline at end of file
diff --git a/docs/user-guide/plugins/k6-load-testing.md b/docs/user-guide/plugins/k6-load-testing.md
old mode 100644
new mode 100755
index d3e3380ea6..551e51170c
--- a/docs/user-guide/plugins/k6-load-testing.md
+++ b/docs/user-guide/plugins/k6-load-testing.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# K6 Load Testing
K6 is an open-source tool and cloud service that makes load testing easy for developers and QA engineers.
@@ -11,7 +15,7 @@ K6 is an open-source tool and cloud service that makes load testing easy for dev
* Enter a relevant name in the `Task name` field. It is a mandatory field.
* Enter a descriptive message for the task in the `Description` field. It is an optional field.
-* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
+* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
| Variable | Format | Description |
| ---- | ---- | ---- |
@@ -23,4 +27,4 @@ K6 is an open-source tool and cloud service that makes load testing easy for dev
* `Trigger/Skip Condition` refers to a conditional statement to execute or skip the task. You can select either:
`Set trigger conditions` or
`Set skip conditions`
-* Click **Update Pipeline**.
+* Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/plugin-list.md b/docs/user-guide/plugins/plugin-list.md
old mode 100644
new mode 100755
index 0cb9e9c333..1ee61bc6b3
--- a/docs/user-guide/plugins/plugin-list.md
+++ b/docs/user-guide/plugins/plugin-list.md
@@ -1,11 +1,15 @@
-## Our Plugins
+---
+hide_table_of_contents: true
+---
+
+# Our Plugins
We have multiple plugins available in Devtron. At the moment, here are the plugins for which user guide is available.
* [Bitbucket Runner Trigger](./bitbucket-runner-trigger.md)
* [Codacy](./codacy.md)
* [Code-Scan](./code-scan.md)
* [Copacetic](./copacetic.md)
-* [Container Image Exporter]()
+* [Container Image Exporter](./container-image-exporter.md)
* [Copy Container Image](./copy-container-image.md)
* [Cosign](./cosign.md)
* [CraneCopy](./crane-copy.md)
@@ -28,4 +32,4 @@ We have multiple plugins available in Devtron. At the moment, here are the plugi
* [Semgrep](./semgrep.md)
* [SonarQube](./sonarqube.md)
* [SonarQube v1.1.0](./sonarqube-v1.1.0.md)
-* [Vulnerability Scanning](./vulnerability-scanning.md)
+* [Vulnerability Scanning](./vulnerability-scanning.md)
\ No newline at end of file
diff --git a/docs/user-guide/plugins/pull-images-from-container-repository.md b/docs/user-guide/plugins/pull-images-from-container-repository.md
old mode 100644
new mode 100755
index a17b2e9839..a8689f4b92
--- a/docs/user-guide/plugins/pull-images-from-container-repository.md
+++ b/docs/user-guide/plugins/pull-images-from-container-repository.md
@@ -4,9 +4,9 @@
The Pull images from container repository plugin helps you poll the specified container repository and fetch the container images to deploy them on your target Kubernetes environments using Devtron's CD pipeline. By integrating this plugin you can:
- Poll the designated container repository to get the specific container image build using external CI like Jenkins and Github actions. Once the image becomes available, you can deploy it to your target Kubernetes environment using Devtron's CD pipeline.
-{% hint style="warning" %}
+:::caution
Currently, this plugin only supports ACR and ECR registry. Support for other container registries will be added soon.
-{% endhint %}
+:::
### Prerequisites
Before integrating the **Pull images from the container repository** plugin, ensure that you have a specific container image present at your ECR container repository to pull the image and deploy it to the target environment.
@@ -14,9 +14,9 @@ Before integrating the **Pull images from the container repository** plugin, ens
---
## Steps
-1. Go to Applications → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **CREATE JOB PIPELINE**.
5. Enter the required fields in the **Basic configuration** window.
6. Under 'TASKS', click the **+ Add task** button.
@@ -49,6 +49,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Pull images from container repository will not be generating an output variable.
-Click **Update Pipeline**.
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/semgrep.md b/docs/user-guide/plugins/semgrep.md
old mode 100644
new mode 100755
index cf6830500e..aeee5991cd
--- a/docs/user-guide/plugins/semgrep.md
+++ b/docs/user-guide/plugins/semgrep.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Semgrep
Semgrep is a fast, open source, static analysis engine for finding bugs, detecting dependency vulnerabilities, and enforcing code standards.
@@ -11,13 +15,13 @@ Semgrep is a fast, open source, static analysis engine for finding bugs, detecti
* Enter a relevant name in the `Task name` field. It is a mandatory field.
* Enter a descriptive message for the task in the `Description` field. It is an optional field.
-* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
+* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
| Variable | Format | Description |
| ---- | ---- | ---- |
| SemgrepAppToken | String | App token of Semgrep. If it is provided, this token will be used, otherwise it will be picked from Global Secret. |
-| PrefixAppNameInSemgrepBranchName | Bool | Enter either `true` or `false` accordingly whether you want app name to be reflected with a branch name. If it is `true`, it will add app name with branch name. E.g., {SemgrepAppName}-{branchName} |
-| UseCommitAsSemgrepBranchName | Bool | Enter either `true` or `false` accordingly whether you want app name to be reflected with commit hash. If it is `true`, it will add app name with commit hash. E.g., {SemgrepAppName}-{CommitHash}. |
+| PrefixAppNameInSemgrepBranchName | Bool | Enter either `true` or `false` accordingly whether you want app name to be reflected with a branch name. If it is `true`, it will add app name with branch name. E.g., `{SemgrepAppName}`-`{branchName}` |
+| UseCommitAsSemgrepBranchName | Bool | Enter either `true` or `false` accordingly whether you want app name to be reflected with commit hash. If it is `true`, it will add app name with commit hash. E.g., `{SemgrepAppName}`-`{CommitHash}`. |
| SemgrepAppName | String | App name for Semgrep. If it is provided, and `PrefixAppNameInSemgrepBranchName` is true, then this will be prefixed with branch name/commit hash.|
| ExtraCommandArguments | String | Extra command arguments for Semgrep CI command. E.g., Input: --json --dry-run. |
diff --git a/docs/user-guide/plugins/sonarqube-v1.1.0.md b/docs/user-guide/plugins/sonarqube-v1.1.0.md
old mode 100644
new mode 100755
index f7958f111f..60906fcb70
--- a/docs/user-guide/plugins/sonarqube-v1.1.0.md
+++ b/docs/user-guide/plugins/sonarqube-v1.1.0.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Sonarqube v1.1.0
Configuring `Sonarqube-v1.1.0` in pre-build or post build task enhances your workflow with Continuous Code Quality & Code Security.
@@ -8,11 +12,12 @@ Configuring `Sonarqube-v1.1.0` in pre-build or post build task enhances your wor
2. Click **+ Add task**.
3. Select **Sonarqube v1.1.0** from **PRESET PLUGINS**.
- 
+ 
+
Figure 1: sonarqube-v1.1.0
* Enter a relevant name in the `Task name` field. It is a mandatory field.
* Enter a descriptive message for the task in the `Description` field. It is an optional field.
-* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
+* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
| Variable | Format | Description |
| ---- | ---- | ---- |
diff --git a/docs/user-guide/plugins/sonarqube.md b/docs/user-guide/plugins/sonarqube.md
old mode 100644
new mode 100755
index a1e83139ac..4752dbc6ad
--- a/docs/user-guide/plugins/sonarqube.md
+++ b/docs/user-guide/plugins/sonarqube.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# SonarQube
Configuring `Sonarqube` in pre-build or post build task enhances your workflow with Continuous Code Quality & Code Security.
@@ -8,11 +12,12 @@ Configuring `Sonarqube` in pre-build or post build task enhances your workflow w
2. Click **+ Add task**.
3. Select **Sonarqube** from **PRESET PLUGINS**.
- 
+ 
+
Figure 1: Sonarqube
* Enter a relevant name in the `Task name` field. It is a mandatory field.
* Enter a descriptive message for the task in the `Description` field. It is an optional field.
-* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
+* Provide a value for the input variable. Note: The value may be any of the values from the previous build stages, a global variable, or a custom value.
| Variable | Format | Description |
| ---- | ---- | ---- |
diff --git a/docs/user-guide/plugins/terraform-cli.md b/docs/user-guide/plugins/terraform-cli.md
old mode 100644
new mode 100755
index da8b90693d..b98dd09c16
--- a/docs/user-guide/plugins/terraform-cli.md
+++ b/docs/user-guide/plugins/terraform-cli.md
@@ -55,7 +55,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Terraform CLI will not be generating an output variable.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/plugins/vulnerability-scanning.md b/docs/user-guide/plugins/vulnerability-scanning.md
old mode 100644
new mode 100755
index bf3762b0aa..bbd03d1e01
--- a/docs/user-guide/plugins/vulnerability-scanning.md
+++ b/docs/user-guide/plugins/vulnerability-scanning.md
@@ -9,9 +9,9 @@ Before integrating the Vulnerability Scanning plugin, ensure that you have insta
---
## Steps
-1. Go to **Applications** → **Devtron Apps**.
+1. Go to **Application Management** → **Applications** → **Devtron Apps** (tab).
2. Click your application.
-3. Go to **App Configuration** → **Workflow Editor**.
+3. Go to **Configurations** (tab) → **Workflow Editor**.
4. Click **New Workflow** and navigate to the **CREATE JOB PIPELINE**.
5. Enter the required fields in the **Basic configuration** window.
6. Click **Task to be executed**.
@@ -45,7 +45,4 @@ Here you can set conditions to execute or skip the task. You can select `Set tri
### Output Variables
Vulnerability Scanning will not be generating an output variable.
-Click **Update Pipeline**.
-
-
-
+Click **Update Pipeline**.
\ No newline at end of file
diff --git a/docs/user-guide/policies/README.md b/docs/user-guide/policies/README.md
new file mode 100755
index 0000000000..f2c024870a
--- /dev/null
+++ b/docs/user-guide/policies/README.md
@@ -0,0 +1,38 @@
+---
+id: README
+title: Policies
+sidebar_label: Policies
+description: Define and enforce governance policies for deployments, image management, and plugin usage in Devtron.
+---
+
+The **Policies** section allows admins and DevOps teams to enforce consistent governance across all applications and environments in Devtron.
+
+These policies help regulate deployments, approvals, plugin usage, and image promotions, ensuring both compliance and operational safety.
+
+---
+
+## Table of Contents
+
+### 1. [Deployment Window](../global-configurations/deployment-window.md)
+Define specific timeframes during which application deployments are either blocked or allowed in specific environments
+
+### 2. [Approval Policy](../global-configurations/approval-policy.md)
+Introduce an approval mechanism to ensure that changes to sensitive configurations and deployment are authorized by the right stakeholders before execution.
+
+### 3. [Plugin Policy](../global-configurations/plugin-policy.md)
+Enforce the presence of specific plugins at various stages in your application's build and deployment pipelines.
+
+### 4. [Pull Image Digest](../global-configurations/pull-image-digest.md)
+Enforce image pull-by-digest instead of pull-by-tag for deployments.
+
+### 5. [Tags Policy](../global-configurations/tags-policy.md)
+Enforce the presence of tag before application creation or before deployment to an environment, for better auditing and rule creation.
+
+### 6. [Filter Condition](../global-configurations/filter-condition.md)
+Apply conditional logic to determine which images should be eligible for deployment after the CI stage.
+
+### 7. [Lock Deployment Config](../global-configurations/lock-deployment-config.md)
+Lock down deployment configurations to prevent unauthorized modifications or accidental changes to critical base configurations or environment configurations.
+
+### 8. [Image Promotion](../global-configurations/image-promotion-policy.md)
+Promote verified builds between deployment pipelines (e.g., from staging to production) by skipping intermediate pipelines.
\ No newline at end of file
diff --git a/docs/user-guide/resource-browser/README.md b/docs/user-guide/resource-browser/README.md
old mode 100644
new mode 100755
index a17045748d..642b8cc102
--- a/docs/user-guide/resource-browser/README.md
+++ b/docs/user-guide/resource-browser/README.md
@@ -4,15 +4,17 @@
The Devtron Resource Browser provides you a central interface to view and manage all your [Kubernetes objects](../../reference/glossary.md#objects) across clusters. It helps you perform key actions like viewing logs, editing live manifests, and even creating/deleting resources directly from the user interface. This is especially useful for troubleshooting purposes as it supports multi-cluster too.
-{% hint style="info" %}
-### Additional References
+
+
+:::info Additional References
* [Resource browser versus traditional tools like kubectl](https://devtron.ai/blog/managing-kubernetes-resources-across-multiple-clusters)
* [Why you should use Devtron's Resource Browser](https://devtron.ai/blog/what-is-the-kubernetes-resource-browser-in-devtron)
-{% endhint %}
+:::
First, the Resource Browser shows you a list of clusters added to your Devtron setup. By default, it displays a cluster named '*default_cluster*' after the Devtron setup is successful.
-
+
+
Figure 1: Devtron Resource Browser - List of Clusters
In the image above, you can see a visual display of the health status for all clusters connected to Devtron. If any node within a cluster encounters an issue and is not ready, it will be highlighted in red, allowing you to quickly address the problem.
@@ -20,7 +22,8 @@ If you are a superadmin, you can connect more clusters by clicking the **Add Clu
You may click a cluster to view and manage all its resources as shown below.
-
+
+
Figure 2: Resources within Cluster
---
@@ -33,5 +36,4 @@ You may click a cluster to view and manage all its resources as shown below.
* [Pod Management and Debugging](pods.md)
* [Cluster Terminal](cluster-terminal.md)
* [Add Monitoring Dashboards/Graphs](monitoring-graphs.md)
-* [Run Kubectl Commands Locally](kubectl-local.md)
-
+* [Run Kubectl Commands Locally](kubectl-local.md)
\ No newline at end of file
diff --git a/docs/user-guide/resource-browser/cluster-terminal.md b/docs/user-guide/resource-browser/cluster-terminal.md
old mode 100644
new mode 100755
index 1d0ff50874..0dd4fa3f84
--- a/docs/user-guide/resource-browser/cluster-terminal.md
+++ b/docs/user-guide/resource-browser/cluster-terminal.md
@@ -1,14 +1,19 @@
+---
+hide_table_of_contents: true
+---
+
# Cluster Terminal
User with [super-admin](../global-configurations/authorization/user-access.md#grant-super-admin-permission) access can now troubleshoot cluster issues by accessing the cluster terminal from Devtron. You can select an image from the list that has all CLI utilities like kubectl, helm, netshoot etc. or can use a custom image, which is publicly available.
To troubleshoot a cluster or a specific node in a cluster, click the terminal icon on the right side.
-
+
+
Figure 1: Terminal Icon
* You will see the user-defined name for the cluster in Devtron. E.g. `default-cluster`.
* Select the node you wish to troubleshoot from the `Node` drop-down. E.g. `demo-new`.
-* Select the namespace from the drop-down list which you have added in the [Clusters & Environments](../global-configurations/cluster-and-environments.md#add-environment) section.
+* Select the namespace from the drop-down list which you have added in the [Clusters & Environments](../global-configurations/clusters/manage-environments.md#add-environment-to-a-cluster) section.
* Select the image from the drop-down list which includes all CLI utilities or you can use a custom image, which is publicly available.
* Select the terminal shell from the drop-down list (e.g. `sh`, `bash`) to troubleshoot a node.
@@ -34,6 +39,6 @@ kubectl describe pod
Here, you can see configuration information about the container(s) and pod (labels, resource requirements, etc.), as well as status information about the container(s) and pod (state, readiness, restart count, events, etc.). [Click here](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/) to know more about pod lifecycle.
-{% hint style="info" %}
+:::info
A container can have no shells or multiple shells running in it. If you are unable to create a successful connection, try changing the shell, as the container may not have that shell running.
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/user-guide/resource-browser/cluster-upgrade-compatibility.md b/docs/user-guide/resource-browser/cluster-upgrade-compatibility.md
new file mode 100644
index 0000000000..7c90e63293
--- /dev/null
+++ b/docs/user-guide/resource-browser/cluster-upgrade-compatibility.md
@@ -0,0 +1,95 @@
+---
+title: Cluster Upgrade Compatibility
+sidebar_label: Cluster Upgrade Compatibility
+---
+
+# Cluster Upgrade Compatibility
+
+## Introduction
+
+Upgrading a Kubernetes cluster to a newer version can break your workloads, because Kubernetes periodically **deprecates** and eventually **removes** older API versions of its resources. If an object in your cluster still uses an API version that is removed in the target Kubernetes version, it will stop working after the upgrade.
+
+Devtron's **Cluster Upgrade Compatibility** check helps you prepare for a cluster upgrade *before* you perform it. For a chosen target Kubernetes version, Devtron scans all the Kubernetes objects in your cluster and tells you:
+
+* Which resources use an API version that is **removed** in the target version.
+* Which resources use an API version that is **deprecated** in the target version.
+* Which resources have **new API versions available** in the target version.
+* Whether each object **can be migrated with just an apiVersion change**, or needs fixes first.
+
+Under the hood, Devtron uses [Silver Surfer](./silver-surfer-internals.md) to compare your live cluster objects against the target Kubernetes version's API schema. For details on how the comparison is computed, see [Silver Surfer Internals](./silver-surfer-internals.md).
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant-super-admin-permission) can run the cluster upgrade compatibility check.
+:::
+
+---
+
+## Checking Compatibility
+
+### Step 1: Open the compatibility check
+
+1. Go to the **Resource Browser** and select the cluster you plan to upgrade.
+
+2. On the cluster **Overview** page, locate the **Kubernetes version** of the cluster. Under it, in the **Migrating to another K8s version?** card, click **Check Compatibility**.
+
+ 
+
Figure 1: Check Compatibility Entry Point
+
+### Step 2: Select the target Kubernetes version
+
+Choose the Kubernetes version you intend to upgrade to. Devtron populates the list of selectable versions based on the available Kubernetes releases.
+
+
+
Figure 2: Selecting the Target Kubernetes Version
+
+Devtron then scans every object in the cluster and compares its API version against the schema of the selected target version.
+
+---
+
+## Understanding the Results
+
+The compatibility report groups your cluster's objects into the following categories:
+
+| Category | Meaning |
+| :--- | :--- |
+| **Removed ApiVersion** | The object's current API version **no longer exists** in the target version. These must be migrated before upgrading, otherwise the object will break. |
+| **Deprecated ApiVersion** | The object's current API version still works in the target version but is **marked for removal** in a future version. You should plan to migrate these. |
+| **New Versions Available** | A **newer API version** is available for the object in the target version. Migrating is recommended to stay current. |
+
+
+
Figure 3: Compatibility Report Overview
+
+### Summary and Migration Status
+
+For each category, a **Summary** table lists the affected objects with their `name`, `namespace`, `kind`, **current API version**, **latest API version**, and a **migration status**. The migration status is one of:
+
+| Migration Status | Meaning |
+| :--- | :--- |
+| **Can be migrated with just an apiVersion change** | The object is compatible with the target version's schema; you only need to update its `apiVersion`. |
+| **N issues: fix issues before migration** | The object has schema validation issues (for example, fields that changed or were removed). Fix these before migrating. |
+| **Cannot migrate Kubernetes version** | The object cannot be migrated to the target version as-is and needs attention. |
+
+Alongside the summary, Devtron also surfaces:
+
+* **Validation Errors** — schema errors for the object, checked both against its **current** API version and against the **latest** API version, with the exact field `path` and `reason`.
+* **Deprecated Fields** — fields used by the object that are deprecated in the current or latest API version.
+
+
+
Figure 4: Object Details and Migration Path
+
+:::info Pod Disruption Budgets
+Along with API compatibility, the report also highlights **risky Pod Disruption Budgets (PDBs)** — PDB configurations that could block nodes from draining during the upgrade — so you can address them beforehand.
+:::
+
+---
+
+## Next Steps
+
+Use the report to prepare your cluster for the upgrade:
+
+1. Migrate objects listed under **Removed ApiVersion** first — these will break after the upgrade.
+2. For objects marked **fix issues before migration**, resolve the reported validation errors, then update the `apiVersion`.
+3. Plan migrations for **Deprecated ApiVersion** objects to avoid problems in future upgrades.
+4. Review and fix any **risky PDBs**.
+
+Once the report shows your objects can be migrated, you can proceed with the cluster upgrade with confidence.
diff --git a/docs/user-guide/resource-browser/compare-and-sync.md b/docs/user-guide/resource-browser/compare-and-sync.md
old mode 100644
new mode 100755
index f008e6d3f9..575063a340
--- a/docs/user-guide/resource-browser/compare-and-sync.md
+++ b/docs/user-guide/resource-browser/compare-and-sync.md
@@ -1,6 +1,6 @@
# Compare & Sync Clusters
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
The Compare & Sync feature in Devtron allows you to:
@@ -12,15 +12,13 @@ The Compare & Sync feature in Devtron allows you to:
Refer to [Use Cases](#use-cases) to know more on how this feature can help you.
-
-
-{% hint style="warning" %}
-
-### Who Can Perform This Action?
+
+
Figure 1: Compare & Sync Feature
+:::caution Who Can Perform This Action?
Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant-super-admin-permission) can compare and sync clusters.
-{% endhint %}
+:::
---
@@ -28,30 +26,32 @@ Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant
1. Navigate to **Resource Browser**.
- 
+ 
+
Figure 2: Resource Browser
2. Click the reference cluster (e.g., `default-cluster`) to compare against other clusters.
3. Click the **Compare & Sync** button. The **Compare & Sync Clusters** page is displayed.
- 
+ 
+
Figure 3: Compare & Sync Button
The **Compare & Sync Clusters** page is primarily divided into two halves. The left side of the page displays the resources of the reference cluster you previously selected (`default-cluster` in this case). The right side of the page displays the resources of the target cluster you want to compare against.
- 
+ 
+
Figure 4: Compare & Sync Clusters Page
4. Select the target cluster in the **Select Cluster** drop-down box (e.g., `playground-vcluster` in this case).
- 
+ 
+
Figure 5: Select the Cluster
Once you select the clusters that you want to compare, all the resources associated with those clusters are listed in the **Compare & Sync Clusters** page.
- 
-
-{% hint style="info" %}
-
-### How to Identify Missing Resource(s)?
+ 
+
Figure 6: Cluster Resources are Displayed
+:::info How to Identify Missing Resource(s)?
When the color of the resource is:
* **Red** - The resource is not available in that particular cluster.
@@ -60,11 +60,12 @@ When the color of the resource is:
For instance, when a resource is displayed in blue in cluster A and in red in cluster B, it means that the resource available in cluster A is not available in cluster B.
-{% endhint %}
+:::
5. Click the filter available at the top left corner of the page. All the resource groups and resource kinds are displayed in the filter box. For example, when you select `ConfigMap` as a resource kind, all the available ConfigMaps in both clusters are displayed.
- 
+ 
+
Figure 7: Resource Kind Filter
6. Click the **View all** drop-down box. This filter allows you to filter the resources based on the following criteria:
@@ -78,15 +79,13 @@ For instance, when a resource is displayed in blue in cluster A and in red in cl
* `View right join` - To display all resources from the target cluster (right-hand side) and only matching resources from the reference cluster (left-hand side).
- 
-
-{% hint style="warning" %}
-
-### Creating a Missing Resource?
+ 
+
Figure 8: View All Filter
+:::caution Creating a Missing Resource?
Before creating a missing resource or comparing a manifest, it is very important to match the namespaces in both clusters. Otherwise, an error will be displayed. For example, if cluster A has a namespace `devtroncd` and cluster B does not have the same namespace, then you will get an error message while creating a missing resource.
-{% endhint %}
+:::
Follow the below steps to match the namespaces:
@@ -98,35 +97,36 @@ Follow the below steps to match the namespaces:
4. Click the **Create Resources** button. The namespaces will now be matched.
- 
+ 
+
Figure 9: Match Namespaces
### Create Missing Resource(s)
Hover over the resource that you'd like to create in the target cluster and click the **Create Resource** option.
-
-
-{% hint style="info" %}
-
-### Note
+
+
Figure 10: Create Resource
+:::info Note
* To create missing resources in bulk, select the checkboxes against the resources or resource groups and click the **Create Resources** button. All the selected resources will be created in the target cluster.
* Even after creating missing resources, a few of them may not run as expected unless the dependencies required to run the resources correctly are also met. Therefore, it is recommended that you ensure all the necessary dependencies are taken care of while creating missing resources.
-{% endhint %}
+:::
### Compare Manifest
1. Hover over the resource and click the **Compare manifest** option to compare the manifest of the resource in both clusters.
- 
+ 
+
Figure 11: Compare Manifest
2. Click **Edit YAML**.
3. Click the **Revert this chunk** option to enforce the values, if required, from the reference cluster to the target cluster.
- 
+ 
+
Figure 12: Revert this Chunk
4. Click **Apply Changes**.
diff --git a/docs/user-guide/resource-browser/download-content-from-pods.md b/docs/user-guide/resource-browser/download-content-from-pods.md
new file mode 100644
index 0000000000..7458cee254
--- /dev/null
+++ b/docs/user-guide/resource-browser/download-content-from-pods.md
@@ -0,0 +1,239 @@
+---
+title: Download Content from Pods
+description: Learn how to download files such as logs, configurations, and diagnostic outputs directly from a Pod Terminal (via App Details or Resource Browser) or Cluster Terminal in Devtron without using external CLI tools.
+sidebar_label: Download Content from Pods
+sidebar_position: 5
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Download Content from Pods
+
+:::info Who Can Perform This Action?
+The permission required depends on how you access the Pod Terminal:
+
+| Access Path | Required Permission |
+|---|---|
+| App Details → Pod → Terminal | **Admin** access on the specific application |
+| Resource Browser → Pods → Terminal | [Admin access on the Kubernetes resource](https://docs.devtron.ai/docs/user-guide/global-configurations/authorization/permission-groups#kubernetes-resources-permissions) |
+| Resource Browser → Cluster Terminal | [Admin access of all the K8s resources of that cluster](https://docs.devtron.ai/docs/user-guide/global-configurations/authorization/permission-groups#kubernetes-resources-permissions) |
+:::
+
+## Introduction
+
+While debugging Kubernetes clusters or pods, the workflow often requires exec-ing into a container and running commands to identify issues. Once the root cause is found, there is frequently a need to retrieve files from within the container — such as log files, configuration files, or diagnostic outputs — to share with teammates or archive for further analysis.
+
+Devtron provides **built-in support** across **three access points** to download files directly to your local system, without needing `kubectl cp` or any external CLI tooling:
+
+- **App Details → Pod → Terminal** — for downloading files from pods belonging to a specific application
+- **Resource Browser → Pods → Terminal** — for downloading files from any pod across any cluster
+- **Resource Browser → Cluster Terminal** — for downloading files at the node level
+
+**Common use cases include:**
+
+- Downloading application log files generated inside a container
+- Retrieving runtime configuration files for auditing
+- Exporting diagnostic outputs after a debugging session
+- Sharing troubleshooting artifacts with your team
+
+---
+
+## Prerequisites
+
+Before you can download content from a pod, ensure the following:
+
+- To download via **App Details**, you have **Admin** access on the specific application.
+- To download via **Resource Browser** or **Cluster Terminal**, you have [Admin access on the Kubernetes resource](https://docs.devtron.ai/docs/user-guide/global-configurations/authorization/permission-groups#kubernetes-resources-permissions).
+- The pod you want to access is in a **Running** state.
+- The file you want to download exists at a known path inside the container.
+
+---
+
+## Steps to Download Content from a Pod
+
+You can access the Pod Terminal and download content from two different places in Devtron — choose the one that fits your workflow:
+
+
+
+
+Use this path when you are debugging a **specific application** and want to download files from one of its running pods.
+
+### Step 1 — Navigate to App Details
+
+Go to **Applications** and click the application whose pod you want to access.
+
+In the application overview, click **App Details**.
+
+
+
+*Figure 1: Downloading content from a pod via App Details*
+
+---
+
+### Step 2 — Locate the Pod
+
+1. Scroll down to the **K8s Resources** section on the App Details page.
+2. Click on **Pods** to expand the pod list for the application.
+3. Identify the pod you want to access and click on it to open its details.
+
+---
+
+### Step 3 — Open the Pod Terminal
+
+1. In the pod details panel, click the **Terminal** tab.
+2. Select the **Container** from the dropdown (for pods with multiple containers).
+3. Select the **Shell** type — `sh` or `bash` — depending on what is available in the container image.
+
+:::info
+If you are unable to connect, try switching the shell type. Not all container images include both `sh` and `bash`.
+:::
+
+The terminal session will open inside the running container.
+
+---
+
+### Step 4 — Download the File
+
+Once you are inside the pod terminal:
+
+1. Confirm the path of the file you want to download. For example:
+
+ ```bash
+ ls /var/log/app/
+ ```
+
+2. Click the **Download** icon (↓) in the terminal toolbar.
+
+3. In the dialog that appears, enter the **absolute path** of the file inside the container. For example:
+
+ ```
+ /var/log/app/application.log
+ ```
+
+4. Click **Download**. The file will be transferred to your local system automatically.
+
+
+
+
+
+Use this path when you want to access **any pod across any cluster**, regardless of which application it belongs to.
+
+### Step 1 — Navigate to the Resource Browser
+
+Go to **Infrastructure Management** → **Resource Browser** and select the cluster containing the pod you want to access.
+
+
+
+*Figure 2: Downloading content from a specific pod via Resource Browser*
+
+---
+
+### Step 2 — Locate the Pod
+
+1. In the left sidebar under **K8s Resources**, expand **Workloads**.
+2. Click **Pod**.
+3. Use the search bar to find the pod you wish to access.
+4. Click the pod name to open its details panel.
+
+---
+
+### Step 3 — Open the Pod Terminal
+
+1. In the pod details panel, click the **Terminal** tab.
+2. Select the **Container** from the dropdown (for pods with multiple containers).
+3. Select the **Shell** type — `sh` or `bash` — depending on what is available in the container image.
+
+:::info
+If you are unable to connect, try switching the shell type. Not all container images include both `sh` and `bash`.
+:::
+
+The terminal session will open inside the running container.
+
+---
+
+### Step 4 — Download the File
+
+Once you are inside the pod terminal:
+
+1. Confirm the path of the file you want to download. For example:
+
+ ```bash
+ ls /var/log/app/
+ ```
+
+2. Click the **Download** icon (↓) in the terminal toolbar.
+
+3. In the dialog that appears, enter the **absolute path** of the file inside the container. For example:
+
+ ```
+ /var/log/app/application.log
+ ```
+
+4. Click **Download**. The file will be transferred to your local system automatically.
+
+
+
+
+---
+
+## Downloading from the Cluster Terminal
+
+The download feature is also available at the **Cluster Terminal** level (node-level access), in addition to the Pod Terminal.
+
+To access the Cluster Terminal:
+
+1. In the Resource Browser, click the **Terminal** icon (⌨) on the right side of the cluster row.
+2. Select a **Node**, **Namespace**, **Image**, and **Shell** from the dropdowns.
+3. Use the **Download** icon in the toolbar to download files from the node.
+
+
+
+*Figure 3: Downloading content via the Cluster Terminal*
+
+Refer to [Cluster Terminal](https://docs.devtron.ai/docs/user-guide/resource-browser/cluster-terminal) for more details on node-level access.
+
+---
+
+## What You Can Download
+
+| File Type | Example Path |
+|---|---|
+| Application log files | `/var/log/app/application.log` |
+| Configuration files | `/etc/myapp/config.yaml` |
+| Diagnostic outputs | `/tmp/debug-output.txt` |
+| Any accessible file | Any path readable by the container process |
+
+:::note
+You can only download files that are accessible within the container's filesystem. Files on volumes not mounted to that container, or files requiring elevated permissions beyond the container's process user, may not be downloadable.
+:::
+
+---
+
+## Troubleshooting
+
+| Issue | Possible Cause | Resolution |
+|---|---|---|
+| Terminal does not connect | Shell (`bash`/`sh`) not present in image | Switch to a different shell from the dropdown |
+| Download dialog does not appear | File path is incorrect or file does not exist | Verify the path inside the terminal first with `ls` |
+| File downloads as empty | File is being actively written to | Wait for the write operation to complete, then retry |
+| Permission denied on file | Container process lacks read access | Use an ephemeral container with appropriate permissions |
+
+---
+
+## Related Topics
+
+- [App Details](https://docs.devtron.ai/docs/user-guide/application-management/app-details)
+- [Pod Management and Debugging](https://docs.devtron.ai/docs/user-guide/resource-browser/pods)
+- [Cluster Terminal](https://docs.devtron.ai/docs/user-guide/resource-browser/cluster-terminal)
+- [Launching Ephemeral Container](https://docs.devtron.ai/docs/user-guide/resource-browser/pods#launching-ephemeral-container)
+- [Kubernetes Resources Permissions](https://docs.devtron.ai/docs/user-guide/global-configurations/authorization/permission-groups#kubernetes-resources-permissions)
\ No newline at end of file
diff --git a/docs/user-guide/resource-browser/kubectl-local.md b/docs/user-guide/resource-browser/kubectl-local.md
old mode 100644
new mode 100755
index 89d5b8e054..728d8c12e0
--- a/docs/user-guide/resource-browser/kubectl-local.md
+++ b/docs/user-guide/resource-browser/kubectl-local.md
@@ -1,10 +1,11 @@
# Running Kubectl Commands Locally
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
If you wish to run kubectl commands from your local system, you need to have access to your cluster. Traditionally, the kubeconfig file (`./kube/config`) helps you connect with the cluster from your local system.
-
+
+
Figure 1: Kubeconfig File
---
@@ -32,7 +33,8 @@ Devtron helps in reducing the challenges and simplifying the maintenance of kube
If you are not a super-admin and can't generate a token yourself, you can find the session token (argocd.token) using the Developer Tools available in your web browser as shown below.
-
+
+
Figure 2: Using Session Token
There are 2 methods of getting kubeconfig in your system:
* [Quick Method](#quick-method)
@@ -42,7 +44,8 @@ There are 2 methods of getting kubeconfig in your system:
1. In Resource Browser, hover on the cluster name and click the `Get kubeconfig` icon.
- 
+ 
+
Figure 3: Get Kubeconfig
2. Copy the commands and run them on your terminal.
@@ -51,8 +54,7 @@ There are 2 methods of getting kubeconfig in your system:
1. Go to `~/.kube` folder on your local machine and open the `config` file. Or you may create one with the following content:
- {% code title="kubeconfig" overflow="wrap" lineNumbers="true" %}
- ```yml
+ ```yaml title="Sample Kubeconfig" showLineNumbers
apiVersion: v1
kind: Config
clusters:
@@ -71,31 +73,32 @@ There are 2 methods of getting kubeconfig in your system:
user:
token:
```
- {% endcode %}
+
2. Edit the following placeholders in the `server` field and the `token` field:
| Placeholder | Description | Example | Where to Find |
| ------------------- | ----------------------------------- | ---------------- | ------------------ |
- | | Hostname of the Devtron server | demo.devtron.ai | [Host URL Page](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/kubernetes-resource-browser/hostname-page.jpg) |
- | | Name of the cluster (or cluster ID) | devtron-cluster | [Applications Page](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/kubernetes-resource-browser/applications-page.jpg) |
- | | API token or session token | \- | [Authorization Page](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/kubernetes-resource-browser/authorization-page.jpg) |
+ | `` | Hostname of the Devtron server | demo.devtron.ai | [Host URL Page](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/kubernetes-resource-browser/hostname-page.jpg) |
+ | `` | Name of the cluster (or cluster ID) | devtron-cluster | [Applications Page](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/kubernetes-resource-browser/applications-page.jpg) |
+ | `` | API token or session token | \- | [Authorization Page](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/kubernetes-resource-browser/authorization-page.jpg) |
- 
+ 
+
Figure 4: Editing Kubeconfig File
3. Test the connection to the cluster by running any kubectl command, e.g., `kubectl get ns` or `kubectl get po -A`
-{% hint style="info" %}
-### Additional References
+:::info Additional References
Once the connection is successful, you may run any [kubectl operations](https://kubernetes.io/docs/reference/kubectl/#operations) from your system.
-{% endhint %}
+:::
---
-## Use Case - Port Forwarding [](https://devtron.ai/pricing)
+## Use Case - Port Forwarding
Assume your applications are running in a Kubernetes cluster on cloud. Now, if you wish to test or debug them on your local machine, you can perform [port forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). It creates a tunnel between a port on your machine and a port on a resource within your cluster. Therefore, you can access applications running inside the cluster as though they are running locally on your machine.
Once you have successfully connected to the cluster, you may run the port-forward command. Refer [kubectl port-forward](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_port-forward/) to see a few examples.
-
\ No newline at end of file
+
+
Figure 5: Example - Port Forwarding
\ No newline at end of file
diff --git a/docs/user-guide/resource-browser/manage-resources.md b/docs/user-guide/resource-browser/manage-resources.md
old mode 100644
new mode 100755
index 22ba041391..271415eb41
--- a/docs/user-guide/resource-browser/manage-resources.md
+++ b/docs/user-guide/resource-browser/manage-resources.md
@@ -1,21 +1,21 @@
# Discover and Manage Resources
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have [access to the cluster](../global-configurations/authorization/user-access.md#kubernetes-resources-permissions) to discover resources.
-{% endhint %}
+:::
## Search a Resource
You can use the searchbox to browse the resources.
-
+
+
Figure 1: Locate Resources using Searchbox
-### Filter Resources [](https://devtron.ai/pricing)
+### Filter Resources
Moreover, you can use filters that allow you to quickly filter your workload as per labels, field selectors, or [CEL expression](https://kubernetes.io/docs/reference/using-api/cel/) as shown below.
-{% embed url="https://www.youtube.com/watch?v=E-V-ELCXtfs" caption="Filtering Workloads in Devtron" %}
+
### Resource Kinds
@@ -36,31 +36,32 @@ Further resources in the cluster are grouped under the following categories:
* Other Resources
* Custom Resource
-
+
+
Figure 2: Resources within Cluster
---
## Edit a Manifest
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
User needs to be an [admin of the Kubernetes resource](../global-configurations/authorization/user-access.md#kubernetes-resources-permissions) to edit its manifest. The fields/paths locked by superadmins in the manifest cannot be edited by non-superadmins.
-{% endhint %}
+:::
-You can edit the [manifest](../../reference/glossary.md#manifest) of a Kubernetes object. This can be for fixing errors, scaling resources, or changing configuration. Moreover, you can edit a manifest [using YAML](#edit-using-yaml) or [GUI](#edit-using-gui), as per your convenience.
+You can edit the [manifest](../../reference/glossary.md#manifest) of a Kubernetes object. This can be for fixing errors, scaling resources, or changing configuration. Moreover, you can edit a manifest [using YAML](#edit-using-yaml) or [GUI](#edit-using-gui-), as per your convenience.
### Edit using YAML
-
+
+
Figure 3a: Editing Manifest (Using YAML)
-### Edit using GUI [](https://devtron.ai/pricing)
+### Edit using GUI
-
+
+
Figure 3b: Editing Manifest (Using GUI)
-{% hint style="info" %}
-### Note
+:::info Note
The fields displayed in GUI mode will be as per the GUI schema configured by the operator for that resource kind.
-{% endhint %}
+:::
---
@@ -68,40 +69,40 @@ The fields displayed in GUI mode will be as per the GUI schema configured by the
You can monitor activities like creation, deletion, updation, scaling, or errors in the resources involved. Refer [Events](https://kubernetes.io/docs/reference/kubernetes-api/cluster-resources/event-v1/) to learn more.
-
+
+
Figure 4a: Viewing All Events
-### AI-assistance on Events [](https://devtron.ai/pricing)
+### AI-assistance on Events
-{% hint style="info" %}
-### How to Configure Devtron Intelligence?
+:::info How to Configure Devtron Intelligence?
Refer [Devtron Intelligence](../devtron-intelligence.md) to enable this feature.
-{% endhint %}
+:::
For events with warnings, you can take the assistance of AI. Clicking the **Explain** button will help you identify the root cause of the issue along with suggestions to fix those.
-
+
+
Figure 4b: AI-assistance
---
## Delete a Resource
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
User needs to be an [admin of the Kubernetes resource](../global-configurations/authorization/user-access.md#kubernetes-resources-permissions) to delete it.
-{% endhint %}
+:::
You can delete an unwanted resource if it is orphaned and no longer required by your applications.
-
+
+
Figure 5: Deleting a Resource
---
## Create a Resource
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
User needs to be an [admin of the Kubernetes resources](../global-configurations/authorization/user-access.md#kubernetes-resources-permissions) to create resources.
-{% endhint %}
+:::
You can create one or more [Kubernetes objects](../../reference/glossary.md#objects) in your cluster using YAML. In case you wish to create multiple objects, separate each resource definition by three dashes (---).
@@ -109,12 +110,12 @@ Once you select a cluster in Resource Browser, click **+ Create Resource**, and
In the below example, we have created a simple pod named `nginx`:
-
+
+
Figure 6: Creating Resources within Cluster
Here's one more example that shows the required fields and object specifications for a Kubernetes Deployment:
-{% code title="Spec File" overflow="wrap" lineNumbers="true" %}
-```yml
+```yml title="Spec File" showLineNumbers
apiVersion: apps/v1
kind: Deployment
metadata:
@@ -137,23 +138,24 @@ spec:
ports:
- containerPort: 80
```
-{% endcode %}
+
---
-## Bulk Actions on Resources [](https://devtron.ai/pricing)
+## Bulk Actions on Resources
You can use the checkbox to select the resources/workloads you wish to delete or restart.
### Bulk Delete
-
+
+
-{% hint style="info" %}
-### Note
+:::info Note
You can only restart certain workloads such as Deployment, DaemonSet, StatefulSet, etc. and not all resource types.
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/user-guide/resource-browser/monitoring-graphs.md b/docs/user-guide/resource-browser/monitoring-graphs.md
old mode 100644
new mode 100755
index 960b6f6a48..14bd7f4e54
--- a/docs/user-guide/resource-browser/monitoring-graphs.md
+++ b/docs/user-guide/resource-browser/monitoring-graphs.md
@@ -1,18 +1,18 @@
# Add Monitoring Graphs or Dashboards
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
The Resource Browser allows you to integrate monitoring graphs and dashboards from tools like Grafana, Kibana, Prometheus, and many more tools, with each cluster. This centralizes all monitoring visuals for your clusters in one place within Devtron, streamlining troubleshooting and significantly reducing manual effort.
It works similarly to a 'Single Pane of Glass (SPOG)' that displays data coming from different sources in a single unified view.
-
-
+
+
Figure 1: Adding Monitoring Visualizations
---
## Tutorial
-{% embed url="https://www.youtube.com/watch?v=XHfrAsHhTQ0" caption="Add Monitoring Graphs or Dashboards" %}
+
---
@@ -22,11 +22,13 @@ It works similarly to a 'Single Pane of Glass (SPOG)' that displays data coming
2. Click the graph icon as shown below and click the **Add Panel** button.
- 
+ 
+
Figure 2: Adding Monitoring
3. Give a name to the monitoring dashboard and add the `iframe` code supplied by your graph/dashboard tool.
- 
+ 
+
Figure 3: Adding Monitoring
4. Click **Save**.
diff --git a/docs/user-guide/resource-browser/nodes.md b/docs/user-guide/resource-browser/nodes.md
old mode 100644
new mode 100755
index 8dda430807..4418787644
--- a/docs/user-guide/resource-browser/nodes.md
+++ b/docs/user-guide/resource-browser/nodes.md
@@ -6,7 +6,8 @@ The components on a typical node include the `kubelet`, a `container runtime`, a
If you have multiple nodes, you can search a node by name or label in the search bar. The search result will display the following information about the node. To display a parameter of a node, use `Columns` on the right side, select the parameter to display from the drop-down list, and click **Apply**.
-
+
+
Figure 1: Searching and Filtering Nodes
| Fields | Description |
| --- | --- |
@@ -28,7 +29,8 @@ Clicking on a node shows you a number of details such as:
* Labels, Annotations, and Taints
* Node IP
-
+
+
Figure 2: Checking Node Summary
Further using the Devtron UI, you will be able to:
* [Debug a Node](#debug-a-node)
@@ -38,15 +40,13 @@ Further using the Devtron UI, you will be able to:
* [Edit a Node Config](#edit-a-node-config)
* [Delete a Node](#delete-a-node)
-{% hint style="info" %}
-### Why Are Node Operations Required?
+:::info Why Are Node Operations Required?
Your applications run on pods, and pods run on nodes. But sometimes, Kubernetes scheduler cannot deploy a pod on a node for several reasons, e.g., node is not ready, node is not reachable, network is unavailable, etc. In such cases, node operations help you manage the nodes better.
-{% endhint %}
+:::
-{% hint style="warning" %}
-### Who Can Perform These Actions?
+:::caution Who Can Perform These Actions?
Users need to have super-admin permission to perform node operations.
-{% endhint %}
+:::
## Debug a Node
@@ -54,11 +54,13 @@ You can debug a node via [Cluster Terminal](./cluster-terminal.md) by selecting
* Click **Debug**.
- 
+ 
+
Figure 3a: Debugging a Node
* Debug a node by selecting the terminal shell, i.e., `bash` or `sh`.
- 
+ 
+
Figure 3b: Debug Terminal
---
@@ -66,15 +68,18 @@ You can debug a node via [Cluster Terminal](./cluster-terminal.md) by selecting
Cordoning a node means making the node unschedulable. After [cordoning a node](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/), new pods cannot be scheduled on this node.
-
+
+
Figure 4a: Visual Representation - Cordoning a Node
* A confirmation dialog box will appear, click **Cordon Node** to proceed.
- 
+ 
+
Figure 4c: Cordon Confirmation
The status of the node shows `SchedulingDisabled` with `Unschedulable` parameter set as `true`.
@@ -86,17 +91,20 @@ Similarly, you can uncordon a node by clicking `Uncordon`. After a node is uncor
Before performing maintenance on a node, [draining a node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) evicts all of your pods safely from a node. Safe evictions allow the pod’s containers to gracefully terminate and honour the `PodDisruptionBudgets` you have specified (if relevant).
-
+
+
Figure 5a: Visual Representation - Draining a Node
After the node is drained, all pods (including those managed by DaemonSets) in the node will be automatically drained to other nodes in the cluster, and the drained node will be set to cordoned status.
* Click **Drain**.
- 
+ 
+
Figure 5b: Draining a Node
* A confirmation dialog box will appear, click **Drain Node** to proceed.
- 
+ 
+
Figure 5c: Drain Confirmation
You can also select from the following conditions before draining a node:
@@ -104,7 +112,7 @@ You can also select from the following conditions before draining a node:
| --- | --- |
| Grace Period | Period of time in seconds given to each pod to terminate gracefully. If negative, the default value specified in the pod will be used. |
| Delete empty directory data | Enabling this field will delete the pods using empty directory data when the node is drained. |
-| Disable eviction (use with caution) | Enabling this field will force drain to use delete, even if eviction is supported. This will bypass checking `PodDisruptionBudgets`. Note: Make sure to use with caution. |
+| Disable eviction (use with caution) | Enabling this field will force drain to use delete, even if eviction is supported. This will bypass checking `PodDisruptionBudgets`. Note: Make sure to use with caution. |
| Force drain | Enabling this field will force drain a node even if there are pods that do not declare a controller. |
| Ignore DaemonSets | Enabling this field will ignore DaemonSet-managed pods. |
@@ -114,34 +122,33 @@ You can also select from the following conditions before draining a node:
Taints are `key:value` pairs associated with effect. After you add taints to nodes, you can set tolerations on a pod to allow the pod to be scheduled to nodes with certain taints. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
-
+
+
Figure 6a: Visual Representation - Tainting a Node
**Note**: Make sure to check taint validations before you add a taint.
* Click **Edit taints**.
- 
+ 
+
Figure 6b: Tainting a Node
-* Enter the `key:value` pairs and select the [taint effect](#taint-effects) from the drop-down list.
+* Enter the `key:value` pairs and select the taint effect from the drop-down list. [Click here](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#concepts) to read about taint effects.
- 
+ 
+
Figure 6c: Adding Taints
* Click **Save**.
You can also add more taints using **+ Add taint button**, or delete the existing taint by using the delete icon.
-{% hint style="info" %}
-### Additional Reference
-[Click here](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/#concepts) to read about taint effects.
-{% endhint %}
-
---
## Edit a Node Config
This allows you to directly edit any node. It will open the editor which contains all the configuration settings in which the default format is YAML. You can edit multiple objects, although changes are applied one at a time.
-
+
+
Figure 7: Editing Node Config
* Go to the `YAML` tab and click **Edit YAML**.
* Make the changes using the editor.
@@ -154,12 +161,14 @@ This allows you to directly edit any node. It will open the editor which contain
You can also delete a node by clicking the **Delete** button present on the right-hand side.
-
+
+
The node will be deleted from the cluster.
-{% hint style="info" %}
+:::info
You can also access [Cluster Terminal](./cluster-terminal.md) from your node.
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/user-guide/resource-browser/overview.md b/docs/user-guide/resource-browser/overview.md
old mode 100644
new mode 100755
index e31e42a601..7139ff53e4
--- a/docs/user-guide/resource-browser/overview.md
+++ b/docs/user-guide/resource-browser/overview.md
@@ -1,6 +1,7 @@
# Overview
-
+
+
Figure 1: Resource Browser - Overview Page
## Resource Utilization
@@ -25,36 +26,35 @@ This shows errors in the cluster. If no error is present in the cluster, Resourc
---
-## Catalog Framework [](https://devtron.ai/pricing)
+## Catalog
-{% hint style="warning" %}
-### Who Can Perform This Action?
-Users need to have super-admin permission to edit the catalog framework.
-{% endhint %}
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to edit the catalog.
+:::
-Based on the schema provided in the catalog framework, you can add relevant details for each cluster. Refer [Catalog Framework](../global-configurations/catalog-framework.md) for more details.
+Based on the schema defined for the catalog, you can add relevant details for each cluster. You can manage this data using the **Manage Schema** option, which defines the structure of your catalog. Refer the [Manage Schema](../global-configurations/catalog-framework.md#managing-a-schema) documentation to learn more.
---
## Readme
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to edit the readme file.
-{% endhint %}
+:::
You can also include additional information about your cluster using the Markdown editor.
---
-## Check Compatibility before Cluster Upgrade [](https://devtron.ai/pricing)
+## Check Compatibility before Cluster Upgrade
Whenever you upgrade your Kubernetes version, the API versions change and your workloads/resources may not be compatible with those API versions. Therefore, the resources need to be upgraded first. This could mean changing the API version of the resources itself or changing their outdated spec.
The **Check Compatibility** feature within Resource Browser scans your cluster and automatically identifies all such resources/workloads that need manual intervention before proceeding with an actual cluster upgrade.
-
+
+
Figure 2: Checking Compatibility
### Walkthrough
-{% embed url="https://www.youtube.com/watch?v=mJsTN1x1fr0" caption="Check Compatibility before Cluster Upgrade" %}
\ No newline at end of file
+
\ No newline at end of file
diff --git a/docs/user-guide/resource-browser/pods.md b/docs/user-guide/resource-browser/pods.md
old mode 100644
new mode 100755
index aebc18e6c5..a87461e5d4
--- a/docs/user-guide/resource-browser/pods.md
+++ b/docs/user-guide/resource-browser/pods.md
@@ -1,9 +1,8 @@
# Pods
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have [access to the cluster](../global-configurations/authorization/user-access.md#kubernetes-resources-permissions) to view its pods and its data.
-{% endhint %}
+:::
## Manifest
@@ -23,9 +22,9 @@ Examining your cluster's pods helps you understand the health of your applicatio
Moreover, you can download the pod logs for ease of sharing and troubleshooting as shown in the below video.
-{% embed url="https://www.youtube.com/watch?v=PP0ZKAZCT58" caption="Downloading Pod Logs" %}
+
-### Pod Last Restart Snapshot [](https://devtron.ai/pricing)
+### Pod Last Restart Snapshot
Frequent pod restarts can impact your application as it might lead to unexpected downtimes. In such cases, it is important to determine the root cause and take actions (both preventive and corrective) if needed.
@@ -35,16 +34,16 @@ In case any of your pod restarts, you can view its details from the pod listing
* Container log before restart
* Node status and events
-
+
+
Figure 1: Checking Restart Pod Log
---
## Terminal
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
User needs to be an [admin of the Kubernetes resource](../global-configurations/authorization/user-access.md#kubernetes-resources-permissions) to access pod terminal.
-{% endhint %}
+:::
You can access the terminal within a running container of a pod to view its logs, troubleshoot issues, or execute commands directly. This is different from the [cluster terminal](cluster-terminal.md) you get at node level.
@@ -52,7 +51,7 @@ You can access the terminal within a running container of a pod to view its logs
This is a part of [Pod Terminal](#terminal). It is especially useful when `kubectl exec` is insufficient because a container has crashed or a container image doesn't include debugging utilities.
-{% embed url="https://www.youtube.com/watch?v=Ml19i29Ivc4" caption="Launching Ephemeral Containers from Resource Browser" %}
+
1. In the Resource Browser, select **Pod** within `Workloads`.
2. Use the searchbar to find and locate the pod you wish to debug. Click the pod.
@@ -62,7 +61,8 @@ This is a part of [Pod Terminal](#terminal). It is especially useful when `kubec
You get 2 tabs:
1. **Basic** - It provides the bare minimum configurations required to launch an ephemeral container.
- 
+ 
+
Figure 2: Basic Tab
It contains 3 mandatory fields:
@@ -74,6 +74,6 @@ This is a part of [Pod Terminal](#terminal). It is especially useful when `kubec
2. **Advanced** - It is particularly useful for advanced users that wish to use labels or annotations since it provides additional key-value options. Refer [Ephemeral Container Spec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#ephemeralcontainer-v1-core) to view the supported options.
-{% hint style="info" %}
+:::info
Devtron ignores the 'command' field while launching an ephemeral container
-{% endhint %}
\ No newline at end of file
+:::
\ No newline at end of file
diff --git a/docs/user-guide/resource-browser/resource-recommender.md b/docs/user-guide/resource-browser/resource-recommender.md
old mode 100644
new mode 100755
index d234e2b2bc..054cd30da3
--- a/docs/user-guide/resource-browser/resource-recommender.md
+++ b/docs/user-guide/resource-browser/resource-recommender.md
@@ -1,6 +1,6 @@
# Resource Recommender
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
**Resource Recommender** is a Devtron feature that analyzes the history of resource usage (such as CPU and memory) for Kubernetes workloads in a specific cluster and generates data-backed recommendations for optimal resource allocation.
@@ -8,21 +8,17 @@ These recommendations are generated by a background job that runs daily at a spe
It helps users eliminate manual guesswork, reduce over-provisioning, and prevent performance issues caused by under-provisioned workloads.
-{% hint style="info" %}
-### Prerequisites
+:::info Prerequisites
+* Prometheus endpoint must be configured. Refer to the [Cluster and Environments](../global-configurations/clusters/add-clusters.md#configure-prometheus-enable-application-metrics)
-* Prometheus endpoint must be configured. Refer to the [Cluster and Environments](../global-configurations/cluster-and-environments.md#configure-prometheus-enable-application-metrics)
-
-{% endhint %}
-
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::
+:::caution Who Can Perform This Action?
To view recommendations, users need to have [view permissions for the specific cluster](../global-configurations/authorization/user-access.md#kubernetes-resources-permissions).
To apply recommendations, users need to have [admin permissions for the specific cluster](../global-configurations/authorization/user-access.md#kubernetes-resources-permissions).
-{% endhint %}
+:::
## Inspect Recommendations
@@ -30,40 +26,48 @@ To inspect the resource recommendations, follow the steps below:
1. Navigate to **Resource Browser**.
- 
+ 
+
Figure 1: Navigating to Resource Browser
2. Select the specific cluster for which you want to inspect the resource recommendations.
- 
+ 
+
Figure 2: Selecting Cluster
3. Select the **Resource Recommender** tab to inspect the recommendations.
- 
+ 
+
Figure 3: Selecting Resource Recommender
1. Each row displays workloads in that cluster, along with recommendations for CPU and memory.
- 
+ 
+
Figure 4: Displaying Workloads along with Recommendations
2. Recommendations are shown as percentage changes by default. You can use the **Show absolute values** checkbox to see current v/s recommended values in actual units (e.g., 128Mi → 4900Ki).
- 
+ 
+
Figure 5: Toggling 'Show Absolute Values'
- {% hint style="info"%}
+:::info
### No Recommendations
* In case you have just configured the Prometheus endpoint, you might face the **No recommendations yet** screen after selecting **Resource Recommender**.
* Click **Check for Recommendations** to initiate the scan, and recommendations will be available in a few minutes.
- {%endhint%}
+:::
4. You can inspect the resource recommendations for each workload within the cluster.
1. If you wish, you can filter the workloads based on their `Kind` and `Namespace`.
- 
+ 
+
Figure 6a: Filtering via 'Kind'
- 
+ 
+
Figure 6b: Filtering via 'Namespace'
2. You can also search for a specific workload via the search bar based on `WORKLOAD`, `NAMESPACE`, `KIND`, `API VERSION`, and `CONTAINER NAME`.
- 
+ 
+
Figure 7: Filtering via Search Bar
5. For each workload, recommendations can be of the following types:
@@ -87,13 +91,17 @@ To inspect the resource recommendations, follow the steps below:
6. Hover the cursor over the specific resource of the particular workload to view the recommendation.
- 
+ 
+
Figure 8a: Recommending for Increasing Resources
- 
+ 
+
Figure 8b: Recommending for Decreasing Resources
- 
+ 
+
Figure 8c: Recommending to not take any action
- 
+ 
+
Figure 8d: No Recommendation
### Rescan for Recommendations
@@ -105,7 +113,8 @@ If you want to rescan for recommendations, use this option to fetch the most rec
3. Rescanning will start, and recommendations will be updated in few minutes.
- 
+ 
+
Figure 9: Rescanning for Recommendations
## Apply Recommendations
@@ -120,15 +129,18 @@ To apply recommended resources to a specific workload, follow the steps below:
1. Hover over the specific workload row and click the **Apply** button that appears on hover.
- 
+ 
+
Figure 10: Selecting Workload
2. A modal window will open, displaying the comparison between the current and recommended resource values for that specific workload; review the recommended changes carefully.
- 
+ 
+
Figure 11: Comparing Configurations
3. Click **Apply Changes** to update the resource configuration.
- 
+ 
+
Figure 12: Applying Changes
### Bulk Apply
@@ -136,15 +148,18 @@ If you wish, you can apply recommended resource configurations to multiple or al
1. Select the workloads for which you want to apply recommended resource configurations and click **Apply Changes**.
- 
+ 
+
Figure 13: Selecting Workloads
2. A modal window will open, displaying the comparison between the current and recommended resource values for each workload; review the recommended changes for each workload carefully.
- 
+ 
+
Figure 14: Comparing Configurations for each workload
3. Click **Apply Changes** to update the resource configuration.
- 
+ 
+
Figure 15: Applying Changes
## Export Recommendations in CSV File
@@ -154,33 +169,39 @@ You can also export resource recommendations to a CSV file. To do so, follow the
2. Click the **Download** button; a dialog box will appear displaying that your export is ready. By default, the file will be downloaded automatically to your system. If you wish you can select **Click Here To Download Manually** to download the file manually.
- 
-
- 
+ 
+
Figure 16: Clicking Download Button
## Modify Resource Recommender Job Schedule
To modify the schedule of the **Resource Recommender** background job, follow the steps below:
-1. In a new tab, go to **Resource Browser** → (Select the Cluster for which you want to modify the resource recommender job schedule) → **Config & Storage** → **ConfigMap**
+1. In a new tab, go to **Infrastructure Management** → **Resource Browser** → (Select the Cluster for which you want to modify the resource recommender job schedule) → **Config & Storage** → **ConfigMap**
2. Select the **Orchestrator/Devtron ConfigMap**
1. If **Devtron** is managing your setup, contact **Devtron** support to perform these changes.
2. If you installed Devtron via Helm, select `devtron-cm` and click **Edit Live Manifest**.
- 
+ 
+
Figure 17a: Selecting Devtron CM
- 
+ 
+
Figure 17b: Clicking 'Edit Live Manifest'
3. Edit the `KRR_SYNC_JOB_CRON_SCHEDULE` key and set the schedule according to your use case using a cron expression.
-4. Click **Apply Changes** and manifest will be updated.
+4. Click **Review and Save Changes** and a split-view will open for comparing changes.
+
+ 
+
Figure 18: Comparing Changes
- 
+5. Click **Apply Changes** and manifest will be updated.
-5. Restart the `orchestrator` or `devtron` pod to implement the changes.
+ 
+
Figure 19: Applying Changes
- 
+6. Restart the `orchestrator` or `devtron` pod to implement the changes.
-
+ 
+
Figure 20: Restarting Pods
\ No newline at end of file
diff --git a/docs/user-guide/resource-browser/scoop-config.md b/docs/user-guide/resource-browser/scoop-config.md
new file mode 100644
index 0000000000..d85f00da63
--- /dev/null
+++ b/docs/user-guide/resource-browser/scoop-config.md
@@ -0,0 +1,209 @@
+# Configuring Scoop
+
+## Introduction
+
+To enable **Pod Last Restart Snapshot**, you must configure Scoop in your target cluster. Scoop collects pod restart events from your cluster and sends them to Devtron, allowing the platform to display details such as restart reason, timestamp, and pre-restart logs directly in the Pod Listing view.
+
+## Steps to Configure Scoop
+
+### 1. Deploying Scoop Chart
+
+To use **Pod Last Restart Snapshot** for your workloads, you must deploy the scoop chart in every cluster for which you want to access restart details for its pods. For this demonstration, we are deploying it in the `default cluster`.
+
+1. Go to **Infrastructure Management** → **Chart Store**.
+
+2. Search the `devtron-scoop` chart and click on it. A new page will open.
+
+ 
+
+3. Click **Deploy Chart**, and a new page will open.
+
+ 
+
+4. Enter the required details in the left pane:
+
+ 
+
+ | **Field** | **Description** |
+ |------------|-----------------|
+ | **App Name** | Give your app a name, e.g. `devtron-scoop` |
+ | **Project** | Select your project |
+ | **Deploy to environment** | Choose the target environment |
+ | **Deployment type** | Select **Helm** as the deployment method |
+ | **Chart Version** | Select the latest chart version |
+ | **Chart Values** | Choose the default one for the latest version |
+
+5. In the right pane, search for the keyword `PASS_KEY`, and specify any value of your choice (We recommend using a random string for better security).
+
+ * If you leave the value unchanged, the default value `random-string` will be used as the passkey for authentication.
+
+6. Note down the value you have specified for `PASS_KEY`. If you left the value unchanged, then the `PASS_KEY` value is `random-string`. We will need this value in later configuration steps.
+
+ 
+
+7. Click **Deploy**.
+
+ 
+
+### 2. Check Service Endpoint
+
+After deploying scoop chart (`devtron-scoop`), you need to check the service endpoint URL for each cluster where you have deployed the Scoop chart.
+
+1. In the **App Details** page of the deployed chart, expand **Networking** and click on **Service**.
+
+2. Locate the service entry with the URL in the format: `.:`. Note the values of `serviceName`, `namespace`, and `port` for each cluster as you will require them in later configuration steps.
+
+
+
+### 3. Fetching Cluster ID
+
+You need to fetch the cluster ID for each cluster where you have deployed the scoop chart (`devtron-scoop`).
+
+1. Go to **Infrastructure Management** → **Resource Browser**.
+
+2. Click on the cluster, in which you have deployed the `devtron-scoop` chart. A new page will open.
+
+3. Look at the URL in your browser’s address bar.
+
+ For example: `https://abc.devtron.com/dashboard/infrastructure-management/resource-browser/1/node/k8sEmptyGroup`.
+
+ Here, the number appearing after `/resource-browser/` is the cluster ID. In this example, the cluster ID is `1`.
+
+ 
+
+Before proceeding to the next step, ensure, that you have noted the values of `PASS_KEY`, `serviceName`, `namespace`, and `port` for each cluster where you have deployed the Scoop chart.
+
+### 4. Update ConfigMap
+
+Now that you’ve collected all the required values for: **cluster ID**, **serviceName**, **namespace**, **port**, and **PASS_KEY** for all the clusters where you have deployed the Scoop chart. The next step is to add them to the **devtron-cm** / **orchestrator-cm** ConfigMap
+
+::: info Note
+The **orchestrator-cm** ConfigMap will be available only if you have Devtron managed setup.
+:::
+
+1. In a new tab, go to **Infrastructure Management** → **Resource Browser** → `default-Cluster` → **Config & Storage** → **ConfigMap**
+
+2. Edit the **devtron-cm** / **orchestrator-cm** ConfigMap by clicking **Edit Live Manifest**
+
+ Ensure the following entry is present in the ConfigMap (create one if it doesn’t exist).
+ This flag defines the target clusters and their endpoints of the Scoop service deployed in those clusters:
+
+ 
+
+ ```json
+ SCOOP_CLUSTER_CONFIG: |-
+ {
+ "1": { # Cluster_ID
+ "serviceName": "scoop-service",
+ "passKey": "random-string",
+ "enableResourceList": false,
+ "namespace": "devtroncd",
+ "port": "80"
+ },
+ "2": { # Cluster_ID
+ "serviceName": "scoop-service",
+ "passKey": "random-string",
+ "enableResourceList": false,
+ "namespace": "monitoring",
+ "port": "80"
+ }
+ }
+ ```
+
+ You can also mention the flag in a single-line format instead of the multi-line format shown above. In this case, the YAML indicator `|-` is removed, and the entire JSON block is written on one line, as shown below:
+
+ ```json
+ SCOOP_CLUSTER_CONFIG: '{"1":{"serviceName":"scoop-service","passKey":"random-string","enableResourceList":false,"namespace":"devtroncd","port":"80"},"2":{"serviceName":"scoop-service","passKey":"custom-passkey","enableResourceList":false,"namespace":"monitoring","port":"80"}}'
+ ```
+
+ Both formats work the same, the multi-line format is just easier to read and maintain.
+
+ #### Understanding the configuration
+
+ | **Field** | **Description** |
+ |------------|-----------------|
+ | **SCOOP_CLUSTER_CONFIG** | The key that stores connection details for all your clusters |
+ | **\|-** | A YAML indicator that allows you to write the JSON block across multiple lines for better readability |
+ | **"1" and "2"** | The cluster IDs of your clusters (as seen in the Resource Browser URL). Each ID represents a unique cluster where Scoop is deployed |
+ | **serviceName** | The name of the Scoop service you noted from the **Service** tab while checking the endpoint |
+ | **passKey** | The value of authentication key (`PASS_KEY`) that you defined (or left as default) during Scoop chart deployment |
+ | **enableResourceList** | A flag that controls whether resource-level details are fetched. Keep it **false** unless you specifically need that data |
+ | **namespace** | The namespace of the Scoop service you noted from the **Service** tab while checking the endpoint |
+ | **port** | The port number of the Scoop service you noted from the **Service** tab while checking the endpoint |
+
+ In this example:
+
+ * Cluster 1 (with cluster ID `1`) uses `scoop-service` (service name), running in the `devtroncd` namespace on port `80`.
+ * Cluster 2 (with cluster ID `2`) uses `scoop-service` (service name), running in the `monitoring` namespace on port `80`.
+
+3. After editing, click **Review and save changes** to review the changes you have made.
+
+4. Click **Apply Changes**.
+
+### 5. Restart Deployment
+
+1. Go to **Infrastructure Management** → **Resource Browser** → `default cluster` → **Workloads** → **Deployment**.
+
+2. Click the checkbox next to the `devtron` **Deployment** workload and restart it using the **`⟳`** button.
+
+ 
+
+### 6. Perform Hard Refresh
+
+Perform a hard refresh of the browser to clear the cache:
+* **Mac**: Hold down `Cmd` and `Shift` and then press `R`
+* **Windows/Linux**: Hold down `Ctrl` and then press `F5`
+
+---
+
+## Adding More Clusters to Scoop Configuration
+
+If you want to enable **Pod Last Restart Snapshot** for more or new clusters in the future, you don’t need to recreate or remove the existing configuration. Instead, you can follow the same process:
+
+1. Deploy the **Scoop** chart in each of the new clusters.
+2. Collect the respective **cluster ID**, **serviceName**, **namespace**, **port**, and **PASS_KEY** values.
+3. Edit the existing **devtron-cm** ConfigMap and **add** the new cluster configurations under the same `SCOOP_CLUSTER_CONFIG` flag.
+
+You should not delete or replace the existing `SCOOP_CLUSTER_CONFIG` flag, you just need to append the new cluster configurations.
+For example, if your ConfigMap currently contains configurations for two clusters (`1` and `2`) and you want to add two more (`3` and `4`), your updated configuration should include all four clusters:
+
+#### Multi-line Format
+```json
+SCOOP_CLUSTER_CONFIG: |-
+ {
+ "1": {
+ "serviceName": "scoop-service",
+ "passKey": "random-string",
+ "enableResourceList": false,
+ "namespace": "devtroncd",
+ "port": "80"
+ },
+ "2": {
+ "serviceName": "scoop-service",
+ "passKey": "random-string",
+ "enableResourceList": false,
+ "namespace": "monitoring",
+ "port": "80"
+ },
+ "3": {
+ "serviceName": "scoop-service",
+ "passKey": "random-string",
+ "enableResourceList": false,
+ "namespace": "staging",
+ "port": "80"
+ },
+ "4": {
+ "serviceName": "scoop-service",
+ "passKey": "random-string4",
+ "enableResourceList": false,
+ "namespace": "prod",
+ "port": "80"
+ }
+ }
+```
+
+#### Single-line Format
+
+```json
+SCOOP_CLUSTER_CONFIG: '{"1":{"serviceName":"scoop-service","passKey":"random-string","enableResourceList":false,"namespace":"devtroncd","port":"80"},"2":{"serviceName":"scoop-service","passKey":"random-string","enableResourceList":false,"namespace":"monitoring","port":"80"},"3":{"serviceName":"scoop-service","passKey":"unique-key-3","enableResourceList":false,"namespace":"staging","port":"80"},"4":{"serviceName":"scoop-service","passKey":"unique-key-4","enableResourceList":false,"namespace":"prod","port":"80"}}'
+```
\ No newline at end of file
diff --git a/docs/user-guide/resource-browser/silver-surfer-internals.md b/docs/user-guide/resource-browser/silver-surfer-internals.md
new file mode 100644
index 0000000000..3007a98290
--- /dev/null
+++ b/docs/user-guide/resource-browser/silver-surfer-internals.md
@@ -0,0 +1,169 @@
+---
+title: Silver Surfer Internals
+sidebar_label: Silver Surfer Internals
+---
+
+# Silver Surfer Internals
+
+This page explains how **Silver Surfer** works internally. It is a technical reference for those who want to understand the engine behind Devtron's [Cluster Upgrade Compatibility](./cluster-upgrade-compatibility.md) check. If you only want to *use* the feature, refer to [Cluster Upgrade Compatibility](./cluster-upgrade-compatibility.md) instead.
+
+## What Is Silver Surfer?
+
+[Silver Surfer](https://github.com/devtron-labs/silver-surfer) (its binary is named `kubedd`) is an **API-version compatibility checker and migration-path advisor** for Kubernetes objects. When you plan to upgrade a cluster to a newer Kubernetes version, Silver Surfer checks each object in the cluster against the **OpenAPI (swagger) specification that Kubernetes ships with the target release** and reports:
+
+* which objects use an API version that is **removed** in the target version,
+* which use an API version that is **deprecated**,
+* which have a **newer API version available**, and
+* which are **unchanged**.
+
+For each object, it also states whether the object can be migrated with just an `apiVersion` change, needs field-level fixes first, or cannot be migrated as-is.
+
+It has two entry points:
+
+* **CLI (`kubedd`)** — takes manifests from files/directories, stdin, or a live cluster (via kubeconfig).
+* **gRPC service** — a wire-injected server that Devtron's orchestrator calls. Devtron sends the target Kubernetes version and the cluster connection config, and receives back the categorized results.
+
+---
+
+## Architecture
+
+The repository is organized into an orchestration layer, a core engine (`pkg/`), and a gRPC server wrapper (`app/`):
+
+| Path | Responsibility |
+| :--- | :--- |
+| `main.go` | CLI entry (cobra `RootCmd`). Dispatches to `processFiles(args)` or `processCluster()`. |
+| `kubedd/kubedd.go` | Orchestration. `Validate([]byte, *Config)` for files/stdin and `ValidateCluster(*Cluster, *Config)` for a live cluster. Loads schemas, splits YAML documents, invokes the validator, filters results. |
+| `pkg/K8sSchemaParser.go` | Schema acquisition (download/load), swagger→OpenAPI 3 conversion, and the `KubeChecker` façade. |
+| `pkg/Validator.go` | The core engine. Builds the kind-info index, performs version comparison, and runs `ValidateObject`. |
+| `pkg/Visitor.go` | Custom recursive JSON walker (`VisitJSON`) for field-level deprecation detection. |
+| `pkg/Cluster.go` | Live-cluster access via client-go discovery + dynamic client (`FetchK8sObjects`). |
+| `pkg/Types.go` | Result types — `ValidationResult`, `SummaryValidationResult`, `SchemaError`, `KindInfo`. |
+| `pkg/Util.go` | GVK parsing and version comparison (`compareVersion`, `getVersionType`). |
+| `pkg/Filter.go` | Post-processing filters (ignore keys, exclude noisy errors). |
+| `pkg/Output.go` | Output managers — human-readable tables, JSON, and TAP. |
+| `app/` | gRPC server wrapper that reuses `kubedd.ValidateCluster` to serve Devtron. |
+
+---
+
+## Core Workflow
+
+### 1. Ingesting Kubernetes objects
+
+* **From files/stdin**: the input is read and split on the YAML document separator (`\n---\n`); each document is validated independently. Directory input collects `.yaml`/`.yml` files (respecting ignore patterns).
+* **From a live cluster**: Silver Surfer builds a client-go discovery + dynamic client, determines the kinds to fetch from the server version, and lists live objects (skipping list/review/binding pseudo-resources). For each object it prefers the `kubectl.kubernetes.io/last-applied-configuration` annotation, falling back to the live manifest.
+
+### 2. Obtaining the target version's schema
+
+Schemas are **not bundled** in the repository — they are fetched at runtime (or read from a local path in air-gapped setups). The schema is downloaded from the Kubernetes source for the target release:
+
+```
+https://raw.githubusercontent.com/kubernetes/kubernetes/release-/api/openapi-spec/swagger.json
+```
+
+If the target version's spec is not found (HTTP 404), Silver Surfer returns an "OpenAPI spec not found" error — this is why an unsupported target version is rejected.
+
+Once downloaded, the schema is prepared through the following pipeline (`loadOpenApi2`):
+
+1. Remove the problematic `IntOrString.format` field.
+2. Parse the spec as **OpenAPI 2 (swagger)**.
+3. Convert it to **OpenAPI 3**.
+4. Re-inject `IntOrString` as `{"oneOf": [{"type": "string"}, {"type": "integer"}]}` so int-or-string fields validate correctly.
+5. Reload and validate the resulting OpenAPI 3 document.
+
+Objects are always validated against the **target** version's schema. In the live-cluster flow, the source/server version is used only to know which kinds to fetch.
+
+### 3. Building the kind-info index
+
+From the target schema, Silver Surfer builds an index (`buildKindInfoMap`) keyed by (lower-cased) `kind`. For each schema definition that carries the `x-kubernetes-group-version-kind` extension it records a `KindInfo`:
+
+```go
+type KindInfo struct {
+ Version string
+ Group string
+ RestPath string // non-empty ⇒ this GVK is actually served by the API server
+ ComponentKey string // schema definition name used for validation lookup
+ IsGA bool
+}
+```
+
+A key insight: the index scans the spec's `Paths` for POST/PUT operations and maps each GVK to its REST path. **A non-empty `RestPath` means that API version is actually served in the target version.** This is how a *deprecated-but-still-present* version is distinguished from a *truly removed* one.
+
+Each kind's list of `KindInfo` is **sorted by version**, so the last element is the newest available version.
+
+### 4. Comparing versions
+
+Version ordering (`compareVersion` / `getVersionType`) ranks versions by:
+
+1. `extensions` group lowest,
+2. numeric major version,
+3. **version type** — `alpha` < `beta` < `ga`,
+4. minor number (a plain GA `vN` sorts highest).
+
+This ordering is what identifies the "latest" available API version for a kind in the target schema.
+
+### 5. Validating and categorizing an object
+
+`ValidateObject` is the heart of the engine. For a given object it resolves two lookups via `getKindsMappings`:
+
+* **`original`** — the schema whose Group+Version exactly matches the object's current `apiVersion` **and** has a non-empty `RestPath` (i.e., the current version is still served in the target).
+* **`latest`** — the newest `KindInfo` for that kind in the target.
+
+It then branches:
+
+* If **`original` is present**, the current API version still exists in the target. The object is validated against the `original` schema; validation errors and deprecations "against current" are recorded, and the `Deprecated` flag is set from the schema description.
+* Else if **`latest` is absent**, the kind is gone entirely (e.g., `PodSecurityPolicy`) → `Deleted = true`.
+* Else if **`latest` is present**, the current version is gone but a newer one exists → `Deleted = true` (this is the **Removed** case).
+
+Additionally, if a newer version exists (`original != latest`), the object is *also* validated against the `latest` schema, recording errors and deprecations "against latest" and setting `LatestAPIVersion`.
+
+Validation against a schema (`applySchema`) does three things:
+
+1. Resolves the schema (following `$ref` chains).
+2. Runs the custom `VisitJSON` walker for field-level deprecation detection.
+3. Sets the resource-level `Deprecated` flag if the schema description contains "deprecated".
+4. Runs the structural (kin-openapi) validation for schema conformance.
+
+### 6. Detecting deprecations
+
+`VisitJSON` is a custom recursive walker (separate from structural validation). At each node it checks whether the corresponding schema's description contains the substring `"deprecated"` (case-insensitive); if so, it emits an error carrying the JSON **path** and the description as the **reason**. It descends only into keys present in the schema's properties. This is how **field-level** deprecations — not just whole-resource deprecations — are surfaced.
+
+### 7. Determining the migration path
+
+The migration path is derived from the combination of `Deleted`, `Deprecated`, `LatestAPIVersion`, and the per-target error counts:
+
+| Condition | Migration status |
+| :--- | :--- |
+| Errors exist against the latest version | **N issue(s): fix issues before migration** |
+| Current version has no served endpoint in target | **Alert! cannot migrate Kubernetes version** |
+| Otherwise | **Can be migrated with just an apiVersion change** |
+
+---
+
+## How Categorization Is Decided
+
+Categorization is computed **entirely against the target version's OpenAPI schema**, using the `original` and `latest` lookups described above:
+
+| Category | Condition |
+| :--- | :--- |
+| **Removed** | The object's current `apiVersion` has no served endpoint (no `RestPath`) in the target version. |
+| **Deprecated** | The current `apiVersion` is still served, but the target schema's description (resource- or field-level) marks it deprecated. |
+| **Newer versions available** | The current `apiVersion` is still served, but a higher-sorted version exists for the kind (`original != latest`). |
+| **Unchanged** | The current `apiVersion` is the latest and produced no validation or deprecation errors. |
+
+The output bucketing priority is: `Deleted` → **Removed**; else `Deprecated` → **Deprecated**; else `LatestAPIVersion` set → **Newer**; else → **Unchanged**.
+
+---
+
+## Output
+
+The output format is selectable (`-o/--output`):
+
+* **stdout** (default) — colored, grouped tables: Removed (red), Deprecated (yellow), Newer versions (yellow), Unchanged (green). Each group renders a summary table (namespace, name, kind, current API version, replace-with API version, migration status) plus deprecation and validation-error tables. If nothing needs attention, it prints a success message.
+* **json** — an indented array of `SummaryValidationResult`, skipping clean objects. Each entry contains `Kind`, `ResourceName`, `ResourceNamespace`, `APIVersion`, `LatestAPIVersion`, `Deleted`, `Deprecated`, `IsVersionSupported`, and the four error/deprecation lists (`ErrorsForOriginal`, `ErrorsForLatest`, `DeprecationForOriginal`, `DeprecationForLatest`), each error being `{Path, SchemaField, Reason, Origin}`. **This is the form the gRPC service returns to Devtron**, which then groups it into the Removed / Deprecated / New Versions sections shown in the UI.
+* **tap** — TAP-protocol output for CI tooling.
+
+---
+
+## How Devtron Uses Silver Surfer
+
+When you run the [Cluster Upgrade Compatibility](./cluster-upgrade-compatibility.md) check in the Resource Browser, Devtron's orchestrator calls Silver Surfer's gRPC service with the **target Kubernetes version** and the **cluster connection config**. Silver Surfer fetches the live objects, downloads and prepares the target version's OpenAPI schema, validates every object, and returns the JSON `SummaryValidationResult` list. Devtron then splits these into the **Removed ApiVersion**, **Deprecated ApiVersion**, and **New Versions Available** sections and renders them with per-object migration status.
diff --git a/docs/user-guide/resource-recommender/resource-recommender.md b/docs/user-guide/resource-recommender/resource-recommender.md
new file mode 100644
index 0000000000..736869d049
--- /dev/null
+++ b/docs/user-guide/resource-recommender/resource-recommender.md
@@ -0,0 +1,151 @@
+# Resource Recommender [](https://devtron.ai/pricing)
+
+## Introduction
+
+The **Resource Recommender** analyzes how your workloads actually consume CPU and memory over time and suggests right-sized resource **requests** and **limits**. This helps you avoid two common problems:
+
+* **Over-provisioning** — paying for CPU/memory your workloads never use.
+* **Under-provisioning** — workloads getting CPU-throttled or killed (OOMKilled) because they were given too little.
+
+Recommendations are generated from historical usage metrics collected by **Prometheus** running on your cluster. The recommender periodically scans supported workloads and stores the latest recommendation alongside the current configuration, so you can compare the two and apply the suggested values.
+
+:::info
+### Prerequisites
+* This is an **Enterprise-only** feature and must be enabled by a super-admin.
+* The target cluster must have a reachable **Prometheus** endpoint configured. Without it, recommendations cannot be generated.
+:::
+
+---
+
+## Supported Workloads
+
+The Resource Recommender can generate recommendations for the following Kubernetes resource types:
+
+| Group / Version | Kind |
+| --- | --- |
+| `apps/v1` | Deployment |
+| `apps/v1` | StatefulSet |
+| `apps/v1` | ReplicaSet |
+| `batch/v1` | Job |
+| `batch/v1` | CronJob |
+| `argoproj.io/v1alpha1` | Rollout (Argo Rollouts) |
+| `v1` | Pod |
+
+Recommendations are computed per **container** for both **CPU** (in cores) and **Memory** (in MiB).
+
+---
+
+## Enabling the Feature
+
+The Resource Recommender is disabled by default. A super-admin (or whoever manages your Devtron installation values) must enable it on the Devtron orchestrator.
+
+Set the following environment variable on the Devtron orchestrator deployment:
+
+| Variable | Value | Description |
+| --- | --- | --- |
+| `FEATURE_RESOURCE_RECOMMENDATION_ENABLE` | `true` | Master switch that turns the Resource Recommender on. Defaults to `false`. |
+
+:::warning
+### Who Can Perform This Action?
+Enabling the feature requires changing the orchestrator's installation/configuration values, which is a super-admin / cluster-operator task.
+:::
+
+---
+
+## Configuration
+
+Once the feature is enabled, the behavior of the recommendation scan job (internally referred to as **KRR** – Kubernetes Resource Recommender) is controlled by the environment variables below. The defaults are suitable for most setups; adjust them only if you have specific requirements.
+
+### Scan Job Settings
+
+| Variable | Default | Description |
+| --- | --- | --- |
+| `KRR_DOCKER_IMAGE` | *(empty)* | Container image used to run the recommendation scan job. **Required** for the scan to run. |
+| `KRR_SYNC_SERVICE_ACCOUNT` | `krr-sync` | Service account the scan job runs under in the cluster. |
+| `KRR_SYNC_JOB_RESOURCES_OBJ` | `{}` | Resource requests/limits for the scan job pod itself, as JSON. Example: `{"requests":{"cpu":"500m","memory":"512Mi"}}`. |
+| `KRR_SYNC_JOB_CRON_SCHEDULE` | `0 0 * * *` | Cron schedule for the automatic scan. Default runs daily at midnight. |
+| `KRR_ACTIVE_DEADLINE_SECONDS` | `15000` | Maximum runtime for the scan job in seconds (~4 hours) before it is terminated. |
+| `KRR_SYNC_JOB_SHUTDOWN_WAIT_DURATION` | `120` | Seconds to wait for graceful shutdown before force-terminating the job. |
+| `KRR_SYNC_JOB_HTTP_PORT` | `8080` | Port used by the scan job for health checks and metrics. |
+| `PARALLELISM_LIMIT_FOR_TAG_PROCESSING` | `1` | Number of workloads processed in parallel during a scan. |
+| `KRR_LOG_LEVEL` | `-1` | Log verbosity: `-1` = debug, `0` = info, `1` = warn, `2` = error. |
+
+### Analysis Settings
+
+These control how recommendations are calculated from Prometheus data.
+
+| Variable | Default | Description |
+| --- | --- | --- |
+| `KRR_MATRIX_TIME_RANGE` | `120h` | How far back the recommender looks at historical metrics (e.g. `120h` = 5 days). A longer range produces more stable recommendations. |
+| `KRR_MATRIX_STEP_INTERVAL` | `5m` | Sampling interval for the Prometheus query. Smaller intervals capture more detail but cost more to query. |
+| `KRR_EVALUATE_STRATEGIES` | `true` | Whether to evaluate the recommendation strategies during analysis. |
+| `KRR_IGNORE_CPU_THROTTLING` | `false` | When `true`, CPU throttling events are ignored while computing the recommendation. |
+| `KRR_IGNORE_OOM` | `false` | When `true`, Out-Of-Memory (OOM) events are ignored while computing the recommendation. |
+| `MIN_CPU_REQUEST` | `0.1` | Minimum CPU request (in cores) the recommender will suggest. Set to `0` to disable the floor. |
+| `MIN_MEMORY_REQUEST` | `1.0` | Minimum memory request (in MiB) the recommender will suggest. Set to `0` to disable the floor. |
+
+:::info
+### Tuning Tips
+* Increase `KRR_MATRIX_TIME_RANGE` (e.g. to `168h` for 7 days) if your workloads have weekly traffic patterns, so peaks are captured.
+* Keep `KRR_IGNORE_OOM=false` and `KRR_IGNORE_CPU_THROTTLING=false` (the defaults) so the recommender accounts for resource starvation events when sizing.
+* Use `MIN_CPU_REQUEST` / `MIN_MEMORY_REQUEST` to prevent the recommender from suggesting unrealistically small values for lightly-used services.
+:::
+
+---
+
+## Using the Resource Recommender
+
+### Trigger a Scan
+
+Recommendations refresh automatically on the configured cron schedule (`KRR_SYNC_JOB_CRON_SCHEDULE`). You can also trigger a scan on demand for a cluster.
+
+* **Endpoint:** `POST /resource/recommendation/sync`
+* **Body:**
+ ```json
+ { "clusterId": 1 }
+ ```
+
+:::warning
+### Who Can Perform This Action?
+Triggering a scan requires **update** permission on the target cluster.
+:::
+
+### View Recommendation Status
+
+Check when a cluster was last scanned and which workload types are supported.
+
+* **Endpoint:** `GET /resource/{clusterId}/recommendation/details`
+* **Returns:** the supported resource types (GVKs) and the `lastScannedOn` timestamp.
+
+### View Recommendations
+
+List the current-vs-recommended resource values for workloads in a cluster (optionally filtered by namespace or workload type).
+
+* **Endpoint:** `POST /resource/recommendation/list`
+* For each container you get:
+ * **Current** — the CPU/memory request and limit configured today.
+ * **Recommended** — the suggested CPU/memory request and limit.
+ * **Delta** — the percentage change between current and recommended.
+
+This lets you quickly spot workloads that are significantly over- or under-provisioned.
+
+---
+
+## How It Works
+
+1. When enabled, Devtron schedules a recommendation scan job on each configured cluster according to `KRR_SYNC_JOB_CRON_SCHEDULE` (or whenever you trigger a sync manually).
+2. The scan job queries the cluster's **Prometheus** for historical CPU and memory usage over the configured time range (`KRR_MATRIX_TIME_RANGE`), sampled at `KRR_MATRIX_STEP_INTERVAL`.
+3. For each supported workload and container, it computes a recommended CPU/memory **request** and **limit**, factoring in throttling and OOM events (unless ignored) and honoring the minimum request floors.
+4. The results are stored and surfaced in the UI/API, where you can compare current vs. recommended values and apply them to your workloads.
+
+---
+
+## Troubleshooting
+
+| Symptom | Likely Cause | Resolution |
+| --- | --- | --- |
+| No recommendations appear for a cluster | Prometheus URL not configured for the cluster | Add a reachable Prometheus URL in **Global Configurations → Clusters & Environments**. |
+| Feature/options not visible | Feature flag disabled | Ensure `FEATURE_RESOURCE_RECOMMENDATION_ENABLE=true` on the orchestrator. |
+| Scan job never runs | Scan image not set | Set `KRR_DOCKER_IMAGE` to a valid image URI. |
+| Recommendations look too small | No minimum floor set | Set `MIN_CPU_REQUEST` / `MIN_MEMORY_REQUEST` to sensible minimums. |
+| Scan times out | Job exceeds deadline on large clusters | Increase `KRR_ACTIVE_DEADLINE_SECONDS` and/or `PARALLELISM_LIMIT_FOR_TAG_PROCESSING`. |
diff --git a/docs/user-guide/resource-watcher.md b/docs/user-guide/resource-watcher.md
old mode 100644
new mode 100755
index 62e0426239..71e9825ca3
--- a/docs/user-guide/resource-watcher.md
+++ b/docs/user-guide/resource-watcher.md
@@ -1,6 +1,6 @@
# Resource Watcher
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
An incident response if delayed can impact businesses, revenue, and waste valuable engineering time. Devtron's Resource Watcher enables you to perform automated actions upon the occurrence of events:
@@ -14,16 +14,16 @@ You can make the Resource Watcher listen to the above events and accordingly run
## Creating a Watcher
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to create a watcher.
-{% endhint %}
+:::
This page allows you to create a watcher to track events and run a job. It also shows the existing list of watchers (if any).
1. Click **+ Create Watcher**.
- 
+ 
+
Figure 1: Watchers - Page
2. Creating a watcher consists of 4 parts, fill all the sections one by one:
* [Basic Details](#basic-details)
@@ -31,13 +31,15 @@ This page allows you to create a watcher to track events and run a job. It also
* [Intercept Change in Resources](#intercept-change-in-resources)
* [Execute Runbook](#execute-runbook)
- 
+ 
+
Figure 2: Create Watcher - Window
### Basic Details
Here, you can give a name and description to your watcher.
-
+
+
Figure 3: Adding Name and Description of Watcher
### Namespaces to Watch
@@ -45,22 +47,25 @@ Here, you can select the [namespaces](../reference/glossary.md#namespace) whose
* You can watch the namespace(s) across **All Clusters** (existing and future).
- 
+ 
+
Figure 4: Choosing Namespaces of all Clusters
* Or you can watch namespace(s) of **Specific Clusters**.
- 
+ 
+
Figure 5: Choosing Namespaces of Specific Clusters
-{% hint style="info" %}
+:::info
In both the above options, if you choose 'Specific Namespaces', you can further decide whether to track the namespaces you enter (by clicking 'Include selections') or to track the namespaces except the ones you enter (by clicking 'Exclude selections').
-{% endhint %}
+:::
### Intercept Change in Resources
Here, you can select the exact Kubernetes resource(s) you wish to track for changes (in the namespace(s) you selected in the previous step).
-
+
+
Figure 6: Picking Resources to Track
* You can choose the resource from the **Resource kind(s) to watch** dropdown. Enter the Group/Version/Kind (GVK) if it's a custom resource definition (CRD), for e.g., `install.istio.io/v1apha1/IstioOperator`
@@ -74,11 +79,11 @@ Here, you can select the exact Kubernetes resource(s) you wish to track for chan
* Enter a [CEL expression](https://kubernetes.io/docs/reference/using-api/cel/) to catch a specific change in the resource's manifest.
-{% hint style="info" %}
+:::info
* **If resource is created** - Use 'DEVTRON_FINAL_MANIFEST'
* **If resource is updated** - Both 'DEVTRON_INITIAL_MANIFEST' and 'DEVTRON_FINAL_MANIFEST' can exist
* **If resource is deleted** - Use 'DEVTRON_INITIAL_MANIFEST'
-{% endhint %}
+:::
**Example**: `DEVTRON_FINAL_MANIFEST.status.currentReplicas == DEVTRON_FINAL_MANIFEST.spec.maxReplicas`
@@ -88,7 +93,8 @@ Here, you can select the exact Kubernetes resource(s) you wish to track for chan
The **Trigger Devtron Job** option allows you to choose a Devtron job pipeline that triggers a job (e.g., executing a script, emailing your stakeholders, etc.) whenever the watcher intercepts any changes.
-
+
+
Figure 7: Trigger Devtron Job
Follow the below steps to trigger Devtron job:
@@ -110,13 +116,15 @@ Follow the below steps to trigger Devtron job:
The watcher is now ready to intercept changes to selected resources and execute the configured job.
-
+
+
Figure 8: Intercepted Changes
#### Trigger Webhook
The Trigger Webhook option allows you to configure a [Webhook](https://hookdeck.com/webhooks/guides/what-are-webhooks-how-they-work) URL along with the payload (data) to be sent whenever the webhook is triggered. For example, to receive notifications in Slack, you can provide the Slack webhook URL and define the payload accordingly.
-
+
+
Figure 9: Trigger Webhook
Follow the below steps to trigger webhook:
@@ -140,22 +148,23 @@ Follow the below steps to trigger webhook:
The watcher is now ready to intercept changes to selected resources and trigger the webhook.
-
+
+
Figure 10: Intercepted Changes
---
## Viewing Intercepted Changes
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to view intercepted changes.
-{% endhint %}
+:::
### Details
This page allows you to view the changes to Kubernetes resources that you have selected for tracking changes.
-
+
+
Figure 11: Intercepted Changes - Page
It comes with the following items to help you locate the resource, where the event has been intercepted:
@@ -180,19 +189,23 @@ You get the following details in the results shown on the page.
You can check the changes in manifest by clicking **View Manifest** in `Change In Resource` column.
-
+
-
+
+
Figure 12a: Updated Resource - Initial and Final Manifest
### Job Execution Log
You can check the logs of the job executed when the Resource Watcher intercepts any change by clicking **logs**.
-
+
+
Figure 13: Job Progress
---
@@ -200,7 +213,7 @@ You can check the logs of the job executed when the Resource Watcher intercepts
### Live Stream Traffic Surge
-A live streaming sports application experiences a surge in viewers during a major game. The Horizontal Pod Autoscaler (HPA) might not be able to handle the unexpected traffic if it's capped at a low max replica count.
+A live-streaming sports application experiences a surge in viewers during a major game. The Horizontal Pod Autoscaler (HPA) might not be able to handle the unexpected traffic if it's capped at a low max replica count.
1. Create a watcher named 'Live Stream Scaling Alert'.
2. Monitor updates to HPA resource in the application's namespace.
@@ -211,5 +224,4 @@ A live streaming sports application experiences a surge in viewers during a majo
A stock trading application constantly updates stock prices for its traders. If the pods become unhealthy, traders might see incorrect stock prices leading to bad investments.
1. Create a watcher named 'Pod Health Monitor'.
-2. Track the pod workload of your application, if `DEVTRON_FINAL_MANIFEST.status.phase != 'Running'`, trigger a job that sends an Email/Slack alert with pod details.
-
+2. Track the pod workload of your application, if `DEVTRON_FINAL_MANIFEST.status.phase != 'Running'`, trigger a job that sends an Email/Slack alert with pod details.
\ No newline at end of file
diff --git a/docs/user-guide/resource-watcher/resource-watcher.md b/docs/user-guide/resource-watcher/resource-watcher.md
new file mode 100644
index 0000000000..e5b2bd07fa
--- /dev/null
+++ b/docs/user-guide/resource-watcher/resource-watcher.md
@@ -0,0 +1,258 @@
+# Resource Watcher [](https://devtron.ai/pricing)
+
+## Introduction
+
+An incident response if delayed can impact businesses, revenue, and waste valuable engineering time. Devtron's **Resource Watcher** enables you to perform automated actions (auto-remediation) upon the occurrence of Kubernetes events:
+
+* **Create Event** - Occurs when a new Kubernetes resource is created, for e.g., a new pod spun up to handle increased traffic.
+* **Update Event** - Occurs when an existing Kubernetes resource is modified, for e.g., deployment configuration tweaked to increase the replica count.
+* **Delete Event** - Occurs when an existing Kubernetes resource is deleted, for e.g., deletion of an orphaned pod.
+
+You can make the Resource Watcher listen to the above events and accordingly run a job you wish to get done, for e.g., increasing memory, executing a script, raising a Jira ticket, emailing your stakeholders, sending Slack notifications, and many more. Since manual intervention is absent, the timely response of this auto-remediation system improves your operational efficiency.
+
+:::info
+### Prerequisites
+* This is an **Enterprise-only** feature.
+* You must have **super-admin** permission to create watchers and view intercepted changes.
+* The **Scoop** component must be running on every cluster you want to watch. Scoop is the per-cluster service that observes resource events, evaluates your filter, and reports intercepted changes back to Devtron. Clusters without Scoop will not produce intercepted events.
+* To run a job on interception, you need at least one **Devtron Job pipeline** already configured (for the Webhook trigger type, a reachable webhook URL).
+:::
+
+---
+
+## Supported Events
+
+A watcher can listen to one or more of the following event types on the resources you select:
+
+| Event Type | Description |
+| ---------- | ----------------------------------------------------------------------- |
+| Created | Triggers the watcher when your Kubernetes resource is created |
+| Updated | Triggers the watcher when your existing Kubernetes resource is modified |
+| Deleted | Triggers the watcher when your existing Kubernetes resource is deleted |
+
+You can watch any built-in Kubernetes resource (Deployment, Pod, HPA, StatefulSet, etc.) as well as **Custom Resource Definitions (CRDs)** by specifying their Group/Version/Kind (GVK).
+
+---
+
+## How It Works
+
+1. You create a **watcher** that defines *what* to watch (namespaces + resource kinds + event types), *when* to act (an optional CEL filter expression), and *what* to do (a runbook — a Devtron Job pipeline or a webhook).
+2. Devtron pushes this configuration to the **Scoop** service running on each selected cluster.
+3. Scoop observes the live resource events. For every matching event it evaluates your **CEL filter expression** against the resource manifest(s).
+4. If the expression passes (or is empty), the event is recorded as an **intercepted change** and the configured runbook is triggered.
+5. The triggered job can read the resource state through the `DEVTRON_INITIAL_MANIFEST` and `DEVTRON_FINAL_MANIFEST` environment variables.
+
+---
+
+## Creating a Watcher
+
+:::warning
+### Who Can Perform This Action?
+Users need to have super-admin permission to create a watcher.
+:::
+
+This page allows you to create a watcher to track events and run a job. It also shows the existing list of watchers (if any).
+
+1. Click **+ Create Watcher**.
+
+ 
+
+2. Creating a watcher consists of 4 parts, fill all the sections one by one:
+ * [Basic Details](#basic-details)
+ * [Namespaces to Watch](#namespaces-to-watch)
+ * [Intercept Change in Resources](#intercept-change-in-resources)
+ * [Execute Runbook](#execute-runbook)
+
+ 
+
+### Basic Details
+
+Here, you can give a name and description to your watcher.
+
+* **Name** is mandatory and must be unique across active watchers.
+
+
+
+### Namespaces to Watch
+
+Here, you can select the [namespaces](../reference/glossary.md#namespace) whose [Kubernetes resource](../reference/glossary.md#objects) you wish to monitor for changes.
+
+* You can watch the namespace(s) across **All Clusters** (existing and future).
+
+ 
+
+* Or you can watch namespace(s) of **Specific Clusters**.
+
+ 
+
+:::info
+In both the above options, if you choose 'Specific Namespaces', you can further decide whether to track the namespaces you enter (by clicking 'Include selections') or to track the namespaces except the ones you enter (by clicking 'Exclude selections'). You can also scope by environment category such as all production or all non-production environments.
+:::
+
+### Intercept Change in Resources
+
+Here, you can select the exact Kubernetes resource(s) you wish to track for changes (in the namespace(s) you selected in the previous step).
+
+
+
+* You can choose the resource from the **Resource kind(s) to watch** dropdown. Enter the Group/Version/Kind (GVK) if it's a custom resource definition (CRD), for e.g., `install.istio.io/v1apha1/IstioOperator`
+
+* Choose the event type your watcher should listen to: `Created`, `Updated`, `Deleted`. (See [Supported Events](#supported-events).)
+
+* Enter a [CEL expression](https://github.com/google/cel-spec/blob/master/doc/langdef.md) to catch a specific change in the resource's manifest. Leaving it **empty** matches every event of the selected type.
+
+#### Variables available in the CEL expression
+
+| Variable | Available on | Description |
+| --- | --- | --- |
+| `DEVTRON_FINAL_MANIFEST` (alias `final`) | Created, Updated | The new/final state of the resource |
+| `DEVTRON_INITIAL_MANIFEST` (alias `initial`) | Updated, Deleted | The previous/initial state of the resource |
+| `action` | All | The event type as a string: `CREATED`, `UPDATED`, or `DELETED` |
+
+:::info
+* **If resource is created** - Use 'DEVTRON_FINAL_MANIFEST'
+* **If resource is updated** - Both 'DEVTRON_INITIAL_MANIFEST' and 'DEVTRON_FINAL_MANIFEST' can exist
+* **If resource is deleted** - Use 'DEVTRON_INITIAL_MANIFEST'
+:::
+
+**Example**: `DEVTRON_FINAL_MANIFEST.status.currentReplicas == DEVTRON_FINAL_MANIFEST.spec.maxReplicas`
+
+### Execute Runbook
+
+Here, you can choose what should trigger if your watcher intercepts a matching change. A watcher supports two runbook (trigger) types:
+
+#### Option A — Run a Devtron Job pipeline
+
+* Choose a job pipeline from the **Run Devtron Job pipeline** dropdown. If a pipeline is not selected, the watcher won't intercept matching resource changes even if your defined conditions are met.
+
+* Select the environment in which the job should run. It can either be `devtron-ci` or the source environment (the intercepted namespace where the event has occurred).
+
+* If the job expects input parameters, you may add its key and value under **Runtime input parameters**.
+
+ During a job's execution, its container can access the initial and final resource manifest through special environment variables. These variables are:
+ * `DEVTRON_INITIAL_MANIFEST`
+ * `DEVTRON_FINAL_MANIFEST`
+
+#### Option B — Call a Webhook
+
+Instead of a job, a watcher can notify an external system by calling a webhook when a change is intercepted. For this trigger type you provide:
+
+* **Webhook URL** — the endpoint to call.
+* **Headers** — optional key/value headers (e.g., an authorization token).
+* **Payload** — the request body to send (can reference the intercepted resource data).
+
+This is useful for forwarding events to incident management, chat, or custom automation systems.
+
+Finally, click **Create Watcher**. Your watcher is now ready to intercept the changes to the selected resources.
+
+
+
+---
+
+## Viewing Intercepted Changes
+
+:::warning
+### Who Can Perform This Action?
+Users need to have super-admin permission to view intercepted changes.
+:::
+
+### Details
+
+This page allows you to view the changes to Kubernetes resources that you have selected for tracking changes.
+
+
+
+It comes with the following items to help you locate the resource, where the event has been intercepted:
+
+* Searchbox
+* Cluster filter
+* Namespace filter
+* Action filter (event type, i.e., `Created`, `Updated`, `Deleted`)
+* Watcher filter (to check the intercepted changes of a specific watcher)
+* Time range filter (`from` / `to`)
+
+You get the following details in the results shown on the page.
+
+|Field | Description |
+|-------|-------------|
+|[Change In Resource](#change-in-resource)|Describes the type of change to the Kubernetes resource along with a link to its manifest|
+|[Cluster/Namespace](#namespaces-to-watch) |Shows the cluster and namespace where the tracked Kubernetes resource belongs to|
+|Intercepted By |Shows the name of the watcher that intercepted the change|
+|Intercepted At |Shows the date and time when the event occurred |
+|[Job Execution](#execute-runbook) |Shows the status of the execution of job, e.g., `Initiated`, `Progressing`, `Succeeded`, `Failed`, `Error`|
+|[Logs](#job-execution-log) |Links to the job log, i.e, the `Run history` page of the job|
+
+### Change in Resource
+
+You can check the changes in manifest by clicking **View Manifest** in `Change In Resource` column.
+
+
+
+
+
+
+
+
+
+### Job Execution Log
+
+You can check the logs of the job executed when the Resource Watcher intercepts any change by clicking **logs**.
+
+
+
+---
+
+## API Reference
+
+These endpoints back the Resource Watcher UI. All require a super-admin bearer token.
+
+### Watchers
+
+| Method | Endpoint | Description |
+| --- | --- | --- |
+| `POST` | `/k8s/watcher` | Create a watcher |
+| `GET` | `/k8s/watcher` | List watchers (supports `offset`, `size`, `search`, `order`, `orderBy`) |
+| `GET` | `/k8s/watcher/{identifier}` | Get a watcher by ID |
+| `PUT` | `/k8s/watcher/{identifier}` | Update a watcher |
+| `DELETE` | `/k8s/watcher/{identifier}` | Delete a watcher |
+
+### Intercepted Changes
+
+| Method | Endpoint | Description |
+| --- | --- | --- |
+| `GET` | `/k8s/intercept-events` | List intercepted changes (supports `search`, `from`, `to`, `watchers[]`, `namespaces[]`, `executionStatuses[]`, `selectedActions[]`) |
+| `GET` | `/intercept-event/{identifier}` | Get a single intercepted change |
+
+A watcher definition consists of the event configuration (namespace **selectors**, **resource kinds (GVKs)**, the **CEL filter expression**, and **selected actions**) plus one or more **triggers** (type `DEVTRON_JOB` or `WEBHOOK`).
+
+---
+
+## Use Cases
+
+### Live Stream Traffic Surge
+
+A live streaming sports application experiences a surge in viewers during a major game. The Horizontal Pod Autoscaler (HPA) might not be able to handle the unexpected traffic if it's capped at a low max replica count.
+
+1. Create a watcher named 'Live Stream Scaling Alert'.
+2. Monitor updates to HPA resource in the application's namespace.
+3. When `currentReplicas` count reaches `maxReplicas`, trigger a job that contains the script to increase the replica count.
+
+### Pod Health Monitoring
+
+A stock trading application constantly updates stock prices for its traders. If the pods become unhealthy, traders might see incorrect stock prices leading to bad investments.
+
+1. Create a watcher named 'Pod Health Monitor'.
+2. Track the pod workload of your application, if `DEVTRON_FINAL_MANIFEST.status.phase != 'Running'`, trigger a job that sends an Email/Slack alert with pod details.
+
+---
+
+## Troubleshooting
+
+| Symptom | Likely Cause | Resolution |
+| --- | --- | --- |
+| Watcher created but no changes are intercepted | Scoop is not running on the watched cluster | Ensure the Scoop component is deployed and healthy on each cluster you want to watch. |
+| Matching events occur but the runbook never runs | No job pipeline selected, or trigger misconfigured | Confirm a Devtron Job pipeline (or a valid webhook URL) is selected in the **Execute Runbook** step. |
+| Too many / unwanted interceptions | CEL filter empty or too broad | Add or tighten the CEL expression so only the intended changes match. |
+| CEL expression rejected on save | Invalid syntax, or referencing a manifest not available for that event | Use `DEVTRON_FINAL_MANIFEST` for Created, `DEVTRON_INITIAL_MANIFEST` for Deleted; both are available for Updated. |
+| Job runs but can't read the resource | Manifest env vars not used | Read `DEVTRON_INITIAL_MANIFEST` / `DEVTRON_FINAL_MANIFEST` inside the job container. |
+| Cannot create or view watchers | Insufficient permissions | Resource Watcher actions require super-admin permission. |
diff --git a/docs/user-guide/security-features.md b/docs/user-guide/security-features.md
old mode 100644
new mode 100755
index 88878b04b4..60cb90e4db
--- a/docs/user-guide/security-features.md
+++ b/docs/user-guide/security-features.md
@@ -1,4 +1,4 @@
-# Security Features
+# Overview
## Introduction
@@ -7,10 +7,11 @@ Devtron provides [DevSecOps](https://devtron.ai/videos/devsecops-policies-as-gua
One of the key components of DevSecOps is the detection of security risks. Currently, Devtron supports the following types of scanning:
* Image Scan
-* Code Scan [](https://devtron.ai/pricing)
-* Kubernetes Manifest Scan [](https://devtron.ai/pricing)
+* Code Scan
+* Kubernetes Manifest Scan
-
+
+
Figure 1: Security Scan Results
You can integrate a scanning tool of your choice. By default, Devtron integrates with [Trivy](./integrations/vulnerability-scanning/trivy.md) using which you can scan for the following issues:
@@ -27,9 +28,10 @@ You can integrate a scanning tool of your choice. By default, Devtron integrates
When you commit the code, it's essential to scan it before building a [container image](../reference/glossary.md#image). By scanning early, you can catch and fix problems before they become expensive or time-consuming to remediate later.
-
+
+
Figure 2: Scanning in Pre-CI Stage
-1. In your application, go to **App Configuration** → **Workflow Editor**.
+1. In your Devtron application, go to **Configurations** (tab) → **Workflow Editor**.
2. Click the CI pipeline of your preferred workflow.
@@ -41,13 +43,15 @@ When you commit the code, it's essential to scan it before building a [container
6. Click **Update Pipeline**.
-Based on the results of the scanner, you can also decide whether your CI should proceed further or not. This is possible through **Pass/Failure Condition** setting in the plugin. In the below example, we are allowing image build only if the no. of high vulnerability is zero.
+
Results of Pre-CI scan will be visible under `Code Scan` in the **App Details** page as shown below.
-
+
+
Figure 3: Pre-CI Code Scan Results
### After Building Container Image
@@ -59,7 +63,8 @@ There are 2 options available:
This section contains the steps for comprehensive scan.
-
+
+
Figure 4: Scanning in Post-CI Stage
1. Go to the **Post-build stage** (tab) of your CI pipeline.
@@ -69,13 +74,15 @@ This section contains the steps for comprehensive scan.
Results of Post-CI scan will be visible under `Image Scan` in the **App Details** page as shown below.
-
+
+
Figure 5: Post-CI Image Scan Results
### Before Triggering Deployment
There can be a loophole where the original image built in the CI stage gets compromised later (say, in publicly accessible repository). Therefore, you can scan the image and catch issues before deploying it. On top of that, you can also scan manifests to detect misconfigurations and exposed secrets.
-
+
+
Figure 6: Scanning in Pre-CD Stage
1. Go to the **Pre-Deployment stage** (tab) of your CD pipeline.
@@ -85,15 +92,17 @@ There can be a loophole where the original image built in the CI stage gets comp
Results of Pre-CD scan will be visible under `Image Scan` and `Kubernetes Manifest` in the **App Details** page as shown below.
-
+
+
Figure 7: Pre-CD Scan Results
-### During Helm App Deployment [](https://devtron.ai/pricing)
+### During Helm App Deployment
When you [deploy a helm chart](../user-guide/deploy-chart/deployment-of-charts.md), Devtron will scan the image associated with that helm chart and also the manifests, but unlike Devtron Apps, there is no code scan involved.
Results of helm app scan will be visible under `Image Scan` and `Kubernetes Manifest` in the **App Details** page as shown below.
-
+
+
Figure 8: Helm App Scan Results
### Extras
@@ -106,7 +115,8 @@ You can also check for vulnerabilities within a specific workload such as job, p
* On the right-hand side, click the kebab menu (3 vertical dots).
* Click **Check Vulnerabilities**.
- 
+ 
+
Figure 9: Scanning Workloads - App Details Page
#### From Resource Browser
@@ -115,20 +125,19 @@ You can also check for vulnerabilities within a specific workload such as job, p
* Click a workload within the **Workloads** dropdown.
* Access the **Check Vulnerabilities** option from the kebab menu present to your selected workload.
- 
+ 
+
Figure 10: Scanning Workloads - Resource Browser
---
## Scans and Policies
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to enable vulnerability scanning and to define security policies in Devtron.
-{% endhint %}
+:::
Devtron's Security feature has two primary sections:
1. [**Security Scans**](./security-features/security-scans.md) - You can view the vulnerabilities detected across your applications.
-2. [**Security Policies**](./security-features/security-policies.md) - This allows you to define guardrails to block or allow the deployment of container images depending on the vulnerabilities detected.
-
+2. [**Security Policies**](./security-features/security-policies.md) - This allows you to define guardrails to block or allow the deployment of container images depending on the vulnerabilities detected.
\ No newline at end of file
diff --git a/docs/user-guide/security-features/security-overview.md b/docs/user-guide/security-features/security-overview.md
new file mode 100644
index 0000000000..712646a2a9
--- /dev/null
+++ b/docs/user-guide/security-features/security-overview.md
@@ -0,0 +1,93 @@
+---
+title: Security Overview
+sidebar_label: Overview
+---
+
+The **Security Overview** page gives you a quick summary of all vulnerabilities found across your active deployments. It helps you to:
+* Monitor vulnerabilities across deployments.
+* Identify which ones can be fixed immediately.
+* Ensure consistent security scanning in workflows.
+* Validate that automated blocking policies are working as intended.
+
+By regularly reviewing this dashboard, you can proactively manage risks and maintain a healthy security across your clusters and environments.
+
+---
+
+## At a Glance
+
+This section provides a snapshot of the key vulnerability metrics in your environment.
+
+
+
Figure 1: 'At a Glance' Section
+
+| Metric | Description | Example |
+|--------|--------------|----------|
+| **Total Vulnerabilities** | Total number of vulnerabilities found in active deployments. | Example: 428 vulnerabilities detected across all running apps. |
+| **Fixable Vulnerabilities** | Vulnerabilities that already have fixes or upgrades available. | Example: 209 vulnerabilities can be fixed by updating the base image or library. |
+| **Zero-day Vulnerabilities** | Newly discovered issues that may not yet have patches. | Example: 219 zero-day vulnerabilities were detected last week. |
+
+Use this section to understand overall exposure and prioritize fixable items first.
+
+---
+
+## Severity Insights
+
+The **Severity Insights** section helps you understand the nature and age of vulnerabilities in prod and non-prod deployments.
+
+
+
Figure 2: 'Severity Insights' Section
+
+* **Severity Distribution:** Pie chart showing proportions of Critical, High, Medium, Low, and Unknown severity.
+ *Example: 60% of all findings are High or Critical, suggesting an immediate need for patching.*
+
+* **Age of Discovered Vulnerabilities:** Groups vulnerabilities by how long they’ve existed in deployments.
+ *Example: Most Critical issues are older than 60 days, indicating delayed remediation.*
+
+* **Vulnerability Trend:** Shows daily changes in vulnerability count over the selected time period (upto 90 days).
+ *Example: A spike on 18th Oct could mean a new deployment introduced fresh vulnerabilities.*
+
+These visuals help you identify aging vulnerabilities, observe trends, and measure the impact of remediation efforts.
+
+---
+
+## Deployment Security Status
+
+The **Deployment Security Status** section highlights the current security health of your active deployments and pipelines.
+
+
+
Figure 3: 'Severity Insights' Section
+
+| Indicator | Description | Example |
+|------------|-------------|----------|
+| **Active Deployments with Vulnerabilities** | Percentage of deployments that contain at least one known vulnerability. | Example: 25.7% of all running deployments have vulnerabilities. |
+| **Active Deployments with Unscanned Images** | Percentage of deployments where image scans have not been performed. | Example: 70.5% of deployments use unscanned images, which can hide potential risks. |
+| **Workflows with Scanning not Enabled** | Percentage of CI/CD workflows that are missing security scanning steps. | Example: 74.3% of pipelines don’t have scanning enabled. |
+| **Blocked Deployments** | Count of deployments automatically blocked by security policies over a period of time (upto 90 days) | Example: 1 deployment was blocked in the past 30 days due to a failed security check. |
+
+Use these indicators to verify that scanning coverage is consistent and your automated policies are functioning as expected.
+
+---
+
+## How to Use the Overview
+
+1. **Track trends**
+ Use the charts to see if vulnerabilities are increasing or decreasing over time.
+
+2. **Prioritize fixes**
+ Focus first on Critical and High vulnerabilities that have available fixes.
+
+3. **Improve scanning coverage**
+ Reduce the number of unscanned images and workflows without scanning steps.
+
+4. **Review blocking rules**
+ If too many deployments are blocked, revisit your policy thresholds to strike the right balance between security and delivery speed.
+
+
+### Example Scenario
+
+Let's say your overview page shows: 428 total vulnerabilities, 70% unscanned images, critical issues older than 60 days, you can take the following actions:
+
+* Enable scanning for all pipelines and image registries.
+* Rebuild or patch outdated base images.
+* Set SLAs to ensure Critical issues are remediated within a defined timeframe.
+
diff --git a/docs/user-guide/security-features/security-policies.md b/docs/user-guide/security-features/security-policies.md
old mode 100644
new mode 100755
index dc0f84f886..0ae8bdae46
--- a/docs/user-guide/security-features/security-policies.md
+++ b/docs/user-guide/security-features/security-policies.md
@@ -1,12 +1,10 @@
# Security Policies
-{% hint style="info" %}
-### Prerequisite
-
+:::info Prerequisite
Install any one of the following integrations for scanning vulnerabilities:
* [Clair](../../user-guide/integrations/vulnerability-scanning/clair.md)
* [Trivy](../../user-guide/integrations/vulnerability-scanning/trivy.md)
-{% endhint %}
+:::
Devtron's Security Policies feature allows users to define policies based on the severity levels of vulnerabilities, which include `Critical`, `Moderate`, and `Low`. Users have the flexibility to set policies that either block the deployment of container images with vulnerabilities or allow their deployment.
@@ -14,10 +12,9 @@ With this feature, users can specify their desired actions for each severity lev
For in-depth instructions, refer to the [Configure Security Policies](#configuring-security-policies) section.
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to define or modify security policies.
-{% endhint %}
+:::
---
@@ -32,7 +29,8 @@ You can define policies at the following levels:
* [Environment](#configure-environment-security-policy)
* [Application](#configure-application-security-policy)
-
+
+
Figure 1: Security Policies
However, if you define policies at more than one level, the order of precedence would be as follows:
@@ -60,7 +58,8 @@ Within the Global Security Policies, there are three options available:
| Block if fix is available | Images containing vulnerabilities will be blocked if a fix is available and has not been applied |
| Allow | Images containing vulnerabilities will be allowed to be deployed regardless of whether a fix is available or not |
-
+
+
Figure 2: Configuring Global Security Policy
If critical severity levels are blocked in the Global Security Policy, the same blocking will be applied to the Cluster Security Policy. Likewise, allowing critical levels in the global policy automatically allows them in Cluster Security Policies.
@@ -72,7 +71,11 @@ However, users have the flexibility to explicitly modify these policies as desir
Cluster Security Policies offer the same three options as [Global Security Policies](#configure-global-security-policy) for handling vulnerabilities. However, an extra option called `Inherit` is available too.
-
+
+
When `Inherit` is selected, the policy adopts settings from higher-level options. For example, if critical severity levels are blocked globally, they will also be blocked in Cluster Security Policies. Changing the global policy to allow critical levels will also allow them in Cluster Security Policies. Explicit changes can be made to these policies.
@@ -93,7 +96,11 @@ Environment Security Policies, like [Cluster Security Policies](#configure-clust
* Allow
* Inherit
-
+
+
The Environment Security Policy inherits its settings from the Cluster Security Policy, following a hierarchical structure where each level inherits the policy from its upper level.
@@ -116,31 +123,40 @@ However, in the Application Security Policy, the policy is determined by both: A
First, choose an application from the list.
-
+
+
Figure 5a: Configuring Application Security Policy - Choosing an App
Next, configure a security policy for that application in the intended environment.
-
+
+
Figure 5b: Configuring Application Security Policy - Choosing an Env
---
## Example
-1. Let's say, you have defined a policy to block the deployment if critical vulnerabilities are found in a given application.
+1. Let's say, you have defined a policy to block the deployment if critical or high vulnerabilities are found in a given application.
- 
+ 
+
Figure 6: Defining a Block Policy
2. Now, go to the **Build & Deploy** tab of that application to select an image.
- 
+ 
+
Figure 7: Selecting an Image
3. As you can see, security issues were found in the scanned image, hence it is not available for selection. Click **Show Source Info**.
- 
+ 
+
Figure 8: Blocked Deployment of Image
4. The `Security` tab shows the critical vulnerabilities and the policy enforced to prevent deployment.
- 
+ 
+
---
@@ -148,14 +164,12 @@ Next, configure a security policy for that application in the intended environme
To block or allow specific Common Vulnerabilities and Exposures (CVE) policies, simply click **Add CVE Policy**.
-
+
+
Figure 10: Adding CVE Policy
A window will appear where you can enter the CVE ID and select whether to allow or block it.
-
-
-This action will determine whether image deployment is allowed or blocked based on the presence of vulnerabilities matching that particular CVE ID. Any other deployment decisions will be made according to the policies set previously.
-
-
-
+
+
Figure 11: Allowing/Blocking a CVE ID
+This action will determine whether image deployment is allowed or blocked based on the presence of vulnerabilities matching that particular CVE ID. Any other deployment decisions will be made according to the policies set previously.
\ No newline at end of file
diff --git a/docs/user-guide/security-features/security-scans.md b/docs/user-guide/security-features/security-scans.md
old mode 100644
new mode 100755
index 6689410318..823b73183d
--- a/docs/user-guide/security-features/security-scans.md
+++ b/docs/user-guide/security-features/security-scans.md
@@ -1,21 +1,19 @@
# Security Scans
-{% hint style="info" %}
-### Prerequisite
-
+:::info Prerequisite
Install any one of the following integrations for scanning vulnerabilities:
* [Clair](../../user-guide/integrations/vulnerability-scanning/clair.md)
* [Trivy](../../user-guide/integrations/vulnerability-scanning/trivy.md)
-{% endhint %}
+:::
-Devtron's CI pipeline provides a [**Scan for vulnerabilities**](../creating-application/workflow/ci-pipeline.md#scan-for-vulnerabilities) option as shown below. Once you enable this option, it will automatically scan the image for vulnerabilities.
+Devtron's CI pipeline provides a **Scan for vulnerabilities** option as shown below. Once you enable this option, it will automatically scan the image for vulnerabilities.
-
+
+
Figure 1: Scan for vulnerabilities
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have Admin permission or above (along with access to the environment and application) to enable the **Scan for vulnerabilities** option.
-{% endhint %}
+:::
---
@@ -25,18 +23,22 @@ To access the comprehensive security scan reports, follow these steps:
1. In the left sidebar, click **Security** and go to the `Security Scans` tab.
-{% hint style="warning" %}
-### Who Can Perform This Action?
+ 
+
Figure 3: Navigate to Security Scans
+
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to view the 'Security Scans' page.
-{% endhint %}
+:::
2. Select the desired application from the available list.
- 
+ 
+
Figure 4: Application Security Scans
This action provides a detailed overview of the application's security scan, including CVE IDs, severity levels of vulnerabilities, and more, as shown below.
- 
+ 
+
Figure 5: Detailed Scan Report
Each vulnerability is identified by a **CVE ID** and categorized based on **Severity**, **Package**, **Current Version**, and **Fixed In Version**.
@@ -56,13 +58,14 @@ To access security vulnerability details during image deployment in Devtron, fol
1. Click **Show Source Info** option for the desired image during the deployment process.
2. Navigate to the `Security` tab.
-
+
+
Figure 6: Vulnerability Details
In the `Security` tab, you will find the security vulnerability details associated with the image.
-{% hint style="info" %}
+:::info
Vulnerability information will only be displayed for images that have undergone vulnerability scanning. If no vulnerabilities were identified during the scan, the **Security** tab will display a zero count, indicating **Security (0)**.
-{% endhint %}
+:::
---
@@ -72,9 +75,10 @@ Devtron offers the capability to identify vulnerabilities even after an image ha
With this capability, Devtron empowers users to stay informed about the security vulnerabilities present in their deployed images.
-
+
+
Figure 7: App Details Tab
Clicking the 'Details' link in the security vulnerabilities report (shown above) reveals detailed information about those found within the deployed image.
-
-
+
+
Figure 8: Detailed List of Vulnerabilities
\ No newline at end of file
diff --git a/docs/user-guide/software-distribution-hub/README.md b/docs/user-guide/software-distribution-hub/README.md
old mode 100644
new mode 100755
index 1fb1923a96..50b5901e51
--- a/docs/user-guide/software-distribution-hub/README.md
+++ b/docs/user-guide/software-distribution-hub/README.md
@@ -1,15 +1,16 @@
-# Software Distribution Hub
+# Software Release Management
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
-Software Distribution Hub is a platform that simplifies the packaging, versioning, and delivery of your software products. By using it, you can manage your software release across multiple clients ([tenants](#release-versions)).
+Software Release Management is a platform that simplifies the packaging, versioning, and delivery of your software products. By using it, you can manage your software release across multiple clients ([tenants](#tenants)).
-
+
+
Figure: Software Release Management
### When and Why to Use
-Devtron's Software Distribution Hub is designed to be used in scenarios where:
+Devtron's Software Release Management is designed to be used in scenarios where:
* **Tenanted deployment**: You build software solutions for clients (tenants) who require updates deployed to their distinct environments. For every tenant, you may have to deploy a separate instance of your application, which has separate application layer and data layer on their infrastructure.
@@ -25,11 +26,11 @@ Devtron's Software Distribution Hub is designed to be used in scenarios where:
## Advantages
-Devtron's Software Distribution Hub goes beyond basic deployment by providing end-to-end release management. Deployments involving manual processes might be prone to human error. However, Software Distribution Hub streamlines the [rollout](#rollout) process by enforcing [requirements](#requirements) for each release, and not just for one environment but multiple tenant environments.
+Devtron's Software Release Management goes beyond basic deployment by providing end-to-end release management. Deployments involving manual processes might be prone to human error. However, Software Release Management streamlines the [rollout](#rollout) process by enforcing [requirements](#requirements) for each release, and not just for one environment but multiple tenant environments.
### Normal Deployment vs SDH
-| Aspect | Normal Deployment | Software Distribution Hub |
+| Aspect | Normal Deployment | Software Release Management |
|--------------------------------------------|----------------------------------------------|----------------------------------------------------------------|
| **Release Management** | No versioned deployments | Centralizes versioning and deployment into a unified platform |
| **Visibility** | Limited visibility | Comprehensive visibility |
@@ -41,12 +42,12 @@ Devtron's Software Distribution Hub goes beyond basic deployment by providing en
## Concepts
-Devtron's Software Distribution Hub has 2 sections:
+Devtron's Software Release Management has 2 sections:
* [Tenants](./tenants.md)
* [Release Hub](./release-hub.md)
-Feel free to familiarize yourself with the following concepts (terms) before you proceed to Software Distribution Hub.
+Feel free to familiarize yourself with the following concepts (terms) before you proceed to Software Release Management.
### Tenants
@@ -74,5 +75,4 @@ This is a part of [requirements](#requirements) where you decide the stages in w
### Rollout
-It is a process of delivering a new release to the tenant's environment. In Software Distribution Hub, this comes right after you lock the basic requirements of a release (i.e., application selection, release order, image selection, and release instructions).
-
+It is a process of delivering a new release to the tenant's environment. In Software Release Management, this comes right after you lock the basic requirements of a release (i.e., application selection, release order, image selection, and release instructions).
\ No newline at end of file
diff --git a/docs/user-guide/software-distribution-hub/release-hub.md b/docs/user-guide/software-distribution-hub/release-hub.md
old mode 100644
new mode 100755
index 033c162308..580175c771
--- a/docs/user-guide/software-distribution-hub/release-hub.md
+++ b/docs/user-guide/software-distribution-hub/release-hub.md
@@ -1,11 +1,10 @@
# Release Hub
-{% hint style="warning" %}
-### Prerequisite
+:::caution Prerequisite
Create a [Tenant](./tenants.md) before proceeding with any action in Release Hub.
-{% endhint %}
+:::
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
This section allows you to define [release tracks](./README.md#release-tracks), create and version software releases, add applications, select container images, and deploy releases to specified tenant [installations](./README.md#installations).
@@ -13,16 +12,16 @@ This section allows you to define [release tracks](./README.md#release-tracks),
## Creating Release Tracks and Versions
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to create release track.
-{% endhint %}
+:::
This involves the creation of release tracks and software versions. A release track helps you organize and keep track of different versions of your software. So if you ship multiple products (say HRMS, Web Builder, Video Editing Tools), you can create separate release tracks for each.
1. Click **+ Release Track**.
- 
+ 
+
Figure 1: Creating New Release Track
2. Give a name to the track, e.g., `numero`
@@ -30,19 +29,23 @@ This involves the creation of release tracks and software versions. A release tr
4. Click **Create Release Track**.
- 
+ 
+
6. Select a track (e.g., *numero*) from the **Release Track** dropdown.
- 
+ 
+
Figure 4: Choosing Release Track
7. Enter a [semantic version](https://semver.org/) in **Release Version** field, e.g., `1.0.0`
- 
+ 
+
Figure 5: Versioning the Release
8. (Optional) Give a name to the release, e.g., `numero-beta`. If you don’t provide one, the name will be same as release version (i.e., 1.0.0).
@@ -50,49 +53,53 @@ This involves the creation of release tracks and software versions. A release tr
10. Click **Create Release**.
- 
+ 
+
Figure 6: Saving Release Details
If you are creating your first release, you may proceed with the **Create from scratch** option. However, for subsequent versions of your release (say 1.0.1), you may clone an existing release (e.g., 1.0.0) as shown below. Please note, you can only clone releases belonging to the same track.
-
+
+
Figure 7: Cloning an Existing Release
---
## Adding Applications
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to add applications to a release track.
-{% endhint %}
+:::
This involves the inclusion of applications you wish to rollout in the release version created by you.
1. Click **+ Add Application** button present within the release you created.
- 
+ 
+
Figure 8: Adding Apps to Release
2. Click the **Search and add applications** dropdown.
3. Use the checkbox to add applications from your projects.
- 
+ 
+
-{% hint style="info" %}
-### Importance of Release Stages
-By default, your selected applications will be set to release in one go. However, you can also release them in stages. In other words, you can decide which set of applications should be released first, subsequently which ones to release next, and the ones to release last.
For example, if you're adding a new payment system (backend) and an updated checkout page (frontend), you would release the payment system first to ensure payments can be processed correctly.
-{% endhint %}
+:::info Importance of Release Stages
+By default, your selected applications will be set to release in one go. However, you can also release them in stages. In other words, you can decide which set of applications should be released first, subsequently which ones to release next, and the ones to release last.
For example, if you're adding a new payment system (backend) and an updated checkout page (frontend), you would release the payment system first to ensure payments can be processed correctly.
+:::
5. Use the drag-and-drop feature to move applications from one stage to another.
- 
+ 
+
Figure 11: Rearranging the Sequence
-{% hint style="warning" %}
+:::caution
The drag-and-drop feature is designed specifically for moving applications between different release stages. It is not meant to alter the sequence of applications within the same stage.
-{% endhint %}
+:::
6. Once you have finalized the sequence and stages, click **Save Changes**.
@@ -100,91 +107,94 @@ The drag-and-drop feature is designed specifically for moving applications betwe
## Selecting Images
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to select images for selected applications.
-{% endhint %}
+:::
1. Select a workflow available for your application. All the [images](../../reference/glossary.md#image) available in the selected workflow will appear.
- 
+ 
+
Figure 12: Selecting Image from Specific Workflow
-{% hint style="info" %}
-### Note
+:::info Note
Only the images that were built already will appear. If there are no images present, [trigger the CI pipeline](../deploying-application/triggering-ci.md) of the application first to obtain the image.
-{% endhint %}
+:::
2. Click **SELECT** next to the image you wish to deploy from the list.
3. Repeat the above steps for other applications you added in the release.
- 
+ 
+
Figure 13: Repeating Steps for Other Applications
4. Click **Save**.
-{% hint style="info" %}
-### Tip
+:::info Tip
In case you don’t have the correct images ready for any of your applications, you can partially save your changes at this point, and return once they are ready.
-{% endhint %}
+:::
5. You may add release instructions for each application using the in-built Markdown editor. This can be detailed deployment notes and configuration guidelines for the team.
- 
+ 
+
Figure 14: Adding Release Instructions
6. Before locking the requirements, make sure the release order is correct, add applications if needed, and include environments in tenants (if not done already). Once you have finalized them, click **Lock Requirements**.
- 
+ 
+
Figure 15: Locking Requirements
-{% hint style="info" %}
+:::info
Once you lock the requirements, Devtron will prevent any unsolicited modifications to your release by anyone (including you). However, you can re-edit it by clicking **Unlock To Edit**.
-{% endhint %}
+:::
---
## Deploying Release
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users with build & deploy permission or above (for the application and target environment) can deploy a release.
-{% endhint %}
+:::
-{% hint style="info" %}
-### Prerequisite
+:::info Prerequisite
All your requirements need to be locked and [tenants](./tenants.md) must be configured.
-{% endhint %}
+:::
This involves the deployment of the release to the specified tenant installations.
1. Go to the **Rollout Release** tab.
- 
+ 
+
Figure 16: Rollout Release Page
2. Your release needs to be marked as ready to proceed further. If it isn’t, you can mark it **Ready for release** from this screen.
- 
+ 
+
Figure 17: Marking a Release as Ready
Optionally, you can also do so by changing the status from **Draft** state to **Ready for release** within your release track.
- 
+ 
+
Figure 18: Alternative Way of Marking
3. Use the checkbox to select the applications belonging to the first release stage. You may use the filters on the left-hand side to make it easier.
- {% embed url="https://www.youtube.com/watch?v=HPYZ4-hhoDM" caption="First Release Stage" %}
+
4. Click **Deploy**.
If the application workflow has pre-deployment/post-deployment stage, you get a dropdown where you can specifically trigger either pre-deployment, deployment, or post-deployment stage.
- 
+ 
+
Figure 19: Pre/Post Deployment
5. Once the applications from the first release stage are successfully deployed, select the applications from the subsequent release stage and deploy.
- {% embed url="https://www.youtube.com/watch?v=ioGZP1CCuxI" caption="Last Release Stage" %}
+
-{% hint style="warning" %}
+:::caution
An application can be deployed on the tenant in the next release stage only if other applications in the previous stage are deployed successfully on the given tenant.
-{% endhint %}
+:::
Here we covered the process of performing a production installation on just one tenant. Similarly, you can perform installations on your other tenants (if any).
@@ -196,7 +206,8 @@ Here we covered the process of performing a production installation on just one
You can view the status of your release at a particular tenant under `Rollout Status`. Moreover, you can go to **Rollout History** tab to view the deployment history.
-
+
+
Figure 20: Checking Rollout Status
You can view the following statuses
@@ -212,21 +223,25 @@ Apart from the rollout status, you can also see the release status:
* If the applications are partially released, the release status shows `Partially released`.
- 
+ 
+
Figure 21: Partial Release
* If all the applications in a release are successfully deployed, the release status shows `Completely Released`.
- 
+ 
+
Figure 22: Full Release
* Alternatively, you can view the release status directly in the release track too.
- 
+ 
+
Figure 23: Alternative Way of Checking Status
### Putting a Release on Hold
If a release is put on hold, none of the applications (in any release stage) can be deployed in that release.
-
+
+
Figure 24: Pausing a Release
**When to use**:
@@ -244,7 +259,8 @@ If a release is put on hold, none of the applications (in any release stage) can
When a release is rescinded, it is marked as invalid or buggy, and cannot be used for further deployments. This action ensures that that the release cannot be modified further and no applications within the rescinded release can be deployed. However, deploying from the [Build & Deploy page](../deploying-application/README.md) of [Applications](../applications.md) or [Application Groups](../application-groups.md) will still be possible.
-
+
+
Figure 25: Cancelling a Release
**When to use**:
@@ -262,13 +278,12 @@ When a release is rescinded, it is marked as invalid or buggy, and cannot be use
In the **Overview** section, you get a Markdown editor to add release notes. You can add text, images, links, and many more to clearly communicate updates and changes in each release. This keeps everyone informed and might contribute to a smoother deployment process.
-
+
+
Figure 26: Release Note Section in SDH
### Release Catalog
-Based on the schema provided in the catalog framework, you can add relevant details for release. Refer [Catalog Framework](../global-configurations/catalog-framework.md) for more details.
-
-
-
-
+Based on the schema provided in the catalog, you can add relevant details for release. You can manage this data using the **Manage Schema** option, which defines the structure of your catalog. Refer the [Catalog Documentation](../global-configurations/catalog-framework.md#managing-a-schema) to learn more.
+
+
Figure 27: Release Catalog
\ No newline at end of file
diff --git a/docs/user-guide/software-distribution-hub/tenants.md b/docs/user-guide/software-distribution-hub/tenants.md
old mode 100644
new mode 100755
index 55749bf1ff..58a605bd34
--- a/docs/user-guide/software-distribution-hub/tenants.md
+++ b/docs/user-guide/software-distribution-hub/tenants.md
@@ -1,6 +1,6 @@
# Tenants
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
This section allows you to add new [tenants](./README.md#tenants) and map environments to these [installations](./README.md#installations) to ensure updates [rollout](./README.md#rollout) correctly.
@@ -8,16 +8,16 @@ This section allows you to add new [tenants](./README.md#tenants) and map enviro
## Adding Tenant
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to add tenants.
-{% endhint %}
+:::
This involves the creation of new organizations where you wish to deploy s/w updates. Whenever you are onboarding a new client, you add them as a tenant.
1. Click **+ Add Tenant**.
- 
+ 
+
Figure 1: Adding a Tenant
2. Enter a name in **Tenant display name** field, e.g., `flareup.xyz`. Once set, you can rename it later (if needed).
@@ -25,7 +25,8 @@ This involves the creation of new organizations where you wish to deploy s/w upd
4. (Optional) Add a description of the tenant.
- 
+ 
+
Figure 2: Saving Tenant Details
5. Click **Save**.
@@ -33,26 +34,28 @@ This involves the creation of new organizations where you wish to deploy s/w upd
## Adding Installation
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to add installations to a tenant.
-{% endhint %}
+:::
This involves setting up [installation](./README.md#installations) for different environments, such as Prod, Development, and QA environments. You can consider these as licenses/installations your client has subscribed for.
1. Click the tenant you created.
- 
+ 
+
3. Enter a name in **Installation display name** field, e.g., `Flareup Prod`
4. Enter an **Installation ID**, e.g., `flareup-prod-1`
- 
+ 
+
Figure 5: Entering Installation ID
5. Click **Save**.
@@ -60,20 +63,21 @@ This involves setting up [installation](./README.md#installations) for different
## Mapping Environments
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
Users need to have super-admin permission to map environments.
-{% endhint %}
+:::
-This involves mapping customer's environments to the tenant installation so that your updates are deployed to the correct environments. If you haven't created an environment yet, refer [Clusters & Environments](../global-configurations/cluster-and-environments.md#add-environment).
+This involves mapping customer's environments to the tenant installation so that your updates are deployed to the correct environments. If you haven't created an environment yet, refer [Clusters & Environments](../global-configurations/clusters/manage-environments.md#add-environment-to-a-cluster).
1. Click **Map Environment**.
- 
+ 
+
Figure 6: Map Environment Button
2. Use the checkbox to choose the environments to map to the tenant installation. Note that, you cannot map an environment that is already mapped to another tenant installation.
- 
+ 
+
Figure 7: Mapping Environment to Your Installation
Here, we have mapped `doc1` and `doc2` environments to the production installation.
diff --git a/docs/user-guide/stack-manager.md b/docs/user-guide/stack-manager.md
old mode 100644
new mode 100755
index 22a024fdbb..f6941394e5
--- a/docs/user-guide/stack-manager.md
+++ b/docs/user-guide/stack-manager.md
@@ -1,21 +1,26 @@
+---
+hide_table_of_contents: true
+---
+
# Devtron Integrations
Devtron integrations extend the functionality of your Devtron stack.
## Discover and install integrations
-The current release of Devtron supports the Build and Deploy (CI/CD) integration. More integrations will be available soon; to request one, please [submit a ticket](https://github.com/devtron-labs/devtron/issues/new/choose)
+The current release of Devtron supports multiple integrations. To request one, please [submit a ticket](https://github.com/devtron-labs/devtron/issues/new/choose)
> Integrations can be installed by super admins; However other user roles can browse and request super admins to install the required integrations.
-> Integrations are updated along with [Devtron updates](setup/../../setup/upgrade-devtron.md).
+> Integrations are updated along with [Devtron updates](setup/../../setup/upgrade/README.md).
Select **Devtron Stack Manager** from the left navigation bar.
Under **INTEGRATIONS**, select **Discover**.
-
+
+
Figure 1: Discover integrations
-> Although the integrations are installed separately, they cannot be upgraded separately. Integrations update happens automatically with [Devtron upgrade](#upgrade-devtron).
+> Although the integrations are installed separately, they cannot be upgraded separately. Integrations update happens automatically with [Devtron upgrade](../setup/upgrade/README.md).
### Build and Deploy (CI/CD) integration
@@ -35,7 +40,7 @@ Devtron CI/CD integration enables software development teams to automate the bui
#### Installation
-1. On the **Devtron Stack Manager > Discover** page, select the **Build and Deploy (CI/CD) integration**.
+1. On the **Devtron Stack Manager** → **Discover** page, select the **Build and Deploy (CI/CD) integration**.
2. On the **Discover integrations/Build and Deploy (CI/CD) page**, select **Install**.
The installation status may be one of the following:
@@ -49,6 +54,6 @@ The installation status may be one of the following:
| Installed | The integration is successfully installed and available on the **Installed page**. |
| Request timed out | The request to install has hit the maximum number of retries. You may retry the installation or [contact support](https://discord.devtron.ai/) for further assistance. |
-> A list of installed integrations can be viewed on the **Devtron Stack Manager > Installed** page.
+> A list of installed integrations can be viewed on the **Devtron Stack Manager** → **Installed** page.
-To update an installed integration, please [update Devtron](../setup/upgrade/upgrade-devtron-ui.md).
+To update an installed integration, please [update Devtron](../setup/upgrade/upgrade-devtron-ui.md).
\ No newline at end of file
diff --git a/docs/user-guide/storageops/README.md b/docs/user-guide/storageops/README.md
new file mode 100755
index 0000000000..172d13899e
--- /dev/null
+++ b/docs/user-guide/storageops/README.md
@@ -0,0 +1,29 @@
+---
+hide_table_of_contents: true
+---
+
+# Backup & Restore
+
+The **Backup & Restore** feature in Devtron helps you protect your Kubernetes workloads when things don’t go as planned.
+
+Whether you are dealing with an unexpected failure, testing a recovery process, or preparing for a cluster or environment change. **Backup & Restore** feature make backups and restores predictable, visible, and easy to manage.
+
+
+
+With StorageOps, you can:
+
+* Create on-demand backups or set up recurring backup schedules.
+
+* Store backup data securely in your cloud storage.
+
+* Restore applications, configurations, and persistent data when needed.
+
+* Track the status of backups and restores from a single place.
+
+---
+
+Refer [Backup & Schedules](./backup.md) page to create a backup/ backup schedule.
+
+Refer [Restores](./restores.md) page to restore from a backup/ backup schedule.
+
+Refer [Backup Locations](./backup-locations.md) to add a storage location for your backups.
\ No newline at end of file
diff --git a/docs/user-guide/storageops/backup-locations.md b/docs/user-guide/storageops/backup-locations.md
new file mode 100644
index 0000000000..c641125636
--- /dev/null
+++ b/docs/user-guide/storageops/backup-locations.md
@@ -0,0 +1,173 @@
+# Backup Locations
+
+## Introduction
+
+The **Backup Locations** section lets you configure and manage where your cluster data is stored.
+Devtron supports two types of locations for storing backup data:
+
+| **Location Types** | **Description** |
+|-------------|-----------------|
+| **Volume Snapshot Locations** | Used to store volume snapshots created using your cloud provider’s native snapshot service. |
+| **Storage Locations** | Used to store backup files and metadata. |
+
+## Storage Locations
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to add backup locations.
+:::
+
+A **Storage Location** defines where Devtron stores backup files, manifests, and metadata.
+
+To add a storage location, navigate to **Data Protection Management** → **Backup Locations** → **Storage Locations**.
+
+### Provider Configuration
+
+#### Basic Details
+
+| **Field** | **Required / Optional** | **Description** |
+|-----------|-------------------------|-------------------|
+| **Provider** | Required | Select your cloud provider, for example **GCP**, **AWS**, or **Azure**. |
+| **Backup Storage Location Name** | Required | A descriptive name, for example `gcp-prod-storage` or `s3-backup-primary`. |
+
+#### Storage Configuration
+
+These fields are for provider-specific advanced settings.
+
+| **Field** | **Required / Optional** | **Sample Value** | **Description** |
+|-----------|-------------------------|-------------------|------------------|
+| **Key** | Optional | `region` | Lets you pass extra configuration to the storage provider. For most standard GCP, AWS, or Azure object storage setups you can leave this empty. Use it only if your provider documentation mentions additional keys. |
+| **Value** | Optional | `us-east-1` for a `region` key. | The value that applies to the configuration key. You can add multiple key–value pairs if needed. |
+| **CA Certificate** | Optional | A base64 encoded CA bundle to be used when verifying TLS connections |
+
+#### Credentials
+
+This section defines how Devtron authenticates with your cloud storage provider to access the backup bucket. Without valid credentials, Devtron won’t be able to read from or write to your storage location.
+
+To configure credentials, first **enable the Credentials toggle**. You can either reuse an existing secret or create a new one directly from the Devtron UI.
+
+#### Option 1: Select Secret
+
+Use this option if the required credentials are **already stored as a Kubernetes secret**.
+
+| Field | Required | What to Enter | Description |
+|------|----------|---------------|-------------|
+| Secret Name | Yes | Name of an existing Kubernetes secret | The secret must already exist and contain valid cloud provider credentials. |
+| Secret Key | Yes | Key inside the secret (for example, `cloud`) | This key should point to the credential data stored inside the secret. |
+
+#### Option 2: Create New Secret
+
+Use this option if you want to add credentials for the first time while configuring the storage location.
+
+| Field | Required | What to Enter | Description |
+|------|----------|---------------|-------------|
+| Secret Name | Yes | A unique name (for example, `gcp-backup-secret`) | This name will be used to create a new Kubernetes secret in the cluster. |
+| Secret Key | Yes | A key name (for example, `cloud`) | The key under which the credential data will be stored. |
+| Credential Data | Yes | Full credential payload | Paste the cloud provider credentials here (for example, a GCP service account JSON). |
+
+### Object Storage Details
+
+After configuring the **credentials**, the next step is to specify which storage bucket for which you set up the credentials. Enter the following details to point Devtron to the correct storage bucket.c
+
+| Field | Required | What to Enter | Description |
+|------|----------|---------------|-------------|
+| **Storage Bucket** | Yes | Name of the object storage bucket | Enter the name of the bucket that will store backups, for example `devtron-backups-prod`. This bucket must already exist and be accessible using the configured credentials |
+| **Bucket Path Prefix** | Optional | Folder path inside the bucket | Specify a path within the bucket, such as `cluster-1/backups`, to organize backups by cluster or environment. If left empty, backups are stored at the root of the bucket |
+| **Access Mode** | Yes | `Read and Write` or `Read Only` | Defines how Devtron can use this bucket with the provided credentials |
+
+### Sync & Validation
+
+After configuring the storage bucket, you can optionally define how Devtron syncs and validates this storage location. These configurations help Devtron stay up to date with backups stored in the bucket and ensure the location remains accessible.
+
+| Field | Required | What to Enter | Description |
+|------|----------|---------------|-------------|
+| **Backup Sync Period** | Optional | Duration (for example, `5m`, `1h`) | Defines how often Devtron syncs backup information from this storage location. This helps Devtron discover new or updated backups present in the bucket |
+| **Validation Frequency** | Optional | Duration (for example, `10m`, `2h`) | Defines how often Devtron validates the object storage location to check connectivity and access using the configured credentials |
+
+### Configuring Default Storage Location
+
+If you want a storage location to be used as the default location for backups, enable the **Set as Default** toggle. When enabled, Devtron automatically selects this storage location for new backups and backup schedules, unless a different location is explicitly chosen during configuration.
+
+---
+
+## Volume Snapshot Locations
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to add backup locations.
+:::
+
+A **Volume Snapshot Location** defines where Devtron stores and manages volume-level snapshots for persistent volumes. These snapshots are used to restore application data backed by persistent volumes during a restore operation.
+
+To add a volume snapshot location, navigate to **Data Protection Management** → **Backup Locations** → **Volume Snapshot Locations**.
+
+### Basic Details
+
+| **Field** | **Required / Optional** | **Description** |
+|-----------|-------------------------|------------------|
+| **Provider** | Required | Select the cloud provider where your persistent volumes are provisioned, such as **GCP**, **AWS**, or **Azure** |
+| **Volume Snapshot Location Name** | Required | A descriptive name for the snapshot location, for example `gcp-prod-snapshots` or `aws-ebs-snapshots`|
+
+### Configuration Fields
+
+These fields allow you to pass **provider-specific configuration** required for snapshot operations.
+
+| **Field** | **Required / Optional** | **Sample Value** | **Description** |
+|-----------|-------------------------|------------------|------------------|
+| **Key** | Optional | `region` | Used to pass additional configuration required by the snapshot provider|
+| **Value** | Optional | `us-central1` | The value corresponding to the configuration key. Multiple key–value pairs can be added if required |
+
+### Credentials
+
+This section defines how Devtron authenticates with your cloud storage provider to access the volume snapshot bucket. Without valid credentials, Devtron won’t be able to read from or write to your volume snapshot location.
+
+To configure credentials, first **enable the Credentials toggle**. You can either reuse an existing secret or create a new one directly from the Devtron UI.
+
+#### Option 1: Select Secret
+
+Use this option if the required credentials are **already stored as a Kubernetes secret**.
+
+| Field | Required | What to Enter | Description |
+|------|----------|---------------|-------------|
+| Secret Name | Yes | Name of an existing Kubernetes secret | The secret must already exist and contain valid cloud provider credentials |
+| Secret Key | Yes | Key inside the secret (for example, `cloud`) | This key should point to the credential data stored inside the secret |
+
+#### Option 2: Create New Secret
+
+Use this option if you want to add credentials for the first time while configuring the storage location.
+
+| Field | Required | What to Enter | Description |
+|------|----------|---------------|-------------|
+| Secret Name | Yes | A unique name (for example, `gcp-backup-secret`) | This name will be used to create a new Kubernetes secret in the cluster |
+| Secret Key | Yes | A key name (for example, `cloud`) | The key under which the credential data will be stored |
+| Credential Data | Yes | Full credential payload | Paste the cloud provider credentials here (for example, a GCP service account JSON) |
+
+---
+
+## Updating Backup Locations
+
+To update the configuration of an existing storage location or volume snapshot location, follow the steps below
+
+1. Go to **Data Protection Management** → **Backup Locations**.
+
+2. Open the **Storage Locations** or **Volume Snapshot Locations** tab.
+
+3. Hover over the **Storage Location** or **Volume Snapshot Location** you want to update, and then click the **Edit** icon.
+
+4. Modify the required fields.
+
+5. Click **Save** to apply the changes.
+
+---
+
+## Deleting Backup Locations
+
+To Delete the configuration of an existing storage location or volume snapshot location, follow the steps below
+
+1. Go to **Data Protection Management** → **Backup Locations**.
+
+2. Open the **Storage Locations** or **Volume Snapshot Locations** tab.
+
+3. Hover over the **Storage Location** or **Volume Snapshot Location** you want to delete, and then click the **Delete** icon.
+
+4. A pop-up window will appear. Enter the name of the **Storage Location** or **Volume Snapshot Location**.
+
+5. Click **Delete** to apply the changes.
\ No newline at end of file
diff --git a/docs/user-guide/storageops/backup.md b/docs/user-guide/storageops/backup.md
new file mode 100755
index 0000000000..30a3c95684
--- /dev/null
+++ b/docs/user-guide/storageops/backup.md
@@ -0,0 +1,197 @@
+---
+hide_table_of_contents: true
+---
+
+# Backup & Schedules
+## Introduction
+
+The **Backup & Restore** feature in Devtron helps you protect your Kubernetes workloads and data by allowing you to back up and restore your **clusters**, **namespaces**, or **specific resources** directly from the Devtron UI.
+
+You can
+
+ * Create on-demand or scheduled backups
+ * Choose where your data is stored (such as AWS S3, Azure Blob, or GCP Storage)
+ * Restore the backups to the same or another cluster when needed.
+
+ Whether you are preparing for disaster recovery, migrating environments, or ensuring business continuity, Devtron makes the process simple, reliable, and transparent while giving you complete visibility and control.
+
+---
+:::caution Prerequisites
+Before creating a backup, make sure that at least one **Backup Storage Location** is configured and available. If no storage location is configured, backups cannot be created. Refer [Backup Locations](./backup-locations.md) to learn more.
+:::
+
+## Creating Backup
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to create a backup.
+:::
+
+You can create a backup in Devtron to capture the current state of your Kubernetes clusters, namespaces, and resources.
+
+1. Go to **Data Protection Management** → **Backup & Schedule**.
+
+2. Select **Create Backup** and select one of the following:
+
+ | **Option** | **Description** |
+ |-------------|-----------------|
+ | **From Scratch** | Configure a new backup manually by defining the scope, storage, and snapshot settings |
+ | **From Schedule** | Trigger a backup using an existing backup schedule configuration |
+ | **Create Backup Schedule** | Create a recurring backup policy to automatically perform backups at regular intervals |
+
+ ### From Scratch
+
+ After selecting **From Scratch**, a new modal window will open, enter the required details for each section
+
+ #### 1. Basic Details
+
+ | **Field** | **Required / Optional** | **Description** |
+ |------------|-------------------------|-----------------|
+ | **Backup Name** | Required | Enter a unique name for the backup to identify it in the list view |
+ | **Labels** | Optional | Add key-value pairs to organize and filter backups by environment, team, or purpose |
+
+ #### 2. Backup Scope & Policy
+
+ | **Field** | **Required / Optional** | **Description** |
+ |------------|-------------------------|-----------------|
+ | **Select Cluster to Backup** | Required | Choose the Kubernetes cluster where the backup will be performed|
+ | **Namespaces to Backup** | Required | Define which namespaces to include in the backup
**All Namespaces** – Backs up all the namespaces in the cluster
**All Production Environments** - Backs up namespaces tagged as production
**All Non-Production Environments** - Backs up namespaces tagged as npn-production
**Specific Namespaces** - Select specific namespaces manually
|
+ | **Resources to Backup** | Optional | Choose which Kubernetes resources to include
**All Resources** – Includes all resources
**Specific Resources** – Select **Global**, **Cluster**, or **Namespace** scoped resources
|
+ | **Included Resources** (Applicable for Specific Namespaces/Resources) | Optional | Specify namespaces or resource kinds to include, such as `deployments` or `configmaps` |
+ | **Excluded Resources** (Applicable for Specific Namespaces/Resources) | Optional | Specify namespaces or resource kinds to exclude, such as `secrets` or `events` |
+ | **Backup TTL** | Optional | Defines how long the backup should be retained before it becomes eligible for garbage collection. You can specify a numeric value along with a time unit such as seconds, minutes, or hours |
+ | **Ordered Resources** | Optional | Allows you to define the order in which Kubernetes resources are backed up by specifying key value pairs. Resources listed here are processed in the defined order during backup creation|
+ | **Resources Policy** | Optional | Specifies the resource policies that the backup should follow. You can either select an existing ConfigMap containing the policy or provide the policy directly as YAML |
+ | **Filter resources using label selectors** | Optional | Filters resources included in the backup using Kubernetes label selectors. Labels within the same group are evaluated using AND logic, while separate groups are evaluated using OR logic. Operators supported are `Equals`, `In`, `NotIn`,`Exists`,`DoesNotExist` |
+
+ #### 3. Storage & Snapshot Location
+
+ | **Field** | **Required / Optional** | **Description** |
+ |------------|-------------------------|-----------------|
+ | **Volume Snapshot Location** | Required | Select where the volume snapshots will be stored. Each cloud provider supports one snapshot location per backup |
+ | **Storage Location** | Required | Choose the object storage target (for example, **AWS S3**, **Azure Blob**, **GCP Storage**) to store backup data and logs |
+ | **Snapshot Option** | Required | Choose how to handle volume data
**Take Snapshot** – Capture persistent volume data
**Skip Volume Snapshot** – Back up only resource manifests
|
+
+ #### Snapshot Volume Settings (When *Take Snapshot* is selected)
+
+ | **Field** | **Required / Optional** | **Description** |
+ |------------|-------------------------|-----------------|
+ | **Snapshot Move Data** | Optional | Specify whether snapshot data should be moved after creation |
+ | **Default Volumes to FS Backup** | Optional | Use file system backup for all volumes instead of block-level snapshots |
+ | **Data Mover** | Optional | Select the data mover for transferring snapshot data (for example, `velero` or `kopia`) |
+ | **Parallel Files Upload** | Optional | Define the number of files uploaded in parallel. Applicable when using the **kopia** uploader|
+
+ #### 4. Advanced Timeouts & Tuning
+
+ | **Field** | **Required / Optional** | **Description** |
+ |------------|-------------------------|-----------------|
+ | **CSI Snapshot Timeout** | Optional | Set the maximum time to wait for CSI snapshot creation before timing out (for example, `10m`) |
+ | **Item Operation Timeout** | Optional | Define how long to wait for asynchronous plugin operations. Default is `72h` |
+
+3. After entering the required details, click **Create Backup** and a backup will be created.
+
+### From Schedule
+
+:::warning Note
+A **Backup Schedule** is required to create a backup using the *From Schedule* option.
+Refer to [Creating Backup Schedule](#creating-backup-schedule) to learn how to configure and manage backup schedules in Devtron.
+:::
+
+If you already have a backup schedule, you can create a backup from it without going through the configuration process again. This helps you quickly trigger a backup using the same configurations which are defined in the selected schedule.
+
+1. After selecting **From Schedule**, a new modal window will open. Enter the required details as described below.
+
+2. Enter the required information:
+
+| **Field** | **Required / Optional** | **Description** |
+|------------|-------------------------|-----------------|
+| **Backup Name** | Required | Enter a unique name for the backup. This name will help identify the backup in the list. |
+| **Schedule** | Required | Select one of the existing schedules (for example, **Daily Backup Schedule**, **Weekly Database Backup**, **Monthly Archive Schedule**). The configurations from the selected schedule will automatically be used to create the backup. |
+
+3. Click **Create Backup**, and the backup creation process will start.
+
+---
+
+## Creating Backup Schedule
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to create a backup.
+:::
+
+A **Backup Schedule** helps you automate backups at regular intervals without having to manually create them every time.
+It uses the same configuration options available in [Creating a Backup](#creating-backup), with a few additional fields that define when and how often the backup should run.
+
+This makes it easier to ensure that your cluster data is always protected, even if you forget to trigger a backup manually.
+
+After selecting **Create Backup Schedule**, a modal window opens where you can specify the schedule details along with your backup configuration.
+
+### Backup Schedule Specific Fields
+
+| **Field** | **Required / Optional** | **Description** |
+|------------|-------------------------|-----------------|
+| **Schedule Name** | Required | Enter a unique name for the schedule. Backups created through this schedule use this name as a prefix |
+| **Description** | Optional | Provide a short description to identify the purpose of the schedule |
+| **Backup Schedule (Cron Expression)** | Required | Define when backups should run (for example, daily at midnight or every 6 hours) |
+| **Pause Schedule** | Optional | Temporarily disable the schedule without deleting it. Backups will not run until resumed |
+| **Skip Upcoming Backup** | Optional | Skips the next scheduled backup but keeps the schedule active |
+| **Delete Backups on Schedule Deletion** | Optional | Automatically deletes backups created by this schedule when the schedule itself is removed |
+| **Backup TTL** | Optional | Defines how long each backup should be retained before it’s automatically deleted |
+
+## Create Backup From Schedule
+
+If you do not want to wait for the scheduled backup to run, you can use **From Schedule** option to create an on-demand backup using an existing backup schedule.
+
+When you create a backup from a schedule, Devtron reuses the same configuration already defined in the selected schedule and triggers the backup right away. This ensures the backup follows the same scope, policies, and storage settings without requiring you to configure them again.
+
+| **Field** | **Required / Optional** | **Description** |
+|----------|--------------------------|-----------------|
+| **Backup Name** | Required | Specify a unique name for the backup that will be created from the selected schedule |
+| **Schedule** | Required | Select an existing backup schedule. All configurations from this schedule will be used to create the backup |
+
+---
+
+## Viewing Backups and Backup Schedules
+
+:::caution Who Can Perform This Action?
+Users need to have view permission to view backups.
+:::
+
+### Backups
+
+After you initiated the backup, you can find it under **Backup** tab. This tab shows all the backups weather they are created manually or via a backup-schedule.
+
+| **Column** | **Description** |
+|-------------|-----------------|
+| **Name** | Displays the unique name of the backup. Click the name to view the backup details, and restore it |
+| **Cluster** | Shows the cluster where the backup was taken |
+| **Created By** | Shows the user or backup schedule name that initiated the backup |
+| **Status** | Shows the current state of the backup:
**Creating** – Backup is in progress
**Completed** – Backup finished successfully
**Failed** – Backup failed
**Partially Failed** – Some resources were not backed up
**Expired** – The backup has reached its retention (TTL) limit
|
+| **Backup Date** | Shows the date and time of when the backup was created |
+| **Expires In** | Shows the remaining time before the backup expires |
+| **Size** | Indicates the total size of the backup stored in the configured location|
+
+You can use the **Search** bar or apply filters such as **Cluster**, **Status**, and **Created By** to quickly locate specific backups or narrow down the list based on: their current state, or who initiated them.
+
+These filters help you quickly find backups for restore operations or verify recent backup activity across clusters.
+
+### Backup Schedules
+
+After creating a backup schedule, you can view it under **Backup Schedules** tab. This tab shows all the backup schedules and displays the following details for each of them
+
+| **Column** | **Description** |
+|-------------|-----------------|
+| **Schedule Name** | Name of the backup schedule. Click to view or edit details |
+| **Status** | Indicates the current state of the backup schedule:
**New** – The schedule has been created successfully but no backups have run yet. Once the first scheduled backup is executed, the status changes to **Active**
**Active** – The schedule is valid and enabled. Backups are automatically triggered at the defined intervals based on the configured cron expression
**Paused** – The schedule is temporarily disabled. No backups will run until the schedule is resumed manually
**Failed Validation** – The schedule configuration is invalid due to missing or incorrect parameters (for example, an invalid cron expression, unavailable cluster, or deleted storage location). Backups will not run until the issue is resolved, and the schedule is validated again
|
+| **Cluster** | Shows the cluster associated with the schedule |
+| **Storage Location** | Displays the storage target (for example, AWS S3, Azure Blob, or GCP Storage)|
+| **Cron** | The cron expression defining how frequently the backup runs (for example, *Every 6 hours*)|
+| **Last Backup** | The timestamp of the last backup triggered by this schedule|
+| **Last Skipped** | Displays when the schedule last skipped a run (if applicable)|
+
+## Delete Backups and Backup Schedules
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to delete backups.
+:::
+
+To delete a backup or backup schedule, click the delete icon next to it. The selected backup or schedule will be deleted.
+
diff --git a/docs/user-guide/storageops/overview.md b/docs/user-guide/storageops/overview.md
new file mode 100644
index 0000000000..c2c76b47c0
--- /dev/null
+++ b/docs/user-guide/storageops/overview.md
@@ -0,0 +1,48 @@
+# Overview
+
+## Introduction
+
+The Backup & Restore Overview page helps you quickly see the current state of backups and restores across your clusters. From one place, you can check backup health, restore activity, schedules, and storage status.
+
+At the top of the page, you can filter data by **cluster** to narrow down insights or view the status across **all clusters**.
+
+## At a Glance
+
+The At a Glance section helps you quickly check the status of your backups and restores.
+
+| Card | Description |
+|-----|-------------|
+| **Backups Initiated** | Total number of backups triggered across the selected clusters |
+| **Restores Initiated** | Total number of restore operations started |
+| **Backup Schedules** | Number of backup schedules configured |
+
+---
+
+## Backup & Restore Summary
+
+The **Backup & Restore Summary** section helps you quickly understand the current status of your backups, restores, schedules, and backup locations across your clusters.
+
+| **Field** | **Description** |
+|----------|-----------------|
+| **Backup Status** | Shows the status of backups based on their current state, such as **Completed**, **In Progress**, or **Failed**. Hover over a state to see the number of backups in that state |
+| **Restore Status** | Shows the status of restores based on their current state, such as **Completed**, **In Progress**, or **Failed**. Hover over a state to see the number of restores in that state |
+| **Clusters with Backup Schedule** | Shows how many clusters have backup schedules configured |
+| **Unavailable Storage Locations** | Indicates the number of storage locations that are currently unavailable |
+| **Paused Schedules** | Displays the number of backup schedules that are currently paused |
+
+---
+
+## Backup Success Rate by Clusters
+
+The **Backup Success Rate by Clusters** graph shows how successful backups have been for each cluster, expressed as a percentage.
+
+Each bar represents a cluster, and the length of the bar indicates the percentage of backups that completed successfully for that cluster. This helps you quickly compare backup reliability across clusters. Hover over a bar to view the exact success rate for the selected cluster.
+
+You can use the sort option to sort the data according to your use case.
+
+| **Sort Option** | **Description** |
+|-----------------|-----------------|
+| **High to Low** | Sorts clusters by backup success rate from highest to lowest |
+| **Low to High** | Sorts clusters by backup success rate from lowest to highest |
+| **A to Z** | Sorts clusters alphabetically by cluster name |
+| **Z to A** | Sorts clusters in reverse alphabetical order |
diff --git a/docs/user-guide/storageops/restores.md b/docs/user-guide/storageops/restores.md
new file mode 100644
index 0000000000..007385ccd7
--- /dev/null
+++ b/docs/user-guide/storageops/restores.md
@@ -0,0 +1,128 @@
+# Restore
+
+## Introduction
+
+Restore page allows you to recover applications, namespaces, or an entire cluster to a previous state. You can create a restore from the **Restores** tab, view all restore jobs, with their current status, target cluster, and backup source.
+
+---
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to create a restore.
+:::
+
+## Creating Restore
+
+To restore a backup, you can create a restore:
+
+1. Go to **Data Protection Management** → **Restores**.
+
+2. Click **+ New Restore**. A new modal window will appear.
+
+3. Enter the required details for each section
+
+ ### 1. Basic Details
+
+ | **Field** | **Required/Optional** | **Description** |
+ |------------|-----------------------|-----------------|
+ | **Restore Name** | Required | A unique name for identifying the restore job |
+ | **Description** | Optional | A short description explaining the purpose of the restore |
+ | **Labels** | Optional | Add key-value labels to organize or filter restore jobs |
+ | **Restore From Backup** | Required | Choose how to restore:
**Specific Backup** – Select a specific backup manually.
**Latest Backup Created by a Schedule** – Automatically uses the latest backup generated by a defined schedule
|
+ | **Backup to be Restored** | Required | For:
**Specific Backup** - Select the backup you want to restore from the available list
**Latest Backup Created by a Schedule** - Select the backup schedule from which you want the latest backup to be restored
|
+
+
+ ### 2. Restore Target
+
+
+ | **Field** | **Required/Optional** | **Description** |
+ |------------|-----------------------|-----------------|
+ | **Restore To (Cluster)** | Required | Select the destination cluster for the restore. |
+ | **All Namespaces** | Optional | Restores all namespaces from the selected backup. |
+ | **Specific Namespaces** | Optional | Select specific namespaces to restore. You can use regex to match multiple namespaces. |
+ | **Included Namespaces** | Optional (visible only when **Specific Namespaces** is selected) | Select one or more namespaces to include in the restore process. Only these namespaces will be restored from the backup. You can also provide regex expressions to include namespaces that follow a specific naming pattern. |
+ | **Excluded Namespaces** | Optional (visible only when **Specific Namespaces** is selected) | Select namespaces that should be excluded from the restore process, even if they exist in the backup. You can also provide regex expressions to exclude namespaces that follow a specific naming pattern. |
+ | **Filter resources using label selectors** | Optional | Filters resources included in the restore using Kubernetes label selectors. Labels within the same group are evaluated using AND logic, while separate groups are evaluated using OR logic. Operators supported are `Equals`, `In`, `NotIn`,`Exists`,`DoesNotExist` |
+
+ ### 3. Restore Settings
+
+ | **Field** | **Required/Optional** | **Description** |
+ |------------|-----------------------|-----------------|
+ | **Resource Status** | Optional | Specify which Kubernetes resources should be included or excluded in the restore status. Resources must be provided in the format `resourceKind.group`, such as `storageclasses.storage.k8s.io` |
+ | **Namespace Mapping** | Optional | Map source namespaces to new target namespaces. For example, restore `prod` → `stage-prod` |
+ | **Include Cluster Resources** | Optional | Defines whether cluster-scoped resources should be restored. You can choose:
**Auto (Recommended):** Automatically determines which cluster resources to include, based on context
**Include all:** Restores all cluster-scoped resources from the backup
**Exclude all:** Skips all cluster-scoped resources, restoring only namespace-scoped resources
|
+ | **Restore Volumes** | Optional | Enables restoring persistent volumes from snapshots taken during the backup. Toggle this on if you need your application data to be restored along with configurations|
+ | **Preserve Node Ports** | Optional | Retains existing node ports for restored services to avoid port conflicts or reassignments during restore |
+ | **Existing Resource Policy** | Optional | Specifies how to handle already existing resources:
**Skip Resources** – Ignore existing ones
**Update Resources** – Replace or modify existing resources
|
+ | **Modify Resources During Restore** | Optional | Allows you to modify resources dynamically during restore using:
**ConfigMap:** Reference a ConfigMap containing JSON patch rules to make specific changes (for example, updating storage classes or image tags)
**JSON Patch:** Apply JSON patches inline for fine-grained control
|
+
+ ::: info Modify resources during restore
+
+ A resource modifier ConfigMap lets you customize Kubernetes resources during a restore by applying JSON patch rules before they are recreated on the target cluster. This helps make backups portable and ensures smooth restores across different environments.
+
+ **Example use cases:**
+ **Cluster migrations:** Change storageClassNames in PVCs to match storage classes available in the new cluster.
+ **How to use:** Create a ConfigMap with JSON patch rules defining the changes you want. Velero will automatically apply these rules to your resources during the restore, allowing you to tailor them for your target cluster's setup.
+
+ :::
+
+ ### 4. Timeout & Execution Controls
+
+ | **Field** | **Required/Optional** | **Description** |
+ |------------|-----------------------|-----------------|
+ | **Parallel Files Download** | Optional | Number of restore threads to run in parallel. Set to `0` to match the node CPU count automatically |
+ | **Write Sparse Files** | Optional | Enables writing of sparse files during volume restoration to optimize disk space usage |
+ | **Item Operation Timeout** | Optional | Duration (in seconds/minutes) to wait for individual restore operations before timing out |
+
+4. Click **Save**. A restore will be initiated.
+
+---
+
+## Viewing Restores
+
+After restoration of a backup is initiated, you can view your restore on the **Restores** Page under **Data Protection Management**. This page shows all your restore jobs, along with their current status, target cluster, and backup source.
+
+| **Column** | **Description** |
+|-------------|-----------------|
+| **Restore Name** | Displays the unique name of the restore job. Click the name to view detailed information such as restored namespaces, logs, and resource summary. |
+| **Status** | Shows the current state of the restore:
**Progressing** – The restore process is currently in progress
**Completed** – Restore has successfully finished, and all resources have been recovered
**Failed** – The restore could not be completed due to configuration or resource-level errors
**Partially Completed** – Restore finished, but some resources were skipped or encountered issues during restoration
|
+| **Target Cluster** | Displays the cluster where the backup was restored |
+| **Backup Source** | Shows the name of the backup used for this restore |
+| **Schedule** | Indicates the backup schedule from which the backup originated |
+| **Created By** | Displays the user or service account that initiated the restore |
+| **Date** | Shows the date and time when the restore was created or triggered |
+
+You can use the **Search** bar or apply filters such as **Cluster**, **Status**, and **Created By** to quickly find a specific restore job or narrow down the list based on recent restore activity.
+
+| **Filter** | **Description** |
+|-------------|-----------------|
+| **Cluster** | Filter restores by the target cluster where they were applied |
+| **Status** | Filter restores by their current state (for example, **Progressing**, **Completed**, **Failed**, **Partially Failed**) |
+| **Created By** | Filter restores by the user or schedule that initiated them |
+
+These filters make it easier to locate specific restore jobs, track recovery operations across clusters, and verify restore outcomes — ensuring that your environments are safely and accurately recovered.
+
+### Inspecting Restore
+
+When you click on a restore job from the **Restores** tab, a detailed view opens showing its configuration, progress, and results.
+This page helps you verify whether the restore completed successfully and understand what resources were included or skipped.
+
+The left-side of the page displays the following information:
+
+| **Field** | **Description** |
+|------------|-----------------|
+| **Status** | Shows the current state of the restore (**Completed**, **Progressing**, **Failed**, or **Partially Completed**) |
+| **Warnings & Errors** | Indicates the number of warnings or errors encountered during the restore process |
+| **Resources** | Displays the number of successfully restored resources against the total resources processed |
+| **Target Cluster** | The cluster where the restore operation was performed |
+| **Created By** | The user or service account that initiated the restore |
+| **Restored From Backup** | Displays the backup name and timestamp used for this restore. Clicking the backup name navigates to its details view |
+| **Duration** | Shows how long the restore took to complete |
+| **Included Resources** | Lists all resource types included in the restore operation |
+| **Excluded Resources** | Lists resources that were excluded from the restore, such as nodes, events, or cluster-scoped resources |
+
+On the right-side of the page, you can switch between two tabs: **Namespace Mapping** and **Manifest**, to review the details of what was restored.
+
+| **Tab** | **Description** |
+|----------|-----------------|
+| **Namespace Mapping** | Displays the mapping between source and target namespaces. This helps confirm that workloads were restored to the correct destination (for example, `production-space` → `prod-space`) |
+| **Manifest** | Shows the YAML manifest of the restore job, including specifications, restore options, and applied configurations. This helps advanced users validate cluster resources and understand how restore parameters were executed |
\ No newline at end of file
diff --git a/docs/user-guide/telemetry.md b/docs/user-guide/telemetry.md
old mode 100644
new mode 100755
index 5b8d9ba101..010a3d842b
--- a/docs/user-guide/telemetry.md
+++ b/docs/user-guide/telemetry.md
@@ -5,7 +5,7 @@
* [Where data is sent](#where-data-is-sent)
-Introduction
+## Introduction
============
Devtron collects anonymous telemetry data that helps the Devtron team in understanding how the product is being used and in deciding what to focus on next.
@@ -18,7 +18,7 @@ As a growing community, it is very valuable in helping us make the Devtron a bet
-What data is collected
+## What data is collected
======================
Here is a sample event JSON which is collected and sent:
@@ -121,7 +121,7 @@ Here is a sample summary JSON which is available under properties:
Dashboard sends the `identify` event when user visits the Dashboard for the first time.
-Where data is sent
+## Where data is sent
======================
The data is sent to Posthog server.
\ No newline at end of file
diff --git a/docs/user-guide/use-cases/README.md b/docs/user-guide/use-cases/README.md
old mode 100644
new mode 100755
index e0bdab8660..35b6d4fb52
--- a/docs/user-guide/use-cases/README.md
+++ b/docs/user-guide/use-cases/README.md
@@ -1,3 +1,7 @@
+---
+hide_table_of_contents: true
+---
+
# Use Cases
_**Welcome, this document consists of Devtron Use Cases**_
@@ -10,4 +14,4 @@ In this comprehensive guide, you will find a wide range of use cases, illustrati
[Connect Expressjs With Mongodb Database](connect-expressjs-with-mongodb-database.md)
-[Connect Django With Mysql Database](connect-django-with-mysql-database.md)
+[Connect Django With Mysql Database](connect-django-with-mysql-database.md)
\ No newline at end of file
diff --git a/docs/user-guide/use-cases/connect-django-with-mysql-database.md b/docs/user-guide/use-cases/connect-django-with-mysql-database.md
old mode 100644
new mode 100755
index 5ba60e14a4..978e441bb1
--- a/docs/user-guide/use-cases/connect-django-with-mysql-database.md
+++ b/docs/user-guide/use-cases/connect-django-with-mysql-database.md
@@ -4,15 +4,15 @@
Django is a free, open-source web framework written in Python programming language. It allows for scalability, re-usability, and rapid development. Django can be connected to different databases like MySQL, PostgreSQL, etc.
-### **1. Deploy a mysql Helm Chart**
+### 1. Deploy a mysql Helm Chart
-To deploy mysql Helm Chart, you can refer to our documentation on [Deploy mysql Helm Chart](../deploy-chart/examples/deploying-mysql-helm-chart.md)
+To deploy mysql Helm Chart, you can refer to our documentation on [Deploy mysql Helm Chart](../deploy-chart/deployment-of-charts.md#example).
-### **2. Fork the Git Repository**
+### 2. Fork the Git Repository
For this example, we are using the following [GitHub Repo](https://github.com/devtron-labs/django-repo.git), you can clone this repository and make following changes in the files.
-#### _\*Configure Database Settings_
+#### Configure Database Settings
Go to mysite/settings.py.
@@ -33,33 +33,34 @@ The `settings.py` contains the configuration for your SQL database. Make sure th
}
```
-### **3. Create Application on Devtron**
+### 3. Create Application on Devtron
To learn how to create an application on Devtron, refer to our documentation on [Creating Application](../creating-application/)
-#### _\*Git Repository_
+#### Git Repository
In this example, we are using the url of the forked Git Repository.
-#### _\*Docker configuration_
+#### Docker configuration
Give, the path of the Dockerfile.
-#### _\*Configure Deployment Template_
+#### Configure Deployment Template
Enable `Ingress`, and give the path on which you want to host the application.
+
Figure 1: Django Ingress Template
-#### _\*Set up the CI/CD Pipelines_
+#### Set up the CI/CD Pipelines
Set up the CI/CD pipelines. You can set them to trigger automatically or manually.
-#### _\*Trigger Pipelines_
+#### Trigger Pipelines
Trigger the CI Pipeline, build should be **Successful**, then trigger the CD Pipeline, deployment pipeline will be initiated, after some time the status should be **Healthy**.
-### **4. Final Step**
+### 4. Final Step
Check the Django app connected to mysql database, running successfully by hitting your application url.
@@ -68,4 +69,4 @@ The syntax is: `http:////`
_**path**_ will be the one that you have given in Step 3 while configuring the Deployment Template.
-
+
Figure 2: Demo
\ No newline at end of file
diff --git a/docs/user-guide/use-cases/connect-expressjs-with-mongodb-database.md b/docs/user-guide/use-cases/connect-expressjs-with-mongodb-database.md
old mode 100644
new mode 100755
index eb02b78a3f..7cc1bb39db
--- a/docs/user-guide/use-cases/connect-expressjs-with-mongodb-database.md
+++ b/docs/user-guide/use-cases/connect-expressjs-with-mongodb-database.md
@@ -6,15 +6,15 @@ In this application, you will learn about how to create a Expressjs Application
Follow the below-mentioned steps, to deploy the application on Devtron using mongoDb Helm Chart.
-## **1. Deploy mongoDb Helm Chart**
+## 1. Deploy mongoDb Helm Chart
-To deploy mongoDb Helm Chart, you can refer to our documentation on [Deploy mongoDb Helm Chart](../deploy-chart/examples/deploying-mongodb-helm-chart.md)
+To deploy mongoDb Helm Chart, you can refer to our documentation on [Deploy mongoDb Helm Chart](../deploy-chart/deployment-of-charts.md#example).
-## **2. Fork the Git Repository**
+## 2. Fork the Git Repository
For this example, we are using the following [GitHub Repo](https://github.com/devtron-labs/DockerNodeMongo), you can clone this repository and make following changes in the files.
-### _\*Dockerfile_
+### Dockerfile
This is the Dockerfile. This exposes our expressjs application to port number 8080
@@ -28,7 +28,7 @@ CMD node server.js
EXPOSE 8080
```
-### _\*db.js File_
+### db.js File
This file will be used to connect to our database. This will include the `service-name` of the mongoDb Helm Chart, that you have deployed in Step1.
@@ -44,35 +44,37 @@ module.exports = {
}
```
-## **3. Create Application on Devtron**
+## 3. Create Application on Devtron
To learn how to create an application on Devtron, refer to our documentation on [Creating Application](../creating-application/)
-### _\*Git Repository_
+### Git Repository
In this example, we are using the url of the forked Git Repository.
-### _\*Docker configuration_
+### Docker configuration
Give, the path of the Dockerfile.
-### _\*Configure Deployment Template_
+### Configure Deployment Template
Enable `Ingress`, and give the path on which you want to host the application.
+
-### _\*Set up the CI/CD Pipelines_
+### Set up the CI/CD Pipelines
Set up the CI/CD pipelines. You can set them to trigger automatically or manually.
-### _\*Trigger Pipelines_
+### Trigger Pipelines
Trigger the CI Pipeline, build should be **Successful**, then trigger the CD Pipeline, deployment pipeline will be initiated, after some time the status should be **Healthy**
-## **4. Final Step**
+## 4. Final Step
Check the Expressjs app connected to mongodb database, running successfully by hitting your application url.
@@ -83,6 +85,6 @@ _**path**_ will be the one that you have given in Step 3 while configuring the D
The output of our application would be as follows:
+
Figure 3: Use Case ExpressJS View Demo Data
-You can see that we are getting the JSON response. We have successfully connected our expressjs application to the mongoDb database.
-
+You can see that we are getting the JSON response. We have successfully connected our expressjs application to the mongoDb database.
\ No newline at end of file
diff --git a/docs/user-guide/use-cases/connect-springboot-with-mysql-database.md b/docs/user-guide/use-cases/connect-springboot-with-mysql-database.md
old mode 100644
new mode 100755
index ff351bda30..5b6a1dfacc
--- a/docs/user-guide/use-cases/connect-springboot-with-mysql-database.md
+++ b/docs/user-guide/use-cases/connect-springboot-with-mysql-database.md
@@ -4,15 +4,15 @@
This document will help you to deploy a sample Spring Boot Application, using **mysql Helm Chart**
-### **1. Deploy a mysql Helm Chart**
+### 1. Deploy a mysql Helm Chart
-To deploy mysql Helm Chart, you can refer to our documentation on [Deploy mysql Helm Chart](../deploy-chart/examples/deploying-mysql-helm-chart.md)
+To deploy mysql Helm Chart, you can refer to our documentation on [Deploy mysql Helm Chart](../deploy-chart/deployment-of-charts.md#example)
-### **2. Fork the Git Repository**
+### 2. Fork the Git Repository
For this example, we are using the following [GitHub Repo](https://github.com/devtron-labs/springboot), you can clone this repository and make following changes in the files.
-#### _\*Configure application.properties_
+#### Configure application.properties
Set the database configuration in this file.
@@ -27,7 +27,7 @@ spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.MySQL5Dialect
spring.jpa.open-in-view=true
```
-#### _Configure the Dockerfile_
+#### Configure the Dockerfile
```bash
# syntax=docker/dockerfile:experimental
@@ -51,41 +51,42 @@ COPY --from=build /workspace/app/target/docker-demo-0.0.1-SNAPSHOT.jar app.jar
ENTRYPOINT ["java","-jar", "app.jar"]
```
-### **3. Create Application on Devtron**
+### 3. Create Application on Devtron
To learn how to create an application on Devtron, refer to our documentation on [Creating Application](../creating-application/)
-#### _\*Git Repository_
+#### Git Repository
In this example, we are using the url of the forked Git repository.
-#### _\*Docker configuration_
+#### Docker configuration
Give, the path of the Dockerfile.
-#### _\*\*\_Configure Deployment Template_\*\_
+#### Configure Deployment Template
Enable `Ingress`, and give the path on which you want to host the application.
+
Figure 1: Enable Ingress
-#### _\*Set up the CI/CD Pipelines_
+#### Set up the CI/CD Pipelines
Set up the CI/CD pipelines. You can set them to trigger automatically or manually.
-#### _\*Trigger Pipelines_
+#### Trigger Pipelines
Trigger the CI Pipeline, build should be **Successful**. Then trigger the CD Pipeline, deployment pipeline will be initiated, after some time the status should be **Healthy**.
### **4. Final Step**
-#### _\*Test Rest API_
+#### Test Rest API
It exposes 3 REST endpoints for it's users to create, to _view specific_ student record and _view all_ student records.
To test Rest API, you can use _curl_ command line tool
-_**Create a new Student Record**_
+**Create a new Student Record**
Create a new POST request to create a new Transaction. Once the transaction is successfully created, you will get the _student id_ as a response.
@@ -95,7 +96,7 @@ Curl Request is as follows:
sudo curl -d '{"name": "Anushka", "marks": 98}' -H "Content-Type: application/json" -X POST http:////create
```
-_**View All Student's Data**_
+**View All Student's Data**
To view all student records, GET Request is:
@@ -104,8 +105,9 @@ _**path**_ will be the one that you have given in Step 3 while configuring the D
`http:////viewAll`
+
Figure 2: Use Cases Springboot View Student Data
-_**View student's data By student ID**_
+**View student's data By student ID**
To view student data by student id, GET Request is:
@@ -114,4 +116,4 @@ To view student data by student id, GET Request is:
_**path**_ will be the one that you have given in Step 3 while configuring the Deployment Template.
-
+
Figure 3: Use Case ExpressJs View Student Data With Id
\ No newline at end of file
diff --git a/docs/user-guide/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job.md b/docs/user-guide/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job.md
old mode 100644
new mode 100755
index c9b61da93b..3e8d0a4162
--- a/docs/user-guide/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job.md
+++ b/docs/user-guide/use-cases/devtron-generic-helm-chart-to-run-cron-job-or-one-time-job.md
@@ -1,6 +1,10 @@
+---
+hide_table_of_contents: true
+---
+
# Devtron Generic Helm Chart To Run Cron Job Or One Time Job
-**Devtron also supports Job and Cronjob pipelines. If you need to regularly update the image and configurations of your cronjob/job, you should prefer to create a pipeline,To know more about this you can refer the link** [cronjob/job documentation](../creating-application/base-config/deployment-template/job-and-cronjob.md).
+Devtron also supports Job and Cronjob pipelines. If you need to regularly update the image and configurations of your cronjob/job, you should prefer to create a pipeline,To know more about this you can refer the link [cronjob/job documentation](../creating-application/base-config/deployment-template-types/job-and-cronjob.md).
## Using Devtron-generic-Helm Chart to run Cron Job or One Time job
@@ -11,16 +15,19 @@ You can use Devtron's generic helm chart to run the CronJobs or one time Job.
Select the `devtron-charts/devtron-generic-helm` chart from the Devtron Chart Store.
+
Figure 1: Use Case Chart Store
Select the Chart Version and the Chart Value of the Chart.
And, then click on `Deploy`
+
Click on **Deploy Chart**
@@ -32,5 +39,4 @@ Click on **Deploy Chart**
| `Chart Version` | Select the Version of the chart |
| `Chart Values` | Select the Chart Value or Create a Custom Value |
-In **values.yaml**, you can specify the YAML file that schedules the CronJob for your application.
-
+In **values.yaml**, you can specify the YAML file that schedules the CronJob for your application.
\ No newline at end of file
diff --git a/docs/user-guide/use-cases/oci-pull.md b/docs/user-guide/use-cases/oci-pull.md
old mode 100644
new mode 100755
index d62cc0a753..e6b2e38817
--- a/docs/user-guide/use-cases/oci-pull.md
+++ b/docs/user-guide/use-cases/oci-pull.md
@@ -15,7 +15,7 @@ You must [add your OCI registry](../global-configurations/container-registries.m
## Tutorial
-{% embed url="https://www.youtube.com/watch?v=9imC5MMz9gs" caption="Pulling Charts from an OCI Registry to Devtron" %}
+
---
@@ -27,7 +27,8 @@ You must [add your OCI registry](../global-configurations/container-registries.m
3. In the **List of repositories**, add the chart repo(s). The format should be `username/chartname`. You can find the username from your registry provider account.
- 
+ 
+
Figure 1: Adding Chart Repos
4. Click **Save** or **Update**.
@@ -35,21 +36,25 @@ You must [add your OCI registry](../global-configurations/container-registries.m
6. You can find your chart(s) either by using the search bar or by selecting your chart source.
- 
+ 
+
Figure 2: Searching your Chart
You have successfully pulled your charts to the chart store.
-
+
+
Figure 3: Uploaded Helm Charts
### Unable to find your Charts?
Deprecated charts won't show up in the Chart Store unless you enable the **Show deprecated charts** filter as shown below
-
+
+
Figure 4: Checking Deprecated Charts
Or, you may try performing a resync as shown below
-
+
+
Figure 5: Performing a Resync
---
@@ -60,14 +65,13 @@ Or, you may try performing a resync as shown below
2. In the **List of repositories** field, remove the unwanted chart repo.
- 
+ 
+
Figure 6: Removing a Chart Repo
3. Click **Update**.
The removed chart would no longer appear in the Chart Store.
-{% hint style="info" %}
+:::info
Deleting a chart repo from your OCI registry will not lead to the removal of chart from the Chart Store
-{% endhint %}
-
-
+:::
\ No newline at end of file
diff --git a/docs/user-guide/use-cases/prometheus-stack-over-devtron.md b/docs/user-guide/use-cases/prometheus-stack-over-devtron.md
old mode 100644
new mode 100755
index 666ca32a7a..560c61a0b6
--- a/docs/user-guide/use-cases/prometheus-stack-over-devtron.md
+++ b/docs/user-guide/use-cases/prometheus-stack-over-devtron.md
@@ -8,6 +8,7 @@ Prometheus is an open-source technology designed to provide monitoring and alert
### Search for Prometheus and choose the kube-prometheus-stack chart of prometheus-community repo.
+
Figure 1: Prometheus Chart
### ***We have to configure below values in values.yaml***
@@ -35,4 +36,4 @@ serviceMonitorSelectorNilUsesHelmValues: false
Here we can see the all the resources of this stack are in healthy state .
-
+
Figure 2: Prometheus Demo
\ No newline at end of file
diff --git a/docs/user-guide/user-guide.md b/docs/user-guide/user-guide.md
old mode 100644
new mode 100755
index a1e5a18d62..34ea7e144b
--- a/docs/user-guide/user-guide.md
+++ b/docs/user-guide/user-guide.md
@@ -8,7 +8,8 @@ Devtron is an open source software delivery workflow for kubernetes written in g
It is designed as a self-serve platform for operationalizing and maintaining applications \(AppOps\) on kubernetes in a developer friendly way.
- 
+ 
+
Figure 1: Dashboard
@@ -84,5 +85,4 @@ Check out our [contributing guidelines](https://github.com/devtron-labs/devtron-
## Vulnerability Reporting
-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 by contacting us at security@devtron.ai.
-
+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 by contacting us at security@devtron.ai.
\ No newline at end of file
diff --git a/docs/user-guide/using-application-templates.md b/docs/user-guide/using-application-templates.md
old mode 100644
new mode 100755
index 1a201a2fc5..2acf73cd82
--- a/docs/user-guide/using-application-templates.md
+++ b/docs/user-guide/using-application-templates.md
@@ -1,17 +1,16 @@
# Creating Application From Template
-## Introduction [](https://devtron.ai/pricing)
+## Introduction
Application templates provide a predefined configuration for creating new applications. You can create an application directly from an application template instead of setting up and repeating the app configuration steps from scratch (such as build configurations, base configurations, CI/CD workflows, and environment details).
Refer [Application Templates](./global-configurations/application-template.md) to learn more.
-{% hint style="warning" %}
-### Who Can Perform This Action?
+:::caution Who Can Perform This Action?
* Users need to have Admin permission or above to create applications from application templates.
* Users need to have super-admin permissions in order to customize template configurations.
-{% endhint %}
+:::
---
@@ -25,15 +24,18 @@ You can create an application using an application template by following the bel
3. Select **Custom app** from the drop-down list; a **Create Devtron Application** modal window will appear.
- 
+ 
+
Figure 1: Clicking 'Custom app'
4. Select **From template** from the left-side of the modal window; a list of all [application templates](./global-configurations/application-template.md) will appear.
- 
+ 
+
Figure 2: Selecting 'From template'
5. Select the application template from which you want to create the application; you can also search for the preferred application template from the search bar.
- 
+ 
+
Figure 3: Selecting Application Template
6. After selecting the application template, you need to provide the following details
@@ -50,18 +52,20 @@ You can create an application using an application template by following the bel
| **Workflows** | Optional | Select preferred environments for your deployment pipeline in your workflows |
- 
+ 
+
Figure 4b: Configuring Code Source, Container Registry and Environments
-{% hint style="warning" %}
-### Note
+:::caution Note
By default, configurations are inherited from the application which is used to create that application template.
-{% endhint %}
+:::
7. Click **Create Application** and the application will be created.
- 
+ 
+
Figure 5: Creating Application From Template
---
@@ -74,7 +78,8 @@ By default, configurations are inherited from the application which is used to c
**Propagate Tags**
When tags are propagated, they are considered as labels to Kubernetes resources. Kubernetes offers integrated support for using these labels to query objects and perform bulk operations e.g., consolidated billing using labels. You can use these tags to filter/identify resources via CLI or in other Kubernetes tools.
-
+
+
+
+ );
+}
diff --git a/src/pages/Faq.js b/src/pages/Faq.js
new file mode 100755
index 0000000000..e7ea682363
--- /dev/null
+++ b/src/pages/Faq.js
@@ -0,0 +1,179 @@
+import React, { useState, useMemo } from "react";
+
+/**
+ * Updated FAQ page with robust color handling for Docusaurus light/dark themes.
+ * Replace src/pages/Faq.jsx with this file.
+ */
+
+const faqData = [
+ { category: "Getting Started", question: "What is Devtron?", answer: "Devtron is a comprehensive Kubernetes platform that simplifies application deployment and management. It provides tools for CI/CD, security scanning, resource management, and more." },
+ { category: "Getting Started", question: "How do I get started with Devtron?", answer: "Start by installing Devtron on your Kubernetes cluster. You can choose from OSS, Freemium, or Enterprise editions. Follow the installation guide to set up your environment." },
+ { category: "Installation", question: "What are the system requirements for Devtron?", answer: "Devtron requires a Kubernetes cluster (v1.16+), sufficient resources (minimum 2 vCPUs and 4GB RAM), and kubectl access to your cluster." },
+ { category: "Installation", question: "How do I install Devtron?", answer: "You can install Devtron using Helm charts. Run the installation command with your preferred configuration and follow the setup wizard to complete the installation." },
+ { category: "Application Management", question: "How do I create a new application?", answer: "Navigate to Applications → Create New App. Fill in the application details, select your Git repository, configure the build and deployment pipelines, and save your application." },
+ { category: "Application Management", question: "Can I deploy multiple environments for one application?", answer: "Yes, Devtron supports multi-environment deployments. You can configure different environments (dev, staging, production) with specific configurations for each." },
+ { category: "Security", question: "What security features does Devtron provide?", answer: "Devtron includes vulnerability scanning, security policy enforcement, RBAC, secrets management, and compliance reporting to ensure your applications are secure." },
+ { category: "Security", question: "How are secrets managed in Devtron?", answer: "Secrets are encrypted at rest and in transit. You can manage secrets through the UI or integrate with external secret management systems like HashiCorp Vault." },
+ { category: "Infrastructure Management", question: "How do I connect a Kubernetes cluster?", answer: "Go to Clusters & Environments → Add Cluster. Provide your cluster credentials (kubeconfig) and Devtron will establish the connection for resource management." },
+ { category: "Infrastructure Management", question: "Can I manage multiple clusters?", answer: "Yes, Devtron supports multi-cluster management. You can connect and manage multiple Kubernetes clusters from a single Devtron instance." },
+ { category: "Cost & Performance", question: "How does cost visibility work?", answer: "Devtron tracks resource usage across your clusters and applications, providing detailed cost breakdowns by namespace, application, and resource type." },
+ { category: "Cost & Performance", question: "Can I set cost alerts?", answer: "Yes, you can configure cost thresholds and receive alerts when spending exceeds your defined limits." },
+ { category: "Troubleshooting", question: "My deployment is failing, how do I debug?", answer: "Check the deployment logs in the App Details page. Review the CI/CD pipeline logs, examine pod events, and verify your configuration settings." },
+ { category: "Troubleshooting", question: "How do I access application logs?", answer: "Navigate to your application, select the environment, and click on the pod to view real-time logs. You can also download logs for offline analysis." }
+];
+
+export default function FAQPage() {
+ const [searchQuery, setSearchQuery] = useState("");
+ const [selectedCategory, setSelectedCategory] = useState(null);
+ const [openIndex, setOpenIndex] = useState(null);
+
+ const categories = useMemo(() => Array.from(new Set(faqData.map((f) => f.category))), []);
+ const filteredFAQs = useMemo(() => {
+ return faqData.filter((f) => {
+ const matchesSearch =
+ f.question.toLowerCase().includes(searchQuery.toLowerCase()) ||
+ f.answer.toLowerCase().includes(searchQuery.toLowerCase());
+ const matchesCategory = !selectedCategory || f.category === selectedCategory;
+ return matchesSearch && matchesCategory;
+ });
+ }, [searchQuery, selectedCategory]);
+
+ const grouped = useMemo(() => {
+ const groups = {};
+ filteredFAQs.forEach((f) => {
+ if (!groups[f.category]) groups[f.category] = [];
+ groups[f.category].push(f);
+ });
+ return groups;
+ }, [filteredFAQs]);
+
+ return (
+
+ {/* Localized CSS variables to make color behavior robust across themes */}
+
+
+
+ );
+}
diff --git a/src/theme/Navbar/MobileSidebar/PrimaryMenu/index.js b/src/theme/Navbar/MobileSidebar/PrimaryMenu/index.js
new file mode 100755
index 0000000000..9c5d0ec067
--- /dev/null
+++ b/src/theme/Navbar/MobileSidebar/PrimaryMenu/index.js
@@ -0,0 +1,27 @@
+import React from 'react';
+import {useThemeConfig} from '@docusaurus/theme-common';
+import {useNavbarMobileSidebar} from '@docusaurus/theme-common/internal';
+import NavbarItem from '@theme/NavbarItem';
+function useNavbarItems() {
+ // TODO temporary casting until ThemeConfig type is improved
+ return useThemeConfig().navbar.items;
+}
+// The primary menu displays the navbar items
+export default function NavbarMobilePrimaryMenu() {
+ const mobileSidebar = useNavbarMobileSidebar();
+ // TODO how can the order be defined for mobile?
+ // Should we allow providing a different list of items?
+ const items = useNavbarItems();
+ return (
+
+ );
+}
diff --git a/src/theme/Navbar/MobileSidebar/SecondaryMenu/index.js b/src/theme/Navbar/MobileSidebar/SecondaryMenu/index.js
new file mode 100755
index 0000000000..dd71af856a
--- /dev/null
+++ b/src/theme/Navbar/MobileSidebar/SecondaryMenu/index.js
@@ -0,0 +1,30 @@
+import React from 'react';
+import {useThemeConfig} from '@docusaurus/theme-common';
+import {useNavbarSecondaryMenu} from '@docusaurus/theme-common/internal';
+import Translate from '@docusaurus/Translate';
+function SecondaryMenuBackButton(props) {
+ return (
+
+ );
+}
+// The secondary menu slides from the right and shows contextual information
+// such as the docs sidebar
+export default function NavbarMobileSidebarSecondaryMenu() {
+ const isPrimaryMenuEmpty = useThemeConfig().navbar.items.length === 0;
+ const secondaryMenu = useNavbarSecondaryMenu();
+ return (
+ <>
+ {/* edge-case: prevent returning to the primaryMenu when it's empty */}
+ {!isPrimaryMenuEmpty && (
+ secondaryMenu.hide()} />
+ )}
+ {secondaryMenu.content}
+
+ );
+}
diff --git a/src/theme/Navbar/MobileSidebar/Toggle/index.js b/src/theme/Navbar/MobileSidebar/Toggle/index.js
new file mode 100755
index 0000000000..bfe298891b
--- /dev/null
+++ b/src/theme/Navbar/MobileSidebar/Toggle/index.js
@@ -0,0 +1,22 @@
+import React from 'react';
+import {useNavbarMobileSidebar} from '@docusaurus/theme-common/internal';
+import {translate} from '@docusaurus/Translate';
+import IconMenu from '@theme/Icon/Menu';
+export default function MobileSidebarToggle() {
+ const {toggle, shown} = useNavbarMobileSidebar();
+ return (
+
+ );
+}
diff --git a/src/theme/Navbar/MobileSidebar/index.js b/src/theme/Navbar/MobileSidebar/index.js
new file mode 100755
index 0000000000..5db3cc7a28
--- /dev/null
+++ b/src/theme/Navbar/MobileSidebar/index.js
@@ -0,0 +1,23 @@
+import React from 'react';
+import {
+ useLockBodyScroll,
+ useNavbarMobileSidebar,
+} from '@docusaurus/theme-common/internal';
+import NavbarMobileSidebarLayout from '@theme/Navbar/MobileSidebar/Layout';
+import NavbarMobileSidebarHeader from '@theme/Navbar/MobileSidebar/Header';
+import NavbarMobileSidebarPrimaryMenu from '@theme/Navbar/MobileSidebar/PrimaryMenu';
+import NavbarMobileSidebarSecondaryMenu from '@theme/Navbar/MobileSidebar/SecondaryMenu';
+export default function NavbarMobileSidebar() {
+ const mobileSidebar = useNavbarMobileSidebar();
+ useLockBodyScroll(mobileSidebar.shown);
+ if (!mobileSidebar.shouldRender) {
+ return null;
+ }
+ return (
+ }
+ primaryMenu={}
+ secondaryMenu={}
+ />
+ );
+}
diff --git a/src/theme/Navbar/Search/index.js b/src/theme/Navbar/Search/index.js
new file mode 100755
index 0000000000..686f73b8d8
--- /dev/null
+++ b/src/theme/Navbar/Search/index.js
@@ -0,0 +1,10 @@
+import React from 'react';
+import clsx from 'clsx';
+import styles from './styles.module.css';
+export default function NavbarSearch({children, className}) {
+ return (
+
+ {children}
+
+ );
+}
diff --git a/src/theme/Navbar/Search/styles.module.css b/src/theme/Navbar/Search/styles.module.css
new file mode 100755
index 0000000000..6dfe189df9
--- /dev/null
+++ b/src/theme/Navbar/Search/styles.module.css
@@ -0,0 +1,20 @@
+/*
+Workaround to avoid rendering empty search container
+See https://github.com/facebook/docusaurus/pull/9385
+*/
+.navbarSearchContainer:empty {
+ display: none;
+}
+
+@media (max-width: 996px) {
+ .navbarSearchContainer {
+ position: absolute;
+ right: var(--ifm-navbar-padding-horizontal);
+ }
+}
+
+@media (min-width: 997px) {
+ .navbarSearchContainer {
+ padding: 0 var(--ifm-navbar-item-padding-horizontal);
+ }
+}
diff --git a/src/theme/Navbar/index.js b/src/theme/Navbar/index.js
new file mode 100755
index 0000000000..d18a258ca9
--- /dev/null
+++ b/src/theme/Navbar/index.js
@@ -0,0 +1,10 @@
+import React from 'react';
+import NavbarLayout from '@theme/Navbar/Layout';
+import NavbarContent from '@theme/Navbar/Content';
+export default function Navbar() {
+ return (
+
+
+
+ );
+}
diff --git a/src/theme/Root.js b/src/theme/Root.js
new file mode 100755
index 0000000000..5b4b9b9dcd
--- /dev/null
+++ b/src/theme/Root.js
@@ -0,0 +1,89 @@
+import React, { useEffect } from 'react';
+import { useLocation } from '@docusaurus/router';
+
+export default function Root({ children }) {
+ const location = useLocation();
+
+ useEffect(() => {
+ // function to classify images
+ function markSnapshotImages() {
+ const allImages = document.querySelectorAll(".markdown img");
+
+ allImages.forEach((img) => {
+ if (
+ img.classList.contains("enterprise-badge-img") || // skip enterprise badges
+ img.closest(".inline-badge") || // skip inline badges
+ img.width <= 64 || // skip tiny icons
+ img.closest("a") // ✅ skip linked images
+ ) {
+ return;
+ }
+ img.classList.add("snapshot-img");
+ });
+ }
+
+ // run initially
+ markSnapshotImages();
+
+ // re-run when Docusaurus SPA swaps content
+ const observer = new MutationObserver(markSnapshotImages);
+ observer.observe(document.body, { childList: true, subtree: true });
+
+ function handleClick(e) {
+ if (
+ e.target.tagName === "IMG" &&
+ e.target.closest(".markdown") &&
+ e.target.classList.contains("snapshot-img")
+ ) {
+ const src = e.target.src;
+ const lightbox = document.createElement("div");
+ lightbox.classList.add("image-lightbox");
+ lightbox.innerHTML = ``;
+
+ function closeLightbox() {
+ lightbox.classList.add("closing");
+ setTimeout(() => lightbox.remove(), 250); // match zoomOut duration
+ }
+
+ // Close on click
+ lightbox.onclick = closeLightbox;
+
+ // Close on ESC key
+ document.addEventListener(
+ "keydown",
+ (ev) => {
+ if (ev.key === "Escape") closeLightbox();
+ },
+ { once: true }
+ );
+
+ document.body.appendChild(lightbox);
+ }
+ }
+
+ document.addEventListener("click", handleClick);
+
+ return () => {
+ document.removeEventListener("click", handleClick);
+ observer.disconnect();
+ };
+ }, []);
+
+ useEffect(() => {
+ if (!location.hash) return;
+
+ // Clean the hash: remove ?utm_* junk
+ const cleanId = location.hash
+ .replace('#', '')
+ .split('?')[0];
+
+ if (!cleanId) return;
+
+ const element = document.getElementById(cleanId);
+ if (element) {
+ element.scrollIntoView();
+ }
+ }, [location.pathname]);
+
+ return <>{children};
+}
diff --git a/docs/.gitbook/assets/gc b/static/.nojekyll
old mode 100644
new mode 100755
similarity index 100%
rename from docs/.gitbook/assets/gc
rename to static/.nojekyll
diff --git a/static/CNAME b/static/CNAME
new file mode 100755
index 0000000000..9047fc1c40
--- /dev/null
+++ b/static/CNAME
@@ -0,0 +1 @@
+docs.devtron.ai
\ No newline at end of file
diff --git a/assets/devtron-logo-plugin.png b/static/img/devtron-favicon.png
old mode 100644
new mode 100755
similarity index 100%
rename from assets/devtron-logo-plugin.png
rename to static/img/devtron-favicon.png
diff --git a/static/img/devtron-social-card.jpg b/static/img/devtron-social-card.jpg
new file mode 100755
index 0000000000..ef3d1efc93
Binary files /dev/null and b/static/img/devtron-social-card.jpg differ
diff --git a/static/img/docusaurus-social-card.jpg b/static/img/docusaurus-social-card.jpg
new file mode 100755
index 0000000000..ffcb448210
Binary files /dev/null and b/static/img/docusaurus-social-card.jpg differ
diff --git a/static/img/docusaurus.png b/static/img/docusaurus.png
new file mode 100755
index 0000000000..f458149e3c
Binary files /dev/null and b/static/img/docusaurus.png differ
diff --git a/static/img/favicon.ico b/static/img/favicon.ico
new file mode 100755
index 0000000000..c01d54bcd3
Binary files /dev/null and b/static/img/favicon.ico differ
diff --git a/static/img/hero-illustration.svg b/static/img/hero-illustration.svg
new file mode 100755
index 0000000000..1e3701d0b7
--- /dev/null
+++ b/static/img/hero-illustration.svg
@@ -0,0 +1,13 @@
+
diff --git a/static/img/hlogos/devtron-logo-horizontal-black.png b/static/img/hlogos/devtron-logo-horizontal-black.png
new file mode 100755
index 0000000000..32c4e1d9b8
Binary files /dev/null and b/static/img/hlogos/devtron-logo-horizontal-black.png differ
diff --git a/static/img/hlogos/devtron-logo-horizontal-black.svg b/static/img/hlogos/devtron-logo-horizontal-black.svg
new file mode 100755
index 0000000000..89a5d4f6c5
--- /dev/null
+++ b/static/img/hlogos/devtron-logo-horizontal-black.svg
@@ -0,0 +1,4 @@
+
diff --git a/static/img/hlogos/devtron-logo-horizontal-blue.png b/static/img/hlogos/devtron-logo-horizontal-blue.png
new file mode 100755
index 0000000000..460e5965dc
Binary files /dev/null and b/static/img/hlogos/devtron-logo-horizontal-blue.png differ
diff --git a/static/img/hlogos/devtron-logo-horizontal-blue.svg b/static/img/hlogos/devtron-logo-horizontal-blue.svg
new file mode 100755
index 0000000000..06ec0c61cc
--- /dev/null
+++ b/static/img/hlogos/devtron-logo-horizontal-blue.svg
@@ -0,0 +1,4 @@
+
diff --git a/static/img/hlogos/devtron-logo-horizontal-dual.png b/static/img/hlogos/devtron-logo-horizontal-dual.png
new file mode 100755
index 0000000000..55417ccf86
Binary files /dev/null and b/static/img/hlogos/devtron-logo-horizontal-dual.png differ
diff --git a/static/img/hlogos/devtron-logo-horizontal-dual.svg b/static/img/hlogos/devtron-logo-horizontal-dual.svg
new file mode 100755
index 0000000000..915e64062b
--- /dev/null
+++ b/static/img/hlogos/devtron-logo-horizontal-dual.svg
@@ -0,0 +1,4 @@
+
diff --git a/static/img/hlogos/devtron-logo-horizontal-white.png b/static/img/hlogos/devtron-logo-horizontal-white.png
new file mode 100755
index 0000000000..4770fb2f38
Binary files /dev/null and b/static/img/hlogos/devtron-logo-horizontal-white.png differ
diff --git a/static/img/hlogos/devtron-logo-horizontal-white.svg b/static/img/hlogos/devtron-logo-horizontal-white.svg
new file mode 100755
index 0000000000..02fa4f37fa
--- /dev/null
+++ b/static/img/hlogos/devtron-logo-horizontal-white.svg
@@ -0,0 +1,4 @@
+
diff --git a/static/img/just-logos/devtron-logo-black.png b/static/img/just-logos/devtron-logo-black.png
new file mode 100755
index 0000000000..befca4c6ed
Binary files /dev/null and b/static/img/just-logos/devtron-logo-black.png differ
diff --git a/static/img/just-logos/devtron-logo-blue.png b/static/img/just-logos/devtron-logo-blue.png
new file mode 100755
index 0000000000..fc17baf728
Binary files /dev/null and b/static/img/just-logos/devtron-logo-blue.png differ
diff --git a/static/img/just-logos/devtron-logo-white.png b/static/img/just-logos/devtron-logo-white.png
new file mode 100755
index 0000000000..33946647dc
Binary files /dev/null and b/static/img/just-logos/devtron-logo-white.png differ
diff --git a/static/img/logo.svg b/static/img/logo.svg
new file mode 100755
index 0000000000..9db6d0d066
--- /dev/null
+++ b/static/img/logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/static/img/socials/blog.svg b/static/img/socials/blog.svg
new file mode 100755
index 0000000000..ba3cd308c5
--- /dev/null
+++ b/static/img/socials/blog.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/static/img/socials/discord.svg b/static/img/socials/discord.svg
new file mode 100755
index 0000000000..9d7796b8a3
--- /dev/null
+++ b/static/img/socials/discord.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/static/img/socials/github.svg b/static/img/socials/github.svg
new file mode 100755
index 0000000000..538ec5bf2a
--- /dev/null
+++ b/static/img/socials/github.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/static/img/socials/linkedin.svg b/static/img/socials/linkedin.svg
new file mode 100755
index 0000000000..c66342908b
--- /dev/null
+++ b/static/img/socials/linkedin.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/static/img/socials/x.svg b/static/img/socials/x.svg
new file mode 100755
index 0000000000..26be660090
--- /dev/null
+++ b/static/img/socials/x.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/static/img/undraw_docusaurus_mountain.svg b/static/img/undraw_docusaurus_mountain.svg
new file mode 100755
index 0000000000..af961c49a8
--- /dev/null
+++ b/static/img/undraw_docusaurus_mountain.svg
@@ -0,0 +1,171 @@
+
diff --git a/static/img/undraw_docusaurus_react.svg b/static/img/undraw_docusaurus_react.svg
new file mode 100755
index 0000000000..94b5cf08f8
--- /dev/null
+++ b/static/img/undraw_docusaurus_react.svg
@@ -0,0 +1,170 @@
+
diff --git a/static/img/undraw_docusaurus_tree.svg b/static/img/undraw_docusaurus_tree.svg
new file mode 100755
index 0000000000..d9161d3392
--- /dev/null
+++ b/static/img/undraw_docusaurus_tree.svg
@@ -0,0 +1,40 @@
+
diff --git a/static/img/vlogos/devtron-logo-vertical-black.png b/static/img/vlogos/devtron-logo-vertical-black.png
new file mode 100755
index 0000000000..dbef49d372
Binary files /dev/null and b/static/img/vlogos/devtron-logo-vertical-black.png differ
diff --git a/static/img/vlogos/devtron-logo-vertical-blue.png b/static/img/vlogos/devtron-logo-vertical-blue.png
new file mode 100755
index 0000000000..2a3cb215af
Binary files /dev/null and b/static/img/vlogos/devtron-logo-vertical-blue.png differ
diff --git a/static/img/vlogos/devtron-logo-vertical-blueblack.png b/static/img/vlogos/devtron-logo-vertical-blueblack.png
new file mode 100755
index 0000000000..ecf9e76ae1
Binary files /dev/null and b/static/img/vlogos/devtron-logo-vertical-blueblack.png differ
diff --git a/static/img/vlogos/devtron-logo-vertical-bluegrey.png b/static/img/vlogos/devtron-logo-vertical-bluegrey.png
new file mode 100755
index 0000000000..c7b67a949a
Binary files /dev/null and b/static/img/vlogos/devtron-logo-vertical-bluegrey.png differ
diff --git a/static/img/vlogos/devtron-logo-vertical-white.png b/static/img/vlogos/devtron-logo-vertical-white.png
new file mode 100755
index 0000000000..982279f8f4
Binary files /dev/null and b/static/img/vlogos/devtron-logo-vertical-white.png differ
diff --git a/static/js/reo.js b/static/js/reo.js
new file mode 100755
index 0000000000..d49fae9104
--- /dev/null
+++ b/static/js/reo.js
@@ -0,0 +1 @@
+!function(){var e,t,n;e="XXXXXX",t=function(){Reo.init({clientID:"XXXXXX"})},(n=document.createElement("script")).src="https://static.reo.dev/"+e+"/reo.js",n.async=!0,n.onload=t,document.head.appendChild(n)}();
\ No newline at end of file
diff --git a/static/robots.txt b/static/robots.txt
new file mode 100644
index 0000000000..2771b790f1
--- /dev/null
+++ b/static/robots.txt
@@ -0,0 +1,4 @@
+User-agent: *
+Allow: /
+
+Sitemap: https://docs.devtron.ai/sitemap.xml
\ No newline at end of file
diff --git a/tools/parse-mdx.mjs b/tools/parse-mdx.mjs
new file mode 100755
index 0000000000..0b7f3a121d
--- /dev/null
+++ b/tools/parse-mdx.mjs
@@ -0,0 +1,29 @@
+// tools/parse-mdx.mjs
+import fs from 'fs';
+import path from 'path';
+import {compile} from '@mdx-js/mdx';
+
+async function main() {
+ const p = process.argv[2];
+ if (!p) {
+ console.error('Usage: node tools/parse-mdx.mjs path/to/file.md');
+ process.exit(2);
+ }
+ const file = path.resolve(p);
+ const src = fs.readFileSync(file, 'utf8');
+ try {
+ // compile will throw a descriptive error for broken MDX
+ await compile(src, {providerImportSource: '@mdx-js/react'});
+ console.log('✅ MDX parsed OK:', file);
+ } catch (err) {
+ // show the full error (stack + message + location)
+ console.error('--- MDX PARSE ERROR ---');
+ console.error(err);
+ // if err.position or err.loc exist, print them clearly
+ if (err.position) console.error('position:', err.position);
+ if (err.loc) console.error('loc:', err.loc);
+ process.exit(1);
+ }
+}
+
+main();
diff --git a/versioned_docs/version-1.7/FAQs/devtron-troubleshoot.md b/versioned_docs/version-1.7/FAQs/devtron-troubleshoot.md
new file mode 100755
index 0000000000..0a886ad4ee
--- /dev/null
+++ b/versioned_docs/version-1.7/FAQs/devtron-troubleshoot.md
@@ -0,0 +1,636 @@
+---
+id: devtron-troubleshoot
+title: Troubleshooting Guide
+sidebar_label: Troubleshooting Guide
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Troubleshooting Guide
+
+We always try to make your experience of using Devtron as smooth as possible but still if you face any issues, follow the troubleshooting guide given below or join our [discord channel](https://discord.gg/jsRG5qx2gp) if you couldn't find the solution for the issue you are facing.
+
+#### 1. How to resolve unauthorized errors, while trying to save global configurations like hostname, GitOps etc. after successful devtron installation
+
+This occurs most of the time because any one or multiple jobs get failed during installation. To resolve this, you'll need to first check which jobs have failed. Follow these steps:
+
+- Run the following command and check which are the jobs with 0/1 completions:
+```bash
+kubectl get jobs -n devtroncd
+```
+- Note down or remember the names of jobs with 0/1 completions and check if their pods are in running state still or not by running the command:
+```bash
+kubectl get pods -n devtroncd
+```
+- If they are in running condition, please wait for the jobs to be completed as it may be due to internet issue. And if not in running condition, then delete those incomplete jobs using command:
+
+```bash
+kubectl delete jobs -n devtroncd
+```
+
+- Now download `migrator.yaml` file from our GitHub repository using the command:
+```bash
+wget https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/yamls/migrator.yaml
+```
+- Now edit the file you downloaded in step 3 and remove the postgresql-migrator secret resource creation and then apply the yaml file using the command:
+```bash
+kubectl apply -f migrator.yaml -n devtroncd
+```
+- It will re-create the failed jobs and you’ll see their pods created again. Just wait for a few minutes until the jobs gets completed then you are good to go. You should be able to save your global configurations now.
+
+#### 2. Not able to see deployment metrics on production environment or Not able to enable application-metrics or Not able to deploy the app after creating a configmap or secret with data-volume option enabled
+
+Update the rollout CRDs to latest version, run the following command:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/yamls/rollout.yaml -n devtroncd
+```
+
+#### 3. SSO Login not working even after entering correct SSO Credentials
+
+```error: user/UserAuthHandler.go:236","msg":"service err, AuthVerification","err":"no token provided```
+
+Or
+
+```error: Failed to query provider "api/dex": Get "api/dex/.well-known/openid-configuration": unsupported protocol scheme```
+
+Delete devtron pod once to reload the configurations using:
+
+```bash
+kubectl delete pod -n devtroncd -l app=devtron
+```
+
+#### 4. Logs are not Visible on UI while running the build and not even able to abort the same
+
+Check if the pods are being created when you start a new build, run the command and look if a new pod is created when you started the build:
+```bash
+kubectl get pods -n devtron-ci
+```
+If yes, delete kubewatch and devtron pod so that kubewatch can restart and start sharing the logs again:
+```bash
+kubectl delete pod -n devtroncd -l app=devtron; kubectl delete pod -n devtroncd -l app=kubewatch
+```
+Wait for 5 minutes and then trigger a new build again, if still not resolved then run the following commands one by one
+```bash
+kubectl delete pod -n devtroncd devtron-nats-0
+kubectl delete pod -n devtroncd devtron-stan-0
+kubectl delete pod -n devtroncd -l app=devtron
+kubectl delete pod -n devtroncd -l app=kubewatch
+```
+Again wait for 5 minutes and your issue should be resolved
+
+#### 5. Grafana dashboards not visible in App Details page even after adding prometheus endpoint or Graphs showing error panel with id 2 not found
+
+If the graphs are not visible check if prometheus is configured properly. Then go to Global Configurations → Clusters & Environments → Click on any environment for the cluster where you added prometheus endpoint and simply click `Update`.
+If the charts are still not visible, try visiting the url: ``/grafana?orgId=2
+If you see `Not Found` on this page, then follow all the given steps or if the page is accessible and you are getting `panel with id 2 not found` then follow from step 6:
+1. Get grafana password using `kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.GRAFANA_PASSWORD}' | base64 -d`
+2. `kubectl run --rm -it --image quay.io/devtron/k8s-utils:tutum-curl curl` Run this command and it will create a pod for using `curl`
+3. Copy the following and change `grafana-password` with your password of grafana and change the value of `prometheusUrl` with your prometheus endpoint
+```
+cat << EOF
+grafanaUrl="http://admin:grafana-password@devtron-grafana.devtroncd/grafana"
+prometheusUrl="http://prometheus.example.com"
+
+ORG_ID=$( curl -d '{"name":"devtron-metrics-view"}' -H "Content-Type: application/json" -X POST "${grafanaUrl}/api/orgs" )
+
+echo $ORG_ID
+
+curl -X POST "${grafanaUrl}/api/user/using/2";
+
+curl -X PUT -H "Content-Type: application/json" -d '{"homeDashboardId":0,"theme":"light","timezone":"browser"}' "${grafanaUrl}/api/org/preferences";
+
+curl "${grafanaUrl}/api/datasources" -H 'content-type: application/json' -H 'x-grafana-org-id: 2' --data '{"name":"Prometheus-devtron-demo","type":"prometheus","access":"proxy","isDefault":true}'
+
+curl "${grafanaUrl}/api/datasources/2" -X PUT \
+ -H 'content-type: application/json' \
+ -H 'x-grafana-org-id: 2' \
+ --data '{"id": 2 ,
+ "orgId": 2,
+ "name":"Prometheus-devtron-demo","type":"prometheus","access":"proxy",
+ "url":${prometheusUrl},
+ "basicAuth":false,"jsonData":{},"version":1}'
+EOF
+```
+and run in the pod that we created above in step 2.
+4. Now visit ``/grafana?orgId=2 again and you'll see grafana login page. Login using username `admin` and password from step 1 and check if prometheus url is updated in datasources. If not, update it in the default datasource.
+5. Now from devtron UI, update any of the environment again and it's datasource will be created automatically.
+6. In Grafana UI you need to be logged in and Go to Dashboards → Manage then click `Import` and Import the given dashboards one by one.
+```
+https://grafana.com/api/dashboards/13322/revisions/4/download
+https://grafana.com/api/dashboards/13320/revisions/4/download
+https://grafana.com/api/dashboards/13325/revisions/4/download
+https://grafana.com/api/dashboards/13321/revisions/6/download
+```
+After that, your issue should be resolved and you should be able to see all the graphs on UI.
+
+#### 6. Unable to Login Devtron dashboard even if the password is correct
+
+If you are not able to login into Devtron dashboard even after giving the correct password, it is possible that the argocd token of previous session has been stored in the cookies and is not able to override the new token that is generated for the new session. If you are facing this issue, follow the steps below -
+
+If using Firefox -
+1. Goto login page of Devtron and open inspect.
+2. Navigate to storage tab in inspect.
+3. Click on url where Devtron has been installed under `Cookies` tab and you could see an argocd token with its value, something similar to below image.
+
+
+
+4. Now right click on token, and click on `Delete All Session Cookies` option.
+
+If using Chrome -
+1. Goto login page of Devtron and open inspect.
+2. Navigate to Application tab, and under `Storage` tab click on `Cookies`.
+3. Click on url under `Cookie` and you would be able tto see an argocd token with its value, as shown in the image below.
+
+
+
+4. Now right click on token and click on `delete` option.
+
+If using Safari -
+1. Goto Safari preferences → Advanced options and check the show develop menu as shown in the image below.
+
+
+
+2. Now goto login page of Devtron and press `option+command+I`. It will open inspect element.
+3. Then navigate to `Storage`, click on `Cookies` and you would be able to see an argocd token with its value as shown in the image below.
+
+
+
+4. Now right click on token and select `delete` option.
+
+After clearing `Cookies`, try again to login, you should be able to login now.
+
+
+#### 7. No charts found in Charts Discover Section
+
+In the Devtron's Discover Chart section, if you are not able to see any charts available, go to **Global Configurations** → **Chart Repository** and click on `Refresh Chart` at the top-right as shown in the image below. After clicking the button, it might take 4-5mins to show all the charts in `Discover` section depending upon the chart repositories added.
+
+
+
+
+#### 8. Not able to update cluster
+
+In **Global Configurations** → **Clusters & Environments**, if you try to update a cluster which has been already added in Devtron, you might get an error as `{"message":"Failed to update datasource. Reload new version and try again"}`. If you are facing such issue, please follow the following steps -
+
+1. Edit the changes you want to make in respective cluster
+2. Click on save after making changes and you may get error message stated above.
+3. Go to cluster where devtron has been installed and execute - `kubectl -ndevtroncd delete po -l app=devtron`
+4. Now refresh the page and you should be able to save it.
+
+[Note: If you already have created some environments in that cluster, it needs to be updated again]
+
+#### 9. Postgresql is in crashloop with error - Failed to pull image
+
+There may be some other pods also in crashloop as they are not able to connect to database. To resolve this issue, you can either [update devtron to latest version](../setup/upgrade/README.md) or run the following commands to fix instantly on the same version you are using:
+```bash
+kubectl patch -n devtroncd statefulset postgresql-postgresql -p '{"spec":{"template":{"spec":{"initContainers":[{"name":"init-chmod-data","image":"quay.io/devtron/minideb:latest"}],"containers":[{"name":"postgresql-postgresql","image":"quay.io/devtron/postgres:11.3.0-debian-9-r28"}]}}}}'
+```
+Then delete postgresql pod so that it can fetch the updated images:
+```bash
+kubectl delete pod -n devtroncd postgresql-postgresql-0
+```
+You can also delete other pods which are in crashloop after postgresql is up and running so that they can restart and connect to postgresql and Devtron will be up and running again in a few moments.
+
+#### 10. Unable to fetch the latest commit and not able to trigger auto build.
+
+To solve this, bounce the git-sensor-0 pod.
+```bash
+kubectl delete pod -n devtroncd git-sensor-0
+```
+#### 11. If you have restricted devtron-service to be accessible on certain IPs only and SSO login isn’t working
+
+Whitelist the NAT-gateway IPs of the cluster (There can be multiple NAT-gateways if your cluster is multi-AZ)
+
+#### 12. If CPU metrics are not showing but memory metrics are visible in graphs.
+
+Do the following:-
+
+1. Go to Grafana and Login with the credentials.
+2. Edit the CPU graphs and remove `image!=””` from the query.
+3. Save the dashboard.
+
+CPU metrics should start showing up in a while.
+
+#### 13. If user not able to upload a file more than specific size.
+
+`Please use below annotation in ingress`
+```bash
+nginx.ingress.kubernetes.io/proxy-body-size: 100m
+```
+`Note:- `Where m is MiB.
+
+#### 14. If AWS Load balancer controller is unable to provision ALB and getting message in alb controller as unauthorized, attach these IAM policy to the nodegroup IAM Role.
+
+[IAM policy](https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.3.1/docs/install/iam_policy.json)
+
+#### 15. When app metrics is not coming on grafana and devtron dashboard, set the value of the following parameter as false in kube prometheus stack values.
+
+```
+serviceMonitorSelectorNilUsesHelmValues: false
+```
+#### 16. Unable to deploy metrics-server using chart on devtron
+
+To solve
+
+Disable certificate validation by passing `--kubelet-insecure-tls` argument to metrics server chart.
+
+#### 17. Unable to delete a database from postgres
+`Description of issue`
+
+ERROR: database `` is being accessed by other users
+
+DETAIL: There is 1 other session using the database.
+
+You have to terminate the connections to the database first, for that you can use the command.
+```bash
+SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname='TARGET_DB';
+```
+Then run the command to delete database - `drop databases `
+
+#### 18. Unable to login with admin password or reset devtron admin password
+
+`Debug`
+
+Run the command for admin credentials and use it for login in dashboard:
+
+```bash
+kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+If you are getting an error message of "invalid username or password" or you want to "reset admin password", follow the steps given below:
+
+`Solution:`
+
+1. Make sure you are on latest version or atleast you are using devtron version v0.6.9 or above. You can check your devtron version using `kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-`
+1. Take a backup of devtron secret using `kubectl get secret devtron-secret -n devtroncd -o yaml > devtron-secret-backup.yaml`
+2. Edit devtron secret using `kubectl edit secret devtron-secret -n devtroncd` and remove the key value pairs of ADMIN_PASSWORD, admin.password and admin.passwordMtime
+3. Restart argocd dex server to create new admin password for devtron using `kubectl delete po -n devtroncd -l app.kubernetes.io/name=argocd-dex-server`
+4. Run the command given above to get the new admin password
+
+#### 19. After installing Devtron using Helm, getting the admin password does not work.(if using windows)
+
+`Debug`
+
+'base64' is not recognized as an internal or external command, operable program or batch file.
+
+`Solution`
+
+The first way to debug is either install base64 encode and decode into your windows machine and use the appropriate cmd to get the admin password.
+
+The other way is to get the password in the encoded form using the cmd
+
+`kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ACD_PASSWORD}'`, further decode it into plaintext using an online [encoder decoder](https://www.base64decode.org/).
+
+
+#### 20. Getting `UPGRADE FAILED: cannot patch "postgresql-postgresql"` while upgrading Devtron to newer versions
+`Debug:`
+1. Make sure to [annotate and label](../setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md#3-annotate-and-label-all-the-devtron-resources) all the Devtron resources.
+2. Description of error
+```
+Error: UPGRADE FAILED: cannot patch "postgresql-postgresql" with kind StatefulSet: StatefulSet.apps "postgresql-postgresql" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy' and 'minReadySeconds' are forbidden
+```
+`Solution:`
+Verify if annotations & labels are set to all k8s resources in `devtroncd` namespace and add `--set components.postgres.persistence.volumeSize=20Gi` parameter in Devtron upgrade command.
+```bash
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+-f https://raw.githubusercontent.com/devtron-labs/devtron/main/charts/devtron/devtron-bom.yaml \
+--set installer.modules={cicd} --reuse-values \
+--set components.postgres.persistence.volumeSize=20Gi
+```
+
+#### 21. Configure Blob Storage
+
+
+You can configure blob storage with one of the following:
+
+
+
+
+
+This configuration will use MinIO for storing logs and cache.
+
+```bash
+helm repo update
+
+helm upgrade devtron devtron/devtron-operator \
+--create-namespace --namespace devtroncd \
+--reuse-values \
+--set installer.modules={cicd} \
+--set minio.enabled=true
+```
+
+
+
+
+This configuration will use AWS S3 bucket for storing build logs and cache. Refer to the `AWS specific` parameters on the [Storage for Logs and Cache](../setup/install/installation-configuration.md#aws-specific) page.
+
+* **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.
+
+```bash
+helm repo update
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--set installer.modules={cicd} \
+--reuse-values \
+--set configs.BLOB_STORAGE_PROVIDER=S3 \
+--set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
+--set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1
+```
+
+* **Configure using access-key and secret-key for aws S3 authentication:**
+
+```bash
+helm repo update
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--set installer.modules={cicd} \
+--reuse-values \
+--set configs.BLOB_STORAGE_PROVIDER=S3 \
+--set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
+--set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1 \
+--set secrets.BLOB_STORAGE_S3_ACCESS_KEY= \
+--set secrets.BLOB_STORAGE_S3_SECRET_KEY=
+```
+
+* **Configure using S3 compatible storages:**
+
+```bash
+helm repo update
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--set installer.modules={cicd} \
+--reuse-values \
+--set configs.BLOB_STORAGE_PROVIDER=S3 \
+--set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
+--set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1 \
+--set secrets.BLOB_STORAGE_S3_ACCESS_KEY= \
+--set secrets.BLOB_STORAGE_S3_SECRET_KEY= \
+--set configs.BLOB_STORAGE_S3_ENDPOINT=
+```
+
+
+
+
+This configuration will use Azure Blob Storage for storing build logs and cache.
+Refer to the `Azure specific` parameters on the [Storage for Logs and Cache](../setup/install/installation-configuration.md#azure-specific) page.
+
+```bash
+helm repo update
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--set installer.modules={cicd} \
+--reuse-values \
+--set secrets.AZURE_ACCOUNT_KEY=xxxxxxxxxx \
+--set configs.BLOB_STORAGE_PROVIDER=AZURE \
+--set configs.AZURE_ACCOUNT_NAME=test-account \
+--set configs.AZURE_BLOB_CONTAINER_CI_LOG=ci-log-container \
+--set configs.AZURE_BLOB_CONTAINER_CI_CACHE=ci-cache-container
+```
+
+
+
+
+This configuration will use Google Cloud Storage for storing build logs and cache.
+Refer to the `Google Cloud specific` parameters on the [Storage for Logs and Cache](../setup/install/installation-configuration.md#google-cloud-storage-specific) page.
+
+```bash
+helm repo update
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--set installer.modules={cicd} \
+--reuse-values \
+--set configs.BLOB_STORAGE_PROVIDER: GCP \
+--set secrets.BLOB_STORAGE_GCP_CREDENTIALS_JSON: {\"type\": \"service_account\",\"project_id\": \"\",\"private_key_id\": \"\",\"private_key\": \"\",\"client_email\": \"\",\"client_id\": \"\",\"auth_uri\": \"https://accounts.google.com/o/oauth2/auth\",\"token_uri\": \"https://oauth2.googleapis.com/token\",\"auth_provider_x509_cert_url\": \"https://www.googleapis.com/oauth2/v1/certs\",\"client_x509_cert_url\": \"\"} \
+--set configs.DEFAULT_CACHE_BUCKET: cache-bucket
+--set configs.DEFAULT_BUILD_LOGS_BUCKET: log-bucket
+```
+
+
+
+
+#### 22. Rollout is showing error - ``:111: attempt to index a non-table object(nil) with key 'stableRS' stack traceback: ``:111: in main chunk [G]: ?
+
+This can occur if you are using or recently upgraded to Kubernetes version 1.22 or above and you are using rollout controller version 0.13.0 from chart `devtron-charts/rollout` or `devtron/rollout`. The issue can be because of CRDs which were updated in later versions of rollout chart.
+
+1. Check which chart repo and version of rollout controller are you using on that cluster from Helm Apps section
+2. Update the rollout chart version to latest and re-deploy. If your rollout controller is deployed from `devtron-charts` helm repo then change the repo to `devtron/rollout` and then update the version to latest. Also, if devtron helm repo is not showing on your devtron then go to Global Configurations → Chart Repository and add a new repo with the name `devtron` and url `https://helm.devtron.ai`. Wait for few minutes and then charts from devtron repo will be there on your devtron. This should resolve your issue
+
+
+
+#### 23. How to resolve if Deployment Status shows Failed or Degraded when you pull images from private container registry
+
+If the deployment status shows `Failed` or `Degraded`, then the cluster is not able to pull container image from the private registry. In that case, the status of pod shows `ImagePullBackOff`.
+
+The failure of deployment can be one of the following reasons:
+
+* Provided credentials may not have permission to pull container image from registry.
+* Provided credentials may be invalid.
+
+You can resolve the `ImagePullBackOff` issue by clicking **How to resolve?** on the **App Details** page.
+
+
+
+
+To provide the auto-inject credentials to the specific clusters for pulling the image from the private repository, click **Manage Access** which will take you to the **Container Registries** page.
+
+
+
+1. On the **Container Registries** page, select the docker registry and click **Manage**.
+2. In the **Auto-inject credentials to clusters**, click **Confirm to edit** to select the specific cluster or all clusters for which you want to auto-inject the credentials to and click **Save**.
+3. Redeploy the application after allowing the access.
+
+
+
+
+
+#### 24. Devtron Terminal Connection Timeout Issue on GKE Cluster
+
+**Problem:**
+
+When connecting to the pod or cluster terminal from the Devtron dashboard on an ingress with gce class in a GKE cluster, the connection gets disconnected after every 30 seconds. This issue is caused by the default timeoutSec value of 30 seconds in the `backendConfig`.
+
+**Solution:**
+
+To resolve this issue, you can increase the timeoutSec value in the backendConfig and apply the configuration to the Devtron service. Here are the steps to do this:
+
+1. Create a `BackendConfig` yaml file with the increased `timeoutSec` value. For example:
+
+```yaml
+apiVersion: cloud.google.com/v1beta1
+kind: BackendConfig
+metadata:
+ name: devtron-backendconfig
+spec:
+ timeoutSec: 1800
+```
+you can adjust the `timeoutSec` value in the `backendConfig` as per your specific requirement. This value determines the maximum amount of time the load balancer should wait for a response from the backend before timing out. You can set the timeoutSec value to a higher or lower value based on your use case and the response time of your backend.
+
+ 2. Apply the BackendConfig to the GKE cluster using the following command:
+
+ ```bash
+ kubectl apply -f -n devtroncd
+ ```
+
+3. Add the `cloud.google.com/backend-config: '{"default": "devtron-backendconfig"}'` annotation to the Devtron service with the BackendConfig name. For example:
+
+```yaml
+apiVersion: v1
+kind: Service
+metadata:
+ name: devtron-service
+ namespace: devtroncd
+ annotations:
+ cloud.google.com/backend-config: '{"default": "devtron-backendconfig"}'
+...
+```
+
+4. Save the changes to the Devtron service configuration.
+
+With these configuration changes, the Devtron dashboard connection should no longer timeout after 30 seconds, allowing for a more stable and consistent connection.
+
+
+#### 25. Refreshing ArgoCD Certificates When Expired
+
+1. **Edit ArgoCD Secret**
+
+Use kubectl edit to edit the ArgoCD secret in the appropriate namespace (devtroncd in this case). Find the data section and delete the lines for tls.crt and tls.key:
+
+```bash
+kubectl edit secret argocd-secret -n devtroncd
+```
+
+2. **Delete Lines for `tls.crt` and `tls.key`**
+
+Once you've opened the ArgoCD secret for editing, find the data section and delete the lines for `tls.crt` and `tls.key`. Save your changes and exit the editor.
+
+3. **Delete ArgoCD Server Pod**
+
+Use `kubectl delete pod` to delete the ArgoCD server pod. This will cause a new pod to be created with the updated certificate.
+
+```bash
+kubectl delete pod -n devtroncd
+```
+Replace `` with the name of the ArgoCD server pod.
+
+4. **Delete Devtron Pod**
+
+Wait for two minutes and then delete the Devtron pod using `kubectl delete pod`. This will force the Devtron pod to use the new certificate.
+
+
+```bash
+kubectl delete pod -n devtroncd -l app=devtron
+```
+
+This command deletes the Devtron pod in the `devtroncd` namespace with the label `app=devtron`.
+
+Following these steps should allow you to refresh the ArgoCD certificates when they have expired.
+
+
+#### 26. Not able to see commits, throwing exit status 128
+
+1. **Save the Git Repository Again**
+Wait for few minutes and check the build pipeline if commits are visible or not
+
+2. **Check git sensor pod logs**
+
+```yaml
+kubectl logs -n devtroncd -l app=git-sensor
+```
+If you still get the same issue, try to bounce the pod and save the git repository again
+```yaml
+kubectl delete po -n devtroncd -l app=git-sensor
+```
+
+3. **Try to clone the git repository with the token you have added for Git Account**
+
+In case the cloning fails, you can generate the token, update the Git account in Global Configurations, and try to save the git repository again.
+
+
+#### 27. Git-sensor PVC- disk full
+
+**Need to increase the PVC size if you are getting following error:**
+
+
+
+**Need to check the `Storageclass` by which PVC was provisioned.**
+
+Run the following command:
+```yaml
+kubectl get storageclass
+```
+Check for the field `allowVolumeExpansion`, if it is set to `true`, run the following command and increase the size of the PVC.
+```yaml
+kubectl edit pvc git-volume-git-sensor-0 -n devtroncd
+```
+However, if the field is `allowVolumeExpansion: false`, set it to `true` and run the above command.
+
+Edit the following field:
+```yaml
+spec:
+ capacity:
+ storage: 10Gi # increase as per convenience
+```
+
+**Increase the PVC size as per your requirement. This will resolve the issue. If not, then try to bounce the pod using the following command.**
+
+```yaml
+kubectl delete po -n devtroncd git-sensor-0
+```
+
+#### 28. Getting 'Invalid JSON Document' while deploying via ArgoCD
+
+
+
+As shown above, Rollout object’s sync status is showing `Failed` and throwing an `Invalid JSON Document` error.
+
+This might happen due to manual changes in the Rollout object in the annotation `kubectl.kubernetes.io/last-applied-configuration:` The value of the above annotation is a JSON. ArgoCD tries to validate that JSON and throws an error if it is invalid.
+
+Below is a sample annotation for your reference.
+
+```
+kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","data":{"foo":"bar"},"kind":"ConfigMap","metadata":{"annotations":{},"creationTimestamp":"2019-08-12T18:38:34Z","labels":{"argocd.argoproj.io/instance":"deploy-test-cd-argo"},"name":"test-cm-1154","namespace":"argo"}}
+```
+
+You may take the help of JSON validators to identify where the unintended human error has occured in the JSON. Rectifying the same should resolve this issue.
+
+:::info
+The annotation `kubectl.kubernetes.io/last-applied-configuration:` is automatically added to each object when you run `kubectl apply`.
+:::
+
+#### 29. Helm Charts provided by Bitnami are not visible in Chart Store. Getting 'tls: handshake failure' while deploying Bitnami Charts.
+
+`rpc error: code = Unknown desc = Get "https://repo.broadcom.com/bitnami-files/index.yaml": remote error: tls: handshake failure`
+
+Follow the below steps if you are getting the above error:
+
+* Make sure your [Devtron version](https://devtron-public-asset.s3.us-east-2.amazonaws.com/integrations/about-devtron.png) is 0.7.1 ([check how to upgrade](../setup/upgrade/README.md)).
+
+* Navigate to **Global Configurations** → **Chart Repository** → **Bitnami**
+
+* Now in the Bitnami repository, uncheck the **Allow Insecure Connection** and update it as shown below.
+
+ 
+
+* Go to **Chart Store** and initiate the Chart Sync.
+
+ 
+
+#### 30. The Advanced (YAML) and Basic (GUI) sections are appearing blank in the Base Deployment Template of the application.
+
+
+
+This happens due to a missing [app-values.yaml](../user-guide/global-configurations/deployment-charts.md#3-add-app-valuesyaml) file in your deployment chart.
+
+To fix this issue, include an `app-values.yaml` file in your deployment helm chart before uploading the chart. Refer [adding app-values.yaml](../user-guide/global-configurations/deployment-charts.md#3-add-app-valuesyaml) to know more.
+
+#### 31. Unable to create a GitOps deployment pipeline or encountering errors with GitOps deployment.
+
+If the **GitOps** section is already configured for your [external Argo apps](../user-guide/creating-application/workflow/cd-pipeline.md#migrate-argo-cd-application), and later if you install the GitOps (ArgoCD) module from [Devtron Stack Manager](../user-guide/integrations/argocd.md), make sure to save the [GitOps](../user-guide/global-configurations/gitops.md) configuration once again and also the [Cluster](../user-guide/global-configurations/cluster-and-environments.md) configuration. This might prevent potential errors and ensure your GitOps deployments (for Devtron Apps/Helm Apps) are functional.
+
diff --git a/versioned_docs/version-1.7/README.md b/versioned_docs/version-1.7/README.md
new file mode 100755
index 0000000000..c0889c0c26
--- /dev/null
+++ b/versioned_docs/version-1.7/README.md
@@ -0,0 +1,87 @@
+---
+id: README
+title: Introduction to Devtron
+sidebar_label: Introduction
+slug: /
+---
+
+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.
+
+
+
+
+
+## Devtron's Key Features:
+
+### No Code Software Delivery Workflow for Kubernetes
+
+* 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
+
+### Multi-cloud Deployment
+
+* Deploy to multiple Kubernetes clusters on multiple cloud/on-prem from one Devtron setup
+* Works for all cloud providers and on-premise Kubernetes clusters
+
+### Easy DevSecOps Integration
+
+* 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
+
+### Application Debugging Dashboard
+
+* 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
+
+### Enterprise-Grade Security and Compliances
+
+* 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
+
+### Implements GitOps
+
+* 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
+
+### Operational Insights
+
+* 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
+
+## Compatibility Notes
+
+* Devtron uses a modified version of [Argo Rollout](https://argoproj.github.io/argo-rollouts/).
+* Application metrics only work for K8s version 1.16+
+
+
+## Contributing Guidelines
+
+Check out our [contributing guidelines](https://github.com/devtron-labs/devtron/blob/main/CONTRIBUTING.md). Directions for opening issues, coding standards, and notes on our development processes are all included.
+
+## Community
+
+Get updates on Devtron's development and chat with the project maintainers, contributors, and community members.
+
+* Join the [Discord Community](https://discord.gg/jsRG5qx2gp)
+* Follow [@DevtronL on Twitter](https://twitter.com/DevtronL)
+* Raise feature requests, suggest enhancements, report bugs at [GitHub issues](https://github.com/devtron-labs/devtron/issues)
+* Read the [Devtron blog](https://devtron.ai/blog/)
+
+## Vulnerability Reporting
+
+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**.
diff --git a/versioned_docs/version-1.7/hyperion/FAQs/hyperion-troubleshoot.md b/versioned_docs/version-1.7/hyperion/FAQs/hyperion-troubleshoot.md
new file mode 100755
index 0000000000..8f07529f9a
--- /dev/null
+++ b/versioned_docs/version-1.7/hyperion/FAQs/hyperion-troubleshoot.md
@@ -0,0 +1,52 @@
+---
+id: hyperion-troubleshoot
+title: hyperion-troubleshoot
+sidebar_label: hyperion-troubleshoot
+---
+
+## Troubleshooting Guide
+
+We always try to make your experience of using hyperion as smooth as possible but still if you face any issues, follow the troubleshooting guide given below or join our [discord channel](https://discord.gg/jsRG5qx2gp) if you couldn't find the solution for the issue you are facing.
+
+#### 1. Hyperion Installed but still helm apps are not visible on dashboard
+
+To get helm apps on dashboard, it's important for migration jobs to be completed. To resolve this, check if Jobs are in `1/1 Completed` state by running the command:
+
+```
+kubectl get jobs -n devtroncd
+```
+
+If you see any of the jobs in `0/1 Completed` state then check if it's pod is still running using the following command:
+
+```
+kubectl get pods -n devtroncd
+```
+
+If the pods are in running state, then wait for them to complete and your helm apps should be visible on dashboard after that and if any of job's pod is in `CrashloopBackOff` state, then check the logs of that pod using:
+
+```
+kubectl logs -f -n devtroncd -c
+```
+
+Now, if you get something like `dirty db found` in the logs, then follow the steps given below and if not dirty db, then wait for the pod to automatically restart and complete the job so that helm apps are visible on dashboard.
+
+#### Steps to follow in case you get dirty db found
+
+1. Run this command to get postgresql password - `kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.PG_PASSWORD}' | base64 -d`
+2. Copy the password you get and exec inside postgresql pod using `kubectl exec -it postgresql-postgresql-0 -n devtroncd -- sh`
+3. Now when you are inside postgres, run the command to authenticate postgres user - `psql -U postgres` and enter the password that you got in step 1.
+4. Terminate the connections to databases, delete them and then re-create using the commands given below
+```
+SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = 'orchestrator';
+SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = 'casbin';
+DROP database orchestrator;
+DROP database casbin;
+CREATE database orchestrator;
+CREATE database casbin;
+```
+5. Download the migrator file and re-apply using the following commands:
+```
+kubectl delete -f https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/hyperion/migrator.yaml -n devtroncd
+kubectl apply -f https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/hyperion/migrator.yaml -n devtroncd
+```
+After completing all the steps, you should see the helm apps on dashboard.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/hyperion/README.md b/versioned_docs/version-1.7/hyperion/README.md
new file mode 100755
index 0000000000..b3d401b9d5
--- /dev/null
+++ b/versioned_docs/version-1.7/hyperion/README.md
@@ -0,0 +1,50 @@
+---
+id: README
+title: Overview
+sidebar_label: Overview
+---
+
+# Overview
+
+## Hyperion 🦹
+
+### Why Hyperion?
+Hyperion is a lightweight Dashboard for Kubernetes deployments. Packed with full-fledged debugging features enabled with resource grouping for easier debugging for Development and Infra team.
+You can also upgrade to Devtron from Hyperion to enjoy full stack features of Devtron.
+
+> Do check the [Hyperion Installation Guide ⎈](../hyperion/setup/install.md)
+
+### Hyperion Features
+
+#### Application-level resource grouping for easier Debugging
+- Hyperion groups your deployed microservices and displays them in a slick UI for easier monitoring or debugging. Access pod logs and resource manifests right from the Hyperion UI and even edit them!
+
+#### Centralized Access Management
+- Give access to users on Project, Environment and App level and control the level of access with customizable View only and Edit access.
+
+#### Manage and observe Multiple Clusters
+- Manage access of all the Kubernetes clusters (hosted on multiple cloud/on-prem) right from one Hyperion setup.
+
+#### View and Edit Kubernetes Manifests
+- View and Edit all Kubernetes resources right from the Hyperion dashboard.
+
+
+---
+
+## Contribute
+
+Check out our [contributing guidelines](https://github.com/devtron-labs/devtron/blob/main/CONTRIBUTING.md). Included are directions for opening issues, coding standards, and notes on our development processes.
+
+
+## Community
+
+Get updates on Devtron's development and chat with the project maintainers, contributors and community members.
+
+* Join the [Discord Community](https://discord.gg/jsRG5qx2gp)
+* Follow [@DevtronL on Twitter](https://twitter.com/DevtronL)
+* Raise feature requests, suggest enhancements, report bugs at [GitHub issues](https://github.com/devtron-labs/devtron/issues)
+* Read the [Devtron blog](https://devtron.ai/blog/)
+
+## Vulnerability Reporting
+
+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 by contacting us at security@devtron.ai.
diff --git a/versioned_docs/version-1.7/hyperion/devtron.md b/versioned_docs/version-1.7/hyperion/devtron.md
new file mode 100755
index 0000000000..a2ffa34696
--- /dev/null
+++ b/versioned_docs/version-1.7/hyperion/devtron.md
@@ -0,0 +1,9 @@
+---
+id: devtron
+title: devtron
+sidebar_label: devtron
+---
+
+Don't worry, your beloved Hyperion is still supported. It has been merged with Devtron and if you want to install Devtron with same functionality as hyperion [visit here](../setup/install/README.md).
+
+Please reach out to us on [discord](https://discord.devtron.ai/) in case of any queries.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/hyperion/setup/install.md b/versioned_docs/version-1.7/hyperion/setup/install.md
new file mode 100755
index 0000000000..c3011ac702
--- /dev/null
+++ b/versioned_docs/version-1.7/hyperion/setup/install.md
@@ -0,0 +1,85 @@
+---
+id: install
+title: Install Hyperion using Helm3 (Deprecated)
+sidebar_label: Install Hyperion using Helm3 (Deprecated)
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Install Hyperion using Helm3 (Deprecated)
+
+> **Note**: Hyperion is now Devtron
+
+Before you begin, install [Helm3](https://helm.sh/docs/intro/install/)
+
+
+
+```bash
+helm repo add devtron https://helm.devtron.ai
+helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd --set installer.mode=hyperion
+```
+
+
+
+For those countries/users where Github is blocked, you can download the [Hyperion Helm chart](https://s3-ap-southeast-1.amazonaws.com/devtron.ai/devtron-operator-latest.tgz)
+
+
+```bash
+wget https://s3-ap-southeast-1.amazonaws.com/devtron.ai/devtron-operator-latest.tgz
+helm install devtron devtron-operator-latest.tgz --create-namespace --namespace devtroncd --set installer.mode=hyperion
+```
+
+[//]: # (If you are planning to use Hyperion for `production deployments`, please refer to our recommended overrides for [Devtron Installation](override-default-devtron-installation-configs.md).)
+
+[//]: # (## Installation status)
+
+[//]: # ()
+[//]: # (Run following command)
+
+[//]: # ()
+[//]: # (```bash)
+
+[//]: # (kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.status}')
+
+[//]: # (```)
+
+## Access Hyperion dashboard
+
+If you did not provide a **BASE\_URL** during install or have used the default installation, Devtron creates a loadbalancer for you on its own. Use the following command to get the dashboard url.
+
+```text
+kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
+```
+
+You will get result something like below
+
+```text
+[test2@server ~]$ kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
+[map[hostname:aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com]]
+```
+
+The hostname mentioned here \( aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com \) is the Loadbalancer URL where you can access the Devtron dashboard.
+
+**PS:** 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.
+
+| Host | Type | Points to |
+| ---: | :--- | :--- |
+| devtron.yourdomain.com | CNAME | aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com |
+
+### Hyperion Admin credentials
+
+For admin login use username:`admin` and for password run the following command.
+
+```bash
+kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ACD_PASSWORD}' | base64 -d
+```
+
+### Cleaning Hyperion Helm3
+
+Please make sure that you do not have anything inside namespaces devtroncd, devtron-cd devtron-ci and devtron-demo as the below steps will clean everything inside these namespaces
+```
+helm uninstall devtron --namespace devtroncd
+kubectl delete -n devtroncd -f https://raw.githubusercontent.com/devtron-labs/charts/main/charts/devtron/crds/crd-devtron.yaml
+kubectl delete ns devtroncd
+```
diff --git a/versioned_docs/version-1.7/hyperion/setup/upgrade-to-devtron.md b/versioned_docs/version-1.7/hyperion/setup/upgrade-to-devtron.md
new file mode 100755
index 0000000000..2b7df231d3
--- /dev/null
+++ b/versioned_docs/version-1.7/hyperion/setup/upgrade-to-devtron.md
@@ -0,0 +1,104 @@
+---
+id: upgrade-to-devtron
+title: Upgrade Hyperion to Devtron Full mode
+sidebar_label: Upgrade Hyperion to Devtron Full mode
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Upgrade Hyperion to Devtron Full mode
+
+To install Helm3, please check [Installing Helm3](https://helm.sh/docs/intro/install/)
+
+
+
+This installation will use Minio for storing build logs and cache.
+
+```bash
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd --set installer.mode=full
+```
+
+
+
+This installation will use AWS s3 buckets for storing build logs and cache
+
+```bash
+helm upgrade devtron devtron/devtron-operator --create-namespace --namespace devtroncd \
+--set installer.mode=full \
+--set configs.BLOB_STORAGE_PROVIDER=S3 \
+--set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
+--set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1
+```
+
+
+
+This installation will use Azure Blob Storage for storing build logs and cache
+
+```bash
+helm upgrade devtron devtron/devtron-operator --create-namespace --namespace devtroncd \
+--set installer.mode=full \
+--set secrets.AZURE_ACCOUNT_KEY=xxxxxxxxxx \
+--set configs.BLOB_STORAGE_PROVIDER=AZURE \
+--set configs.AZURE_ACCOUNT_NAME=test-account \
+--set configs.AZURE_BLOB_CONTAINER_CI_LOG=ci-log-container \
+--set configs.AZURE_BLOB_CONTAINER_CI_CACHE=ci-cache-container
+```
+
+
+
+
+If you are planning to use Devtron for `production deployments`, please refer to our recommended overrides for [Devtron Installation](../../setup/install/override-default-devtron-installation-configs.md).
+
+## Installation status
+
+Run following command
+
+```bash
+kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.status}'
+```
+
+The install commands initiates Devtron-operator which spins up all the Devtron micro-services one by one in about 20 mins. You can use the above command to check the status of the installation if the installation is still in progress, it will print `Downloaded`. When the installation is complete, it prints `Applied`.
+
+## Access Devtron dashboard
+
+If you did not provide a **BASE\_URL** during install or have used the default installation, Devtron creates a loadbalancer for you on its own. Use the following command to get the dashboard url.
+
+```text
+kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
+```
+
+You will get result something like below
+
+```text
+[test2@server ~]$ kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
+[map[hostname:aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com]]
+```
+
+The hostname mentioned here \( aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com \) is the Loadbalancer URL where you can access the Devtron dashboard.
+
+**PS:** 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.
+
+| Host | Type | Points to |
+| ---: | :--- | :--- |
+| devtron.yourdomain.com | CNAME | aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com |
+
+### Devtron Admin credentials
+If you are upgrading from Hyperion to Devtron full mode, the admin password does NOT change.
+For admin login use username:`admin` and for password run the following command.
+
+```bash
+kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.ACD_PASSWORD}' | base64 -d
+```
+
+### Cleaning Devtron Installer Helm3
+
+Please make sure that you do not have anything inside namespaces devtroncd, devtron-cd devtron-ci and devtron-demo as the below steps will clean everything inside these namespaces
+```
+helm uninstall devtron --namespace devtroncd
+kubectl delete -n devtroncd -f https://raw.githubusercontent.com/devtron-labs/charts/main/charts/devtron/crds/crd-devtron.yaml
+kubectl delete -n argo -f https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/yamls/workflow.yaml
+kubectl delete ns devtroncd devtron-cd devtron-ci devtron-demo
+```
diff --git a/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/README.md b/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/README.md
new file mode 100755
index 0000000000..31399dcf2e
--- /dev/null
+++ b/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/README.md
@@ -0,0 +1,19 @@
+---
+id: README
+title: Global Configurations
+sidebar_label: Global Configurations
+---
+
+# Global Configurations
+
+This documentation consists of the Global Configurations available in Devtron.
+
+**Parts of the Documentation**
+
+[Cluster And Environments](cluster-and-environments.md)
+
+[SSO Login Service](sso-login.md)
+
+[User Access](user-access.md)
+
+
diff --git a/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/cluster-and-environments.md b/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/cluster-and-environments.md
new file mode 100755
index 0000000000..55dd58d631
--- /dev/null
+++ b/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/cluster-and-environments.md
@@ -0,0 +1,119 @@
+---
+id: cluster-and-environments
+title: Cluster And Environments
+sidebar_label: Cluster And Environments
+---
+
+# Cluster And Environments
+
+The Global configuration provides a feature of `Cluster & Environments` in which you can add your Kubernetes clusters and environment.
+
+Select the Cluster & Environment section of global configuration and click on `Add Cluster` to add your cluster.
+
+## Add Cluster:
+
+To add a cluster on devtron, you must have superadmin access.
+
+Navigate to the **Global Configurations** → **Cluster and Environments** on devtron and click on `Add Cluster`. Provide the below information to add your kubernetes cluster:
+
+1. Name
+2. Kubernetes Cluster Info
+ * Server URL
+ * Bearer token
+3. Prometheus Info
+ * Prometheus endpoint
+ * Basic
+ * Username
+ * Password
+ * Anonymous
+ * TLS Key
+ * TLS Certificate
+
+
+
+
+### 1. Name
+
+Give a name to your cluster inside the name box.
+
+### 2. Kubernetes Cluster Info
+
+Provide your kubernetes cluster’s credentials.
+
+* **Server URL**
+
+Provide the endpoint/URL of your kubernetes cluster.It is recommended to use a self-hosted URL instead of cloud hosted. Self-hosted URL will provide the following benefits.
+
+**\(a\) Disaster Recovery -** It is not possible to edit the server-url of a cluster. So if you're using an eks url, For eg- ` *****.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. While using a self-hosted url For eg- `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.
+
+**\(b\) Easy cluster migrations -** Cluster url is given in the name of the cloud provider used, so migrating your cluster from one provider to another will result in waste of time and effort. On the other hand, if using a self-hosted url migrations will be easy as the url is of single hosted domain independent of the cloud provider.
+
+* **Bearer token**
+
+Provide your kubernetes cluster’s Bearer token for authentication purposes so that the Devtron tool will be able to talk to your kubernetes cluster and can deploy your application in your kubernetes cluster.Generate the admin token to add the cluster on devtron by running the following command. Please ensure that you have kubectl and jq installed on the bastion that you’re running the command.
+
+```bash
+curl -O https://raw.githubusercontent.com/devtron-labs/utilities/main/kubeconfig-exporter/kubernetes_export_sa.sh && bash kubernetes_export_sa.sh cd-user devtroncd https://raw.githubusercontent.com/devtron-labs/utilities/main/kubeconfig-exporter/clusterrole.yaml
+```
+
+### 3. Prometheus Info
+
+Prometheus is a powerful solution to provide graphical insight into your application behavior. If you want to see your application matrix against your applications deployed in kubernetes, install Prometheus in your kubernetes cluster. The below inputs are required to configure your prometheus into Devtron’s tool.
+
+* **Prometheus endpoint**
+
+Provide the URL of your prometheus. Prometheus supports two types of authentication `Basic` and `Anonymous`. Select the authentication type for your Prometheus setup.
+
+* **Basic**
+
+If you select the `basic` type of authentication then you have to provide the `Username` and `Password` of prometheus for authentication.
+
+* **Anonymous**
+
+If you select `Anonymous` then you do not have to provide any username and password for authentication.
+
+* **TLS Key & TLS Certificate**
+
+TLS key and TLS certificate both options are optional, these options are used when you use a custom URL, in that case, you can pass your TLS key and TLS certificate.
+
+
+### K8s Version
+on saving or update a cluster there is a call to fetch k8s version, it will store corresponding to cluster on db. used in listing api's and app detail page for grafana url.
+
+
+Check the below screenshots to know how it looks like If you select the `Basic` authentication type
+
+
+
+If you select the `Anonymous` authentication type
+
+
+
+Now click on `Save Cluster` to save your cluster information.
+
+### Note:
+
+Your kubernetes cluster gets mapped with the Devtron when you save your kubernetes cluster Configuration. Now the agents of devtron will be installed on your cluster so that the components of devtron can communicate to your cluster. When the agent starts installing on your cluster, you can check the status of the agents in the Cluster & Environment tab also.
+
+
+
+Click on `Details` to check what got installed inside the agents. A new window will be popped up displaying all the details about these agents.
+
+
+
+## Add Environment
+
+Once you have added your cluster in Cluster & Environment, you can add the environment also. Click on `Add Environment`, a window will be opened. Give a name to your environment in the `Environment Name` box and provide a namespace corresponding to your environment in the `Namespace` input box. Now choose if your environment is for Production purposes or for Non-production purposes. Production and Non-production options are only for tagging purposes. Click on `Save` and your environment will be created.
+
+
+
+You can update an already created environment, Select and click on the environment which you want to update. You can only change Production and Non-production options here.
+
+**Note**
+
+You can not change the Environment name and Namespace name.
+
+
+
+Click on `Update` to update your environment.
+
diff --git a/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/sso-login.md b/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/sso-login.md
new file mode 100755
index 0000000000..6659b84c6e
--- /dev/null
+++ b/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/sso-login.md
@@ -0,0 +1,58 @@
+---
+id: sso-login
+title: SSO LOGIN
+sidebar_label: SSO LOGIN
+---
+
+# SSO LOGIN
+## Overview
+
+Once installed Devtron has one built-in `admin` user with super-admin privileges that has complete access to the system. It is recommended to use `admin` user only for initial and global configuration and then switch to local users or configure SSO integration.
+
+Only users with super-admin privileges have access to create SSO configuration. Devtron uses dex for authenticating a user against the identity provider.
+
+To add/edit SSO configuration please go to the left main panel -> Select `Global Configurations` -> Select `SSO Login Services`
+
+## Supported SSO Providers
+
+`LDAP`
+`GitHub`
+`OpenID Connect`
+`Google`
+`Microsoft`
+`OpenShift`
+
+Dex implements connectors that target specific `identity providers`, for each connector configuration user must have created account for the corresponding identity provider and registered an app for client key and secret.
+For examples see
+* https://dexidp.io/docs/connectors/
+* https://dexidp.io/docs/connectors/google/
+
+
+### 1. Create new SSO Configuration
+
+Login as a user with super-admin privileges and go to `Global Configurations` -> `SSO Login Services` and click on any `Identity Provider` and fill the configuration.
+
+Add valid devtron application `URL` where it is hosted.
+
+Fill correct `redirect URL` or `callback URL` from which you have registered with the identity provider in the previous step along with the `client id` and `client secret` shared by the identity provider.
+
+Only single SSO login configuration can be active at one time. Whenever you create or update any SSO config, it will be activated and used by the system and previous configurations will be deleted.
+
+Except for the domain substring, URL and redirectURI should be the same as in the screenshots.
+
+
+
+Select `Save` to create and activate SSO login.
+
+### 2. Update SSO Configuration
+
+SSO configuration can be changed by the user at any later point in time by updating the configuration and clicking on the `Save` button at the bottom right.
+In case of configuration change all users will be logged out of the system and will have to login again.
+
+### 3. Configuration Payload
+
+* `type` : oidc or any platform name such as (google, gitlab, github etc)
+* `name` : identity provider platform name
+* `id` : identity provider platform unique id in string. (refer to dexidp.io)
+* `config` : user can put connector details into this key. platforms may not have same structure but commons are clientID, clientSecret, redirectURI.
+* `hostedDomains` : domains authorized for SSO login.
diff --git a/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/user-access.md b/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/user-access.md
new file mode 100755
index 0000000000..d73b9a0769
--- /dev/null
+++ b/versioned_docs/version-1.7/hyperion/user-guide/global-configurations/user-access.md
@@ -0,0 +1,201 @@
+---
+id: user-access
+title: User Access for Hyperion Mode
+sidebar_label: User Access for Hyperion Mode
+---
+
+# User Access for Hyperion Mode
+
+Like any enterprise product, Devtron supports fine grained access control to the resources
+
+Access can be added to the User either directly or via Groups.
+
+## Access Levels
+Devtron supports 4 levels of access
+1. **View only**: User with `view` only access has the least privilege. This user can only view combination of environments, applications and helm charts on which access has been granted to the user. This user cannot view sensitive data like secrets used in applications or charts.
+2. **View and Edit**: In addition to `view` privilege mentioned in above, user with `View and Edit` permission can edit the resource manifests of permitted applications and helm charts to permitted environments.
+3. **Admin**: User with `admin` access can create, edit, delete and view permitted applications in permitted projects.
+4. **Super Admin**: User with `super admin` privilege has unrestricted access to all Devtron resources. Super admin can create, modify, delete and view any Devtron resource without any restriction; its like Superman without the weakness of Kryptonite. Super Admin can also add and delete user access across any Devtron resource, add delete git repository credentials, docker registry credentials, cluster and environment.
+
+## Visualize using access table (Apps)
+
+| Access Level | View App | Create App | Edit App | Delete App | Trigger App |
+|--|--|--|--|--|--|
+| View | Yes | No | No | No| No |
+| View and Edit | Yes | No | Yes | Yes| Yes |
+|Admin| Yes | Yes | Yes | Yes | Yes |
+|Super Admin| Yes | Yes | Yes | Yes | Yes |
+
+
+## Visualize using access table (Charts)
+| Access Level | View Charts | Install Charts | Edit Charts | Delete Charts |
+|--|--|--|--|--|
+| View | Yes | No | No | No|
+| View and Edit | Yes | No | No | No|
+|Admin| Yes | Yes | Yes | Yes |
+|Super Admin| Yes | Yes | Yes | Yes |
+
+
+## Visualize using access table (User Management)
+| Access Level | Add User Access | Edit User Access | Delete User Access |
+|--|--|--|--|
+|Super Admin| Yes | Yes | Yes |
+
+
+## Visualize using access table (Config Management)
+| Access Level | Add Global Config | Edit Global Config | Delete Global Config |
+|--|--|--|--|
+|Super Admin| Yes | Yes |
+
+
+To control the access of User and Group
+
+Go to the left main panel -> `Select Global Configurations` -> Select `User Access`
+
+## Users
+### 1. Add new user
+
+Click on `Add User`, to add one or multiple users.
+
+
+
+### 2. Search the existing User
+Click on `Search Box`, and type your user's email
+
+
+
+### 3. Create User Permissions
+
+When you click on Add User, you will see 4 options to set permission for users which are as follow:
+
+* Email addresses
+* Assign super admin permissions
+* Group permissions
+* Helm Apps
+ * Project
+ * Environment
+ * Application
+ * Permission
+
+## Email addresses:
+
+In the `Email address` box, you have to provide the mail ID of the user to whom you want to give access to your applications.
+
+**`IMP`** Please note that Email address should be same as that in the `email` field in the JWT token returned by OIDC provider.
+
+
+### Assign super admin permissions
+
+If you check the option `Assign super admin permissions`, the user will get full access to your system and the rest of the options will disappear. Please check [above](#access-levels) to see permission levels.
+
+
+
+Click on `Save` and your user will be saved with super admin permissions.
+
+We suggest that super admin privileges should be given to only select few.
+
+If you don’t want to assign super admin permissions then you have to provide the rest of the information.
+
+
+### Group permissions
+
+This is used to assign user to a particular group and user inherits all the permissions granted to this group. The Group permissions section contains a drop-down of all existing groups on which you have access. This is optional field and more than one groups can be selected for a user.
+
+
+
+We will discuss how to create groups in the later section.
+
+### Helm Apps
+
+Access can be given to user by attaching permission directly to his/her email id through the `Helm Apps` section. This section has 4 options to manage the permissions of your users.
+
+* **Project**
+
+Select a project from the drop-down to which you want to give permission to the users. You can select only one project at a time if you want to select more than one project then click `Add row`.
+
+* **Environment or cluster/namespace**
+
+In the `Environment or cluster/namespace` section, you can select one or more than one or all environments at a time. Click on the environment section, you will see a drop-down of your environments and select any environment on which you want to give permission to the user.
+
+**`IMP`** If `all environments` option is selected then user gets access to all current environments and any new environment which gets associated with this application later.
+
+* **Application**
+
+Similarly, you can select `Applications` from the drop-down corresponding to your selected Environments. In this section, you can also give permissions to one or more than one or to all applications at a time.
+
+**`IMP`** If `all applications` option is selected then user gets access to all current applications and any new application which gets associated with this project later.
+
+* **Permission**
+
+ Inside the `Permission`, you actually choose which type of permissions you want to give to the users.
+
+There are there different view access levels available for both User and Group as described [above](#access-levels):
+
+
+
+You can add multiple rows, for Helm Apps.
+
+Once you have finished assigning the appropriate permissions for the listed user, Click on `Save`.
+
+### 4. Edit User Permissions
+
+You can edit the user permissions, by clicking on the `downward arrow`.
+
+
+
+Then you can edit the user permissions here.
+
+
+
+After you have done editing the user permissions. Click on `Save`.
+
+If you want to delete the user/users with particular permissions. Click on `Delete`.
+
+## Groups
+
+The advantage of the 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. Users can be added to an existing group to utilize the privileges that it grants. Any access change to group is reflected immediately in user access.
+
+You can select the group which you are creating in the `Group permissions` section inside `Add users`.
+
+### 1. Add new Group
+
+Click on `Add Group`, to create a new group.
+
+
+
+Enter the `Group Name` and `Description`.
+
+
+
+### 2. Create Group Permissions
+
+Once you have given the group name and group description.
+
+Then, control the access permissions of groups in the Helm Apps section. Manage the Project, Environment, Application, and Permission access the same as we discuss in the above users section.
+
+
+
+You can add multiple rows, for the Helm Apps section.
+
+Once you have finished assigning the appropriate permissions for the listed users, Click on `Save`.
+
+### 3. Edit Group Permissions
+
+You can edit the group permissions, by clicking on the `downward arrow.`
+
+
+
+Then you can edit the group permissions here.
+
+
+
+Once you are done editing the group permissions. Click on `Save`.
+
+If you want to delete the groups with particular permissions. Click on `Delete`.
+
+
+### 4. Manage Chart Group Permissions
+
+The chart group permissions for the group will be managed in the same way as for the users. For reference, check Manage chart group permissions for users.
+
+
diff --git a/versioned_docs/version-1.7/reference/README.md b/versioned_docs/version-1.7/reference/README.md
new file mode 100755
index 0000000000..0c2156c250
--- /dev/null
+++ b/versioned_docs/version-1.7/reference/README.md
@@ -0,0 +1,23 @@
+---
+id: README
+title: Additional Installation Resources
+sidebar_label: Additional Installation Resources
+hide_table_of_contents: true
+---
+
+# Additional Installation Resources
+
+Every environment is different, and you may want to tune, extend, or troubleshoot your installation.
+
+This section brings together all the extra resources you might need beyond the basic install:
+
+* **[Production Infra Recommendations](../setup/install/prod-infra.md)** - Plan a stable, scalable Devtron setup in production.
+* **[Advanced Configurations](../setup/configurations/configurations-overview.md)** - Learn how to adjust Devtron’s install and runtime behavior.
+ * **[Installation Configurations](../setup/install/installation-configuration.md)** - Fine-tune installation values for blob storage, node selectors and tolerations, StorageClass, etc.
+ * **[Override Configurations](../setup/install/override-default-devtron-installation-configs.md)** - Customize default settings.
+ * **[Ingress Setup](../setup/install/ingress-setup.md)** - Configure ingress for external access.
+* **[Install Devtron on Air-gapped Environment](../setup/install/install-devtron-in-airgapped-environment.md)** - Steps to install Devtron in restricted/offline environments.
+* **[Devtron Kubernetes Desktop Client](../setup/install/install-devtron-Kubernetes-client.md)** - Try Devtron locally without touching your cluster.
+* **[Installation Walkthrough on EKS, AKS, GKE](../setup/install/demo-tutorials.md)** - Hands-on installation demos on EKS, AKS, and GKE.
+* **[Backup for Disaster Recovery](../setup/install/devtron-backup.md)** - Protect your data and recover quickly.
+* **[FAQs](../setup/install/faq-on-installation.md)** - Answers to common installation questions.
diff --git a/versioned_docs/version-1.7/reference/glossary.md b/versioned_docs/version-1.7/reference/glossary.md
new file mode 100755
index 0000000000..8b43fccd0d
--- /dev/null
+++ b/versioned_docs/version-1.7/reference/glossary.md
@@ -0,0 +1,303 @@
+---
+id: glossary
+title: Glossary
+sidebar_label: Glossary
+---
+
+# Glossary
+
+### Artifacts
+
+An immutable blob of data generated as an output after the execution of a job, build, or deployment process, e.g., container image, helm chart. In Devtron, you can view the artifacts in the `Build History` and `Deployment History` of your application. Whereas, job artifacts are visible in the `Run history` of your job.
+
+* Once a build is complete, you can view the build artifacts by going to Applications (choose your app) → Build History (tab) → (choose a pipeline and date of triggering the build) → Artifacts (tab).
+
+* Once a deployment is complete, you can view the deployment artifacts by going to Applications (choose your app) → Deployment History (tab) → (choose an environment and date of deployment) → Artifacts (tab).
+
+* Once a job is complete, you can view the job artifacts by going to Jobs → Run history (tab) → (choose a pipeline and date of triggering the build) → Artifacts (tab).
+
+### ArgoCD Apps
+
+ArgoCD Apps are the micro-services deployed using a [GitOps](#gitops) deployment tool named [Argo CD](https://argo-cd.readthedocs.io/en/stable/).
+
+If ArgoCD applications are present in your cluster, they will appear in the [ArgoCD Apps listing](../user-guide/applications.md#enabling-argocd-app-listing).
+
+### Deployment Template
+
+A deployment template is a manifest of the application defining its runtime behavior. You can select one of the default deployment charts or custom deployment charts created by super-admin.
+
+It’s a single entry point for you to enter the values, so that when the application is deployed your filled values go to the respective template files (YAML), and accordingly the resources would be created.
+
+In Devtron, you get the option to select a deployment template in the `Configurations` tab at the time of creating an application. [Read More...](../user-guide/creating-application/base-config/deployment-template.md)
+
+### Build Context
+
+For building a docker image we require a [Dockerfile](#dockerfile) and a build context. The Dockerfile contains the instructions to build. Context is the path where the build process may refer for getting the files required for build.
+
+To build files from the root, use (.) as the build context. Or to refer a subdirectory, enter the path in the format `/myfolder` or `/myfolder/mysubfolder`. If the path is not set, the default path will be the root directory of selected git repository.
+
+Go to Applications (choose your app) → Configurations (tab) → Build Configuration → (choose 'I have a Dockerfile') → Set Build Context.
+
+### Build Pipeline
+
+A series of automated steps that transform source code into a deployable container image. In Devtron, you can create a build pipeline by going to Applications (choose your app) → Configurations (tab) → Workflow Editor → New Workflow. [Read More...](../user-guide/creating-application/workflow/ci-pipeline.md)
+
+### Chart Store
+
+A place where all Helm charts are centrally listed for users to deploy applications on Kubernetes. In Devtron, the chart store is available in the left sidebar. You can view, configure, and deploy the existing charts or add new chart repositories too. [Read More...](../user-guide/global-configurations/chart-repo.md)
+
+### Cluster
+
+A cluster in Kubernetes refers to a set of connected computers (nodes) that collectively manage containerized applications using Kubernetes. It provides resources and services to run, manage, and scale applications.
+
+In Devtron, you can view the list of clusters in 'Global Configurations' as well as 'Resource Browser'. [Read More...](../user-guide/resource-browser/README.md)
+
+### Commit Hash
+
+A unique identifier representing a specific version of source code in a Git [repository](#repo). In Devtron, you can view the commit hash of the top 15 commits you pushed to your branch while selecting the git material under the `Build & Deploy` tab of your application.
+
+### ConfigMaps
+
+Kubernetes objects used to store configuration data as key-value pairs. They allow separation of configuration from application code, making it easier to manage and update settings.
+
+You can use different ConfigMaps for respective environments too. [Read More...](../user-guide/creating-application/base-config/config-maps.md)
+
+### Container/OCI Registry
+
+It is a collection of repositories that store container images. It allows developers to store, share, and manage images used to deploy containers. In Devtron, you can add a container registry by going to Global Configurations → Container / OCI Registry. Your CI images are pushed to the container registry you configure. [Read More...](../user-guide/global-configurations/container-registries.md).
+
+An OCI-compliant registry can also store artifacts (such as helm charts). Here, OCI stands for Open Container Initiative. It is an open industry standard for container formats and registries.
+
+### Cordoning
+
+Temporarily marking a node as unschedulable, preventing new pods from being assigned to it. In Devtron, you can cordon a node by going to Resource Browser → (choose a cluster) → Nodes → (click on a node) → Cordon (available in blue). [Read More...](../user-guide/resource-browser/nodes.md#cordon-a-node)
+
+### CRD
+
+A Custom Resource Definition (CRD) allows you to add custom resource types to Kubernetes, extending its capabilities to support configurations specific to your application. In Devtron, CRDs enable you to manage these custom resources alongside standard Kubernetes resources, making it easier to handle specialized application requirements within the platform.
+
+### CronJob
+
+CronJob is used to create Jobs on a repeating schedule. It is commonly used for running periodic tasks with no manual intervention. In Devtron, you can view a list of cronjobs by going to Resource Browser → (choose a cluster) → Workloads → CronJob. [Read More...](../user-guide/creating-application/base-config/deployment-template-types/job-and-cronjob.md#2-cronjob)
+
+### Deployment Charts
+
+Devtron offers a variety of ready-made Helm charts for common tasks and functions. If you have a specific need that isn't met by these preconfigured charts, super-admins have the permission to upload their own charts. Once uploaded, these charts become accessible for use by all users on the Devtron platform. [Read More...](../user-guide/global-configurations/deployment-charts.md)
+
+### DaemonSet
+
+A Kubernetes object that ensures a specific pod runs on all or certain nodes within a cluster, often used for tasks such as logging or monitoring.
+
+In Devtron, you can view a list of DaemonSets by going to Resource Browser → (choose a cluster) → Workloads → DaemonSet.
+
+### Deployment Strategy
+
+A defined approach for deploying updates or changes to applications. Devtron supports rolling updates, blue-green deployments, canary releases, and recreate strategy.
+
+In Devtron, you can choose a deployment strategy by going to Applications (choose your app) → Configurations (tab) → Workflow Editor → (edit deployment pipeline) → Deployment Strategy. [Read More...](../user-guide/creating-application/workflow/cd-pipeline.md#deployment-strategies)
+
+### Devtron Apps
+
+Devtron Apps are the micro-services deployed using Kubernetes-native CI/CD with Devtron. To create one, go to Applications → Create (button) → Custom App.
+
+### Dockerfile
+
+A script that defines how to build a Docker [container image](#image). It includes instructions to assemble the image's base, dependencies, and application code. It's recommended that you include a Dockerfile with your source code.
+
+However, in case you don't have a Dockerfile, Devtron helps you create one. Go to Applications (choose your app) → Configurations (tab) → Build Configuration. [Read More...](../user-guide/creating-application/docker-build-configuration.md#build-docker-image-by-creating-dockerfile)
+
+### Draining
+
+Evacuating pods from a node before cordoning it, ensuring that running pods are gracefully rescheduled on other nodes.
+
+In Devtron, you can drain a node by going to Resource Browser → (choose a cluster) → Nodes → (click on a node) → Drain (available in blue). [Read More...](../user-guide/resource-browser/nodes.md#drain-a-node)
+
+### Endpoints
+
+Endpoints are nothing but the address of your pods. When something inside or outside the cluster (e.g., your browser) wants to connect with your service (e.g., your application), endpoints are the way for Kubernetes to make this happen. To know more, refer to [Endpoints](https://kubernetes.io/docs/reference/kubernetes-api/service-resources/endpoints-v1/).
+
+### EndpointSlice
+
+When a cluster contains more than a hundred pods, for example, EndpointSlice splits the endpoints of the pods into small, managable sizes and helps in keeping track of the endpoints of the pods within a Kubernetes cluster. To know more, refer to [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/).
+
+### Environment
+
+You can deploy your application to one or more environments (e.g., development, testing, production). In Devtron, Environment = [Cluster](#cluster) + [Namespace](#namespace). For a given application, you cannot have multiple CD pipelines for an environment. For e.g., if an application named 'test-app' is deployed on an environment named 'test-environment', you cannot create another deployment (CD) pipeline for the same app and environment.
+
+Your application can have different deployment configurations for respective environments. For e.g., the number of [ReplicaSet](#replicaset) could be 2 for staging environment, whereas it could be 5 for production.
+
+Similarly, the CPU and memory resources can be different for each environment. This is possible through Environment Overrides. [Read More...](../user-guide/creating-application/environment-overrides.md)
+
+### External Links
+
+You can add external links related to the application. For e.g., you can add Prometheus, Grafana, and many more to your application by going to Global Configurations → External Links. [Read More...](../user-guide/global-configurations/external-links.md)
+
+### FluxCD Apps
+
+FluxCD Apps are the micro-services deployed using a [GitOps](#gitops) deployment tool named [Flux CD](https://fluxcd.io/).
+
+If FluxCD applications are present in your cluster, they will appear in the [FluxCD Apps listing](../user-guide/applications.md#view-external-fluxcd-app-listing).
+
+### GitOps
+
+A methodology for managing and automating Kubernetes deployments using Git repositories as the source of truth. Changes to the desired state of the cluster are driven by Git commits. [Read More...](../user-guide/global-configurations/gitops.md)
+
+### Helm Apps
+
+Apps deployed using Helm Chart from the `Chart Store` section of Devtron. In Devtron, you can view such apps under a tab named `Helm Apps` in the Applications section. To create one, go to Applications → Create (button) → From Chart store.
+
+### Helm Charts/Packages
+
+Packages that contain pre-configured Kubernetes resources and configurations. Helm charts are used to define, install, and upgrade applications on Kubernetes clusters. Refer [chart store](#chart-store) to know more.
+
+### Image
+
+A packaged and standalone software that contains the code and dependencies needed to run a containerized application. Using Devtron, you can build a container image of your application, push it to a container registry, and deploy it on your Kubernetes cluster.
+
+Since images are platform-agnostic, you don't have to worry about compiling your application to work on different systems. With Devtron, you can enable automatic image builds and vulnerability scanning whenever you make edits to your source code. [Read More...](../user-guide/creating-application/workflow/ci-pipeline.md)
+
+You can also view the list of image builds while preparing your deployment in the `Build & Deploy` tab of your application (provided the CI stage is successful).
+
+### Ingress Host URL
+
+A web address (e.g., `https://your-company.com`) that people use to access your application via [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/).
+
+### Job
+
+In Devtron, there is a job that is very similar to Kubernetes job. A Kubernetes job is an object used to create one or more pods to complete a specific task or job and then terminate.
+
+If you are a super-admin in Devtron, you can view Jobs in the sidebar.
+
+### Load Balancer
+
+Distributes incoming network traffic across multiple instances or nodes to ensure efficient resource utilization and improved performance. In Kubernetes, Load Balancer is a service type. Behind the scenes, the managed Kubernetes service connects to the load balancer service of the respective cloud service provider and creates a load balancer, mapping it to the Kubernetes service.
+
+GKE and AKS provide the public IP of the Load Balancer as the service endpoint, while in the case of EKS, it provides a non-customizable DNS name.
+
+### Load Balancer URL
+
+A web address (e.g., `http://sdk39dksig3-23kd.us-west-2.elb.amazonaws.com`) that is automatically generated when the [Load Balancer](#load-balancer) is created. When this load balancer URL is accessed by an external system (e.g., applications running outside the cluster), the load balancer then splits the traffic among different pods and services.
+
+### Manifest
+
+A manifest is a YAML file that describes each component or resource of your Kubernetes object and the state you want your cluster to be in once applied. A manifest specifies the desired state of an object that Kubernetes will maintain when you apply the manifest.
+
+In Devtron, you can view the manifest of K8s resources under `App Details` and also under `Resource Browser`.
+
+### Material
+
+In Git Repo, the source code of your application in a given commit is referred as material. The option to choose a Git material will be available in the CI stage under the `Build & Deploy` tab of your application. [Read More...](../user-guide/jobs/triggering-job.md)
+
+### Namespace
+
+A namespace is a way to organize and isolate resources within a Kubernetes cluster. It provides a logical separation between different applications or environments within a cluster.
+
+In Devtron, you can view a list of namespaces by going to Resource Browser → (choose a cluster) → Namespaces.
+
+### Node Taint
+
+A setting applied to a node that influences the scheduling of pods. Taints can restrict which pods are allowed to run on the node.
+
+In Devtron, you can edit the taints of a node by going to Resource Browser → (choose a cluster) → Nodes → (click on a node) → Edit taints (available in blue). [Read More...](../user-guide/resource-browser/nodes.md#taint-a-node)
+
+### NodePort
+
+A Kubernetes service type that exposes a port on each node in the cluster, making a service accessible externally.
+
+### Nodes
+
+The physical or virtual machines that make up a Kubernetes cluster, where containers are scheduled to run.
+
+In Devtron, you can view nodes by going to Resource Browser → (choose a cluster) → Nodes. [Read More...](../user-guide/resource-browser/nodes.md)
+
+### Objects
+
+Kubernetes objects are the building blocks that define and manage your applications running on the platform. They are also known as 'Resources' or 'Kinds'. This includes nodes, pods, deployment, cronjob, configmap, and many more.
+
+Devtron's [Resource Browser](../user-guide/resource-browser/README.md) helps you manage all such objects present in your clusters.
+
+### Pod
+
+The smallest deployable unit in Kubernetes, consisting of one or more containers that share storage and network resources within the same context.
+
+In Devtron, you can view a list of Pods by going to Resource Browser → (choose a cluster) → Workloads → Pod. In Devtron, you can create a pod by going to Resource Browser → Create Resource (button).
+
+### Pre-build
+
+Actions or processes performed before the actual image-building process in a containerized application's deployment pipeline, e.g., Jira Issue Validator.
+
+In Devtron, you can configure pre-build actions by going to Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit build pipeline) → Pre-build stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/pre-post-tasks.md#creating-prepost-tasks)
+
+### Post-build
+
+Actions or processes performed after the [image](#image) building process in a containerized application's deployment pipeline, e.g., email notification about build status.
+
+In Devtron, you can configure post-build actions by going to Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit build pipeline) → Post-build stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/pre-post-tasks.md#creating-prepost-tasks)
+
+### Pre-deployment
+
+Steps, scripts, or configurations executed before deploying a new version of an application to a Kubernetes cluster.
+
+In Devtron, you can configure pre-deployment actions by going to Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit deployment pipeline) → Pre-deployment stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/cd-pipeline.md#pre-deployment-stage)
+
+### Post-deployment
+
+Actions, checks, or processes carried out after a new version of an application is successfully deployed to a Kubernetes cluster, e.g., Jira Issue Updater.
+
+In Devtron, you can configure post-deployment actions by going to Applications (choose your app) → App Configuration (tab) → Workflow Editor → (edit deployment pipeline) → Post-deployment stage (tab) → Add task (button). [Read More...](../user-guide/creating-application/workflow/cd-pipeline.md#post-deployment-stage)
+
+### ReplicaSet
+
+A Kubernetes object responsible for maintaining a specified number of replica pods, ensuring high availability and desired scaling.
+
+In Devtron, you can view the deployed ReplicaSet by going to Applications (choose your app) → App Details (tab) → K8s Resources (under Application Metrics section).
+
+### Repo
+
+Abbreviation for "repository". It could either signify a Git repo, container repo, or helm repo.
+
+**Git repo** - A version control system (like Git) that stores and manages source code and other project assets. Once you create a git repo, you can add it in Applications (choose your app) → App Configuration (tab) → Git Repository → Add Git Repository.
+
+**Container repo** - A collection of [container images](#image), e.g., Docker repository.
+
+**Helm repo** - Also known as chart repo. You can add it in Global Configurations.
+
+### Resource Allocation
+
+The process where you allocate resources (e.g., `memory`) to different environments depending on your requirement. For example, you might require `50Mi` memory in a QA environment, whereas the same application might need `100Mi` memory in a production-grade environment.
+
+### Rollback
+
+The process of reverting a deployment to a previously known working version in case of errors or issues with the current version.
+
+In Devtron, you can rollback a deployment by going to Applications (choose your app) → Build & Deploy (tab) → (click the rollback icon in the deployment pipeline). [Read More...](../user-guide/deploying-application/rollback-deployment.md)
+
+### Secrets
+
+Kubernetes objects used to store sensitive information, such as passwords and API keys. Secrets are encoded and can be mounted as files or environment variables in pods.
+
+In Devtron, you get the option to add secrets in the `Configurations` tab of your application. You can use different secrets for respective environments too. [Read More...](../user-guide/creating-application/base-config/secrets.md)
+
+### Security Context
+
+A Kubernetes resource configuration that defines security settings and permissions for pods and containers. A security context defines privilege and access control settings for a pod or container. [Read More...](../user-guide/creating-application/base-config/deployment-template-types/deployment.md#security-context)
+
+### Service
+
+When the network addresses of pods changes frequently, it becomes difficult to connect to them directly. A service then acts as a stable access point to your application, and automatically redirects requests to the pods, even when they change over time. To know more, refer to [Service](https://kubernetes.io/docs/concepts/services-networking/service/).
+
+### StatefulSet
+
+A Kubernetes object designed for managing stateful applications, maintaining stable network identities and storage across pod rescheduling.
+
+In Devtron, view the list of StatefulSets by going to Resource Browser → (choose a cluster) → Workloads → StatefulSet. [Read More...](../user-guide/creating-application/base-config/deployment-template-types/statefulset.md)
+
+### Target Platform
+
+The operating system and architecture for which the [container image](#image) will be built, e.g., ubuntu/arm64, linux/amd64. The image will only be compatible to run only on the target platform chosen in the build configuration.
+
+In Devtron, you can choose the target platform by going to Applications (choose your app) → App Configuration (tab) → Build Configuration → (create build pipeline) → (click `Allow Override` button) → Target platform for the build (section). [Read More...](../user-guide/creating-application/docker-build-configuration.md)
+
+
+
+
diff --git a/versioned_docs/version-1.7/reference/graviton.md b/versioned_docs/version-1.7/reference/graviton.md
new file mode 100755
index 0000000000..93dea5355f
--- /dev/null
+++ b/versioned_docs/version-1.7/reference/graviton.md
@@ -0,0 +1,94 @@
+---
+id: graviton
+title: Devtron On Graviton
+sidebar_label: Devtron On Graviton
+---
+
+# Devtron On Graviton
+In cloud computing, optimizing performance, efficiency, and cost-effectiveness is an endless pursuit. As technology evolves, new opportunities arise to achieve these goals. One such advancement is the introduction of AWS Graviton instances, which are rapidly gaining prominence as a game-changer in cloud architecture.
+
+AWS Graviton instances are a family of Arm-based processors developed by Amazon Web Services (AWS). These processors are designed to deliver high performance while maintaining energy efficiency.
+
+We are thrilled to announce that Devtron seamlessly supports Graviton instances, and it's fantastic to note the substantial benefits we've experienced in terms of resource utilization. With 5% less memory utilization and 2% less CPU utilization compared to AMD instances, underscore the advantages of leveraging Graviton architecture. This not only translates into cost savings but also contributes to a more environmentally sustainable cloud infrastructure.
+
+## Installation
+
+To install Devtron on graviton-cluster, refer this [link](../setup/install/devtron-oss.md)
+
+## Inferences
+
+### 1. Reduced Build Time
+
+The utilization of Graviton machines for building Graviton architecture has led to reduction in build time by approximately 30% and less CPU/Memory utilization within Devtron.
+
+**AMD Build**
+
+
+
+
+
+**ARM Build**
+
+
+
+
+
+
+
+### 2. Similar Performance
+
+Experience Devtron's equivalent performance to that of other architectures, all while exhibiting slightly lower resource utilization.
+
+
+
+
+### 3. Less Resource Utilization
+
+Notably, Graviton instances exhibit slightly lower resource utilization compared to AMD Nodes, users can take the opportunity for cost savings in cloud operations.
+
+We have attached some snapshots of the resource utilization for the critical micro-services on Devtron having the GitOps option enabled and more than 115 applications deployed. For an accurate performance comparison, We have used a single-node cluster for both architectures (AMD and ARM).
+
+#### 1. orchestrator
+
+**AMD-Based**
+
+
+
+**ARM-Based**
+
+
+
+
+#### 2. argocd-server
+
+**AMD-Based**
+
+
+
+**ARM-Based**
+
+
+
+#### 3. argocd-application-controller
+
+**AMD-Based**
+
+
+
+**ARM-Based**
+
+
+
+#### 4. argocd-repo-server
+
+**AMD-Based**
+
+
+
+**ARM-Based**
+
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/reference/resources.md b/versioned_docs/version-1.7/reference/resources.md
new file mode 100755
index 0000000000..63cb80fe77
--- /dev/null
+++ b/versioned_docs/version-1.7/reference/resources.md
@@ -0,0 +1,9 @@
+---
+id: resources
+title: Resources
+sidebar_label: Resources
+---
+
+# Resources
+
+Work in Progress
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/configurations/configurations-overview.md b/versioned_docs/version-1.7/setup/configurations/configurations-overview.md
new file mode 100755
index 0000000000..a1847e93fb
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/configurations/configurations-overview.md
@@ -0,0 +1,19 @@
+---
+id: configurations-overview
+title: Advanced Configurations
+sidebar_label: Advanced Configurations
+hide_table_of_contents: true
+---
+
+# Advanced Configurations
+
+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:
+
+* [Installation Configurations](../install/installation-configuration.md)
+* [Override Configurations](../install/override-default-devtron-installation-configs.md)
+
+
+You can also setup `ingress` while setting up Devtron dashboard. Refer [here](../install/ingress-setup.md) for ingress setup.
diff --git a/versioned_docs/version-1.7/setup/getting-started.md b/versioned_docs/version-1.7/setup/getting-started.md
new file mode 100755
index 0000000000..90a322aa86
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/getting-started.md
@@ -0,0 +1,62 @@
+---
+id: getting-started
+title: Getting Started
+sidebar_label: Getting Started
+slug: /getting-started
+---
+
+
+### Introduction
+
+Devtron is installed over a Kubernetes cluster. Once you create a Kubernetes cluster, Devtron can be installed standalone or along with integrations. This section includes information about the minimum requirements you need to install and use Devtron.
+
+---
+
+### Create a Kubernetes Cluster
+
+:::info
+**Setting up a production-grade infrastructure?**
+
+Refer [Devtron's Production Infra Recommendations](./install/prod-infra.md)
+:::
+
+You can create any [Kubernetes cluster](https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/) (preferably K8s version 1.16 or higher) for installing Devtron.
+
+| Cloud Provider | |
+| ---------------------------------- | -------------------------------------------------------- |
+| **AWS EKS** |
Create a cluster using [AWS EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html)
Note: [Refer our documentation](http://github.com/devtron-labs/devtron/blob/b33a37bb608d07966c8f8b89e4f59287db873c6c/docs/setup/install/install-devtron-on-aws-eks.md) for installing Devtron on AWS EKS Cluster
|
+| **Google Kubernetes Engine (GKE)** | Create a cluster using [GKE](https://cloud.google.com/kubernetes-engine/) |
+| **Azure Kubernetes Service (AKS)** | Create a cluster using [AKS](https://learn.microsoft.com/en-us/azure/aks/) |
+| **k3s - Lightweight Kubernetes** |
Create a cluster using [k3s - Lightweight Kubernetes](https://devtron.ai/blog/deploy-your-applications-over-k3s-lightweight-kubernetes-in-no-time/)
Note: [Refer our documentation](../setup/install/devtron-oss.md) for installing Devtron on Minikube, Microk8s, K3s, or Kind
| |
+| **Azure Kubernetes Service (AKS)** | Create a cluster using [AKS](https://learn.microsoft.com/en-us/azure/aks/) |
+| **k3s - Lightweight Kubernetes** |
|
+
+---
+
+### Recommended Resources
+
+The minimum requirements for installing Devtron depends on the integrations you need.
+
+* For configuring small resources (to manage not more than 5 apps on Devtron):
+
+ | Integration | CPU | Memory |
+ | --------------------------------------------- | :-: | :----: |
+ | **With CI/CD, GitOps** | 2 | 6 GB |
+ | **Minimal (Only Dashboard, No Integrations)** | 1 | 1 GB |
+* For configuring medium/larger resources (to manage more than 5 apps on Devtron):
+
+ | Integration | CPU | Memory |
+ | --------------------------------------------- | :-: | :----: |
+ | **With CI/CD, GitOps** | 6 | 13 GB |
+ | **Minimal (Only Dashboard, No Integrations)** | 2 | 3 GB |
+
+> Refer to the [Override Configurations](./install/override-default-devtron-installation-configs.md) section for more information. If you have questions, let us know on our Discord channel. [](https://discord.gg/jsRG5qx2gp)
+
+:::warning Note
+* Please make sure that the recommended resources are available on your Kubernetes cluster before you proceed with Devtron installation.
+* We do not recommend using burstable CPU VMs (T series in AWS, B series in Azure, or E2/N1 in GCP) for installing Devtron, as they may lead to inconsistent performance.
+:::
+
+:::success Next Step
+[Install Devtron on your Kubernetes Cluster](./install/README.md)
+:::
diff --git a/versioned_docs/version-1.7/setup/install/README.md b/versioned_docs/version-1.7/setup/install/README.md
new file mode 100755
index 0000000000..db83b432e7
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/README.md
@@ -0,0 +1,56 @@
+---
+id: README
+title: Install Devtron
+sidebar_label: Install Devtron
+---
+
+# Install Devtron
+
+## Introduction
+
+Devtron can be installed on any [Kubernetes cluster](../getting-started.md#create-a-kubernetes-cluster) of your choice.
+
+The following tiers are available in Devtron:
+
+| Tiers | Description | Installation Link |
+|------------|-----------------------------------------------------------------------------------------------|-------------------|
+| OSS | OSS edition, with optional CI/CD and GitOps modules | [**Install Devtron OSS**](../install/devtron-oss.md) |
+| Freemium | All enterprise features, limited to 1 cluster managed by Devtron | [**Install Devtron Freemium**](../install/devtron-freemium.md) |
+| Enterprise | Full access to enterprise features, with multi-cluster support and enterprise-scale solutions | [**Get Devtron Enterprise**](https://devtron.ai/contact-sales) |
+
+
+## Additional Resources
+
+
+
+Want to install Devtron in an Air-gapped environment?
+
+See the full guide here: [Install Devtron in Air-gapped Environment](install-devtron-in-airgapped-environment.md)
+
+
+
+
+
+Want to explore Devtron without installing on your cluster?
+
+* Try [Devtron Sandbox](https://preview.devtron.ai)
+* Try [Devtron Kubernetes Desktop Client](install-devtron-Kubernetes-client.md)
+
+
+
+
+
+Need help or demo?
+
+* [Discord community for support](https://discord.gg/jsRG5qx2gp) [](https://discord.gg/jsRG5qx2gp)
+* [Book time with our team](https://devtron.ai/demo)
+
+
+
+
+
+Looking for advanced setup?
+
+See [Additional Installation Resources](../../reference/README.md) for production infra recommendations, advanced configs, blob storage, air-gapped installs, backup, and more.
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/install/demo-tutorials.md b/versioned_docs/version-1.7/setup/install/demo-tutorials.md
new file mode 100755
index 0000000000..bda3905973
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/demo-tutorials.md
@@ -0,0 +1,40 @@
+---
+id: demo-tutorials
+title: Demo Tutorials
+sidebar_label: Demo Tutorials
+---
+
+# Demo Tutorials
+
+Here we have demonstrated the installation of Devtron on popular cloud providers. The videos are easy to follow and provide step-by-step instructions.
+
+## Installing on EKS Cluster
+
+**Cloud Provider**: [Amazon Web Services (AWS)](https://aws.amazon.com/)
+
+
+
+---
+
+## Installing on AKS Cluster
+
+**Cloud Provider**: [Microsoft Azure](https://azure.microsoft.com/)
+
+
+
+---
+
+## Installing on GKE Cluster
+
+**Cloud Provider**: [Google Cloud Platform (GCP)](https://console.cloud.google.com/)
+
+
+
+---
+
+:::info Next Recommended Action
+When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
+
+After the initial login, we recommend you set up any [Single Sign-On (SSO)](../../user-guide/global-configurations/sso-login.md) service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (e.g., GitHub) to log in to the Dashboard.
+
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/install/devtron-backup.md b/versioned_docs/version-1.7/setup/install/devtron-backup.md
new file mode 100755
index 0000000000..d83f3bee98
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/devtron-backup.md
@@ -0,0 +1,47 @@
+---
+id: devtron-backup
+title: devtron-backup
+sidebar_label: devtron-backup
+---
+
+## Devtron Backup
+
+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.
+
+1. Go to the devtron chart store and search for `devtron-backups` chart.
+
+
+
+2. Select the `devtron-backups` and click `Configure & Deploy`.
+3. Now follow either of the options described below according to your Cloud provider.
+
+### AWS S3 Backup
+
+To store Devtron backups on AWS S3, please follow these steps:
+
+1. Create an S3 bucket to store the Devtron backup, you can configure the bucket to delete all the objects older than 15/30 days.
+2. Create a user with sufficient permissions to push to the S3 bucket created in step 1.
+3. Obtain the access key and secret access key for the created user.
+4. Configure the `devtron-backups` chart for AWS S3 by selecting the appropriate options:
+
+
+
+5. Deploy the chart, and the Devtron backup will be automatically uploaded to the AWS S3 bucket at the scheduled intervals.
+
+### Azure Containers Backup
+
+To store Devtron backups on Azure Containers, please follow these steps:
+
+1. Create a storage account in Azure.
+2. Within the storage account, create two containers for the Devtron backup.
+3. Navigate to Security + Networking → Access Key section in Azure and copy the Access Key:
+
+
+
+4. Configure the `devtron-backups` chart for Azure Containers by providing the Access Key:
+
+
+
+5. 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.
diff --git a/versioned_docs/version-1.7/setup/install/devtron-freemium.md b/versioned_docs/version-1.7/setup/install/devtron-freemium.md
new file mode 100755
index 0000000000..3dcd2ffec5
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/devtron-freemium.md
@@ -0,0 +1,362 @@
+# Install Devtron Freemium
+
+## Introduction
+
+With Devtron Freemium, you can access all the enterprise features limited to 1 cluster managed by Devtron. For your advanced and challenging use cases, you get comprehensive enterprise features including but not limited to:
+
+* Release orchestration
+* Resource monitoring
+* Advanced filtering
+* Fine-grained access control
+* Security scans
+* Policies related to approval, deployment, plugins, tags, infra...and many more.
+
+:::info Already using Devtron OSS?
+
+This guide is intended for fresh installation of **Devtron Freemium**.\
+If you're currently using the [open-source (OSS) version of Devtron](../install/devtron-oss.md), we **do not recommend** upgrading your existing setup to Devtron Freemium.
+
+Instead, we suggest you to perform a fresh installation of Devtron Freemium on a separate cluster (following the steps below) for the best experience.
+:::
+
+---
+
+## Step 1: Sign up for License
+
+To install Devtron Freemium, go to [Devtron's License Dashboard](https://license.devtron.ai/dashboard/).
+
+You can choose any of the two methods to sign up: [SSO](devtron-freemium.md#method-1-sign-up-using-sso) or [Work Email](devtron-freemium.md#method-2-sign-up-using-work-email)
+
+### Method 1: Sign up using SSO
+
+1. Log in using **Google**, **GitHub**, or **Microsoft** SSO providers. Personal email accounts such as Gmail, Yahoo are not supported.
+
+ 
+
Figure 1: Selecting SSO Provider
+
+2. Once logged in, the **Devtron License Dashboard** will open.
+
+3. Under **Tell Us About You**, fill the required basic details, and click **Next** to proceed to [Step 2: Install Devtron](devtron-freemium.md#step-2-install-devtron).
+
+### Method 2: Sign up using Work Email
+
+Use this method if your email is not associated with any of the SSO options provided on the screen.
+
+1. Select **Continue with Email** to log in.
+
+ 
+
Figure 2: Selecting 'Continue with Email'
+
+2. Enter your work email and select **Send Login Link**
+
+ 
+
Figure 3: Entering Email
+
+3. A login link will be sent to the email address provided by you. If you do not receive the link, you can resend it after 30 seconds.
+
+ **Note:** Your login link will be valid only for 10 minutes.
+
+ 
+
Figure 4: Sending Login Link
+
+:::info
+**Did Not Receive Email?**
+
+* Check all sections of the mailbox, including the 'Spam' section.
+* If the email is in the Spam section, mark it as 'Not Spam'.
+:::
+
+4. Open the email and click **Login to License Dashboard**.
+
+ 
+
Figure 5: Email with Login Link
+
+ Once logged in, the **Devtron License Dashboard** will open.
+5. Under **Tell Us About You**, fill the required basic details, and click **Next** to proceed to [Step 2: Install Devtron](devtron-freemium.md#step-2-install-devtron).
+
+ 
+
Figure 6: Entering the Details
+
+---
+
+## Step 2: Install Devtron
+
+For convenience, Devtron Freemium offers you three installation options:
+
+* [**Option 1**: Install on own K8s Cluster](#option-1-install-on-own-k8s-cluster)
+* [**Option 2**: Install via AWS Marketplace](#option-2-install-via-aws-marketplace)
+* [**Option 3**: Devtron Cloud (SaaS)](#option-3-devtron-cloud-saas)
+
+The below table will help you identify the right option for you.
+
+
+| If you want to… | Install on Own K8s Cluster | Via AWS Marketplace | Devtron Cloud (SaaS) |
+| ----------------------------------------- | -------------------------- | --------------- | -------------------- |
+| Get started in minutes with zero setup | ❌ | ❌ | ✅ |
+| Use Devtron long term | ✅ | ✅ | ❌ |
+| Evaluate Devtron quickly | ❌ | ❌ | ✅ |
+| Run Devtron inside your own cloud account | ✅ | ✅ | ❌ |
+| Use Devtron for production workloads | ✅ | ✅ | ❌ |
+| Pay nothing for Devtron | ✅ | ✅ | ❌ (30-day trial) |
+
+### Option 1: Install on own K8s Cluster
+
+Choose this option if you want Devtron installed in your Kubernetes cluster.
+
+
+
Figure 7: Choosing 'Install on own K8s Cluster'
+
+:::warning Note
+We recommend installing Devtron on a separate Kubernetes cluster, since the cluster may run critical system services. Therefore, it should be kept separate from application workloads. Also ensure your `kubeconfig` is properly configured.
+
+See [Additional Installation Resources](../../reference/README.md) for production infra recommendations, air-gapped installs, blob storage, config overrides, StorageClass, Database, Ingress setup, backups, and more.
+:::
+
+The installation commands are directly available on the [Devtron License Dashboard](https://license.devtron.ai/dashboard) for supported K8s distributions.
+
+1. Select your preferred K8s distribution.
+
+2. Run the installation commands provided.
+
+3. Run the dashboard access commands shown below them.
+
+Once Devtron is installed and you have the dashboard URL, click **Next** to proceed to [Step 3: Get License Key](devtron-freemium.md#step-3-get-license-key)
+
+:::info
+**Using MicroK8s/Kind/K3s/Cloud VMs? Want to Access Dashboard via NodePort? Or Locally from Remote VM?**
+
+* **Access via NodePort**:
+
+To obtain the Dashboard URL on MicroK8s/Kind/K3s/Cloud VMs using NodePort, run the following command to retrieve the port number assigned to the service:
+
+```bash
+kubectl get svc -n devtroncd devtron-service -o jsonpath='{.spec.ports[0].nodePort}'
+```
+
+**Dashboard URL**: `http://:/dashboard`
+
+---
+
+* **Local Access from a remote VM (Port Forwarding via Kubeconfig)**:
+
+To obtain the Dashboard URL if Devtron is installed on a remote VM (e.g., AWS EC2, Azure VM, GCP Compute Engine) using MicroK8s, Kind, or K3s, run the following commands one-by-one:
+
+```bash
+scp user@cloud-vm-ip:/path/to/kubeconfig ~/.kube/config
+kubectl config use-context # Set the correct context.
+kubectl -n devtroncd port-forward service/devtron-service 8000:80
+```
+
+**Dashboard URL**: `http://127.0.0.1:8000`
+
+:::
+
+### Option 2: Install via AWS Marketplace
+
+Choose this option if you want a Devtron instance inside your AWS account with minimal setup effort. It will launch a preconfigured Devtron instance from AWS Marketplace.
+
+
+
Figure 8: Choosing 'Install via AWS Marketplace'
+
+
+
+:::caution
+Since the instance runs inside your AWS account and infrastructure, you might incur infra costs.
+:::
+
+### Option 3: Devtron Cloud (SaaS)
+
+Choose this option if you want to try Devtron without setting up any Kubernetes cluster. You will directly get the credentials to log in to Devtron. This is a 30-day trial meant for fair usage and not production workloads.
+
+
+
Figure 9: Choosing 'Devtron Cloud (SaaS)'
+
+* Click **Launch Devtron**.
+
+ Devtron will provision the SaaS instance within a couple of minutes. The Dashboard URL and credentials will be shown on screen.
+
+ 
+
Figure 10: Enter Installation Fingerprint
+
+* Click **Go to Devtron Dashboard** to open the Devtron login page.
+
+ The username will be `admin`. Enter the password shown to you in the above step.
+
+:::caution
+Instance will automatically hibernate after 72 hours of inactivity.
+:::
+
+:::tip
+Step 3 (given below) will not be applicable for **Devtron Cloud (SaaS)** as you already get the license key and credentials here.
+:::
+
+---
+
+## Step 3: Get License Key
+
+You will now need to enter your Devtron **Installation Fingerprint** to generate a license key.
+
+
+
Figure 11: Enter Installation Fingerprint
+
+### Get Devtron installation's fingerprint
+
+To get the **Installation Fingerprint**, follow the below steps:
+
+1. Visit the Dashboard URL obtained in Step 2.
+
+ 
+
Figure 12: License Activation Screen
+2. You will see an installation fingerprint that uniquely identifies your installation. Copy the fingerprint.
+
+ 
+
Figure 13: Copying Installation Fingerprint
+
+3. Go back to the **License Dashboard** and paste the fingerprint you copied earlier and click **Get License Key**.
+
+ 
+
Figure 14: Pasting Installation Fingerprint
+
+4. Your license will be generated. Copy the license key.
+
+ 
+
Figure 15: Copying Generated License Key
+
+:::warning Note
+The license key you generate will be valid only for your Devtron Freemium installation.
+
+* Only one Devtron Freemium cluster per organization.
+* The license key is uniquely mapped to your installation fingerprint.
+:::
+
+:::danger
+**Warning**
+
+The license is bound to your Kubernetes cluster and cannot be transferred to another cluster. In case the cluster is deleted, you cannot claim freemium license on a new cluster. In that case, contact [support@devtron.ai](mailto:support@devtron.ai).
+:::
+
+5. Go back to your **Devtron Dashboard URL** page. Paste your license key under the **License Key** field, and click **Activate**.
+
+ 
+
Figure 16: Pasting License Key and Activating
+
+6. Devtron Freemium will be activated, and you can log in to **Devtron Dashboard**.
+
+ 
+
Figure 17: Log in as Administrator
+
+:::info
+**Facing Issues?**
+
+Visit the [Troubleshoot](devtron-freemium.md#troubleshoot-issues) section to identify the issue or connect with [Devtron Support](mailto:support@devtron.ai).
+:::
+
+---
+
+## Step 4: Log in to Devtron
+
+1. After successful license activation, you will see the Devtron login page.
+
+ 
+
Figure 18: Devtron Login Page
+2. Initially, log in with the administrator credentials. By default, the username is **admin**. Run the following command to get the admin password:
+
+ ```bash
+ kubectl -n devtroncd get secret devtron-secret \
+ -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+ ```
+
+:::success Next Recommended Action
+After the initial login, we recommend you set up an [Single Sign-On (SSO) service](../../user-guide/global-configurations/sso-login.md) like Google, GitHub, etc., and then [add other members](../../user-guide/global-configurations/authorization/user-access.md#add-users) (including yourself). Thereafter, they can log in using the configured SSO.
+:::
+
+3. After a successful login, the **Devtron Dashboard** will open, and you can explore all the enterprise features supported by Devtron Freemium.
+
+ 
+
Figure 19: Devtron Dashboard
+
+---
+
+## Additional Actions
+
+### Check License Details
+
+In Devtron, click the **Help** menu (top-right corner) → **About Devtron** to know the following:
+
+* License details (Key and Expiry)
+* Installation fingerprint
+* Enterprise version
+
+
+
Figure 20: 'About Devtron' Help Menu
+
+### Update License
+
+If you have a new license key, you can update the license key directly within Devtron, from the **About Devtron** page.
+
+
+
Figure 21: Updating License
+
+### Upgrade License
+
+If you want to add more than one cluster, email us at enterprise@devtron.ai or reach out to your Devtron representative to upgrade your license.
+
+
+
Figure 22: Upgrade License
+
+---
+
+## Troubleshoot Issues
+
+| Issue | What it means | Where is it shown | Solution |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------ |
+|
| You have added more than one cluster | Devtron Dashboard Page or License Dashboard | Reach out to enterprise@devtron.ai for renewal |
+|
License Key Already Exists for Fingerprint Snapshot
| You cannot generate more than 1 license key for 1 fingerprint | License Dashboard (Step-3) | Contact Support |
+
+---
+
+## FAQs
+
+
+
+How many clusters does Freemium support?
+
+Freemium supports **adding one additional cluster** (the **Devtron cluster** where Devtron is installed and **one additional connected cluster**). For more clusters, upgrade to the Devtron Enterprise.
+
+
+
+
+
+Can I convert my existing Devtron OSS setup to Freemium?
+
+We **don’t recommend** converting an existing OSS setup. For the best experience, perform a **fresh Freemium installation**.\
+Refer [Step 2: Install Devtron](devtron-freemium.md#step-2-install-devtron) for the installation.
+
+
+
+
+
+Can I switch from Freemium to a fully Enterprise one without reinstalling?
+
+Yes. You don’t need to reinstall.\
+Contact [Devtron Support](https://devtron.ai/enterprise-support) to obtain a full Enterprise license key, then update the key in your existing setup.
+
+**Steps:** In Devtron, go to **Help → About Devtron → License → Update License**, paste the Enterprise license key, and select **Activate**.\
+Your apps, pipelines, and settings remain intact.
+
+
+
+
+
+Is my Freemium license transferable to another Kubernetes cluster?
+
+No. The Freemium license is bound to your **current Kubernetes cluster** and **cannot be transferred**.\
+If the cluster is deleted, you will not be able to claim a Freemium license on a new cluster.
+
+If you need help, contact [support@devtron.ai](mailto:support@devtron.ai).
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/install/devtron-oss.md b/versioned_docs/version-1.7/setup/install/devtron-oss.md
new file mode 100755
index 0000000000..f7bded379f
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/devtron-oss.md
@@ -0,0 +1,210 @@
+---
+id: devtron-oss
+title: Install Devtron OSS
+sidebar_label: Install Devtron OSS
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Install Devtron OSS
+
+## Introduction
+
+Devtron OSS is the open-source edition of Devtron intended for non-enterprise users.
+
+The table below shows the installation options available in Devtron OSS. Further, there are steps given to install your preferred option in your Kubernetes cluster.
+
+| Installation Option | What Is Included | When To Use |
+| -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------------- |
+| [**Minimal (without integrations)**](#option-a-minimal-without-integrations) | Dashboard + Resource Browser + Core operator configurations | A unified view of Helm apps, FluxCD apps, ArgoCD apps, and their related K8s resources |
+| [**With CI/CD**](#option-b-install-devtron-with-cicd) | Everything in Minimal + Build and Deploy (CI/CD) module | You need a complete CI-CD pipeline for your custom apps (a.k.a Devtron Apps) |
+| [**With CI/CD + GitOps (Argo CD)**](#option-c-install-devtron-with-cicd--gitops-argocd) | Everything in CI/CD + GitOps (Argo CD) module | You need automated, Git-driven deployments |
+
+:::success Not Sure What To Choose?
+Begin with the **Minimal** version. You can always install CI/CD and GitOps integrations later from [Devtron Stack Manager](../../user-guide/integrations/).
+:::
+
+---
+
+## Prerequisites
+
+* Kubernetes cluster v1.16 or later (cloud or local)
+* [Helm v3.8+ installed](https://helm.sh/docs/intro/install/)
+* For production cases, fulfill the [Infrastructure Recommendations](prod-infra.md)
+
+:::warning Cluster created on AWS? Is your EKS version 1.23 or above?
+Install ['AWS EBS CSI' driver](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html) using the following command:
+
+```bash
+helm repo add aws-ebs-csi-driver https://kubernetes-sigs.github.io/aws-ebs-csi-driver
+helm repo update
+helm upgrade --install aws-ebs-csi-driver \
+--namespace kube-system aws-ebs-csi-driver/aws-ebs-csi-driver
+```
+:::
+
+:::warning Using K3s?
+K3s does not include a default storage provisioner, so before you run Helm install in [Step 2](devtron-oss.md#step-2-choose-an-installation-option), apply the Rancher local-path-provisioner to enable dynamic storage:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
+```
+:::
+
+:::info Want to Customize the Installation?
+See [Additional Installation Resources](../../reference/README.md) for production infra recommendations, air-gapped installs, blob storage, config overrides, StorageClass, Database, Ingress setup, backups, and more.
+:::
+
+---
+
+## Step 1: Add Devtron Helm Repository
+
+```bash
+helm repo add devtron https://helm.devtron.ai
+helm repo update devtron
+```
+
+---
+
+## Step 2: Choose an Installation Option
+
+### Option A: Minimal (without integrations)
+
+After you [add Devtron Helm Repository](#step-1-add-devtron-helm-repository) run the command below:
+
+```bash
+helm install devtron devtron/devtron-operator \
+--create-namespace --namespace devtroncd
+```
+
+### Option B: Install Devtron with CI/CD
+
+After you [add Devtron Helm Repository](#step-1-add-devtron-helm-repository) run the command below:
+
+```bash
+helm install devtron devtron/devtron-operator \
+--create-namespace --namespace devtroncd \
+--set installer.modules={cicd}
+```
+
+### Option C: Install Devtron with CI/CD + GitOps (ArgoCD)
+
+After you [add Devtron Helm Repository](#step-1-add-devtron-helm-repository) run the command below:
+
+```bash
+helm install devtron devtron/devtron-operator \
+--create-namespace --namespace devtroncd \
+--set installer.modules={cicd} \
+--set argo-cd.enabled=true
+```
+
+:::info How much time does it take for installation?
+It usually takes 5–15 minutes to spin up all Devtron microservices (depending on your installation option).
+
+You may check the status by running the command below. If the output is `Applied`, Devtron is installed.
+
+```bash
+kubectl -n devtroncd get installers installer-devtron \
+-o jsonpath='{.status.sync.status}'
+```
+
+:::
+
+---
+
+## Step 3: Obtain the Dashboard URL
+
+
+
+To access the dashboard on EKS, AKS, or GKE cluster, run the following command:
+
+```bash
+kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
+```
+
+**Dashboard URL**: The LoadBalancer URL displayed in the output
+
+
+
+
+You have a few different ways to open the Devtron dashboard on local or VM-based clusters.\
+Pick the method that works best for you: quick port-forward, persistent NodePort, or remote access via kubeconfig.
+
+#### Accessing the Dashboard locally (MicroK8s/Kind/K3s)
+
+Run the following command to port-forward the devtron service to port `8000`
+
+```bash
+kubectl -n devtroncd port-forward service/devtron-service 8000:80
+```
+
+**Dashboard URL**: `http://127.0.0.1:8000`
+
+---
+
+#### Accessing the Dashboard via NodePort
+
+If you prefer NodePort instead of port-forwarding, reinstall Devtron with:
+
+```bash
+--set components.devtron.service.type=NodePort
+```
+
+Then run the following command to get the port number assigned to the service:
+
+```bash
+kubectl get svc -n devtroncd devtron-service -o jsonpath='{.spec.ports[0].nodePort}'
+```
+
+**Dashboard URL**: `http://:/dashboard`
+
+---
+
+#### Accessing the Dashboard locally from a remote VM (Port Forwarding via Kubeconfig)
+
+If Devtron is installed on a remote VM (e.g., AWS EC2, Azure VM, GCP Compute Engine) using MicroK8s, Kind, or K3s, run the following commands one-by-one:
+
+```bash
+scp user@cloud-vm-ip:/path/to/kubeconfig ~/.kube/config
+
+kubectl config use-context # Set the correct context.
+
+kubectl -n devtroncd port-forward service/devtron-service 8000:80
+```
+
+**Dashboard URL**: `http://127.0.0.1:8000`
+
+
+
+
+
+Run the following command:
+
+```bash
+minikube service devtron-service --namespace devtroncd
+```
+
+**Dashboard URL**: (Directly opens in your browser)
+
+
+
+
+---
+
+## Step 4: Log in to Devtron
+
+1. From your browser, visit the Dashboard URL (obtained in the previous step) to view the login page of Devtron.
+2. Enter **`admin`** in the username.
+3. Run the below command to get your password.
+
+ ```bash
+ kubectl -n devtroncd get secret devtron-secret \
+ -o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+ ```
+
+You should see the **Devtron Dashboard** post successful login.
+
+:::success Next Recommended Action
+After the initial login, we recommend you set up an [Single Sign-On (SSO) service](../../user-guide/global-configurations/sso-login.md) like Google, GitHub, etc., and then [add other members](../../user-guide/global-configurations/authorization/user-access.md#add-users) (including yourself). Thereafter, they can log in using the configured SSO.
+:::
diff --git a/versioned_docs/version-1.7/setup/install/faq-on-installation.md b/versioned_docs/version-1.7/setup/install/faq-on-installation.md
new file mode 100755
index 0000000000..a8a0ee9f6f
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/faq-on-installation.md
@@ -0,0 +1,53 @@
+---
+id: faq-on-installation
+title: FAQ
+sidebar_label: FAQ
+hide_table_of_contents: true
+---
+
+
+# FAQ
+
+
+ 1. How will I know when the installation is finished?
+
+ Run the following command to check the status of the installation:
+
+ ```bash
+ kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.status}'
+ ```
+
+ The above command will print `Applied` once the installation process is complete. The installation process could take up to 30 minutes.
+
+
+
+ 2. How do I track the progress of the installation?
+
+ Run the following command to check the logs of the Pod:
+
+ ```bash
+ pod=$(kubectl -n devtroncd get po -l app=inception -o jsonpath='{.items[0].metadata.name}')&& kubectl -n devtroncd logs -f $pod
+ ```
+
+
+
+ 3. How can I restart the installation if the Devtron installer logs contain an error?
+
+ First run the below command to clean up components installed by Devtron installer:
+
+ ```bash
+ cd devtron-installation-script/
+ kubectl delete -n devtroncd -f yamls/
+ kubectl -n devtroncd patch installer installer-devtron --type json -p '[{"op": "remove", "path": "/status"}]'
+ ```
+
+ Next, [install Devtron](./devtron-oss.md)
+
+
+
+ 4. What's the purpose of 'Login as administrator' option on the login page?
+ 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.
+
+
+
+Still facing issues, please reach out to us on [Discord](https://discord.gg/jsRG5qx2gp).
diff --git a/versioned_docs/version-1.7/setup/install/freemium.md b/versioned_docs/version-1.7/setup/install/freemium.md
new file mode 100755
index 0000000000..080fb712a8
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/freemium.md
@@ -0,0 +1,445 @@
+---
+hidden: true
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Install Devtron Freemium
+
+## Introduction
+
+With Devtron Freemium, you can access all the enterprise features limited to adding one additional cluster only, i.e., Devtron cluster (the cluster where Devtron is installed) and you can add up to one additional Kubernetes cluster. For your advanced and challenging use cases, you get comprehensive enterprise features including but not limited to:
+
+1. Release orchestration
+2. Resource monitoring
+3. Advanced filtering
+4. Fine-grained access control
+5. Security scans
+6. Policies related to approval, deployment, plugins, tags, infra...and many more.
+
+
+:::info Already using Devtron's Open Source version?
+This guide is intended for fresh installation of **Devtron Freemium**.
+If you're currently using the open-source (OSS) version of Devtron, we **do not recommend** upgrading your existing setup to Devtron Freemium.
+
+Instead, we suggest you to perform a fresh installation of Devtron Freemium on a separate cluster (following the steps below) for the best experience.
+:::
+
+---
+
+## Step 1: Go to the Devtron License Dashboard
+
+To install Devtron Freemium; go to the [Devtron License Dashboard](https://license.devtron.ai/dashboard/).\
+\
+Log in with your work email to access the license dashboard. Devtron provides two login methods to log in to the License Dashboard
+
+### Method 1: Log In with SSO
+
+1. Log in using **Google**, **GitHub**, or **Microsoft** SSO providers. Personal email accounts such as Gmail, Yahoo are not supported.
+
+
+
+2. Once logged in, the **Devtron License Dashboard** will open.
+3. Under **Tell Us About You**, enter some basic details to help us improve your Devtron Experience.
+4. After entering the details, click **Next** to proceed to [Step 2: Install Devtron](freemium.md#step-2-install-devtron).
+
+
+
+### Method 2: Log In with Email
+
+You can also log in via **Continue with Email**. This will send a login link to the provided work email. To do so, follow the below steps:
+
+1. Select **Continue with Email** to log in.
+
+
+
+2. Enter your work email and select **Send Login Link**
+
+
+
+3. A login link will be sent to the email provided by you. If you do not receive the link, you can resend it after 30 seconds.
+
+**Note:** Your login link is valid only for 10 minutes.
+
+
+
+:::info Email not received?
+* Check all sections of the mailbox, including the Spam section.
+* If you find the login link email in the Spam section, mark it as 'Not Spam'.
+:::
+
+4. Go to your provided email inbox and use the login link.
+
+
+
+Once logged in, the **Devtron License Dashboard** will open.
+
+5. Under **Tell Us About You**, enter a few basic details to help us improve your Devtron Experience.
+6. Click **Next** to proceed to [Step 2: Install Devtron](freemium.md#step-2-install-devtron).
+
+
+
+---
+
+## Step 2: Install Devtron
+
+:::success Recommendation
+We recommend installing Devtron on a separate Kubernetes cluster, as Devtron Cluster (cluster on which Devtron is installed) has critical system services and should be kept separate from application workloads.
+:::
+
+After entering the basic details, the next step is to install **Devtron Freemium**.
+
+The installation commands for installing **Devtron in Full Mode** (with integrations) is directly available on the **Devtron License Dashboard** for different K8s distributions.
+
+Choose your preferred K8s distribution and follow the displayed commands to install **Devtron in Full Mode**.
+
+
+
+In case, you want to install Devtron dashboard only, use the commands given in **Devtron without integrations (only dashboard)** tab in [Choose an Installation Option](freemium.md#22-choose-an-installation-option) section.
+
+:::info Install Devtron in Air-Gapped Environments
+You can also install Devtron in Air-Gapped environments to securely manage and deploy applications without internet access.
+
+Refer the [Devtron Enterprise (Air‐gapped) Guide](https://github.com/devtron-labs/utilities/wiki/Devtron-Enterprise-\(Air%E2%80%90gapped\)) to install Devtron in Air-Gapped environments.
+:::
+
+:::warning Note
+Please ensure that cluster `kubeconfig` is properly configured and available in your system.
+:::
+
+### 2.1 Add Devtron Helm Repository
+
+```bash
+helm repo add devtron https://helm.devtron.ai
+helm repo update devtron
+```
+
+### 2.2 Choose an Installation Option
+
+
+
+* To install Devtron with all core enterprise features **except ArgoCD**:
+
+```bash
+helm install devtron devtron/devtron-enterprise --create-namespace --namespace devtroncd
+```
+
+* To include ArgoCD integration, add `--set devtron.argo-cd.enabled=true`
+
+```bash
+helm install devtron devtron/devtron-enterprise --create-namespace --namespace devtroncd --set devtron.argo-cd.enabled=true
+```
+
+
+
+To install only the Devtron Dashboard (without CI/CD, ArgoCD, Security, Notification, or Monitoring):
+
+```bash
+helm install devtron devtron/devtron-enterprise --create-namespace --namespace devtroncd \
+--set devtron.installer.modules={} --set devtron.security.enabled=false \
+--set devtron.notifier.enabled=false --set devtron.security.trivy.enabled=false --set devtron.monitoring.grafana.enabled=false
+```
+
+
+
+### 2.3 Obtain the Dashboard URL
+
+
+
+Run the following command to get the Dashboard URL:
+
+```bash
+kubectl get svc -n devtroncd devtron-service -o jsonpath='{.status.loadBalancer.ingress}'
+```
+
+You can access your Devtron Dashboard using the LoadBalancer URL displayed in the output.
+
+
+
+#### Accessing the Dashboard locally (MicroK8s/Kind/K3s)
+
+To obtain the Dashboard URL when MicroK8s/Kind/K3s running locally, run the following command to port-forward the devtron service to port `8000`
+
+```bash
+kubectl -n devtroncd port-forward service/devtron-service 8000:80
+```
+
+After port-forwarding, The Dashboard URL will be: `http://127.0.0.1:8000`
+
+#### Accessing the Dashboard via NodePort
+
+To obtain the Dashboard URL on MicroK8s/Kind/K3s using NodePort, run the following command to retrieve the port number assigned to the service:
+
+```bash
+kubectl get svc -n devtroncd devtron-service -o jsonpath='{.spec.ports[0].nodePort}'
+```
+
+The Dashboard URL will be: `http://:/dashboard`
+
+#### Accessing the Dashboard locally from a remote VM (Port Forwarding via Kubeconfig)
+
+To obtain the Dashboard URL if Devtron is installed on a remote VM (e.g., AWS EC2, Azure VM, GCP Compute Engine) using MicroK8s, Kind, or K3s, run the following commands:
+
+```bash
+scp user@cloud-vm-ip:/path/to/kubeconfig ~/.kube/config
+# Export the kubeconfig file from the remote VM to your local system.
+
+kubectl config use-context
+# Set the correct context.
+
+kubectl -n devtroncd port-forward service/devtron-service 8000:80
+# This command will forward traffic from the service running on the
+# remote VM's MicroK8s, Kind, or K3s cluster to your local system’s port.
+```
+
+The Dashboard URL will be `http://127.0.0.1:8000` on your local machine.
+
+
+
+To access the dashboard on Minikube cluster, run the following command:
+
+```bash
+minikube service devtron-service --namespace devtroncd
+```
+
+This will directly open the dashboard URL on your browser
+
+
+
+#### Accessing the Dashboard via NodePort
+
+To obtain the dashboard URL on Cloud VMs using NodePort, run the following command to retrieve the port number assigned to the service:
+
+```bash
+kubectl get svc -n devtroncd devtron-service -o jsonpath='{.spec.ports[0].nodePort}'
+```
+
+The Dashboard URL will be: `http://:/dashboard`
+
+#### Accessing the Dashboard locally from a remote VM (Port Forwarding via Kubeconfig)
+
+To obtain the Dashboard URL if Devtron is installed on a remote VM (e.g., AWS EC2, Azure VM, GCP Compute Engine) using MicroK8s, Kind, or K3s, run the following commands:
+
+```bash
+scp user@cloud-vm-ip:/path/to/kubeconfig ~/.kube/config
+# Export the kubeconfig file from the remote VM to your local system.
+
+kubectl config use-context
+# Set the correct context.
+
+kubectl -n devtroncd port-forward service/devtron-service 8000:80
+# This command will forward traffic from the service running on the
+# remote VM's MicroK8s, Kind, or K3s cluster to your local system’s port.
+```
+
+The Dashboard URL will be `http://127.0.0.1:8000` on your local machine.
+
+
+
+After successfully installing Devtron and obtaining the dashboard URL, click **Next** to proceed to [Step 3: Get License Key](freemium.md#step-3-get-license-key)
+
+---
+
+## Step 3: Get License Key
+
+You will now need to enter your Devtron **Installation Fingerprint** to generate a license key.
+
+
+
+### Get Devtron installation's fingerprint
+
+To get the **Installation Fingerprint**, follow the below steps
+
+1. Visit your Dashboard URL (which you have obtained in [Step-2.3](freemium.md#23-obtain-the-dashboard-url)) as shown below.
+
+
+
+2. You will see an Installation Fingerprint that uniquely identifies your installation. Copy the fingerprint.
+
+
+
+3. Go back to the **License Dashboard** and paste the fingerprint you copied earlier and click **Get License Key**.
+
+
+
+4. Your license will be generated. Copy the license key.
+
+
+
+:::warning Note
+The license key you generate will be valid only for your Devtron Freemium installation.
+
+* Only one Devtron Freemium cluster per organization.
+* The license key is uniquely mapped to your installation fingerprint.
+:::
+
+:::danger Warning
+The license is bound to your Kubernetes cluster and cannot be transferred to another cluster. In case cluster is deleted, you cannot claim freemium license on a new cluster.
+
+In such cases, contact [Devtron Support](mailto:support@devtron.ai).
+:::
+
+5. Go back to your **Devtron Dashboard URL** page and paste your license key under **License Key** field and click **Activate**.
+
+
+
+6. **Devtron Freemium** will be activated, and you can log in to **Devtron Dashboard**.
+
+
+
+:::info Facing Issues?
+Visit the [Troubleshoot](freemium.md#troubleshoot-issues) section to identify the issue or connect with [Devtron Support](mailto:support@devtron.ai).
+:::
+
+---
+
+## Log in to Devtron
+
+1. After successful license activation, you will see the Devtron login page.
+
+
+
+2. Initially, log in with the administrator credentials. By default, the username is **admin**. Run the following command to get the admin password:
+
+```bash
+kubectl -n devtroncd get secret devtron-secret \
+-o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+:::info Note
+When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
+
+After the initial login, we recommend you set up any [Single Sign-On (SSO) service](../../user-guide/global-configurations/sso-login.md) 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 the Dashboard.
+:::
+
+3. After a successful login, the **Devtron Dashboard** will open, and you can explore all the enterprise features supported by Devtron Freemium.
+
+
+
+---
+
+## Convert Enterprise Free Trial to Freemium
+
+You can switch to Devtron Freemium at no cost and no reinstallation is required. All your apps, pipelines and config will remain intact.
+
+After upgrade, with Devtron Freemium, you will be able to access all Devtron enterprise features for free and forever, with the limit of adding one additional connected cluster (the default cluster where Devtron runs + 1 additional connected cluster).
+
+:::warning Mandatory Action Before Upgrading
+Ensure your Enterprise Free Trial has no more than one additional cluster connected (Devtron Cluster + 1 additional connected cluster). If more than one additional cluster is connected, disconnect the extra clusters before upgrading; otherwise, the upgrade will not proceed.
+:::
+
+1. Open your Devtron dashboard and navigate to **Help** → **About Devtron** → **License**.
+
+ 
+2. Copy the Installation fingerprint.
+
+ 
+3. Navigate to the license dashboard; and you will be automatically redirected to the step 3 (Get License Key).
+
+ 
+4. Paste the fingerprint you copied earlier and click **Get License Key**.
+
+ 
+5. Your license will be generated. Copy the license key.
+
+ 
+6. Navigate back to **Help** → **About Devtron** → **License**, and click **Update License**.
+
+ 
+7. Paste the new license key you copied earlier and click **Activate**; Devtron Freemium is now activated.
+
+ 
+
+---
+
+## Additional Actions
+
+### Check License Details
+
+In Devtron, click the **Help** menu (top-right corner) → **About Devtron** to know the following:
+
+* License details (Key and Expiry)
+* Installation fingerprint
+* Enterprise version
+
+
+
+### Update License
+
+If you have a new license key, you can update the license key directly within Devtron, from the **About Devtron** page.
+
+
+
+### Upgrade License
+
+If you want to add more than one cluster, email us at [enterprise@devtron.ai](mailto:enterprise@devtron.ai) or reach out to your Devtron representative to upgrade your license.
+
+
+
+---
+
+## Troubleshoot Issues
+
+| Issue | What it means | Where is it shown | Solution |
+| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------- | ------------------------------------------------------------ |
+|
| Someone from your organization has already availed a license | License Dashboard | Reach out to [enterprise@devtron.ai](mailto:enterprise@devtron.ai) |
+|
| You have added more than one cluster | Devtron Dashboard Page or License Dashboard | Reach out to enterprise@devtron.ai for renewal |
+|
License Key Already Exists for Fingerprint Snapshot
| You cannot generate more than 1 license key for 1 fingerprint | License Dashboard (Step-3) | Contact Support |
+
+---
+
+## FAQs
+
+
+
+How many clusters does Freemium support?
+
+Freemium supports **adding one additional cluster** (the **Devtron cluster** where Devtron is installed and **one additional connected cluster**). For more clusters, upgrade to the Devtron Enterprise.
+
+
+
+
+
+Can I convert my existing Devtron OSS setup to Freemium?
+
+We **don’t recommend** converting an existing OSS setup. For the best experience, perform a **fresh Freemium installation**.\
+Refer [Step 2: Install Devtron](freemium.md#step-2-install-devtron) for the installation.
+
+
+
+
+
+I’m on the Enterprise Free Trial. Can I switch to Freemium for free?
+
+Yes. Generate a **Freemium** license key from the [License Dashboard](https://license.devtron.ai/dashboard/).\
+In Devtron, open **Help → About Devtron → Update License**, paste the key, and select **Activate**.\
+No reinstallation required; your setup remains intact.
+
+
+
+
+
+Can I switch from Freemium to the Enterprise without reinstalling Devtron?
+
+Yes. You don’t need to reinstall.\
+Contact [Devtron Support](https://devtron.ai/enterprise-support) to obtain an Enterprise license key, then update the key in your existing setup.
+
+**Steps:** In Devtron, go to **Help → About Devtron → License → Update License**, paste the Enterprise license key, and select **Activate**.\
+Your apps, pipelines, and settings remain intact.
+
+
+
+
+
+Is my Freemium license transferable to another Kubernetes cluster?
+
+No. The Freemium license is bound to your **current Kubernetes cluster** and **cannot be transferred**.\
+If the cluster is deleted, you will not be able to claim a Freemium license on a new cluster.
+
+If you need help, contact [Devtron Support](mailto:support@devtron.ai).
+
+
diff --git a/versioned_docs/version-1.7/setup/install/ingress-setup.md b/versioned_docs/version-1.7/setup/install/ingress-setup.md
new file mode 100755
index 0000000000..990acc59c5
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/ingress-setup.md
@@ -0,0 +1,314 @@
+---
+id: ingress-setup
+title: Ingress Setup
+sidebar_label: Ingress Setup
+---
+
+# Ingress Setup
+
+## Introduction
+
+If you wish to use [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) as a means to access the Devtron services available in your cluster, you can configure it either during the installation or after the installation of Devtron.
+
+Refer the section relevant to you:
+* [During Devtron Installation](#enabling-ingress-during-devtron-installation)
+* [After Devtron Installation](#configuring-ingress-after-devtron-installation)
+
+If you have successfully configured Ingress, refer [Post Ingress Setup](#enable-https-for-devtron).
+
+---
+
+## Enabling Ingress during Devtron Installation
+
+If you are installing Devtron, you can enable Ingress either via [set flag](#using-set-flag) or by using [ingress-values.yaml](#using-ingress-valuesyaml) to specify the desired Ingress settings.
+
+### Using set flag
+
+You can use the `--set` flag to specify the desired Ingress settings.
+
+Here, we have added 5 configurations you can perform depending on your requirements:
+* [Only Basic Configuration](#only-basic-configuration)
+* [Configuration Including Labels](#configuration-including-labels)
+* [Configuration Including Annotations](#configuration-including-annotations)
+* [Configuration Including TLS Settings](#configuration-including-tls-settings)
+* [Comprehensive Configuration](#comprehensive-configuration)
+
+#### Only Basic Configuration
+
+To enable Ingress and set basic parameters, use the following command:
+
+```bash
+helm install devtron devtron/devtron-operator -n devtroncd \
+ --set components.devtron.ingress.enabled=true \
+ --set components.devtron.ingress.className=nginx \
+ --set components.devtron.ingress.host=devtron.example.com
+```
+
+#### Configuration Including Labels
+
+To add labels to the Ingress resource, use the following command:
+
+```bash
+helm install devtron devtron/devtron-operator -n devtroncd \
+ --set components.devtron.ingress.enabled=true \
+ --set components.devtron.ingress.className=nginx \
+ --set components.devtron.ingress.host=devtron.example.com \
+ --set components.devtron.ingress.labels.env=production
+```
+
+#### Configuration Including Annotations
+
+To add annotations to the Ingress resource, use the following command:
+
+```bash
+helm install devtron devtron/devtron-operator -n devtroncd \
+ --set components.devtron.ingress.enabled=true \
+ --set components.devtron.ingress.className=nginx \
+ --set components.devtron.ingress.host=devtron.example.com \
+ --set components.devtron.ingress.annotations."kubernetes\.io/ingress\.class"=nginx \
+ --set components.devtron.ingress.annotations."nginx\.ingress\.kubernetes\.io\/app-root"="/dashboard"
+```
+
+#### Configuration Including TLS Settings
+
+To configure TLS settings, including `secretName` and `hosts`, use the following command:
+
+```bash
+helm install devtron devtron/devtron-operator -n devtroncd \
+ --set components.devtron.ingress.enabled=true \
+ --set components.devtron.ingress.className=nginx \
+ --set components.devtron.ingress.host=devtron.example.com \
+ --set components.devtron.ingress.tls[0].secretName=devtron-tls \
+ --set components.devtron.ingress.tls[0].hosts[0]=devtron.example.com
+```
+
+#### Comprehensive Configuration
+
+To include all the above settings in a single command, use:
+
+```bash
+helm install devtron devtron/devtron-operator -n devtroncd \
+ --set components.devtron.ingress.enabled=true \
+ --set components.devtron.ingress.className=nginx \
+ --set components.devtron.ingress.host=devtron.example.com \
+ --set components.devtron.ingress.annotations."kubernetes\.io/ingress\.class"=nginx \
+ --set components.devtron.ingress.annotations."nginx\.ingress\.kubernetes\.io\/app-root"="/dashboard" \
+ --set components.devtron.ingress.labels.env=production \
+ --set components.devtron.ingress.pathType=ImplementationSpecific \
+ --set components.devtron.ingress.tls[0].secretName=devtron-tls \
+ --set components.devtron.ingress.tls[0].hosts[0]=devtron.example.com
+```
+
+
+### Using ingress-values.yaml
+
+As an alternative to the [set flag](#using-set-flag) method, you can enable Ingress using `ingress-values.yaml` instead.
+
+Create an `ingress-values.yaml` file. You may refer the below format for an advanced ingress configuration which includes labels, annotations, secrets, and many more.
+
+```yml
+components:
+ devtron:
+ ingress:
+ enabled: true
+ className: nginx
+ labels: {}
+ # env: production
+ annotations: {}
+ # nginx.ingress.kubernetes.io/app-root: /dashboard
+ pathType: ImplementationSpecific
+ host: devtron.example.com
+ tls: []
+ # - secretName: devtron-info-tls
+ # hosts:
+ # - devtron.example.com
+```
+
+Once you have the `ingress-values.yaml` file ready, run the following command:
+
+```bash
+helm install devtron devtron/devtron-operator -n devtroncd --reuse-values -f ingress-values.yaml
+```
+
+---
+
+## Configuring Ingress after Devtron Installation
+
+After Devtron is installed, Devtron is accessible through `devtron-service`. If you wish to access Devtron through ingress, you'll need to modify this service to use a ClusterIP instead of a LoadBalancer.
+
+You can do this using the `kubectl patch` command:
+
+```bash
+kubectl patch -n devtroncd svc devtron-service -p '{"spec": {"ports": [{"port": 80,"targetPort": "devtron","protocol": "TCP","name": "devtron"}],"type": "ClusterIP","selector": {"app": "devtron"}}}'
+```
+
+Next, create ingress to access Devtron by applying the `devtron-ingress.yaml` file. The file is also available on this [link](https://github.com/devtron-labs/devtron/blob/main/manifests/yamls/devtron-ingress.yaml). You can access Devtron from any host after applying this yaml.
+
+```yml
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+ annotations:
+ nginx.ingress.kubernetes.io/app-root: /dashboard
+ labels:
+ app: devtron
+ release: devtron
+ name: devtron-ingress
+ namespace: devtroncd
+spec:
+ ingressClassName: nginx
+ rules:
+ - http:
+ paths:
+ - backend:
+ service:
+ name: devtron-service
+ port:
+ number: 80
+ path: /orchestrator
+ pathType: ImplementationSpecific
+ - backend:
+ service:
+ name: devtron-service
+ port:
+ number: 80
+ path: /dashboard
+ pathType: ImplementationSpecific
+ - backend:
+ service:
+ name: devtron-service
+ port:
+ number: 80
+ path: /grafana
+ pathType: ImplementationSpecific
+```
+
+For k8s versions < 1.19, [apply this yaml](https://github.com/devtron-labs/devtron/blob/main/manifests/yamls/devtron-ingress-legacy.yaml):
+
+```yml
+apiVersion: extensions/v1beta1
+kind: Ingress
+metadata:
+ annotations:
+ nginx.ingress.kubernetes.io/app-root: /dashboard
+ labels:
+ app: devtron
+ release: devtron
+ name: devtron-ingress
+ namespace: devtroncd
+spec:
+ rules:
+ - http:
+ paths:
+ - backend:
+ serviceName: devtron-service
+ servicePort: 80
+ path: /orchestrator
+ - backend:
+ serviceName: devtron-service
+ servicePort: 80
+ path: /dashboard
+ pathType: ImplementationSpecific
+```
+
+Optionally, you also can access Devtron through a specific host by running the following YAML file:
+
+```yml
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+ annotations:
+ nginx.ingress.kubernetes.io/app-root: /dashboard
+ labels:
+ app: devtron
+ release: devtron
+ name: devtron-ingress
+ namespace: devtroncd
+spec:
+ ingressClassName: nginx
+ rules:
+ - host: devtron.example.com
+ http:
+ paths:
+ - backend:
+ service:
+ name: devtron-service
+ port:
+ number: 80
+ path: /orchestrator
+ pathType: ImplementationSpecific
+ - backend:
+ service:
+ name: devtron-service
+ port:
+ number: 80
+ path: /dashboard
+ pathType: ImplementationSpecific
+ - backend:
+ service:
+ name: devtron-service
+ port:
+ number: 80
+ path: /grafana
+ pathType: ImplementationSpecific
+```
+
+---
+
+## Enable HTTPS For Devtron
+
+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.
+
+### 1. Nginx Ingress Controller
+
+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.
+
+```bash
+ annotations:
+ service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"
+ service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
+ nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
+ service.beta.kubernetes.io/aws-load-balancer-ssl-cert: ""
+```
+
+(ii) Digital Ocean
+
+If you are using Digital Ocean cloud, add the following annotations under `service.annotations` under nginx ingress controller.
+
+```bash
+annotations:
+ service.beta.kubernetes.io/do-loadbalancer-protocol: "http"
+ service.beta.kubernetes.io/do-loadbalancer-tls-ports: "443"
+ service.beta.kubernetes.io/do-loadbalancer-certificate-id: ""
+ service.beta.kubernetes.io/do-loadbalancer-redirect-http-to-https: "true"
+```
+
+### 2. AWS Application Load Balancer (AWS ALB)
+
+In case of AWS application load balancer, add following annotations under `ingress.annotations` to run devtron over `https`.
+
+```bash
+ annotations:
+ kubernetes.io/ingress.class: alb
+ alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
+ alb.ingress.kubernetes.io/certificate-arn: ""
+```
+
+### 3. Azure Application Gateway
+
+In case of AWS application load balancer, the following annotations need to be added under `ingress.annotations` to run devtron over `https`.
+
+```bash
+ annotations:
+ kubernetes.io/ingress.class: "azure/application-gateway"
+ appgw.ingress.kubernetes.io/backend-protocol: "http"
+ appgw.ingress.kubernetes.io/ssl-redirect: "true"
+ appgw.ingress.kubernetes.io/appgw-ssl-certificate: ""
+```
+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.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/install/install-devtron-Kubernetes-client.md b/versioned_docs/version-1.7/setup/install/install-devtron-Kubernetes-client.md
new file mode 100755
index 0000000000..4086878fa4
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/install-devtron-Kubernetes-client.md
@@ -0,0 +1,182 @@
+---
+id: install-devtron-Kubernetes-client
+title: Devtron Kubernetes Desktop Client
+sidebar_label: Devtron Kubernetes Desktop Client
+---
+
+# Devtron Kubernetes Desktop Client
+
+## Introduction
+
+The Devtron Kubernetes Desktop Client is a lightweight dashboard that is installed outside your Kubernetes [cluster](../../reference/glossary.md#cluster) on a `arm64` / `amd64` based architecture to help you manage your Kubernetes resources with a unified view.
+
+The **Devtron Kubernetes Desktop Client** comes packaged with the following modules:
+
+* [Kubernetes Resource Browser](#kubernetes-resource-browser) - To manage all Kubernetes resources in your cluster(s)
+* [Clusters](#clusters) - To perform troubleshooting and node operations on the cluster(s) you connect from the Devtron Kubernetes Desktop Client
+
+:::success
+Try Devtron Freemium to access all the enterprise features for free and forever, limited to adding one additional cluster. [Install Devtron Freemium](https://license.devtron.ai/dashboard)
+
+:::
+
+---
+
+## Steps
+
+1. Run the following command in your terminal to automatically download the executable file. Devtron Kubernetes Desktop Client will automatically opened in your default browser.
+
+ ```bash
+ wget -O devtron-install.bash https://cdn.devtron.ai/k8s-client/devtron-install.bash && [ -f devtron-install.bash ] && sh devtron-install.bash start
+ ```
+
+:::info Desktop Client not opening?
+* In case you closed the Devtron Kubernetes Desktop Client browser tab by mistake, you can reopen it by executing the following command in your terminal:
+
+ ```bash
+ sh devtron-install.bash open
+ ```
+
+* When installing the Devtron Kubernetes Desktop Client, if you encounter any errors, or if the tab opened in your default browser fails to load, or you encounter any issue because of the existence of the application, run the following command to delete the application.
+
+ ```bash
+ rm -rf .devtron/
+ ```
+
+:::
+
+2. Open your terminal and enter the following command to download and run a bash script for generating the [kubeconfig](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/):
+
+ ```bash
+ curl -O https://raw.githubusercontent.com/devtron-labs/utilities/main/kubeconfig-exporter/kubernetes_export_sa.sh && bash kubernetes_export_sa.sh cd-user devtroncd
+ ```
+
+ The cluster credentials are displayed in the output of the command.
+
+:::info Important Note
+Upon executing the above-mentioned command, if you encounter an error saying that you already have a service account named `cd-user`, change the service account name in the command from `cd-user` to `cd-user1` or `cd-user2`.
+
+:::
+
+3. Fetch the cluster credentials (`Cluster name`, `Server URL`, `Bearer token`) from the terminal and note them aside.
+
+ 
+
+4. Navigate to **Global Configurations** → **Clusters & Environments** → **Add cluster** and paste the credentials in their respective fields.
+
+ 
+
+ 
+
+5. Click **Save Cluster**. This cluster will now be displayed in the **Kubernetes Resource Browser** page. Refer [Kubernetes Resource Browser](#kubernetes-resource-browser) or [Clusters](#clusters) in the Devtron Kubernetes Desktop Client for more information.
+
+6. To stop the Devtron Kubernetes Desktop Client, run the following command in your terminal:
+
+ ```bash
+ sh devtron-install.bash stop
+ ```
+
+:::info Note
+The next time, if you wish to run the Devtron Kubernetes Desktop Client again, run the following command in your terminal:
+
+```bash
+sh devtron-install.bash start
+```
+
+:::
+
+---
+
+## Kubernetes Resource Browser
+
+Kubernetes Resource Browser, in short, is a central interface from which you can view logs, edit live manifests, and even perform CRUD operations (create, read, update, or delete) on resources like pods, deployments, configmaps, jobs, and many more in the cluster(s).
+
+On the left side bar, under the **K8s Resources** tab, the Kubernetes resources are grouped into the following categories:
+
+* Workloads
+
+* Config & Storage
+
+* Networking
+
+* RBAC
+
+* Administration
+
+* Other Resources
+
+* Custom Resource
+
+
+
+For the convenience of the user, the Resource Browser page comes with a search box and filters to locate resource kinds quickly.
+
+
+
+
+
+### Create a Resource
+
+
+
+#### Sample Script for Creating a Pod
+
+```bash
+apiVersion: v1
+kind: Pod
+metadata:
+ name: my-sample-pod
+ labels:
+ app: sampleApp
+spec:
+ containers:
+ - name: nginx-container
+ image: nginx:latest
+ ports:
+ - containerPort: 80
+```
+
+### View a Resource
+
+
+
+### Update a Resource
+
+
+
+### Delete a Resource
+
+
+
+---
+
+## Clusters
+
+Devtron Kubernetes Desktop Client allows you to add multiple clusters and manage all of them from your local machine. The **Clusters** module allows you to view CPU and Memory metrics like CPU Capacity, Memory Capacity, and much more.
+
+
+
+### Perform Node Operations
+
+You can perform node operations such as [Cordon](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_cordon/), [Drain](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_drain/), and [Taints](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) either from the (⋮) icon displayed against the cluster name or by clicking the cluster itself.
+
+
+
+
+
+### Access Cluster Terminal
+
+At any time, you can debug and troubleshoot any issues in your cluster using the Cluster Terminal. You can access the Cluster Terminal by either clicking **Terminal** option in the Overview page or by clicking the cluster and then clicking the **Debug** option. The same Cluster Terminal will be opened irrespective of the option that you choose.
+
+
+
+
+
+---
+
+## Upgrade Devtron Kubernetes Desktop Client
+To upgrade your Devtron Kubernetes Desktop Client, run the following command in your terminal. The Devtron Kubernetes Desktop Client will automatically be stopped, and the downloaded latest executable file will be opened in the default browser.
+
+```bash
+sh devtron-install.bash upgrade
+```
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/install/install-devtron-in-airgapped-environment.md b/versioned_docs/version-1.7/setup/install/install-devtron-in-airgapped-environment.md
new file mode 100755
index 0000000000..11ff55d4f8
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/install-devtron-in-airgapped-environment.md
@@ -0,0 +1,319 @@
+---
+id: install-devtron-in-airgapped-environment
+title: Devtron Installation in an Airgapped Environment
+sidebar_label: Devtron Installation in an Airgapped Environment
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Devtron Installation in an Airgapped Environment
+
+## Introduction
+
+In certain scenarios, you may need to deploy Devtron to a Kubernetes cluster that isn’t connected to the internet. Such air-gapped environments are used for various reasons, particularly in industries with strict regulatory requirements like healthcare, banking, and finance. This is because air-gapped environments aren't exposed to the public internet; therefore, they create a controlled and secure space for handling sensitive data and operations.
+
+:::success
+Try Devtron Freemium to access all the enterprise features for free and forever, limited to adding one additional cluster. [Install Devtron Freemium](https://license.devtron.ai/dashboard)
+
+:::
+
+:::warning Prerequisites
+1. Install `podman` or `docker` on the VM from where you're executing the installation commands.
+
+2. Get the latest image file
+
+```bash
+curl -LO https://raw.githubusercontent.com/devtron-labs/devtron/refs/heads/main/devtron-images.txt.source
+```
+
+3. Set the values of `TARGET_REGISTRY`, `TARGET_REGISTRY_USERNAME`, and `TARGET_REGISTRY_TOKEN`. This registry should be accessible from the VM where you are running the cloning script and the K8s cluster where you’re installing Devtron.
+
+If you are using Docker, the TARGET_REGISTRY should be in the format `docker.io/`
+
+:::
+
+---
+
+## Docker Instructions
+
+### Platform Selection
+
+#### For Linux/amd64
+
+```bash
+export PLATFORM="linux/amd64"
+```
+
+#### For Linux/arm64
+
+```bash
+export PLATFORM="linux/arm64"
+```
+
+1. Set the environment variables
+
+ ```bash
+ # Set the source registry URL
+ export SOURCE_REGISTRY="quay.io/devtron"
+
+ # Set the target registry URL, username, and token/password
+ export TARGET_REGISTRY=""
+ export TARGET_REGISTRY_USERNAME=""
+ export TARGET_REGISTRY_TOKEN=""
+
+ # Set the source and target image file names with default values if not already set
+ SOURCE_IMAGES_LIST="${SOURCE_IMAGES_LIST:=devtron-images.txt.source}"
+ TARGET_IMAGES_LIST="${TARGET_IMAGES_LIST:=devtron-images.txt.target}"
+ ```
+
+2. Log in to the target Docker registry
+
+ ```bash
+ docker login -u $TARGET_REGISTRY_USERNAME -p $TARGET_REGISTRY_TOKEN $TARGET_REGISTRY
+ ```
+
+3. Clone the images
+
+ ```bash
+ while IFS= read -r source_image; do
+ # Check if the source image belongs to the quay.io/devtron registry
+ if [[ "$source_image" == quay.io/devtron/* ]]; then
+ # Replace the source registry with the target registry in the image name
+ target_image="${source_image/quay.io\/devtron/$TARGET_REGISTRY}"
+
+ # Check if the source image belongs to the quay.io/argoproj registry
+ elif [[ "$source_image" == quay.io/argoproj/* ]]; then
+ # Replace the source registry with the target registry in the image name
+ target_image="${source_image/quay.io\/argoproj/$TARGET_REGISTRY}"
+
+ # Check if the source image belongs to the public.ecr.aws/docker/library registry
+ elif [[ "$source_image" == public.ecr.aws/docker/library/* ]]; then
+ # Replace the source registry with the target registry in the image name
+ target_image="${source_image/public.ecr.aws\/docker\/library/$TARGET_REGISTRY}"
+ fi
+
+ # Pull the image from the source registry
+ docker pull --platform $PLATFORM $source_image
+
+ # Tag the image with the new target registry name
+ docker tag $source_image $target_image
+
+ # Push the image to the target registry
+ docker push $target_image
+
+ # Output the updated image name
+ echo "Updated image: $target_image"
+
+ # Append the new image name to the target image file
+ echo "$target_image" >> "$TARGET_IMAGES_LIST"
+
+ done < "$SOURCE_IMAGES_LIST"
+ ```
+---
+
+## Podman Instructions
+
+### For Multi-arch
+
+1. Set the environment variables
+
+ ```bash
+ export SOURCE_REGISTRY="quay.io/devtron"
+ export SOURCE_REGISTRY_TOKEN=#Enter token provided by Devtron team
+ export TARGET_REGISTRY=#Enter target registry url
+ export TARGET_REGISTRY_USERNAME=#Enter target registry username
+ export TARGET_REGISTRY_TOKEN=#Enter target registry token/password
+ ```
+
+2. Log in to the target Podman registry
+
+ ```bash
+ podman login -u $TARGET_REGISTRY_USERNAME -p $TARGET_REGISTRY_TOKEN $TARGET_REGISTRY
+ ```
+
+3. Clone the images
+
+ ```bash
+ SOURCE_REGISTRY="quay.io/devtron"
+ TARGET_REGISTRY=${TARGET_REGISTRY}
+ SOURCE_IMAGES_FILE_NAME="${SOURCE_IMAGES_FILE_NAME:=devtron-images.txt.source}"
+ TARGET_IMAGES_FILE_NAME="${TARGET_IMAGES_FILE_NAME:=devtron-images.txt.target}"
+
+ cp $SOURCE_IMAGES_FILE_NAME $TARGET_IMAGES_FILE_NAME
+ while read source_image; do
+ if [[ "$source_image" == *"workflow-controller:"* || "$source_image" == *"argoexec:"* || "$source_image" == *"argocd:"* ]]
+ then
+ SOURCE_REGISTRY="quay.io/argoproj"
+ sed -i "s|${SOURCE_REGISTRY}|${TARGET_REGISTRY}|g" $TARGET_IMAGES_FILE_NAME
+ elif [[ "$source_image" == *"redis:"* ]]
+ then
+ SOURCE_REGISTRY="public.ecr.aws/docker/library"
+ sed -i "s|${SOURCE_REGISTRY}|${TARGET_REGISTRY}|g" $TARGET_IMAGES_FILE_NAME
+ else
+ SOURCE_REGISTRY="quay.io/devtron"
+ sed -i "s|${SOURCE_REGISTRY}|${TARGET_REGISTRY}|g" $TARGET_IMAGES_FILE_NAME
+ fi
+ done <$SOURCE_IMAGES_FILE_NAME
+ echo "Target Images file finalized"
+
+ while read -r -u 3 source_image && read -r -u 4 target_image ; do
+ echo "Pushing $source_image $target_image"
+ podman manifest create $source_image
+ podman manifest add $source_image $source_image --all
+ podman manifest push $source_image $target_image --all
+ done 3<"$SOURCE_IMAGES_FILE_NAME" 4<"$TARGET_IMAGES_FILE_NAME"
+ ```
+
+---
+
+## Devtron Installation
+
+Before starting, ensure you have created an image pull secret for your registry if authentication is required.
+
+1. Create the namespace (if not already created)
+ ```bash
+ kubectl create ns devtroncd
+ ```
+
+2. Create the Docker registry secret
+ ```bash
+ kubectl create secret docker-registry devtron-imagepull \
+ --namespace devtroncd \
+ --docker-server=$TARGET_REGISTRY \
+ --docker-username=$TARGET_REGISTRY_USERNAME \
+ --docker-password=$TARGET_REGISTRY_TOKEN
+ ```
+ If you are installing Devtron with the CI/CD module or using Argo CD, create the secret in the following namespaces else, you can skip this step-:
+ ```bash
+ kubectl create secret docker-registry devtron-imagepull \
+ --namespace devtron-cd \
+ --docker-server=$TARGET_REGISTRY \
+ --docker-username=$TARGET_REGISTRY_USERNAME \
+ --docker-password=$TARGET_REGISTRY_TOKEN
+ kubectl create secret docker-registry devtron-imagepull \
+ --namespace devtron-ci \
+ --docker-server=$TARGET_REGISTRY \
+ --docker-username=$TARGET_REGISTRY_USERNAME \
+ --docker-password=$TARGET_REGISTRY_TOKEN
+ kubectl create secret docker-registry devtron-imagepull \
+ --namespace argo \
+ --docker-server=$TARGET_REGISTRY \
+ --docker-username=$TARGET_REGISTRY_USERNAME \
+ --docker-password=$TARGET_REGISTRY_TOKEN
+ ```
+
+### Get the Latest Devtron Helm Chart
+
+``` bash
+helm pull devtron-operator --repo http://helm.devtron.ai
+```
+This would download the tar file of the devtron-operator chart, Make sure to replace the `` in the installation commands with this file name.
+
+### Installation Commands
+
+
+
+
+
+Use the below command to install Devtron without any integrations:
+
+1. Without `imagePullSecrets`:
+ ```bash
+ helm install devtron -n devtroncd --set global.containerRegistry="$TARGET_REGISTRY" --set-string components.devtron.customOverrides.IS_AIR_GAP_ENVIRONMENT=true
+ ```
+
+2. With `imagePullSecrets`:
+ ```bash
+ helm install devtron -n devtroncd --set global.containerRegistry="$TARGET_REGISTRY" --set global.imagePullSecrets[0].name=devtron-imagepull --set-string components.devtron.customOverrides.IS_AIR_GAP_ENVIRONMENT=true
+ ```
+
+
+
+
+
+Use the below command to install Devtron with only the CI/CD module
+
+1. Without `imagePullSecrets`:
+ ```bash
+ helm install devtron -n devtroncd --set installer.modules={cicd} --set global.containerRegistry="$TARGET_REGISTRY" --set-string components.devtron.customOverrides.IS_AIR_GAP_ENVIRONMENT=true
+ ```
+
+2. With `imagePullSecrets`:
+ ```bash
+ helm install devtron -n devtroncd --set installer.modules={cicd} --set global.containerRegistry="$TARGET_REGISTRY" --set global.imagePullSecrets[0].name=devtron-imagepull --set-string components.devtron.customOverrides.IS_AIR_GAP_ENVIRONMENT=true
+ ```
+
+
+
+
+
+Use the below command to install Devtron with the CI/CD module and Argo CD
+
+1. Without `imagePullSecrets`:
+ ```bash
+ helm install devtron --create-namespace -n devtroncd --set installer.modules={cicd} --set argo-cd.enabled=true --set global.containerRegistry="$TARGET_REGISTRY" --set argo-cd.global.image.repository="${TARGET_REGISTRY}/argocd" --set argo-cd.redis.image.repository="${TARGET_REGISTRY}/redis" --set-string components.devtron.customOverrides.IS_AIR_GAP_ENVIRONMENT=true
+ ```
+
+2. With `imagePullSecrets`:
+ ```bash
+ helm install devtron --create-namespace -n devtroncd --set installer.modules={cicd} --set argo-cd.enabled=true --set global.containerRegistry="$TARGET_REGISTRY" --set argo-cd.global.image.repository="${TARGET_REGISTRY}/argocd" --set argo-cd.redis.image.repository="${TARGET_REGISTRY}/redis" --set global.imagePullSecrets[0].name=devtron-imagepull --set-string components.devtron.customOverrides.IS_AIR_GAP_ENVIRONMENT=true
+ ```
+
+
+
+
+
+---
+
+### Devtron Dashboard
+
+Run the following command to get the Devtron dashboard URL:
+
+```bash
+kubectl get svc -n devtroncd devtron-service \
+-o jsonpath='{.status.loadBalancer.ingress}'
+```
+
+You will get an output similar to the example shown below:
+
+```bash
+[map[hostname:aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com]]
+```
+
+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.
+
+| Host | Type | Points to |
+| :--- | :--- | :--- |
+| devtron.yourdomain.com | CNAME | aaff16e9760594a92afa0140dbfd99f7-305259315.us-east-1.elb.amazonaws.com |
+
+---
+
+### Devtron Admin Credentials
+
+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.
+
+**Username**: `admin`
+**Password**: Run the following command to get the admin password:
+
+```bash
+kubectl -n devtroncd get secret devtron-secret \
+-o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+:::info Next Recommended Action
+When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
+
+After the initial login, we recommend you set up any [Single Sign-On (SSO)](../../user-guide/global-configurations/sso-login.md) service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (e.g., GitHub) to log in to the Dashboard.
+
+:::
+
+:::info
+If you have questions, please let us know on our discord channel. [](https://discord.gg/jsRG5qx2gp)
+
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/install/install-devtron.md b/versioned_docs/version-1.7/setup/install/install-devtron.md
new file mode 100755
index 0000000000..251bac4bdc
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/install-devtron.md
@@ -0,0 +1,41 @@
+---
+hidden: true
+hide_table_of_contents: true
+---
+
+# Get Admin Credentials
+
+:::info Note
+Refer [Install Devtron](./README.md) to know the available tiers and installation options.
+:::
+
+## Using Own Kubernetes Cluster?
+
+When Devtron is installed on your own Kubernetes cluster, it creates a default admin user and password (with unrestricted access to Devtron). You can use that credentials to log in as an administrator.
+
+**Username**: `admin`
+**Password**: Run the following command to get the admin password:
+
+```bash
+kubectl -n devtroncd get secret devtron-secret \
+-o jsonpath='{.data.ADMIN_PASSWORD}' | base64 -d
+```
+
+---
+
+## Using Devtron Cloud (SaaS)?
+
+If you are using the 30-day trial version of [Devtron Cloud (SaaS)](../install/devtron-freemium.md#option-3-devtron-cloud-saas), follow the steps below to get the credentials.
+
+1. Go to [Devtron's License Dashboard](https://license.devtron.ai/dashboard/) and sign in using SSO or registered email address used at the time of installation.
+
+2. Once logged in, the Devtron License Dashboard will show your existing license. Below the license, you will find the Dashboard URL and login password (username will be `admin`).
+
+ 
+
Figure 1: License Page
+
+:::info Next Recommended Action
+When you install Devtron for the first time, it creates a default admin user and password (with unrestricted access to Devtron). You can use it to log in as an administrator.
+
+After the initial login, we recommend you set up any [Single Sign-On (SSO)](../../user-guide/global-configurations/sso-login.md) service like Google, GitHub, etc., and then add other users (including yourself). Subsequently, all the users can use the same SSO (e.g., GitHub) to log in to the Dashboard.
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/install/installation-configuration.md b/versioned_docs/version-1.7/setup/install/installation-configuration.md
new file mode 100755
index 0000000000..2bc09350bf
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/installation-configuration.md
@@ -0,0 +1,511 @@
+---
+id: installation-configuration
+title: Installation Configuration
+sidebar_label: Installation Configuration
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Installation Configuration
+
+## Configure Secrets
+
+For `Helm` installation this section refers to _**secrets**_ section of `values.yaml`.
+
+Configure the following properties:
+
+| Parameter | Description | Default |
+| :--- | :--- | :--- |
+| **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 |
+
+## Configure ConfigMaps
+
+For `Helm` installation this section refers to _**configs**_ section of `values.yaml`.
+
+Configure the following properties:
+
+| Parameter | Description | Default |
+| :--- | :--- | :--- |
+| **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](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/) | 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 |
+
+## Configure Resources
+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`.
+
+## Configure Overrides
+
+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:
+
+| Parameter | Description | Default |
+| :--- | :--- | :--- |
+| **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 |
+
+### Storage for Logs and Cache
+
+#### `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.
+
+| Parameter | Description | Default |
+| :--- | :--- | :--- |
+| **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. | |
+
+
+The below parameters are to be used in the Secrets :
+
+| Parameter | Description |
+| :--- | :--- |
+| **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 SPECIFIC`
+
+While installing Devtron using Azure Blob Storage for storing logs and caches, the below parameters will be used in the ConfigMap.
+
+| Parameter | Description |
+| :--- | :--- |
+| **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 | |
+
+#### `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.
+
+| Parameter | Description | Default |
+| :--- | :--- | :--- |
+| **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 | |
+
+
+To convert string to base64 use the following command:
+
+```bash
+echo -n "string" | base64
+```
+
+> **Note**:
+> 1. 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.
+> 2. Ensure that the cluster has **read access** to AWS secrets backends \(SSM & secrets manager\).
+
+---
+
+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 [values.yaml](https://github.com/devtron-labs/charts/blob/main/charts/devtron/values.yaml) file.
+
+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:
+
+```bash
+helm install devtron devtron/devtron-operator --create-namespace --namespace devtroncd \
+--set secrets.POSTGRESQL_PASSWORD=change-me \
+--set configs.BLOB_STORAGE_PROVIDER=S3
+```
+
+## Configuration of Blob Storage
+
+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 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.
+
+```bash
+helm repo update
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--reuse-values \
+--set installer.modules={cicd} \
+--set minio.enabled=true
+```
+
+
+
+
+Use the following command to configure AWS S3 bucket for storing build logs and cache. Refer to the `AWS specific` parameters on the [Storage for Logs and Cache](#aws-specific) page.
+
+* **Configure 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 the below command.
+
+```bash
+helm repo update
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--reuse-values \
+--set installer.modules={cicd} \
+--set configs.BLOB_STORAGE_PROVIDER=S3 \
+--set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
+--set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1
+```
+
+* **Configure using access-key and secret-key for aws S3 authentication:**
+
+```bash
+helm repo update
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--reuse-values \
+--set installer.modules={cicd} \
+--set configs.BLOB_STORAGE_PROVIDER=S3 \
+--set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
+--set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1 \
+--set secrets.BLOB_STORAGE_S3_ACCESS_KEY= \
+--set secrets.BLOB_STORAGE_S3_SECRET_KEY=
+```
+
+* **Configure using S3 compatible storages:**
+
+```bash
+helm repo update
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--reuse-values \
+--set installer.modules={cicd} \
+--set configs.BLOB_STORAGE_PROVIDER=S3 \
+--set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
+--set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1 \
+--set secrets.BLOB_STORAGE_S3_ACCESS_KEY= \
+--set secrets.BLOB_STORAGE_S3_SECRET_KEY= \
+--set configs.BLOB_STORAGE_S3_ENDPOINT=
+```
+
+
+
+
+Use the following command to configure Azure Blob Storage for storing build logs and cache.
+Refer to the `Azure specific` parameters on the [Storage for Logs and Cache](#azure-specific) page.
+
+```bash
+helm repo update
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--reuse-values \
+--set installer.modules={cicd} \
+--set secrets.AZURE_ACCOUNT_KEY=xxxxxxxxxx \
+--set configs.BLOB_STORAGE_PROVIDER=AZURE \
+--set configs.AZURE_ACCOUNT_NAME=test-account \
+--set configs.AZURE_BLOB_CONTAINER_CI_LOG=ci-log-container \
+--set configs.AZURE_BLOB_CONTAINER_CI_CACHE=ci-cache-container
+```
+
+
+
+
+Use the following command to configure Google Cloud Storage for storing build logs and cache.
+Refer to the `Google Cloud specific` parameters on the [Storage for Logs and Cache](#google-cloud-storage-specific) page.
+
+```bash
+helm repo update
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--reuse-values \
+--set installer.modules={cicd} \
+--set configs.BLOB_STORAGE_PROVIDER=GCP \
+--set secrets.BLOB_STORAGE_GCP_CREDENTIALS_JSON=eyJ0eXBlIjogInNlcnZpY2VfYWNjb3VudCIsInByb2plY3RfaWQiOiAiPHlvdXItcHJvamVjdC1pZD4iLCJwcml2YXRlX2tleV9pZCI6ICI8eW91ci1wcml2YXRlLWtleS1pZD4iLCJwcml2YXRlX2tleSI6ICI8eW91ci1wcml2YXRlLWtleT4iLCJjbGllbnRfZW1haWwiOiAiPHlvdXItY2xpZW50LWVtYWlsPiIsImNsaWVudF9pZCI6ICI8eW91ci1jbGllbnQtaWQ+IiwiYXV0aF91cmkiOiAiaHR0cHM6Ly9hY2NvdW50cy5nb29nbGUuY29tL28vb2F1dGgyL2F1dGgiLCJ0b2tlbl91cmkiOiAiaHR0cHM6Ly9vYXV0aDIuZ29vZ2xlYXBpcy5jb20vdG9rZW4iLCJhdXRoX3Byb3ZpZGVyX3g1MDlfY2VydF91cmwiOiAiaHR0cHM6Ly93d3cuZ29vZ2xlYXBpcy5jb20vb2F1dGgyL3YxL2NlcnRzIiwiY2xpZW50X3g1MDlfY2VydF91cmwiOiAiPHlvdXItY2xpZW50LWNlcnQtdXJsPiJ9Cg== \
+--set configs.DEFAULT_CACHE_BUCKET=cache-bucket \
+--set configs.DEFAULT_BUILD_LOGS_BUCKET=log-bucket
+```
+
+
+
+
+Use the following command to configure S3-compatible storage (e.g., Longhorn) for storing build logs and cache.
+
+```bash
+helm repo update
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+--reuse-values \
+--set configs.BLOB_STORAGE_PROVIDER=S3 \
+--set configs.DEFAULT_CACHE_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CACHE_BUCKET_REGION=us-east-1 \
+--set configs.DEFAULT_BUILD_LOGS_BUCKET=demo-s3-bucket \
+--set configs.DEFAULT_CD_LOGS_BUCKET_REGION=us-east-1 \
+--set secrets.BLOB_STORAGE_S3_ACCESS_KEY= \
+--set secrets.BLOB_STORAGE_S3_SECRET_KEY= \
+--set configs.BLOB_STORAGE_S3_ENDPOINT=
+```
+
+
+
+
+---
+
+## Configuring NodeSelectors and Tolerations
+
+### Adding Custom Configurations
+
+When installing Devtron, you can specify `nodeSelectors` and `tolerations` to fine-tune your deployment. These configurations can be added using either additional `--set` flags or a separate `values.yaml` file.
+
+### Global vs. Component-level Configurations
+
+* **Global Configurations**: When specified at the global level, these settings apply to all Devtron microservices, except for ArgoCD.
+* **Component-Level Configurations**: You can also apply these settings to specific components individually.
+* **Priority**: If a configuration is specified at both the global and component levels, the component-level setting takes precedence for that particular component.
+
+### Using `--set` Flags
+
+You can use the `--set` flag to specify individual values directly in the Helm command.
+
+
+1. **nodeSelector**
+
+To set a nodeSelector:
+
+```bash
+helm install devtron devtron/devtron-operator \
+ --create-namespace --namespace devtroncd \
+ --set global.nodeSelector."kubernetes\.io/hostname"=node1
+```
+
+This example sets the nodeSelector to schedule pods on a node with the hostname "node1".
+
+
+2. **Tolerations**
+
+To set tolerations:
+
+```bash
+helm install devtron devtron/devtron-operator \
+ --create-namespace --namespace devtroncd \
+ --set global.tolerations[0].key=example-key \
+ --set global.tolerations[0].operator=Exists \
+ --set global.tolerations[0].effect=NoSchedule \
+ --set global.tolerations[0].value=value1
+```
+
+This example adds a tolerance for pods to be scheduled on nodes with the taint "example-key".
+
+
+### Using `values.yaml`
+
+In the values.yaml file of devtron chart, set the values of the following fields:
+
+```yaml
+global:
+ nodeSelector:
+ kubernetes.io/hostname: node1 # For nodeSelector
+ tolerations:
+ - key: example-key # For tolerations
+ operator: Exists
+ value: "value1"
+ effect: NoSchedule
+```
+
+---
+
+## Set StorageClass for Devtron Microservices
+
+You can specify a StorageClass to be used by Devtron microservices' Persistent Volume Claims (PVCs) if a default StorageClass is not already configured in your cluster.
+
+### Checking for a Default StorageClass
+
+To check if your cluster has a default StorageClass, run:
+
+```bash
+kubectl get sc
+```
+
+This command will list all available StorageClasses in your cluster, including the default storage class set (if any). The default StorageClass (if any) can be identified by the (default) label next to its name.
+
+### Setting a Default StorageClass
+
+If no StorageClass class is set as default, you can set one using the following command:
+
+```bash
+kubectl patch storageclass -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}
+```
+
+Or, if you do not want to change the default StorageClass or prefer to use a different StorageClass for Devtron microservices, specify it during installation using the `--set` flag:
+
+```bash
+helm install devtron devtron/devtron-operator \
+ --create-namespace --namespace devtroncd \
+ --set global.storageClass="" # set your preferred StorageClass
+```
+
+Alternatively, you can specify the StorageClass in the values.yaml file by modifying the [following line in values.yaml](https://github.com/devtron-labs/devtron/blob/main/charts/devtron/values.yaml#L23).
+
+---
+
+## Configure External PostgreSQL Database
+
+You can configure Devtron to use an external PostgreSQL database (e.g., Amazon RDS, Google Cloud SQL, Azure PostgreSQL) instead of the default internal database.
+
+### Prerequisites
+
+* An external PostgreSQL server that is running and accessible
+* PostgreSQL version must be 14
+* The username Devtron uses to connect with PostgreSQL must be `postgres`
+* Network connectivity between Devtron and PostgreSQL server
+* DNS mapping must be completed for your PostgreSQL server
+
+### Database Setup
+
+Before installing Devtron, create the following databases on your external PostgreSQL server.
+
+1. **orchestrator** - Main Devtron orchestration database
+2. **lens** - Lens service database
+3. **git_sensor** - Git sensor service database
+4. **casbin** - Authorization and policy database
+5. **clairv4** - (*Optional*) Required only if you are using [Clair](../../user-guide/integrations/vulnerability-scanning/clair.md) for image scanning instead of [Trivy](../../user-guide/integrations/vulnerability-scanning/trivy.md)
+
+:::warning Not sure how to create a PostgreSQL database?
+Here’s how you can create databases using popular providers:
+* [Amazon RDS instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html)
+* [Google Cloud SQL for PostgreSQL](https://cloud.google.com/sql/docs/postgres/create-instance#create-2nd-gen)
+* [Azure Database for PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/quickstart-create-server)
+:::
+
+#### Database Creation Commands
+
+Connect to your PostgreSQL server as the `postgres` user and run the following commands:
+
+```sql
+-- Connect as postgres user
+CREATE DATABASE orchestrator;
+CREATE DATABASE lens;
+CREATE DATABASE git_sensor;
+CREATE DATABASE casbin;
+
+-- Optional: Only if using Clair for image scanning
+CREATE DATABASE clairv4;
+```
+
+### Devtron Configuration for External DB
+
+:::warning Note
+Ensure the [required databases](#database-creation-commands) exist before proceeding.
+:::
+
+When installing Devtron, you can specify your external PostgreSQL by using either of the following:
+* Updating `values.yaml` file
+* Passing `--set` flags during Helm installation
+
+#### Using `values.yaml` file
+
+You can specify the following parameters in your Devtron [values.yaml](https://github.com/devtron-labs/devtron/blob/main/charts/devtron/values.yaml#L12):
+
+```yaml
+externalPostgres:
+ enabled: true
+ # Password for the postgres user
+ PG_PASSWORD: "your_postgres_password"
+ # DNS endpoint of your PostgreSQL server
+ PG_ADDR: "your.postgres.endpoint"
+```
+
+#### Using `--set` flags
+
+You can use the following `--set` flags when installing Devtron with Helm:
+
+```bash
+helm install devtron devtron/devtron-operator \
+ --set global.externalPostgres.enabled=true \
+ --set global.externalPostgres.PG_PASSWORD="your_postgres_password" \
+ --set global.externalPostgres.PG_ADDR="your.postgres.endpoint"
+```
+
+#### Example
+
+```bash
+helm install devtron devtron/devtron-operator \
+ --set global.externalPostgres.enabled=true \
+ --set global.externalPostgres.PG_PASSWORD="mySecurePassword123" \
+ --set global.externalPostgres.PG_ADDR="postgres.example.com"
+```
+
+---
+
+## Secrets
+
+|Parameter | Description| Default| Necessity|
+|-|-|-|-|
+|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|
+
+## ConfigMaps
+
+|Parameter | Description| Default| Necessity|
+|-|-|-|-|
+|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|
+
+## Dashboard Configurations
+
+```bash
+RECOMMEND_SECURITY_SCANNING=false
+FORCE_SECURITY_SCANNING=false
+HIDE_DISCORD=false
+```
+
+|Parameter | Description|
+|-|-|
+|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.|
diff --git a/versioned_docs/version-1.7/setup/install/override-default-devtron-installation-configs.md b/versioned_docs/version-1.7/setup/install/override-default-devtron-installation-configs.md
new file mode 100755
index 0000000000..690bb8df71
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/override-default-devtron-installation-configs.md
@@ -0,0 +1,91 @@
+---
+id: override-default-devtron-installation-configs
+title: Override Default Configurations of Devtron Installation
+sidebar_label: Override Default Configurations of Devtron Installation
+---
+
+# Override Default Configurations of Devtron Installation
+
+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](https://github.com/devtron-labs/devtron/tree/main/manifests/updates) directory.
+
+To modify a particular object, it looks in namespace `devtroncd` for the corresponding configmap as mentioned in the mapping below:
+
+|component| configmap name| purpose|
+|-|-|-|
+|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](https://github.com/devtron-labs/devtron/tree/main/manifests/updates/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](https://github.com/devtron-labs/devtron/blob/main/manifests/updates/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:
+
+```bash
+kubectl apply -f file-name -n devtroncd
+```
+
+Run the following command to make these changes take effect:
+
+```bash
+kubectl patch -n devtroncd installer installer-devtron --type='json' -p='[{"op": "add", "path": "/spec/reSync", "value": true }]'
+```
+
+Our changes would have been propagated to Devtron after 20-30 minutes.
+
+## Recommended Resources for Production use
+
+To use Devtron for production deployments, use our recommended production overrides located in [manifests/updates/production](https://github.com/devtron-labs/devtron/tree/main/manifests/updates/production). This configuration should be enough for handling up to 200 microservices.
+
+The overall resources required for the recommended production overrides are:
+
+|Name| Value|
+|-|-|
+|cpu| 6|
+|memory|13GB|
+
+The production overrides can be applied as `pre-devtron installation` as well as `post-devtron installation` in the respective namespace.
+
+### Pre-Devtron Installation
+
+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:
+
+```bash
+kubectl create ns devtroncd
+```
+
+After files are applied, you are ready to install your Devtron instance with production-ready resources.
+
+### Post-Devtron Installation
+
+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.
+
+```bash
+kubectl apply -f prod-configs -n devtroncd
+```
diff --git a/versioned_docs/version-1.7/setup/install/prod-infra.md b/versioned_docs/version-1.7/setup/install/prod-infra.md
new file mode 100755
index 0000000000..40593e1ca0
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/prod-infra.md
@@ -0,0 +1,101 @@
+---
+id: prod-infra
+title: Production Infra Recommendations
+sidebar_label: Production Infra Recommendations
+---
+
+# Production Infra Recommendations
+
+## 1. Infrastructure Overview
+
+For production environments, we recommend a dedicated infrastructure setup that separates Devtron microservices to ensure optimal performance, reliability, and cost efficiency.
+
+### Node Group Structure
+
+Set up separate node groups to isolate workloads, optimize resource allocation, and ensure system stability under production load.
+
+| Node Group | Purpose | Instance Type | Configuration |
+|------------|---------|--------------|---------------|
+| **Devtron Microservices** | Hosts all Devtron core components | On-Demand | 3 nodes (4 CPU, 16 GB RAM each) |
+| **CI Workers** | Handles build jobs and CI processes | Spot Instances | Auto-scaling based on workload |
+
+
+### Autoscaling Configuration
+
+Configure autoscaling to handle fluctuating workloads efficiently, reduce downtime, and control cloud costs without manual intervention.
+
+* **Devtron Node Group**: Minimum 1 node, Maximum 5 nodes (Autoscaled)
+* **CI Node Group** (Tainted): Configure based on build volume and concurrency requirements
+
+
+### Blob Storage
+
+Use blob storage to persist build caches and logs, enabling faster builds and reliable CI troubleshooting in production environments. Refer [Blob Storage Guide](./installation-configuration.md#configuration-of-blob-storage) to know more.
+
+* **Cache-Storage**: Used to store the build cache to reduce build time of your application.
+* **CI Logs Bucket**: Used to store the build logs of your application.
+
+---
+
+## 2. Cloud-Specific Setup Guidelines
+
+Depending on your choice of cloud provider, refer the instructions/scripts below to set up a cluster.
+
+### AWS (EKS)
+You can follow this [Readme](https://github.com/devtron-labs/utilities/tree/main/eksctl-configs#creating-a-cluster-for-devtron-setup) for setting up the EKS cluster for Devtron.
+
+
+### GCP (GKE)
+Use our provided [Terraform scripts](https://github.com/devtron-labs/utilities/tree/main/terraform/terraform-gke) to set up GKE cluster for Devtron.
+
+
+### Azure (AKS)
+Use our provided [Terraform scripts](https://github.com/devtron-labs/utilities/tree/main/terraform/terraform-aks) to set up AKS cluster for Devtron.
+
+:::success Next Step
+Proceed with the [Devtron installation on your cluster](../install/devtron-oss.md).
+:::
+
+---
+
+## 3. Microservice Resource Recommendations
+
+Below are the core components (Devtron microservices) for which you need to allocate appropriate CPU and memory resources. This will ensure optimum performance and prevent resource contention in production.
+
+| Component | CPU Requests | CPU Limits | Memory Requests | Memory Limits |
+|-----------|--------------|------------|-----------------|---------------|
+| **Devtron** | 1 | 1 | 1536Mi | 1536Mi |
+| **Kubelink** | 1 | 1 | 1536Mi | 1536Mi |
+| **Dashboard** | 100m | 100m | 150Mi | 150Mi |
+| **Lens** | 200m | 200m | 100Mi | 100Mi |
+| **Git-sensor** | 800m | 1 | 1510Mi | 1510Mi |
+| **Kubewatch** | 200m | 300m | 600Mi | 1000Mi |
+
+
+:::info Need a YAML template to add resources?
+You can create a resources file similar to this [YAML file](https://github.com/devtron-labs/devtron/blob/main/charts/devtron/resources-small.yaml) and add resources according to your load and requirements for any service you want, and remove those you don’t wish to modify.
+
+Run the following command once the file is ready:
+
+```bash
+helm upgrade devtron devtron/devtron-operator -n devtroncd --reuse-values -f resources-values-file.yaml
+```
+
+:::
+
+---
+
+## 4. Kubernetes Configuration
+
+### CI Isolation with Taints and Tolerations
+
+To ensure CI workloads run exclusively on the dedicated CI nodes, you need to specify the taints and labels to the node. Then, for the CI build pods, you can add the tolerations and node selectors in the `devtron-custom-cm` (ConfigMap) of `devtroncd` namespace using [these keys](./installation-configuration.md#configure-overrides). These will automatically propagate to CI workloads when they are created.
+
+If you are following our [Cloud-Specific Setup Guidelines](#2-cloud-specific-setup-guidelines) then set the below values for the keys in `devtron-custom-cm`:
+
+
+``` bash
+CI_NODE_LABEL_SELECTOR: purpose=ci
+CI_NODE_TAINTS_KEY: dedicated
+CI_NODE_TAINTS_VALUE: ci
+```
diff --git a/versioned_docs/version-1.7/setup/install/uninstall-devtron.md b/versioned_docs/version-1.7/setup/install/uninstall-devtron.md
new file mode 100755
index 0000000000..5eeb2c1c9f
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/install/uninstall-devtron.md
@@ -0,0 +1,26 @@
+---
+id: uninstall-devtron
+title: Uninstall Devtron
+sidebar_label: Uninstall Devtron
+hide_table_of_contents: true
+---
+
+# Uninstall Devtron
+
+To uninstall Devtron, run the following command:
+
+This command will remove all the namespaces related to Devtron (`devtroncd`, `devtron-cd`, `devtron-ci` etc.).
+
+```bash
+helm uninstall devtron --namespace devtroncd
+
+kubectl delete -n devtroncd -f https://raw.githubusercontent.com/devtron-labs/charts/main/charts/devtron/crds/crd-devtron.yaml
+
+kubectl delete -n argo -f https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/yamls/workflow.yaml
+
+kubectl delete ns devtroncd devtron-cd devtron-ci devtron-demo argo
+
+```
+
+
+**Note**: If you have questions, please let us know on our discord channel. [](https://discord.gg/jsRG5qx2gp)
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/start-using.md b/versioned_docs/version-1.7/setup/start-using.md
new file mode 100755
index 0000000000..081f7044bb
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/start-using.md
@@ -0,0 +1,24 @@
+---
+id: start-using
+title: Start Using devtron
+sidebar_label: Start Using devtron
+---
+
+# Start Using devtron
+
+#### configure docker registry
+
+Please [setup docker registry](../user-guide/global-configurations/container-registries.md) before deploying application.
+
+## Deploying Applications
+
+### deploy spring boot app
+
+Please use [this spring boot app](https://github.com/nishant-d/demo.git) repo for reference and follow steps described in the video
+
+
+
+### deploy helm chart
+
+for deploying helm chart follow [helm chart installation guide](../user-guide/deploy-chart/)
+
diff --git a/versioned_docs/version-1.7/setup/upgrade/README.md b/versioned_docs/version-1.7/setup/upgrade/README.md
new file mode 100755
index 0000000000..62c0b3fb98
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/upgrade/README.md
@@ -0,0 +1,27 @@
+---
+id: README
+title: Devtron Upgrade
+sidebar_label: Devtron Upgrade
+---
+
+# Devtron Upgrade
+
+Devtron can be upgraded in one of the following ways:
+
+## Upgrade Devtron using Helm
+
+**Versions Upgrade**
+
+- [Upgrade to 1.5.0](devtron-upgrade-1.5.0.md)
+- [0.6.x to 0.7.x](devtron-upgrade-0.6.x-0.7.x.md)
+- [0.5.x to 0.6.x](devtron-upgrade-0.5.x-0.6.x.md)
+- [0.4.x to 0.5.x](devtron-upgrade-0.4.x-0.5.x.md)
+- [0.4.x to 0.4.x](devtron-upgrade-0.4.x-0.4.x.md)
+- [0.3.x to 0.4.x](devtron-upgrade-0.3.x-0.4.x.md)
+- [0.3.x to 0.3.x](devtron-upgrade-0.3.x-0.3.x.md)
+- [0.2.x to 0.3.x](devtron-upgrade-0.2.x-0.3.x.md)
+
+## Upgrade Devtron from the UI
+
+- [Update Devtron from Devtron UI](upgrade-devtron-ui.md)
+- [Update Devtron to beta version](devtron-upgrade-to-beta.md)
diff --git a/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.2.x-0.3.x.md b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.2.x-0.3.x.md
new file mode 100755
index 0000000000..f7b80f3be6
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.2.x-0.3.x.md
@@ -0,0 +1,37 @@
+---
+id: devtron-upgrade-0.2.x-0.3.x
+title: Upgrading Devtron 0.2.x to 0.3.x
+sidebar_label: Upgrading Devtron 0.2.x to 0.3.x
+---
+
+# Upgrading Devtron 0.2.x to 0.3.x
+
+## Follow the required steps to update the Devtron version
+
+#### STEP 1
+
+Delete the respective resources i.e, nats-operator , nats-streaming and nats-server using the following commands.
+
+```bash
+kubectl delete -f https://raw.githubusercontent.com/devtron-labs/devtron/v0.2.37/manifests/yamls/nats-operator.yaml
+kubectl -n devtroncd delete -f https://raw.githubusercontent.com/devtron-labs/devtron/v0.2.37/manifests/yamls/nats-streaming.yaml
+kubectl -n devtroncd delete -f https://raw.githubusercontent.com/devtron-labs/devtron/v0.2.37/manifests/yamls/nats-server.yaml
+```
+
+#### STEP 2
+
+Verify the deletion of resources using the following commands.
+
+```bash
+kubectl -n devtroncd get pods
+kubectl -n devtroncd get serviceaccount
+kubectl -n devtroncd get clusterrole
+```
+
+#### STEP 3
+
+Set `reSync: true` in the installer object, this will initiate upgrade of the entire Devtron stack, you can use the following command to do this.
+
+```bash
+kubectl patch -n devtroncd installer installer-devtron --type='json' -p='[{"op": "add", "path": "/spec/reSync", "value": true }]'
+```
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.3.x-0.3.x.md b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.3.x-0.3.x.md
new file mode 100755
index 0000000000..bc47fd7e88
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.3.x-0.3.x.md
@@ -0,0 +1,48 @@
+---
+id: devtron-upgrade-0.3.x-0.3.x
+title: Upgrading Devtron 0.3.x to 0.3.x
+sidebar_label: Upgrading Devtron 0.3.x to 0.3.x
+---
+
+# Upgrading Devtron 0.3.x to 0.3.x
+
+If you want to check the current version of Devtron you are using, please use the following command.
+
+```
+kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
+```
+
+## Upgrade the Devtron version using Helm
+
+1. Fetch the latest Devtron helm chart
+
+```bash
+helm repo update
+```
+
+2. Input the target Devtron version that you want to upgrade to. You can find the latest releases from Devtron on Github https://github.com/devtron-labs/devtron/releases
+
+```bash
+DEVTRON_TARGET_VERSION=v0.3.x
+```
+
+3. Upgrade Devtron
+
+```bash
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd --set installer.release=$DEVTRON_TARGET_VERSION
+```
+
+
+## Upgrade the Devtron version using Kubectl
+
+1. Input the target Devtron version that you want to upgrade to. You can find the latest releases from Devtron on Github https://github.com/devtron-labs/devtron/releases
+
+```bash
+DEVTRON_TARGET_VERSION=v0.3.x
+```
+
+2. Patch Devtron Installer
+
+```bash
+kubectl patch -n devtroncd installer installer-devtron --type='json' -p='[{"op": "add", "path": "/spec/reSync", "value": true },{"op": "replace", "path": "/spec/url", "value": "https://raw.githubusercontent.com/devtron-labs/devtron/'$DEVTRON_TARGET_VERSION'/manifests/installation-script"}]'
+```
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md
new file mode 100755
index 0000000000..2f330a460a
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.3.x-0.4.x.md
@@ -0,0 +1,73 @@
+---
+id: devtron-upgrade-0.3.x-0.4.x
+title: Upgrading Devtron 0.3.x to 0.4.x
+sidebar_label: Upgrading Devtron 0.3.x to 0.4.x
+---
+
+# Upgrading Devtron 0.3.x to 0.4.x
+
+If you want to check the current version of Devtron you are using, please use the following command.
+
+```
+kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
+```
+
+## Upgrade the Devtron version using Helm
+
+### 1. Check the devtron release name
+```bash
+helm list --namespace devtroncd
+```
+
+### 2. Set release name in the variable
+```bash
+RELEASE_NAME=devtron
+```
+
+### 3. Annotate and Label all the Devtron resources
+
+```bash
+kubectl -n devtroncd label all --all "app.kubernetes.io/managed-by=Helm"
+kubectl -n devtroncd annotate all --all "meta.helm.sh/release-name=$RELEASE_NAME" "meta.helm.sh/release-namespace=devtroncd"
+kubectl -n devtroncd label secret --all "app.kubernetes.io/managed-by=Helm"
+kubectl -n devtroncd annotate secret --all "meta.helm.sh/release-name=$RELEASE_NAME" "meta.helm.sh/release-namespace=devtroncd"
+kubectl -n devtroncd label cm --all "app.kubernetes.io/managed-by=Helm"
+kubectl -n devtroncd annotate cm --all "meta.helm.sh/release-name=$RELEASE_NAME" "meta.helm.sh/release-namespace=devtroncd"
+kubectl -n devtroncd label sa --all "app.kubernetes.io/managed-by=Helm"
+kubectl -n devtroncd annotate sa --all "meta.helm.sh/release-name=$RELEASE_NAME" "meta.helm.sh/release-namespace=devtroncd"
+kubectl label clusterrole devtron "app.kubernetes.io/managed-by=Helm"
+kubectl annotate clusterrole devtron "meta.helm.sh/release-name=$RELEASE_NAME" "meta.helm.sh/release-namespace=devtroncd"
+kubectl label clusterrolebinding devtron "app.kubernetes.io/managed-by=Helm"
+kubectl annotate clusterrolebinding devtron "meta.helm.sh/release-name=$RELEASE_NAME" "meta.helm.sh/release-namespace=devtroncd"
+kubectl -n devtroncd label role --all "app.kubernetes.io/managed-by=Helm"
+kubectl -n devtroncd annotate role --all "meta.helm.sh/release-name=$RELEASE_NAME" "meta.helm.sh/release-namespace=devtroncd"
+kubectl -n devtroncd label rolebinding --all "app.kubernetes.io/managed-by=Helm"
+kubectl -n devtroncd annotate rolebinding --all "meta.helm.sh/release-name=$RELEASE_NAME" "meta.helm.sh/release-namespace=devtroncd"
+```
+
+### 4. Fetch the latest Devtron helm chart
+
+```bash
+helm repo update
+```
+
+### 5. Upgrade Devtron
+
+5.1 Upgrade Devtron to latest version
+
+```bash
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+-f https://raw.githubusercontent.com/devtron-labs/devtron/main/charts/devtron/devtron-bom.yaml \
+--set installer.modules={cicd} --reuse-values
+```
+OR
+
+5.2 Upgrade Devtron to a custom version. You can find the latest releases from Devtron on Github https://github.com/devtron-labs/devtron/releases
+
+```bash
+DEVTRON_TARGET_VERSION=v0.4.x
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+-f https://raw.githubusercontent.com/devtron-labs/devtron/$DEVTRON_TARGET_VERSION/charts/devtron/devtron-bom.yaml \
+--set installer.modules={cicd} --reuse-values
+```
diff --git a/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.4.x-0.4.x.md b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.4.x-0.4.x.md
new file mode 100755
index 0000000000..bc5233bae1
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.4.x-0.4.x.md
@@ -0,0 +1,53 @@
+---
+id: devtron-upgrade-0.4.x-0.4.x
+title: Upgrading Devtron 0.4.x to 0.4.x
+sidebar_label: Upgrading Devtron 0.4.x to 0.4.x
+---
+
+# Upgrading Devtron 0.4.x to 0.4.x
+
+If you want to check the current version of Devtron you are using, please use the following command.
+
+```
+kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
+```
+
+## Upgrade the Devtron version using Helm
+
+### 1. Check the devtron release name
+
+```bash
+helm list --namespace devtroncd
+```
+
+### 2. Set release name in the variable
+```bash
+RELEASE_NAME=devtron
+```
+
+### 3. Fetch the latest Devtron helm chart
+
+```bash
+helm repo update
+```
+
+### 4. Upgrade Devtron
+
+4.1 Upgrade Devtron to latest version
+
+```bash
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+-f https://raw.githubusercontent.com/devtron-labs/devtron/main/charts/devtron/devtron-bom.yaml \
+--set installer.modules={cicd} --reuse-values
+```
+OR
+
+4.2 Upgrade Devtron to a custom version. You can find the latest releases from Devtron on Github https://github.com/devtron-labs/devtron/releases
+
+```bash
+DEVTRON_TARGET_VERSION=v0.4.x
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+-f https://raw.githubusercontent.com/devtron-labs/devtron/$DEVTRON_TARGET_VERSION/charts/devtron/devtron-bom.yaml \
+--set installer.modules={cicd} --reuse-values
+```
diff --git a/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.4.x-0.5.x.md b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.4.x-0.5.x.md
new file mode 100755
index 0000000000..b1138f1e6d
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.4.x-0.5.x.md
@@ -0,0 +1,71 @@
+---
+id: devtron-upgrade-0.4.x-0.5.x
+title: Upgrading Devtron 0.4.x to 0.5.x
+sidebar_label: Upgrading Devtron 0.4.x to 0.5.x
+---
+
+# Upgrading Devtron 0.4.x to 0.5.x
+
+If you want to check the current version of Devtron you are using, please use the following command.
+
+```
+kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
+```
+
+## Upgrade the Devtron version using Helm
+
+
+### 1. Apply Prerequisites Patch Job
+
+If you are using rawYaml in deployment template, this update can introduce breaking changes. We recommend you to update the `Chart Version`
+of your app to `v4.13.0` to make rawYaml section compatible to new argocd version `v2.4.0`.
+
+Or
+
+We have released a argocd-v2.4.0 patch job to fix the compatibilities issues. Please apply this job in your cluster and wait for completion
+and then only upgrade to `Devtron v0.5.x`.
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/devtron-labs/utilities/main/scripts/jobs/argocd-2.4.0-prerequisites-patch-job.yaml
+```
+
+### 2. Check the devtron release name
+
+```bash
+helm list --namespace devtroncd
+```
+
+### 3. Set release name in the variable
+```bash
+RELEASE_NAME=devtron
+```
+
+### 4. Fetch the latest Devtron helm chart
+
+```bash
+helm repo update
+```
+
+
+### 5. Upgrade Devtron
+
+**`5.1` Upgrade Devtron to latest version**
+
+```bash
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+-f https://raw.githubusercontent.com/devtron-labs/devtron/main/charts/devtron/devtron-bom.yaml \
+--set installer.modules={cicd} --reuse-values
+```
+OR
+
+**`5.2` Upgrade Devtron to a custom version**
+
+ You can find the latest releases from Devtron on Github https://github.com/devtron-labs/devtron/releases
+
+```bash
+DEVTRON_TARGET_VERSION=v0.5.x
+
+helm upgrade devtron devtron/devtron-operator --namespace devtroncd \
+-f https://raw.githubusercontent.com/devtron-labs/devtron/$DEVTRON_TARGET_VERSION/charts/devtron/devtron-bom.yaml \
+--set installer.modules={cicd} --reuse-values
+```
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.5.x-0.6.x.md b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.5.x-0.6.x.md
new file mode 100755
index 0000000000..a3d4099c35
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.5.x-0.6.x.md
@@ -0,0 +1,37 @@
+---
+id: devtron-upgrade-0.5.x-0.6.x
+title: Upgrading Devtron 0.5.x to 0.6.x
+sidebar_label: Upgrading Devtron 0.5.x to 0.6.x
+---
+
+# Upgrading Devtron 0.5.x to 0.6.x
+
+If you want to check the current version of Devtron you are using, please use the following command.
+
+```
+kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
+```
+
+## Upgrade the Devtron version using Helm
+
+### 1. Check the devtron release name
+
+```bash
+helm list --namespace devtroncd
+```
+
+### 2. Set release name in the variable
+```bash
+export RELEASE_NAME=devtron
+```
+
+### 3. Run the following script to upgrade
+
+```bash
+wget https://raw.githubusercontent.com/devtron-labs/utilities/main/scripts/shell/upgrade-devtron-v6.sh
+```
+
+```bash
+sh upgrade-devtron-v6.sh
+```
+Please ignore any errors you encounter while running the upgrade script
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.6.x-0.7.x.md b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.6.x-0.7.x.md
new file mode 100755
index 0000000000..2c1fdb2a81
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-0.6.x-0.7.x.md
@@ -0,0 +1,61 @@
+---
+id: devtron-upgrade-0.6.x-0.7.x
+title: Upgrading Devtron 0.6.x to 0.7.x
+sidebar_label: Upgrading Devtron 0.6.x to 0.7.x
+---
+
+# Upgrading Devtron 0.6.x to 0.7.x
+
+To check the current version of your Devtron setup, use the following command
+
+```bash
+kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
+```
+
+Proceed with the following steps only if the version is `0.6.x`
+
+---
+
+## Prerequisites
+
+1. Set the release name
+
+```bash
+export RELEASE_NAME=devtron
+```
+
+2. Label and annotate the service accounts in the `devtron-ci` namespace
+
+```bash
+kubectl -n devtron-ci label sa --all "app.kubernetes.io/managed-by=Helm" --overwrite
+kubectl -n devtron-ci annotate sa --all "meta.helm.sh/release-name=$RELEASE_NAME" "meta.helm.sh/release-namespace=devtroncd" --overwrite
+```
+
+3. Now, label and annotate the service accounts in the `devtron-cd` namespace
+
+```
+kubectl -n devtron-cd label sa --all "app.kubernetes.io/managed-by=Helm" --overwrite
+kubectl -n devtron-cd annotate sa --all "meta.helm.sh/release-name=$RELEASE_NAME" "meta.helm.sh/release-namespace=devtroncd" --overwrite
+```
+
+---
+
+## Upgrade Commands
+
+1. Update the Helm repository
+
+```bash
+helm repo update
+```
+
+2. Run the upgrade command for Devtron
+
+```bash
+helm upgrade devtron devtron/devtron-operator -n devtroncd --reuse-values -f https://raw.githubusercontent.com/devtron-labs/devtron/main/charts/devtron/devtron-bom.yaml
+```
+
+---
+
+## Expected Command Output
+
+
diff --git a/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-1.5.0.md b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-1.5.0.md
new file mode 100755
index 0000000000..9bf6c71b2b
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-1.5.0.md
@@ -0,0 +1,147 @@
+---
+id: devtron-upgrade-1.5.0
+title: Upgrade Devtron to 1.5.0
+sidebar_label: Upgrade Devtron to 1.5.0
+---
+
+# Upgrade Devtron to 1.5.0
+
+This document outlines the step-by-step process to be followed before upgrading Devtron to version **1.5.0**.
+
+## Overview of the Upgrade Process
+
+The upgrade process consists of three sequential Kubernetes jobs:
+
+1. **devtron-pre-upgrade**: Prepares the environment for the upgrade.
+2. **devtron-upgrade-init**: Scales down Devtron and takes the backup.
+3. **devtron-upgrade**: Performs the restoration of data and scales up Devtron.
+
+After the completion of the above jobs, you may proceed to upgrade Devtron using the UI or command line.
+
+---
+
+## Prerequisites
+
+* Ensure that you have [deployed the **devtron-backups** chart](../install/devtron-backup.md) and that at least one backup has been pushed successfully. [Click here](https://github.com/devtron-labs/charts/blob/main/charts/devtron-backups/README.md) to know more about the backups chart.
+* You must have administrative access to the cluster where Devtron is running, along with `kubectl` configured.
+* PVC creation must not be blocked by any policy. If it is, exclude the `devtroncd` namespace from it.
+
+---
+
+## Steps
+
+### 1. Apply the 'pre-upgrade' job
+
+The `devtron-pre-upgrade` job creates the necessary resources and prepares for the database backup.
+
+```bash
+# Apply the devtron-pre-upgrade job
+kubectl apply -f https://raw.githubusercontent.com/devtron-labs/utilities/refs/heads/main/scripts/postgres-upgrade/devtron-pre-upgrade.yaml
+```
+
+This job will:
+1. Create a ConfigMap named `devtron-postgres-upgrade` in the `devtroncd` namespace.
+2. Determine the StorageClass and size of the existing PostgreSQL PVC.
+3. Create a new PVC named `devtron-db-upgrade-pvc` with additional storage (+5Gi).
+4. Automatically apply the upgrade-init job.
+
+To monitor the progress of this job:
+
+```bash
+kubectl logs -f job/devtron-pre-upgrade -n devtroncd
+```
+
+Wait for this job to complete successfully before proceeding.
+
+
+### 2. Monitor the 'upgrade-init' job
+
+The `devtron-upgrade-init` job is automatically triggered by the `devtron-pre-upgrade` job:
+1. It scales down all Devtron components to ensure database consistency.
+2. Terminates active database connections.
+3. Starts the Postgres migration process.
+
+To monitor the progress of this job:
+
+```bash
+kubectl logs -f job/devtron-upgrade-init -n devtroncd
+```
+
+Ensure this job completes successfully before proceeding to the next step.
+
+
+### 3. Apply the 'upgrade' job
+
+Once the backup is confirmed, apply the final upgrade job:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/devtron-labs/utilities/refs/heads/main/scripts/postgres-upgrade/devtron-upgrade.yaml
+```
+
+This job will:
+1. Verify if the `devtron-upgrade-init` job was successful.
+2. Extract any nodeSelectors or tolerations from the existing PostgreSQL StatefulSet.
+3. Remove PostgreSQL 11 components.
+4. Install PostgreSQL 14 with the same configuration.
+5. Migrate the data.
+6. Scale up all Devtron components.
+
+To monitor the progress of this job:
+
+```bash
+kubectl logs -f job/devtron-upgrade -n devtroncd
+```
+
+---
+
+## Verify the Upgrade
+
+After the upgrade job completes, verify the PostgreSQL migration:
+
+```bash
+# Check if all pods are running
+kubectl get pods -n devtroncd
+
+# Verify PostgreSQL version (should now be 14)
+kubectl get configmap devtron-postgres-upgrade -n devtroncd -o jsonpath="{.data.POSTGRES_MIGRATED}"
+```
+
+The value of `POSTGRES_MIGRATED` should be "14" if the migration was successful.
+
+---
+
+## Potential Issues and Troubleshooting
+
+### Job Failure
+
+1. If the `devtron-upgrade-init` or the `devtron-upgrade` job fails, check the logs of job and the ConfigMap for error messages:
+
+```bash
+kubectl get configmap devtron-postgres-upgrade -n devtroncd -o yaml
+```
+
+Look for any entries with "ERROR" in the keys.
+
+2. To reapply the devtron-upgrade-init job, delete the PVC named `devtron-db-upgrade-pvc`, recreate it with the same configurations and then reapply the `devtron-upgrade-init` job.
+
+3. If the `devtron-upgrade-init` job is in a pending state, check for the PVC named `devtron-db-upgrade-pvc`, ensure that the PVC is successfully created.
+
+---
+
+## Next Steps
+
+Once the database migration is complete, you can proceed with upgrading the Devtron application through the UI as mentioned in the final message of the upgrade job. Alternatively, you may use the [upgrade commands](#upgrade-commands) mentioned below.
+
+### Upgrade Commands
+
+1. Update the Helm repository
+
+```bash
+helm repo update
+```
+
+2. Run the upgrade command for Devtron
+
+```bash
+helm upgrade devtron devtron/devtron-operator -n devtroncd --reuse-values -f https://raw.githubusercontent.com/devtron-labs/devtron/refs/tags/v1.5.1/charts/devtron/devtron-bom.yaml --version 0.22.93
+```
diff --git a/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-to-beta.md b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-to-beta.md
new file mode 100755
index 0000000000..39a8426418
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/upgrade/devtron-upgrade-to-beta.md
@@ -0,0 +1,26 @@
+---
+id: devtron-upgrade-to-beta
+title: Upgrading existing devtron to beta
+sidebar_label: Upgrading existing devtron to beta
+---
+
+# Upgrading existing devtron to beta
+
+If you want to check the current version of Devtron you are using, please use the following command.
+
+```
+kubectl -n devtroncd get installers installer-devtron -o jsonpath='{.status.sync.data}' | grep "^LTAG=" | cut -d"=" -f2-
+```
+
+### To upgrade your existing devtron installation to beta, use helm upgrade.
+
+```bash
+$ git clone [https://github.com/devtron-labs/devtron.git](https://github.com/devtron-labs/devtron.git)
+$ cd devtron/charts/devtron
+$ helm dependency up
+$ #modify values in values.yaml
+$ helm upgrade devtron . --reuse-values --namespace devtroncd \
+-f devtron-bom.yaml
+```
+
+> Note: There is no option to upgrade to beta on stack manager UI as of now and you may always see upgrade available for latest stable version using which you'll be moved to latest stable version available.
diff --git a/versioned_docs/version-1.7/setup/upgrade/upgrade-devtron-ui.md b/versioned_docs/version-1.7/setup/upgrade/upgrade-devtron-ui.md
new file mode 100755
index 0000000000..ec692b1591
--- /dev/null
+++ b/versioned_docs/version-1.7/setup/upgrade/upgrade-devtron-ui.md
@@ -0,0 +1,26 @@
+---
+id: upgrade-devtron-ui
+title: Update Devtron from Devtron UI
+sidebar_label: Update Devtron from Devtron UI
+hide_table_of_contents: true
+---
+
+# Update Devtron from Devtron UI
+
+Devtron can be updated from the **Devtron Stack Manager → About Devtron** section.
+
+
+
+* Select **Update to Devtron**
+
+The update process may show one of the following statuses, with details available for tracking, troubleshooting, and additional information:
+
+| Installation status | Description |
+| --- | --- |
+| Initializing | The update is being initialized. |
+| Updating | Devtron is being updated to the latest version. |
+| Failed | Update failed. You may retry the upgrade or [contact support](https://discord.devtron.ai/). |
+| Unknown | Status is unknown at the moment and will be updated shortly. |
+| Request timed out | The request to install has hit the maximum number of retries. You may retry the installation or [contact support](https://discord.devtron.ai/) for further assistance. |
+
+> Updating Devtron also updates the installed integrations.
diff --git a/versioned_docs/version-1.7/user-guide/app-configurations/README.md b/versioned_docs/version-1.7/user-guide/app-configurations/README.md
new file mode 100755
index 0000000000..926936eaf1
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/app-configurations/README.md
@@ -0,0 +1,38 @@
+---
+id: README
+title: Configurations
+sidebar_label: Configurations
+description: Manage GitOps, chart repositories, notifications, and build infrastructure settings for applications in Devtron.
+---
+
+The **Configurations** section in Devtron lets you manage all foundational settings that influence how your applications are built, deployed, and updated.
+
+It provides the configuration layer that integrates source code, chart repositories, and notification systems across your organization.
+
+---
+
+## Table of Contents
+
+### 1. [GitOps](../global-configurations/gitops.md)
+Enable and manage GitOps to synchronize application states between Git repositories and Kubernetes clusters.
+
+### 2. [Git Accounts](../global-configurations/git-accounts.md)
+Add and manage Git provider credentials used for fetching codebases and storing Helm chart configurations.
+
+### 3. [External Links](../global-configurations/external-links.md)
+Add supporting quick links to dashboards, documentation, or observability tools within the Devtron apps.
+
+### 4. [Chart Repository](../global-configurations/chart-repo.md)
+Integrate public or private Helm chart repositories for deploying charts.
+
+### 5. [Deployment Charts](../global-configurations/deployment-charts.md)
+Manage custom Helm charts and deployment templates that define the characteristics of your applications.
+
+### 6. [Notifications](../global-configurations/manage-notification.md)
+Configure notification channels (e.g., Slack, Email, Webhooks) to receive real-time deployment and build alerts.
+
+### 7. [Scoped Variables](../global-configurations/scoped-variables.md)
+Define and manage scoped environment variables that can be reused across multiple application and jobs pipelines.
+
+### 8. [Build Infra](../global-configurations/build-infra.md)
+Tweak the resources (CPU, RAM, and many more) as per the needs of your applications.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/app-details/README.md b/versioned_docs/version-1.7/user-guide/app-details/README.md
new file mode 100755
index 0000000000..1d3224a250
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/app-details/README.md
@@ -0,0 +1,53 @@
+---
+id: README
+title: App Details
+sidebar_label: App Details
+---
+
+# App Details
+
+## Introduction
+
+The **App Details** page acts as a comprehensive dashboard that provides a bird's-eye view of your application (e.g., Devtron, Helm, ArgoCD, FluxCD). From the **App Details** page, you can:
+
+* View your application status
+
+* Scan for vulnerabilities
+
+* Monitor application metrics (e.g., CPU usage and memory usage)
+
+* Manage the most widely used Kubernetes resources
+
+* Deploy your application
+
+* Modify environment configurations
+
+* Rollback deployments and much more
+
+
+
+Consider the **App Details** page as the following two sections:
+
+* [Application summary](application-summary.md) - Where you can view your application and deployment statuses, application metrics, swap traffic, scale workloads, deploy, and do more.
+
+* [Manage Kubernetes resources](app-resource-management.md) - Where you can manage the logs, manifest, and events of your Kubernetes resources and scan for vulnerabilities.
+
+:::caution Who can perform this action?
+Anyone with a `View Only` permission can view this page, but only those at the level of `Admin` (with specific app permissions) or above can take actions on this page.
+
+Refer to [User Permissions](../global-configurations/authorization/user-access.md) for more information.
+
+:::
+
+---
+
+## Next Steps
+
+| **What do you want to do** |**Navigate to**|
+|:--------------------------- |:--------------|
+| View application summary and security details| [Cards Overview](application-summary.md)|
+| Perform quick actions (e.g., Hibernate) | [Action Icons](application-summary.md#action-icons) |
+| Monitor application metrics | [Application Metrics](application-summary.md#application-metrics)|
+| Rollback a deployment | [Rollback](application-summary.md#rollback)|
+| Manage Kubernetes resources | [Resource Management](app-resource-management.md)|
+| Scan for vulnerabilities | [Check Vulnerabilities](app-resource-management.md#check-vulnerabilities)|
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/app-details/app-resource-management.md b/versioned_docs/version-1.7/user-guide/app-details/app-resource-management.md
new file mode 100755
index 0000000000..da62cee64b
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/app-details/app-resource-management.md
@@ -0,0 +1,141 @@
+---
+id: app-resource-management
+title: App Resource Management
+sidebar_label: App Resource Management
+---
+
+# App Resource Management
+
+## Introduction
+
+You can check for vulnerabilities, analyze logs, create ephemeral containers, and manage a few resource kinds directly from the **App Details** page.
+
+
+
+---
+## K8s Resources
+
+The following Kubernetes resource kinds are available for you to view and manage in the **K8s Resources** tab:
+
+* Deployment - View the deployment health, manifest and monitor events like creation, updation, deletion, etc., of the resources.
+
+* [Pod](../../reference/glossary.md#pod) - View the currently running pods (both old and new), access pod terminal, view events and manifest associated with the pod, and even delete a pod.
+
+* [Replica Set](../../reference/glossary.md#replicaset) - View the manifest, events, and the status and health of the replica set.
+
+* [EndpointSlice](../../reference/glossary.md#endpointslice) - View the manifest, events of the active EndpointSlice.
+
+* [Endpoints](../../reference/glossary.md#endpoints) - View the endpoints of your pods, their manifest, and their events.
+
+* [Service](../../reference/glossary.md#service) - View the service health, endpoint and endpointSlice information, and their manifest and events.
+
+When you choose a Kubernetes resource kind (e.g., pods), you can perform a few actions against the resource. Refer the following table to know more:
+
+| **Actions** |**Description**|
+|:------------- |:--------------|
+| **Logs** | Choose **Logs** when you want to view the logs of running pods (old and new). The logs that you get when you click **Logs** and the logs you get when you go via **Log Analyzer** are the same. Note: **Logs** are available only for the **Pod** resource kind. |
+| **Terminal** | Choose **Terminal** when you want to view logs, debug issues, or execute commands directly. Please note that this terminal is different from the cluster terminal that you get on a node level. |
+| **Events** | Choose **Events** when you want to view all the activities (create/update/delete) of the selected pod. |
+| **Manifest** | Choose **Manifest** when you want to view or edit the configuration of the selected pod. |
+
+
+
+---
+### Check Vulnerabilities
+
+:::caution Prerequisite
+To check vulnerabilities, any one of the following integrations must be installed in your Devtron instance:
+
+* [Clair](../../user-guide/integrations/vulnerability-scanning/clair.md)
+
+* [Trivy](../../user-guide/integrations/vulnerability-scanning/trivy.md)
+
+:::
+
+One of the primary reasons to check for vulnerabilities is to catch problems in images, or code, or in the Kubernetes manifest before they end up in production. While Code Scan and Kubernetes Manifest Scan are a part of Devtron's Enterprise offering, you can, however, check for vulnerabilities in your images directly from the **App Details** page.
+
+Follow the below steps to check for vulnerabilities:
+
+1. Choose any one of the following resource kinds from the **K8s Resources** tab:
+
+ * Deployment
+
+ * Pod
+
+ * ReplicaSet
+
+2. Click the (**⋮**) icon against the resource.
+
+3. Click **Check Vulnerabilities**. The **Security** page will be displayed.
+
+ 
+
+ From the **Security** page, you can view the scan results categorized by severity. When you click on the image link, you will get an even more detailed scan results, including CVE ID (Common Vulnerabilities and Exposures) and package (the specific place where the vulnerability is present) information. To know more, refer to [Security](../../user-guide/security-features.md).
+
+---
+## Log Analyzer
+
+Log Analyzer in Devtron helps you to manage the logs of multiple pods and services from one place. You can then:
+
+* Stop the logs
+
+* Clear the logs
+
+* Select the pod for which you'd like to see the logs
+
+* Select the container for which you'd like to see the logs
+
+* Decide how many lines of logs are to be displayed at once
+
+* Download the logs
+
+* Quickly search for and filter the logs based on your requirement
+
+To know more about analyzing logs, refer to [Logs](../resource-browser/pods.md#logs).
+
+---
+
+## Create Ephemeral Containers
+
+You create [Ephemeral Containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) when you want to add a temporary container to a running pod for troubleshooting and debugging purposes.
+
+:::info
+Ephemeral containers are turned on by default in Kubernetes v1.23 and later
+
+:::
+
+
+
+Follow the instructions below to create an ephemeral container from the **App Details** page:
+
+1. Navigate to **Applications** and choose your preferred application.
+
+2. Go to the **App Details** tab.
+
+3. Choose **Pod** under the **K8 Resources** tab.
+
+4. Locate the pod you wish to debug. Hover over and click **Terminal**.
+
+ 
+
+5. Click **Launch Ephemeral Container**. The **Launch ephemeral container on pod** page is displayed.
+
+ 
+
+6. Choose **Basic** to create a bare minimum ephemeral container:
+
+ 
+
+ * Enter a prefix to your ephemeral container, for e.g., *debug* in the **Container name prefix** field.
+
+ * Choose an image to run from the **Image** drop-down box. Ephemeral containers need an image to run and provide the capability to debug, such as `curl`. You can use a custom image too.
+
+ * Choose a target container you wish to debug from the **Target Container name**.
+
+7. Choose **Advanced** if you wish to use labels or annotations to create an ephemeral container since it provides additional key-value options. Refer [Ephemeral Container Spec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#ephemeralcontainer-v1-core) to view the supported options.
+
+ 
+
+8. Click **Launch Container**.
+
+Refer to [Using Ephemeral Containers](ephemeral-containers.md) for more information.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/app-details/application-summary.md b/versioned_docs/version-1.7/user-guide/app-details/application-summary.md
new file mode 100755
index 0000000000..f9e9cdacb3
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/app-details/application-summary.md
@@ -0,0 +1,202 @@
+---
+id: application-summary
+title: Application Summary
+sidebar_label: Application Summary
+---
+
+# Application Summary
+
+## Introduction
+
+Devtron helps you to view your application summary in the form of [cards](#cards-overview) and [Application Metrics](#application-metrics). It also helps you perform [quick actions](#action-icons) and [manage the most widely used Kubernetes resources](app-resource-management.md) directly from the **App Details** page.
+
+
+
+:::caution Who can perform this action?
+Anyone with a `View Only` permission can view this page, but only those at the level of `Admin` (with specific app permissions) or above can take actions on this page. Refer to [User Permissions](../global-configurations/authorization/user-access.md) for more information.
+
+:::
+
+Follow the below steps to access the **App Details** page:
+
+1. Navigate to **Applications** and choose your preferred application.
+
+2. Choose **App Details** and select the environment for which you'd like to see the application summary in the **Env** drop-down box.
+
+The icon next to the **Env** drop-down box denotes the application deployment method. It can be any of the following:
+
+* Deployed using Helm
+
+* Deployed using ArgoCD
+
+* Deployed using FluxCD
+
+
+
+Manifest status (whether they are in sync or not) is denoted by [this](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/creating-application/app-details/manifest-status-icon.jpg) icon. When you click on this icon, the **Live and desired manifest comparison** page is displayed (read-only) allowing you to compare the manifests and view config drifts (if there are any).
+
+---
+## Cards Overview
+
+Devtron provides you a quick summary of your application via cards. Refer to the following table to know more about cards:
+
+| **Card Name** |**Description**|
+|:------------- |:--------------|
+| **Application Status** | Tells you the application status (e.g., `Healthy` or `Degraded`). The available application statuses in Devtron are:
Degraded
Healthy
Hibernating
Missing
Not Deployed
Progressing
When you click **Details**, all the details about the resource kinds, their statuses, and the message (if any) are displayed. |
+| **Blackout Window** / **Maintenance Window** | Tells you whether the application deployment is blocked or allowed for the chosen environment. This card also displays the upcoming blackout/maintenance window and the remaining time for the blackout/maintenance window to complete. Refer to [Deployment Window](../global-configurations/deployment-window.md) for more information. |
+| **Chart Used** (available only for Helm apps) | Displays the chart used to deploy the application. When you hover over the (**?**) icon in the card, you can directly configure the YAML values by clicking the **Go to Configure** option. |
+| **Deployed commit** (available only for Devtron apps) | Displays the commit ID of the deployed image. When you click **Details**, the commit ID, repository name, branch name, and the deployed image ID are displayed. |
+| **Deployment Status** | Tells you the deployment status (e.g., `Succeeded` or `Failed`). The available deployment statuses in Devtron are:
Failed
Progressing
Succeeded
Timed Out
Triggered
When you click **Details**, the complete deployment status, from when it was deployed by whom to the current status of it, is displayed. |
+| **Security** (available only for Devtron and Helm apps) | Displays the following security scan results:
Image Scan
Code Scan
Manifest Scan
Refer to [Security Policies](../security-features/security-policies.md) for more information.|
+| **Rollout Deployment Visibility** |
**Canary Strategy** - Displays the live progress of how many users are being redirected to the new release. Refer to [Canary Deployments](deployment-visibility.md#for-canary-deployments) for more information.
**Blue Green Strategy** - Displays the progress of the Blue Green deployment. You can [swap traffic](deployment-visibility.md#swap-traffic) or [skip and promote full](deployment-visibility.md#skip--promote-full) directly from this card as per your requirement. Refer to [Blue Green Deployments](deployment-visibility.md#for-blue-green-deployments) for more information.
|
+
+---
+## Action Icons
+
+You can perform a variety of actions right from the **App Details** page using the following action icons:
+
+### URLs
+
+When you click the **URLs** icon, the **URLs** page is displayed with the [Ingress Host URL](../../reference/glossary.md#ingress-host-url) and the [Load Balancer URL](../../reference/glossary.md#load-balancer-url) (if available).
+
+
+
+
+
+You can directly copy the URLs (Ingress and Load Balancer) from the **URLs** page instead of searching in the manifest.
+
+The Ingress Host URL will point to the load balancer of your application, and you can also view the service name with the load balancer details.
+
+### Hibernate
+
+:::info Note
+* This functionality is available as **Hibernate/Unhibernate** icons in Devtron apps and as a **Scale Workloads** icon in Helm apps.
+
+* When there is an ongoing blackout or maintenance window for the application, then the option to hibernate or unhibernate that app (**Scale Workloads**, in the case of a Helm app) will be restricted.
+
+:::
+
+The **Hibernate** icon (**Scale Workloads**, in the case of a Helm app) allows you to hibernate (to rest) your application when not in use by scaling down the pods to nearly zero in that selected environment (e.g., `QA`). The application will automatically unhibernate when you make a new deployment.
+
+However, you can manually unhibernate the application by clicking the **Unhibernate** icon.
+
+
+
+### Restart Workloads
+
+:::info Note
+* The **Restart Workloads** icon is available only for Devtron custom applications.
+
+* When there is an ongoing blackout or maintenance window for the application, then the **Restart Workloads** icon will be restricted.
+
+:::
+
+When you are facing issues with your application (e.g., crashing of pods) or prefer to use a new configuration, you restart the workloads. When you click the **Restart Workloads** icon, the **Restart Workloads** page is displayed.
+
+
+
+When you select a workload and click **Restart Workloads**, all the pods for the selected workloads are restarted using the configured deployment strategy (e.g., `Rolling`).
+
+### Rollback
+
+:::info Note
+* The **Rollback** icon is available only for Devtron custom applications.
+
+* You will not be able to rollback your deployment during blackout window and outside maintenance window of the application.
+
+:::
+
+You can perform a rollback of your deployment directly from the **App Details** page. When you click the **Rollback** icon, the following page is displayed.
+
+
+
+* Select an image from the available list of previously deployed images in that specific environment.
+
+:::info Note
+When there is an active policy in place for an environment, and there are no approved images, then no images will be displayed in the **Rollback** page.
+
+:::
+
+* Select one of the following deployment configurations in the **Deploy** drop-down box:
+
+ * Last Saved Config
+
+ * Last Deployed Config
+
+ * Config Deployed with Selected Image
+
+* Review configuration differences (if any) by selecting the **Review** option. If there is any config difference, it will be highlighted in this section.
+
+* Choose a deployment strategy in the **Rolling (Default)** drop-down box.
+
+* Click **Deploy**.
+
+### Deploy
+
+:::info Note
+* The **Deploy** button is available only for Devtron custom applications.
+
+* When there is an ongoing blackout or maintenance window for the application, the **Deploy** button will be changed to **Deployment is Blocked** and you will not be able to deploy during this time period.
+
+:::
+
+Devtron helps you in deploying images directly from the **App Details** page. When you click the **Deploy** button, the following page is displayed.
+
+
+
+Follow the below steps to deploy an image:
+
+* Select an image from the available list of previously deployed images in that specific environment.
+
+* Select one of the following deployment configurations in the **Deploy** drop-down box:
+
+ * Last Saved Config
+
+ * Last Deployed Config
+
+ * Config Deployed with Selected Image
+
+* Review configuration difference (if any) by selecting the **Review** option. If there is any config difference, it will be highlighted in this section.
+
+* Choose a deployment strategy in the **Rolling (Default)** drop-down box.
+
+* Click **Deploy**.
+
+### Environment Configurations
+
+:::info Note
+The **Environment Configuration** icon is available only for Devtron custom applications.
+
+:::
+
+You can quickly configure Deployment Templates, ConfigMaps and Secrets for the selected environment directly from the **App Details** page. When you click the **Go to Environment Config** icon, the following page is displayed.
+
+
+
+To configure enviroment specific Deployment Templates, ConfigMaps, Secrets, refer to [Environment Overrides](../creating-application/environment-overrides.md).
+
+---
+## External Links
+
+All your [external links configured](../../user-guide/global-configurations/external-links.md) in the **Configurations** tab are displayed in the **App Details** page. When you hover around an external link (e.g. `Grafana`), a description of the external link is displayed. To know more, refer to [External Links](../global-configurations/external-links.md).
+
+
+
+:::info Note
+If you enable `App admins can edit` in the **External Links** page, then only non super admins can view the selected links on the **App Details** page.
+
+:::
+
+---
+## Application Metrics
+
+Application metrics help you in evaluating the performance and efficiency of your application. The Application Metrics section can be enabled by enabling the checkbox **Show application metrics** while configuring the application. Refer to [Application Metrics](../creating-application/app-metrics.md) for more information.
+
+
+
+---
+## Next Steps
+
+Devtron also allows you to manage a few of your Kubernetes resource kinds from the **App Details** page. Refer to [App Resource Management](app-resource-management.md) to manage your Kubernetes resources.
+
+If you want to manage your **Canary** and **Blue-Green** deployments, refer to [Deployment Visibility & Actions](deployment-visibility.md).
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/app-details/deployment-visibility.md b/versioned_docs/version-1.7/user-guide/app-details/deployment-visibility.md
new file mode 100755
index 0000000000..0c37da554f
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/app-details/deployment-visibility.md
@@ -0,0 +1,125 @@
+---
+id: deployment-visibility
+title: Deployment Visibility & Actions
+sidebar_label: Deployment Visibility & Actions
+---
+
+# Deployment Visibility & Actions
+
+## Introduction
+
+Devtron helps you to manage your **Canary** and **Blue-Green** deployments by providing visibility and easy controls to manage how new versions (releases) are shared with users.
+
+Devtron allows you to:
+
+* Quickly view the current deployment status and detailed progress.
+
+* For canary deployments you can manually trigger the next step for the release or fully complete the rollout.
+
+* For Blue-Green deployments
+
+ * You can directly route the end user traffic to the application’s new deployment on a particular environment.
+
+ * You can swap the traffic from Blue to Green.
+
+* Easily rollback deployments (if needed).
+
+:::info Prerequisites
+The [Deployment Chart Type](../creating-application/base-config/deployment-template.md#select-a-deployment-chart-type) must be set to rollout in order to use Blue-Green or Canary strategies.
+
+Deployment Visibility and Actions is only available for Canary and Blue-Green Strategies. Refer to the [Deployment Strategies](../creating-application/workflow/cd-pipeline.md#deployment-strategies) to learn more.
+
+:::
+
+:::caution Who Can Perform This Action?
+Users need to have Build and Deploy or above (along with access to the environment and application).
+
+:::
+
+---
+
+## Visibility & Actions
+
+### For Canary Deployments
+
+After triggering the deployment, navigate to **App Details**, to get a quick overview of your release rollout status.
+
+You can click the [Manage Traffic](../application-groups.md#managing-traffic-) button to view the rollout status and steps involved in the release.
+
+If you wish you can also trigger the next release steps (for example 25%, 50%, 75%) or you can also trigger the full rollout at once according to your use case.
+
+ 
+
+ 
+
+
+### For Blue Green deployments
+
+Devtron automatically swaps the traffic from the current running release to the new release based on the defined strategy configuration. In case `autoPromotionEnabled` field value is set to `false`, you can manually swap the traffic from the current release to the new release.
+
+
+
+To do so, follow the steps below:
+
+#### Swap Traffic
+
+1. Navigate to **App Details** of your application.
+
+2. During Blue-Green deployment, click the **Swap Traffic** button to shift the traffic to application's new release.
+
+ 
+
+3. Enter the name of the environment and select **Swap Traffic**
+
+ 
+
+4. This will route the end user traffic from the current running release to the new release on a particular environment.
+
+
+In any scenario, if you want to skip the Blue-Green Strategy and route the end user traffic from the current running release to the new release on a particular environment, you can do that via **Skip & Promote Full** button during the deployment.
+
+To do so, follow the below steps:
+
+#### Skip & Promote Full
+
+1. Navigate to **App Details** of your application.
+
+2. During Blue-Green deployment, click the **Skip & Promote Full** button to shift the traffic to application's new deployment.
+
+ 
+
+3. Enter the name of the environment and select **Promote to Full**.
+
+ 
+
+4. This will skip the Blue-Green Strategy and route the end user traffic from the current running release to the new release on a particular environment.
+
+### Rollback the Deployment
+
+In case you have identified some bugs or performance of the release is not as expected then you can also rollback to the previous release.
+
+You can perform a rollback from **Build & Deploy** Section and from App Details (for Blue-Green & Canary Strategies only)
+
+To perform a rollback from App Details follow the below steps:
+
+1. Navigate to **App details** of your Devtron Application.
+
+2. Based on the type of deployment strategy, perform one of the following actions:
+
+ * In case of Canary deployments, select **Rollback** under **Canary Strategy**.
+
+ 
+
+ * In case of Blue Green deployments, select **Rollback** under **Blue Green Strategy**.
+
+ 
+
+3. Select the image to which you want your release to be rolled back and click **Deploy** to rollback the release.
+
+ 
+
+4. If you wish, you can select a different deployment strategy other than the default according to the use case.
+
+ 
+
+5. The application will be rolled back to the previous release (image) using the selected deployment strategy.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/app-details/ephemeral-containers.md b/versioned_docs/version-1.7/user-guide/app-details/ephemeral-containers.md
new file mode 100755
index 0000000000..c34e9613d6
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/app-details/ephemeral-containers.md
@@ -0,0 +1,57 @@
+---
+id: ephemeral-containers
+title: Using Ephemeral Containers
+sidebar_label: Using Ephemeral Containers
+---
+
+# Using Ephemeral Containers
+
+## Introduction
+
+An ephemeral container runs temporarily in an existing running pod primarily for debugging and troubleshooting purposes. When your pod(s) crash or your application misbehaves, but you can't restart the workloads for various reasons, you create an ephemeral container.
+
+In Devtron, you can create an ephemeral container in the following ways:
+
+* [From App Details Page](#create-from-app-details-page)
+
+* [From Resource Browser](#create-from-resource-browser)
+
+* [From Cluster Terminal](#create-from-cluster-terminal)
+
+---
+
+## Create From App Details Page
+
+You can quickly create an ephemeral container directly from the **App Details** page of your application. Refer to [Create Ephemeral Containers](app-resource-management.md#create-ephemeral-containers) for more information.
+
+---
+
+## Create From Resource Browser
+
+
+
+To create an ephemeral container from the Resource Browser, refer to [Launching Ephemeral Container](../resource-browser/pods.md#launching-ephemeral-container).
+
+---
+
+## Create From Cluster Terminal
+
+:::caution
+This is not a recommended method. However, if you still wish to proceed, then this option is available only if you are an [Admin](../global-configurations/authorization/user-access.md).
+
+:::
+
+
+
+---
+
+## Remove an Ephemeral Container
+
+You can remove an ephemeral container from either the **App Details** page or the **Resource Browser**.
+
+:::info
+If you had created an ephemeral container using the Kubernetes CLI, then you will not be able to remove the container from the **App Details** page or the **Resource Browser**.
+
+:::
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/app-labels.md b/versioned_docs/version-1.7/user-guide/app-labels.md
new file mode 100755
index 0000000000..88082af514
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/app-labels.md
@@ -0,0 +1,47 @@
+---
+id: app-labels
+title: App Labels Tagging
+sidebar_label: App Labels Tagging
+---
+
+# App Labels Tagging
+
+Overview
+============
+
+This feature helps you to tag labels on applications, this will help you to filter out and categories your applications.
+
+labels are combinations of key value pairs, each application may have multiple labels.
+
+every app must have unique key.
+
+### 1. Add labels on creation of application
+
+Login with valid credentials and go to `Applications` and click on right top button `Add New App` and fill the required
+values.
+
+Labels are optionals and can be entered `key:values` format. multiple labels can be added without repeating `key` name.
+
+
+
+### 2. Application meta info
+
+Login with valid credentials and go to `Applications` and click on any application and go to detail page, click on top
+left button next to application name `?`.
+
+This will open show you the applications meta details like project, labels associated with it.
+
+
+
+### 3. Edit Labels to existing apps
+
+We also add or remove labels for app from here.
+
+
+
+### 3. Label Payload
+
+* `id` : integer unique label id
+* `appId` : integer application id
+* `key` : string key is the part of label stored individually in db.
+* `value` : string value is the part of label stored individually in db.
diff --git a/versioned_docs/version-1.7/user-guide/application-groups.md b/versioned_docs/version-1.7/user-guide/application-groups.md
new file mode 100755
index 0000000000..2e94f2c3a7
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/application-groups.md
@@ -0,0 +1,516 @@
+---
+id: application-groups
+title: Application Groups
+sidebar_label: Application Groups
+---
+
+# Application Groups
+
+## Introduction
+
+Application groups in Devtron streamline the deployment of microservices by enabling you to build and deploy multiple applications simultaneously. This feature is particularly beneficial when your microservices are interdependent, as a change in one service often triggers the need to redeploy others.
+
+:::info Note
+Only one application group would exist for each [environment](../reference/glossary.md#environment). You cannot group applications belonging to different environments.
+
+:::
+
+---
+
+## Accessing Application Groups
+
+:::info Who Can Perform This Action?
+Users need to have [View only permission](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to view all the applications within a group.
+
+:::
+
+1. From the left sidebar, go to **Application Groups**
+
+ 
+
+2. You will see a list of environments. Select the environment to view the application group.
+
+ 
+
+3. The application group would contain the applications meant for deployment in the chosen environment.
+
+ 
+
+As you can see, it has similar options as available under [Applications](./applications.md):
+* Overview
+* Build & Deploy
+* Build history
+* Deployment history
+* Configurations
+
+First, we will walk you through the [key features](#key-features) of Application Groups, followed by [additional features](#additional-features) that will help you perform bulk actions.
+
+---
+
+## Key Features
+
+### Building Application Images
+
+:::info Who Can Perform This Action?
+Users need to have [Build and deploy permission](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to trigger the build.
+
+:::
+
+The **Build & Deploy** tab of your application group enables you to trigger the [CI builds](../reference/glossary.md#image) of one or more applications in bulk.
+
+1. Select the applications using the checkboxes and click the **Build Image** button present at the bottom.
+
+ 
+
+2. The `Build image` screen opens. Select the application and the [commit](../reference/glossary.md#commit-hash) for which you want to trigger the CI build.
+
+ 
+
+:::info Tip
+Adding [image labels](./deploying-application/image-labels-and-comments.md) can help you quickly locate the container image from the list of images shown in Application Groups.
+:::
+
+3. Similar to application, you can also [pass build parameters](./deploying-application/triggering-ci.md#passing-build-parameters-) in application groups before triggering the build.
+
+:::info Note
+Passing build parameters feature is only available in
+
+:::
+
+* Go to the **Parameters** tab.
+
+ 
+
+* Click **+ Add parameter**.
+
+ 
+
+* Enter your key-value pair as shown below.
+
+ 
+
+* You may follow the above steps for other applications too, and then click **Start Build**.
+
+ 
+
+ 
+
+4. The builds will initiate, following which, you can close the `Build image` screen.
+
+ 
+
+### Changing Configurations
+
+:::info Who Can Perform This Action?
+Users need to have [Admin role](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to change their configuration. Please note, you might not be able to change the values of locked keys in deployment template. Refer [Lock Deployment Configuration](./global-configurations/lock-deployment-config.md) to know more.
+
+:::
+
+The **Configurations** tab of your application group allows you to configure the following:
+
+* [Deployment template](../reference/glossary.md#deployment-template)
+* [ConfigMaps](../reference/glossary.md#configmaps)
+* [Secrets](../reference/glossary.md#secrets)
+
+As shown below, you can handle the configurations of more than one application from a single screen.
+
+
+
+### Deploying Applications
+
+:::info Who Can Perform This Action?
+Users need to have [Build and deploy permission](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to initiate the deployment.
+
+:::
+
+The **Build & Deploy** tab of your application group helps you deploy one or more applications in bulk.
+
+1. Select the applications using the checkboxes.
+
+ 
+
+2. You can also trigger Pre-deployment stage or Post-deployment stage for your applications in bulk.
+
+ * To trigger Pre-deployment stage, click the droupup next to **Deploy** and select **Trigger Pre-deployment stage**.
+
+ * To trigger Post-deployment stage, click the droupup next to **Deploy** and select **Trigger Post-deployment stage**.
+
+ 
+
+:::info Note
+* The dropup appears only if your workflow has Pre-deployment stage or Post-deployment stage configured for the selected environment.
+* If both stages are configured, the dropup will display options for triggering **Pre-deployment** and **Post-deployment** stages.
+* If only one stage is configured, the dropup will show the option for triggering that specific stage.
+:::
+
+3. After selecting the applications, click the **Deploy** button present at the bottom.
+
+ 
+
+4. Select the desired container image that you want to deploy for respective application.
+
+ 
+
+ Repeat the step for other applications too.
+
+ 
+
+5. If you wish, you can deploy all applications in an Application Group using a single deployment strategy, select the preferred deployment strategy for all the applications and click **Deploy**.
By default, all applications will be deployed using their respective default strategies.
+
+ 
+
+ * **Deployment feasibility** page will open, in case for any application, the selected deployment strategy is not configured, you can select one of the configured strategies for that application.
If you do not select a configured deployment strategy, deployment will be skipped for that particular application.
+
+ 
+
+6. The deployment will be initiated, following which, you can close the screen as shown below.
+
+ 
+
+7. Once the deployment is successful, the pipelines will show `Succeeded`.
+
+ 
+
+:::info Note
+You can go to the **App Details** tab to have a bird's-eye view of your application, view application metrics, and even perform quick actions (e.g., restarting workloads). Refer to [App Details](../user-guide/app-details/README.md) for more information.
+
+:::
+
+### Managing Traffic
+
+While deployment, Devtron allows you to manage your **Canary** and **Blue-Green** deployments by providing visibility and easy controls to manage how new versions (releases) are shared with users.
+
+To do so, follow the below steps:
+
+1. Go to **Overview** and click **Manage Traffic**.
+
+ 
+
+2. Select the required applications, a side window will appear displaying all the eligible rollouts.
+
+3. You can take the following actions based on the deployment strategy of the application
+
+ * For **Canary Deployments**, you can either choose to initiate the next step or to initiate the full rollout.
+
+ 
+
+ * For **Blue Green deployments**, you can either choose to **Swap Traffic**, or you can choose Skip & Promote Full.
+
+ * **Swap Traffic**: This will swap the traffic from the current deployment to the application latest deployment.
+
+ 
+
+ * **Skip & Promote Full**: While deploying, this will directly deploy the whole traffic to application latest deployment.
+
+ 
+
+4. Click **Initiate Eligible Rollouts** to implement the actions.
+
+ 
+
+ 
+
+---
+
+## Additional Features
+
+### Clone Pipelines
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../user-guide/global-configurations/authorization/user-access.md#grant-super-admin-permission) can clone pipelines.
+
+:::
+
+This feature aims at helping the user clone existing CI/CD pipelines for new target environments in multiple applications. The configurations present in the given CI/CD pipeline also get copied to the cloned pipelines (refer the below table).
+
+| Configuration Item | Cloning Behavior |
+|----------------------------------|--------------------------------------------------------------|
+| [**CI Workflow**](../user-guide/creating-application/workflow/ci-pipeline.md) | Clones the source’s workflow CI as it is |
+| [**Pipeline Configuration**](../user-guide/creating-application/workflow/pre-post-tasks.md) | Cloned, including Pre-CD and Post-CD scripts/plugins |
+| [**Environment Configuration**](../user-guide/creating-application/environment-overrides.md) | Cloned, including Deployment Template (DT), ConfigMap (CM), and Secret |
+| [**GitOps Configuration**](../user-guide/creating-application/gitops-config.md) | Not cloned |
+| [**Environment Policies**](../user-guide/creating-application/environment-overrides.md) | Cloned if at pipeline level,ignored if global |
+| [**CD Filter**](../user-guide/global-configurations/filter-condition.md) | Not cloned (handled globally) |
+| [**Protect Configurations**](../user-guide/creating-application/config-approval.md) | Cloned (handled at pipeline level) |
+| [**Deployment Approvals**](../user-guide/global-configurations/approval-policy.md) | Not cloned (handled globally) |
+| [**Lock Configurations**](../user-guide/global-configurations/lock-deployment-config.md) | Not cloned |
+| [**Mandatory Plugin**](../user-guide/global-configurations/plugin-policy.md) | Not cloned |
+| [**Image Digest Policy**](../user-guide/global-configurations/pull-image-digest.md) | Cloned at pipeline level, ignored if global |
+| [**Promotion Policy**](../user-guide/global-configurations/image-promotion-policy.md) | Not cloned |
+| [**Deployment Window**](../user-guide/global-configurations/deployment-window.md) | Not cloned |
+| [**Security Policy**](../user-guide/security-features/security-policies.md) | Not cloned |
+| [**Permissions**](../user-guide/global-configurations/authorization/user-access.md) | Not cloned |
+
+
+**Use Case**: Let's say you have 'n' number of apps deployed to a development environment named `dev-env`. Later, a few testers joined your team, thus necessitating the addition of a testing environment (`test-env`) with those same apps deployed. Manually creating the pipelines and configuring them for `test-env` environment in each app might be impractical. Therefore, we recommend you to use the cloning feature.
+
+#### Methods of Cloning
+
+This feature gives you two methods of cloning:
+
+1. **New Workflow**: Creates a new workflow and clones the source CI and CD pipeline. Gives you the flexibility to tweak the cloned CI (e.g., changing code branch for build) too.
+
+ 
+
+2. **Source Workflow**: Uses the same workflow and clones only the source CD pipeline, thus keeping the original CI pipeline unchanged.
+
+ 
+
+#### Steps to Clone Pipelines
+
+1. Go to **Application Groups** and click the source environment from the list.
+
+ 
+
+2. Select the applications whose pipelines you wish to clone.
+
+3. A floating widget will appear at the bottom. Click the `⋮` menu and then click **Clone Pipeline Config**.
+
+ * Alternatively, you may access **Clone Pipeline Config** from the `⋮` menu next to the application name.
+
+ 
+
+4. From the dropdown, select the target environment for which pipelines should be created for selected applications.
+
+ 
+
+5. Select the workflow where you wish to create deployment pipeline: **New Workflow** or **Workflow as source environment**. Refer [Methods of Cloning](#methods-of-cloning) to know which option will fulfill your requirement.
+
+ 
+
+6. Click **Clone in new workflow** or **Clone in source workflow** (depending on the option you selected in the previous step).
+
+ 
+
+:::caution Note
+The cloning process will skip if a CD pipeline (for the target environment) already exists in the chosen application's workflow. You can view this in the clone status generated after the above process.
+
+:::
+
+
+### Hibernating and Unhibernating Apps
+
+:::caution Who Can Perform This Action?
+Users need to have [Build & deploy permission](./global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and application) to hibernate or unhibernate applications.
+
+:::
+
+Since every application comes with an option to hibernate, the same is true for application groups. Using application group, you can hibernate one or more applications belonging to the same environment if you do not want them to consume resources (replica count will be set to 0).
+
+In other words, you can hibernate running applications or unhibernate hibernated applications as per your requirement.
+
+#### Hibernation Process
+
+1. In the **Overview** page of your application group, use the checkboxes to choose the applications you wish to hibernate.
+
+2. A floating widget will appear at the bottom. Click the **Hibernate** button.
+
+ * Alternatively, you may access **Hibernate** from the `⋮` menu next to the application name.
+
+ 
+
+3. Confirm the hibernation by clicking **Hibernate**.
+
+ 
+
+4. Hibernation will initiate as shown below. You may close the window.
+
+ 
+
+Your applications pods would be scaled down and would stop incurring costs.
+
+:::caution Note
+* The hibernation process will show the status as `Skipped` for the applications which are already hibernated.
+* The hibernation process will show the status as `Failed` for the applications which have no deployment history.
+:::
+
+#### Unhibernation Process
+
+1. In the **Overview** page of your application group, use the checkboxes to choose the applications you wish to unhibernate.
+
+2. A floating widget will appear at the bottom. Click the **Unhibernate** button.
+
+ * Alternatively, you may access **Unhibernate** from the `⋮` menu next to the application name.
+
+ 
+
+3. Confirm the unhibernation by clicking **Unhibernate**.
+
+ 
+
+4. Unhibernation will initiate as shown below. You may close the window.
+
+ 
+
+Your applications would be up and running in some time.
+
+:::caution Note
+* The unhibernation process will show the status as `Skipped` for the applications which are already running.
+* The unhibernation process will show the status as `Failed` for the applications which have no deployment history.
+:::
+
+### Restart Workloads
+
+:::caution Who Can Perform This Action?
+Users need to have [Build & deploy permission](./global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and application) to restart workloads in bulk.
+
+:::
+
+Restarting workloads might be necessary if you want your new code or configuration to come into effect, or you are experiencing issues like crashing of pods.
+
+Using application group, you can select the workloads (i.e., Pod, Deployment, ReplicaSet, etc.) of specific applications and restart them.
+
+1. In the **Overview** page of your application group, use the checkboxes to choose the applications you wish to restart.
+
+2. A floating widget will appear, click the **Restart Workloads** button.
+
+ * Alternatively, you may access **Restart Workload** from the `⋮` menu next to the application name.
+
+ 
+
+3. Next to the application, click the workload dropdown to view all the individual workloads of an application. Choose only the ones you wish to restart.
+
+ 
+
+ Moreover, you can easily select, deselect, or choose multiple workloads as shown below.
+
+ 
+
+4. Click **Restart Workloads**.
+
+ 
+
+Restarting workloads might take time depending on the number of applications.
+
+### Filtering Applications
+
+Assume you have multiple applications (maybe 10, 50, 100, or more) showing up in an application group. If you want to limit your operations (build/deploy/other) to a specific set of applications, the filter feature will help you narrow down the list. Thus, you will see only those applications you select from the filter (be it on the **Overview** page, **Build & Deploy** page, and so on.)
+
+1. Click the filter next to the application group as shown below.
+
+ 
+
+2. The filter will show all the applications present in the group. Click to select the relevant ones.
+
+ 
+
+3. The filter narrows down the list of applications as shown below.
+
+ 
+
+4. (Optional) If required, you can save the filter for future use by clicking **Save selection as filter**.
+
+ 
+
+5. Add a name and description to the filter to help you know its purpose, and click **Save**.
+
+ 
+
+Now when you access the application group, your saved filter will be visible on top.
+
+
+
+:::info Permissions
+#### 1. Creating a filter
+
+Users can create a filter if they have Admin/Manager access on all selected applications.
+
+* **Case 1**: User has Admin/Manager access on all selected applications
+
+ User will be able to create a filter with all selected applications.
+
+* **Case 2**: User does not have Admin/Manager access on all selected applications
+
+ User will not be able to create a filter.
+
+* **Case 3**: User selected 4 applications but has Admin/Manager access for only 2 of them
+
+ User should be able to create filter with these 2 applications.
+
+#### 2. Editing a saved filter
+
+Users can edit a saved filter if they have Admin/Manager access on all applications in the saved filter.
+
+#### 3. Deleting a saved filter
+
+Users can delete a saved filter if they have Admin/Manager access on all applications in the saved filter.
+
+:::
+
+### Changing Branch
+
+:::caution Who Can Perform This Action?
+Users need to have [Admin role](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to update their branch.
+
+:::
+
+Assume you have a few applications whose [build pipelines](../reference/glossary.md#build-pipeline) fetch from the `main` branch of your code repository. However, you decided to maintain a `master` branch, and you want all the upcoming CI builds to consider the `master` branch as the source. Devtron provides you the option to change the branch at both levels, individual application as well as application group.
+
+1. In the **Build & Deploy** tab of your application group, select the intended applications and click the **Change Branch** button present at the bottom.
+
+ 
+
+2. Enter the new branch name. If your build pipeline has `Branch Regex` as the Source Type, you must ensure your new branch name matches the regex (regular expression) provided in that build pipeline. Once done, click **Update Branch**.
+
+ 
+
+### Changing Image Source
+
+:::caution Who Can Perform This Action?
+Users need to have [Admin role](../user-guide/global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and applications) to update their branch.
+:::
+
+The **Change Image Source** feature in Devtron lets you update the container image source for an application’s workflow without modifying it.
+
+1. In the **Build & Deploy** tab of your application group, select the preferred workflows and click the **Change Image Source** button present at the bottom.
+
+ 
+
+2. Select the preferred Workflow template, and enter the required details as per the workflow template. Currently, **Change Image Source** feature for **Application Groups** is only supported for **Build from Source Code** and **Sync with Environment**.
+
+ 1. **Build from Source Code**
+ * After selecting **Build from Source Code**, a feasibility check will run. You can click **Create Build Pipeline** only if the application's feasibility shows `Can change`.
+
+ **Note:** Application for which the feasibility shows `Cannot change` will be skipped due to following reasons:
+
+ * `Multi git material found at the source, not allowed to change the source`
+ * `No cd pipeline found for the selected app and env combination`
+ * `Invalid request, trying to create self loop, cannot create sync-cd source pipeline with source environment in same workflow`
+
+ 
+
+ 
+
+ * A pop-up window will open, enter the **Source Type** and **Branch** under **Select code source**.
+
+ 
+
+ * Click **Create Pipeline**. A modal window will appear showing the status of the image source change.
+
+ 
+
+ 2. **Sync with Environment**
+ * After selecting **Sync with Environment**, a modal window will open.
+
+ 
+
+ * Select the environment from which you want to sync your workflow, and then click **Next**.
+
+ 
+
+ * A feasibility check will run. You can click **Change Image Source** only if the application's feasibility is marked as `Can change`.
+
+ **Note:** Application for which the feasibility shows `Cannot change` will be skipped due to following reasons:
+
+ * `Multi git material found at the source, not allowed to change the source`
+ * `No cd pipeline found for the selected app and env combination`
+ * `Invalid request, trying to create self loop, cannot create sync-cd source pipeline with source environment in same workflow`
+
+ 
+
+ * Click **Change Image Source**. A modal window will appear showing the operation status.
+
+ 
+
+3. The image source is applied to all selected workflows where the feasibility check passed.
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/applications.md b/versioned_docs/version-1.7/user-guide/applications.md
new file mode 100755
index 0000000000..9b285f3e99
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/applications.md
@@ -0,0 +1,171 @@
+---
+id: applications
+title: Applications
+---
+
+# Applications
+
+:::caution
+Configure [Global Configurations](./global-configurations/README.md) first before creating an application or cloning an existing application.
+:::
+
+## Introduction
+
+The **Applications** page helps you create and manage your microservices, and it majorly consists of the following:
+
+* [Application Listing](#application-listing)
+* [Create Button](#create-button)
+* [Other Options](#other-options)
+
+### Application Listing
+
+You can view the app name, its status, environment, namespace, and many more upfront. The apps are segregated into: [Devtron Apps](../reference/glossary.md#devtron-apps), [Helm Apps](../reference/glossary.md#helm-apps), [ArgoCD Apps](../reference/glossary.md#argocd-apps), and [FluxCD Apps](../reference/glossary.md#fluxcd-apps).
+
+
+
+### Create Button
+
+You can use this to:
+* [Create a Devtron app](./create-application.md)
+* [Create a Helm app](./deploy-chart/deployment-of-charts.md)
+* [Create a Job](./jobs/create-job.md)
+
+### Other Options
+
+There are additional options available for you:
+* **Search and filters** to make it easier for you to find applications.
+* **Export CSV** to download the data of Devtron apps (not supported for Helm apps and Argo CD apps).
+* **Sync button** to refresh the app listing.
+
+---
+
+## View External Helm App Listing
+
+:::tip Want to Manage your Existing Helm Release using Devtron?
+Apart from internal helm apps created in Devtron, you can also view your external Helm app listing. Moreover, you can manage their deployments using Devtron. Read [Migrate Helm Release to Devtron](../user-guide/creating-application/workflow/cd-pipeline.md#migrate-helm-release) to know more.
+:::
+
+:::caution Who Can Perform This Action?
+Users with view only permission or above for an application can view helm app listing.
+:::
+
+External Helm apps are Helm applications deployed outside of Devtron.
+
+1. Connect the cluster containing your external Helm apps in [Global Configurations → Clusters & Environments](./global-configurations/cluster-and-environments.md).
+
+2. Use the **Cluster** selection dropdown to choose the external cluster(s). You will see your external Helm apps under the **Helm Apps** tab.
+
+ 
+
+---
+
+
+## View External ArgoCD App Listing
+
+:::tip Want to Manage your Existing Argo CD Apps using Devtron?
+You can not only view your ArgoCD app list, but also manage their deployments using Devtron. Read [Migrate ArgoCD Apps to Devtron](../user-guide/creating-application/workflow/cd-pipeline.md#migrate-argo-cd-application) to know more.
+:::
+
+:::caution Who Can Perform This Action?
+Users need super-admin permission to view/enable/disable the ArgoCD listing.
+:::
+
+### Preface
+
+In Argo CD, a user manages one dashboard for one ArgoCD instance. Therefore, with multiple ArgoCD instances, the process becomes cumbersome for the user to manage several dashboards.
+
+With Devtron, you get an entire Argo CD app listing in one place. This listing includes:
+* Apps deployed using [GitOps](../reference/glossary.md#gitops) on Devtron
+* Other Argo CD apps present in your cluster
+
+
+
+### Advantages
+
+Devtron also bridges the gap for ArgoCD users by providing additional features as follows:
+
+* **Resource Scanning**: You can scan for vulnerabilities using Devtron's [resource scanning](../user-guide/security-features.md#from-app-details) feature.
+
+* **Single-pane View**: All Argo CD apps will show details such as their app status, environment, cluster, and namespace together in one dashboard.
+
+* **Feature-rich Options**: Clicking an Argo CD app will give you access to its logs, terminal, events, manifest, available resource kinds, pod restart log, and many more.
+
+:::info Additional References
+[ArgoCD: Standalone Configuration vs Devtron Configuration](https://devtron.ai/blog/argocd-standalone-configuration-vs-devtron-configuration/#argocd-installation-and-configuration)
+:::
+
+### Prerequisite
+The cluster in which Argo CD apps exist should be added in **Global Configurations** → **Clusters and Environments**
+
+### Feature Flag
+
+> **`ENABLE_EXTERNAL_ARGO_CD: "true"`**
+
+### Enabling ArgoCD App Listing
+
+
+
+1. Go to the **Resource Browser** of Devtron.
+
+2. Select the cluster (in which your Argo CD app exists).
+
+3. Type `ConfigMap` in the 'Jump to Kind' field.
+
+4. Search for `dashboard-cm` using the available search bar and click it.
+
+5. Click **Edit Live Manifest**.
+
+6. Set the feature flag **ENABLE_EXTERNAL_ARGO_CD** to **"true"**
+
+7. Click **Apply Changes**.
+
+8. Go back to the 'Jump to Kind' field and type `Pod`.
+
+9. Search for `dashboard` pod and use the kebab menu (3 vertical dots) to delete the pod.
+
+10. Go to **Applications** and refresh the page. A new tab named **ArgoCD Apps** will be visible.
+
+11. Select the cluster(s) from the dropdown to view the Argo CD apps available in the chosen cluster(s).
+
+ 
+
+---
+
+## View External FluxCD App Listing
+
+:::caution Who Can Perform This Action?
+Users need super-admin permission to view/enable/disable the FluxCD listing.
+:::
+
+### Preface
+
+Flux CD doesn't have any official dashboard; however, Devtron supports the listing of your [Flux CD](https://fluxcd.io/) apps in one dashboard. Here, the [advantages](#advantages) are same as those of [ArgoCD app listing](#view-external-argocd-app-listing).
+
+
+
+### Prerequisite
+The cluster in which Flux CD apps exist should be added in **Global Configurations** → **Clusters and Environments**
+
+### Feature Flag
+
+> **`FEATURE_EXTERNAL_FLUX_CD_ENABLE: "true"`**
+
+### Enabling FluxCD App Listing
+
+:::info Tip
+You may refer the steps mentioned in the [Enabling ArgoCD App Listing](#enabling-argocd-app-listing) section since the procedure is similar.
+:::
+
+Using Devtron's Resource Browser, add the [feature flag](#feature-flag-1) in the Dashboard ConfigMap as shown below.
+
+
+
+After successfully executing all the steps, a new tab named **FluxCD Apps** will be visible. Select the cluster(s) from the dropdown to view the Flux CD apps available in the chosen cluster(s).
+
+
+
+(Optional) Once you choose cluster(s), you may use the **Template Type** dropdown to further filter your Flux CD app listing based on its type, i.e., [Kustomization](https://fluxcd.io/flux/components/kustomize/kustomizations/) or [Helmrelease](https://fluxcd.io/flux/components/helm/helmreleases/).
+
+Click any Flux CD app to view its details as shown below.
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/bulk-update.md b/versioned_docs/version-1.7/user-guide/bulk-update.md
new file mode 100755
index 0000000000..4449597953
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/bulk-update.md
@@ -0,0 +1,107 @@
+---
+id: bulk-update
+title: Bulk Updates
+sidebar_label: Bulk Updates
+---
+
+# Bulk Updates
+This feature helps you to update Deployment Template, ConfigMaps & Secrets for multiple apps in one go! You can filter the apps on the basis of environments, global flag, and app names(we provide support for both substrings included and excluded in the app name).
+## Overview
+
+Need to make some common changes across multiple devtron applications?
+**Bulk Edit** allows you to do that.
+Eg. You can change the value for `MaxReplicas` in Deployment Templates of multiple Devtron applications or you can add key-value pairs in multiple ConfigMaps & Secrets. However, you might not be able to change the values of locked keys. Refer [Lock Deployment Configuration](./global-configurations/lock-deployment-config.md) to know more.
+
+## Support
+Bulk edit is currently supported for:
+ - Deployment Template
+ - ConfigMaps
+ - Secrets
+
+
+## Steps:
+
+1. Click on the `Bulk Edit` option in the main navigation. This is where you can write and execute scripts to perform bulk updates in Devtron objects.
+
+ 
+
+2. To help you get started, a script template is provided under the `See Samples` section.
+
+ 
+
+3. Copy and Paste the `Sample Script` in the code editor and make desired changes. Refer `Payload Configuration` in the Readme to understand the parameters.
+
+ 
+
+### Example
+Example below will select all applications having `abc and xyz` present in their name and out of those will exclude applications having `abcd and xyza` in their name. Since global flag is false and envId 23 is provided, it will make changes in envId 23 and not in global deployment template for this application.
+
+If you want to update globally then please set `global: true`. If you have provided an envId but deployment template, ConfigMap or Secret is not overridden for that particular environment then it will not apply the changes.
+Also, of all the provided names of ConfigMaps/secrets, for every app & environment override only the names that are present in them will be considered.
+
+
+### Sample Script
+
+This is the piece of code which works as the input and has to be pasted in the code editor for achieving bulk updation
+task.
+
+```
+apiVersion: batch/v1beta1
+kind: Application
+spec:
+ includes:
+ names:
+ - "%abc%"
+ - "%xyz%"
+ excludes:
+ names:
+ - "%abcd%"
+ - "%xyza%"
+ envIds:
+ - 23
+ global: false
+ deploymentTemplate:
+ spec:
+ patchJson: '[{ "op": "add", "path": "/MaxSurge", "value": 1 },{"op": "replace","path":"/GracePeriod","value": "30"}]'
+ configMap:
+ spec:
+ names:
+ - "configmap1"
+ - "configmap2"
+ - "configmap3"
+ patchJson: '[{ "op": "add", "path": "/{key}", "value": "{value}" },{"op": "replace","path":"/{key}","value": "{value}"}]'
+ secret:
+ spec:
+ names:
+ - "secret1"
+ - "secret2"
+ patchJson: '[{ "op": "add", "path": "/{key}", "value": "{value}" },{"op": "replace","path":"/{key}","value": "{value}"}]'
+```
+
+
+### Payload Configuration
+The following tables list the configurable parameters of the Payload component in the Script and their description along with example. Also, if you do not need to apply updates on all the tasks, i.e. Deployment Template, ConfigMaps & Secrets, leave the Spec object empty for that respective task.
+
+| Parameter | Description | Example |
+| -------------------------- | ---------------------------------- | ---------------------------------------------------------- |
+|`includes.names ` | Will filter apps having exact string or similar substrings | `["app%","%abc", "xyz"]` (will include all apps having `"app%"` **OR** `"%abc"` as one of their substring, example - app1, app-test, test-abc etc. **OR** application with name xyz) |
+| `excludes.names` | Will filter apps not having exact string or similar substrings. | `["%z","%y", "abc"]` (will filter out all apps having `"%z"` **OR** `"%y"` as one of their substring, example - appz, test-app-y etc. **OR** application with name abc) |
+| `envIds` | List of envIds to be updated for the selected applications. | `[1,2,3]` |
+| `global` | Flag to update global deployment template of applications. | `true`,`false` |
+| `deploymentTemplate.spec.patchJson` | String having the update operation(you can apply more than one changes at a time). It supports [JSON patch ](http://jsonpatch.com/) specifications for update. | `'[ { "op": "add", "path": "/MaxSurge", "value": 1 }, { "op": "replace", "path": "/GracePeriod", "value": "30" }]'` |
+| `configMap.spec.names` | Names of all ConfigMaps to be updated. | `configmap1`,`configmap2`,`configmap3` |
+| `secret.spec.names` | Names of all Secrets to be updated. | `secret1`,`secret2`|
+| `configMap.spec.patchJson` / `secret.spec.patchJson` | String having the update operation for ConfigMaps/Secrets(you can apply more than one changes at a time). It supports [JSON patch ](http://jsonpatch.com/) specifications for update. | `'[{ "op": "add", "path": "/{key}", "value": "{value}" },{"op": "replace","path":"/{key}","value": "{value}"}]'`(Replace the `{key}` part to the key you want to perform operation on & the `{value}`is the key's corresponding value |
+
+
+
+4. Once you have modified the script, you can click on the `Show Impacted Objects` button to see the names of all applications that will be modified when the script is `Run`.
+
+ 
+
+5. Click on the `Run` button to execute the script. Status/Output of the script execution will be shown in the `Output` section of the bottom drawer.
+
+ 
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/cloning-application.md b/versioned_docs/version-1.7/user-guide/cloning-application.md
new file mode 100755
index 0000000000..2380ddd7ea
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/cloning-application.md
@@ -0,0 +1,34 @@
+---
+id: cloning-application
+title: Cloning Application
+sidebar_label: Cloning Application
+hide_table_of_contents: true
+---
+
+# Cloning Application
+
+Click on `Create New` and the select `Custom app` to create a new application.
+
+
+
+ As soon you click on `Custom app`, you will get a popup window on screen where you have to enter `app name` and `project` for the application. there are two radio buttons present on the popup window, one is for `Blank app` and another one is for `Clone an existing app`. For cloning an existing application, select the second one. After this, one more drop-down will appear on the window from which you can select the application that you want to clone. For this, you will have to type minimum three character to see the matching results in the drop-down. After typing the matching characters, select the application that you want to clone. You also can add additional information about the application (eg. `created by`, `Created on`) using `tags` (only key:value allowed).
+
+
+
+| Key | Description |
+| :--- | :--- |
+| `App Name` | Name of the new app you want to Create |
+| `Project` | Project name |
+| `Select an app to clone` | Select the application that you want to clone |
+| `Tags` | Additional information about the application |
+
+Now click on `Clone App` to clone the selected application.
+
+
+
+New application with a duplicate template is created.
+
+:::caution
+When cloning an application with GitOps configuration, the configuration itself is not copied. To set up the configuration for your new application, refer [GitOps Configuration](./creating-application/gitops-config.md) guide.
+:::
+
diff --git a/versioned_docs/version-1.7/user-guide/command-bar.md b/versioned_docs/version-1.7/user-guide/command-bar.md
new file mode 100755
index 0000000000..4352eda9f7
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/command-bar.md
@@ -0,0 +1,49 @@
+---
+hidden: true
+---
+
+# Command bar
+## Why command bar?
+The command bar is designed to enable you to navigate across the devtron dashboard without having to click around the screen.
+
+
+
+Top-level categories (eg. app, chart, security, global-config) are auto-filled depending upon your location on the Devtron dashboard.
+
+> You can clear the top-level category to navigate within other category locations.
+
+### Shortcuts
+| Action | Keys |
+| :--- | :--- |
+| Open Command bar | `Cmd/Ctrl` + `/` |
+| Navigate | `↓` `↑`|
+| Explore nested options | `→` |
+| Navigate to a screen | `Enter` |
+
+
+
+### How to use the command bar (Eg. Navigate to Workflow editor of an App.)
+
+
+
+
+
+
+
+### Steps to use
+
+1. Open command bar by clicking the 🔍 search icon on left navbar or pressing `Cmd/Ctrl` + `/`
+
+2. Start typing the app name you're looking for.
+
+3. Navigate using `↓` `↑` between the matching results and press `→` to view nested options.
+
+ > Note: Pressing Enter on a highlighted option will navigate to the selected page location.
+
+4. In this case, `app / dashboard / configure / workflow-editor` will navigate to the Workflow editor in dashboard application.
+
+
+
+Similarly, you can use the command bar to navigate around the Devtron dashboard without a click.
+
+We would love to know your experience with the command bar. Jump in to the [Devtron Discord Community](https://discord.gg/jsRG5qx2gp)
diff --git a/versioned_docs/version-1.7/user-guide/create-application.md b/versioned_docs/version-1.7/user-guide/create-application.md
new file mode 100755
index 0000000000..58b22a979a
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/create-application.md
@@ -0,0 +1,47 @@
+---
+id: create-application
+title: Create a New Application
+sidebar_label: Create a New Application
+---
+
+# Create a New Application
+
+* On the Devtron dashboard, select **Applications**.
+* On the upper-right corner of the screen, click **Create**.
+* Select **Custom app** from the drop-down list.
+
+
+
+A new application can be created from one of the following options:
+
+* Custom App
+* [From Chart Store](../user-guide/deploy-chart/README.md)
+
+
+## Create Custom App
+
+To create a new application from the custom app, select **Custom app**.
+
+
+
+* In the **Create application** window, enter an **App Name** and select a **Project**.
+* Select either:
**Create from scratch** to create an application from scratch
, or
**Clone existing application** to clone an existing application.
+* If you select **Create from scratch**, select the project from the drop-down list. `Note`: You have to add [project under Global Configurations](./global-configurations/projects.md). Only then, it will appear in the drop-down list here.
+* If you select **Clone existing application**, select an app you want to clone from and the project from the drop-down list. `Note`: You have to add [project under Global Configurations](./global-configurations/projects.md). Only then, it will appear in the drop-down list here.
+
+
+## Tags
+
+`Tags` are key-value pairs. You can add one or multiple tags in your application.
+
+**Propagate Tags**
+When tags are propagated, they are considered as labels to Kubernetes resources. Kubernetes offers integrated support for using these labels to query objects and perform bulk operations e.g., consolidated billing using labels. You can use these tags to filter/identify resources via CLI or in other Kubernetes tools.
+
+
+
+* Click `+ Add tag` to add a new tag.
+* Click the symbol  on the left side of your tag to propagate a tag. `Note`: Dark grey colour in symbol specifies that the tags are propagated.
+* To remove the tags from propagation, click the symbol  again.
+* Click `Save`.
+
+
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/README.md b/versioned_docs/version-1.7/user-guide/creating-application/README.md
new file mode 100755
index 0000000000..55f462a46a
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/README.md
@@ -0,0 +1,32 @@
+---
+id: README
+title: App Configuration
+sidebar_label: App Configuration
+hide_table_of_contents: true
+---
+
+# App Configuration
+
+**Please configure Global Configurations before moving ahead with App Configuration**
+
+
+
+**Parts of Documentation**
+
+[Git Repository](git-material.md)
+
+[Build Configuration](docker-build-configuration.md)
+
+[Base Configurations](./base-config/README.md)
+
+[GitOps Configuration](gitops-config.md)
+
+[Workflow Editor](workflow/README.md)
+
+[External Links](external-links.md)
+
+[Environment Overrides](environment-overrides.md)
+
+[Deleting Application](../deleting-application.md)
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/app-metrics.md b/versioned_docs/version-1.7/user-guide/creating-application/app-metrics.md
new file mode 100755
index 0000000000..05c86d346a
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/app-metrics.md
@@ -0,0 +1,267 @@
+---
+id: app-metrics
+title: Application Metrics
+sidebar_label: Application Metrics
+---
+
+# Application Metrics
+
+## Introduction
+
+Application Metrics are the indicators used to evaluate the performance and efficiency of your application. It can be enabled in the Devtron platform to see your application's metrics.
+
+
+
+---
+
+## Types of Metrics
+
+| Metrics | Description |
+| :----------------| :---------------------------------------------------------- |
+| **CPU usage** | Overall CPU utilization per pod and aggregated |
+| **Memory Usage** | Overall memory utilization per pod and aggregated |
+| **Throughput** | Number of requests processed per minute |
+| **Latency** | Delay between request and response, measured in percentiles |
+
+---
+
+## Set Up Application Metrics
+
+:::caution Note
+Application metrics can only be enabled if your application is deployed using Devtron Deployment Charts and not [Custom Deployment Charts](../global-configurations/deployment-charts.md).
+:::
+
+### Step 1: Install Monitoring (Grafana) Integration
+
+#### For OSS and Self-Managed Enterprise
+
+:::caution Who Can Perform This Action?
+Only super admin users can install Devtron integrations.
+:::
+
+To use the Grafana dashboard, you need to first install the integration from the [Devtron Stack Manager](../integrations/README.md). Refer [Monitoring (Grafana) Integration](../integrations/grafana.md) to learn more.
+
+#### For Devtron-Managed Enterprise
+
+If you want to enable Grafana Integration, email us at [enterprise@devtron.ai](mailto:enterprise@devtron.ai) or reach out to your Devtron representative.
+
+
+### Step 2: Install Prometheus
+
+:::caution Who Can Perform This Action?
+Users need to have [Admin role](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above to deploy a chart.
+:::
+
+:::caution Note
+Ensure [GitOps](../global-configurations/gitops.md) is configured before deploying Prometheus. If not, Prometheus will default to being deployed via Helm.
+:::
+
+1. Go to the **Chart Store** and search for `prometheus`. Use the Prometheus community's `kube-prometheus-stack` chart to deploy Prometheus.
+
+ 
+
+2. After selecting the chart, configure these values as needed before deployment.
+
+ ```yaml
+ kube-state-metrics:
+ metricLabelsAllowlist:
+ - pods=[*]
+ ```
+
+
+
+ ```yaml
+ serviceMonitorSelectorNilUsesHelmValues: false
+ podMonitorSelectorNilUsesHelmValues: false
+ ```
+
+
+
+ Search for the above parameters, and update them as shown (or customize as needed).
+
+ 
+
+ 
+
+3. Enable `upgradeJob` parameter to install CRDs:
+
+ Since Helm does not automatically apply CRDs, you need to enable the `upgradeJob` parameter in the Helm chart to ensure CRDs are applied before deploying Prometheus.
+
+ In the Prometheus Helm chart settings, locate the `upgradeJob` parameter and set it to `true` if it is `false`.
+
+ 
+
+4. After enabling the parameter, click **Deploy Chart**.
+
+:::caution Common Pitfall: Prometheus Deployment Timeout due to Failed CRDs
+While deploying `kube-prometheus-stack` chart, the deployment status may show as **Timed out**, and some CustomResourceDefinitions (CRDs) may appear as **Failed**.
+
+To solve it, refer [Troubleshoot Issues](#troubleshoot-issues)
+
+:::
+
+### Step 3: Set Up Prometheus Endpoint
+
+:::caution Who Can Perform This Action?
+Only super admin users can set up Prometheus endpoint in a cluster.
+:::
+
+1. Once Prometheus is installed, go to its **App Details** and navigate to **Networking** → **Service** in the K8s resources. Expand the Prometheus server service to see the endpoints.
+
+2. Copy the URL of the `kube-prometheus` service as shown in the image below.
+
+ 
+
+3. To set Prometheus as a data source in Grafana, navigate to **Global Configurations** → **Clusters & Environments**, select your cluster, and edit its settings.
+
+ 
+
+4. Now to set up the Prometheus endpoint:
+ 1. Enable the `See metrics for applications in this cluster` option, as shown in the image below.
+ 2. Paste the copied URL into the Prometheus endpoint field, ensuring it includes `http://`
+ 3. Click **Update Cluster** to save the changes.
+
+ 
+
+
+### Step 4: Enable Application Metrics
+
+:::caution Who Can Perform This Action?
+Users need to have [Admin role](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above to enable application metrics.
+:::
+
+After adding the endpoint in your preferred cluster, **CPU usage** and **Memory usage** metrics will be visible in the **App Details** page for all the Devtron apps in that cluster (it may take a few minutes).
+
+
+
+To enable **Throughput** and **Latency** metrics in Devtron, follow these steps:
+
+:::caution Note
+**Throughput** and **Latency** metrics will only display data if there is active traffic (i.e., incoming requests) to your application. If there is no traffic, these metrics will show `No data`.
+:::
+
+1. Open your Devtron app.
+
+2. Go to its **Configurations** (tab) → **Base Configurations** → **Deployment Template**.
+
+3. Enable **Application Metrics** in the Deployment Template as shown below and save the changes.
+
+ 
+
+4. Now, you can track all your application metrics by navigating to **Applications** and going to the **App Details** page of your Devtron App as shown below.
+
+ 
+
+:::caution Note
+If your environment is [Overridden](../creating-application/environment-overrides.md), you need to enable the Application Metrics at the environment override deployment template instead of the base deployment template.
+:::
+
+---
+
+## Troubleshoot Issues
+
+
+Facing Prometheus Deployment Timeout due to Failed CRDs
+
+While deploying `kube-prometheus-stack` chart, the deployment status may show as **Timed out**, and some CustomResourceDefinitions (CRDs) may appear as **Failed**.
+
+
+
+
+
+**This behavior is expected and do not require any action from you.**
+
+This occurs because certain Prometheus CRDs are large in size, which can lead to temporary sync issues during deployment, but, this does not impact the functionality of the Prometheus components.
+
+ArgoCD handles such cases automatically and the `kube-prometheus-stack` will continue to function as expected.
+
+
+
+Not able to see deployment metrics on production environment or Not able to enable application-metrics
+
+Update the rollout CRDs to the latest version, run the following command:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/devtron-labs/devtron/main/manifests/yamls/rollout.yaml -n devtroncd
+```
+
+
+
+
+ Grafana dashboards not visible in App Details page even after adding prometheus endpoint or Graphs showing error panel with id 2 not found
+
+If the graphs are not visible check if Prometheus is configured properly. Then go to **Global Configurations** → **Clusters & Environments** → Click on any environment for the cluster where you added Prometheus endpoint and simply click `Update`.
+If the charts are still not visible, try visiting the URL: `/grafana?orgId=2`
+If you see `Not Found` on this page, then follow all the given steps or if the page is accessible, and you are getting `panel with id 2 not found` then follow from step 6:
+1. Get Grafana password using `kubectl -n devtroncd get secret devtron-secret -o jsonpath='{.data.GRAFANA_PASSWORD}' | base64 -d`
+
+2. `kubectl run --rm -it --image quay.io/devtron/k8s-utils:tutum-curl curl` Run this command, and it will create a pod for using `curl`
+
+3. Copy the following and change `grafana-password` with your password of Grafana and change the value of `prometheusUrl` with your Prometheus endpoint, and run in the pod that we created above in step 2.
+
+ ``` bash
+ cat << EOF
+ grafanaUrl="http://admin:grafana-password@devtron-grafana.devtroncd/grafana"
+ prometheusUrl="http://prometheus.example.com"
+
+ ORG_ID=$( curl -d '{"name":"devtron-metrics-view"}' -H "Content-Type: application/json" -X POST "${grafanaUrl}/api/orgs" )
+
+ echo $ORG_ID
+
+ curl -X POST "${grafanaUrl}/api/user/using/2";
+
+ curl -X PUT -H "Content-Type: application/json" -d '{"homeDashboardId":0,"theme":"light","timezone":"browser"}' "${grafanaUrl}/api/org/preferences";
+
+ curl "${grafanaUrl}/api/datasources" -H 'content-type: application/json' -H 'x-grafana-org-id: 2' --data '{"name":"Prometheus-devtron-demo","type":"prometheus","access":"proxy","isDefault":true}'
+
+ curl "${grafanaUrl}/api/datasources/2" -X PUT \
+ -H 'content-type: application/json' \
+ -H 'x-grafana-org-id: 2' \
+ --data '{"id": 2 ,
+ "orgId": 2,
+ "name":"Prometheus-devtron-demo","type":"prometheus","access":"proxy",
+ "url":${prometheusUrl},
+ "basicAuth":false,"jsonData":{},"version":1}'
+ EOF
+ ```
+
+4. Now visit `/grafana?orgId=2` again, and you'll see Grafana login page. Login using username `admin` and password from step 1 and check if Prometheus URL is updated in data sources. If not, update it in the default data source.
+
+5. Now from Devtron UI, update any of the environment again and its data source will be created automatically.
+
+6. In Grafana UI you need to be logged in and Go to Dashboards → Manage then click `Import` and Import the given dashboards one by one.
+
+ ```
+ https://grafana.com/api/dashboards/13322/revisions/4/download
+ https://grafana.com/api/dashboards/13320/revisions/4/download
+ https://grafana.com/api/dashboards/13325/revisions/4/download
+ https://grafana.com/api/dashboards/13321/revisions/6/download
+ ```
+After that, your issue should be resolved, and you should be able to see all the graphs on UI.
+
+
+
+
+
+If CPU metrics are not showing but memory metrics are visible in graphs.
+
+Do the following:-
+
+1. Go to Grafana and Login with the credentials.
+2. Edit the CPU graphs and remove `image!=””` from the query.
+3. Save the dashboard.
+
+CPU metrics should start showing up in a while.
+
+
+
+
+
+When app metrics is not coming on grafana and devtron dashboard, set the value of the following parameter as false in kube prometheus stack values.
+
+
+```
+serviceMonitorSelectorNilUsesHelmValues: false
+```
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/README.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/README.md
new file mode 100755
index 0000000000..af5b3ee40d
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/README.md
@@ -0,0 +1,31 @@
+---
+id: README
+title: Base Configurations
+sidebar_label: Base Configurations
+---
+
+# Base Configurations
+
+## Introduction
+
+Base configurations help you share common configurations across environments, bootstrap new environments and pipelines, or use scoped variables (placeholders) to templatize your configurations.
+
+Base Configurations in Devtron consists of:
+
+* A [Deployment Template](../../../reference/glossary.md#deployment-template) for defining application specifications
+
+* [ConfigMaps](../../../reference/glossary.md#configmaps) for managing non-sensitive data (e.g., `username`)
+
+* [Secrets](../../../reference/glossary.md#secrets) for securely handling sensitive information (e.g., `password`, `API key`).
+
+In Devtron, these are the core settings that dictate an application's behavior.
+
+
+
+## Next Steps
+
+* [Configuring Deployment Template](deployment-template.md)
+
+* [Creating ConfigMaps](config-maps.md)
+
+* [Creating Secrets](secrets.md)
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/config-maps.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/config-maps.md
new file mode 100755
index 0000000000..da1f00bee2
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/config-maps.md
@@ -0,0 +1,168 @@
+---
+id: config-maps
+title: ConfigMaps
+sidebar_label: ConfigMaps
+---
+
+# ConfigMaps
+
+A ConfigMap stores key-value pairs (non-sensitive data) that your applications can use as environment variables or mounted files. You can update configurations without modifying or rebuilding your container images, thus making the deployments more efficient.
+
+## Add ConfigMap
+
+1. Go to **Applications** → **Devtron Apps** (tab) → (Select Your App)
+
+2. Go to **Configurations** (tab) → **Base Configurations**.
+
+ 
+
+3. Click the **+** button next to **ConfigMaps**.
+
+ 
+
+4. **Data Type** - Choose between the following data types:
+
+ * [Kubernetes ConfigMap](#kubernetes-configmap) - When you want to create a ConfigMap that is specific to an application and is managed within the cluster
+
+ * [Kubernetes External ConfigMap](#kubernetes-external-configmap) - When you want to create a ConfigMap outside the cluster to use it across environments and applications
+
+### Kubernetes ConfigMap
+
+Kubernetes ConfigMap stores and manages non-sensitive data such as application settings, environment variables, etc. When you want to create a configuration that is specific to a cluster or an environment, you create a Kubernetes ConfigMap.
+
+Follow the instructions below to create a Kubernetes ConfigMap:
+
+1. Select **Kubernetes ConfigMap** as the Data Type.
+
+2. **Name** - Provide a name to your ConfigMap (cannot be changed later).
+
+ 
+
+3. **Mount data as** - Select how you want to mount the ConfigMap:
+
+ * **Environment Variable** – Select this option if you want to inject Environment Variables in pods using ConfigMap.
+
+ * **Data Volume** – Select this option, if you want to configure a Data Volume that is accessible to Containers running in a pod and provide a Volume mount path. Go to [Data Volume](#mount-data-as-data-volume) to know more.
+
+4. Enter data in:
+ * **GUI mode** – User-friendly interface. Click **+Add** button and enter the **Key** and **Value** fields without quotes.
+ * **YAML mode** – Raw YAML for entering key-value pairs in the format **`key: value`**. Boolean and numeric values must be wrapped in double quotes.
+
+
+
+5. You may [perform a dry run](#perform-a-dry-run) before clicking **Save**.
+
+
+### Kubernetes External ConfigMap
+
+Kubernetes External ConfigMap is usually created to reuse a configMap outside the cluster (e.g., from another namespace or an application). You create an external ConfigMap when you want to use the same ConfigMap across multiple applications or environments. Follow the below steps to create an external ConfigMap:
+
+1. Select **Kubernetes External ConfigMap** as the Data Type.
+
+2. **Name** - Since you are using Kubernetes External ConfigMap, make sure you give the name of ConfigMap the same as the name given using `kubectl create configmap ` command, otherwise, it might result in an error during the build.
+
+3. Mount data as: **Environment Variable** or [Data Volume](#mount-data-as-data-volume)
+
+4. Click **Save**.
+
+---
+
+## Mount Data as Data Volume
+
+### Mount ConfigMap Data
+
+
+
+In the above example, we have seen how to pass environment variables in your ConfigMap. Additionally, there is an option to mount a ConfigMap by passing its content to a file. The content could be a plain text, json, yaml, bash script, etc. You can do so by selecting the `Data Volume` option in **Mount data as**.
+
+The key of the ConfigMap should be your filename and the value of the ConfigMap should be your file content. In the below example, you `file.json` is the key, and the json content is the value of that ConfigMap (below the pipe (**|**) symbol). This file will be created on your specified [volume mount path](#volume-mount-path).
+
+
+
+### Volume Mount Path
+
+Enter the folder path where the data volume should be mounted for it to be accessible to the containers running in a pod. Your keys will be mounted as files to that volume.
+
+### Set Sub Path
+
+When mounting multiple files to the same location, you can use the **Set Sub Path** option to control how the files are handled. This setting allows you to control whether existing files are overwritten or preserved when mounting new files.
+
+* If **Set Sub Path** is enabled, the system will preserve existing files in the [specified path](#volume-mount-path) and append the new file using the file name as a sub-path.
+
+* If **Set Sub Path** is disabled (unchecked), the system will delete any files already present in the [specified path](#volume-mount-path) and then mount the new files.
+
+:::info Note
+In case of Kubernetes ConfigMap, all keys will be mounted as files on the specified path.
+
+In case of Kubernetes External ConfigMap, manually specify the keys which should be mounted as files.
+
+:::
+
+
+### Set File Permission
+
+The **Set File Permission** option applies permissions at the ConfigMap level, not to individual keys within the ConfigMap. Enabling this option will let you enter a 3-digit standard permission value to control access to the file.
+
+The 3-digit numeric value represents the permission settings for the file:
+
+* **First digit**: Owner permissions (user).
+* **Second digit**: Group permissions.
+* **Third digit**: Other users' permissions.
+
+| **Permission** | **Description** |
+|----------------|------------------------------------------------|
+| **r** (read) | Grants the ability to read the file. |
+| **w** (write) | Grants the ability to modify the file. |
+| **x** (execute)| Grants the ability to execute the file as a program. |
+
+For example, **755** means:
+* Owner can read, write, and execute (7),
+* Group can read and execute (5),
+* Others can read and execute (5).
+
+---
+
+## Perform a Dry Run
+
+Before saving your configured ConfigMap, you can use the **Dry Run** option (as shown below) to preview the final Kubernetes manifest.
+
+This feature helps you verify your configurations, detect issues, and ensure correctness.
+
+
+
+Your configurations will appear in the left pane, while the right pane will display a section named `Manifest generated from merged` showing the computed Kubernetes manifest.
+
+---
+
+## Update ConfigMap
+
+1. Click your ConfigMap available inside the list of **ConfigMaps** inside **Base Configurations**.
+2. Modify its values.
+3. Click **Update**.
+
+:::caution Note
+You cannot change the name of a ConfigMap. Create a new ConfigMap instead.
+:::
+
+
+
+---
+
+## Delete ConfigMap
+
+You may delete a ConfigMap if not in use anymore. Once a ConfigMap is deleted, it will not be used in future deployments.
+
+1. Click your ConfigMap available inside the list of **ConfigMaps** inside **Base Configurations**.
+2. On the right side, click the kebab menu (3 vertical dots).
+3. Click **Delete**.
+4. Confirm the deletion in the dialogbox.
+
+
+
+---
+
+## Edit a Protected ConfigMap
+
+Any changes made to the protected base configurations (Deployment Template, ConfigMap, Secret) will require approval if an [approval policy](../../../user-guide/global-configurations/approval-policy.md) is enforced.
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/README.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/README.md
new file mode 100755
index 0000000000..d522bb5361
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/README.md
@@ -0,0 +1,19 @@
+---
+id: README
+title: Types of Deployment Templates
+sidebar_label: Types of Deployment Templates
+hide_table_of_contents: true
+---
+
+# Types of Deployment Templates
+
+In Devtron, the following deployment charts are available for you to use for your application:
+
+* [Deployment](deployment.md)
+* [Rollout Deployment](rollout-deployment.md)
+* [Job and Cronjob](job-and-cronjob.md)
+* [StatefulSets](statefulset.md)
+
+
+
+Each template serves a specific purpose; therefore, choose one based on your application’s requirements.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/deployment.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/deployment.md
new file mode 100755
index 0000000000..92f057c53d
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/deployment.md
@@ -0,0 +1,1137 @@
+---
+id: deployment
+title: Deployment
+sidebar_label: Deployment
+---
+
+# Deployment
+
+This chart creates a deployment that runs multiple replicas of your application and automatically replaces any instances that fail or become unresponsive. It does not support Blue/Green and Canary deployments. This is the default deployment chart. You can select `Deployment` chart when you want to use only basic use cases which contain the following:
+
+* Create a Deployment to rollout a ReplicaSet. The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not.
+* Declare the new state of the Pods. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment.
+* Rollback to an earlier Deployment revision if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment.
+* Scale up the Deployment to facilitate more load.
+* Use the status of the Deployment as an indicator that a rollout has stuck.
+* Clean up older ReplicaSets that you do not need anymore.
+
+
+
+You can define application behavior by providing information in the following sections:
+
+| Key | Descriptions |
+| :--- | :--- |
+| `Chart version` | Select the Chart Version using which you want to deploy the application. Refer [Chart Version](../../../creating-application/base-config/deployment-template.md#choose-a-chart-version) section for more detail. |
+| `GUI` | You can perform a basic deployment configuration for your application in the **GUI** section instead of configuring the YAML file. Refer [Basic Configuration](../../../creating-application/base-config/deployment-template.md#using-gui) section for more detail.|
+| `YAML` | If you want to do additional configurations, then click **YAML** for modifications. Refer [YAML](#yaml) section for more detail. |
+| `Show application metrics` | You can enable `Show application metrics` to see your application's metrics-CPU Service Monitor usage, Memory Usage, Status, Throughput and Latency. Refer [Application Metrics](../../../creating-application/app-metrics.md) for more detail. |
+
+
+:::caution Note
+Super-admins can lock keys in deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
+:::
+
+---
+
+## YAML
+
+### Container Ports
+
+This defines ports on which application services will be exposed to other services
+
+```yaml
+ContainerPort:
+ - envoyPort: 8799
+ idleTimeout:
+ name: app
+ port: 8080
+ servicePort: 80
+ nodePort: 32056
+ supportStreaming: true
+ useHTTP2: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `envoyPort` | envoy port for the container |
+| `idleTimeout` | the duration of time that a connection is idle before the connection is terminated |
+| `name` | name of the port |
+| `port` | port for the container |
+| `servicePort` | port of the corresponding kubernetes service |
+| `nodePort` | nodeport of the corresponding kubernetes service |
+| `supportStreaming` | Used for high performance protocols like grpc where timeout needs to be disabled |
+| `useHTTP2` | Envoy container can accept HTTP2 requests |
+
+### EnvVariables
+```yaml
+EnvVariables: []
+```
+To set environment variables for the containers that run in the Pod.
+
+### EnvVariablesFromFieldPath
+```yaml
+EnvVariablesFromFieldPath:
+- name: ENV_NAME
+ fieldPath: status.podIP (example)
+```
+To set environment variables for the containers and fetching their values from pod-level fields.
+
+### Liveness Probe
+
+If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
+
+```yaml
+LivenessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the liveness needs to be checked |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for liveliness |
+| `periodSeconds` | It defines the time to check a given container for liveness |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the liveness probe |
+| `timeoutSeconds` | It defines the time for checking timeout |
+| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as live |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers, you can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+
+### MaxUnavailable
+
+```yaml
+ MaxUnavailable: 0
+```
+The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
+
+### MaxSurge
+
+```yaml
+MaxSurge: 1
+```
+The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count.
+The default value of "MaxSurge: " is 25%.
+
+### Min Ready Seconds
+
+```yaml
+MinReadySeconds: 60
+```
+This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
+
+### Readiness Probe
+
+If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
+
+```yaml
+ReadinessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the readiness needs to be checked |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for readiness |
+| `periodSeconds` | It defines the time to check a given container for readiness |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the readiness probe |
+| `timeoutSeconds` | It defines the time for checking timeout |
+| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as ready |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers, you can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+### Pod Disruption Budget
+
+You can create `PodDisruptionBudget` for each application. A PDB limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, an application would like to ensure the number of replicas running is never brought below the certain number.
+
+```yaml
+podDisruptionBudget:
+ minAvailable: 1
+```
+
+or
+
+```yaml
+podDisruptionBudget:
+ maxUnavailable: 50%
+```
+
+You can specify either `maxUnavailable` or `minAvailable` in a PodDisruptionBudget and it can be expressed as integers or as a percentage.
+
+| Key | Description |
+| :--- | :--- |
+| `minAvailable` | Evictions are allowed as long as they leave behind 1 or more healthy pods of the total number of desired replicas. |
+| `maxUnavailable` | Evictions are allowed as long as at most 1 unhealthy replica among the total number of desired replicas. |
+
+### Ambassador Mappings
+
+You can create ambassador mappings to access your applications from outside the cluster. At its core a Mapping resource maps a resource to a service.
+
+```yaml
+ambassadorMapping:
+ ambassadorId: "prod-emissary"
+ cors: {}
+ enabled: true
+ hostname: devtron.example.com
+ labels: {}
+ prefix: /
+ retryPolicy: {}
+ rewrite: ""
+ tls:
+ context: "devtron-tls-context"
+ create: false
+ hosts: []
+ secretName: ""
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable ambassador mapping else set false|
+| `ambassadorId` | used to specify id for specific ambassador mappings controller |
+| `cors` | used to specify cors policy to access host for this mapping |
+| `weight` | used to specify weight for canary ambassador mappings |
+| `hostname` | used to specify hostname for ambassador mapping |
+| `prefix` | used to specify path for ambassador mapping |
+| `labels` | used to provide custom labels for ambassador mapping |
+| `retryPolicy` | used to specify retry policy for ambassador mapping |
+| `corsPolicy` | Provide cors headers on flagger resource |
+| `rewrite` | used to specify whether to redirect the path of this mapping and where |
+| `tls` | used to create or define ambassador TLSContext resource |
+| `extraSpec` | used to provide extra spec values which not present in deployment template for ambassador resource |
+
+### Autoscaling
+
+This is connected to HPA and controls scaling up and down in response to request load.
+
+```yaml
+autoscaling:
+ enabled: false
+ MinReplicas: 1
+ MaxReplicas: 2
+ TargetCPUUtilizationPercentage: 90
+ TargetMemoryUtilizationPercentage: 80
+ extraMetrics: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable autoscaling else set false |
+| `MinReplicas` | Minimum number of replicas allowed for scaling |
+| `MaxReplicas` | Maximum number of replicas allowed for scaling |
+| `TargetCPUUtilizationPercentage` | The target CPU utilization that is expected for a container |
+| `TargetMemoryUtilizationPercentage` | The target memory utilization that is expected for a container |
+| `extraMetrics` | Used to give external metrics for autoscaling |
+
+### Flagger
+
+You can use flagger for canary releases with deployment objects. It supports flexible traffic routing with istio service mesh as well.
+
+```yaml
+flaggerCanary:
+ addOtherGateways: []
+ addOtherHosts: []
+ analysis:
+ interval: 15s
+ maxWeight: 50
+ stepWeight: 5
+ threshold: 5
+ annotations: {}
+ appProtocol: http
+ corsPolicy:
+ allowCredentials: false
+ allowHeaders:
+ - x-some-header
+ allowMethods:
+ - GET
+ allowOrigin:
+ - example.com
+ maxAge: 24h
+ createIstioGateway:
+ annotations: {}
+ enabled: false
+ host: example.com
+ labels: {}
+ tls:
+ enabled: false
+ secretName: example-tls-secret
+ enabled: false
+ gatewayRefs: null
+ headers:
+ request:
+ add:
+ x-some-header: value
+ labels: {}
+ loadtest:
+ enabled: true
+ url: http://flagger-loadtester.istio-system/
+ match:
+ - uri:
+ prefix: /
+ port: 8080
+ portDiscovery: true
+ retries: null
+ rewriteUri: /
+ targetPort: 8080
+ thresholds:
+ latency: 500
+ successRate: 90
+ timeout: null
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable canary releases using flagger else set false |
+| `addOtherGateways` | To provide multiple istio gateways for flagger |
+| `addOtherHosts` | Add multiple hosts for istio service mesh with flagger |
+| `analysis` | Define how the canary release should progress and at what interval |
+| `annotations` | Annotation to add on flagger resource |
+| `labels` | Labels to add on flagger resource |
+| `appProtocol` | Protocol to use for canary |
+| `corsPolicy` | Provide cors headers on flagger resource |
+| `createIstioGateway` | Set to true if you want to create istio gateway as well with flagger |
+| `headers` | Add headers if any |
+| `loadtest` | Enable load testing for your canary release |
+
+
+
+### Fullname Override
+
+```yaml
+fullnameOverride: app-name
+```
+`fullnameOverride` replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses `{app-name}-{environment-name}` as release fullname.
+
+### Image
+
+```yaml
+image:
+ pullPolicy: IfNotPresent
+```
+
+Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
+
+### imagePullSecrets
+
+`imagePullSecrets` contains the docker credentials that are used for accessing a registry.
+
+```yaml
+imagePullSecrets:
+ - regcred
+```
+regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry [https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) .
+
+### serviceAccount
+
+```yaml
+serviceAccount:
+ create: false
+ name: ""
+ annotations: {}
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Determines whether to create a ServiceAccount for pods or not. If set to `true`, a ServiceAccount will be created. |
+| `name` | Specifies the name of the ServiceAccount to use. |
+| `annotations` | Specify annotations for the ServiceAccount. |
+
+### HostAliases
+
+ the hostAliases field is used in a Pod specification to associate additional hostnames with the Pod's IP address. This can be helpful in scenarios where you need to resolve specific hostnames to the Pod's IP within the Pod itself.
+
+```yaml
+ hostAliases:
+ - ip: "192.168.1.10"
+ hostnames:
+ - "hostname1.example.com"
+ - "hostname2.example.com"
+ - ip: "192.168.1.11"
+ hostnames:
+ - "hostname3.example.com"
+```
+
+### Ingress
+
+This allows public access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ className: nginx
+ annotations: {}
+ hosts:
+ - host: example1.com
+ paths:
+ - /example
+ - host: example2.com
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+Legacy deployment-template ingress format
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ path: ""
+ host: ""
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `path` | Path name |
+| `host` | Host name |
+| `tls` | It contains security details |
+
+### Ingress Internal
+
+This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
+
+```yaml
+ingressInternal:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ hosts:
+ - host: example1.com
+ paths:
+ - /example
+ - host: example2.com
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `path` | Path name |
+| `host` | Host name |
+| `tls` | It contains security details |
+
+### Init Containers
+```yaml
+initContainers:
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+
+ - name: nginx
+ image: nginx:1.14.2
+ securityContext:
+ privileged: true
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+```
+Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to `true`.
+
+### Pause For Seconds Before Switch Active
+```yaml
+pauseForSecondsBeforeSwitchActive: 30
+```
+To wait for given period of time before switch active the container.
+
+### Resources
+
+These define minimum and maximum RAM and CPU available to the application.
+
+```yaml
+resources:
+ limits:
+ cpu: "1"
+ memory: "200Mi"
+ requests:
+ cpu: "0.10"
+ memory: "100Mi"
+```
+
+Resources are required to set CPU and memory usage.
+
+#### Limits
+
+Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
+
+#### Requests
+
+Requests are what the container is guaranteed to get.
+
+### Service
+
+This defines annotations and the type of service, optionally can define name also.
+
+```yaml
+ service:
+ type: ClusterIP
+ annotations: {}
+```
+
+### Volumes
+
+```yaml
+volumes:
+ - name: log-volume
+ emptyDir: {}
+ - name: logpv
+ persistentVolumeClaim:
+ claimName: logpvc
+```
+
+It is required when some values need to be read from or written to an external disk.
+
+### Volume Mounts
+
+```yaml
+volumeMounts:
+ - mountPath: /var/log/nginx/
+ name: log-volume
+ - mountPath: /mnt/logs
+ name: logpvc
+ subPath: employee
+```
+
+It is used to provide mounts to the volume.
+
+### Affinity and anti-affinity
+
+```yaml
+Spec:
+ Affinity:
+ Key:
+ Values:
+```
+
+Spec is used to define the desire state of the given container.
+
+Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
+
+Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
+
+#### Key
+
+Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+#### Values
+
+Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+### Tolerations
+
+```yaml
+tolerations:
+ - key: "key"
+ operator: "Equal"
+ value: "value"
+ effect: "NoSchedule|PreferNoSchedule|NoExecute(1.6 only)"
+```
+
+Taints are the opposite, they allow a node to repel a set of pods.
+
+A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
+
+Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
+
+### Arguments
+
+```yaml
+args:
+ enabled: false
+ value: []
+```
+
+This is used to give arguments to command.
+
+### Command
+
+```yaml
+command:
+ enabled: false
+ value: []
+```
+
+It contains the commands for the server.
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | To enable or disable the command |
+| `value` | It contains the commands |
+
+
+### Containers
+Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to `true`.
+
+```yaml
+ containers:
+ - name: nginx
+ image: nginx:1.14.2
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+```
+
+### Container Lifecycle Hooks
+
+Container lifecycle hooks are mechanisms that allow users to define custom actions to be performed at specific stages of a container's lifecycle i.e. PostStart or PreStop.
+
+```yaml
+containerSpec:
+ lifecycle:
+ enabled: false
+ postStart:
+ httpGet:
+ host: example.com
+ path: /example
+ port: 90
+ preStop:
+ exec:
+ command:
+ - sleep
+ - "10"
+```
+
+| Key | Description |
+| :--- | :--- |
+| `containerSpec` | containerSpec to define container lifecycle hooks configuration |
+| `lifecycle` | Lifecycle hooks for the container |
+| `enabled` | Set true to enable lifecycle hooks for the container else set false |
+| `postStart` | The postStart hook is executed immediately after a container is created |
+| `httpsGet` | Sends an HTTP GET request to a specific endpoint on the container |
+| `host` | Specifies the host (example.com) to which the HTTP GET request will be sent |
+| `path` | Specifies the path (/example) of the endpoint to which the HTTP GET request will be sent |
+| `port` | Specifies the port (90) on the host where the HTTP GET request will be sent |
+| `preStop` | The preStop hook is executed just before the container is stopped |
+| `exec` | Executes a specific command, such as pre-stop.sh, inside the cgroups and namespaces of the container |
+| `command` | The command to be executed is sleep 10, which tells the container to sleep for 10 seconds before it is stopped |
+
+### Prometheus
+
+```yaml
+ prometheus:
+ release: monitoring
+```
+
+It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case. It describes the state of the Prometheus.
+
+### rawYaml
+
+```yaml
+rawYaml:
+ - apiVersion: v1
+ kind: Service
+ metadata:
+ name: my-service
+ spec:
+ selector:
+ app: MyApp
+ ports:
+ - protocol: TCP
+ port: 80
+ targetPort: 9376
+ type: ClusterIP
+```
+Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
+
+### Grace Period
+
+```yaml
+GracePeriod: 30
+```
+Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the `GracePeriod`.
+
+A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
+
+There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
+
+
+### Server
+
+```yaml
+server:
+ deployment:
+ image_tag: 1-95a53
+ image: ""
+```
+
+It is used for providing server configurations.
+
+#### Deployment
+
+It gives the details for deployment.
+
+| Key | Description |
+| :--- | :--- |
+| `image_tag` | It is the image tag |
+| `image` | It is the URL of the image |
+
+### Service Monitor
+
+```yaml
+servicemonitor:
+ enabled: true
+ path: /abc
+ scheme: 'http'
+ interval: 30s
+ scrapeTimeout: 20s
+ metricRelabelings:
+ - sourceLabels: [namespace]
+ regex: '(.*)'
+ replacement: myapp
+ targetLabel: target_namespace
+```
+
+It gives the set of targets to be monitored.
+
+### Db Migration Config
+
+```yaml
+dbMigrationConfig:
+ enabled: false
+```
+
+It is used to configure database migration.
+
+### Istio
+
+These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
+
+```yaml
+istio:
+ enable: true
+
+ gateway:
+ enabled: true
+ labels:
+ app: my-gateway
+ annotations:
+ description: "Istio Gateway for external traffic"
+ host: "example.com"
+ tls:
+ enabled: true
+ secretName: my-tls-secret
+
+ virtualService:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio VirtualService for routing"
+ gateways:
+ - my-gateway
+ hosts:
+ - "example.com"
+ http:
+ - match:
+ - uri:
+ prefix: /v1
+ route:
+ - destination:
+ host: my-service-v1
+ subset: version-1
+ - match:
+ - uri:
+ prefix: /v2
+ route:
+ - destination:
+ host: my-service-v2
+ subset: version-2
+
+ destinationRule:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio DestinationRule for traffic policies"
+ subsets:
+ - name: version-1
+ labels:
+ version: "v1"
+ - name: version-2
+ labels:
+ version: "v2"
+ trafficPolicy:
+ connectionPool:
+ tcp:
+ maxConnections: 100
+ outlierDetection:
+ consecutiveErrors: 5
+ interval: 30s
+ baseEjectionTime: 60s
+
+ peerAuthentication:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio PeerAuthentication for mutual TLS"
+ selector:
+ matchLabels:
+ version: "v1"
+ mtls:
+ mode: STRICT
+ portLevelMtls:
+ 8080:
+ mode: DISABLE
+
+ requestAuthentication:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio RequestAuthentication for JWT validation"
+ selector:
+ matchLabels:
+ version: "v1"
+ jwtRules:
+ - issuer: "issuer-1"
+ jwksUri: "https://issuer-1/.well-known/jwks.json"
+
+ authorizationPolicy:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio AuthorizationPolicy for access control"
+ action: ALLOW
+ provider:
+ name: jwt
+ kind: Authorization
+ rules:
+ - from:
+ - source:
+ requestPrincipals: ["*"]
+ to:
+ - operation:
+ methods: ["GET"]
+```
+
+| Key | Description |
+| :--- | :--- |
+| `istio` | Istio enablement. When `istio.enable` set to true, Istio would be enabled for the specified configurations |
+| `authorizationPolicy` | It allows you to define access control policies for service-to-service communication. |
+| `action` | Determines whether to ALLOW or DENY the request based on the defined rules. |
+| `provider` | Authorization providers are external systems or mechanisms used to make access control decisions. |
+| `rules` | List of rules defining the authorization policy. Each rule can specify conditions and requirements for allowing or denying access. |
+| `destinationRule` | It allows for the fine-tuning of traffic policies and load balancing for specific services. You can define subsets of a service and apply different traffic policies to each subset. |
+| `subsets` | Specifies subsets within the service for routing and load balancing. |
+| `trafficPolicy` | Policies related to connection pool size, outlier detection, and load balancing. |
+| `gateway` | Allowing external traffic to enter the service mesh through the specified configurations. |
+| `host` | The external domain through which traffic will be routed into the service mesh. |
+| `tls` | Traffic to and from the gateway should be encrypted using TLS. |
+| `secretName` | Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway. |
+| `peerAuthentication` | It allows you to enforce mutual TLS and control the authentication between services. |
+| `mtls` | Mutual TLS. Mutual TLS is a security protocol that requires both client and server, to authenticate each other using digital certificates for secure communication. |
+| `mode` | Mutual TLS mode, specifying how mutual TLS should be applied. Modes include STRICT, PERMISSIVE, and DISABLE. |
+| `portLevelMtls` | Configures port-specific mTLS settings. Allows for fine-grained control over the application of mutual TLS on specific ports. |
+| `selector` | Configuration for selecting workloads to apply PeerAuthentication. |
+| `requestAuthentication` | Defines rules for authenticating incoming requests. |
+| `jwtRules` | Rules for validating JWTs (JSON Web Tokens). It defines how incoming JWTs should be validated for authentication purposes. |
+| `selector` | Specifies the conditions under which the RequestAuthentication rules should be applied. |
+| `virtualService` | Enables the definition of rules for how traffic should be routed to different services within the service mesh. |
+| `gateways` | Specifies the gateways to which the rules defined in the VirtualService apply. |
+| `hosts` | List of hosts (domains) to which this VirtualService is applied. |
+| `http` | Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies. |
+
+
+### KEDA Autoscaling
+[KEDA](https://keda.sh) is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
+
+Example for autosccaling with KEDA using Prometheus metrics is given below:
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced:
+ restoreToOriginalReplicaCount: true
+ horizontalPodAutoscalerConfig:
+ behavior:
+ scaleDown:
+ stabilizationWindowSeconds: 300
+ policies:
+ - type: Percent
+ value: 100
+ periodSeconds: 15
+ triggers:
+ - type: prometheus
+ metadata:
+ serverAddress: http://:9090
+ metricName: http_request_total
+ query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy",}
+ threshold: "50"
+ triggerAuthentication:
+ enabled: false
+ name:
+ spec: {}
+ authenticationRef: {}
+```
+Example for autosccaling with KEDA based on kafka is given below :
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced: {}
+ triggers:
+ - type: kafka
+ metadata:
+ bootstrapServers: b-2.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-3.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-1.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092
+ topic: Orders-Service-ESP.info
+ lagThreshold: "100"
+ consumerGroup: oders-remove-delivered-packages
+ allowIdleConsumers: "true"
+ triggerAuthentication:
+ enabled: true
+ name: keda-trigger-auth-kafka-credential
+ spec:
+ secretTargetRef:
+ - parameter: sasl
+ name: keda-kafka-secrets
+ key: sasl
+ - parameter: username
+ name: keda-kafka-secrets
+ key: username
+ authenticationRef:
+ name: keda-trigger-auth-kafka-credential
+```
+
+### NetworkPolicy
+
+Kubernetes NetworkPolicies control pod communication by defining rules for incoming and outgoing traffic.
+
+```yaml
+networkPolicy:
+ enabled: false
+ annotations: {}
+ labels: {}
+ podSelector:
+ matchLabels:
+ role: db
+ policyTypes:
+ - Ingress
+ - Egress
+ ingress:
+ - from:
+ - ipBlock:
+ cidr: 172.17.0.0/16
+ except:
+ - 172.17.1.0/24
+ - namespaceSelector:
+ matchLabels:
+ project: myproject
+ - podSelector:
+ matchLabels:
+ role: frontend
+ ports:
+ - protocol: TCP
+ port: 6379
+ egress:
+ - to:
+ - ipBlock:
+ cidr: 10.0.0.0/24
+ ports:
+ - protocol: TCP
+ port: 5978
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable NetworkPolicy. |
+| `annotations` | Additional metadata or information associated with the NetworkPolicy. |
+| `labels` | Labels to apply to the NetworkPolicy.
+| `podSelector` | Each NetworkPolicy includes a podSelector which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty podSelector selects all pods in the namespace.|
+| `policyTypes` | Each NetworkPolicy includes a policyTypes list which may include either Ingress, Egress, or both. |
+| `Ingress` | Controls incoming traffic to pods. |
+| `Egress` | Controls outgoing traffic from pods. |
+
+### Winter-Soldier
+Winter Soldier can be used to
+- cleans up (delete) Kubernetes resources
+- reduce workload pods to 0
+
+**_NOTE:_** After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check [the main repo](https://github.com/devtron-labs/winter-soldier)
+
+Given below is template values you can give in winter-soldier:
+```yaml
+winterSoldier:
+ enabled: false
+ apiVersion: pincher.devtron.ai/v1alpha1
+ action: sleep
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges: []
+ targetReplicas: []
+ fieldSelector: []
+```
+
+| Key | values | Description |
+| :--- | :--- | :--- |
+| `enabled` | `false`,`true` | decide the enabling factor |
+| `apiVersion` | `pincher.devtron.ai/v1beta1`, `pincher.devtron.ai/v1alpha1` | specific api version |
+| `action` | `sleep`,`delete`, `scale` | This specify the action need to perform. |
+| `timeRangesWithZone`:`timeZone` | eg:- `"Asia/Kolkata"`,`"US/Pacific"` | It use to specify the timeZone used. (It uses standard format. please refer [this](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)) |
+| `timeRangesWithZone`:`timeRanges` | array of [ `timeFrom`, `timeTo`, `weekdayFrom`, `weekdayTo`] | It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges. These settings will take `action` on Sat and Sun from 00:00 to 23:59:59, |
+| `targetReplicas` | `[n]` : n - number of replicas to scale. | These is mandatory field when the `action` is `scale` Default value is `[]`. |
+| `fieldSelector` | `- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now()) ` | These value will take a list of methods to select the resources on which we perform specified `action` . |
+
+
+here is an example,
+```yaml
+winterSoldier:
+ apiVersion: pincher.devtron.ai/v1alpha1
+ enabled: true
+ annotations: {}
+ labels: {}
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges:
+ - timeFrom: 00:00
+ timeTo: 23:59:59
+ weekdayFrom: Sat
+ weekdayTo: Sun
+ - timeFrom: 00:00
+ timeTo: 08:00
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ - timeFrom: 20:00
+ timeTo: 23:59:59
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ action: scale
+ targetReplicas: [1,1,1]
+ fieldSelector:
+ - AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '10h'), Now())
+```
+Above settings will take action on `Sat` and `Sun` from 00:00 to 23:59:59, and on `Mon`-`Fri` from 00:00 to 08:00 and 20:00 to 23:59:59. If `action:sleep` then runs hibernate at timeFrom and unhibernate at `timeTo`. If `action: delete` then it will delete workloads at `timeFrom` and `timeTo`. Here the `action:scale` thus it scale the number of resource replicas to `targetReplicas: [1,1,1]`. Here each element of `targetReplicas` array is mapped with the corresponding elements of array `timeRangesWithZone/timeRanges`. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
+
+The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
+
+- ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use `ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')`
+- AddTime - This can be used to add time. For eg `AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h')` ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
+- Now - This can be used to get current time.
+- CpuToNumber - This can be used to compare CPU. For eg `any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')})` will check if any resource.requests is less than 60Mi.
+
+
+### Security Context
+A security context defines privilege and access control settings for a Pod or Container.
+
+To add a security context for main container:
+```yaml
+containerSecurityContext:
+ allowPrivilegeEscalation: false
+```
+
+To add a security context on pod level:
+```yaml
+podSecurityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+```
+
+### Topology Spread Constraints
+You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
+
+```yaml
+topologySpreadConstraints:
+ - maxSkew: 1
+ topologyKey: zone
+ whenUnsatisfiable: DoNotSchedule
+ autoLabelSelector: true
+ customLabelSelector: {}
+```
+
+### Deployment Metrics
+
+It gives the realtime metrics of the deployed applications
+
+| Key | Description |
+| :--- | :--- |
+| `Deployment Frequency` | It shows how often this app is deployed to production |
+| `Change Failure Rate` | It shows how often the respective pipeline fails |
+| `Mean Lead Time` | It shows the average time taken to deliver a change to production |
+| `Mean Time to Recovery` | It shows the average time taken to fix a failed pipeline |
+
+---
+
+## 4. Show Application Metrics
+
+If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
+
+
+
+Once all the Deployment template configurations are done, click on `Save` to save your deployment configuration. Now you are ready to create [Workflow](../../workflow/README.md) to do CI/CD.
+
+### Helm Chart Json Schema
+
+Helm Chart [json schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_5-1-0/schema.json) is used to validate the deployment template values.
+
+### Other Validations in Json Schema
+
+The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
+```
+resources.limits.cpu >= resources.requests.cpu
+resources.limits.memory >= resources.requests.memory
+envoyproxy.resources.limits.cpu >= envoyproxy.resources.requests.cpu
+envoyproxy.resources.limits.memory >= envoyproxy.resources.requests.memory
+```
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/job-and-cronjob.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/job-and-cronjob.md
new file mode 100755
index 0000000000..ba6ee2e9b4
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/job-and-cronjob.md
@@ -0,0 +1,77 @@
+---
+id: job-and-cronjob
+title: Job and CronJob
+sidebar_label: Job and CronJob
+---
+
+# Job and CronJob
+
+
+This chart deploys Job & CronJob. A Job is a controller object that represents a finite task and CronJob is used to schedule the creation of Jobs.
+
+ * [Job](#1-job)
+ * [CronJob](#2-cronjob)
+
+
+
+## 1. Job
+
+A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. As pods successfully complete, the Job tracks the successful completions. When a specified number of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up the Pods it created. Suspeding a Job will delete its active Pods until the Job is resumed again.
+
+## **Example:**
+
+```yaml
+kind: Job
+jobConfigs:
+ activeDeadlineSeconds: 120
+ backoffLimit: 6
+ completions: 1
+ parallelism: 1
+ suspend: false
+ ttlSecondsAfterFinished: 100
+```
+
+| Key | Description |
+| :--- | :--- |
+| `activeDeadlineSeconds` | Another way to terminate a Job is by setting an active deadline. Do this by setting the activeDeadlineSeconds field of the Job to a number of seconds. The activeDeadlineSeconds applies to the duration of the job, no matter how many Pods are created. Once a Job reaches activeDeadlineSeconds, all of its running Pods are terminated and the Job status will become type: Failed with reason: DeadlineExceeded. |
+| `backoffLimit` | There are situations where you want to fail a Job after some amount of retries due to a logical error in configuration etc. To do so, set backoffLimit to specify the number of retries before considering a Job as failed. The back-off limit is set by default to 6. Failed Pods associated with the Job are recreated by the Job controller with an exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The back-off count is reset when a Job's Pod is deleted or successful without any other Pods for the Job failing around that time. |
+| `completions` | Jobs with fixed completion count - that is , jobs that have non null completions - can have a completion mode that is specified in completionMode. |
+| `parallelism` | The requested parallelism can be set to any non-negative value. If it is unspecified, it defaults to 1. If it is specified as 0, then the Job is effectively paused until it is increased. |
+| `suspend` | The suspend field is also optional. If it is set to true, all subsequent executions are suspended. This setting does not apply to already started executions. Defaults to false. |
+| `ttlSecondsAfterFinished` | The TTL controller only supports Jobs for now. A cluster operator can use this feature to clean up finished Jobs (either Complete or Failed) automatically by specifying the ttlSecondsAfterFinished field of a Job, as in this example. The TTL controller will assume that a resource is eligible to be cleaned up TTL seconds after the resource has finished, in other words, when the TTL has expired. When the TTL controller cleans up a resource, it will delete it cascadingly, that is to say it will delete its dependent objects together with it. Note that when the resource is deleted, its lifecycle guarantees, such as finalizers, will be honored. |
+| `kind` | As with all other Kubernetes config, a Job and cronjob needs apiVersion, kind.cronjob and job also needs a section fields which is optional . these fields specify to deploy which job (conjob or job) should be kept. by default, they are set job. |
+
+
+## 2. CronJob
+
+A CronJob creates jobs on a repeating schedule. One Cronjob object is like one line of a crontab (cron table) file. It runs a job periodically on a given schedule, written in Cron format.
+ CronJobs are meant for performing regular scheduled actions such as backups, report generation, and so on. Each task must be configured to recur indefinitely (as an example: once a day / week / month). You can schedule the time within that interval when the job should start.
+
+ ## **Example:**
+
+```yaml
+kind: CronJob
+cronjobConfigs:
+ concurrencyPolicy: Allow
+ failedJobsHistoryLimit: 1
+ restartPolicy: OnFailure
+ schedule: 32 8 * * *
+ startingDeadlineSeconds: 100
+ successfulJobsHistoryLimit: 3
+ suspend: false
+```
+
+| Key | Descriptions |
+| :--- | :--- |
+| `concurrencyPolicy` | A CronJob is counted as missed if it has failed to be created at its scheduled time. For example, If concurrencyPolicy is set to Forbid and a CronJob was attempted to be scheduled when there was a previous schedule still running, then it would count as missed,`Acceptable values: Allow / Forbid`. |
+| `failedJobsHistoryLimit` | The failedJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0 corresponds to keeping none of the corresponding kind of jobs after they finish. |
+| `restartPolicy` | The spec of a Pod has a restartPolicy field with possible values Always, OnFailure, and Never. The default value is Always.The restartPolicy applies to all containers in the Pod. restartPolicy only refers to restarts of the containers by the kubelet on the same node. After containers in a Pod exit, the kubelet restarts them with an exponential back-off delay (10s, 20s, 40s, …), that is capped at five minutes. Once a container has executed for 10 minutes without any problems, the kubelet resets the restart backoff timer for that container, `Acceptable values: Always / OnFailure / Never`. |
+| `schedule` | To generate Cronjob schedule expressions, you can also use web tools like https://crontab.guru/. |
+| `startingDeadlineSeconds` | If startingDeadlineSeconds is set to a large value or left unset (the default) and if concurrencyPolicy is set to Allow, the jobs will always run at least once. |
+| `successfulJobsHistoryLimit` | The successfulJobsHistoryLimit fields are optional. These fields specify how many completed and failed jobs should be kept. By default, they are set to 3 and 1 respectively. Setting a limit to 0 corresponds to keeping none of the corresponding kind of jobs after they finish. |
+| `suspend` | The suspend field is also optional. If it is set to true, all subsequent executions are suspended. This setting does not apply to already started executions. Defaults to false. |
+| `kind` | As with all other Kubernetes config, a Job and cronjob needs apiVersion, kind.cronjob and job also needs a section fields which is optional . these fields specify to deploy which job (conjob or job) should be kept. by default, they are set cronjob. |
+
+:::caution Note
+Super-admins can lock keys in Job & CronJob deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/rollout-deployment.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/rollout-deployment.md
new file mode 100755
index 0000000000..9aea86cee8
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/rollout-deployment.md
@@ -0,0 +1,1211 @@
+---
+id: rollout-deployment
+title: Rollout Deployment
+sidebar_label: Rollout Deployment
+---
+
+
+# Rollout Deployment
+
+The `Rollout Deployment` chart deploys an advanced version of deployment that supports Blue/Green and Canary deployments. For functioning, it requires a rollout controller to run inside the cluster.
+
+
+
+You can define application behavior by providing information in the following sections:
+
+| Key | Descriptions |
+| :--- | :--- |
+| `Chart version` | Select the Chart Version using which you want to deploy the application. Refer [Chart Version](../../../creating-application/base-config/deployment-template.md#choose-a-chart-version) section for more detail. |
+| `GUI` | You can perform a basic deployment configuration for your application in the **GUI** section instead of configuring the YAML file. Refer [Basic Configuration](../../../creating-application/base-config/deployment-template.md#using-gui) section for more detail.|
+| `YAML` | If you want to do additional configurations, then click **YAML** for modifications. Refer [YAML](#yaml) section for more detail. |
+| `Show application metrics` | You can enable `Show application metrics` to see your application's metrics-CPU Service Monitor usage, Memory Usage, Status, Throughput and Latency. Refer [Application Metrics](../../../creating-application/app-metrics.md) for more detail. |
+
+:::caution Note
+Super-admins can lock keys in rollout deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
+:::
+
+---
+
+## YAML
+
+### Container Ports
+
+This defines the ports on which application services will be exposed to other services.
+
+```yaml
+ContainerPort:
+ - envoyPort: 8799
+ envoyTimeout: 15s
+ idleTimeout:
+ name: app
+ port: 8080
+ servicePort: 80
+ supportStreaming: true
+ useHTTP2: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `envoyPort` | envoy port for the container. |
+| `envoyTimeout` | envoy Timeout for the container,envoy supports a wide range of timeouts that may need to be configured depending on the deployment.By default the envoytimeout is 15s. |
+| `idleTimeout` | the duration of time that a connection is idle before the connection is terminated. |
+| `name` | name of the port. |
+| `port` | port for the container. |
+| `servicePort` | port of the corresponding kubernetes service. |
+| `supportStreaming` | Used for high performance protocols like grpc where timeout needs to be disabled. |
+| `useHTTP2` | Envoy container can accept HTTP2 requests. |
+
+### EnvVariables
+```yaml
+EnvVariables: []
+```
+`EnvVariables` provide run-time information to containers and allow to customize how the application works and the behavior of the applications on the system.
+
+Here we can pass the list of env variables , every record is an object which contain the `name` of variable along with `value`.
+
+To set environment variables for the containers that run in the Pod.
+
+### Example of EnvVariables
+
+`IMP` Docker image should have env variables, whatever we want to set.
+```yaml
+EnvVariables:
+ - name: HOSTNAME
+ value: www.xyz.com
+ - name: DB_NAME
+ value: mydb
+ - name: USER_NAME
+ value: xyz
+```
+
+But `ConfigMap` and `Secret` are the preferred way to inject env variables. You can create this in **Configurations** page of your app.
+
+### ConfigMap
+
+It is a centralized storage, specific to k8s namespace where key-value pairs are stored in plain text.
+
+
+
+### Secret
+
+It is a centralized storage, specific to k8s namespace where we can store the key-value pairs in plain text as well as in encrypted(`Base64`) form.
+
+
+
+`IMP` All key-values of `Secret` and `CofigMap` will reflect to your application.
+
+### Liveness Probe
+
+If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
+
+```yaml
+LivenessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ command:
+ - python
+ - /etc/app/healthcheck.py
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the liveness needs to be checked. |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for liveliness. |
+| `periodSeconds` | It defines how often (in seconds) to perform the liveness probe. |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfil the liveness probe. |
+| `timeoutSeconds` | The maximum time (in seconds) for the probe to complete. |
+| `failureThreshold` | The number of consecutive failures required to consider the probe as failed. |
+| `command` | The mentioned command is executed to perform the livenessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP. |
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+
+### MaxUnavailable
+
+```yaml
+ MaxUnavailable: 0
+```
+The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
+
+### MaxSurge
+
+```yaml
+MaxSurge: 1
+```
+The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count.
+The default value of "MaxSurge: " is 25%.
+
+### Min Ready Seconds
+
+```yaml
+MinReadySeconds: 60
+```
+This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
+
+### Readiness Probe
+
+If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
+
+```yaml
+ReadinessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ command:
+ - python
+ - /etc/app/healthcheck.py
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the readiness needs to be checked. |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for readiness. |
+| `periodSeconds` | It defines how often (in seconds) to perform the readiness probe. |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the readiness probe. |
+| `timeoutSeconds` | The maximum time (in seconds) for the probe to complete. |
+| `failureThreshold` | The number of consecutive failures required to consider the probe as failed. |
+| `command` | The mentioned command is executed to perform the readinessProbe. If the command returns a non-zero value, it's equivalent to a failed probe. |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP. |
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+
+### Startup Probe
+
+Startup Probe in Kubernetes is a type of probe used to determine when a container within a pod is ready to start accepting traffic. It is specifically designed for applications that have a longer startup time.
+
+```yaml
+StartupProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ command:
+ - python
+ - /etc/app/healthcheck.py
+ tcp: false
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the startup needs to be checked. |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for startup. |
+| `periodSeconds` | It defines how often (in seconds) to perform the startup probe. |
+| `successThreshold` | The number of consecutive successful probe results required to mark the container as ready. |
+| `timeoutSeconds` | The maximum time (in seconds) for the probe to complete. |
+| `failureThreshold` | The number of consecutive failures required to consider the probe as failed. |
+| `command` | The mentioned command is executed to perform the startup probe. If the command returns a non-zero value, it's equivalent to a failed probe. |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+### Autoscaling
+
+This is connected to HPA and controls scaling up and down in response to request load.
+
+```yaml
+autoscaling:
+ enabled: false
+ MinReplicas: 1
+ MaxReplicas: 2
+ TargetCPUUtilizationPercentage: 90
+ TargetMemoryUtilizationPercentage: 80
+ extraMetrics: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable autoscaling else set false.|
+| `MinReplicas` | Minimum number of replicas allowed for scaling. |
+| `MaxReplicas` | Maximum number of replicas allowed for scaling. |
+| `TargetCPUUtilizationPercentage` | The target CPU utilization that is expected for a container. |
+| `TargetMemoryUtilizationPercentage` | The target memory utilization that is expected for a container. |
+| `extraMetrics` | Used to give external metrics for autoscaling. |
+
+### Fullname Override
+
+```yaml
+fullnameOverride: app-name
+```
+`fullnameOverride` replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses `{app-name}-{environment-name}` as release fullname.
+
+### Image
+
+```yaml
+image:
+ pullPolicy: IfNotPresent
+```
+
+Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
+
+### serviceAccount
+
+```yaml
+serviceAccount:
+ create: false
+ name: ""
+ annotations: {}
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Determines whether to create a ServiceAccount for pods or not. If set to `true`, a ServiceAccount will be created. |
+| `name` | Specifies the name of the ServiceAccount to use. |
+| `annotations` | Specify annotations for the ServiceAccount. |
+
+
+### imagePullSecrets
+
+`imagePullSecrets` contains the docker credentials that are used for accessing a registry.
+
+```yaml
+imagePullSecrets:
+ - regcred
+```
+regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry [https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) .
+
+### HostAliases
+
+ the hostAliases field is used in a Pod specification to associate additional hostnames with the Pod's IP address. This can be helpful in scenarios where you need to resolve specific hostnames to the Pod's IP within the Pod itself.
+
+```yaml
+ hostAliases:
+ - ip: "192.168.1.10"
+ hostnames:
+ - "hostname1.example.com"
+ - "hostname2.example.com"
+ - ip: "192.168.1.11"
+ hostnames:
+ - "hostname3.example.com"
+```
+
+### Ingress
+
+This allows public access to the url. Please ensure you are using the right nginx annotation for nginx class.
+The default value is `nginx`.
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ className: nginx
+ annotations: {}
+ hosts:
+ - host: example1.com
+ pathType: "ImplementationSpecific"
+ paths:
+ - /example
+ - host: example2.com
+ pathType: "ImplementationSpecific"
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+Legacy deployment-template ingress format
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ path: ""
+ host: ""
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `host` | Host name |
+| `pathType` | Path in an Ingress is required to have a corresponding path type. Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`. |
+| `path` | Path name |
+| `tls` | It contains security details |
+
+### Ingress Internal
+
+This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
+
+```yaml
+ingressInternal:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ hosts:
+ - host: example1.com
+ pathType: "ImplementationSpecific"
+ paths:
+ - /example
+ - host: example2.com
+ pathType: "ImplementationSpecific"
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `host` | Host name |
+| `pathType` | Path in an Ingress is required to have a corresponding path type. Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`. |
+| `path` | Path name |
+| `pathType` | Supported path types are `ImplementationSpecific`, `Exact` and `Prefix`.|
+| `tls` | It contains security details |
+
+### Init Containers
+```yaml
+initContainers:
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+
+ - name: nginx
+ image: nginx:1.14.2
+ securityContext:
+ privileged: true
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+```
+Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to `true`.
+
+### Pause For Seconds Before Switch Active
+```yaml
+pauseForSecondsBeforeSwitchActive: 30
+```
+To wait for given period of time before switch active the container.
+
+### Resources
+
+These define minimum and maximum RAM and CPU available to the application.
+
+```yaml
+resources:
+ limits:
+ cpu: "1"
+ memory: "200Mi"
+ requests:
+ cpu: "0.10"
+ memory: "100Mi"
+```
+
+Resources are required to set CPU and memory usage.
+
+#### Limits
+
+Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
+
+#### Requests
+
+Requests are what the container is guaranteed to get.
+
+### Service
+
+This defines annotations and the type of service, optionally can define name also.
+
+```yaml
+ service:
+ type: ClusterIP
+ annotations: {}
+```
+| Key | Description |
+| :--- | :--- |
+| `type` | Select the type of service, default `ClusterIP` |
+| `annotations` | Annotations are widely used to attach metadata and configs in Kubernetes. |
+| `name` | Optional field to assign name to service |
+| `loadBalancerSourceRanges` | If service type is `LoadBalancer`, Provide a list of whitelisted IPs CIDR that will be allowed to use the Load Balancer. |
+
+Note - If `loadBalancerSourceRanges` is not set, Kubernetes allows traffic from 0.0.0.0/0 to the LoadBalancer / Node Security Group(s).
+
+
+### Volumes
+
+```yaml
+volumes:
+ - name: log-volume
+ emptyDir: {}
+ - name: logpv
+ persistentVolumeClaim:
+ claimName: logpvc
+```
+
+It is required when some values need to be read from or written to an external disk.
+
+### Volume Mounts
+
+```yaml
+volumeMounts:
+ - mountPath: /var/log/nginx/
+ name: log-volume
+ - mountPath: /mnt/logs
+ name: logpvc
+ subPath: employee
+```
+
+It is used to provide mounts to the volume.
+
+### Affinity and anti-affinity
+
+```yaml
+Spec:
+ Affinity:
+ Key:
+ Values:
+```
+
+Spec is used to define the desire state of the given container.
+
+Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
+
+Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
+
+#### Key
+
+Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+#### Values
+
+Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+### Tolerations
+
+```yaml
+tolerations:
+ - key: "key"
+ operator: "Equal"
+ value: "value"
+ effect: "NoSchedule|PreferNoSchedule|NoExecute(1.6 only)"
+```
+
+Taints are the opposite, they allow a node to repel a set of pods.
+
+A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
+
+Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
+
+### Arguments
+
+```yaml
+args:
+ enabled: false
+ value: []
+```
+
+This is used to give arguments to command.
+
+### Command
+
+```yaml
+command:
+ enabled: false
+ value: []
+ workingDir: {}
+```
+
+It contains the commands to run inside the container.
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | To enable or disable the command. |
+| `value` | It contains the commands. |
+| `workingDir` | It is used to specify the working directory where commands will be executed. |
+
+### Containers
+Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to `true`.
+
+```yaml
+ containers:
+ - name: nginx
+ image: nginx:1.14.2
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+
+```
+
+### Prometheus
+
+```yaml
+ prometheus:
+ release: monitoring
+```
+
+It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case.It describes the state of the prometheus.
+
+### rawYaml
+
+```yaml
+rawYaml:
+ - apiVersion: v1
+ kind: Service
+ metadata:
+ name: my-service
+ spec:
+ selector:
+ app: MyApp
+ ports:
+ - protocol: TCP
+ port: 80
+ targetPort: 9376
+ type: ClusterIP
+```
+Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
+
+### Grace Period
+
+```yaml
+GracePeriod: 30
+```
+Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the `GracePeriod`.
+
+A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
+
+There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
+
+
+### Server
+
+```yaml
+server:
+ deployment:
+ image_tag: 1-95a53
+ image: ""
+```
+
+It is used for providing server configurations.
+
+#### Deployment
+
+It gives the details for deployment.
+
+| Key | Description |
+| :--- | :--- |
+| `image_tag` | It is the image tag |
+| `image` | It is the URL of the image |
+
+### Service Monitor
+
+```yaml
+servicemonitor:
+ enabled: true
+ path: /abc
+ scheme: 'http'
+ interval: 30s
+ scrapeTimeout: 20s
+ metricRelabelings:
+ - sourceLabels: [namespace]
+ regex: '(.*)'
+ replacement: myapp
+ targetLabel: target_namespace
+```
+
+It gives the set of targets to be monitored.
+
+### Db Migration Config
+
+```yaml
+dbMigrationConfig:
+ enabled: false
+```
+
+It is used to configure database migration.
+
+### Istio
+
+These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
+
+
+### Istio
+
+These Istio configurations collectively provide a comprehensive set of tools for controlling access, authenticating requests, enforcing security policies, and configuring traffic behavior within a microservices architecture. The specific settings you choose would depend on your security and traffic management requirements.
+
+```yaml
+istio:
+ enable: true
+
+ gateway:
+ enabled: true
+ labels:
+ app: my-gateway
+ annotations:
+ description: "Istio Gateway for external traffic"
+ host: "example.com"
+ tls:
+ enabled: true
+ secretName: my-tls-secret
+
+ virtualService:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio VirtualService for routing"
+ gateways:
+ - my-gateway
+ hosts:
+ - "example.com"
+ http:
+ - match:
+ - uri:
+ prefix: /v1
+ route:
+ - destination:
+ host: my-service-v1
+ subset: version-1
+ - match:
+ - uri:
+ prefix: /v2
+ route:
+ - destination:
+ host: my-service-v2
+ subset: version-2
+
+ destinationRule:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio DestinationRule for traffic policies"
+ subsets:
+ - name: version-1
+ labels:
+ version: "v1"
+ - name: version-2
+ labels:
+ version: "v2"
+ trafficPolicy:
+ connectionPool:
+ tcp:
+ maxConnections: 100
+ outlierDetection:
+ consecutiveErrors: 5
+ interval: 30s
+ baseEjectionTime: 60s
+
+ peerAuthentication:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio PeerAuthentication for mutual TLS"
+ selector:
+ matchLabels:
+ version: "v1"
+ mtls:
+ mode: STRICT
+ portLevelMtls:
+ 8080:
+ mode: DISABLE
+
+ requestAuthentication:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio RequestAuthentication for JWT validation"
+ selector:
+ matchLabels:
+ version: "v1"
+ jwtRules:
+ - issuer: "issuer-1"
+ jwksUri: "https://issuer-1/.well-known/jwks.json"
+
+ authorizationPolicy:
+ enabled: true
+ labels:
+ app: my-service
+ annotations:
+ description: "Istio AuthorizationPolicy for access control"
+ action: ALLOW
+ provider:
+ name: jwt
+ kind: Authorization
+ rules:
+ - from:
+ - source:
+ requestPrincipals: ["*"]
+ to:
+ - operation:
+ methods: ["GET"]
+```
+
+| Key | Description |
+| :--- | :--- |
+| `istio` | Istio enablement. When `istio.enable` set to true, Istio would be enabled for the specified configurations |
+| `authorizationPolicy` | It allows you to define access control policies for service-to-service communication. |
+| `action` | Determines whether to ALLOW or DENY the request based on the defined rules. |
+| `provider` | Authorization providers are external systems or mechanisms used to make access control decisions. |
+| `rules` | List of rules defining the authorization policy. Each rule can specify conditions and requirements for allowing or denying access. |
+| `destinationRule` | It allows for the fine-tuning of traffic policies and load balancing for specific services. You can define subsets of a service and apply different traffic policies to each subset. |
+| `subsets` | Specifies subsets within the service for routing and load balancing. |
+| `trafficPolicy` | Policies related to connection pool size, outlier detection, and load balancing. |
+| `gateway` | Allowing external traffic to enter the service mesh through the specified configurations. |
+| `host` | The external domain through which traffic will be routed into the service mesh. |
+| `tls` | Traffic to and from the gateway should be encrypted using TLS. |
+| `secretName` | Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway. |
+| `peerAuthentication` | It allows you to enforce mutual TLS and control the authentication between services. |
+| `mtls` | Mutual TLS. Mutual TLS is a security protocol that requires both client and server, to authenticate each other using digital certificates for secure communication. |
+| `mode` | Mutual TLS mode, specifying how mutual TLS should be applied. Modes include STRICT, PERMISSIVE, and DISABLE. |
+| `portLevelMtls` | Configures port-specific mTLS settings. Allows for fine-grained control over the application of mutual TLS on specific ports. |
+| `selector` | Configuration for selecting workloads to apply PeerAuthentication. |
+| `requestAuthentication` | Defines rules for authenticating incoming requests. |
+| `jwtRules` | Rules for validating JWTs (JSON Web Tokens). It defines how incoming JWTs should be validated for authentication purposes. |
+| `selector` | Specifies the conditions under which the RequestAuthentication rules should be applied. |
+| `virtualService` | Enables the definition of rules for how traffic should be routed to different services within the service mesh. |
+| `gateways` | Specifies the gateways to which the rules defined in the VirtualService apply. |
+| `hosts` | List of hosts (domains) to which this VirtualService is applied. |
+| `http` | Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies. |
+
+### Application Metrics
+
+Application metrics can be enabled to see your application's metrics-CPU Service Monitor usage, Memory Usage, Status, Throughput and Latency.
+
+### Deployment Metrics
+
+It gives the realtime metrics of the deployed applications
+
+| Key | Description |
+| :--- | :--- |
+| `Deployment Frequency` | It shows how often this app is deployed to production |
+| `Change Failure Rate` | It shows how often the respective pipeline fails. |
+| `Mean Lead Time` | It shows the average time taken to deliver a change to production. |
+| `Mean Time to Recovery` | It shows the average time taken to fix a failed pipeline. |
+
+
+## Addon features in Deployment Template Chart version 3.9.0
+
+### Service Account
+
+```yaml
+serviceAccountName: orchestrator
+```
+
+A service account provides an identity for the processes that run in a Pod.
+
+When you access the cluster, you are authenticated by the API server as a particular User Account. Processes in containers inside pod can also contact the API server. When you are authenticated as a particular Service Account.
+
+When you create a pod, if you do not create a service account, it is automatically assigned the default service account in the namespace.
+
+### Pod Disruption Budget
+
+You can create `PodDisruptionBudget` for each application. A PDB limits the number of pods of a replicated application that are down simultaneously from voluntary disruptions. For example, an application would like to ensure the number of replicas running is never brought below the certain number.
+
+```yaml
+podDisruptionBudget:
+ minAvailable: 1
+```
+
+or
+
+```yaml
+podDisruptionBudget:
+ maxUnavailable: 50%
+```
+
+You can specify either `maxUnavailable` or `minAvailable` in a PodDisruptionBudget and it can be expressed as integers or as a percentage.
+
+| Key | Description |
+| :--- | :--- |
+| `minAvailable` | Evictions are allowed as long as they leave behind 1 or more healthy pods of the total number of desired replicas. |
+| `maxUnavailable` | Evictions are allowed as long as at most 1 unhealthy replica among the total number of desired replicas. |
+
+### Application metrics Envoy Configurations
+
+```yaml
+envoyproxy:
+ image: envoyproxy/envoy:v1.14.1
+ configMapName: ""
+ resources:
+ limits:
+ cpu: "50m"
+ memory: "50Mi"
+ requests:
+ cpu: "50m"
+ memory: "50Mi"
+```
+
+Envoy is attached as a sidecar to the application container to collect metrics like 4XX, 5XX, Throughput and latency. You can now configure the envoy settings such as idleTimeout, resources etc.
+
+### Prometheus Rule
+
+```yaml
+prometheusRule:
+ enabled: true
+ additionalLabels: {}
+ namespace: ""
+ rules:
+ - alert: TooMany500s
+ expr: 100 * ( sum( nginx_ingress_controller_requests{status=~"5.+"} ) / sum(nginx_ingress_controller_requests) ) > 5
+ for: 1m
+ labels:
+ severity: critical
+ annotations:
+ description: Too many 5XXs
+ summary: More than 5% of the all requests did return 5XX, this require your attention
+```
+
+Alerting rules allow you to define alert conditions based on Prometheus expressions and to send notifications about firing alerts to an external service.
+
+In this case, Prometheus will check that the alert continues to be active during each evaluation for 1 minute before firing the alert. Elements that are active, but not firing yet, are in the pending state.
+
+### Pod Labels
+Labels are key/value pairs that are attached to pods. Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system. Labels can be used to organize and to select subsets of objects.
+```yaml
+podLabels:
+ severity: critical
+```
+
+### Pod Annotations
+Pod Annotations are widely used to attach metadata and configs in Kubernetes.
+
+```yaml
+podAnnotations:
+ fluentbit.io/exclude: "true"
+```
+
+### Custom Metrics in HPA
+
+```yaml
+autoscaling:
+ enabled: true
+ MinReplicas: 1
+ MaxReplicas: 2
+ TargetCPUUtilizationPercentage: 90
+ TargetMemoryUtilizationPercentage: 80
+ behavior:
+ scaleDown:
+ stabilizationWindowSeconds: 300
+ policies:
+ - type: Percent
+ value: 100
+ periodSeconds: 15
+ scaleUp:
+ stabilizationWindowSeconds: 0
+ policies:
+ - type: Percent
+ value: 100
+ periodSeconds: 15
+ - type: Pods
+ value: 4
+ periodSeconds: 15
+ selectPolicy: Max
+```
+
+HPA, by default is configured to work with CPU and Memory metrics. These metrics are useful for internal cluster sizing, but you might want to configure wider set of metrics like service latency, I/O load etc. The custom metrics in HPA can help you to achieve this.
+
+### Wait For Seconds Before Scaling Down
+```yaml
+waitForSecondsBeforeScalingDown: 30
+```
+Wait for given period of time before scaling down the container.
+
+
+
+## 4. Show Application Metrics
+
+If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
+
+
+
+Once all the Deployment template configurations are done, click on `Save` to save your deployment configuration. Now you are ready to create [Workflow](../../workflow/README.md) to do CI/CD.
+
+### Helm Chart Json Schema Table
+
+Helm Chart json schema is used to validate the deployment template values.
+
+| Chart Version | Link |
+| :--- | :--- |
+| `reference-chart_3-12-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-12-0/schema.json) |
+| `reference-chart_3-11-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-11-0/schema.json) |
+| `reference-chart_3-10-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-10-0/schema.json) |
+| `reference-chart_3-9-0` | [Json Schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_3-9-0/schema.json) |
+
+
+### Other Validations in Json Schema
+
+The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
+```
+resources.limits.cpu >= resources.requests.cpu
+resources.limits.memory >= resources.requests.memory
+envoyproxy.resources.limits.cpu >= envoyproxy.resources.requests.cpu
+envoyproxy.resources.limits.memory >= envoyproxy.resources.requests.memory
+```
+
+## Addon features in Deployment Template Chart version 4.11.0
+
+### KEDA Autoscaling
+
+**Prerequisite:** KEDA controller should be installed in the cluster. To install KEDA controller using Helm, navigate to chart store and search for `keda` chart and deploy it. You can follow this [documentation](../../../deploy-chart/deployment-of-charts.md) for deploying a Helm chart on Devtron.
+
+KEDA Helm repo : https://kedacore.github.io/charts
+
+
+[KEDA](https://keda.sh) is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
+
+
+Example for autoscaling with KEDA using Prometheus metrics is given below:
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced:
+ restoreToOriginalReplicaCount: true
+ horizontalPodAutoscalerConfig:
+ behavior:
+ scaleDown:
+ stabilizationWindowSeconds: 300
+ policies:
+ - type: Percent
+ value: 100
+ periodSeconds: 15
+ triggers:
+ - type: prometheus
+ metadata:
+ serverAddress: http://:9090
+ metricName: http_request_total
+ query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy",}
+ threshold: "50"
+ triggerAuthentication:
+ enabled: false
+ name:
+ spec: {}
+ authenticationRef: {}
+```
+
+Example for autosccaling with KEDA based on kafka is given below :
+
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced: {}
+ triggers:
+ - type: kafka
+ metadata:
+ bootstrapServers: b-2.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-3.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-1.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092
+ topic: Orders-Service-ESP.info
+ lagThreshold: "100"
+ consumerGroup: oders-remove-delivered-packages
+ allowIdleConsumers: "true"
+ triggerAuthentication:
+ enabled: true
+ name: keda-trigger-auth-kafka-credential
+ spec:
+ secretTargetRef:
+ - parameter: sasl
+ name: keda-kafka-secrets
+ key: sasl
+ - parameter: username
+ name: keda-kafka-secrets
+ key: username
+ authenticationRef:
+ name: keda-trigger-auth-kafka-credential
+```
+
+### NetworkPolicy
+
+Kubernetes NetworkPolicies control pod communication by defining rules for incoming and outgoing traffic.
+
+```yaml
+networkPolicy:
+ enabled: false
+ annotations: {}
+ labels: {}
+ podSelector:
+ matchLabels:
+ role: db
+ policyTypes:
+ - Ingress
+ - Egress
+ ingress:
+ - from:
+ - ipBlock:
+ cidr: 172.17.0.0/16
+ except:
+ - 172.17.1.0/24
+ - namespaceSelector:
+ matchLabels:
+ project: myproject
+ - podSelector:
+ matchLabels:
+ role: frontend
+ ports:
+ - protocol: TCP
+ port: 6379
+ egress:
+ - to:
+ - ipBlock:
+ cidr: 10.0.0.0/24
+ ports:
+ - protocol: TCP
+ port: 5978
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable NetworkPolicy. |
+| `annotations` | Additional metadata or information associated with the NetworkPolicy. |
+| `labels` | Labels to apply to the NetworkPolicy.
+| `podSelector` | Each NetworkPolicy includes a podSelector which selects the grouping of pods to which the policy applies. The example policy selects pods with the label "role=db". An empty podSelector selects all pods in the namespace.|
+| `policyTypes` | Each NetworkPolicy includes a policyTypes list which may include either Ingress, Egress, or both. |
+| `Ingress` | Controls incoming traffic to pods. |
+| `Egress` | Controls outgoing traffic from pods. |
+
+
+### Winter-Soldier
+Winter Soldier can be used to
+- cleans up (delete) Kubernetes resources
+- reduce workload pods to 0
+
+**_NOTE:_** After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check [the main repo](https://github.com/devtron-labs/winter-soldier)
+
+Given below is template values you can give in winter-soldier:
+```yaml
+winterSoldier:
+ enabled: false
+ apiVersion: pincher.devtron.ai/v1alpha1
+ action: sleep
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges: []
+ targetReplicas: []
+ fieldSelector: []
+```
+
+| Key | values | Description |
+| :--- | :--- | :--- |
+| `enabled` | `false`,`true` | decide the enabling factor |
+| `apiVersion` | `pincher.devtron.ai/v1beta1`, `pincher.devtron.ai/v1alpha1` | specific api version |
+| `action` | `sleep`,`delete`, `scale` | This specify the action need to perform. |
+| `timeRangesWithZone`:`timeZone` | eg:- `"Asia/Kolkata"`,`"US/Pacific"` | It use to specify the timeZone used. (It uses standard format. please refer [this](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)) |
+| `timeRangesWithZone`:`timeRanges` | array of [ `timeFrom`, `timeTo`, `weekdayFrom`, `weekdayTo`] | It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges. These settings will take `action` on Sat and Sun from 00:00 to 23:59:59, |
+| `targetReplicas` | `[n]` : n - number of replicas to scale. | These is mandatory field when the `action` is `scale` Default value is `[]`. |
+| `fieldSelector` | `- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now()) ` | These value will take a list of methods to select the resources on which we perform specified `action` . |
+
+
+here is an example,
+```yaml
+winterSoldier:
+ apiVersion: pincher.devtron.ai/v1alpha1
+ enabled: true
+ annotations: {}
+ labels: {}
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges:
+ - timeFrom: 00:00
+ timeTo: 23:59:59
+ weekdayFrom: Sat
+ weekdayTo: Sun
+ - timeFrom: 00:00
+ timeTo: 08:00
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ - timeFrom: 20:00
+ timeTo: 23:59:59
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ action: scale
+ targetReplicas: [1,1,1]
+ fieldSelector:
+ - AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '10h'), Now())
+```
+
+Above settings will take action on `Sat` and `Sun` from 00:00 to 23:59:59, and on `Mon`-`Fri` from 00:00 to 08:00 and 20:00 to 23:59:59. If `action:sleep` then runs hibernate at timeFrom and unhibernate at `timeTo`. If `action: delete` then it will delete workloads at `timeFrom` and `timeTo`. Here the `action:scale` thus it scale the number of resource replicas to `targetReplicas: [1,1,1]`. Here each element of `targetReplicas` array is mapped with the corresponding elements of array `timeRangesWithZone/timeRanges`. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
+
+The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
+
+- ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use `ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')`
+- AddTime - This can be used to add time. For eg `AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h')` ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
+- Now - This can be used to get current time.
+- CpuToNumber - This can be used to compare CPU. For eg `any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')})` will check if any resource.requests is less than 60Mi.
+
+
+
+### Security Context
+A security context defines privilege and access control settings for a Pod or Container.
+
+To add a security context for main container:
+```yaml
+containerSecurityContext:
+ allowPrivilegeEscalation: false
+```
+
+To add a security context on pod level:
+```yaml
+podSecurityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+```
+
+### Topology Spread Constraints
+You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
+
+```yaml
+topologySpreadConstraints:
+ - maxSkew: 1
+ topologyKey: zone
+ whenUnsatisfiable: DoNotSchedule
+ autoLabelSelector: true
+ customLabelSelector: {}
+```
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/statefulset.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/statefulset.md
new file mode 100755
index 0000000000..cf5b475f36
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template-types/statefulset.md
@@ -0,0 +1,996 @@
+---
+id: statefulset
+title: StatefulSet
+sidebar_label: StatefulSet
+---
+
+# StatefulSet
+
+The StatefulSet chart in Devtron allows you to deploy and manage stateful applications. StatefulSet is a Kubernetes resource that provides guarantees about the ordering and uniqueness of Pods during deployment and scaling.
+
+
+
+It supports only `ONDELETE` and `ROLLINGUPDATE` deployment strategy.
+
+
+
+
+You can select `StatefulSet` chart when you want to use only basic use cases which contain the following:
+
+* **Managing Stateful Applications:** StatefulSets are ideal for managing stateful applications, such as databases or distributed systems, that require stable network identities and persistent storage for each Pod.
+
+* **Ordered Pod Management:** StatefulSets ensure ordered and predictable management of Pods by providing each Pod with a unique and stable hostname based on a defined naming convention and ordinal index.
+
+* **Updating and Scaling Stateful Applications:** StatefulSets support updating and scaling stateful applications by creating new versions of the StatefulSet and performing rolling updates or scaling operations in a controlled manner, ensuring minimal disruption to the application.
+
+* **Persistent Storage:** StatefulSets have built-in mechanisms for handling persistent volumes, allowing each Pod to have its own unique volume claim and storage. This ensures data persistence even when Pods are rescheduled or restarted.
+
+* **Maintaining Pod Identity:** StatefulSets guarantee consistent identity for each Pod throughout its lifecycle. This stability is maintained even if the Pods are rescheduled, allowing applications to rely on stable network identities.
+
+* **Rollback Capability:** StatefulSets provide the ability to rollback to a previous version in case the current state of the application is unstable or encounters issues, ensuring a known working state for the application.
+
+* **Status Monitoring:** StatefulSets offer status information that can be used to monitor the deployment, including the current version, number of replicas, and the readiness of each Pod. This helps in tracking the health and progress of the StatefulSet deployment.
+
+* **Resource Cleanup:** StatefulSets allow for easy cleanup of older versions by deleting StatefulSets and their associated Pods and persistent volumes that are no longer needed, ensuring efficient resource utilization.
+
+:::caution Note
+Super-admins can lock keys in StatefulSet deployment template to prevent non-super-admins from modifying those locked keys. Refer [Lock Deployment Configuration](../../../global-configurations/lock-deployment-config.md) to know more.
+:::
+
+
+## 1. Yaml File
+
+### Container Ports
+
+This defines ports on which application services will be exposed to other services
+
+```yaml
+ContainerPort:
+ - envoyPort: 8799
+ idleTimeout:
+ name: app
+ port: 8080
+ servicePort: 80
+ nodePort: 32056
+ supportStreaming: true
+ useHTTP2: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `envoyPort` | envoy port for the container. |
+| `idleTimeout` | the duration of time that a connection is idle before the connection is terminated. |
+| `name` | name of the port. |
+| `port` | port for the container. |
+| `servicePort` | port of the corresponding kubernetes service. |
+| `nodePort` | nodeport of the corresponding kubernetes service. |
+| `supportStreaming` | Used for high performance protocols like grpc where timeout needs to be disabled. |
+| `useHTTP2` | Envoy container can accept HTTP2 requests. |
+
+### EnvVariables
+```yaml
+EnvVariables: []
+```
+
+### EnvVariablesFromSecretKeys
+```yaml
+EnvVariablesFromSecretKeys:
+ - name: ENV_NAME
+ secretName: SECRET_NAME
+ keyName: SECRET_KEY
+
+```
+ It is used to get the name of Environment Variable name, Secret name and the Key name from which we are using the value in that corresponding Environment Variable.
+
+ ### EnvVariablesFromConfigMapKeys
+```yaml
+EnvVariablesFromConfigMapKeys:
+ - name: ENV_NAME
+ configMapName: CONFIG_MAP_NAME
+ keyName: CONFIG_MAP_KEY
+
+```
+ It is used to get the name of Environment Variable name, Config Map name and the Key name from which we are using the value in that corresponding Environment Variable.
+
+To set environment variables for the containers that run in the Pod.
+### StatefulSetConfig
+These are all the configuration settings for the StatefulSet.
+```yaml
+statefulSetConfig:
+ labels:
+ app: my-statefulset
+ environment: production
+ annotations:
+ example.com/version: "1.0"
+ serviceName: "my-statefulset-service"
+ podManagementPolicy: "Parallel"
+ revisionHistoryLimit: 5
+ mountPath: "/data"
+ volumeClaimTemplates:
+ - apiVersion: v1
+ kind: PersistentVolumeClaim
+ metadata:
+ labels:
+ app: my-statefulset
+ spec:
+ accessModes:
+ - ReadWriteOnce
+ dataSource:
+ kind: Snapshot
+ apiGroup: snapshot.storage.k8s.io
+ name: my-snapshot
+ resources:
+ requests:
+ storage: 5Gi
+ limits:
+ storage: 10Gi
+ storageClassName: my-storage-class
+ selector:
+ matchLabels:
+ app: my-statefulset
+ volumeMode: Filesystem
+ volumeName: my-pv
+ - apiVersion: v1
+ kind: PersistentVolumeClaim
+ metadata:
+ name: pvc-logs
+ labels:
+ app: myapp
+ spec:
+ accessModes:
+ - ReadWriteMany
+ dataSourceRef:
+ kind: Secret
+ apiGroup: v1
+ name: my-secret
+ resources:
+ requests:
+ storage: 5Gi
+ storageClassName: my-storage-class
+ selector:
+ matchExpressions:
+ - {key: environment, operator: In, values: [production]}
+ volumeMode: Block
+ volumeName: my-pv
+
+```
+Mandatoryfields in statefulSetConfig is
+```
+statefulSetConfig:
+ mountPath: /tmp
+ volumeClaimTemplates:
+ - spec:
+ accessModes:
+ - ReadWriteOnce
+ resources:
+ requests:
+ storage: 2Gi
+```
+Here is an explanation of each field in the statefulSetConfig :
+
+
+| Key | Description |
+| :--- | :--- |
+| `labels` | set of key-value pairs used to identify the StatefulSet . |
+| `annotations` | A map of key-value pairs that are attached to the stateful set as metadata. |
+| `serviceName` | The name of the Kubernetes Service that the StatefulSet should create. |
+| `podManagementPolicy` | A policy that determines how Pods are created and deleted by the StatefulSet. In this case, the policy is set to "Parallel", which means that all Pods are created at once. |
+| `revisionHistoryLimit` | The number of revisions that should be stored for each replica of the StatefulSet. |
+| `updateStrategy` | The update strategy used by the StatefulSet when rolling out changes. |
+| `mountPath` | The path where the volume should be mounted in the container. |
+
+volumeClaimTemplates: An array of volume claim templates that are used to create persistent volumes for the StatefulSet. Each volume claim template specifies the storage class, access mode, storage size, and other details of the persistent volume.
+
+
+| Key | Description |
+| :--- | :--- |
+| `apiVersion` | The API version of the PVC . |
+| `kind` | The type of object that the PVC is. |
+| `metadata` | Metadata that is attached to the resource being created. |
+| `labels` | A set of key-value pairs used to label the object for identification and selection. |
+| `spec` | The specification of the object, which defines its desired state and behavior.|
+| `accessModes` | A list of access modes for the PersistentVolumeClaim, such as "ReadWriteOnce" or "ReadWriteMany". |
+| `dataSource` | A data source used to populate the PersistentVolumeClaim, such as a Snapshot or a StorageClass. |
+| `kind`| specifies the kind of the snapshot, in this case Snapshot.|
+| `apiGroup`| specifies the API group of the snapshot API, in this case snapshot.storage.k8s.io.|
+| `name`| specifies the name of the snapshot, in this case my-snapshot.|
+| `dataSourceRef` | A reference to a data source used to create the persistent volume. In this case, it's a secret. |
+| `updateStrategy` | The update strategy used by the StatefulSet when rolling out changes. |
+| `resources` | The resource requests and limits for the PersistentVolumeClaim, which define the minimum and maximum amount of storage it can use. |
+| `requests` | The amount of storage requested by the PersistentVolumeClaim. |
+| `limits` | The maximum amount of storage that the PersistentVolumeClaim can use. |
+| `storageClassName` | The name of the storage class to use for the persistent volume. |
+| `selector` | The selector used to match a persistent volume to a persistent volume claim. |
+| `matchLabels` | a map of key-value pairs to match the labels of the corresponding PersistentVolume.|
+| `matchExpressions` |A set of requirements that the selected object must meet to be considered a match. |
+| `key` | The key of the label or annotation to match.|
+| `operator` | The operator used to compare the key-value pairs (in this case, "In" specifies a set membership test).|
+| `values` | A list of values that the selected object's label or annotation must match.|
+| `volumeMode` | The mode of the volume, either "Filesystem" or "Block". |
+| `volumeName` | The name of the PersistentVolume that is created for the PersistentVolumeClaim. |
+
+
+### Liveness Probe
+
+If this check fails, kubernetes restarts the pod. This should return error code in case of non-recoverable error.
+
+```yaml
+LivenessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the liveness needs to be checked. |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for liveliness. |
+| `periodSeconds` | It defines the time to check a given container for liveness. |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfil the liveness probe. |
+| `timeoutSeconds` | It defines the time for checking timeout. |
+| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as live. |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+
+### MaxUnavailable
+
+```yaml
+ MaxUnavailable: 0
+```
+The maximum number of pods that can be unavailable during the update process. The value of "MaxUnavailable: " can be an absolute number or percentage of the replicas count. The default value of "MaxUnavailable: " is 25%.
+
+### MaxSurge
+
+```yaml
+MaxSurge: 1
+```
+The maximum number of pods that can be created over the desired number of pods. For "MaxSurge: " also, the value can be an absolute number or percentage of the replicas count.
+The default value of "MaxSurge: " is 25%.
+
+### Min Ready Seconds
+
+```yaml
+MinReadySeconds: 60
+```
+This specifies the minimum number of seconds for which a newly created Pod should be ready without any of its containers crashing, for it to be considered available. This defaults to 0 (the Pod will be considered available as soon as it is ready).
+
+### Readiness Probe
+
+If this check fails, kubernetes stops sending traffic to the application. This should return error code in case of errors which can be recovered from if traffic is stopped.
+
+```yaml
+ReadinessProbe:
+ Path: ""
+ port: 8080
+ initialDelaySeconds: 20
+ periodSeconds: 10
+ successThreshold: 1
+ timeoutSeconds: 5
+ failureThreshold: 3
+ httpHeaders:
+ - name: Custom-Header
+ value: abc
+ scheme: ""
+ tcp: true
+```
+
+| Key | Description |
+| :--- | :--- |
+| `Path` | It define the path where the readiness needs to be checked. |
+| `initialDelaySeconds` | It defines the time to wait before a given container is checked for readiness. |
+| `periodSeconds` | It defines the time to check a given container for readiness. |
+| `successThreshold` | It defines the number of successes required before a given container is said to fulfill the readiness probe. |
+| `timeoutSeconds` | It defines the time for checking timeout. |
+| `failureThreshold` | It defines the maximum number of failures that are acceptable before a given container is not considered as ready. |
+| `httpHeaders` | Custom headers to set in the request. HTTP allows repeated headers,You can override the default headers by defining .httpHeaders for the probe. |
+| `scheme` | Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.
+| `tcp` | The kubelet will attempt to open a socket to your container on the specified port. If it can establish a connection, the container is considered healthy. |
+
+### Ambassador Mappings
+
+You can create ambassador mappings to access your applications from outside the cluster. At its core a Mapping resource maps a resource to a service.
+
+```yaml
+ambassadorMapping:
+ ambassadorId: "prod-emissary"
+ cors: {}
+ enabled: true
+ hostname: devtron.example.com
+ labels: {}
+ prefix: /
+ retryPolicy: {}
+ rewrite: ""
+ tls:
+ context: "devtron-tls-context"
+ create: false
+ hosts: []
+ secretName: ""
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable ambassador mapping else set false.|
+| `ambassadorId` | used to specify id for specific ambassador mappings controller. |
+| `cors` | used to specify cors policy to access host for this mapping. |
+| `weight` | used to specify weight for canary ambassador mappings. |
+| `hostname` | used to specify hostname for ambassador mapping. |
+| `prefix` | used to specify path for ambassador mapping. |
+| `labels` | used to provide custom labels for ambassador mapping. |
+| `retryPolicy` | used to specify retry policy for ambassador mapping. |
+| `corsPolicy` | Provide cors headers on flagger resource. |
+| `rewrite` | used to specify whether to redirect the path of this mapping and where. |
+| `tls` | used to create or define ambassador TLSContext resource. |
+| `extraSpec` | used to provide extra spec values which not present in deployment template for ambassador resource. |
+
+### Autoscaling
+
+This is connected to HPA and controls scaling up and down in response to request load.
+
+```yaml
+autoscaling:
+ enabled: false
+ MinReplicas: 1
+ MaxReplicas: 2
+ TargetCPUUtilizationPercentage: 90
+ TargetMemoryUtilizationPercentage: 80
+ extraMetrics: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Set true to enable autoscaling else set false.|
+| `MinReplicas` | Minimum number of replicas allowed for scaling. |
+| `MaxReplicas` | Maximum number of replicas allowed for scaling. |
+| `TargetCPUUtilizationPercentage` | The target CPU utilization that is expected for a container. |
+| `TargetMemoryUtilizationPercentage` | The target memory utilization that is expected for a container. |
+| `extraMetrics` | Used to give external metrics for autoscaling. |
+
+### Fullname Override
+
+```yaml
+fullnameOverride: app-name
+```
+`fullnameOverride` replaces the release fullname created by default by devtron, which is used to construct Kubernetes object names. By default, devtron uses `{app-name}-{environment-name}` as release fullname.
+
+### Image
+
+```yaml
+image:
+ pullPolicy: IfNotPresent
+```
+
+Image is used to access images in kubernetes, pullpolicy is used to define the instances calling the image, here the image is pulled when the image is not present,it can also be set as "Always".
+
+### imagePullSecrets
+
+`imagePullSecrets` contains the docker credentials that are used for accessing a registry.
+
+```yaml
+imagePullSecrets:
+ - regcred
+```
+regcred is the secret that contains the docker credentials that are used for accessing a registry. Devtron will not create this secret automatically, you'll have to create this secret using dt-secrets helm chart in the App store or create one using kubectl. You can follow this documentation Pull an Image from a Private Registry [https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) .
+
+### Ingress
+
+This allows public access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ className: nginx
+ annotations: {}
+ hosts:
+ - host: example1.com
+ paths:
+ - /example
+ - host: example2.com
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+Legacy deployment-template ingress format
+
+```yaml
+ingress:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ path: ""
+ host: ""
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `path` | Path name |
+| `host` | Host name |
+| `tls` | It contains security details |
+
+### Ingress Internal
+
+This allows private access to the url, please ensure you are using right nginx annotation for nginx class, its default value is nginx
+
+```yaml
+ingressInternal:
+ enabled: false
+ # For K8s 1.19 and above use ingressClassName instead of annotation kubernetes.io/ingress.class:
+ ingressClassName: nginx-internal
+ annotations: {}
+ hosts:
+ - host: example1.com
+ paths:
+ - /example
+ - host: example2.com
+ paths:
+ - /example2
+ - /example2/healthz
+ tls: []
+```
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | Enable or disable ingress |
+| `annotations` | To configure some options depending on the Ingress controller |
+| `path` | Path name |
+| `host` | Host name |
+| `tls` | It contains security details |
+
+### Init Containers
+```yaml
+initContainers:
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+
+ - name: nginx
+ image: nginx:1.14.2
+ securityContext:
+ privileged: true
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+```
+Specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image. One can use base image inside initContainer by setting the reuseContainerImage flag to `true`.
+
+### Istio
+
+Istio is a service mesh which simplifies observability, traffic management, security and much more with it's virtual services and gateways.
+
+```yaml
+istio:
+ enable: true
+ gateway:
+ annotations: {}
+ enabled: false
+ host: example.com
+ labels: {}
+ tls:
+ enabled: false
+ secretName: example-tls-secret
+ virtualService:
+ annotations: {}
+ enabled: false
+ gateways: []
+ hosts: []
+ http:
+ - corsPolicy:
+ allowCredentials: false
+ allowHeaders:
+ - x-some-header
+ allowMethods:
+ - GET
+ allowOrigin:
+ - example.com
+ maxAge: 24h
+ headers:
+ request:
+ add:
+ x-some-header: value
+ match:
+ - uri:
+ prefix: /v1
+ - uri:
+ prefix: /v2
+ retries:
+ attempts: 2
+ perTryTimeout: 3s
+ rewriteUri: /
+ route:
+ - destination:
+ host: service1
+ port: 80
+ timeout: 12s
+ - route:
+ - destination:
+ host: service2
+ labels: {}
+```
+
+| Key | Description |
+| :--- | :--- |
+| `istio` | Istio enablement. When `istio.enable` set to true, Istio would be enabled for the specified configurations |
+| `gateway` | Allowing external traffic to enter the service mesh through the specified configurations. |
+| `host` | The external domain through which traffic will be routed into the service mesh. |
+| `tls` | Traffic to and from the gateway should be encrypted using TLS. |
+| `secretName` | Specifies the name of the Kubernetes secret that contains the TLS certificate and private key. The TLS certificate is used for securing the communication between clients and the Istio gateway. |
+| `virtualService` | Enables the definition of rules for how traffic should be routed to different services within the service mesh. |
+| `gateways` | Specifies the gateways to which the rules defined in the VirtualService apply. |
+| `hosts` | List of hosts (domains) to which this VirtualService is applied. |
+| `http` | Configuration for HTTP routes within the VirtualService. It define routing rules based on HTTP attributes such as URI prefixes, headers, timeouts, and retry policies. |
+| `corsPolicy` | Cross-Origin Resource Sharing (CORS) policy configuration. |
+| `headers` | Additional headers to be added to the HTTP request. |
+| `match` | Conditions that need to be satisfied for this route to be used. |
+| `uri` | This specifies a match condition based on the URI of the incoming request. |
+| `prefix` | It specifies that the URI should have the specified prefix. |
+| `retries` | Retry configuration for failed requests. |
+| `attempts` | It specifies the number of retry attempts for failed requests. |
+| `perTryTimeout` | sets the timeout for each individual retry attempt. |
+| `rewriteUri` | Rewrites the URI of the incoming request. |
+| `route` | List of destination rules for routing traffic. |
+
+### Pause For Seconds Before Switch Active
+```yaml
+pauseForSecondsBeforeSwitchActive: 30
+```
+To wait for given period of time before switch active the container.
+
+### Resources
+
+These define minimum and maximum RAM and CPU available to the application.
+
+```yaml
+resources:
+ limits:
+ cpu: "1"
+ memory: "200Mi"
+ requests:
+ cpu: "0.10"
+ memory: "100Mi"
+```
+
+Resources are required to set CPU and memory usage.
+
+#### Limits
+
+Limits make sure a container never goes above a certain value. The container is only allowed to go up to the limit, and then it is restricted.
+
+#### Requests
+
+Requests are what the container is guaranteed to get.
+
+### Service
+
+This defines annotations and the type of service, optionally can define name also.
+
+```yaml
+ service:
+ type: ClusterIP
+ annotations: {}
+```
+
+### Volumes
+
+```yaml
+volumes:
+ - name: log-volume
+ emptyDir: {}
+ - name: logpv
+ persistentVolumeClaim:
+ claimName: logpvc
+```
+
+It is required when some values need to be read from or written to an external disk.
+
+### Volume Mounts
+
+```yaml
+volumeMounts:
+ - mountPath: /var/log/nginx/
+ name: log-volume
+ - mountPath: /mnt/logs
+ name: logpvc
+ subPath: employee
+```
+
+It is used to provide mounts to the volume.
+
+### Affinity and anti-affinity
+
+```yaml
+Spec:
+ Affinity:
+ Key:
+ Values:
+```
+
+Spec is used to define the desire state of the given container.
+
+Node Affinity allows you to constrain which nodes your pod is eligible to schedule on, based on labels of the node.
+
+Inter-pod affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods.
+
+#### Key
+
+Key part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+#### Values
+
+Value part of the label for node selection, this should be same as that on node. Please confirm with devops team.
+
+### Tolerations
+
+```yaml
+tolerations:
+ - key: "key"
+ operator: "Equal"
+ value: "value"
+ effect: "NoSchedule|PreferNoSchedule|NoExecute(1.6 only)"
+```
+
+Taints are the opposite, they allow a node to repel a set of pods.
+
+A given pod can access the given node and avoid the given taint only if the given pod satisfies a given taint.
+
+Taints and tolerations are a mechanism which work together that allows you to ensure that pods are not placed on inappropriate nodes. Taints are added to nodes, while tolerations are defined in the pod specification. When you taint a node, it will repel all the pods except those that have a toleration for that taint. A node can have one or many taints associated with it.
+
+### Arguments
+
+```yaml
+args:
+ enabled: false
+ value: []
+```
+
+This is used to give arguments to command.
+
+### Command
+
+```yaml
+command:
+ enabled: false
+ value: []
+```
+
+It contains the commands for the server.
+
+| Key | Description |
+| :--- | :--- |
+| `enabled` | To enable or disable the command. |
+| `value` | It contains the commands. |
+
+
+### Containers
+Containers section can be used to run side-car containers along with your main container within same pod. Containers running within same pod can share volumes and IP Address and can address each other @localhost. We can use base image inside container by setting the reuseContainerImage flag to `true`.
+
+```yaml
+ containers:
+ - name: nginx
+ image: nginx:1.14.2
+ ports:
+ - containerPort: 80
+ command: ["/usr/local/bin/nginx"]
+ args: ["-g", "daemon off;"]
+ - reuseContainerImage: true
+ securityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+ volumeMounts:
+ - mountPath: /etc/ls-oms
+ name: ls-oms-cm-vol
+ command:
+ - flyway
+ - -configFiles=/etc/ls-oms/flyway.conf
+ - migrate
+```
+
+### Prometheus
+
+```yaml
+ prometheus:
+ release: monitoring
+```
+
+It is a kubernetes monitoring tool and the name of the file to be monitored as monitoring in the given case.It describes the state of the prometheus.
+
+### rawYaml
+
+```yaml
+rawYaml:
+ - apiVersion: v1
+ kind: Service
+ metadata:
+ name: my-service
+ spec:
+ selector:
+ app: MyApp
+ ports:
+ - protocol: TCP
+ port: 80
+ targetPort: 9376
+ type: ClusterIP
+```
+Accepts an array of Kubernetes objects. You can specify any kubernetes yaml here and it will be applied when your app gets deployed.
+
+### Grace Period
+
+```yaml
+GracePeriod: 30
+```
+Kubernetes waits for the specified time called the termination grace period before terminating the pods. By default, this is 30 seconds. If your pod usually takes longer than 30 seconds to shut down gracefully, make sure you increase the `GracePeriod`.
+
+A Graceful termination in practice means that your application needs to handle the SIGTERM message and begin shutting down when it receives it. This means saving all data that needs to be saved, closing down network connections, finishing any work that is left, and other similar tasks.
+
+There are many reasons why Kubernetes might terminate a perfectly healthy container. If you update your deployment with a rolling update, Kubernetes slowly terminates old pods while spinning up new ones. If you drain a node, Kubernetes terminates all pods on that node. If a node runs out of resources, Kubernetes terminates pods to free those resources. It’s important that your application handle termination gracefully so that there is minimal impact on the end user and the time-to-recovery is as fast as possible.
+
+
+### Server
+
+```yaml
+server:
+ deployment:
+ image_tag: 1-95a53
+ image: ""
+```
+
+It is used for providing server configurations.
+
+#### Deployment
+
+It gives the details for deployment.
+
+| Key | Description |
+| :--- | :--- |
+| `image_tag` | It is the image tag |
+| `image` | It is the URL of the image |
+
+### Service Monitor
+
+```yaml
+servicemonitor:
+ enabled: true
+ path: /abc
+ scheme: 'http'
+ interval: 30s
+ scrapeTimeout: 20s
+ metricRelabelings:
+ - sourceLabels: [namespace]
+ regex: '(.*)'
+ replacement: myapp
+ targetLabel: target_namespace
+```
+
+It gives the set of targets to be monitored.
+
+### Db Migration Config
+
+```yaml
+dbMigrationConfig:
+ enabled: false
+```
+
+It is used to configure database migration.
+
+
+### KEDA Autoscaling
+[KEDA](https://keda.sh) is a Kubernetes-based Event Driven Autoscaler. With KEDA, you can drive the scaling of any container in Kubernetes based on the number of events needing to be processed. KEDA can be installed into any Kubernetes cluster and can work alongside standard Kubernetes components like the Horizontal Pod Autoscaler(HPA).
+
+Example for autosccaling with KEDA using Prometheus metrics is given below:
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced:
+ restoreToOriginalReplicaCount: true
+ horizontalPodAutoscalerConfig:
+ behavior:
+ scaleDown:
+ stabilizationWindowSeconds: 300
+ policies:
+ - type: Percent
+ value: 100
+ periodSeconds: 15
+ triggers:
+ - type: prometheus
+ metadata:
+ serverAddress: http://:9090
+ metricName: http_request_total
+ query: envoy_cluster_upstream_rq{appId="300", cluster_name="300-0", container="envoy",}
+ threshold: "50"
+ triggerAuthentication:
+ enabled: false
+ name:
+ spec: {}
+ authenticationRef: {}
+```
+Example for autosccaling with KEDA based on kafka is given below :
+```yaml
+kedaAutoscaling:
+ enabled: true
+ minReplicaCount: 1
+ maxReplicaCount: 2
+ idleReplicaCount: 0
+ pollingInterval: 30
+ advanced: {}
+ triggers:
+ - type: kafka
+ metadata:
+ bootstrapServers: b-2.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-3.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092,b-1.kafka-msk-dev.example.c2.kafka.ap-southeast-1.amazonaws.com:9092
+ topic: Orders-Service-ESP.info
+ lagThreshold: "100"
+ consumerGroup: oders-remove-delivered-packages
+ allowIdleConsumers: "true"
+ triggerAuthentication:
+ enabled: true
+ name: keda-trigger-auth-kafka-credential
+ spec:
+ secretTargetRef:
+ - parameter: sasl
+ name: keda-kafka-secrets
+ key: sasl
+ - parameter: username
+ name: keda-kafka-secrets
+ key: username
+ authenticationRef:
+ name: keda-trigger-auth-kafka-credential
+```
+### Winter-Soldier
+Winter Soldier can be used to
+- cleans up (delete) Kubernetes resources
+- reduce workload pods to 0
+
+**_NOTE:_** After deploying this we can create the Hibernator object and provide the custom configuration by which workloads going to delete, sleep and many more. for more information check [the main repo](https://github.com/devtron-labs/winter-soldier)
+
+Given below is template values you can give in winter-soldier:
+```yaml
+winterSoilder:
+ enable: false
+ apiVersion: pincher.devtron.ai/v1alpha1
+ action: sleep
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges: []
+ targetReplicas: []
+ fieldSelector: []
+```
+Here,
+| Key | values | Description |
+| :--- | :--- | :--- |
+| `enable` | `false`,`true` | decide the enabling factor |
+| `apiVersion` | `pincher.devtron.ai/v1beta1`, `pincher.devtron.ai/v1alpha1` | specific api version |
+| `action` | `sleep`,`delete`, `scale` | This specify the action need to perform. |
+| `timeRangesWithZone`:`timeZone` | eg:- `"Asia/Kolkata"`,`"US/Pacific"` | It use to specify the timeZone used. (It uses standard format. please refer [this](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)) |
+| `timeRangesWithZone`:`timeRanges` | array of [ `timeFrom`, `timeTo`, `weekdayFrom`, `weekdayTo`] | It use to define time period/range on which the user need to perform the specified action. you can have multiple timeRanges. These settings will take `action` on Sat and Sun from 00:00 to 23:59:59, |
+| `targetReplicas` | `[n]` : n - number of replicas to scale. | These is mandatory field when the `action` is `scale` Default value is `[]`. |
+| `fieldSelector` | `- AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '5m'), Now()) ` | These value will take a list of methods to select the resources on which we perform specified `action` . |
+
+
+here is an example,
+```yaml
+winterSoilder:
+ apiVersion: pincher.devtron.ai/v1alpha1
+ enable: true
+ annotations: {}
+ labels: {}
+ timeRangesWithZone:
+ timeZone: "Asia/Kolkata"
+ timeRanges:
+ - timeFrom: 00:00
+ timeTo: 23:59:59
+ weekdayFrom: Sat
+ weekdayTo: Sun
+ - timeFrom: 00:00
+ timeTo: 08:00
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ - timeFrom: 20:00
+ timeTo: 23:59:59
+ weekdayFrom: Mon
+ weekdayTo: Fri
+ action: scale
+ targetReplicas: [1,1,1]
+ fieldSelector:
+ - AfterTime(AddTime( ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '10h'), Now())
+```
+Above settings will take action on `Sat` and `Sun` from 00:00 to 23:59:59, and on `Mon`-`Fri` from 00:00 to 08:00 and 20:00 to 23:59:59. If `action:sleep` then runs hibernate at timeFrom and unhibernate at `timeTo`. If `action: delete` then it will delete workloads at `timeFrom` and `timeTo`. Here the `action:scale` thus it scale the number of resource replicas to `targetReplicas: [1,1,1]`. Here each element of `targetReplicas` array is mapped with the corresponding elements of array `timeRangesWithZone/timeRanges`. Thus make sure the length of both array is equal, otherwise the cnages cannot be observed.
+
+The above example will select the application objects which have been created 10 hours ago across all namespaces excluding application's namespace. Winter soldier exposes following functions to handle time, cpu and memory.
+
+- ParseTime - This function can be used to parse time. For eg to parse creationTimestamp use `ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z')`
+- AddTime - This can be used to add time. For eg `AddTime(ParseTime({{metadata.creationTimestamp}}, '2006-01-02T15:04:05Z'), '-10h')` ll add 10h to the time. Use d for day, h for hour, m for minutes and s for seconds. Use negative number to get earlier time.
+- Now - This can be used to get current time.
+- CpuToNumber - This can be used to compare CPU. For eg `any({{spec.containers.#.resources.requests}}, { MemoryToNumber(.memory) < MemoryToNumber('60Mi')})` will check if any resource.requests is less than 60Mi.
+
+
+
+### Security Context
+A security context defines privilege and access control settings for a Pod or Container.
+
+To add a security context for main container:
+```yaml
+containerSecurityContext:
+ allowPrivilegeEscalation: false
+```
+
+To add a security context on pod level:
+```yaml
+podSecurityContext:
+ runAsUser: 1000
+ runAsGroup: 3000
+ fsGroup: 2000
+```
+
+### Topology Spread Constraints
+You can use topology spread constraints to control how Pods are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
+
+```yaml
+topologySpreadConstraints:
+ - maxSkew: 1
+ topologyKey: zone
+ whenUnsatisfiable: DoNotSchedule
+ autoLabelSelector: true
+ customLabelSelector: {}
+```
+
+### Deployment Metrics
+
+It gives the realtime metrics of the deployed applications
+
+| Key | Description |
+| :--- | :--- |
+| `Deployment Frequency` | It shows how often this app is deployed to production |
+| `Change Failure Rate` | It shows how often the respective pipeline fails. |
+| `Mean Lead Time` | It shows the average time taken to deliver a change to production. |
+| `Mean Time to Recovery` | It shows the average time taken to fix a failed pipeline. |
+
+## 2. Show application metrics
+
+If you want to see application metrics like different HTTP status codes metrics, application throughput, latency, response time. Enable the Application metrics from below the deployment template Save button. After enabling it, you should be able to see all metrics on App detail page. By default it remains disabled.
+
+
+
+Once all the Deployment template configurations are done, click on `Save` to save your deployment configuration. Now you are ready to create [Workflow](../../workflow/README.md) to do CI/CD.
+
+### Helm Chart Json Schema
+
+Helm Chart [json schema](https://github.com/devtron-labs/devtron/blob/main/scripts/devtron-reference-helm-charts/reference-chart_5-1-0/schema.json) is used to validate the deployment template values.
+
+### Other Validations in Json Schema
+
+The values of CPU and Memory in limits must be greater than or equal to in requests respectively. Similarly, In case of envoyproxy, the values of limits are greater than or equal to requests as mentioned below.
+```
+resources.limits.cpu >= resources.requests.cpu
+resources.limits.memory >= resources.requests.memory
+envoyproxy.resources.limits.cpu >= envoyproxy.resources.requests.cpu
+envoyproxy.resources.limits.memory >= envoyproxy.resources.requests.memory
+```
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template.md
new file mode 100755
index 0000000000..29a0c92cbc
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/deployment-template.md
@@ -0,0 +1,369 @@
+---
+id: deployment-template
+title: Deployment Template
+sidebar_label: Deployment Template
+---
+
+# Deployment Template
+
+## Introduction
+
+
+
+In Devtron, a [Deployment Template](../../../reference/glossary.md#deployment-template) defines how your application should run by defining its specifications. Devtron uses [Helm charts](../../../reference/glossary.md#helm-chartspackages) to manage these deployments, allowing you to control everything from [Resource Allocation](../../../reference/glossary.md#resource-allocation) to environment variables.
+
+You can use default [Deployment Charts](../../../reference/glossary.md#deployment-charts) provided by Devtron or [Custom Deployment Charts](../../global-configurations/deployment-charts.md) developed by a super-admin to suit your needs.
+
+This guide covers how to:
+
+* [Select a Deployment Chart](#select-a-deployment-chart-type)
+
+* [Choose a Chart Version](#choose-a-chart-version)
+
+* [Configure the Deployment Template](#configure-the-deployment-template)
+
+* [Enable Application Metrics](#enable-application-metrics)
+
+* [Perform a Dry Run](#perform-a-dry-run)
+
+* [Extra: Edit a Protected Deployment Configuration](#edit-a-protected-deployment-template-)
+
+---
+
+## Select a Deployment Chart Type
+
+:::caution Who Can Perform This Action?
+Users need to have [Admin role](../../../user-guide/global-configurations/user-access.md#user-roles-and-permissions) or above to select a chart.
+
+:::
+
+1. Go to the **Configurations** page of your application.
+
+ 
+
+2. Click **Base Configuration** → **Deployment Template**.
+
+ 
+
+3. Select the **Chart** drop-down box. The following tabs are displayed:
+
+ * [Charts by Devtron](./deployment-template-types/README.md) - Displays the default deployment charts provided by Devtron
+
+ * [Custom charts](../../global-configurations/deployment-charts.md) - Displays your custom deployment charts (if available). To create a custom deployment chart, refer to [Deployment Charts](../../global-configurations/deployment-charts.md).
+
+ 
+
+ 
+
+:::danger Important Note
+After you select and save a chart type for a given application, you won't be able to change it later. Make sure to choose the correct chart type before saving.
+
+:::
+
+---
+
+## Choose a Chart Version
+
+:::caution Who Can Perform This Action?
+Users need to have [Admin role](../../../user-guide/global-configurations/authorization/user-access.md#roles-available-for-devtron-apps) or above to select a chart version.
+
+:::
+
+Devtron maintains multiple chart versions for each chart type. Additionally, each chart version has a supporting README file that you can use to know more about the features and variables.
+
+
+
+Once you [select a deployment chart](#select-a-deployment-chart-type), choose a chart version with which you wish to deploy your application from the **Version** drop-down box. By default, the latest version of the helm chart is selected.
+
+
+
+---
+
+## Configure the Deployment Template
+
+:::caution Who Can Perform This Action?
+Users need to have [Admin role](../../../user-guide/global-configurations/authorization/user-access.md#roles-available-for-devtron-apps) or above to configure a deployment template. However, super-admins can lock keys in deployment template to prevent non-super-admins from modifying them. Refer [Lock Deployment Configuration](../../global-configurations/lock-deployment-config.md) to know more.
+
+:::
+
+You can edit a deployment template using the following two ways:
+
+* [Using GUI](#using-gui)
+
+* [Using YAML](#using-yaml)
+
+### Using GUI
+
+If you prefer to use a simple way to configure your chosen deployment chart, select **GUI**.
+
+
+
+By default, the following fields are commonly available for you to modify in the **GUI** section of most charts:
+
+| Fields | Description |
+| :--- | :--- |
+| **Container Port** | The internal port on which the container listens for HTTP requests. Specify the container port and optionally the service port that maps to it. |
+| **Resources** | Here, you can tweak the requests and limits of the CPU resource and RAM resource as per the application. |
+| **Autoscaling** | Define the autoscaling parameters to automatically scale your application's deployment based on resource utilization.
**Maximum Replicas**: The maximum number of replicas your application can scale up to.
**Minimum Replicas**: The minimum number of replicas your application should run at any time.
**Target CPU Utilization Percentage**: The average CPU utilization across all pods that will trigger scaling.
**Target Memory Utilization Percentage**: The average memory utilization across all pods that will trigger scaling.
|
+| **Replica Count** | Defines the number of pod replicas to be deployed for the application. Adjusting this value helps scale the application horizontally. |
+| **Ingress** | Enable the `Ingress` to control external access to the application using HTTP/HTTPS routes. You can define hostnames, paths, and ingress class settings. By default, it is in the `disabled` state.
**Host**: Domain name of the server.
**Path**: Path of the specific component in the host that the HTTP wants to access.
You can define multiple paths as required by clicking **Add paths**.|
+| **Environment Variables** (**Key/Value**) | Define `key/value` by clicking **Add variable**.
**Key**: Define the key of the environment.
**Value**: Define the value of the environment.
You can define multiple env variables by clicking **Add EnvironmentVariables**. |
+| **Readiness Probe** | Define the readiness probe to determine when a container is ready to start accepting traffic.
**Path**: The HTTP path that the readiness probe will access.
**Port**: The port on which the readiness probe will access the application.
|
+| **Liveness Probe** | Define the liveness probe to check if the container is still running and to restart it if it is not.
**Path**: The HTTP path that the liveness probe will access.
**Port**: The port on which the liveness probe will access the application.
|
+| **Service** | Configure the service that exposes your application to the network.
**Type**: Specify the type of service (e.g., ClusterIP, NodePort, LoadBalancer).
**Annotations**: Add custom annotations to the service for additional configuration.
|
+| **serviceAccount** | Specify the service account for the deployment to use, allowing it to access Kubernetes API resources.
**Create**: Toggle to create a new service account.
**Name**: The name of the service account to use.
|
+| **podDisruptionBudget** | Ensure high availability by setting limits on how many pods can be disrupted at a time during voluntary disruptions like maintenance or updates. |
+| **Spec** | Define node selection rules using key-value pairs. This ensures that the pod runs on specific nodes that match your given labels. |
+| **Tolerations** | Define tolerations to allow the pods to be scheduled on nodes with matching taints.
**Key**: The key of the taint to tolerate.
**Operator**: The relationship between the key and the value (e.g., Exists, Equal).
**Value**: The value of the taint to match.
**Effect**: The effect of the taint to tolerate (e.g., NoSchedule, NoExecute).
|
+| **Image** | Defines the container image to be used for deployment, including its pull policy (e.g., IfNotPresent, Always, Never) |
+| **Arguments** | Enable the `Arguments` to pass one or more argument values. By default, it is in the `disabled` state. |
+| **Command** | Enable the `Command` to pass one or more command values (e.g., `/bin/sh -c "/app/custom-script.sh"`). By default, it is in the `disabled` state. |
+| **imagePullSecrets** | Provide secrets to authenticate and pull container images from a private registry. |
+
+
+If you wish to perform additional configurations, click the **Switch to Advanced** button or **YAML** button. Or [perform a dry run](#perform-a-dry-run) before saving your configuration.
+
+
+
+:::info Note
+* If you change any values in the **GUI**, then the corresponding values will change in **YAML** too.
+
+* Users who are not super-admins will land on **GUI** section when they visit **Deployment Template** page; whereas super-admins will land on **YAML** section. This is just a default behavior, they can still navigate to the other section if needed.
+
+:::
+
+#### Customize the GUI
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../../global-configurations/user-access.md#assign-super-admin-permissions) can customize the GUI section.
+
+:::
+
+By default, the **GUI** section comes with multiple predefined fields as seen earlier [in the table](#using-gui). However, if you wish to display a different set of fields to your team, you can modify the whole section as per your requirement.
+
+This is useful in scenarios where:
+
+ * Your team members find it difficult to understand and edit the YAML section.
+
+ * You frequently edit certain fields in **YAML**, which you expect to remain easily accessible in **GUI** section.
+
+ * You don't require some fields in **GUI** section.
+
+ * You need the autonomy to keep the GUI unique for applications/clusters/environments/charts, or display the same GUI everywhere.
+
+There are two ways you can customize the GUI, use any one of the following:
+
+1. From [Deployment Charts](../../global-configurations/deployment-charts.md#editing-gui-schema-of-deployment-charts-) section
+
+2. Using APIs (explained below)
+
+
+
+You can pass a custom JSON (deployment schema) of your choice through the following API. You may need to run the API with the `POST` method if you are doing it for the first time.
+
+```
+PUT {{DEVTRON_BASEURL}}/orchestrator/deployment/template/schema
+```
+
+```json title="Sample API Request Body" showLineNumbers
+{
+ "name": "schema-1",
+ "type": "JSON",
+ "schema": "{\"type\":\"object\",\"properties\":{\"args\":{\"type\":\"object\",\"title\":\"Arguments\",\"properties\":{\"value\":{\"type\":\"array\",\"items\":{\"type\":\"string\"},\"title\":\"Value\"},\"enabled\":{\"type\":\"boolean\",\"title\":\"Enabled\"}}},\"command\":{\"type\":\"object\",\"title\":\"Command\",\"properties\":{\"value\":{\"type\":\"array\",\"items\":{\"type\":\"string\"},\"title\":\"Value\"},\"enabled\":{\"type\":\"boolean\",\"title\":\"Enabled\"}}},\"resources\":{\"type\":\"object\",\"title\":\"Resources(CPU&RAM)\",\"properties\":{\"limits\":{\"type\":\"object\",\"required\":[\"cpu\",\"memory\"],\"properties\":{\"cpu\":{\"type\":\"string\"},\"memory\":{\"type\":\"string\"}}},\"requests\":{\"type\":\"object\",\"properties\":{\"cpu\":{\"type\":\"string\"},\"memory\":{\"type\":\"string\"}}}}},\"autoscaling\":{\"type\":\"object\",\"title\":\"Autoscaling\",\"properties\":{\"MaxReplicas\":{\"type\":[\"integer\",\"string\"],\"title\":\"MaximumReplicas\",\"pattern\":\"^[a-zA-Z0-9-+\\\\/*%_\\\\\\\\s]+$\"},\"MinReplicas\":{\"type\":[\"integer\",\"string\"],\"title\":\"MinimumReplicas\",\"pattern\":\"^[a-zA-Z0-9-+\\\\/*%_\\\\\\\\s]+$\"},\"TargetCPUUtilizationPercentage\":{\"type\":[\"integer\",\"string\"],\"title\":\"TargetCPUUtilizationPercentage\",\"pattern\":\"^[a-zA-Z0-9-+\\\\/*%_\\\\\\\\s]+$\"},\"TargetMemoryUtilizationPercentage\":{\"type\":[\"integer\",\"string\"],\"title\":\"TargetMemoryUtilizationPercentage\",\"pattern\":\"^[a-zA-Z0-9-+\\\\/*%_\\\\\\\\s]+$\"}}},\"EnvVariables\":{\"type\":\"array\",\"items\":{\"type\":\"object\",\"properties\":{\"key\":{\"type\":\"string\"},\"value\":{\"type\":\"string\"}}},\"title\":\"EnvironmentVariables\"},\"ContainerPort\":{\"type\":\"array\",\"items\":{\"type\":\"object\",\"properties\":{\"port\":{\"type\":\"integer\"}}},\"title\":\"ContainerPort\"}}}",
+ "selectors": [
+ {
+ "attributeSelector": {
+ "category": "APP",
+ "appNames": ["my-demo-app"]
+ }
+ },
+ {
+ "attributeSelector": {
+ "category": "ENV",
+ "envNames": ["env1", "env2", "env3"]
+ }
+ },
+ {
+ "attributeSelector": {
+ "category": "CLUSTER",
+ "clusterNames": ["cluster1", "cluster2", "cluster3"]
+ }
+ },
+ {
+ "attributeSelector": {
+ "category": "CHART_REF",
+ "chartVersions": [
+ {
+ "type": "Deployment",
+ "version": "1.0.0"
+ }
+ ]
+ }
+ },
+ {
+ "attributeSelector": {
+ "category": "APP_ENV",
+ "appEnvNames": [
+ {
+ "appName": "my-demo-app",
+ "envName": "devtron"
+ }
+ ]
+ }
+ }
+ ]
+}
+
+```
+
+
+1. In the `name` field, give a name to your schema, e.g., *schema-1*
+
+2. Enter the `type` as JSON.
+
+3. The `schema` field is for entering your custom JSON representing the deployment template's GUI. You can customize the fields that are displayed in the GUI section while configuring the deployment template. Perform the following steps:
+
+ * To create a custom JSON for your deployment, you may use [RJSF JSON Schema Tool](https://rjsf-team.github.io/react-jsonschema-form/).
+
+ * Copy the final JSON and stringify it using any free online tool.
+
+ * Paste the stringified JSON in the `schema` field of the API request body.
+
+ * Send the API request. If your schema already exists, use the `PUT` method instead of `POST` in the API call.
+
+4. The `attributeSelector` object helps you choose the scope at which your custom JSON will take effect.
+
+ | Priority | Category Scope | Description |
+ |----------|-----------------|----------------------------------------------------------------------------|
+ | 1 (High) | APP_ENV | Specific to an application and its environment |
+ | 2 | APP | Applies at the application level if no specific environment is defined |
+ | 3 | ENV | Applies to specific deployment environment |
+ | 4 | CHART_REF | Applies to all applications using a specific chart type and version |
+ | 5 | CLUSTER | Applies across all applications and environments within a specific cluster |
+ | 6 | GLOBAL | Universally applies if no other more specific schemas are defined |
+
+
+### Using YAML
+
+If you prefer to perform additional configurations in your chosen deployment template, select **YAML**.
+
+
+
+Every chart version has its own YAML file that provides specifications for your application. To make it easy to use, we have created templates for the YAML file and added some variables inside the YAML. You can provide or change the values of these variables as per your requirement.
+
+Refer the respective templates to view the YAML details.
+
+* [Deployment](./deployment-template-types/deployment.md)
+
+* [Rollout Deployment](./deployment-template-types/rollout-deployment.md)
+
+* [Job & CronJob](./deployment-template-types/job-and-cronjob.md)
+
+* [StatefulSet](./deployment-template-types/statefulset.md)
+
+Before saving your configuration in YAML, make sure to [perform a dry run](#perform-a-dry-run).
+
+---
+
+## Enable Application Metrics
+
+The availability of application metrics depends on the selected chart type and version. If supported, you can view key performance metrics such as:
+
+* Status codes (2xx, 3xx, 5xx)
+* Throughput
+* Latency
+* And more
+
+To enable this, turn on the **Show application metrics** toggle.
+
+
+
+Once enabled, you can view the application metrics on the **App Details** page.
+
+
+
+:::info Important
+Enabling application metrics adds a sidecar container to your main container, which may require additional configuration. We recommend running a load test in a non-production environment before enabling it in production.
+
+:::
+
+---
+
+## Perform a Dry Run
+
+Before saving your configured deployment template, you can use the **Dry Run** option (as shown below) to preview the final Kubernetes manifests.
+
+This feature helps you verify your configurations, detect issues, and ensure correctness before actual deployment.
+
+
+
+Your configurations will appear in the left pane, while the right pane will display a section named `Manifest generated from merged` showing the computed Kubernetes manifests, each representing a separate resource after merging all your changes.
+
+---
+
+## Edit a Protected Deployment Template
+
+:::info Who Can Perform This Action?
+Only a super-admin, manager, and admin can edit the configuration values.
+
+:::
+
+Any changes made to the deployment template will require approval if an approval policy is enforced. To check if your deployment template is protected, check the stamp/approve symbol as shown below.
+
+
+
+### Request Approval for Changes
+
+Let's assume you are the application admin and your deployment template in **Base Configurations** is protected from edits.
+
+1. In the YAML editor of the deployment template, modify the values.
+
+ 
+
+2. You can change the value of a key to a desired value as shown below. Once done, click the **Save Changes** button.
+
+ 
+
+:::info What if the keys are locked from editing?
+You cannot modify locked keys in deployment template unless you are a super-admin. Refer [Lock Deployment Configuration](../../global-configurations/lock-deployment-config.md) to know more.
+
+:::
+
+3. Since the deployment configuration is protected, your changes won't be published right away. You can do either of the following:
+
+ * **Save as draft** : Selecting this option will save your file as a draft. You and other users can view and edit the saved draft and propose it further for approval.
+
+ * **Save & Propose Changes** : Selecting this option will allow you to choose and notify the configuration approver(s) and propose your changes for a review. Moreover, it also has the option to notify all the users having access to the application on Devtron.
+
+ Since we are proposing the changes immediately, click **Propose Changes**.
+
+ 
+
+4. You can also view the approval status if you wish.
+
+ 
+
+:::info Can I approve my own changes?
+No, the one who performs the edits cannot approve their own changes. A different user has to review and approve.
+
+:::
+
+Only one draft can exist at time and you cannot create multiple drafts. In the top-right corner, you have the option to discard the draft if you don't wish to proceed with the edits you made.
+
+
+
+### Grant Approval for Changes
+
+:::info Who Can Perform This Action?
+Only a valid approver or a Super-Admin can approve the changes made to the deployment configuration. Refer to [Approval Policy](../../global-configurations/approval-policy.md) for more information.
+
+:::
+
+Go to the edited configuration file to review and approve the changes as shown below.
+
+
+
+:::info Note
+If [SES/SMTP](../../global-configurations/manage-notification.md) is configured in Devtron, the approver gets notified via email. Therefore, the approver can take an action directly from the mail as shown below. Once the approver validates and approves your configuration changes, you can proceed to deploy your application with the updated configuration.
+
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/README.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/README.md
new file mode 100755
index 0000000000..5ae1d7639a
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/README.md
@@ -0,0 +1,19 @@
+---
+id: README
+title: Types of External Secrets
+sidebar_label: Types of External Secrets
+hide_table_of_contents: true
+---
+
+# Types of External Secrets
+
+Apart from the provision to add Secrets, Devtron supports the addition of External Secrets too including:
+
+* [AWS Secrets Manager](aws-eso.md)
+* [Google Secrets Manager](gcp-eso.md)
+* [HashiCorp Vault](hashicorp-eso.md)
+* Azure Secrets Manager
+
+
+
+However make sure to install [ESO chart](install-eso.md) to your cluster before adding any of the above external secrets.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/aws-eso.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/aws-eso.md
new file mode 100755
index 0000000000..4d6a39435b
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/aws-eso.md
@@ -0,0 +1,112 @@
+---
+id: aws-eso
+title: AWS Secrets Manager
+sidebar_label: AWS Secrets Manager
+---
+
+# AWS Secrets Manager
+
+:::caution Prerequisite
+Install [External Secret Operator (ESO)](install-eso.md).
+:::
+
+To add secrets from **AWS Secrets Manager**, we need to create a generic Kubernetes secret for AWS authentication.
+
+Create a Kubernetes secret in the namespace in which the application is to be deployed using base64 encoded AWS access-key and secret-access-key. You can use a Devtron generic chart for it.
+
+**Note**: You don't have to create the Kubernetes secret every time you create external secret for the respective namespace.
+
+
+
+After creating the generic secret, navigate to `Secrets` section of the application and follow the steps mentioned below :
+
+1. Click `Add Secret` to add a new secret
+
+ 
+
+2. Select `AWS Secret Manager` under `External Secret Operator` (ESO) from the dropdown of `Data type`
+
+ 
+
+3. Configure the secret.
+
+ | Key | Description |
+ | :--- | :--- |
+ | `region` | AWS region in which secret is created |
+ | `accessKeyIDSecretRef.name` | Name of secret created that would be used for authentication|
+ | `accessKeyIDSecretRef.key` | In generic secret created for AWS authentication, variable name in which base64 encoded AWS access-key is stored |
+ | `secretAccessKeySecretRef.name` | Name of secret created that would be used for authentication|
+ | `secretAccessKeySecretRef.key` | In generic secret created for AWS authentication, variable name in which base64 encoded secret-access-key is stored|
+ | `secretKey` | Key name to store secret |
+ | `key` | AWS Secrets Manager secret name |
+ | `property` | AWS Secrets Manager secret key |
+
+ 
+
+ 
+
+
+4. Save the secret.
+
+
+## ESO AWS secrets Manager Setup with Devtron using ClusterSecretsStore
+
+ClusterSecretStore provides a secure and centralized storage solution for managing and accessing sensitive information, such as passwords, API keys, certificates, and other credentials, within a cluster or application environment.
+
+**Requirement:** Devtron deployment template chart version should be 4.17 and above.
+
+To setup ESO AWS secrets manager with Devtron using ClusterSecretsStore, follow the mentined steps:
+
+**1. Create a secret for AWS authentication**
+
+Create a Kubernetes secret in any namespace using base64 encoded AWS access-key and secret-access-key. You can use the devtron generic chart for this.
+
+
+
+**2. Create a `ClusterSecretStore`**
+
+Create a `ClusterSecretStore` using the secret created for AWS authentication in step 1.
+
+
+
+**3. Create a secret in the application using ESO AWS Secrets Manager**
+
+Go to the application where you want to create an external secret. Navigate to secrets section under application configuration and create a secret using ESO AWS Secrets Manager.
+
+
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/gcp-eso.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/gcp-eso.md
new file mode 100755
index 0000000000..5f4dd1adbe
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/gcp-eso.md
@@ -0,0 +1,63 @@
+---
+id: gcp-eso
+title: Google Secrets Manager
+sidebar_label: Google Secrets Manager
+hide_table_of_contents: true
+---
+
+# Google Secrets Manager
+
+:::caution Prerequisite
+Install [External Secret Operator (ESO)](install-eso.md).
+:::
+
+To add secrets from **Google Secrets Manager**, follow the steps mentioned below :
+
+1. Go to Google cloud console and create a Service Account.
+
+ 
+
+
+ 
+
+2. Assign roles to the service account.
+
+ 
+
+3. Add and create a new key.
+
+ 
+
+ 
+
+
+4. Create a Kubernetes secret in the namespace in which the application is to be deployed using base64 encoded service account key.
+
+ You can use devtron generic chart for this.
+
+ 
+
+5. After creating the generic secret, navigate to `Secrets` section of the application and click `Add Secret` to add a new secret.
+
+ 
+
+6. Select `Google Secrets Manager` under `External Secret Operator` (ESO) from the dropdown of `Data type`.
+
+ 
+
+7. Configure secret.
+
+ 
+
+ | Key | Description |
+ | :--- | :--- |
+ | `secretAccessKeySecretRef.name` | Name of secret created that would be used for authentication.|
+ | `secretAccessKeySecretRef.key` | In generic secret created for GCP authentication, variable name in which base64 encoded service account key is stored.|
+ | `ProjectID` | GCP Project ID where secret is created. |
+ | `secretKey` | Key name to store secret. |
+ | `key` | GCP Secrets Manager secret name. |
+
+
+ 
+
+8. Save secret.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/hashicorp-eso.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/hashicorp-eso.md
new file mode 100755
index 0000000000..262345d4bf
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/hashicorp-eso.md
@@ -0,0 +1,69 @@
+---
+id: hashicorp-eso
+title: HashiCorp Vault
+sidebar_label: HashiCorp Vault
+hide_table_of_contents: true
+---
+
+# HashiCorp Vault
+
+:::caution Prerequisite
+Install [External Secret Operator (ESO)](install-eso.md).
+:::
+
+To incorporate secrets from **HashiCorp Vault**, you need to create a generic Kubernetes secret that will be used for vault authentication. This involves creating a Kubernetes secret in the specific namespace where your application will be deployed.
+The secret should store the base64-encoded password or token obtained from vault. To simplify the process, you can utilize the Devtron generic chart. An example yaml is given below:
+
+```yaml
+apiVersion: v1
+kind: Secret
+type: Opaque
+data:
+ token:
+metadata:
+ name: vault-token
+ namespace:
+```
+
+**Note**: Please note that you don't need to create the Kubernetes secret every time you create an External Secret for the corresponding namespace.
+
+Once you have created the generic secret, follow these steps in the application's Secrets section:
+
+**1. Create a new secret**
+
+To add a new secret to the application, go to the **Configurations** page of the application. Then, navigate to the left pane and select the `Secrets` option and click the **Add Secret** button.
+
+
+
+**2. Select `HashiCorp Vault` as the External Secret Operator**
+
+After clicking the **Add Secret** button, select `HashiCorp Vault` from the dropdown menu for the `Data type` option. Provide a name for the secret you are creating, and then proceed to configure the external secret as described in the next step.
+
+
+
+**3. Configure the secret**
+
+To configure the external secret that will be fetched from HashiCorp Vault for your application, you will need to provide specific details using the following key-value pairs:
+
+
+
+
+| Key | Description |
+| :--- | :--- |
+| `vault.server` | Server is the connection address for the Vaultserver, e.g: "https://vault.example.com:8200" |
+| `vault.path` | Specify the path where the secret is stored in Vault |
+| `tokenSecretRef.name` | Enter the name of the secret that will be used for authentication |
+| `tokenSecretRef.key` | Specify the key name within the secret that contains the token |
+| `secretKey` | Provide a name for the secret in Kubernetes |
+| `key` | Enter the name of the secret in Vault |
+| `property` | Specify the key within the Vault secret |
+
+
+
+
+
+**4. Save the secret**
+
+After configuring the external secret from HashiCorp Vault, proceed to save the secret by clicking the **Save** button.
+
+By following the steps mentioned above and configuring these values correctly, you can seamlessly fetch and utilize external secrets from HashiCorp Vault within your application environment by deploying the application.
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/install-eso.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/install-eso.md
new file mode 100755
index 0000000000..6df641a375
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/install-eso.md
@@ -0,0 +1,32 @@
+---
+id: install-eso
+title: Install ESO
+sidebar_label: Install ESO
+---
+
+# Install ESO
+
+:::info Prerequisites
+Chart version should be > 4.14.0
+:::
+
+## Introduction
+
+External Secrets Operator is a Kubernetes operator that integrates external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault and many more. The operator reads information from external APIs and automatically injects the values into a Kubernetes Secret.
+
+---
+
+## Install External Secret Operator
+
+Before creating any external secrets on Devtron, `External Secret Operator` must be installed on the target cluster. `External Secret Operator` allows you to use external secret management systems (e.g., AWS Secrets Manager, Hashicorp Vault, Azure Secrets Manager, Google Secrets Manager etc.) to securely inject secrets in Kubernetes.
+
+You can install `External Secrets Operator` using charts store:
+
+1. Go to the **Charts Store**.
+2. Search the chart named `external-secrets`.
+
+
+
+3. If you don't find any chart with this name i.e `external-secrets`, add chart repository using repository url ` https://charts.external-secrets.io`. Please follow this [documentation](../../../global-configurations/chart-repo.md#add-chart-repository) for adding chart repository.
+
+4. Deploy the chart.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/secrets.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/secrets.md
new file mode 100755
index 0000000000..b718a9f49e
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/eso/secrets.md
@@ -0,0 +1,205 @@
+---
+id: secrets
+title: Secrets
+sidebar_label: Secrets
+---
+
+# Secrets
+
+Secrets allow you to store environment variables and files. With Secrets, you can store and manage sensitive information (e.g., passwords, authentication tokens, and SSH keys) in base64 encrypted form. Embedding this information in secrets is safer and more flexible than putting it verbatim in a pod definition or in a container image. Devtron generally hides the data of secrets, and it is only visible to the users having the edit permission.
+
+Simply put, if a [ConfigMap](../config-maps.md) is a recipe card in the kitchen, then a secret is the locked box containing a special ingredient that only your chef (application) can unlock and use.
+
+## Add Secret
+
+1. Go to the **Configurations** → **Base Configurations**.
+
+ 
+
+2. Click the **+** button next to **Secrets**.
+
+ 
+
+3. **Data Type** - Choose between the following data types:
+ * [Kubernetes Secret](#kubernetes-secret)
+ * [Mount Existing Kubernetes Secret](#mount-existing-kubernetes-secrets)
+ * [External Secret Operator (ESO)](#external-secret-operator-eso)
+
+ **Note**: Devtron automatically converts secrets from various data types to Kubernetes Secrets. Regardless of the original data type, once the conversion is complete, the Pods can access the secrets in the same way as native Kubernetes Secrets.
+
+### Kubernetes Secret
+
+1. Select **Kubernetes Secret** as the Data Type.
+
+2. **Name** - Provide a name to your Secret (cannot be changed later).
+
+ 
+
+3. **Mount data as** - Select how you want to mount the Secret:
+ * **Environment Variable** – Select this option if you want to inject Environment Variables in pods using Secret.
+ * **Data Volume** – Select this option, if you want to configure a Data Volume that is accessible to Containers running in a pod and provide a Volume mount path. Go to [Data Volume](#mount-data-as-data-volume) to know more.
+
+4. Enter data in:
+ - **GUI mode** – User-friendly interface. Click **+Add** button and enter the **Key** and **Value** fields without quotes.
+ - **YAML mode** – Raw YAML for entering key-value pairs in the format **`key: value`**. Boolean and numeric values must be wrapped in double quotes.
+
+
+
+5. You may [perform a dry run](#perform-a-dry-run) before clicking **Save**.
+
+### Mount Existing Kubernetes Secrets
+
+Use this option to mount an existing Kubernetes Secret in your application pods. A Secret will not be created by system so please ensure that the secret with the same name already exists within the namespace. Otherwise, the deployment will fail.
+
+1. Select **Mount Existing Kubernetes Secrets** as the Data Type.
+
+2. **Name** - Make sure you give the same name as the existing secret. Otherwise, it might result in an error during the build.
+
+3. Mount data as: **Environment Variable** or [Data Volume](#mount-data-as-data-volume)
+
+4. Click **Save**.
+
+---
+
+## Mount Data as Data Volume
+
+### Mount Secret from File
+
+In the above example, we have seen how to pass environment variables in your Secret. Additionally, there is an option to mount a Secret by passing its content to a file. The content could be a plain text, json, yaml, bash script, etc. You can do so by selecting the `Data Volume` option in **Mount data as**.
+
+
+
+The key of the Secret should be your filename and the value of the Secret should be your file content. In the below example, you `file.json` is the key, and the json content is the value of that Secret (below the pipe (**|**) symbol). This file will be created on your specified [volume mount path](#volume-mount-path).
+
+
+
+### Volume Mount Path
+
+Enter the folder path where the data volume should be mounted for it to be accessible to the containers running in a pod. Your keys will be mounted as files to that volume.
+
+
+
+### Set Sub Path
+
+When mounting multiple files to the same location, you can use the **Set Sub Path** option to control how the files are handled. This setting allows you to control whether existing files are overwritten or preserved when mounting new files.
+
+* If **Set Sub Path** is enabled, the system will preserve existing files in the [specified path](#volume-mount-path) and append the new file using the file name as a sub-path.
+
+* If **Set Sub Path** is disabled (unchecked), the system will delete any files already present in the [specified path](#volume-mount-path) and then mount the new files.
+
+:::info Note
+In case of Kubernetes Secrets, all keys will be mounted as files on the specified path.
+In case of External Secrets, manually specify the keys which should be mounted as files.
+:::
+
+
+### Set File Permission
+
+The **Set File Permission** option applies permissions at the Secret level, not to its individual secret keys. Enabling this option will let you enter a 3-digit standard permission value to control access to the file.
+
+The 3-digit numeric value represents the permission settings for the file:
+
+* **First digit**: Owner permissions (user).
+* **Second digit**: Group permissions.
+* **Third digit**: Other users' permissions.
+
+| **Permission** | **Description** |
+|----------------|------------------------------------------------|
+| **r** (read) | Grants the ability to read the file. |
+| **w** (write) | Grants the ability to modify the file. |
+| **x** (execute)| Grants the ability to execute the file as a program. |
+
+For example, **755** means:
+* Owner can read, write, and execute (7),
+* Group can read and execute (5),
+* Others can read and execute (5).
+
+---
+
+## Perform a Dry Run
+
+Before saving your configured Secret, you can use the **Dry Run** option (as shown below) to preview the final Kubernetes manifest.
+
+This feature helps you verify your configurations, detect issues, and ensure correctness.
+
+
+
+Your configurations will appear in the left pane, while the right pane will display a section named `Manifest generated from merged` showing the computed Kubernetes manifest.
+
+---
+
+## Update Secret
+
+1. Click your Secret available inside the list of **Secrets** inside **Base Configurations**.
+2. Modify its values.
+3. Click **Update**.
+
+:::caution Note
+You cannot change the name of a Secret. Create a new Secret instead.
+:::
+
+
+
+---
+
+## Delete Secret
+
+You may delete a Secret if not in use anymore. Once a Secret is deleted, it will not be used in future deployments.
+
+1. Click your Secret available inside the list of **Secrets** inside **Base Configurations**.
+2. On the right side, click the kebab menu (3 vertical dots).
+3. Click **Delete**.
+4. Confirm the deletion in the dialogbox.
+
+
+
+---
+
+## Edit a Protected Secret
+
+Any changes made to the protected base configurations (Deployment Template, ConfigMap, Secret) will require approval if an [approval policy](../../../global-configurations/approval-policy.md) is enforced.
+
+
+
+---
+
+## External Secret Operator (ESO)
+
+:::info Prerequisite
+Chart version should be > 4.14.0
+:::
+
+### Purpose
+
+This section is for users who wish to use the following data type while adding secrets in Devtron:
+* [Google Secrets Manager](../eso/gcp-eso.md)
+* [AWS Secrets Manager](../eso/aws-eso.md)
+* [Hashi Corp Vault](../eso/hashicorp-eso.md)
+* Azure Secrets Manager
+
+External Secrets Operator (ESO) is a Kubernetes component that integrates with external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, and more. It retrieves secrets from these external sources and injects them into Kubernetes Secrets automatically. Before you can create external secrets in Devtron, you need to install the External Secrets Operator on the target cluster.
+
+### Installation Steps
+
+1. Go to the **Chart Store**.
+
+2. Search for the `external-secrets` chart.
+
+ 
+
+:::info What if external-secrets chart is not found?
+Manually add the following chart repository URL in Devtron: `https://charts.external-secrets.io`. Follow this [guide](../../../global-configurations/chart-repo.md#add-chart-repository) to know the steps.
+:::
+
+3. Give a name to the helm app that will be created from the chart. Also enter the project and environment where you wish to install the chart.
+
+ 
+
+4. Click **Deploy Chart**.
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/base-config/secrets.md b/versioned_docs/version-1.7/user-guide/creating-application/base-config/secrets.md
new file mode 100755
index 0000000000..fd9d828649
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/base-config/secrets.md
@@ -0,0 +1,154 @@
+---
+id: secrets
+title: Secrets
+sidebar_label: Secrets
+---
+
+# Secrets
+
+Secrets and configmaps both are used to store environment variables but there is one major difference between them: Configmap stores key-values in normal text format while secrets store them in base64 encrypted form. Devtron hides the data of secrets for the normal users and it is only visible to the users having edit permission.
+
+Secret objects let you store and manage sensitive information, such as passwords, authentication tokens, and ssh keys. Embedding this information in secrets is safer and more flexible than putting it verbatim in a Pod definition or in a container image.
+
+## Configure Secret
+
+
+
+Click `Add Secret` to add a new secret.
+
+
+
+
+| Key | Description |
+| :--- | :--- |
+| `Name` | Provide a name to your Secret |
+| `Data Type` | Provide the Data Type of your secret. To know about different Data Types available click on [Data Types](secrets.md#data-types) |
+| `Data Volume` | Specify if there is a need to add a volume that is accessible to the Containers running in a pod. |
+| `Use secrets as Environment Variable` | Select this option if you want to inject Environment Variables in your pods using Secrets. |
+| `Use secrets as Data Volume` | Select this option if you want to configure a Data Volume that is accessible to Containers running in a pod. Ensure that you provide a Volume mount path for the same. |
+| `Key-Value` | Provide a key and the corresponding value of the provided key. |
+
+## Volume Mount Path
+
+Specify the volume mount folder path in `Volume Mount Path`, a path where the data volume needs to be mounted. This volume will be accessible to the containers running in a pod.
+
+
+
+## Sub Path
+For multiple files mount at the same location you need to check sub path `bool` field, it will use the file name (key) as sub path.
+Sub Path feature is not applicable in case of external configmap except
+AWS Secret Manager, AWS System Manager and Hashi Corp Vault, for these cases `Name (Secret key)` as sub path will be picked up automatically.
+
+## File Permission
+File permission will be provide at the configmap level not on the each key of the configmap. it will take 3 digit standard permission for the file.
+
+
+Click `Save Secret` to save the secret.
+
+
+
+You can see the Secret is added.
+
+
+
+## Update Secrets
+
+You can update your secrets anytime later, but you cannot change the name of your secrets. If you want to change your name of secrets then you have to create a new secret.
+
+To update secrets, click the secret you wish to update.
+
+
+
+Click `Update Secret` to update your secret.
+
+## Delete Secret
+
+You can delete your secret. Click your secret and click the `delete sign` to delete your secret.
+
+
+
+## Data Types
+
+There are five Data types that you can use to save your secret.
+
+* **Kubernetes Secret**: The secret that you create using Devtron.
+* **Kubernetes External Secret**: The secret data of your application is fetched by Devtron externally. Then the Kubernetes External Secret is converted to Kubernetes Secret.
+* [External Secrets Operator](./eso/README.md)
+ * **Google Secrets Manager**
+ * **AWS Secret Manager**
+ * **Azure Secrets Manager**
+ * **HashiCorp Vault**
+
+*Note: The conversion of secrets from various data types to Kubernetes Secrets is done within Devtron and irrespective of the data type, after conversion, the Pods access `secrets` normally.*
+
+## Mount Existing Kubernetes Secrets
+
+Use this option to mount an existing Kubernetes Secret in your application pods. A Secret will not be created by system so please ensure that the secret already exist within the namespace else the deployment will fail.
+
+### Kubernetes External Secret (Deprecated)
+
+The secret that is already created and stored in the environment and being used by Devtron externally is referred here as `Kubernetes External Secret`. For this option, Devtron will not create any secret by itself but they can be used within the pods. Before adding secret from kubernetes external secret, please make sure that secret with the same name is present in the environment. To add secret from kubernetes external secret, follow the steps mentioned below:
+
+1. Navigate to `Secrets` of the application.
+2. Click `Add Secret` to add a new secret.
+3. Select `Kubernetes External Secret` from dropdown of `Data type`.
+4. Provide a name to your secret. Devtron will search secret in the environment with the same name that you mention here.
+
+---
+
+## External Secrets
+
+Refer [External Secrets Operator](./eso/README.md) to know more.
+
+### AWS Secret Manager
+
+Before adding any external secrets on Devtron, `kubernetes-external-secrets` must be installed on the target cluster. Kubernetes External Secrets allows you to use external secret management systems (e.g., AWS Secrets Manager, Hashicorp Vault, etc) to securely add secrets in Kubernetes.
+
+#### Installing kubernetes-external-secrets Using Chart
+
+To install the chart with the release named my-release:
+
+```bash
+$ helm install my-release external-secrets/kubernetes-external-secrets
+```
+To install the chart with AWS IAM Roles for Service Accounts:
+
+```bash
+$ helm install my-release external-secrets/kubernetes-external-secrets --set securityContext.fsGroup=65534 --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"='arn:aws:iam::111111111111:role/ROLENAME'
+```
+#### Adding Secrets From AWS Secret Manager
+
+To add secrets from AWS secret manager, navigate to `Secrets` of the application and follow the steps mentioned below :
+
+
+
+1. Click `Add Secret` to add a new secret.
+
+
+
+2. Select `AWS Secret Manager` from dropdown of `Data type`.
+
+3. Provide a name to your secret.
+
+4. Select how you want to use the secret. You may leave it selected as environment variable and also you may leave `Role ARN` empty.
+
+5. In `Data` section, you will have to provide data in key-value format.
+
+All the required field to pass your data to fetch secrets on Devtron are described below :
+
+| Key | Description |
+| :--- | :--- |
+|`key`| Secret key in backend |
+|`name`| Name for this key in the generated secret |
+|`property`| Property to extract if secret in backend is a JSON object |
+|`isBinary`| Set this to true if configuring an item for a binary file stored else set false |
+
+#### Adding Secrets in AWS Secret Manager
+
+To add secrets in AWS secret manager, do the following steps :
+
+1. Go to AWS secret manager console.
+2. Click `Store a new secret`.
+3. Add and save your secret.
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/config-approval.md b/versioned_docs/version-1.7/user-guide/creating-application/config-approval.md
new file mode 100755
index 0000000000..51bf4b5c07
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/config-approval.md
@@ -0,0 +1,140 @@
+---
+id: config-approval
+title: Protect Configuration
+sidebar_label: Protect Configuration
+---
+
+# Protect Configuration
+
+## Introduction
+
+Since resources are created according to the configurations you enter, it's essential to restrict such configurations from direct modifications. For critical environments like production, it becomes necessary to introduce an approval flow for any edits made to the configuration files.
+
+In Devtron, these configurations are present in the **App Configuration** tab of your application.
+
+Any changes made to the following configurations will require approval if enabled:
+
+- Deployment Template
+- ConfigMaps
+- Secrets
+
+This stands true for both: base configuration and respective environment-level configuration.
+
+
+
+
+
+---
+
+## Tutorial
+
+
+
+---
+
+## Changing the Configuration Values
+
+:::info
+Only a super-admin, manager, and admin can edit the configuration values.
+:::
+
+Let's assume you are the application admin and you wish to edit the deployment template of your environment (as an override).
+
+1. Go to the `App Configuration` tab.
+
+2. In Environment Overrides → (choose your environment) → Deployment Template
+
+ 
+
+3. You can change the value of a key to a desired value as shown below. Once done, click the **Save Changes…** button.
+
+ 
+
+:::info
+If you are not a super-admin, you cannot modify the locked keys in deployment template. Refer [Lock Deployment Configuration](../global-configurations/lock-deployment-config.md) to know more.
+:::
+
+4. If the configuration is protected, your changes won't be published right away. You can do either of the following:
+
+ * **Save as draft** : Selecting this option will save your file as a draft. You and other users can view and edit the saved draft and propose it further for approval.
+ * **Save & Propose Changes** : Selecting this option will propose your changes to a configuration approver for a review.
+
+ Since we are proposing the changes immediately, click **Propose Changes**.
+
+ 
+
+5. You can also view the approver(s) if you wish.
+
+ 
+
+:::info
+The one who performs the edits cannot approve their own changes. A different user has to review and approve.
+:::
+
+Only one draft can exist at time and you cannot create multiple drafts. In the top-right corner, you have the option to discard the draft if you don't wish to proceed with the edits you made.
+
+---
+
+## Approving the Configuration
+
+:::info
+Only a different super-admin user or someone (who is not amongst the editors of the draft), having `Configuration approver` access, can approve the changes made to the configuration files.
+:::
+
+Go to the edited configuration file to review and approve the changes as shown below.
+
+
+
+A super-admin can check whether a user has approval rights by going to **Global Configurations** → **Authorization** (dropdown) → **User Permissions**.
+
+
+
+
+---
+
+## Deploying with New Configuration Values
+
+Once the approver validates and approves your configuration changes, you can proceed to deploy your application with the updated configuration.
+
+1. Go to the **Build & Deploy** tab of your application.
+
+2. Click **Select Image** in the deployment flow.
+
+ 
+
+3. You can view an indicator at the bottom `Config Diff from Last Deployed`. Click **Review** to view the changes.
+
+ 
+
+:::info
+If the new configuration is not yet approved, the changes made to the config would not be visible during deployment, it would show `No Config Diff from Last Deployed` at the bottom. In that case, check whether your changes are present in the live config or not. If your changes are absent, chances are your draft is either pending for approval or rejected (discarded).
+:::
+
+4. Once you have verified the changes, you can click **Deploy**.
+
+ 
+
+:::info
+If you don't wish to deploy with the new changes, you can choose `Last deployed config` from the available drop-down.
+:::
+
+---
+
+## Enabling/Disabling Config Protection
+
+:::info
+Only a super-admin can enable or disable the config protection.
+:::
+
+1. Go to the `App Configuration` tab.
+
+2. Click `Protect Configuration`.
+
+3. Use the toggle button to enable the protection for the configuration of your choice (base/environment level). A protection badge would appear next to the chosen configuration.
+
+Alternatively, unprotecting the configuration will lead to the discarding of unapproved drafts (if any).
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/container-registry-override.md b/versioned_docs/version-1.7/user-guide/creating-application/container-registry-override.md
new file mode 100755
index 0000000000..604e3133dc
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/container-registry-override.md
@@ -0,0 +1,32 @@
+---
+id: container-registry-override
+title: Override Build Configuration
+sidebar_label: Override Build Configuration
+---
+
+# Override Build Configuration
+
+Within the same application, you can override a `container registry`, `container image` and `target platform` during the build pipeline, which means the images built for non-production environment can be included to the non-production registry and the images for production environment can be included to the production registry.
+
+
+
+
+
+
+To override a container registry, container image or target platform:
+
+* Go to **Applications** and select your application from the **Devtron Apps** tabs.
+* On the **App Configuration** tab, select **Workflow Editor**.
+* Open the build pipeline of your application.
+* Click **Allow Override** to:
+ * Select the new container registry from the drop-down list.
+ * Or, [create and build the new container image](../creating-application/docker-build-configuration.md#build-the-container-image) with different options.
+ * Or, set a [new target platform](../creating-application/docker-build-configuration.md#set-target-platform-for-the-build) from the drop-down list or enter a new target platform.
+
+* Click **Update Pipeline**.
+
+The overridden container registry/container image location/target platform will be reflected on the [Build Configuration](docker-build-configuration.md) page. You can also see the number of build pipelines for which the container registry/container image location/target platform is overridden.
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/deployment-visibility.md b/versioned_docs/version-1.7/user-guide/creating-application/deployment-visibility.md
new file mode 100755
index 0000000000..bfc97904de
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/deployment-visibility.md
@@ -0,0 +1,120 @@
+---
+id: deployment-visibility
+title: Deployment Visibility & Actions
+sidebar_label: Deployment Visibility & Actions
+---
+
+# Deployment Visibility & Actions
+
+:::info Prerequisites
+The [Deployment Chart Type](../creating-application/base-config/deployment-template.md#select-a-deployment-chart-type) must be set to Rollout in order to use Blue-Green or Canary strategies.
+
+Deployment Visibility and Actions is only available for Canary and Blue-Green Strategies. Refer to the [Deployment Strategies](../creating-application/workflow/cd-pipeline.md#deployment-strategies) to learn more.
+
+:::
+
+:::caution Who Can Perform This Action?
+Users need to have Build and Deploy or above (along with access to the environment and application).
+:::
+
+Devtron helps you to manage your **Canary** and **Blue-Green** deployments by providing visibility and easy controls to manage how new versions (releases) are shared with users.
+
+Devtron allows you to:
+
+* Quickly view the current deployment status and detailed progress.
+
+* For canary deployments you can manually trigger the next step for the release or fully complete the rollout.
+
+* For Blue-Green deployments
+
+ * You can directly route the end user traffic to the application’s new deployment on a particular environment.
+
+ * You can swap the traffic from Blue to Green.
+
+* Easily rollback deployments (if needed).
+
+## Visibility & Actions
+
+### For Canary Deployments
+
+After triggering the deployment, navigate to **App Details**, to get a quick overview of your release rollout status.
+
+You can select the **Manage Traffic** button to view the rollout status and steps involved in the release.
+
+If you wish you can also trigger the next release steps (for example 25%, 50%, 75%) or you can also trigger the full rollout at once according to your use case.
+
+ 
+
+ 
+
+
+### For Blue Green deployments
+
+Devtron automatically swaps the traffic from the current running release to the new release based on the defined strategy configuration. In case `autoPromotionEnabled` field value is set to `false`, you can manually swap the traffic from the current release to the new release.
+
+
+
+To do so, follow the steps below:
+
+#### Swap Traffic
+
+1. Navigate to **App Details** of your application.
+
+2. During Blue-Green deployment, click the **Swap Traffic** button to shift the traffic to application's new release.
+
+ 
+
+3. Enter the name of the environment and select **Swap Traffic**
+
+ 
+
+4. This will route the end user traffic from the current running release to the new release on a particular environment.
+
+
+In any scenario, if you want to skip the Blue-Green Strategy and route the end user traffic from the current running release to the new release on a particular environment, you can do that via **Skip & Promote Full** button during the deployment.
+
+To do so, follow the below steps:
+
+#### Skip & Promote Full
+
+1. Navigate to **App Details** of your application.
+
+2. During Blue-Green deployment, click the **Skip & Promote Full** button to shift the traffic to application's new deployment.
+
+ 
+
+3. Enter the name of the environment and select **Promote to Full**.
+
+ 
+
+4. This will skip the Blue-Green Strategy and route the end user traffic from the current running release to the new release on a particular environment.
+
+### Rollback the Deployment
+
+In case you have identified some bugs or performance of the release is not as expected then you can also rollback to the previous release.
+
+You can perform a rollback from **Build & Deploy** Section and from App Details (for Blue-Green & Canary Strategies only)
+
+To perform a rollback from App Details follow the below steps:
+
+1. Navigate to **App details** of your Devtron Application.
+
+2. Based on the type of deployment strategy, perform one of the following actions:
+
+ * In case of Canary deployments, select **Rollback** under **Canary Strategy**.
+
+ 
+
+ * In case of Blue Green deployments, select **Rollback** under **Blue Green Strategy**.
+
+ 
+
+3. Select the image to which you want your release to be rolled back and click **Deploy** to rollback the release.
+
+ 
+
+4. If you wish, you can select a different deployment strategy other than the default according to the use case.
+
+ 
+
+5. The application will be rolled back to the previous release (image) using the selected deployment strategy.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/docker-build-configuration.md b/versioned_docs/version-1.7/user-guide/creating-application/docker-build-configuration.md
new file mode 100755
index 0000000000..d24d62b941
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/docker-build-configuration.md
@@ -0,0 +1,134 @@
+---
+id: docker-build-configuration
+title: Build Configuration
+sidebar_label: Build Configuration
+---
+
+ # Build Configuration
+
+In this section, we will provide information on the `Build Configuration`.
+
+ Build configuration is used to create and push docker images in the container registry of your application. You will provide all the docker related information to build and push docker images on the `Build Configuration` page.
+
+Only one docker image can be created for multi-git repository applications as explained in the [Git Repository](git-material.md) section.
+
+For **build configuration**, you must provide information in the sections as given below:
+
+* [Store Container Image](#store-container-image)
+* [Build the Container Image](#build-the-container-image)
+* [Advanced Options](#advanced-options)
+
+
+
+## Store Container Image
+
+The following fields are provided on the **Store Container Image** section:
+
+
+
+| Field | Description |
+| --- | --- |
+| **Container Registry** | Select the container registry from the drop-down list or you can click **Add Container Registry**. This registry will be used to [store docker images](../global-configurations/container-registries.md). |
+| **Container Repository** | Enter the name of your container repository, preferably in the format `username/repo-name`. The repository that you specify here will store a collection of related docker images. Whenever an image is added here, it will be stored with a new tag version. |
+
+**If you are using docker hub account, you need to enter the repository name along with your username. For example - If my username is *kartik579* and repo name is *devtron-trial*, then enter kartik579/devtron-trial instead of only devtron-trial.**
+
+
+
+
+## Build the Container Image
+
+In order to deploy the application, we must build the container images to configure a fully operational container environment.
+
+You can choose one of the following options to build your container image:
+* **I have a Dockerfile**
+* **Create Dockerfile**
+* **Build without Dockerfile**
+
+### Build Docker Image when you have a Dockerfile
+
+A `Dockerfile` is a text document that contains all the commands which you can call on the command line to build an image.
+
+
+
+| Field | Description |
+| --- | --- |
+| **Select repository containing Dockerfile** | Select the Git checkout path of your repository. This repository is the same which you defined on the [Git Repository](../creating-application/git-material.md) section. |
+| **Dockerfile Path (Relative)** | Enter a relative file path where your docker file is located in Git repository. Ensure that the dockerfile is available on this path. This is a mandatory field. |
+
+### Build Docker Image by creating Dockerfile
+
+With the option **Create Dockerfile**, you can create a `Dockerfile` from the available templates. You can edit any selected Dockerfile template as per your build configuration requirements.
+
+
+
+| Field | Description |
+| --- | --- |
+| **Language** | Select the programming language (e.g., `Java`, `Go`, `Python`, `Node` etc.) from the drop-down list you want to create a dockerfile as per compatibility to your system. **Note** We will be adding other programming languages in the future releases.|
+| **Framework** | Select the framework (e.g., `Maven`, `Gradle` etc.) of the selected programming language. **Note** We will be adding other frameworks in the future releases.|
+
+### Build Docker Image without Dockerfile
+
+With the option **Build without Dockerfile**, you can use Buildpacks to automatically build the image for your preferred language and framework.
+
+
+
+| Field | Description |
+| --- | --- |
+| **Select repository containing code** | Select your code repository. This repository is the same which you defined on the [Git Repository](../creating-application/git-material.md) section.|
+| **Project Path (Relative)** | In case of monorepo, specify the path of the project from your Git repository.|
+| **Language** | Select the programming language (e.g., `Java`, `Go`, `Python`, `Node`, `Ruby`, `PHP` etc.) from the drop-down list you want to build your container image as per the compatibility to your system. **Note**: We will be adding other programming languages in the future releases.|
+| **Version** | Select a language version from the drop-down list. If you do not find the version you need, then you can update the language version in `Build Env Arguments`. You can also select **Autodetect** in case if you want `Builder` to detect version by itself or its default version.|
+| **Select a builder** | A builder is an image that contains a set of buildpacks which provide your app's dependencies, a stack, and the OS layer for your app image. Select a buildpack provider from the following options:
**Heroku**: It compiles your deployed code and creates a slug, which is a compressed and pre-packaged copy of your app and also the runtime which is optimized for distribution to the dyno (Linux containers) manager. [Learn more](https://devcenter.heroku.com/articles/buildpacks).
**GCR**: GCR builder is a general purpose builder that creates container images designed to run on most platforms (e.g. Kubernetes / Anthos, Knative / Cloud Run, Container OS, etc.). It auto-detects the language of your source code, and can also build functions compatible with the Google Cloud Function Framework. [Learn more](https://github.com/GoogleCloudPlatform/buildpacks).
**Paketo**: Paketo buildpacks provide production-ready buildpacks for the most popular languages and frameworks to easily build your apps. Based on your application needs, you can select from `Full`, `Base` and `Tiny`. [Learn more](https://paketo.io/docs/).
|
+
+
+#### Build Env Arguments
+
+You can add Key/Value pair by clicking **Add argument**.
+
+| Field | Description |
+| --- | --- |
+| **Key** | Define the key parameter as per your selected language and builder. E.g., By default `GOOGLE_RUNTIME_VERSION` for GCR buildpack. **Note**: If you want to define `env arguments` for `PHP` and `Ruby` languages after selecting `Heroku` builder, please make sure to refer respective [Heroku Ruby Support](https://devcenter.heroku.com/articles/ruby-support) and [Heroku PHP Support](https://devcenter.heroku.com/articles/php-support) documentation for runtime information.|
+| **Value** | Define the value for the specified key. E.g. Version no. |
+
+
+**Note** This fields are optional. If required, it can be overridden at [CI step](../deploying-application/triggering-ci.md).
+
+
+## Advanced Options
+
+### Set Target Platform for the build
+
+Using this option, you can build images for a specific or multiple **architectures and operating systems (target platforms)**. You can select the target platform from the drop-down list or can type to select a customized target platform.
+
+
+
+
+
+Before selecting a customized target platform, please ensure that the architecture and the operating system are supported by the `registry type` you are using, otherwise build will fail. Devtron uses BuildX to build images for multiple target Platforms, which requires higher CI worker resources. To allocate more resources, you can increase value of the following parameters in the `devtron-cm` configmap in `devtroncd` namespace.
+
+- LIMIT_CI_CPU
+- REQ_CI_CPU
+- REQ_CI_MEM
+- LIMIT_CI_MEM
+
+To edit the `devtron-cm` configmap in `devtroncd` namespace:
+```
+kubectl edit configmap devtron-cm -n devtroncd
+```
+
+If target platform is not set, Devtron will build image for architecture and operating system of the k8s node on which CI is running.
+
+The Target Platform feature might not work in minikube & microk8s clusters as of now.
+
+ ### Docker Build Arguments
+ It is is a collapsed view including the following parameters:
+ * Key
+ * Value
+
+
+
+These fields will contain the key parameter and the value for the specified key for your [docker build](https://docs.docker.com/engine/reference/commandline/build/#options). This field is Optional. If required, this can be overridden at [CI step](../deploying-application/triggering-ci.md).
+
+Click **Save Configuration**.
+
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/environment-overrides.md b/versioned_docs/version-1.7/user-guide/creating-application/environment-overrides.md
new file mode 100755
index 0000000000..d3c400b75f
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/environment-overrides.md
@@ -0,0 +1,210 @@
+---
+id: environment-overrides
+title: Environment Overrides
+sidebar_label: Environment Overrides
+---
+
+# Environment Overrides
+
+You can view all environments associated with an application under the **Environment Overrides** section.
+
+
+
+The Environment Overrides section allows you to customize the **Deployment Template**, **ConfigMaps**, and **Secrets** for different environments such as development, testing, staging, and production.
+
+## How it works
+
+* When you add a deployment pipeline to an application's workflow, each environment configuration initially inherits the Deployment Template, ConfigMap and Secret from the **Base Configurations** of the application.
+
+* The **Environment Overrides** section lets you customize those Deployment Template, ConfigMap and Secret per environment without affecting those of other environments. For example, in a non-production environment, you might allocate `100m` CPU, while in production, you may increase it to `500m` to handle higher traffic.
+
+---
+
+## Environment Configurations Page
+
+:::caution Who Can Perform This Action?
+Users need to have [Admin role](../global-configurations/authorization/user-access.md#roles-available-for-devtron-apps) or above (along with access to the environment and applications) to perform environment override.
+:::
+
+1. In your Devtron app, go to **Configurations** (tab) → **Environment Overrides**.
+
+ 
+
+2. Select an environment whose configurations you wish to modify.
+
+ 
+
+3. You will get the following options (similar to the **Base Configurations** page):
+ * [Deployment Template](#override-deployment-template)
+ * [ConfigMaps](#override-configmap--secret)
+ * [Secrets](#override-configmap--secret)
+
+ 
+
+
+Let's visit each of the configuration files and see how to override their values for the selected environment (say *banking-final*).
+
+---
+
+## Override Deployment Template
+
+As you can see, the Deployment Template for the *banking-final* environment shows 3 tabs:
+* Inherited
+* No override or Override
+* Dry run
+
+1. Go to the **Inherited** tab. This will show the inherited configuration in a read-only YAML editor. You cannot edit any values here.
+
+ 
+
+2. Clicking **No override** to override the inherited configuration (if not done already).
+
+ 
+
+3. Click the **Create Override** button.
+
+ 
+
+4. In the same tab (now labelled as **Override**), you can choose any one mode for changing the configuration values:
+ * **YAML** - This mode has a YAML based editor intended for advanced users. [Click here](../creating-application/base-config/deployment-template-types/deployment.md#yaml) to know more about each key-value pair within the `YAML` section.
+ * **GUI** - This mode has a user-friendly interface intended for beginner to advanced users. [Click here](../creating-application/base-config/deployment-template.md#using-gui) to know more about each field within the `GUI` section.
+
+:::info Note
+Users who are not super-admins will land on GUI mode when they override; whereas super-admins will land on YAML mode. This is just the default behavior, users can still toggle the mode if needed.
+:::
+
+Let's choose YAML mode for now and proceed. If you prefer GUI mode, go to [Override Deployment Template using GUI](#override-deployment-template-using-gui) section.
+
+5. You can override the values using any merge strategy:
+ * [Patch](#using-patch-strategy)
+ * [Replace](#using-replace-strategy)
+
+### Using Patch Strategy
+
+Suppose you want to update only one field (e.g., `"username" = "johndoe"`) in a deployment template. Using the patch strategy, you can just update the field to `"username" = "mathew"`. All other fields in the deployment template will remain unchanged.
+
+* Only the fields you explicitly specify are updated.
+* The patched template will continue to depend on the base configuration, so all other inherited fields remain unchanged and will continue to inherit in future.
+* Best for minor edits.
+
+| Field | Inherited Configuration | Input (with Patch) | Final Configuration |
+|-----------|--------------------|----------------------------|----------------------|
+| cpu | 100m | 500m | 500m |
+| memory | 256Mi | *(Not specified)* | 256Mi *(Unchanged)* |
+| replicas | 2 | *(Not specified)* | 2 *(Unchanged)* |
+| logLevel | "info" | *(Not specified)* | "info" *(Unchanged)* |
+| timeout | (Not specified) | 30s | 30s (Added) |
+
+If you know the fields you wish to change, simply enter the changed key-value fields along with indentation (if any).
+
+
+
+
+
+### Using Replace Strategy
+
+Suppose you update your deployment chart version (e.g., from `4.0.0` to `4.0.1`). Although the new chart version contains new features and key-value pairs, if you prefer to keep a few configurations unchanged regardless of the new key-value pairs added in the new chart version, you can use the replace strategy.
+
+* The entire configuration is replaced with your new environment-specific settings.
+* The replaced template will no longer depend or inherit from base configuration anymore.
+* Best for a complete override.
+
+| Field | Inherited Configuration | Input (with Replace) | Final Configuration |
+|-----------|--------------------|------------------------------|---------------------|
+| cpu | 100m | 500m | 500m |
+| memory | 256Mi | 512Mi | 512Mi |
+| replicas | 2 | *(Not specified)* | *(Removed)* |
+| logLevel | "info" | *(Not specified)* | *(Removed)* |
+| timeout | (Not specified) | 30s | 30s (Added) |
+
+:::info What if some keys are locked from editing?
+You cannot modify locked keys in an environment's deployment template unless you are a super-admin. Refer [Lock Deployment Configuration](../global-configurations/lock-deployment-config.md) to know more.
+:::
+
+### Override Deployment Template using GUI
+
+Follow the below steps to override your deployment template using GUI:
+
+1. Navigate to **Applications** and click your Devtron application.
+
+2. Go to **Configurations** (tab) → **Base Configurations** → **Environment Overrides** and click on your preferred environment to override deployment template.
+
+3. Click on the **No Override** option and then click on **Create Override**.
+
+4. Click on the **GUI** option. The available fields will be displayed on the right side of the page.
+
+5. Select your preferred fields and enter the values to override.
+
+6. Select your preferred merge strategy from the **Merge Strategy** drop-down box.
+
+7. Click on **Save Changes**.
+
+:::info Want to customize the deployment template values displayed on GUI?
+The GUI mode shows limited number of fields as specified by the super-admin in the GUI schema. Refer [Customize GUI](../creating-application/base-config/deployment-template.md#customize-the-gui-) to know more.
+
+:::
+
+---
+
+## Override ConfigMap & Secret
+
+If you want to configure your ConfigMap and Secret at the application-level then you can provide them in [ConfigMaps](../creating-application/base-config/config-maps.md) and [Secrets](../creating-application/base-config/secrets.md), but if you want to have environment-specific ConfigMap and Secret, use **Environment Override** to create them. At the time of deployment, it will pick both of them and pass them to your cluster.
+
+The process to override both ConfigMaps and Secrets is similar to [Override Deployment Template](#override-deployment-template). Refer the tutorials below to know the process in YAML mode. In case you wish to use GUI mode, skip to [Overriding in GUI mode](#override-configmaps-and-secrets-using-gui).
+
+### Patch Strategy
+
+:::info Impact of Patch strategy on Base Configuration's CM/Secret?
+You cannot delete a ConfigMap or Secret in **Base Configurations** if you have used 'Patch' strategy for overridding ConfigMap or Secret at your environment-level. This happens because they are still dependent and inheriting their values from Base Configurations.
+
+:::
+
+### Replace Strategy
+
+
+
+### Override ConfigMaps and Secrets using GUI
+
+
+
+---
+
+## Delete Override
+
+This action will discard the current overrides and the base configuration file (in this example, deployment template) will be restored back for the environment.
+
+1. On the right side, click the kebab menu (3 vertical dots).
+2. Click **Delete Override**.
+3. Confirm the deletion in the dialogbox.
+
+
+
+---
+
+## Protected Environment Configurations
+
+Any changes made to the protected environment configurations (Deployment Template, ConfigMap, Secret) will require approval if an [approval policy](../global-configurations/approval-policy.md) is enforced.
+
+Follow the below steps to make changes to a protected environment:
+
+1. Navigate to **Applications** and click on your preferred application.
+
+2. Go to **Configurations** (tab) → **Base Configurations** → **Environment Overrides** and click on your preferred environment.
+
+3. Click on the **No Override** option and then click on **Create Override**.
+
+4. Select your preferred merge strategy from the **Merge Strategy** drop-down box.
+
+5. Make changes to the key-value pairs in the **Patch data** section.
+
+6. Click **Save Changes**. The **Save as draft** pop-up page will be displayed.
+
+ * **Save as draft** - Select this option if you want to continue making your changes later but save your changes as a draft for now.
+
+ * **Save & Propose changes** - Select this option if you want to save and propose your changes to the approvers. You can then select the approvers to get notified regarding the change from the **Select approvers to notify** drop-down box.
+
+7. Enter your comments (reason for making the changes) in the **Comment** text box.
+
+8. Click **Propose Changes**. The corresponding approver will be notified via email regarding your request.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/external-links.md b/versioned_docs/version-1.7/user-guide/creating-application/external-links.md
new file mode 100755
index 0000000000..4153250fe7
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/external-links.md
@@ -0,0 +1,13 @@
+---
+id: external-links
+title: External Links
+sidebar_label: External Links
+---
+
+# External Links
+
+This is similar to [External Links](../global-configurations/external-links.md) present under **Global Configurations**.
+
+The only difference is that in **External Links**, only the links editable by application admins and manager are displayed. You can also configure external links separately for your application.
+
+Whereas, in **Application** → **Configurations (tab)** → **External Links**, you can configure the external links for all applications in a cluster or for specific applications.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/fluxcd.md b/versioned_docs/version-1.7/user-guide/creating-application/fluxcd.md
new file mode 100755
index 0000000000..7470962458
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/fluxcd.md
@@ -0,0 +1,170 @@
+---
+id: fluxcd
+title: Enable GitOps Deployments with FluxCD
+sidebar_label: Enable GitOps Deployments with FluxCD
+---
+
+# Enable GitOps Deployments with FluxCD
+
+:::info Prerequisite
+Make sure to install:
+
+1. [Build and Deploy (CI/CD) integration](../integrations/build-and-deploy-ci-cd.md)
+
+2. [GitOps (ArgoCD) integration](../integrations/argocd.md)
+
+:::
+
+Devtron supports FluxCD to enable GitOps-based deployments. With FluxCD, you can:
+
+* Deploy applications via GitOps (via FluxCD).
+
+* Deploy Helm charts via FluxCD.
+
+* Migrate existing FluxCD applications into Devtron.
+
+Your Git repository becomes the single source of truth for your Kubernetes workloads. Any changes you make in Git are automatically applied to your Kubernetes cluster by FluxCD. Refer to the [FluxCD documentation](https://fluxcd.io/flux/) to learn more.
+
+
+## Installation
+
+:::caution Who Can Perform This Action?
+The user must have permissions to:
+ * Edit the ConfigMaps of 'default-cluster'
+ * Restart the pods
+:::
+
+To enable deployments through GitOps via FluxCD, you need to enable a specific feature flag for the `default_cluster` in Devtron.
+
+ |Feature|Flag|Description|
+ |:---|:---|:---|
+ |**Deployments via FluxCD**|`FEATURE_FLUX_DEPLOYMENTS_ENABLE: "true"`|This flag will enable deployments through GitOps via FluxCD.
After enabling this flag, you also need to install FluxCD controller in order to deploy applications successfully. Refer [Installing FluxCD Controller](#installing-fluxcd-controller-only-for-deployments) to know more.
|
+ |**Migrating existing FluxCD applications**|`FEATURE_LINK_EXTERNAL_FLUX_ENABLE: "true"`|This flag will enable migrations for external FluxCD apps into Devtron.|
+
+ :::caution Deployment Strategies for FluxCD Deployments
+ Application deployments through GitOps (via FluxCD) are supported only when using the `Deployment` or `Rollout` deployment strategies with the latest chart versions. Other deployment strategies are currently not supported.
+ :::
+
+### Enabling Feature Flags
+
+1. Navigate to Devtron's **Resource Browser**.
+
+ 
+
+2. Select the `default_cluster` to enable the feature flags.
+
+ 
+
+3. Go to Config & Storage → ConfigMap, and click `dashboard-cm` ConfigMap
+
+ 
+
+4. Edit the `dashboard-cm` ConfigMap by clicking **Edit live manifest**.
+
+ 
+ 1. To enable deployments via FluxCD, check if the below entries are present in the ConfigMap (create one if it doesn't exist) and select **Apply changes**.
+
+ ```yaml
+ FEATURE_FLUX_DEPLOYMENTS_ENABLE: "true"
+ ```
+
+ 2. To enable migration for external FluxCD applications, check if the below entries are present in the ConfigMap (create one if it doesn't exist) and select **Apply changes**.
+
+ ```yaml
+ FEATURE_LINK_EXTERNAL_FLUX_ENABLE: "true"
+ ```
+
+
+
+ 
+
+5. Restart the deployment:
+ 1. **For OSS Users:**
+ 1. Navigate to Devtron's [Resource Browser](../resource-browser/).
+
+ 2. Select the cluster for which you have enabled the feature flags.
+
+ 3. Click the **Terminal** tab.
+
+ 4. Restart the deployment using the following command:
+
+ ```yaml
+ kubectl rollout restart deployment dashboard -n devtroncd
+ ```
+
+ 
+ 2. **For Enterprise Users:**
+ 1. Go to **Resource Browser** → (select the cluster in which you have enabled the feature flags) → **Workloads** → **Deployment**
+
+ 2. Click the checkbox next to the `dashboard` Deployment workloads and restart them using the `⟳` button.
+
+ 
+
+6. Perform a hard refresh of the browser to clear the cache:
+
+ * **Mac**: Hold down Cmd and Shift and then press R.
+
+ * **Windows/Linux**: Hold down Ctrl and then press F5.
+
+### Installing FluxCD Controller (Only for Deployments)
+
+After enabling the feature flag for deployments, the next step is to install FluxCD Controller in every cluster (including the default cluster) in which you want to deploy the FluxCD applications.
+
+You can install FluxCD Controller by any of the following ways:
+
+ 1. [Install FluxCD controller via Cluster Terminal](#install-fluxcd-controller-via-cluster-terminal) (Recommended)
+
+ 2. [Install FluxCD controller via Chart Store](#install-fluxcd-controller-via-chart-store)
+
+
+#### Install FluxCD controller via Cluster Terminal.
+
+1. Navigate to Devtron's Resource Browser.
+
+2. Select the cluster for which you have enabled the feature flags.
+
+3. Click the **Terminal** tab.
+
+4. Run the following command to install the FluxCD Controller:
+
+ ```yaml
+ kubectl apply -f https://github.com/fluxcd/flux2/releases/download/v0.35.0/install.yaml
+ ```
+
+ 
+
+5. After the command is executed successfully, you can deploy or migrate your applications in that cluster through GitOps (via FluxCD).
+
+#### Install FluxCD controller via Chart Store.
+
+To install FluxCD controller via Chart Store, follow the below steps.
+
+ 1. Add FluxCD controller repository, `https://fluxcd-community.github.io/helm-charts` in the chart repositories (if not already added) in Global Configurations. Refer [Chart Repositories](../global-configurations/chart-repo.md#add-chart-repository) to learn more.
+
+ 
+
+ 2. Add a new environment in the cluster in which you want to deploy the application via FluxCD linked to namespace as `flux-system`. Refer [Clusters and Environments](../global-configurations/cluster-and-environments.md#add-environment-to-a-cluster) to lean more.
+
+ 
+
+ 3. Navigate to **Chart Store** and select the `flux2` chart.
+
+ 
+
+ 4. Click **Configure and Deploy**.
+
+ 
+
+ 5. Configure the following configurations:
+
+ |Field Name|Description|
+ |:---|:---|
+ |**App Name**|Define a name for the chart.|
+ |**Project**|Select a project from the dropdown|
+ |**Deploy to Environment**|Select the environment which you have created in your preferred cluster linked to `flux-system` namespace.|
+
+ 
+
+ 6. Click **Deploy** and the chart will be deployed.
+
+After the chart is successfully deployed, you can deploy applications though GitOps (via FluxCD).
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/git-material.md b/versioned_docs/version-1.7/user-guide/creating-application/git-material.md
new file mode 100755
index 0000000000..0601f73037
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/git-material.md
@@ -0,0 +1,150 @@
+---
+id: git-material
+title: Git Repository
+sidebar_label: Git Repository
+---
+
+# Git Repository
+
+## Introduction
+
+During the [CI process](../deploying-application/triggering-ci.md), the application source code is pulled from your [git repository](../../reference/glossary.md#repo).
+
+Devtron also supports multiple Git repositories (be it from one Git account or multiple Git accounts) in a single deployment.
+
+
+
+Therefore, this doc is divided into 2 sections, read the one that caters to your application:
+* [Single Repo Application](#single-repo-application)
+* [Multi Repo Application](#multi-repo-application)
+
+---
+
+## Single Repo Application
+
+Follow the below steps if the source code of your application is hosted on a single Git repository.
+
+In your Devtron app, go to **Configurations** (tab) → **Git Repository**. You will get the following fields and options:
+
+1. [Git Account](#git-account)
+2. [Git Repo URL](#git-repo-url)
+3. (Checkboxes)
+ * [Exclude specific file/folder in this repo](#exclude-specific-filefolder-in-this-repo)
+ * [Set clone directory](#set-clone-directory)
+ * [Pull submodules recursively](#pull-submodules-recursively)
+
+### Git Account
+
+This is a dropdown that shows the list of Git accounts added to your organization on Devtron. If you haven't done already, we recommend you to first [add your Git account](../global-configurations/git-accounts.md) (especially when the repository is private).
+
+
+
+:::info
+If the authentication type of your Git account is anonymous, only public Git repositories in that account will be accessible. Whereas, adding a user auth or SSH key will make both public and private repositories accessible.
+:::
+
+
+### Git Repo URL
+
+In this field, you have to provide your code repository’s URL, for e.g., `https://github.com/devtron-labs/django-repo`.
+
+You can find this URL by clicking on the **Code** button available on your repository page as shown below:
+
+
+
+:::info
+* Copy the HTTPS/SSH portion of the URL too
+* Make sure you've added your [Dockerfile](https://docs.docker.com/engine/reference/builder/) in the repo
+:::
+
+
+### Exclude specific file/folder in this repo
+
+Not all repository changes are worth triggering a new [CI build](../deploying-application/triggering-ci.md). If you enable this checkbox, you can define the file(s) or folder(s) whose commits you wish to use in the CI build.
+
+
+
+In other words, if a given commit contains changes only in file(s) present in your exclusion rule, the commit won't show up while selecting the [Git material](../../reference/glossary.md#material), which means it will not be eligible for build. However, if a given commit contains changes in other files too (along with the excluded file), the commit won't be excluded and it will definitely show up in the list of commits.
+
+
+
+Devtron allows you to create either an exclusion rule, an inclusion rule, or a combination of both. In case of multiple files or folders, you can list them in new lines.
+
+To exclude a path, use **!** as the prefix, e.g. `!path/to/file`
+To include a path, don't use any prefix, e.g. `path/to/file`
+
+
+#### Examples
+
+
+| Sample Values | Description |
+|---|---|
+| `!README.md` | **Exclusion of a single file in root folder:** Commits containing changes made only in README.md file will not be shown |
+| `!README.md` `!index.js` | **Exclusion of multiple files in root folder:** Commits containing changes made only in README.md or/and index.js files will not be shown |
+| `README.md` | **Inclusion of a single file in root folder:** Commits containing changes made only in README.md file will be shown. Rest all will be excluded. |
+| `!src/extensions/printer/code2.py` | **Exclusion of a single file in a folder tree:** Commits containing changes made specifically to code2.py file will not be shown |
+| `!src/*` | **Exclusion of a single folder and all its files:** Commits containing changes made specifically to files within src folder will not be shown |
+| `!README.md` `index.js` | **Exclusion and inclusion of files:** Commits containing changes made only in README.md will not be shown, but commits made in index.js file will be shown. All other commits apart from the aforementioned files will be excluded. |
+| `!README.md` `README.md` | **Exclusion and inclusion of conflicting files:** If conflicting paths are defined in the rule, the one defined later will be considered. In this case, commits containing changes made only in README.md will be shown. |
+
+
+You may use the **Learn how** link (as shown below) to understand the syntax of defining an exclusion or inclusion rule.
+
+
+
+Since file paths can be long, Devtron supports regex too for writing the paths. To understand it better, you may click the **How to use** link as shown below.
+
+
+
+#### How to view excluded commits?
+
+As we saw earlier in fig. 4 and 5, commits containing the changes of only `README.md` file were not displayed, since the file was in the exclusion list.
+
+However, Devtron gives you the option to view the excluded commits too. There's a döner menu at the top-right (beside the `Search by commit hash` search bar).
+
+
+
+
+
+
+
+The **EXCLUDED** label (in red) indicates that the commits contain changes made only to the excluded file, and hence they are unavailable for build.
+
+
+### Set clone directory
+
+After clicking the checkbox, a field titled `clone directory path` appears. It is the directory where your code will be cloned for the repository you specified in the previous step.
+
+This field is optional for a single Git repository application and you can leave the path as default. Devtron assigns a directory by itself when the field is left blank. The default value of this field is `./`
+
+
+
+
+### Pull submodules recursively
+
+This checkbox is optional and is used for pulling [git submodules](https://git-scm.com/book/en/v2/Git-Tools-Submodules) present in a repo. The submodules will be pulled recursively, and the auth method used for the parent repo will be used for submodules too.
+
+---
+
+## Multi Repo Application
+
+As discussed earlier, Devtron also supports multiple git repositories in a single application. To add multiple repositories, click **Add Git Repository** and repeat all the steps as mentioned in [Single Repo Application](#single-repo-application). However, ensure that the clone directory paths are unique for each repo.
+
+Repeat the process for every new git repository you add. The clone directory path is used by Devtron to assign a directory to each of your Git repositories. Devtron will clone your code at those locations and those paths can be referenced in the Docker file to create a Docker image of the application.
+
+Whenever a change is pushed to any of the configured repositories, CI will be triggered and a new Docker image file will be built (based on the latest commits of the configured repositories). Next, the image will be pushed to the container registry you configured in Devtron.
+
+:::info
+Even if you add multiple repositories, only one image will be created based on the Dockerfile as shown in the [docker build config](docker-build-configuration.md)
+:::
+
+### Why do you need Multi-Git support?
+
+Let’s look at this with an example:
+
+Due to security reasons, you want to keep sensitive configurations like third-party API keys in separate access-restricted git repositories, and the source code in a Git repository that every developer has access to. To deploy this application, code from both the repositories are required. A Multi-Git support helps you achieve it.
+
+Other examples where you might need Multi-Git support:
+
+* To make code modularized, where front-end and back-end code are in different repos
+* Common library extracted out in a different repo so that other projects can use it
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/gitops-config.md b/versioned_docs/version-1.7/user-guide/creating-application/gitops-config.md
new file mode 100755
index 0000000000..095eee324a
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/gitops-config.md
@@ -0,0 +1,92 @@
+---
+id: gitops-config
+title: GitOps Configuration
+sidebar_label: GitOps Configuration
+---
+
+# GitOps Configuration
+
+:::caution
+The 'GitOps Configuration' page appears only if the super-admin has enabled 'Allow changing git repository for application' in [Global Configurations → GitOps](../global-configurations/gitops.md).
+:::
+
+## Introduction
+
+This configuration is an extension of the [GitOps](../global-configurations/gitops.md) settings present in [Global Configurations](../global-configurations/README.md) of Devtron. Therefore, make sure you read it before making any changes to your app configuration.
+
+The application-level GitOps configuration offers the flexibility to add a custom Git repo (as opposed to Devtron auto-creating a repo for your application).
+
+---
+
+## Adding Custom Git Repo for GitOps
+
+:::caution Who Can Perform This Action?
+Users need to have [Admin permission](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and application) to configure user-defined Git repo.
+:::
+
+### For Devtron Apps
+
+1. Go to **Applications** → **Devtron Apps** (tab) → (choose your app) → **Configurations** (tab) → **GitOps Configuration**.
+
+ 
+
+2. Assuming a GitOps repo was not added to your application earlier, you get 2 options:
+
+ * **Auto-create repository** - Select this option if you wish to proceed with the default behavior. It will create a repository automatically, named after your application with a prefix. Thus saving you the trouble of creating one manually.
+
+ * **Commit manifests to a desired repository** - Select this option if you wish to add a custom repo that is already created with your [Git provider](../global-configurations/gitops.md#supported-git-providers). Enter its link in the `Git Repo URL` field.
+
+ 
+
+
+:::caution
+GitOps repositories, whether auto-created by Devtron or added manually, are immutable. This means they cannot be modified after creation. The same is true if you have an existing CD pipeline that uses/used GitOps for deployment.
+:::
+
+3. Click **Save**.
+
+ 
+
+**Note**: In case you skipped the GitOps configuration for your application and proceeded towards the [creation of a new CD pipeline](../creating-application/workflow/cd-pipeline.md) (that uses GitOps), you will be prompted to configure GitOps as shown below:
+
+
+
+
+### For Helm Apps
+
+You can [deploy a helm chart](../deploy-chart/deployment-of-charts.md#configure-and-deploy-charts) using either Helm or GitOps. Let's assume you wish to deploy `airflow` chart.
+
+1. Select the helm chart from the [Chart Store](../deploy-chart/README.md).
+
+ 
+
+2. Click **Configure & Deploy**.
+
+ 
+
+3. After you enter the `App Name`, `Project`, and `Environment`; an option to choose the deployment approach (i.e., Helm or GitOps) would appear. Select **GitOps**.
+
+:::info
+The option to choose between 'Helm' or 'GitOps' is only available in
+
+:::
+
+
+
+
+
+4. A modal window will appear for you to enter a Git repository. Just like [Devtron Apps](#for-devtron-apps) (step 2), you get two options:
+ * Auto-create repository
+ * Commit manifests to a desired repository
+
+ 
+
+5. Enter your custom Git Repo URL, and click **Save**.
+
+ 
+
+Next, you may proceed to deploy the chart.
+
+:::caution
+Once you deploy a helm app with GitOps, you cannot change its GitOps repo.
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/overview.md b/versioned_docs/version-1.7/user-guide/creating-application/overview.md
new file mode 100755
index 0000000000..f979a754f0
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/overview.md
@@ -0,0 +1,273 @@
+---
+id: overview
+title: Overview
+sidebar_label: Overview
+---
+
+# Overview
+
+The Overview page provides a centralized view of an application’s details within Devtron. It allows users to quickly access information about the application, manage tags, view deployment environments, and understand inter-app dependencies, all in a single, organized interface.
+
+The **Overview** page contains three main sections:
+* [**About**](#about): Contains application metadata such as name, description, project, creator, tags, and connected code source. It also includes options to manage tags and [Configure PVCs](#configure-persistentvolumeclaim-pvc).
+* [**Environments**](#environments): Displays all environments where the application is deployed, along with their current status and quick access to associated workflows.
+* [**Dependencies**](#dependencies-): Shows which Devtron applications this application depends on, and which other Devtron applications depend on it, thus helping visualize microservices dependency.
+
+
+
+## About
+
+The **About** section allows you to:
+
+* View key application details
+* Change the project your application is assigned to
+* Manage tags that you may have added during the application’s creation
+* [Configure Persistent Volume Claims (PVCs)](#configure-persistentvolumeclaim-pvc)
+
+The left side of the **About** section displays essential information about the application.
+
+
+
+ The table below captures all the key elements presented in this section, along with their descriptions and whether they can be edited by the user.
+
+| Field Name | User Editable |Description|
+| :--------- | :--------------- |:--------- |
+| **Application Name** | No |Displays the name of the application (e.g., backend-healthcare-app).|
+| **Short Description**|Yes|A short, optional description to summarize the application's purpose.|
+| **Project** |Yes|Indicates the current project under which the application is organized. You can change the project directly from this section.
Click the **Edit** icon next to the current project.
In the **Change Project** window, select the new project from the dropdown.
Click **Save**.
Changing the project will revoke access for existing users and grant access only to those who have permissions in the newly selected project.|
+| **Created on** |No|Shows the exact date and time when the application was created.|
+| **Created by**|No|Displays the email address of the user who created the application.|
+| **Code Source** |No|Shows the connected Git repository or template used for the application.|
+| **Part of release track** |No|Lists all release track names linked to the app.
Clicking a release opens its detailed view in the Software Release Management.
This is an enterprise-only feature available as part of Devtron's SDH offering.
|
+| **Tags** |Yes| Refer [Manage Tags](#manage-tags) |
+
+
+### Manage Tags
+
+Tags are key-value pairs used to identify and organize applications effectively. These tags can be propagated as Kubernetes labels, enabling filtering, bulk operations, and integrations with Kubernetes tools.
+
+1. Click the **Edit** icon next to **Tags**.
+2. On the **Manage Tags** page, click **+ Add tag** to create a new tag.
+3. To delete a tag, click the **X** icon next to it.
+4. To propagate a tag as a Kubernetes label, click the **Propagation** icon .
+ - The icon turns dark grey when propagation is enabled.
+ - Click again if you wish to disable propagation.
+
+ 
+
+5. Click **Save**. The configured tags will appear under the **Tags** in the **About** section immediately.
+
+> **Note:** Tags can also be used to [configure PersistentVolumeClaims (PVCs)](#configure-persistentvolumeclaim-pvc) to optimize build time.
+
+
+### Readme
+The right side of the **About** section contains a **Readme** area where you can maintain application-specific notes or documentation. The **Readme** supports Markdown formatting, making it easy to include formatted text, instructions, or important context related to the application.
+
+
+
+To add or update the **Readme**:
+1. Click the **Edit** button in the Readme section.
+2. A Markdown editor will appear where you can write or modify content under the **Write** tab.
+3. Use standard Markdown syntax to format text, create lists, insert links, and more.
+4. Preview the content using the **Preview** tab.
+5. Click **Save** to update the Readme.
+
+
+
+:::info
+After saving, the system displays the email address of the user who last updated the README, along with the date and time. This information appears in the header of the Readme section, beside the title.
+:::
+
+### Deployment Window
+
+The **Deployment Window** in the **About** section displays all Blackout Windows and Maintenance Windows configured for your application’s environments.
+
+These windows are defined by Super-Admins to control when deployments and related actions are allowed or blocked. The goal is to minimize disruptions during critical business hours.
+
+* **Blackout Window**: Periods during which deployments are strictly blocked.
+* **Maintenance Window**: Periods during which deployments are allowed; outside of this window, they are blocked.
+* If both are configured for the same time period, **Blackout Window** takes precedence.
+
+You can expand each environment row to view detailed information like window name, duration, and frequency.
+
+
+
+:::info
+This section is view-only and does not require any configuration at the application level.
+:::
+
+> To learn how to configure deployment windows, refer to the [Deployment Window documentation](../global-configurations/deployment-window.md).
+
+### Catalog
+
+The **Catalog** in the **About** section displays information about your application, such as documentation references, ownership details, and technical specifications. This data is managed using [Devtron’s Catalog Framework](../global-configurations/catalog-framework.md).
+
+
+
+You can use the **Catalog framework** to maintain information about your application, such as Documentation (e.g., API contract, service documentation), ownership details, technical attributes, etc. This makes it easier for others to understand, manage, and use your application.
+
+Super-Admins define a custom JSON schema that determines what fields are shown in the catalog form. This schema is specific to each resource type, such as Devtron applications.
+
+When you click the **Edit** icon, a form appears based on the defined schema. As an application owner or client, you can fill out fields like:
+
+* Documentation (e.g., API contract, service documentation)
+* Code owners and on-call responsibilities
+* Service attributes (e.g., internet-facing flag, communication method, framework, language)
+
+
+
+:::info
+The structure and labels in the catalog form are entirely configurable by your platform team via JSON schema in **Catalog Framework**. Field names and sections may vary depending on how the schema was defined by your organization.
+:::
+
+Once saved, this information is displayed in a readable format within the Catalog subsection and is accessible to all users who have permission to view the application.
+
+
+
+### Configure PersistentVolumeClaim (PVC)
+
+A [PersistentVolumeClaim (PVC)](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) is a request for storage, which is used to mount a PersistentVolume (PV) into a Pod that can be used by your application’s CI pipeline.
+
+In Devtron, you can use a [PersistentVolumeClaim (PVC)](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) to provide persistent storage to the Pod that runs your CI pipeline, enabling the pod to store and reuse cached data such as dependencies.
+
+Mounting a PVC into the build Pod gives it access to a dedicated storage volume for caching, without interfering with the normal build process, which continues to run based on the architecture and operating system of the Kubernetes node where the CI pipeline is executed.
+
+#### Configure PVC in Your Application
+
+##### Create a PVC
+
+Before you can configure an Application to use a PVC, you need to make sure the PVC is created in the Kubernetes cluster.
+
+The following is a sample PVC YAML configuration. You can modify it as needed based on your storage class, access mode, and resource requirements:
+
+```bash title="pvc.yaml" showLineNumbers
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+ name: cache-pvc
+ namespace: devtron-ci
+spec:
+ accessModes:
+ - ReadWriteOnce
+ storageClassName: standard-rwo
+ resources:
+ requests:
+ storage: 30Gi
+```
+
+
+You can apply this configuration using Devtron’s **Resource Browser**
+
+**Apply using Devtron’s Resource Browser**
+
+1. Navigate to [Resource Browser](../resource-browser/README.md)..
+2. Select the Cluster where your CI pipelines run.
+3. Click **Create Resource**.
+4. Paste the YAML into the editor and click **Create**.
+5. The PVC will now be created and will appear under **Resource Browser** → **Config & Storage** → **PersistentVolumeClaim** with the status shown as `Bound`
+
+##### Apply PVC to CI Pipelines Using Tags
+
+Once PVC is created and in the Bound state, the next step is to configure it within your application using tags from the **About** section.
+
+Devtron allows you to define special tags as key-value pairs. These tags act as instructions for Devtron to mount the specified PVC to the Pod where the CI pipeline runs, making the storage available during pipeline execution.
+
+You can choose to mount the PVC for all pipelines in the application or for a specific pipeline, depending on your use case. The configuration remains the same in both cases, the only difference lies in the tag key used to define the scope of the PVC.
+
+Follow the steps below to apply the PVC to all or specific pipelines
+1. Navigate to your application’s **Overview** → **About** section.
+2. Click the **Edit** icon next to the Tags section.
+
+
+
+3. Add one of the following key-value tags depending on how you want the PVC to be applied
+ * To mount the PVC across all pipelines in the application
+
+| Key | Value|
+|:--- |:--- |
+|devtron.ai/ci-pvc-all | cache-pvc |
+
+
+
+ * To mount the PVC for a specific pipeline only in the application
+
+| Key | Value|
+|:--- |:--- |
+|devtron.ai/ci-pvc-``| cache-pvc |
+
+
+
+
+
+> Replace `` with the exact name of the CI pipeline (visible in the Workflow Editor).
+
+4. Click **Save** to apply the tag.
+
+After saving, Devtron will automatically mount the PVC into your CI pipeline Pod, allowing it to use the configured persistent storage for caching purposes. No further manual configuration is required.
+
+## Environments
+
+The Environments section provides a detailed view of all environments where the application is configured. For each environment, it displays
+
+| Field Name |Description|
+| :--------- |:--------- |
+| **Application Status** |The current application status in that particular environment.|
+| **Environment** | Displays the name of the Environment.|
+| **Last Deployed**|Shows the image tag or artifact version from the latest deployment. If the application has not been deployed yet, this shows Not Deployed.|
+| **Commit**|Displays the Git commit hash associated with the last deployment.|
+| **Deployed At**|Indicates who deployed the application and when, it is shown as the email ID of the user along with a relative timestamp (e.g.,9 days ago).|
+
+
+
+## Dependencies
+
+The Dependencies section displays the relationship of the current application with other Devtron-managed applications in the form of upstream and downstream dependencies.
+
+* Upstream dependencies are other applications that the current application depends on.
+* Downstream dependencies are applications that rely on the current application.
+
+### Upstream Dependencies
+
+Upstream dependencies are other Devtron applications that your current application depends on. You can manually define upstream dependencies to indicate that your application depends on certain Devtron applications.
+
+To add upstream dependencies:
+1. Click the **Add Dependency** button in the **Dependencies** section. If dependencies already exist, click the **Edit Dependency** button on the right instead.
+
+
+
+2. In the right-side panel, under Upstream Dependency, click **+ Add Dependency**.
+
+
+
+3. Use the search bar to find and select one or more applications that your app depends on.
+
+
+
+4. Click **Map Environments** to associate each selected application with a specific environment.
+ * This helps Devtron understand where your dependencies are running. By mapping environments, you can view the correct deployment details (like image, commit, and status) for each dependency.
+
+
+
+5. Once you’ve mapped the environments, click **Save** to confirm and apply the upstream dependencies.
+
+
+
+6. After saving:
+ * The selected applications will appear under **Dependent Applications** above your current application as Upstream Dependencies.
+ * Your current application will be shown in bold, displaying its mapped environment and latest deployment details.
+ * You can switch the environment of your current application using the dropdown next to its name under **Environment**. This allows you to view the upstream and downstream dependencies specific to that environment. The table will refresh to show deployment details for the selected environment.
+ * Any applications that have added your app as an upstream will automatically be listed below your app as Downstream Dependencies.
+
+
+
+### Downstream Dependencies
+
+Downstream dependencies are Devtron applications that rely on current application. These are automatically listed when your app is added as an upstream in another application’s configuration.
+
+You don’t need to configure anything manually for downstream entries, they are system-generated based on how other apps define their upstreams.
+
+For every downstream application listed, a **Map Environment** link appears beside its name.
+
+* Clicking this link redirects you to that application’s Dependencies section, where your app will appear in the upstream list.
+
+* From there, you can assign or update the environment mapping for your app in the context of that downstream application.
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/workflow/README.md b/versioned_docs/version-1.7/user-guide/creating-application/workflow/README.md
new file mode 100755
index 0000000000..506ef0c594
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/workflow/README.md
@@ -0,0 +1,79 @@
+---
+id: README
+title: Workflow Editor
+sidebar_label: Workflow Editor
+---
+
+# Workflow Editor
+
+## Introduction
+
+After configuring the **Build Configurations** and **Base Configurations**, the next step is to create a workflow using the Workflow Editor.
+
+In Devtron, a **Workflow** is a logical sequence of different stages(pipelines) used for continuous integration and continuous deployment of an application.
+
+ 
+
+---
+
+## Create Workflow
+
+The **Build and Deploy from Source Code** provides a simple way to create both CI and CD pipelines in one step. It is for users who want to set up a complete workflow quickly using minimal required information, such as the source repository branch and the target environment.
+
+To create a quick workflow with both build and deployment pipelines, follow the steps below:
+
+1. Click **New Workflow** in the workflow editor.
+
+ 
+
+2. Select **Build and Deploy from Source Code**; a window appears.
+
+ 
+
+3. Enter the required information in the following fields.
+
+ | Field Name|Required/Optional| Description|
+ | :--- | :--- | :--- |
+ | `Source type`| Required| Source type to trigger the CI. Available options: Branch Fixed, Branch Regex, Pull Request, Tag Creation|
+ | `Branch Name`| Required| Branch that triggers the CI build|
+ | `Environment` | Required |Select the environment where you want to deploy your application |
+ | `Namespace`| Required (Auto Filled)| Automatically populated based on the selected environment |
+
+ 
+
+ **Source Types**
+
+ |Source Type| Description| Additional Requirements|
+ |:---|:---|:---|
+ | `Branch Fixed`| Triggers a CI build whenever changes are pushed to a specified branch.| Requires a predefined branch name.|
+ | `Branch Regex`| Allows dynamic branch selection based on a regex pattern| Requires a regex pattern to be defined. For example, if the user sets the Branch Regex as feature-\*, then users can trigger the build from branches such as feature-1450, feature-hot-fix, etc.. |
+ | `Pull Request` (PR) | Triggers a CI build when a new pull request is created. You can also define filters (such as PR author, title, or branch) to control which pull requests trigger the pipeline. | Requires configuring a webhook configuration for GitHub or Bitbucket.|
+ | `Tag Creation`| Triggers a build whenever a new tag is created. You can also define filters (such as author and tag name) to control which tags trigger the pipeline.| Requires webhook configuration for GitHub or Bitbucket.|
+
+4. Click **Create Workflow**; a workflow with both build and deployment pipelines will be created.
+
+ 
+
+5. If you want to configure advanced configurations in the build pipeline, such as Custom image tag pattern, Vulnerability Scanning, etc., refer to the [CI Pipeline](./ci-pipeline.md#configuring-advanced-options) page to learn more.
+
+6. If you want to configure advanced configurations in the deployment pipeline, such as adding pre/post tasks, Custom image tag pattern, configure different deployment strategies, etc., refer to the [CD Pipeline](./cd-pipeline.md) page to learn more.
+
+7. If you want, you can also add Pre/Post Tasks in both build and deployment pipelines. To do so, refer to the [Pre/Post tasks](./pre-post-tasks.md) page to learn more.
+
+---
+
+## Types of CI Pipelines
+
+Apart from configuring advanced options, you can create five types of CI pipelines depending on your use case.
+
+* [Build from Source Code](./ci-pipeline.md#1-build-from-source-code): Choose this option if you want Devtron to build the image of the source code.
+
+* [Linked Build Pipeline](./ci-pipeline.md#2-linked-build-pipeline): Choose this option if you want to use an image created by an existing CI pipeline in Devtron.
+
+* [Deploy Image from External Service](./ci-pipeline.md#3-deploy-image-from-external-service): Choose this if you want to build your image outside Devtron; it will receive a Docker image from an external source via the incoming webhook.
+
+* [Sync with Environment](./ci-pipeline.md#4-sync-with-environment-)
+
+* [Create a Job](./ci-pipeline.md#5-create-a-job)
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/workflow/automated-test.md b/versioned_docs/version-1.7/user-guide/creating-application/workflow/automated-test.md
new file mode 100755
index 0000000000..49d85519cf
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/workflow/automated-test.md
@@ -0,0 +1,24 @@
+---
+id: automated-test
+title: automated-test
+sidebar_label: automated-test
+---
+
+## Automated Test suite integration in the CI step using devtron-ci.yaml
+
+Users can run the test case using the Devtron dashboard or by including the test cases in the devtron.ci.yaml file in the source git repository. For reference, check: [https://github.com/kumarnishant/getting-started-nodejs/blob/master/devtron-ci.yaml](https://github.com/kumarnishant/getting-started-nodejs/blob/master/devtron-ci.yaml)
+
+The test cases given in the script will run before the test cases given in the devtron.ci.yaml
+
+
+
+| Field | Description |
+| :--- | :--- |
+| `version` | specify the version of yaml |
+| `appliesTo` | applies the changes to a specified branch |
+| `type` | branch type on which changes are to be applied, it can be **BRANCH\_FIXED** or **TAG\_PATTERN** |
+| `value` | branch name on which changes are to be applied, it can take a value as the name of branch \(“master”\) or as a regular expression \("%d.%d.%d-rc"\) |
+| `script` | A script which you want to execute, you can also execute the docker commands here |
+| `beforeDockerBuildStages` | script to run before the docker build step |
+| `afterDockerBuildStages` | script to run after the docker build step |
+| `outputLocation` | The location where you want to see the output of the report of Test cases |
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/workflow/cd-pipeline.md b/versioned_docs/version-1.7/user-guide/creating-application/workflow/cd-pipeline.md
new file mode 100755
index 0000000000..bb09090aa9
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/workflow/cd-pipeline.md
@@ -0,0 +1,557 @@
+---
+id: cd-pipeline
+title: CD Pipeline
+sidebar_label: CD Pipeline
+---
+
+# CD Pipeline
+
+:::caution Prerequisites
+A [CI pipeline](./ci-pipeline.md) created in your workflow.
+:::
+
+After your CI pipeline is ready, you can start building your CD pipeline. Devtron enables you to design your CD pipeline in a way that fully automates your deployments. Images from Build stage can be deployed to one or more environments through dedicated CD pipelines.
+
+Click the '**+**' sign on CI Pipeline to attach a CD Pipeline to it.
+
+
+
+A basic `Create deployment pipeline` window will pop up.
+
+
+
+Here, you get two tabs:
+* [New Deployment](#new-deployment) - Use this option to create a new Helm/GitOps deployment.
+* [Migrate to Devtron](#migrate-to-devtron) - Use this option if you wish to migrate your existing Helm Release/Argo CD Apps to Devtron.
+
+---
+
+## New Deployment
+
+The **New Deployment** tab displays the following sections:
+
+* [Deploy to Environment](#deploy-to-environment)
+* [Deployment Strategy](#deployment-strategy)
+* [Advanced Options](#advanced-options)
+
+### Deploy to Environment
+
+This section expects four inputs from you:
+
+| Setting | Description | Options |
+| ----------- | ---------------------------------------------------------- | ------------------------- |
+| Environment | Select the environment where you want to deploy your application | (List of available environments) |
+| Namespace | Automatically populated based on the selected environment | Not Applicable |
+| Trigger | When to execute the deployment pipeline | **Automatic**: Deployment triggers automatically when a new image completes the previous stage (build pipeline or another deployment pipeline) **Manual**: Deployment is not initiated automatically. You can trigger deployment with a desired image. |
+| Deployment Approach | How to deploy the application | **Helm**, [GitOps(ArgoCD)](../../integrations/argocd.md) or [Gitops (FluxCD)](../../creating-application/fluxcd.md) Refer [GitOps](../../global-configurations/gitops.md) to learn more |
+
+:::caution FluxCD Deployment Failed
+ * Make sure that the FluxCD controller is installed in the cluster in which you want to deploy the application. Refer [Enable GitOps Deployments with FluxCD](../../creating-application/fluxcd.md#installing-fluxcd-controller-only-for-deployments) to learn more.
+
+ * Application deployments through GitOps (via FluxCD) are supported only when using the `Deployment` or `Rollout` deployment strategies with the latest chart versions. Other deployment strategies are currently not supported.
+
+:::
+
+:::info Deploying to an Isolated Environment?
+In case you are choosing an [isolated environment](../../global-configurations/cluster-and-environments.md#add-isolated-cluster-) for deployment, you will get two additional options to choose from in the 'Deploy to Environment' window ([check snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/use-cases/oci-push/create-cd2.jpg)):
+ * **Do not push** - A link to download the helm package will be available after the deployment. However, it will not push the helm package to the OCI registry.
+ * **Push to registry** - This will generate and [push the helm package to the OCI registry](../../global-configurations/container-registries.md#push-helm-packages). Upon selecting this option, you will get two more fields:
+ * **Registry** - Choose the OCI registry to which the helm chart package must be pushed. Only those registries that have `Push helm packages` enabled will be shown in the dropdown.
+ * **Repository** - Enter the repository name. You can find the username from your registry provider account (e.g., Docker Hub).
+
+:::
+
+### Deployment Strategy
+
+Devtron supports multiple deployment strategies depending on the [deployment chart type](../../creating-application/base-config/deployment-template.md#select-a-deployment-chart-type).
+
+
+
+Refer to [Deployment Strategies](#deployment-strategies) to know more about each strategy in depth.
+
+The next section is [Advanced Options](#advanced-options) and it comes with additional capabilities. This option is available at the bottom of the `Create deployment pipeline` window. However, if you don't need them, you may proceed with a basic CD pipeline and click **Create Pipeline**.
+
+
+
+---
+
+### Advanced Options
+
+After selecting **Advanced Options**, the `Create deployment pipeline` window has 3 distinct tabs, and you will see the following additions:
+
+* [Pre-Deployment stage (tab)](#pre-deployment-stage)
+* [Deployment stage (tab)](#deployment-stage)
+* [Post-Deployment stage (tab)](#post-deployment-stage)
+
+
+
+:::info Note
+You can create or edit a deployment strategy in Advanced Options. Remember, only the default strategy will be used for deployment, so use the **SET DEFAULT** button to mark your preferred strategy as default after creating it.
+:::
+
+### Pre-Deployment Stage
+
+If your deployment requires prior actions like DB migration, code quality check (QC), etc., you can use the `Pre-Deployment stage` to configure such tasks. Refer [Pre/Post tasks](./pre-post-tasks.md) to configure tasks in `Pre-Deployment stage`.
+
+
+
+
+
+### Deployment Stage
+
+#### Pipeline Name
+
+The pipeline name will be auto-generated; however, you are free to modify the name as per your requirement.
+
+
+
+#### Deployment Strategies
+
+A deployment strategy is a method of updating, downgrading, or creating new versions of an application. The options you see under deployment strategy depend on the selected chart type (see Fig. 3). Below are some deployment configuration-based strategies.
+
+#### Blue-Green Strategy
+
+Blue-green deployments involve running two versions of an application at the same time and moving traffic from the in-production version \(the green version\) to the newer version \(the blue version\).
+
+```markup
+blueGreen:
+ autoPromotionSeconds: 30
+ scaleDownDelaySeconds: 30
+ previewReplicaCount: 1
+ autoPromotionEnabled: false
+```
+
+| Key | Description |
+| :--- | :--- |
+| `autoPromotionSeconds` | It will make the rollout automatically promote the new ReplicaSet to active Service after this time has passed |
+| `scaleDownDelaySeconds` | It is used to delay scaling down the old ReplicaSet after the active Service is switched to the new ReplicaSet |
+| `previewReplicaCount` | It will indicate the number of replicas that the new version of an application should run |
+| `autoPromotionEnabled` | It will make the rollout automatically promote the new ReplicaSet to the active service |
+
+#### Rolling Strategy
+
+A rolling deployment slowly replaces instances of the previous version of an application with instances of the new version of the application. Rolling deployment typically waits for new pods to become ready via a readiness check before scaling down the old components. If a significant issue occurs, the rolling deployment can be aborted.
+
+```markup
+rolling:
+ maxSurge: "25%"
+ maxUnavailable: 1
+```
+
+| Key | Description |
+| :--- | :--- |
+| `maxSurge` | No. of replicas allowed above the scheduled quantity |
+| `maxUnavailable` | Maximum number of pods allowed to be unavailable |
+
+#### Canary Strategy
+
+Canary deployments are a pattern for rolling out releases to a subset of users or servers. The idea is to first deploy the change to a small subset of servers, test it, and then roll the change out to the rest of the servers. The canary deployment serves as an early warning indicator with less impact on downtime: if the canary deployment fails, the rest of the servers aren't impacted.
+
+```markup
+canary:
+ maxSurge: "25%"
+ maxUnavailable: 1
+ steps:
+ - setWeight: 25
+ - pause:
+ duration: 15 # 15 sec
+ - setWeight: 50
+ - pause:
+ duration: 1m # 1 min
+ - setWeight: 75
+ - pause:
+ duration: 1m # 1 min
+```
+
+| Key | Description |
+| :--- | :--- |
+| `maxSurge` | It defines the maximum number of replicas the rollout can create to move to the correct ratio set by the last setWeight |
+| `maxUnavailable` | The maximum number of pods that can be unavailable during the update |
+| `setWeight` | It is the required percent of pods to move to the next step |
+| `duration` | It is used to set the duration to wait to move to the next step |
+
+#### Recreate Strategy
+
+The recreate strategy is a dummy deployment that consists of shutting down version 'A' and then deploying version 'B' after version 'A' is turned off.
+
+A recreate deployment incurs downtime because, for a brief period, no instances of your application are running. However, your old code and new code do not run at the same time. It terminates the old version and releases the new one.
+
+```markup
+recreate:
+```
+
+Unlike other strategies mentioned above, 'Recreate' strategy doesn't contain keys for you to configure.
+
+:::info Does your app have different requirements for different environments?
+Read [Environment Overrides](../environment-overrides.md)
+:::
+
+
+#### Configure Deployment Strategies
+
+To configure the CD pipeline for different deployment strategies, follow the steps below:
+
+1. Select **Add Strategy** and select the deployment strategies you want to add.
+
+ 
+
+ * In case, you have multiple deployment strategies, you have to choose a default deployment strategy which are configured for the pipeline.
+
+ 
+
+ * If in any scenario such as deploying a hotfix, if you need to use a different deployment strategy other than the default, you can change it from **Build & Deploy** section while triggering the deployment.
+
+ **Note:** You can only select the deployment strategies which are configured for that pipeline.
+
+ 
+
+2. Configure the deployment strategy by selecting the **Settings** icon next to it to edit the strategy template according to your use case.
+
+ 
+
+ 
+
+ 
+
+ 
+
+3. Select **Update Pipeline** to save the configurations.
+
+ 
+
+
+#### Custom Image Tag Pattern
+
+:::caution Note
+This will be utilized only when an existing container image is copied to another repository using the [Copy Container Image Plugin](../../plugins/copy-container-image.md). The image will be copied with the tag generated by the Image Tag Pattern you defined.
+:::
+
+1. Enable the toggle button as shown below.
+
+ 
+
+2. Click the edit icon.
+
+ 
+
+3. You can write an alphanumeric pattern for your image tag, e.g., **prod-v1.0.`{x}`**. Here, 'x' is a mandatory variable whose value will incrementally increase with every pre or post deployment trigger (that option is also available to you). You can also define the value of 'x' for the next trigger in case you want to change it.
+
+ 
+
+:::caution Warning
+Ensure your custom tag do not start or end with a period (.) or comma (,)
+:::
+
+4. Click **Update Pipeline**.
+
+To know how and where this image tag would appear, refer [Copy Container Image Plugin](../../plugins/copy-container-image.md)
+
+#### Pull Container Image with Image Digest
+
+Although Devtron ensures that [image tags](#custom-image-tag-pattern) remain unique, the same cannot be said if images are pushed with the same tag to the same container registry from outside Devtron.
+
+Therefore, to eliminate the possibility of pulling an unintended image, Devtron offers the option to pull container images using digest and image tag.
+
+
+
+An image digest is a unique and immutable SHA-256 string returned by the container registry when you push an image. So the image referenced by the digest will never change.
+
+
+
+:::caution Who Can Perform This Action?
+Users need to have Admin permission or above (along with access to the environment and application) to enable this option. However, this option will be non-editable in case the super-admin has enabled [pull image digest in Global Configurations](../../global-configurations/pull-image-digest.md).
+:::
+
+### Post-Deployment Stage
+
+If you need to run any actions, e.g., closure of Jira ticket, load testing, or performance testing, you can configure such actions in the post-deployment stages.
+
+Post-deployment stages are similar to Pre-Deployment stages. The difference is that pre-deployment executes before the deployment, while post-deployment occurs after.
+
+You can use [ConfigMap](../base-config/config-maps.md) and [Secrets](../base-config/secrets.md) in post deployments as well. The option to execute tasks in application environment is available too.
+
+Refer [Pre/Post tasks](./pre-post-tasks.md) to configure tasks in `Post-deployment stage`.
+
+
+
+---
+
+## Migrate to Devtron
+
+:::info When can I see this option?
+This option will be available only during the creation of CD pipeline in your workflow. Existing CD pipelines will not have this option.
+:::
+
+:::caution Who Can Perform This Action?
+Only superadmins can migrate existing Helm releases or Argo apps to Devtron
+:::
+
+If you already use external Helm or Argo CD for deployment and wish to try out Devtron, this feature helps you onboard and manage your external applications using Devtron’s CI/CD capabilities, offering the following benefits:
+
+* No hassle of manually migrating your existing applications
+* No need to set up a parallel Argo CD instance
+* No risk of losing your existing configurations
+* Use build pipeline in your workflow
+* Execute pre-deployment and post-deployment tasks
+* Scan your apps for vulnerabilities
+* Hibernate or restart your app
+* View config diff, deployment history, and all the capabilities that come with Devtron Apps. Check the [full list of features](https://devtron.ai/pricing).
+
+### Migrate Helm Release
+
+:::caution Prerequisites
+* Add your external cluster (containing your Helm Apps) in [Clusters & Environments](../../global-configurations/cluster-and-environments.md).
+* Your Helm release must use the same chart type as your application. If needed, you can upload or select the appropriate chart in **Global Configurations** → **Deployment Charts**, then save the chart type at [base configuration](../base-config/deployment-template.md) of your application.
+:::
+
+You can not only [view your external Helm apps](../../applications.md#view-external-helm-app-listing), but also manage their deployments using Devtron's CI/CD.
+
+1. Click **Helm Release** in 'Select type of application to migrate'.
+
+2. Select the external cluster containing your Helm releases, and select the Helm release you wish to migrate.
+
+ 
+
+3. The target cluster, its namespace, and environment would be visible. If the environment is not available, click **Add Environment**. This will open a new tab. Once you have [added the environment to your cluster](../../global-configurations/cluster-and-environments.md#add-environment-to-a-cluster), return and click the refresh button.
+
+ 
+
+4. Select the trigger (**Automatic/Manual**) and click **Create Pipeline**.
+
+ 
+
+5. Once the pipeline is created, you may go to [Build & Deploy](../../deploying-application/README.md) to trigger the pipelines. Your Helm release would be deployed using Devtron.
+
+:::info Limitations
+This feature comes with certain mentioned limitations and expectations. If your use case doesn't fit and goes beyond, feel free to [**open a feature request**](https://github.com/devtron-labs/devtron/issues).
+
+* Apps deployed using Helm + manual kubectl, kubectl, kustomize + helm are not supported.
+* By default, Devtron detects and uses `app-values.yaml` as the values file. If your Helm app contains multiple values files, you must consolidate it into a single `app-values.yaml`.
+* Once an app is onboarded to Devtron, the user should only use Devtron to manage that application and not make manual changes on that onboarded Helm release. This is because Devtron might not monitor or reconcile the manual changes you make outside Devtron.
+
+:::
+
+### Migrate Argo CD Application
+
+You can not only [view your external Argo CD apps](../../applications.md#view-external-argocd-app-listing), but also manage their deployments using Devtron's CI/CD.
+
+:::caution Prerequisites
+* Your app should be an Argo Helm app ([read about supported tools](https://argo-cd.readthedocs.io/en/stable/user-guide/application_sources/)).
+
+* It must have a single Git source and a single values file. By default, Devtron expects `app-values.yaml` so make sure it is committed to Git.
+
+* GitOps credentials required to commit in the Git repo should be configured in [Global Configurations](../../global-configurations/gitops.md).
+
+* The cluster containing your external Argo applications should be added to Devtron. Refer [Clusters & Environments](../../global-configurations/cluster-and-environments.md).
+
+* The target deployment cluster, its namespace, and its [environment](../../global-configurations/cluster-and-environments.md#add-environment-to-a-cluster) should be added to Devtron.
+
+* Your Argo CD app must use the same chart type as your application. If needed, you can upload or select the appropriate chart in **Global Configurations** → **Deployment Charts**. Then save the chart type at [base configuration](../base-config/deployment-template.md) of your application.
+
+* The external Argo CD should have auto-sync enabled or an alternative syncing mechanism, as Devtron does not perform manual syncs.
+
+:::
+
+1. Click **Argo CD Application** in 'Select type of application to migrate'.
+
+2. Select the external cluster containing your Argo apps, and select the Argo CD application you wish to migrate.
+
+ 
+
+3. The target cluster, its namespace, and environment would be visible. If the environment is not available, click **Add Environment**. This will open a new tab. Once you have [added the environment to your cluster](../../global-configurations/cluster-and-environments.md#add-environment-to-a-cluster), return and click the refresh button.
+
+ 
+
+4. Select the trigger (**Automatic/Manual**) and click **Create Pipeline**.
+
+ 
+
+5. Once the pipeline is created, you may go to [Build & Deploy](../../deploying-application/README.md) to trigger the pipelines. Your Argo CD app would be deployed using Devtron.
+
+:::info Limitations
+This feature comes with certain mentioned limitations and expectations. If your use case doesn't fit and goes beyond, feel free to [**open a feature request**](https://github.com/devtron-labs/devtron/issues).
+
+* The Git source type should be branch HEAD.
+* The target deployment cluster’s endpoint in Devtron must be the same as the one configured in Argo CD.
+* Once onboarded to Devtron, users should manage the application only through Devtron and avoid making changes directly in Git or Argo CD. This is because Devtron might not monitor or reconcile the manual changes you make outside Devtron.
+:::
+
+:::caution Note
+If you have configured [GitOps](../gitops-config.md) for your external Argo apps in Devtron, and later install the GitOps (ArgoCD) module from [Devtron Stack Manager](../../integrations/argocd.md) to deploy your Devtron apps/Helm apps via GitOps, you must once again save your GitOps and Cluster configurations after installation. This might prevent potential errors and ensure your GitOps deployments are functional.
+:::
+
+### Migrate Flux CD Application
+
+You can not only [view your external Flux CD apps](../../applications.md#view-external-fluxcd-app-listing), but also manage their deployments using Devtron's CI/CD.
+
+:::caution Prerequisites
+ * Your app should be a Flux Helm release.
+
+ * The Helm chart values will be referenced from the file (e.g., values.yaml) mentioned in the helm release at `spec.chart.spec.valuesFiles`, otherwise, they will be taken from `spec.extFluxValues`.
+
+ * Devtron only supports [Refer to values inside the chart](https://fluxcd.io/flux/guides/helmreleases/#refer-to-values-inside-the-chart) only.
+
+ * GitOps credentials required to commit in the Git repo should be configured in [Global Configurations](../../global-configurations/gitops.md).
+
+ * The cluster containing your external Flux Helm release applications should be added to Devtron. Refer [Clusters & Environments](../../global-configurations/cluster-and-environments.md).
+
+ * The target deployment cluster, its namespace, and its [environment](../../global-configurations/cluster-and-environments.md#add-environment-to-a-cluster) should be added to Devtron.
+
+ * The external Flux CD should have auto-sync enabled or an alternative syncing mechanism, as Devtron does not perform manual syncs.
+
+:::
+
+1. Click **Flux CD Application** in 'Select type of application to migrate'.
+
+ 
+
+2. Select the external cluster containing your Flux apps, and select the Flux CD application you wish to migrate.
+
+ 
+
+3. The target cluster, its namespace, and environment would be visible. If the environment is not available, click **Add Environment**. This will open a new tab. Once you have [added the environment to your cluster](../../global-configurations/cluster-and-environments.md#add-environment-to-a-cluster), return and click the refresh button.
+
+ 
+
+4. Select the trigger (**Automatic/Manual**) and click **Create Pipeline**.
+
+ 
+
+5. Once the pipeline is created, you may go to [Build & Deploy](../../deploying-application/README.md) to trigger the pipelines. Your Flux CD app would be deployed using Devtron.
+
+
+:::info Limitations
+This feature comes with certain mentioned limitations and expectations. If your use case doesn't fit and goes beyond, feel free to [**open a feature request**](https://github.com/devtron-labs/devtron/issues).
+
+* The Git source type should not be branch HEAD.
+* The target deployment cluster’s endpoint in Devtron must be the same as the one configured in FluxCD.
+* Once onboarded to Devtron, users should manage the application only through Devtron and avoid making changes directly in Git or FluxCD. This is because Devtron might not monitor or reconcile the manual changes you make outside Devtron.
+:::
+
+---
+
+## Updating CD Pipeline
+
+You can update the deployment stages and the deployment strategy of the CD Pipeline whenever you require it. However, you cannot change the name of a CD Pipeline or its Deployment Environment. If you want a new CD pipeline for the same environment, first delete the previous CD pipeline.
+
+To update a CD Pipeline, go to the `App Configurations` section, Click on `Workflow editor` and then click on the CD Pipeline you want to Update.
+
+
+
+Make changes as needed and click on `Update Pipeline` to update this CD Pipeline.
+
+---
+
+## Deleting CD Pipeline
+
+If you no longer require the CD Pipeline, you can also delete the Pipeline.
+
+To delete a CD Pipeline, go to the App Configurations and then click on the Workflow editor. Now click on the pipeline you wish to delete. A pop-up having the CD details will appear. Verify the name and the details to ensure that you are not accidentally deleting the wrong CD pipeline and then click **Delete Pipeline** to delete it.
+
+:::caution
+Deleting a CD pipeline also deletes all the K8s resources associated with it and will bring a disruption in the deployed micro-service. Before deleting a CD pipeline, please ensure that the associated resources are not being used in any production workload.
+:::
+
+---
+
+## Extras
+
+### Creating Sequential Pipelines
+
+Devtron supports attaching multiple deployment pipelines to a single build pipeline, in its workflow editor. This feature lets you deploy an image first to stage, run tests and then deploy the same image to production.
+
+Please follow the steps mentioned below to create sequential pipelines:
+
+1. After creating CI/build pipeline, create a CD pipeline by clicking on the `+` sign on CI pipeline and configure the CD pipeline as per your requirements.
+
+2. To add another CD Pipeline sequentially after previous one, again click on + sign on the last CD pipeline.
+
+3. Similarly, you can add multiple CD pipelines by clicking + sign of the last CD pipeline, each deploying in different environments.
+
+ 
+
+:::tip Tip
+If you have multiple applications that already have an existing pipeline (for a given environment) in their workflow, you may clone the same pipeline and its configurations for new environments instead of recreating them in each application. Refer [Clone Pipeline Config](../../application-groups.md#clone-pipelines-) to know more.
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/workflow/ci-pipeline.md b/versioned_docs/version-1.7/user-guide/creating-application/workflow/ci-pipeline.md
new file mode 100755
index 0000000000..8d4a99565a
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/workflow/ci-pipeline.md
@@ -0,0 +1,884 @@
+---
+id: ci-pipeline
+title: CI Pipeline
+sidebar_label: CI Pipeline
+---
+
+# CI Pipeline
+
+:::caution Who Can Perform This Action?
+Users need to have the **Admin role**, the **Manager role**, or the **Super Admin role**.
+Refer the [User permissions](../../global-configurations/authorization/user-access.md#roles-available-for-devtron-apps).
+:::
+
+A workflow can be created in one of the following ways:
+
+* [Build from Source Code](#1-build-from-source-code)
+
+* [Linked Build Pipeline](#2-linked-build-pipeline)
+
+* [Deploy Image from External Service](#3-deploy-image-from-external-service)
+
+* [Sync with Environment](#4-sync-with-environment-)
+
+* [Create a Job](#5-create-a-job)
+
+Each method has different use-cases that can be tailored according to the needs of the organization.
+
+---
+
+## 1. Build from Source Code
+
+**Build from Source Code** workflow allows you to build the container image from a source code repository.
+
+:::info Note
+Devtron typically uses a Dockerfile from your repository to build container images. If you don’t have one, Devtron provides default templates to help you get started. You can also build images without a Dockerfile using **Buildpacks**.
+:::
+
+### Creating a CI Pipeline
+
+1. From the **Applications** page, select your application.
+
+2. Go to **Configurations** tab and select **Workflow Editor**.
+
+3. Click **+ New Workflow**.
+
+ 
+
+4. Select **Build from Source Code**.
+
+ 
+
+5. In the **Create Build Pipeline** window, enter the following details:
+
+ 
+
+ | Field Name|Required/Optional| Description|
+ | :--- | :--- | :--- |
+ | `Pipeline Name`| Required (Auto-Assigned) | Devtron automatically assigns a unique name for the pipeline. If you wish, you can change it in [Advanced Options](#configuring-advanced-options)|
+ | `Source type`| Required| Source type to trigger the CI. **Available options:** `Branch Fixed`, `Branch Regex`, `Pull Request`, `Tag Creation`|
+ | `Branch Name`| Required| Branch that triggers the CI build|
+ | `Advanced Options` | Optional| Create Pre-Build, Build, and Post-Build tasks Refer the [Configure Advanced options](#configuring-advanced-options) section to configure **Advanced options**. |
+
+ ### Understanding Source Types
+
+ Devtron allows you set up different source types for a build pipeline, source types specify the repository events that initiate a build pipeline, such as a change in a branch, pull request creation, or tag creation.
+
+ 
+
+ |Source Type| Description| Additional Requirements|
+ |:---|:---|:---|
+ | `Branch Fixed`| Triggers a CI build whenever changes are pushed to a specified branch.| Requires a predefined branch name.|
+ | `Branch Regex`| Allows dynamic branch selection based on a regex pattern| Requires a regex pattern to be defined. For example, if the user sets the Branch Regex as feature-\*, then users can trigger the build from branches such as feature-1450, feature-hot-fix, etc. |
+ | `Pull Request` (PR) | Triggers a CI build when a new pull request is created. You can also define filters (such as PR author, title, or branch) to control which pull requests trigger the pipeline. | Requires [configuring a webhook](#configuring-webhook) for GitHub or Bitbucket.|
+ | `Tag Creation`| Triggers a build whenever a new tag is created. You can also define filters (such as author and tag name) to control which tags trigger the pipeline.| [Configuring a webhook](#configuring-webhook) for GitHub or Bitbucket.|
+
+
+ #### Pull Request Filters
+
+ When using **Pull Request** as a source type, Devtron allows you to filter which PRs should trigger a build using the following filters
+
+ 
+
+ Select the appropriate filter and pass the matching condition as a regular expression (regex).
+
+ :::info
+Devtron uses the regexp library, view [regexp cheatsheet](https://yourbasic.org/golang/regexp-cheat-sheet/). You can test your custom regex from [here](https://regex101.com/r/lHHuaE/1).
+ :::
+
+ | Filter Key | Description |
+ | :-------------- | :--------------------------------------------------------------------- |
+ | `Author` | Author of the PR |
+ | `Source Branch` | The git branch from which the PR originates, e.g., `feature-login-auth`|
+ | `Target Branch` | The git branch to which the PR is being merged, e.g., `main` |
+ | `Title` | Title of the PR |
+ | `State` | Status of the PR (default is `open`) |
+
+ #### Tag Creation Filters
+
+ When using **Tag Creation** as a source type, Devtron allows you to filter which tags should trigger a build based on the following filters
+
+ 
+
+ Select the appropriate filter and pass the matching condition as a regular expression (regex).
+
+ :::info
+Devtron uses the regexp library, view [regexp cheatsheet](https://yourbasic.org/golang/regexp-cheat-sheet/). You can test your custom regex from [here](https://regex101.com/r/lHHuaE/1).
+ :::
+
+ | Filter Key | Description |
+ | ---------- | ------------------------ |
+ | `Author` | User who created the tag |
+ | `Tag Name` | Name of the tag |
+
+6. Click **Create Pipeline** to save the configuration. You can now proceed to trigger the build, or continue below to explore additional configuration options for customizing your pipeline.
+
+ 
+
+### Configuring Advanced Options
+
+Devtron provides three stages in a CI pipeline: `Pre-Build`, `Build`, and `Post-Build`.
+
+* **Pre-build stage**: The tasks in this stage are executed before the image is built.
+
+* **Build stage**: In this stage, the build is triggered from the source code that you provide.
+
+* **Post-build stage**: The tasks in this stage will be triggered once the build is complete.
+
+This document focuses on configuring the Build Stage. If you want to set up Pre-Build and Post-Build stages, refer to the [Pre/Post Stages](./pre-post-tasks.md) to learn more.
+
+### Build Stage
+
+1. In **Create Build Pipeline** window, select **Advanced options**.
+
+ 
+
+2. Go to **Build stage** tab and configure the following fields:
+
+ 
+
+
+ | Field Name| Required/Optional | Description|
+ | :---| :--- |:---|
+ | `TRIGGER BUILD PIPELINE`| Required|
The build execution may be set to:
Automatically(default): Build is triggered automatically as the Git source code changes.
Manually: Build is triggered manually.
|
+ | DOCKER LAYER CACHING | Optional | Use this to [enable/disable caching of docker image layers](#docker-layer-caching-) from your build pipeline |
+ | `Pipeline Name`| Required| Devtron automatically assigns a unique name for the pipeline, if you wish, you can edit it here.|
+ | `Scan for Vulnerabilities` | Optional|
Prerequisite: Install either [Clair](../../integrations/vulnerability-scanning/clair.md) or [Trivy](../../integrations/vulnerability-scanning/trivy.md).
In the **Build** Stage, enable the **Scan for vulnerabilities** toggle.
Refer: [Vulnerability Scanning](../../integrations/vulnerability-scanning/README.md) to learn more.
Override docker build configurations for this pipeline.
Key: Field name
Value: Field value.
|
+ | `Custom Image Tag Pattern` | Optional|
Enable the Custom Image Tag Pattern toggle.
Define an alphanumeric pattern (e.g., test-v1.0.`{x}`) where `{x}` auto-increments with each build.
Tags must not start or end with a period (.) or comma (,).
After configuration, trigger a build by navigating to **Build & Deploy**, selecting the Git commit by clicking on **Select Material**, and clicking **Start Build**.
The generated image tag will be available in **Build History**, Docker Registry, CD Pipeline (Image Selection)
Note: Build will fail if the resulting image tag has already been built in the past. This error might occur when you reset the value of the variable `x` or when you disable/enable the toggle button for **Custom image tag pattern**.
|
+
+3. Click **Create Pipeline** to save the configuration.
+
+ 
+
+#### Triggering a Build
+
+Once the CI pipeline is set up, follow these steps to trigger a build:
+
+1. Navigate to **Build & Deploy**.
+
+2. Click **Select Material** in the specific pipeline for which you want to trigger the build.
+
+ 
+
+3. Choose the **Git commit** to build under **Code Source** tab.
+
+ 
+
+
+4. Configure runtime parameters (if any) before starting the build under the **Parameters** tab.
+
+ 
+
+5. Click **Start Build**. This will trigger the build process and push the generated container image to the configured container registry for storage, versioning, and later use in the CD pipeline.
+
+ 
+
+---
+
+## 2. Linked Build Pipeline
+
+**Linked Build Pipeline** allows you to reuse build images from another pipeline within **Devtron**, instead of building images from source code each time.
+
+This is useful when the same codebase is shared across multiple applications.
+
+Instead of creating and maintaining separate pipelines for each application, you can first set up a primary build pipeline (in the same application or in any other application) that builds the image from source code using **Build and Deploy from Source Code** or you can also use an existing pipeline from any application with the same codebase.
+
+Then, for other applications, you can simply link that source pipeline to reuse its build images directly in your workflow and proceed to create a CD pipeline using those images.
+
+:::info
+The **Linked Build Pipeline** can only access build images that are generated after it has been created. Any images built by the source pipeline before the Linked Build Pipeline was set up will not be available.
+:::
+
+To create a **Linked Build Pipeline**, follow the steps below.
+
+:::caution Who Can Perform This Action?
+Users need to have the **Admin role**, the **Manager role**, or the **Super Admin role**.
+Refer the [User permissions](../../global-configurations/authorization/user-access.md#roles-available-for-devtron-apps).
+:::
+
+1. Navigate to **Configurations** (tab) → **Workflow Editor** of your application.
+
+2. Select **+ New Workflow**, a modal window will appear where you can select the type of pipeline you want to create.
+
+ 
+
+3. Select **Linked Build Pipeline**. Another modal window will appear where you can enter the details of the existing pipeline you want to link.
+
+ 
+
+4. Enter the details of the existing pipeline you want to link and click **Create Linked CI Pipeline** to create the pipeline.
+
+ 
+
+ :::caution Note
+ The user must have at least view access to the application that contains the source pipeline, otherwise, the application will not appear in the **Filter By Application** field.
+ :::
+
+ |Field Name|Description|
+ |:---|:---|
+ |Filter By Application|Enter the application name in which the source CI pipeline exists.|
+ |Source CI pipeline|List all the build pipelines for the selected application. Choose the pipeline that you want to link|
+ |Name|Enter the name for the **Linked Build Pipeline**.
By default, it takes the name of the source pipeline, if you wish, you can rename it.
In case the source pipeline exists within the same application, the **Linked Build Pipeline** name must be different from the source pipeline, as Devtron does not allow two pipelines with the same name within a single application.
|
+
+ 
+
+ Thereafter, the source CI pipeline will indicate the number of Linked CI pipelines. On clicking it, a modal window will appear, which lists all the applications from which the source pipeline is linked, as shown in the image below.
+
+ 
+
+5. After creating a **Linked CI Pipeline**, you can create a CD pipeline. Refer to [CD Pipeline](./cd-pipeline.md) page to know more.
+
+ 
+
+:::caution Note
+Linked CI pipelines can't trigger builds. They rely on the source CI pipeline to build images. Trigger a build in the source CI pipeline to see the images available for deployment in the linked CI pipeline's Deployment stage.
+:::
+
+---
+
+## 3. Deploy Image from External Service
+
+**Deploy Image from External Service** allows you to deploy container images built by external CI tools such as Jenkins, CircleCI, etc., using webhooks.
+
+This is useful when your CI pipeline is managed outside the Devtron platform, allowing you to use Devtron exclusively for deploying container images on Kubernetes while maintaining your existing CI setup.
+
+To create a pipeline form **Deploy Image from External Service**, follow the steps below
+
+1. Navigate to **Configurations** (tab) → **Workflow Editor** of your application.
+
+2. Select **+ New Workflow**, a modal window will appear where you can select the type of pipeline you want to create.
+
+ 
+
+3. Select **Deploy Image from External Service**, another modal window will appear where you can enter deployment details such as environment, execution mode, and deployment strategy.
+
+ 
+
+4. Enter the deployment details and click **Create Pipeline** to create the pipeline.
+
+ 
+
+ | Fields | Description |
+ | --- | --- |
+ |**Environment**|Provide the name of the Environment in which you want to deploy your image.|
+ |**Namespace**|It will display the namespace of that Environment.|
+ | **When do you want the pipeline to execute?** | You can deploy either in one of the following ways:
`Automatic`: Pipeline triggers automatically when a new container image is received from the previous stage. Users can also trigger the pipeline manually.
`Manual`: Users can trigger the pipeline manually.
|
+ | **Deployment Strategy** | Choose the [Deployment Strategy](./cd-pipeline.md#deployment-strategies) according to your preference. |
+
+ To get the image from an external CI service (let's say Jenkins), you need to configure the Webhook provided by Devtron in your existing External CI pipeline.
+
+### Configure Webhook in External CI
+
+To configure the Webhook in External CI, follow the steps below.
+
+1. After creating the pipeline, select **Show webhook details** or select **External Source** stage to get the webhook URL and JSON sample payload to be used in the external CI pipeline.
+
+ 
+
+2. On the **Webhook Details** page, click **Select or auto-generate token with required permissions** to select or generate a `API token`. This token allows external CI services to authenticate with Devtron.
+
+ 
+
+ * To select an existing API token, choose an API token from the dropdown under **Select API token**.
+
+ 
+
+ * To generate an API token, select **Auto-generate token** sub tab → Enter a name for the token in the **Token Name** field → Click **Generate token** to generate a token.
+
+ 
+
+ 
+
+3. After generating an API token, click **Sample cURL request** and select the metadata you want to send to Devtron. Sample JSON and cURL request will be generated accordingly.
+
+ 
+
+4. Copy the Sample cURL request and integrate it into your External CI (Jenkins) pipeline along with the API token and tag for Docker Image. Refer to [Integrate with External Sources](#integrate-with-external-sources---jenkins) to know more.
+
+ 
+
+5. After integrating the webhook, whenever the external CI pipeline is triggered and generates an image, the webhook will automatically send the image details to Devtron for deployment.
+
+
+### Integrate with External Sources - Jenkins
+
+To integrate Webhook with your Jenkins project/pipeline, you need to add a new step/stage in your project/pipeline.
+
+Before adding the stage/step, you need to add the API token provided by Devtron as the secret in Jenkins. To do so, follow the steps below:
+
+1. Go to **Manage Jenkins** → **Credentials**.
+
+ 
+
+ 
+
+2. Select **System** under **Stores scoped to Jenkins** → **Global credentials (unrestricted)** → **+Add Credentials**.
+
+ 
+
+ 
+
+ 
+
+3. Select `Secret text` in the **Kind** field and select the required **Scope**
+
+4. Enter the **API Token** generated from Devtron in the **Secret** field.
+
+5. Provide a `ID` (devtron-token) in the **ID** field. If left blank, Jenkins will automatically generate an ID for the credential.
+
+6. If you want you can also provide an optional description in the **Description** field.
+
+7. Select **Create** to create the secret in Jenkins.
+
+ 
+
+ 
+
+After adding the API token as a secret, add a new step/stage in your Jenkins project/pipeline.
+
+In case your Jenkins project is of type `freestyle`, follow the steps below:
+
+1. Select the Jenkins project in which you want to integrate the Webhook.
+
+ 
+
+2. Go to **Configure** → **Environments** and enable the **Use secret text(s) or file(s)** option.
+
+ 
+
+3. Click **Add** under **Bindings** and select **Secret Text**.
+
+4. Provide a variable name (eg., `DEVTRON_TOKEN`) for the secret in **Variable** field. This variable name will be used to access the secret.
+
+5. Select the credential's `ID` in **Specific credentials** under **Credentials**.
+
+ **Note:** In case you have provided a description for your credential, then instead of the credential `ID`, the description will be displayed.
+
+ 
+
+ 
+
+6. Go to **Configure** → **Build Steps**, click **Add build step**, and then select **Execute Shell**.
+
+ 
+
+7. Enter the cURL request command as shown below. Make sure to enter the `API token` and `dockerImage` in your cURL command and click **Save**.
+
+ **Note:** API Token has been referenced from the secret via **Variable Name** (`DEVTRON_TOKEN`) configured in Jenkins credentials using its `ID`
+
+ 
+
+
+In case your Jenkins project is of type `pipeline`, `Multibranch Pipeline`, etc., which uses a **Pipeline Script** or **Jenkinsfile**, then you need to add a new stage in the pipeline for configuring the webhook. To do so follow the steps below.
+
+1. Select the Jenkins project in which you want to integrate the Webhook.
+
+ 
+
+2. Go to **Configure** → **Pipeline**.
+
+ 
+
+3. In case you are using **Pipeline Script**, then modify the script to add a new stage as shown below. If you are using **Pipeline script from SCM**, then modify your Jenkinsfile in the same way.
+
+ 
+
+4. Click **Save**.
+
+The new images that will be built after adding the webhook will be available to Devtron for deployment.
+
+Now, you can access the images on the Devtron dashboard and deploy manually. If you select the **Automatic** deployment option, your application deployment will trigger automatically when a new image is received.
+
+### Integrate with External Sources - GitHub Actions
+
+To integrate Webhook with your GitHub Actions workflow, you need to add a new step in your workflow file.
+
+Before adding the step in the workflow, you need to add the API token provided by Devtron as a secret in your repository. To do so, follow the steps below
+
+1. Navigate to **Settings** tab of your repository.
+
+ 
+
+2. Select **Secrets and variables** → **Actions** under **Security**.
+
+ 
+
+3. Under **Secrets** tab, select **New repository secret**.
+
+ 
+
+4. Enter a name for your secret in the **Name** field.
+
+5. Enter the value of the secret in the **Secret** field.
+
+6. Select **Add Secret** and the secret will be added to your repository.
+
+ 
+
+ 
+
+After adding the API token as a secret, add a new step in your GitHub Action workflow. To do so, follow the steps below:
+
+1. Navigate to **Actions** tab of your repository.
+
+ 
+
+2. Select your workflow under the **All workflows** section.
+
+ 
+
+3. Click the workflow file (`main.yml`) under the workflow name, this will open the workflow file in GitHub.
+
+ 
+
+4. Select the edit icon to add the webhook step in the workflow file.
+
+ 
+
+5. Add the webhook step in the workflow file and select **Commit changes...**
+
+ 
+
+ 
+
+6. Provide a **Commit message** and an optional description.
+
+7. Select **Commit changes**, and the workflow file will be updated with the webhook step.
+
+ 
+
+The new images that will be built after adding the webhook will be available to Devtron for deployment.
+
+Now, you can access the images on the Devtron dashboard and deploy manually. If you select the **Automatic** deployment option, your application deployment will trigger automatically when a new image is received.
+
+---
+
+## 4. Sync with Environment
+
+**Sync with Environment** allows you to reuse the deployed container image from one CD workflow in another CD workflow within the same application.
+
+It is useful when you want to test a microservice (say, A) in a test environment, and it depends on another microservice (say, B). To ensure accurate testing of **Microservice (A)**, you need a stable version of **Microservice (B)** (the one that is already running in production). However, modifying the production pipeline for testing purposes is not ideal and often not allowed due to stability concerns.
+
+In such cases, you can use **Sync with Environment** to create a new workflow that uses the deployed image from the existing CD pipeline (of microservice B) from a specific environment. This image then acts as the source CI for the new workflow within the same application.
+
+This allows the new workflow to use the same image as the stable production environment, thus enabling consistent and reliable testing without impacting production workloads.
+
+To create a pipeline form **Sync with Environment**, follow the steps below
+
+1. Navigate to **Configurations** (tab) → **Workflow Editor** of your application.
+
+2. Select **+ New Workflow**, a modal window will appear where you can select the type of pipeline you want to create.
+
+ 
+
+3. Select **Sync with Environment**, another modal window will appear where you need to select the environment in which the source CD pipeline exists.
+
+ 
+
+4. Select the environment in which the source CD pipeline exists. You can only select one source CD per workflow.
+
+ **Note:** The CD pipeline used as a source cannot be deleted while it’s linked.
+
+ 
+
+5. Select **Deploy to** in the top right corner to select the environment in which you want to deploy the source CD image.
+
+ 
+
+ 
+
+6. Select **Create Pipeline** to create a new workflow.
+
+You can now configure the deployment pipeline, and if you wish, you can also add more deployment pipelines within the same workflow.
+
+---
+
+## 5. Create a Job
+
+If options like **Build and Deploy from Source Code** do not satisfy your use case, you can use **Create a Job** to define a workflow with a custom Build stage and with deployment capabilities.
+
+In this workflow, the build stage is replaced by a Job stage, where you can either use [Preset Plugins](./pre-post-tasks.md#configure-a-task-using-preset-plugins) or define [custom tasks](./pre-post-tasks.md#execute-custom-task) to define custom steps to satisfy your use case. For e.g., you can use a preset plugin to pull the container images required for deployment from a container registry (such as ACR or ECR).
+
+This is useful when the image is built externally (for example, in Jenkins) and needs to be brought into Devtron for further processing and deployment. You can configure tasks like scanning, testing, or notifications using preset plugins either in the Job stage or the pre-CD stage, depending on your use case.
+
+**Create a Job** differs from **Deploy Image from External Source** by allowing you to define custom tasks after the image is received, using Job tasks.
+
+To create a workflow using **Create a job**, follow the steps below
+
+1. Navigate to **Configurations** (tab) → **Workflow Editor** of your application.
+
+2. Select **+ New Workflow**, a modal window will appear where you can select the type of pipeline you want to create.
+
+ 
+
+3. Select **Create a job**. This opens the **Create job pipeline** Window in which you can create and configure your job.
+
+ 
+
+4. In the **Create job pipeline** window, you can create and configure job pipelines.
+
+ 
+
+It includes 2 stages
+
+* [**Basic Configurations**](#basic-configurations)
+
+* [**Tasks to be executed**](#tasks-to-be-executed)
+
+### Basic Configurations
+
+This stage allows you to define primary configurations such as Pipeline name, Source Type, Branch Name, and how the job should be triggered. Refer to the following table to configure each field.
+
+ 
+
+| Field Name|Description|
+| :--- |:--- |
+| `Trigger Job Pipeline` |
The job execution may be set to:
Automatically: Job execution is triggered automatically as the Git source code changes.
Manually: Build is triggered manually.
|
+| `Pipeline Name` | Assign a name to your job pipeline|
+| `Source type` | Source type to trigger the job pipeline. Available options: Branch Fixed, Branch Regex, Pull Request, Tag Creation|
+| `Branch Name`| Branch that triggers the CI build|
+| `Use remote cache`|
Enable this option to use the Docker cache from previous builds. Docker's layer caching mechanism allows unchanged docker images layers to be reused across pipeline runs, thus drastically reducing execution times
The globe toggle, next to Docker Layer Caching means that the configuration is inherited from global
Enabled: Inherits the caching settings defined globally.
Disabled: Allows you to define a pipeline-level configuration specific to this job.
|
+
+### Tasks to be executed
+
+The Stage allows you to define tasks for your job.
+
+You can create one or more tasks. Tasks can be dependent on each other for execution. In other words, the output variable of one task can be used as an input for the next task to execute your job. Tasks will execute in the order they are arranged and can be rearranged by drag-and-drop, however, the order of passing the variables must be followed.
+
+To create a task:
+
+1. Navigate to **Tasks to be executed** in the **Create job pipeline** window.
+
+2. Click **Add Task** to add a task in your job pipeline.
+
+ 
+
+3. A new task will be added (on the left side of the Create job pipeline window), you can configure the task either by selecting one of the available [preset plugins](#pulling-images-through-preset-plugin) or by [Executing a custom script](#create-task-using-custom-script)
+
+ 
+
+#### Pulling Images through Preset Plugin
+
+In Devtron, preset plugins are pre-defined tasks templates that helps you automate and execute common operations such as provisioning infrastructure, taking backups, exporting container images etc., without writing custom scripts.
+
+Devtron provides a set of built-in preset plugins, and you can also create your own plugins in Devtron according to your specific needs.
+
+To create a task using the **Pull Images from Container Repository** plugin, follow the steps below:
+
+**Note:** **Pull Images from Container Repository** plugin only supports [ECR (Elastic Container Registry)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) and [ACR (Azure Container Registry)](https://learn.microsoft.com/en-us/azure/container-registry/).
+
+1. After configuring the basic configurations, select the **Tasks to be executed** Tab
+
+2. Click **+Add Task** from the left side panel.
+
+3. Search for `Pull Images from Container Repository` in the **Search Plugin** Search bar and select **Pull Images from Container Repository** from the list of plugins.
+
+ * The right-side panel will display the fields specific to the **Pull Images from Container Repository** plugin, which are required to be configured.
+
+ * The left-side panel will now show a task under **Tasks (IN ORDER OF EXECUTION)**, named after the selected plugin(by default), along with its logo. You can change the task's name using the **Task name** field, but plugin's logo will remain indicating that it is a preset plugin.
+
+ 
+
+ 
+
+4. Refer the [Pull Images from Container Repository](../../plugins/pull-images-from-container-repository.md) documentation to configure the **Pull Images from Container Repository** fields with appropriate values. You may explore [Plugins documentation](../../plugins/README.md) to configure any of the available plugins.
+
+5. After configuring the fields successfully, your task will be created. If you wish, you can add more tasks by clicking on **+ Add task** in the left-side panel.
+
+#### Create Task using Custom Script
+
+In the job stage, you can also define a task using a custom script to meet specific requirements. To create a task using a custom script, follow the steps below:
+
+1. After configuring the basic configurations, select the **Tasks to be executed** Tab.
+
+2. Click **+Add Task** from the left side panel, and then select **Execute custom task**.
+
+ * The right-side panel will display the fields that are required to be configured in order to create the task.
+
+ * The left-side panel will now display a task under **Tasks (IN ORDER OF EXECUTION)**.
+
+3. Enter the Task name (required) and Task Description (optional).
+
+4. Select the **Task type**, it can be `Shell` or `Container Image`.
+
+ * **Shell Tasks**: These execute shell scripts directly within the job runtime environment. In this type of task, you can define inline scripts or use script files from your configured source code.
+
+ * **Container Image Tasks**: These allow you to execute commands and scripts inside a custom Docker container. Instead of using the default environment provided by Devtron, you can specify you own container image with all dependencies and tools required for the tasks.
+
+ These Tasks run using container in container approach, which means the specified image is pulled and run inside the job pod, thus providing a complete isolated environment.
+
+5. After selecting the **Task type**, you need to configure task-specific fields based on that **Task type**.
+
+
+
+After configuring the **Basic Configurations** and adding the tasks, select **Create Pipeline** to create a new workflow with a job stage (instead of a build stage).
+
+Now, you can add a deployment pipeline to this workflow. The image will be pulled during the execution of the pipeline using the configured plugin, and then passed to the CD stage for deployment.
+
+---
+
+## Updating CI Pipeline
+
+You can update the configurations of an existing CI Pipeline except for the pipeline's name.
+To update a pipeline,
+
+1. Select your CI pipeline.
+
+2. In the **Edit build pipeline** window, edit the required stages and select **Update Pipeline**.
+
+ 
+
+---
+
+## Deleting CI Pipeline
+
+Before deleting a CI pipeline, make sure that there is no CD pipeline attached to it in your workflow. In that case, you must first delete the CD pipeline, and only then you can delete a CI pipeline.
+
+To delete a CI pipeline, follow the steps below.
+
+1. Navigate to **Configurations** (tab) → **Workflow Editor** and click the pipeline you wish to delete.
+
+ 
+
+
+2. Click on the Deployment Stage, **Edit deployment pipeline** window will open and select **Delete Pipeline**.
+
+ 
+
+3. A pop-up will appear asking you to enter the environment name of the deployment.
+
+4. Enter the environment name and select **Delete**. The CD pipeline will be deleted.
+
+ 
+
+ In case there are multiple CD pipelines in the workflow, then you need to delete them individually in a similar way.
+
+5. After deleting all CD pipelines, click the Build stage, and the **Edit build pipeline** window will open.
+
+ 
+
+6. Select **Delete Pipeline** from the bottom left corner of the window button in the Build stage, a pop-up will appear prompting you to delete the CI pipeline.
+
+ 
+
+ In case your build pipeline is linked to another pipeline through **Linked Build Pipeline**, then you must first delete the linked pipeline in order to delete your pipeline.
+
+7. Select **Delete** and the CI pipeline will be deleted along with its workflow.
+
+ 
+
+---
+
+## Extras
+
+### Changing Image Source
+
+The **Change Image Source** feature in Devtron lets you update the container image source for an application’s workflow without modifying it.
+
+1. In the **Configurations** tab of your application, hover over the intended workflow name and click **Change Image Source** icon.
+
+ 
+
+ 
+
+2. Select the intended workflow template and enter the details required as per the selected workflow template. Refer [Types of workflow templates](../workflow/README.md#types-of-ci-pipelines) to learn more.
+
+### Docker Layer Caching
+
+:::caution Prerequisite
+[Configure blob storage](../../../setup/install/installation-configuration.md#configuration-of-blob-storage) if you wish to store cache.
+:::
+
+If you are rebuilding the same Docker image frequently, an effective cache strategy can cut down build time. Docker images are built layer by layer, and [Docker’s layer caching mechanism](https://docs.docker.com/build/cache/) allows unchanged layers to be reused across pipeline runs.
+
+You can disable caching if:
+* It’s not relevant to your workflow
+* It consumes unnecessary storage
+* The pipeline doesn’t perform an actual Docker build
+
+:::info Which cache gets impacted?
+If a PVC with cache is attached, it will not be impacted by disabling cache. Only the remote cache is disabled.
+:::
+
+There are 3 places from where you can control the cache behavior:
+
+* [Orchestrator ConfigMap (Global Settings)](#1-orchestrator-configmap-global-settings)
+
+* [Editing Pipeline](#2-editing-pipeline)
+
+* [During Trigger](#3-during-trigger)
+
+#### 1. Orchestrator ConfigMap (Global Settings)
+
+Super-admins can define the cache settings in `orchestrator-cm` globally for all applications and jobs using the following flags:
+
+``` shell
+DEFAULT_CACHE_FOR_CI_BUILD # for main application build stage
+DEFAULT_CACHE_FOR_CI_JOB # for CI jobs
+DEFAULT_CACHE_FOR_JOB # for general jobs
+DEFAULT_CACHE_FOR_CD_PRE # for pre-deployment stage
+DEFAULT_CACHE_FOR_CD_POST # for post-deployment stage
+```
+
+
+
+#### 2. Editing Pipeline
+
+Go to **Workflow Editor** → **Edit Build Pipeline** (Build Stage) → **Docker Layer Caching** (toggle) → **Use remote cache** (checkbox)
+
+By default, your build pipeline will inherit the Global Settings. However, you can use the toggle button to override it and decide the caching behavior using the **Use remote cache** checkbox. In other words, cache behavior defined in the pipeline configuration will have higher priority than the global one.
+
+
+
+#### 3. During Trigger
+
+Go to **Build & Deploy** (tab) → **Select Material** → **Ignore Cache** (checkbox)
+
+You have the option to ignore cache while triggering a build (regardless of the cache settings defined at the pipeline or global level).
+
+
+
+:::caution Note
+If the caching flags in **Global Settings** are set to false, ignoring cache becomes the default behavior even if you don't select the 'Ignore Cache' checkbox during trigger.
+:::
+
+### Override Build Configuration
+
+**Override Options** in **Build Stage** lets you override **Build Configurations** for each workflow of the same application. You can configure overrides in the build stage of each workflow.
+
+For example, you might want to push development or testing builds to a separate registry from production builds, but in **Build Configurations** you have configured the production container registry to push build images. This means for all the workflows (testing or production), build images will be pushed to the production container registry by default.
+
+To override this Build configuration for the specific workflow (testing workflow), you can use **Override Options** in the **Build Stage** of that workflow that lets you specify different container registries, how to build container images, and target platforms for different workflows of the same application. This means the images built for testing environment can be included to the testing registry and the images for production environment can be included to the production registry. This helps keep environments isolated, improves deployment safety, and makes managing multiple environments easier.
+
+#### Creating Build Configuration Override
+
+To override a container registry, container image, or target platform:
+
+1. Go to **Applications** and select your application from the **Devtron Apps** tabs.
+
+2. On the **App Configuration** tab, select **Workflow Editor**.
+
+3. Select the build pipeline of your application.
+
+ 
+
+4. Click **Allow Override** in the **Build Stage**:
+
+ * Select the new container registry from the drop-down list.
+
+ * [Create and build the new container image](../../creating-application/docker-build-configuration.md#build-the-container-image) with different options.
+
+ * Set a [new target platform](../../creating-application/docker-build-configuration.md#set-target-platform-for-the-build) from the drop-down list or enter a new target platform.
+
+ 
+
+5. Select **Update Pipeline**, The override will be effective when the next build is triggered.
+
+The overridden container registry/container image location/target platform will be reflected on the [Build Configuration](../../creating-application/docker-build-configuration.md) page. You can also see the number of build pipelines for which the container registry/container image location/target platform are overridden.
+
+ 
+
+### Configuring Webhook
+
+:::info
+If you choose **Pull Request** or **Tag Creation** as the **Source Type**, you must first configure the Webhook for GitHub/Bitbucket as a prerequisite step.
+:::
+
+#### For GitHub
+
+1. Go to **Settings** → **Webhooks** of your repository.
+
+ 
+
+ 
+
+2. Select **Add webhook**.
+
+ 
+
+3. In the **Payload URL** field, enter the Webhook URL that you get on selecting the source type as "Pull Request" or "Tag Creation" in Devtron the dashboard.
+
+4. Select the Content-type as `application/json`.
+
+5. In the **Secret** field, enter the secret from Devtron the dashboard when you select the source type as "Pull Request" or "Tag Creation".
+
+6. Under **Which events would you like to trigger this webhook?**, select **Let me select individual events** to trigger the webhook for specific events.
+
+ 
+
+7. Select the appropriate triggers
+
+ * For Pull Requests, select **Pull Requests**.
+
+ 
+
+ * For Tag Creation, select **Branch or tag creation**.
+
+ 
+
+8. Select **Add webhook**.
+
+ 
+
+#### For GitLab
+
+1. Navigate to **Setting** → **Webhooks** of your repository.
+
+ 
+
+2. Select **Add new webhook**.
+
+ 
+
+3. You can provide a name and description (optional).
+
+4. In the **URL** field, enter the Webhook URL that you get on selecting the source type as "Pull Request" or "Tag Creation" in the Devtron dashboard.
+
+5. In the **Secret token** field, enter the secret from the Devtron dashboard when you select the source type as "Pull Request" or "Tag Creation".
+
+ 
+
+6. Checkmark the appropriate triggers under the **Trigger** section.
+
+ * For Pull Requests, select **Merge request events**.
+
+ 
+
+ * For Tag Creation, select **Tag push events**
+
+ 
+
+7. Select **Add Webhook** and the webhook will be added to your repository.
+
+ 
+
+#### For Bitbucket Cloud
+
+1. Navigate to the **Repository settings** page of your Bitbucket repository.
+
+ 
+
+2. Select **Webhooks** under **Workflow** section and then select **Add webhook**.
+
+ 
+
+ 
+
+3. Enter a **Title** for the webhook.
+
+4. In the **URL** field, enter the Webhook URL that you get on selecting the source type as "Pull Request" or "Tag Creation" in the Devtron dashboard.
+
+5. In the **Secret** field, enter the secret from the Devtron dashboard when you select the source type as "Pull Request" or "Tag Creation".
+
+ 
+
+6. Select the event triggers for which you want to trigger the webhook under the **Triggers** section.
+
+ 
+
+7. Select **Save** to save your configurations.
+
+ 
+
diff --git a/versioned_docs/version-1.7/user-guide/creating-application/workflow/pre-post-tasks.md b/versioned_docs/version-1.7/user-guide/creating-application/workflow/pre-post-tasks.md
new file mode 100755
index 0000000000..55c8075646
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/creating-application/workflow/pre-post-tasks.md
@@ -0,0 +1,409 @@
+---
+id: pre-post-tasks
+title: Pre/Post Stages
+sidebar_label: Pre/Post Stages
+---
+
+# Pre/Post Stages
+
+The build and deployment pipelines also include a pre stage and a post stage:
+
+* **Pre Stage** - Tasks to be executed before the build/deployment pipeline triggers.
+* **Post Stage** - Tasks to be executed only after the successful execution of the build/deployment pipeline.
+
+**Examples**: Tasks like code analysis, Jira Issue updation, load testing, security scanning, etc.
+
+* **Build Stage** includes **Pre-build stage** and **Post-build stage**.
+* **Deployment Stage** includes **Pre-deployment** and **Post-deployment**.
+
+In Devtron, a task is a step within a CI/CD pipeline that runs a specific operation, such as executing a script or running a container image. Tasks can be created using preset plugins or custom scripts, and are executed in sequence to complete the process.
+
+Preset plugins are extensions that allow you to enhance and refine the CI/CD workflow of your application by adding new features, integrating with external tools, and automating tasks. Unlike custom scripts, preset plugins come bundled with specific variables and conditions that help you make the plugins work seamlessly with your CI/CD pipeline.
+
+Some plugins are specific to build pipelines (used in **Pre-Build** and **Post-Build** stages), and some plugins are specific to deployment pipelines (used in **Pre-Deployment** and **Post-Deployment** stages), and some plugins are versatile and can be used in both build and deployment pipelines, depending on your use case.
+
+---
+
+## Before you begin
+
+Before you start adding Pre or Post tasks, make sure you have already setup your [Build pipeline](./ci-pipeline.md) or [Deployment pipeline](./cd-pipeline.md).
+
+---
+
+## Creating Pre/Post Tasks
+
+Each Pre/Post task in the build or deployment stage is executed as a series of events called tasks and includes custom scripts.
+
+You can create one or more tasks. Tasks can be dependent on each other for execution. In other words, the output variable of one task can be used as an input for the next task. Tasks will execute in the order they are arranged and can be rearranged by drag-and-drop; however, the order of passing the variables must be followed.
+
+You can create a task either by selecting one of the available preset plugins or by creating a custom script.
+
+To create a pre/post task, follow the steps below:
+
+1. Navigate to **Configurations** (tab) → **Workflow Editor** of your Devtron App.
+
+2. Select the Build or Deployment pipeline for configuring the pre/post tasks.
+
+ 
+
+3. Based on the pipeline you are editing, follow the steps below to add a task:
+
+ * **Build pipelines:** On the **Edit build pipeline** window, select the **Pre-Build stage** or **Post-Build stage** tab.
+
+ 
+
+ * **Deployment pipelines:** On the **Edit deployment pipeline** window, select the **Pre-Deployment stage** or **Post-Deployment stage** tab.
+
+ 
+
+4. Select **+ Add task** to add a task.
+
+ 
+
+5. Configure the task using a preset plugin or **Execute custom task**. If you wish, you can add more tasks by clicking on **+ Add task** in the left-side panel.
+
+ 
+
+6. Click **Update Pipeline**. The pre/post task will be executed when you trigger the next build or deployment.
+
+ 
+
+### Configure a Task using Preset Plugins
+
+In Devtron, preset plugins are pre-defined tasks templates that helps you automate and execute common operations such as provisioning infrastructure, taking backups, exporting container images etc., without writing custom scripts.
+
+Devtron provides a set of built-in preset plugins, and you can also create your own plugins in Devtron according to your specific needs.
+
+Let's take `Codacy` as an example and configure it in the Pre-Build stage in the CI pipeline for finding bugs, detecting dependency vulnerabilities, and enforcing code standards
+
+To create a task using preset plugins, let's take `Codacy` as an example and configure it in the **Pre-Build stage** in the build pipeline for finding bugs, detecting dependency vulnerabilities, and enforcing code standards.
+
+To configure a task using the **Codacy** plugin, follow the steps below:
+
+1. Navigate to **Pre-Build stage** and select **+Add task**.
+
+2. Search for `Codacy` in the **Search Plugin** bar and select **Codacy** from the list of plugins.
+
+ * The right-side panel will display the fields specific to the **Codacy** plugin, which are required to be configured.
+
+ * The left-side panel will now shows a task under **Tasks (IN ORDER OF EXECUTION)**, named after the selected plugin(by default), along with its logo. You can change the task's name using the **Task name** field but plugin's logo will remain indicating that it is a preset plugin.
+
+ 
+
+ 
+
+3. Refer the [Codacy](../../plugins/codacy.md) documentation to configure the **Codacy** fields with appropriate values. You may explore [Plugins documentation](../../plugins/README.md) to configure any of the available plugins.
+
+4. After configuring the fields successfully, your task will be created. If you wish, you can add more tasks by clicking on **+ Add task** in the left-side panel.
+
+5. Select **Update pipeline**; The pre/post task will be executed when you trigger the next build or deployment.
+
+Similarly, you can configure any task with a preset plugin in Pre/post-build stages or pre/post-deployment stages.
+
+### Execute Custom Task
+
+1. After adding the task, select **Execute custom task**.
+
+
+ * The right-side panel will display the fields that are required to be configured in order to create the task.
+
+ * The left-side panel will now display a task under **Tasks (IN ORDER OF EXECUTION)**.
+
+ 
+
+2. Enter the Task name (required) and Task Description (optional).
+
+ 
+
+3. Select the **Task type**, it can be `Shell` or `Container Image`.
+
+ * **Shell Tasks**: These execute shell scripts directly within the application runtime environment. In this type of task, you can define inline scripts or use script files from your configured source code.
+
+ * **Container Image Tasks**: These allow you to execute commands and scripts inside a custom Docker container. Instead of using the default environment provided by Devtron, you can specify your own container image with all dependencies and tools required for the tasks. These Tasks run using container in container approach, which means the specified image is pulled and run inside the App pod, thus providing a completely isolated environment.
+
+4. After selecting the **Task type**, you need to configure task-specific fields based on that **Task type**. Refer the [Examples and Use cases](#examples-and-use-cases) to configure both **Shell type** and **Container image** tasks.
+
+### Examples and Use Cases
+
+#### Example 1 - Shell Task (Post-Build)
+
+Let's take an example of a **Shell task** in the Post-Build stage, that send an email notification immediately after the build stage is completed.
+
+#### Tasks Configurations
+
+|Field| Values for This Example| Required/Optional | Description|
+| :--- | :--- | :--- | :--- |
+| `Task Name`| `email-notifier`| Required| Enter a name for the task|
+| `Task Description`| `This task sends a email after the build is completed` | Optional | Short description for the task|
+| `Task Type` | `Shell`| Optional| Select the preferred task type |
+| `Script`| Refer the [Script](#script) below| Required| Custom script for executing tasks|
+
+#### Prerequisites
+Make sure to create an App password for the sender's email account to use in the script below. Refer the below video to learn how to create an App password for GMAIL accounts
+
+
+
+#### Script
+
+```bash title="Custom Script" showLineNumbers
+!/bin/bash
+
+# SMTP server settings for Gmail
+SMTP_SERVER="smtp.gmail.com"
+SMTP_PORT="587"
+SMTP_USERNAME="docs@devtron.ai" # Enter the sender's email
+SMTP_PASSWORD="xxxx-xxxx-xxxx-xxxx" # Replace with 16-character App Password of Gmail
+
+# Recipient email address
+TO="abc@gmail.com"
+
+# Email subject and body
+SUBJECT="Build is completed"
+BODY="Build Stage is successfully completed."
+
+# Construct the email message
+MESSAGE="Subject: $SUBJECT\n\n$BODY"
+
+# Send the email using Curl
+curl --url "smtp://$SMTP_SERVER:$SMTP_PORT" \
+ --ssl-reqd \
+ --mail-from "$SMTP_USERNAME" \
+ --mail-rcpt "$TO" \
+ --user "$SMTP_USERNAME:$SMTP_PASSWORD" \
+ --tlsv1.2 \
+ -T <(echo -e "$MESSAGE")
+
+echo "Email sent to $TO"
+```
+
+
+After the build stage is completes, this task will sends an email to notify you that the build stage is completed.
+
+#### Example 2 - Shell Task (Pre-Build)
+
+Let's take an example of a **Shell task** in the Pre-Build stage that ensures the database configured is prod-db. If the configured database is anything else, the build should stop.
+
+#### Tasks Configurations
+
+
+
+
+
+|Field| Values for This Example| Required/Optional | Description|
+| :--- | :--- | :--- | :--- |
+| `Task Name`| `check-db-name`| Required| Enter a name for the task|
+| `Task Description`| `This task stops the build if the database name is not 'prod-db'` | Optional | Short description for the task|
+| `Task Type` | `Shell`| Optional| Select the preferred task type |
+| `Input variables`| Refer the [Input Variable table](#input-variable-table) below | Optional|
These variables provide dynamic values to the script at the time of execution and are defined directly in the UI.
Variable name: Alphanumeric chars and (_) only
Source or input value: The variable's value can be global, output from the previous task, or a custom value. Accepted data types include: STRING
|
+| `Trigger/Skip condition` | Not required for this example | Optional| A conditional statement to execute or skip the task|
+| `Script`| Refer the [Script](#script-1) below| Required| Custom script for executing tasks|
+| `Output directory path` | Not required for this example | Optional| Directory path where output files such as logs, errors, etc. will be available after the execution.|
+| `Output variables`| Refer to the [output variable](#output-variables) table| Optional|
Output variables store the output as variables, and these variables can be used as input variables for the next task.
[Pass/Failure Condition](#passfail-condition) (Optional): Conditional statements to determine the success/failure of the task. A failed condition stops the execution of the next task and/or build process
|
+
+#### Input Variable Table
+
+ | Variable|Type| Value| Description|
+ | :--- | :--- | :--- | :--- |
+ | `DB_NAME`| String | `prod-db`| Name of the database to be backed up|
+
+* To add an input variable, click **+ Add Variable** next to the **Input Variable**, a new table appears asking you to enter the variable and its required information.
+
+* You can click `+` icon next to **Variable** header field to add more rows to the input variable table.
+
+ 
+
+* You can click the slider icon next to each variable name to make its value required and add a description for it.
+
+ 
+
+* You can click the slider icon next to each variable value to add choices, allow custom input, and ask value at runtime.
+
+ 
+
+#### Script
+
+```bash title="Custom Script" showLineNumbers
+#!/bin/sh
+set -eo pipefail
+#set -v ## uncomment this to debug the script
+
+if [ "$DB_NAME" = "prod-db" ]; then
+ export DB_VALIDATION=pass
+ echo $DB_VALIDATION
+ echo "Using valid database: $DB_NAME"
+else
+ export DB_VALIDATION=fail
+ echo $DB_VALIDATION
+ echo "Unsupported DB: $DB_NAME. Only 'prod-db' is allowed for this build."
+fi
+```
+
+
+#### Output Variables
+
+| Variable | Type | Description |
+| ------------------ | ------ | --------------------------------------------------- |
+| `DB_VALIDATION` | String | Indicates whether the DB is valid (pass or fail) |
+
+#### Pass/Fail Condition
+
+PASS If: `DB_VALIDATION == pass`
+
+After adding this database validation task, you can add more tasks as well, for example, you can add a follow-up Pre-Build task that runs only if the database is valid.
+
+#### Example 3 - Container Image Task
+
+Let's take an example of a **Container Image Task** that verify that the configured database is reachable and accepting connections before executing build stage. This ensures that the build does not proceed if the database configuration is incorrect or unreachable, saving time and resources.
+
+Since we have already configured a shell task to validate the database name, we will add this task after the shell task; This means it will execute after the shell task. This container image task will run only if that check passes, to verify that we are connecting to the correct database and that it is reachable before the build starts.
+
+#### Tasks Configurations
+
+
+
+
+
+| Field| Values for This Example| Required/Optional | Description|
+| :---|:---|:---|:---|
+| `Task name`| `verify-db-connectivity`| Required|Enter a name for the task|
+| `Description`| Verify DB connection before build | Optional| A descriptive message for the task|
+| `Task type`| `Container Image`| Optional| Allows you to execute commands and scripts inside a custom Docker container|
+| `Input variables`| Refer the [Input Variable table](#input-variable-table-1) below | Optional|
These variables provide dynamic values to the script and are defined directly in the UI.
Variable name: Alphanumeric chars and (_) only
Source or input value: The variable's value can be global, output from the previous task, or a custom value. Accepted data types include: STRING
|
+| `Trigger/Skip condition`| `DB_VALIDATION == pass`| Optional| Execute or skip the task based on the condition provided.|
+| `Container image`| `mysql:8.0`| Required| Select an image from the drop-down list or enter a custom value in the format `:`|
+| `Mount custom code`| Refer below [Mount custom code](#mount-custom-code) section| Optional|
Enable to mount the custom code in the container. Enter the script in the box below.
**Mount above code at** (required): Path where the code should be mounted, eg, `/scripts`
|
+| `Command`| `sh`| Optional|Mention commands to execute inside the container|
+| `Args`| `/scripts/check-db.sh`| Optional| The arguments to be passed to the command mentioned in the command field|
+| `Port mapping`| `No`| Optional| The port number on which the container listens. The port number exposes the container to outside services.|
+| `Mount code to container`| `yes`| Optional| Mounts the source code (configured git repository) inside the container. The default is "No". If set to "Yes", enter the path where the source should be mounted inside the container.|
+| `Mount directory from host` |`No`| Optional| Mount any directory from the host into the container. This can be used to mount code or even output directories.|
+| `Output directory path`|`No`| Optional| Directory path where output files such as logs, errors, etc. will be available after the execution.|
+
+#### Input Variable Table
+
+| Variable| Type| Value| Description|
+| :--- | :---| :--- | :--- |
+| `DB_NAME`| String | `prod-db`| Name of the database|
+| `DB_HOST` | String | `192.168.1.10` | Database hostname or IP address|
+| `DB_USER` | String | `root` | Database user|
+
+* To add an input variable, click **+ Add Variable** next to the `Input Variable`, a new table appears asking you to enter the variable and its required information.
+
+* You can click `+` icon next to **Variable** header field to add more rows to the input variable table.
+
+ 
+
+* You can click the slider icon next to each variable name to make its value required and add a description for it.
+
+ 
+
+* You can click the slider icon next to each variable value to add choices, allow custom input, and ask value at runtime.
+
+ 
+
+#### Mount Custom Code
+
+```bash title="Custom Script" showLineNumbers
+#!/bin/sh
+set -e
+
+echo "Checking database connectivity to $DB_NAME at $DB_HOST..."
+
+mysql -h "$DB_HOST" -u "$DB_USER" -p"$DB_PASSWORD" -e "SELECT 1;" "$DB_NAME"
+
+if [ $? -eq 0 ]; then
+ echo "DB_CONNECTION=pass"
+ echo "Database connectivity check passed."
+else
+ echo "DB_CONNECTION=fail"
+ echo "Database connectivity check failed."
+ exit 1
+fi
+```
+
+
+**Note:** The examples above demonstrate configuring tasks in the Pre-Build and Post-Build stages; you can add tasks in the Pre-Deployment, and Post-Deployment stages in exactly the same way.
+
+---
+
+## Additional configurations for Pre/Post-Deployment Tasks
+
+Pre/Post-Deployment Tasks have some additional configurations (required and optional) which are not available in Pre/Post build tasks. These configurations are explained below
+
+### Trigger Pre/Post-Deployment Stage
+
+The execution of the Pre/Post-Deployment stages can be set to:
+
+**Automatically (default):**
+
+ * Pre-deployment stage will trigger automatically when the build image is available.
+ * Post-deployment stage will trigger automatically after the successful deployment.
+
+**Manually:** The User needs to trigger the Pre/Post-Deployment stages manually.
+
+ 
+
+### ConfigMaps & Secrets
+
+:::info Prerequisites
+Make sure you have added [ConfigMaps](../base-config/config-maps.md) and [Secrets](../base-config/secrets.md) in App Configuration.
+:::
+
+If you want to use some configuration files and secrets in pre-deployment stages or post-deployment stages, then you can use the `ConfigMaps` & `Secrets` options. You will get them as a drop-down in the pre-deployment stage.
+
+
+
+### Execute tasks in an application environment
+
+These `Pre-deployment CD / Post-deployment CD` pods can be created in your deployment cluster or the Devtron build cluster. If your scripts/tasks has some dependency on the deployment environment, you may run these pods in the deployment cluster. Thus, your scripts \(if any\) can interact with the cluster services that may not be publicly exposed.
+
+Some tasks require extra permissions for the node where Devtron is installed. However, if the node already has the necessary permissions for deploying applications, there is no need to assign them again. Instead, you can enable the **Execute tasks in application environment** option for the pre-CD or post-CD steps. By default, this option is disabled.
+
+
+
+To enable the `Execute tasks in application environment` option, follow these steps:
+
+1. Go to the **Chart Store** and search for the `devtron-in-clustercd` chart.
+
+ 
+
+2. Configure the chart according to your requirements and deploy it in the target cluster.
+
+3. After the deployment, edit the devtron-cm configmap and add the following key-value pair:
+
+ ```bash
+ ORCH_HOST: /orchestrator/webhook/msg/nats
+
+ Example:
+
+ ORCH_HOST: http://xyz.devtron.com/orchestrator/webhook/msg/nats
+
+ ```
+
+ `ORCH_HOST` value should be the same as of `CD_EXTERNAL_LISTENER_URL` value, which is passed in values.yaml.
+
+ 
+
+4. Delete the Devtron pod using the following command:
+
+ ```bash
+ kubectl delete pod -l app=devtron -n devtroncd
+ ```
+
+5. Again, navigate to the chart store and search for the "migration-incluster-cd" chart.
+
+ 
+
+6. Edit the `cluster-name` and `secret name` values within the chart. The `cluster name` refers to the name used when adding the cluster in the global configuration and for which you are going to enable `Execute tasks in application environment` option.
+
+ 
+
+7. Deploy the chart in any environment within the Devtron cluster. Now you should be able to enable the `Execute tasks in application environment` option for an environment of target cluster.
+
+---
+
+## What's next
+
+* Trigger the [CI pipeline](../../deploying-application/triggering-ci.md)
+
+* Trigger the [CD pipeline](../../deploying-application/triggering-cd.md)
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/debugging-deployment-and-monitoring.md b/versioned_docs/version-1.7/user-guide/debugging-deployment-and-monitoring.md
new file mode 100755
index 0000000000..f4d708a19f
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/debugging-deployment-and-monitoring.md
@@ -0,0 +1,69 @@
+---
+id: debugging-deployment-and-monitoring
+title: Debugging Deployment And Monitoring
+sidebar_label: Debugging Deployment And Monitoring
+---
+
+# Debugging Deployment And Monitoring
+
+If the deployment of your application is not successful, then debugging needs to be done to check the cause of the error.
+
+This can be done through `App Details` section which you can access in the following way:-
+
+Applications->AppName->App Details
+
+Over here, you can see the status of the app as Healthy. If there are some errors with deployment then the status would not be in a Healthy state.
+
+### Events
+
+
+
+Events of the application are accessible from the bottom left corner.
+
+Events section displays you the events that took place during the deployment of an app. These events are available until 15 minutes of deployment of the application.
+
+### Logs
+
+
+
+Logs contain the logs of the Pods and Containers deployed which you can use for the process of debugging.
+
+### Manifest
+
+
+
+The Manifest shows the critical information such as Container-image, restartCount, state, phase, podIP, startTime etc. and status of the pods deployed.
+
+### Deleting Pods
+
+
+
+You might run into a situation where you need to delete Pods. You may need to bounce or restart a pod.
+
+Deleting a Pod is not an irksome task, it can simply be deleted by Clicking on `Delete Pod`.
+
+Suppose you want to setup a new environment, you can delete a pod and thereafter a new pod will be created automatically depending upon the replica count.
+
+### Application Objects
+
+You can view `Application Objects` in this section of `App Details`, such as:
+
+| Key | Description |
+| :----------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Workloads` | _ReplicaSet_\(ensures how many replica of pod should be running\), _Status of Pod_\(status of the Pod\) |
+| `Networking` | _Service_\(an abstraction which defines a logical set of Pods\), _Endpoints_\(names of the endpoints that implement a Service\), _Ingress_\(API object that manages external access to the services in a cluster\) |
+| `Config & Storage` | _ConfigMap_\( API object used to store non-confidential data in key-value pairs\) |
+| `Custom Resource` | _Rollout_\(new Pods will be scheduled on Nodes with available resources\), _ServiceMonitor_\(specifies how groups of services should be monitored\) |
+
+
+
+
+## Monitoring
+
+
+
+You can monitor the application in the `App Details` section.
+
+Metrics like `CPU Usage`, `Memory Usage`, `Throughput` and `Latency` can be viewed here.
+
+Refer [Application Metrics](./creating-application/app-metrics.md) to know the process of enabling them.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/deleting-application.md b/versioned_docs/version-1.7/user-guide/deleting-application.md
new file mode 100755
index 0000000000..8ee6769f86
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/deleting-application.md
@@ -0,0 +1,32 @@
+---
+id: deleting-application
+title: Deleting Application
+sidebar_label: Deleting Application
+hide_table_of_contents: true
+---
+
+# Deleting Application
+
+Delete the Application, when you are sure you no longer need it.
+
+Clicking on `Delete Application` will not delete your application if you have workflows in the application.
+
+If your Application contains workflows in the Workflow Editor. So, when you click on `Delete Application`, you will see the following prompt.
+
+
+
+Click on `View Workflows` to view and delete your workflows in the application.
+
+To delete the workflows in your application, you must first delete all the pipelines \(CD Pipeline, CI Pipeline or Linked CI Pipeline or External CI Pipeline if there are any\).
+
+
+
+After you have deleted all the pipelines in the workflow, you can delete that particular workflow.
+
+Similarly, delete all the workflows in the application.
+
+
+
+
+Now, Click on `Delete Application` to delete the application.
+
diff --git a/versioned_docs/version-1.7/user-guide/deploy-chart/README.md b/versioned_docs/version-1.7/user-guide/deploy-chart/README.md
new file mode 100755
index 0000000000..a2e78addab
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/deploy-chart/README.md
@@ -0,0 +1,77 @@
+---
+id: README
+title: Chart Store
+sidebar_label: Chart Store
+---
+
+# Chart Store
+
+## Introduction
+
+A [Helm Chart](../../reference/glossary.md#helm-chartspackages) is like a blueprint for deploying your application on Kubernetes. It contains all the necessary configuration files needed to define what and how your application should run. The **Chart Store** in Devtron offers a wide variety of helm charts from different sources for you to select and install based on your requirement. It helps you in managing and organizing charts in the same way an app store helps you manage apps.
+
+Navigate to the **Chart Store**.
+
+
+
+---
+
+## Fetch and Populate Charts
+
+The **Chart Store** populates charts from two sources:
+
+* The chart repositories added to the [Chart Repository](../global-configurations/chart-repo.md) section of the **Global Configurations** page.
+
+* The OCI registry (only if **Use as chart repository** checkbox is enabled) added to the [Container/OCI Registry](../global-configurations/container-registries.md) section of the **Global Configurations** page.
+
+
+
+When you add a chart repository and/or an OCI registry, the sources along with the associated charts are automatically populated in the **Chart Store**. The chart sources are displayed in the **Chart Source** drop-down box, and the charts are displayed in the **All Charts** section.
+
+---
+
+## Add a Chart Source
+
+:::caution Who Can Perform This Action?
+Only a [Super Admin](../global-configurations/user-access.md#assign-super-admin-permissions) can add a chart source. The **Source** button in the **Chart Store** page is visible only to Super Admins.
+
+:::
+
+To add a chart repository or an OCI registry as a chart source, follow the instructions below:
+
+1. Navigate to **Chart Store** → **Sources**. The **Helm chart sources** section appears, displaying all helm chart sources.
+
+2. Click the **Add** button.
+
+ 
+
+3. Click on **Add Chart Repository** . It will take you to the [Chart Repositories](../global-configurations/chart-repo.md#add-chart-repository) page in the **Global Configurations** page.
+
+4. Click on **Add OCI Registry**. It will take you to the [Container/OCI Registry](../global-configurations/container-registries.md#add-container-registry) page in the **Global Configurations**.
+
+---
+
+## Search for a Chart
+
+To quickly search for a chart, perform any of the following actions:
+
+* Navigate to the search bar at the top-left corner of the screen. Enter the chart name you're looking for and press Enter. The chart will be displayed in the All Charts section.
+
+ 
+
+* Select your preferred chart source(s) using the checkboxes in the **Chart Source** drop-down box. The charts associated with that chart source will be displayed in the All Charts section.
+
+:::info Unable to Find Your Chart?
+Try performing a resync by clicking the **Resync** button next to each chart source. If the chart is still not displayed, it might be deprecated. Enable the **Show deprecated charts** checkbox in the Filters section. All the deprecated charts will then be displayed in the All Charts section.
+
+:::
+
+---
+
+## Next Steps
+
+Refer to:
+
+* [Deploy Charts](deployment-of-charts.md) - if you need to deploy, update, upgrade, disable, or delete charts.
+
+* [Chart Groups](chart-group.md) - if you need to create a chart group and bulk deploy them.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/deploy-chart/chart-group.md b/versioned_docs/version-1.7/user-guide/deploy-chart/chart-group.md
new file mode 100755
index 0000000000..939d72b456
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/deploy-chart/chart-group.md
@@ -0,0 +1,132 @@
+---
+id: chart-group
+title: Chart Groups
+sidebar_label: Chart Groups
+---
+
+# Chart Groups
+
+## Introduction
+
+A Chart Group in Devtron is a collection of [Helm charts](../../reference/glossary.md#helm-chartspackages) grouped together (e.g., what a folder is to files) to help you create, manage, and deploy them easily.
+
+When setting up a new environment or a microservice, or when your application requires multiple Helm charts, you can simply group the required charts into a chart group. You can then view, manage, and deploy related charts together in one place instead of searching and installing each one individually.
+
+---
+
+## Prerequisites
+
+Ensure the [Build and Deploy (CI/CD)](../../user-guide/integrations/build-and-deploy-ci-cd.md) module is installed in your Devtron instance if you are an OSS user. Enterprise user can skip this step.
+
+---
+
+## Create and Deploy a Chart Group
+
+:::caution Who Can Perform This Action?
+* A user with the **Create** permission enabled for [Chart Groups](../global-configurations/authorization/user-access.md#chart-groups-permissions) can create a chart group. However, they will not be able to deploy it.
+
+* Only a [Super-Admin](../global-configurations/authorization/user-access.md#chart-groups-permissions) can create as well as deploy a chart group.
+
+:::
+
+To create a chart group, follow the instructions below:
+
+1. Navigate to **Chart Store**.
+
+2. Click the **Create Group** button. The **Create Chart Group** page is displayed.
+
+ 
+
+3. Enter your preferred chart group name in the **Name** field.
+
+4. (Optional) Enter the chart group description in the **Description** field.
+
+5. Click **Create Group** button.
+
+6. Select your preferred charts from the list of charts available in the **Edit group** page.
+
+ 
+
+7. Click **Save**. The chart group is now saved.
+
+8. Navigate back to the chart group page.
+
+ 
+
+9. Click on the **Deploy to...** button. The **Deploy Selected Charts** screen is displayed.
+
+ 
+
+10. Select the project in the **Project** drop-down box.
+
+11. Select the environment where you want to deploy the charts in the **Deploy to Environment** drop-down box.
+
+12. Click **Deploy Chart** to deploy the charts. The deployment will be initiated.
+
+ If you prefer to change the chart values in the `.yaml` file or change chart configurations, click **Advanced Options**. Refer to [Advanced Options](#advanced-options) for more information.
+
+ 
+
+---
+
+## Edit a Chart Group
+
+:::caution Who Can Perform This Action?
+* A user with the **Edit** permission for the specific [Chart Group](../global-configurations/authorization/user-access.md#chart-groups-permissions) can edit that chart group.
+
+* A [Super-Admin](../global-configurations/authorization/user-access.md#chart-groups-permissions) can also edit a chart group.
+
+:::
+
+If you want to add/remove a chart to your existing chart group, or change the chart group name, you can edit the chart group. Follow the below instructions to edit a chart group:
+
+1. Select your preferred chart group in the **Chart Store**.
+
+ 
+
+2. Click the **Edit** button. The **Edit group** page is displayed.
+
+3. Add or remove charts based on your needs from the list of charts available in the **Edit group** page.
+
+4. Enter your new chart group name (if required) in the **Group name** field.
+
+5. Click **Save** to save the changes.
+
+---
+
+## Delete a Chart Group
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../global-configurations/authorization/user-access.md#chart-groups-permissions) or a user with the **Create** permission can delete a chart group.
+
+:::
+
+When you delete a chart group, only the chart group is deleted. Application deployed using that chart group remain unaffected. Follow the below instructions to delete a chart group.
+
+1. Select your preferred chart group in the **Chart Store**.
+
+ 
+
+2. Click the **Delete** button. A pop-up window will appear, asking for confirmation to delete the chart group.
+
+---
+
+## Extras
+
+### Advanced Options
+
+The **Advanced Options** page enables you to change the chart values, chart configurations, use preset values (if already configured) for your charts.
+
+
+
+1. Enter your preferred application name in the **App name** field.
+
+2. Select the environment where you want to deploy the charts in the **Deploy to Environment** drop-down box.
+
+3. Select the chart version you'd like to use from the **Chart version** drop-down box.
+
+4. Select the chart values you'd like to use from the **Values** drop-down box. If you want to configure a preset value for your chart, or use a previously configured one, select **Preset values**. Refer to [Preset Values](deployment-of-charts.md#preset-values) for more information.
+
+5. Select the project in the **Project** drop-down box.
+
+6. Click **Deploy** to deploy the charts. The deployment will be initiated.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/deploy-chart/deployment-of-charts.md b/versioned_docs/version-1.7/user-guide/deploy-chart/deployment-of-charts.md
new file mode 100755
index 0000000000..ec86699067
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/deploy-chart/deployment-of-charts.md
@@ -0,0 +1,274 @@
+---
+id: deployment-of-charts
+title: Deploy Charts
+sidebar_label: Deploy Charts
+---
+
+# Deploy Charts
+
+## Introduction
+
+This document helps you deploy, update, upgrade, disable, and delete Helm charts.
+
+---
+
+## Configure and Deploy Charts
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin or an Admin](../global-configurations/authorization/user-access.md#helm-apps-permissions) can configure and deploy charts.
+
+:::
+
+To configure and deploy Helm, follow the instructions below:
+
+1. Navigate to **Chart Store**.
+
+2. Enter your preferred chart name in the search bar at the top-left corner of the screen.
+
+3. Select your preferred chart. The chart page is displayed.
+
+ 
+
+ | Section | Description |
+ | :--- | :--- |
+ | **About** | A short description of the chart|
+ | **README.md** | Contains the instructions, configurations, and everything related to the configuration and deployment of the chart |
+ | **Deployments** | Displays the list of projects under which the chart is deployed |
+
+4. Click **Configure & Deploy**. Configuring a Helm chart gives you the flexibility to customize it to your needs instead of relying on the default values of the chart.
+
+ To predefine configurations and make future deployments across environments easier, refer to [Preset Values](#preset-values).
+
+ 
+
+5. Enter your application name in the **App Name** field.
+
+6. Select your project in the **Project** drop-down box.
+
+7. Select the environment where you want to deploy the chart in the **Deploy to Environment** drop-down box. When you select an environment, the **How do you want to deploy?** section is displayed.
+
+ 
+
+ **How do you want to deploy?**
+
+ | Method | Description |
+ | :--- | :--- |
+ | **Helm** | Select this option if you do not want version tracking for deployments and would like to directly deploy charts into the cluster |
+ | **GitOps (Via Argo CD)** | Select this option if you want Git to track every deployment via Argo CD. As a prerequisite:
The [GitOps (Argo CD)](../../user-guide/integrations/argocd.md) module should be installed in your Devtron instance for this option to be displayed
GitOps should be configured in the Global Configurations page. Refer to [GitOps](../global-configurations/gitops.md) for more information
|
+ | **GitOps (Via Flux CD)** | Select this option if you want Git to track every deployment via Flux CD. As a prerequisite:
The Flux CD controller should be installed in your preferred cluster to deploy using GitOps (Via Flux CD). Refer [Enable GitOps Deployments with FluxCD](../creating-application/fluxcd.md#install-fluxcd-controller-via-cluster-terminal) for more information.
GitOps should be configured in the Global Configurations page. Refer to [GitOps](../global-configurations/gitops.md) for more information.
|
+
+:::caution Note
+The deployment method cannot be changed once the chart is deployed.
+
+:::
+
+8. Select the chart version you prefer to deploy in the **Chart Version** drop-down box.
+
+9. Select the chart values you prefer to use in the **Chart Values** drop-down box. Kindly refer to [Preset Values](#preset-values).
+
+10. Click **Deploy Chart**.
+
+Once you have deployed a chart, you will be redirected automatically to the **App Details** tab where the deployment status is shown.
+
+
+
+The Application Status should be `Healthy`, indicating that the application has been successfully deployed.
+
+---
+
+## Refetch Charts
+
+When you click on **Refetch Charts**, the system fetches the latest Helm charts (e.g., `stable/mySQL`, `bitnami/mySQL`) and their latest available versions (e.g., v1.0, v1.1) that include improvements, features, and fixes. You can then either update a chart version or upgrade the chart itself in your environment.
+
+To check the latest charts and chart versions, follow the instructions below:
+
+1. Navigate to the **Configure** tab of your helm application.
+
+ 
+
+2. Click **Refetch Charts**. All the latest charts are displayed in the **Helm Chart** drop-down box and all the latest versions of a chart will be displayed in the **Chart Version** drop-down box.
+
+---
+
+## Update Charts
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin or an Admin](../global-configurations/authorization/user-access.md#helm-apps-permissions) can update charts.
+
+:::
+
+When you update a Helm chart, the system actually deploys the selected latest version of a chart (e.g., `12.4.2`) in your environment, just like how you'd install the latest version of an app from the app store.
+
+Follow the below instructions to update a Helm chart:
+
+1. Navigate back to the **Configure** tab of your Helm application.
+
+2. Select your preferred chart version from the **Chart Version** drop-down box.
+
+ You can also compare the existing configured values of the previous chart version with the default values of the newer chart version by clicking the **Compare Values** button in the top-right corner of the page.
+
+ 
+
+3. Click **Update And Deploy**.
+
+---
+
+## Upgrade Charts
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin or an Admin](../global-configurations/authorization/user-access.md#helm-apps-permissions) can upgrade charts.
+
+:::
+
+If the chart you're already using is deprecated or for other business reasons you wish to move from one chart to another (e.g., `stable/mySQL` to `bitnami/mySQL`), consider upgrading your charts.
+
+Follow the below instructions to upgrade a Helm chart:
+
+1. Navigate back to the **Configure** tab of your Helm application.
+
+2. Select your preferred chart from the **Helm Chart** drop-down box.
+
+ 
+
+:::info Note
+When you upgrade your helm chart, ensure that the values are compatible with the new chart.
+
+:::
+
+3. Click **Update And Deploy**.
+
+---
+
+## Security Scan
+
+Enabling the **Security scan** toggle scans the image(s) in the chart for vulnerabilities and license risks. To know more about security scan, refer to [Vulnerability Scanning](../plugins/vulnerability-scanning.md).
+
+---
+
+## Disable Chart Source
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../global-configurations/authorization/user-access.md#helm-apps-permissions) can disable a chart source in the Chart Store.
+
+:::
+
+Disabling a Helm chart source (e.g., Bitnami) does not display all associated charts in the Chart Store. When you previously used charts from a particular chart source, but no longer want to use it, you can simply disable the chart source by following the instructions below:
+
+1. Navigate to **Chart Store** → **Source**.
+
+2. Disable the toggle next to your preferred chart source (e.g., Bitnami).
+
+ 
+
+The chart source (e.g., Bitnami) will no longer be displayed in the **Chart Source** drop-down box, and all its associated charts will no longer be displayed in the **All Charts** section of the **Chart Store** page.
+
+You can always enable the chart source again anytime by enabling the toggle next to the chart source.
+
+---
+
+## Delete Chart Source
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../global-configurations/authorization/user-access.md#helm-apps-permissions) can delete a chart source in Devtron.
+
+:::
+
+When you delete a chart source in Devtron, all associated charts will be removed from the Chart Store, and you will no longer be able to view or deploy them. You can consider deleting a chart source when you no longer have any applications running on its charts or when the chart repository is no longer relevant to your business needs.
+
+:::danger Disabling Chart Source vs Deleting Chart Source
+Disabling charts only hides specific chart repositories and their associated charts from appearing on the Chart Store page. They are not removed from Devtron. However, deleting a chart source removes the chart repository or OCI registry from Devtron entirely, along with all its associated charts.
+
+:::
+
+You can delete a chart source in the following two ways:
+
+* [By deleting a chart repository](../global-configurations/chart-repo.md#delete-a-chart-repository)
+
+* [By deleting an OCI registry](../global-configurations/container-registries.md#delete-an-oci-registry)
+
+You cannot disable or delete the default charts provided by Devtron.
+
+---
+
+## Extras
+
+### Preset Values
+
+If you frequently deploy a particular chart, you can then predefine its configurations as a template, making it easier to deploy across environments.
+
+To predefine the configurations for a chart, follow the instructions below:
+
+1. Click the **Preset Values** button.
+
+ 
+
+2. Enter your preferred preset value name in the **Name** field.
+
+ 
+
+3. Select the chart version for which you'd like to create a preset value from the **Chart Version** drop-down box.
+
+4. Edit the chart values as per your needs.
+
+5. Click on the **Save Value** button.
+
+A preset value for the selected chart version is now created and will be displayed in the **Chart Values** drop-down box whenever you wish to deploy the same chart again.
+
+---
+
+## Example
+
+### Deploying mySQL Helm Chart
+
+#### Discover the mySQL Helm Chart in Chart Store
+
+1. Navigate to **Chart Store**.
+
+ 
+
+2. Enter `mySQL` in the search bar at the top-left corner of the **Chart Store** page.
+
+3. Select `bitnami/mySQL` from the list of available charts.
+
+#### Configure and Deploy the Chart
+
+Once you have clicked on the `bitnami/mySQL`, follow the set of instructions below:
+
+1. Read the **README.md** file to know more about the chart configurations.
+
+ 
+
+2. Refer to the tables below and fill in the details:
+
+ 
+
+ | Key | Description |
+ | :--- | :--- |
+ | **App Name** | Enter the name of your application |
+ | **Project** | Select your project |
+ | **Environment** | Select the environment where you want to deploy the chart |
+ | **Chart Version** | Select the chart version you prefer to deploy |
+ | **Chart Value** | Select the chart value you prefer to use. Kindly refer to [Preset Values](#preset-values) |
+
+ | Parameters | Description |
+ | :--- | :--- |
+ | `mysqlRootPassword` | Password for the root user. Ignored if existing secret is provided |
+ | `mysqlDatabase` | Name of your MySQL database |
+ | `mysqluser` | Username of new user to create |
+ | `mysqlPassword` | Password for the new user. Ignored if existing secret is provided |
+
+3. Click **Deploy Chart** to deploy the chart.
+
+#### Check the Deployment Status
+
+When you deploy the chart, you will be redirected to the **App Details** tab of the Helm application.
+
+
+
+The **Application Status** should be `Healthy`, indicating that the application has been successfully deployed.
+
+#### Extract the Service Name
+
+Service names makes it easier to find, connect to, and interact with your application. To extract the service name, navigate to **K8s Resources** → **Networking** → **Service**. The service name(s) are displayed in the **Name** column along with the URL in the **URL** column.
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/deploy-sample-app/nodejs_app.md b/versioned_docs/version-1.7/user-guide/deploy-sample-app/nodejs_app.md
new file mode 100755
index 0000000000..482991474e
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/deploy-sample-app/nodejs_app.md
@@ -0,0 +1,18 @@
+---
+id: nodejs_app
+title: Let's deploy a sample App
+sidebar_label: Let's deploy a sample App
+---
+
+# Let's deploy a sample App
+
+Hurray!
+Your Devtron stack is completely setup. Let's get started by deploying a simple application on it.
+
+
+
+## Find out the steps here
+
+This is a sample Nodejs application which we are going to deploy using Devtron. For a detailed step-wise procedure, please have a look at the link below -
+
+[Getting Started with Deploying application through devtron](https://github.com/devtron-labs/getting-started-nodejs#getting-started-with-deploying-application-through-devtron)
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/deploying-application/README.md b/versioned_docs/version-1.7/user-guide/deploying-application/README.md
new file mode 100755
index 0000000000..4356163c50
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/deploying-application/README.md
@@ -0,0 +1,19 @@
+---
+id: README
+title: Deploying Application
+sidebar_label: Deploying Application
+hide_table_of_contents: true
+---
+
+# Deploying Application
+
+Each time you push a change to your application through GitHub, your application goes through a process to be built and deployed.
+
+There are two main steps for building and deploying applications:
+
+* [Triggering CI](triggering-ci.md)
+
+* [Triggering CD](triggering-cd.md)
+
+You can also rollback the deployment. Refer [Rollback Deployment](rollback-deployment.md) for detail.
+
diff --git a/versioned_docs/version-1.7/user-guide/deploying-application/image-labels-and-comments.md b/versioned_docs/version-1.7/user-guide/deploying-application/image-labels-and-comments.md
new file mode 100755
index 0000000000..97f7c5ad31
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/deploying-application/image-labels-and-comments.md
@@ -0,0 +1,117 @@
+---
+id: image-labels-and-comments
+title: Applying Labels and Comments
+sidebar_label: Applying Labels and Comments
+---
+
+# Applying Labels and Comments
+
+## Introduction
+
+Typically in a CI pipeline, you [build container images](./triggering-ci.md), and the number of images gradually increases over a period of time. Devtron's image labels and comments feature helps you to mark and recall specific images from the repository by allowing you to add special instructions or notes to them.
+
+For example:
+* You can label an image as `non-prod` to indicate that it is meant for 'Dev' or 'QA' environments, but not for production.
+* Add `hotfix image only` label to indicate a one-time patch on production.
+* Comments like `This image is buggy and shouldn't be used for deployment` to caution other users from deploying an unwanted image.
+
+
+
+Such labels and comments will be visible only within Devtron, and will not propagate to your [container registry](../../reference/glossary.md#containeroci-registry) (say Docker Hub), unlike custom image tag pattern. You may use it to simplify the management and [selection of container images](./triggering-cd.md#deploying-approved-image) for deployment.
+
+:::caution
+Tagging labels and comments are supported only for images in workflows with at least one production deployment pipeline. In Devtron, you can go to **Global Configurations** → **Clusters & Environments** to identify a production environment by checking the 'Prod' label.
+:::
+
+---
+
+## Adding Labels & Comments
+
+:::caution Who Can Perform This Action?
+Users need to have [Build & deploy permission](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and application) to add labels and comments.
+:::
+
+You can add labels and comments from the following pages:
+
+* [From Build & Deploy](#from-build--deploy)
+* [From Build History](#from-build-history)
+* [From Deployment History](#from-deployment-history) (only after deployment)
+* [From App Details](#from-app-details) (only after deployment)
+
+:::caution
+You can add multiple labels to an image. but each label can be used only once 'per image, per application'. You may use it in an image of other application though.
+Refer [Deleting Labels](#deleting-labels--comments) if you commit a mistake while adding labels.
+:::
+
+### From Build & Deploy
+
+
+
+### From Build History
+
+
+
+### From Deployment History
+
+
+
+### From App Details
+
+
+
+---
+
+## Deleting Labels & Comments
+
+### Soft-Delete Labels
+
+:::caution Who Can Perform This Action?
+Users need to have [Build & deploy permission](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and application) to perform soft deletion of labels.
+:::
+
+This action marks the label as invalid but doesn't delete the label. Therefore, you can recover it again but you cannot reuse it for other image (unless it's a different application).
+
+1. Click the edit option.
+2. Use the (-) icon to strike off the label. This icon is available on the left-side of a label.
+3. Click **Save**.
+
+
+
+### Hard-Delete Labels
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to perform hard deletion of labels.
+:::
+
+This action deletes the label permanently and makes it available for reuse in same/other image of the given application.
+
+1. Click the edit option.
+2. Use the (x) icon to permanently remove the label. This icon is available on the right-side of a label.
+3. Click **Save**.
+
+
+
+### Removing Comments
+
+:::caution Who Can Perform This Action?
+Users need to have [Build & deploy permission](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and application) to remove comments.
+:::
+
+If you wish to permanently remove a comment, do the following:
+
+1. Click the edit option.
+2. Empty the content of an existing comment.
+3. Click **Save**.
+
+
+
+---
+
+## Extra Use Case
+
+If you use [Application Groups](../application-groups.md) to deploy in bulk, image labels (if added) will be available as filters for you to quickly locate the container image.
+
+
+
+This will be helpful in scenarios (say release package) where you wish to deploy multiple applications at once, and you have already labelled the intended images of the respective applications.
+
diff --git a/versioned_docs/version-1.7/user-guide/deploying-application/rollback-deployment.md b/versioned_docs/version-1.7/user-guide/deploying-application/rollback-deployment.md
new file mode 100755
index 0000000000..c7d35b47a3
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/deploying-application/rollback-deployment.md
@@ -0,0 +1,59 @@
+---
+id: rollback-deployment
+title: Rollback Deployment
+sidebar_label: Rollback Deployment
+hide_table_of_contents: true
+---
+
+# Rollback Deployment
+
+
+Deployments can be rolled back manually. After a deployment is completed, you can manually rollback to a previously deployed image by retaining the same configuration or changing the configuration.
+
+**As an example**, You have deployed four different releases as follows:
+
+| Image | Configuration | Release |
+| --- | --- | --- |
+| V1 | C1 | R1 |
+| V2 | C2 | R2 |
+| V3 | C2 | R3 |
+| V3 | C3 | R4 |
+| V3 | C4 (saved but not deployed)| - |
+
+If you want to roll back from V3 image to V2 image, then you have the following options:
+
+| Configuration Option | Image | Configuration |
+| --- | --- | --- |
+| Config deployed with selected image | V2 | C2 |
+| Last deployed config | V2 | C3 |
+| Last saved config | V2 | C4 |
+
+
+
+
+
+
+1. Select `Rollback` in your deployed pipeline.
+
+2. On the `Rollback` page, select a configuration to deploy from the list:
+
+| Configurations | Description |
+| --- | --- |
+| **Last saved config** | Deploy the image with the latest saved configuration. |
+| **Last deployed config** | Deploy the image with the last deployed configuration. **Example**: `The configuration C3`.|
+| **Config deployed with selected image** | Deploy the configuration which was deployed with the selected image. **Example**: `The configuration C2`. |
+
+3. Once you select the previously deployed image and the configuration, review the difference between `Last Deployed Configuration` and the selected configuration.
+
+4. Click `Deploy`.
+
+
+
+The selected previously deployed image will be deployed.
+
+**Note**:
+- There will be no difference in the configuration if you select `Last deployed config` from the list.
+- When you select `Config deployed with selected image` and if the configuration is missing in the selected previously deployed image, it will show as `Config Not Available`. In such cases, you can select either `Last saved config` or `Last deployed config`.
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/deploying-application/triggering-cd.md b/versioned_docs/version-1.7/user-guide/deploying-application/triggering-cd.md
new file mode 100755
index 0000000000..7577b0e506
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/deploying-application/triggering-cd.md
@@ -0,0 +1,152 @@
+---
+id: triggering-cd
+title: Triggering CD Pipelines
+sidebar_label: Triggering CD Pipelines
+---
+
+# Triggering CD Pipelines
+
+After the [CI pipeline](./triggering-ci.md) is complete, you can trigger the CD pipeline.
+
+1. Go to the `Build & Deploy` tab of your application and click **Select Image** in the CD pipeline.
+
+ 
+
+2. Select an image for deployment.
+
+ 
+
+ However, if an image is already deployed, you can identify it by the tag `Active on `.
+
+ 
+
+3. If in any scenario, such as deploying a hotfix, if you need to use a different deployment strategy other than the default, you can select a different deployment strategy.
+
+ **Note:** You can only select the deployment strategies that are configured for that pipeline. Refer to the [CD Pipeline](../creating-application/workflow/cd-pipeline.md#configure-deployment-strategies) to learn more.
+
+ 
+
+4. In case you have made any changes in the environment configurations (such as changing deployment strategy, modifying ConfigMaps & Secrets, etc.) since the last deployment, use the **Config Diff** button to compare the new configurations with the last deployed configurations before deploying. Refer to [Reviewing Configurations Differences](#reviewing-configuration-differences) to learn more.
+
+5. Click **Deploy** to trigger the CD pipeline.
+
+## Reviewing Configuration Differences
+
+Before triggering a deployment, if you’ve made any changes to the environment configurations, you can review the configuration differences between your **Last Deployed Configurations** (old configurations) and your **Last Saved Configurations** (new configurations) by clicking the **Config Diff** button. After reviewing, you can choose whether to deploy using the updated configurations or stick with the previously deployed ones.
+
+1. Click the **Config Diff** button to review the changes; a modal window will appear.
+
+ 
+
+2. You can compare configuration differences for various resources, including the **Deployment template**, **Pipeline Configurations**, **ConfigMaps**, and **Secrets**.
+
+3. To compare changes for a specific resource, select it from the left side of the modal window under **Deployment Configurations**.
+
+ 
+
+4. The right panel displays a side-by-side comparison between the **Last Deployed** and **Last Saved** configurations for the selected resource. You can review the configuration differences for each resource before triggering the deployment.
+
+ 
+
+ 
+
+ 
+
+ 
+
+5. After reviewing, select whether you want to trigger the deployment with **Last Saved Config** (new configurations) or **Last Deploy Config** (old configurations).
+
+ 
+
+6. Select **Deploy** to trigger the deployment.
+
+ 
+
+## Manual Approval for Deployment
+
+When [manual approval is enabled](../global-configurations/approval-policy.md) for the deployment pipeline configured in the workflow, you are expected to request for an image approval before each deployment. Alternatively, you can deploy images that have already been approved once.
+
+If no approved images are available or the current image is already deployed, you won't see any images for deployment when clicking **Select Image**.
+
+
+
+### Requesting for Image Approval
+
+Users need to have [Build & deploy permission](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and application) to request for an image approval.
+
+To request an image approval, follow these steps:
+
+1. Navigate to the `Build & Deploy` page, and click the **Approval for deployment** icon.
+
+ 
+
+2. Click the **Request Approval** button present on the image for which you want to request an approval and click **Submit Request**.
+
+ 
+
+ In case you have configured [SES or SMTP on Devtron](../global-configurations/manage-notification.md#configurations), you can directly choose the approver(s) from the list of approvers as shown below.
+
+ 
+
+ The users you selected will receive an approval request via email. Any user with 'Image approver' permission alongwith access to the given application and given environment would be able to approve the image.
+
+
+## Extras
+
+* In case you wish to cancel the image approval request, you can do so from the `Approval pending` tab as shown in the below image.
+
+ 
+
+* If you've received an approval but no longer want the image to be deployable, you can let the approval expire.
+
+ 
+
+### Accepting Image Approval Request
+
+By default, super-admin users are considered as the default approvers. Users who build the image and/or request for its approval, cannot self-approve it even if they have super-admin privileges.
+
+Users with `Approver` permission (for the specific application and environment) can also approve a deployment. This permission can be granted to users from [`User Permissions`](../global-configurations/authorization/user-access.md#devtron-apps-permissions) present in [Global Configurations](../global-configurations/README.md).
+
+In case [SES](../global-configurations/manage-notification.md#email-ses-configuration) or [SMTP](../global-configurations/manage-notification.md#email-smtp-configuration) was configured in Devtron, and the user chose the approvers while raising an image approval request, the approvers would receive an email notification as shown below:
+
+
+
+To approve an image approval request, follow these steps:
+
+1. Go to the `Build & Deploy` page and click the `Approval for deployment` button.
+
+ 
+
+2. Switch to the `Approval pending` tab. Here, you will get a list of images that are awaiting approval.
+
+ 
+
+3. Click **Approve** followed by **Approve Request** button.
+
+ 
+
+### Deploying Approved Image
+
+Users need to have [Build & deploy permission](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the respective environment and application) to select and deploy an approved image.
+
+In case the super-admin has set the minimum number of approval to more than 1 (in [Approval Policy](../global-configurations/approval-policy.md)), you must wait for all approvals before deploying the image. In other words, partially approved image will not be eligible for deployment.
+
+
+
+To deploy an approved image, follow these steps:
+
+1. Navigate to the `Build & Deploy` tab and click **Select Image**.
+
+ 
+
+2. You will find all the approved images listed under the `Approved images` section. From the list, you can select the desired image and deploy it to your environment.
+
+ 
+
+3. You can view the status of current deployment in the `App Details` tab.
+
+ 
+
+The status initially appears as `Progressing` for approximately 1-2 minutes, and then gradually transitions to `Healthy` state based on the deployment strategy.
+
+Here, our CD pipeline trigger was successful, and the deployment is in `Healthy` state.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/deploying-application/triggering-ci.md b/versioned_docs/version-1.7/user-guide/deploying-application/triggering-ci.md
new file mode 100755
index 0000000000..4a033b791e
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/deploying-application/triggering-ci.md
@@ -0,0 +1,89 @@
+---
+id: triggering-ci
+title: Triggering CI Pipelines
+sidebar_label: Triggering CI Pipelines
+---
+
+# Triggering CI Pipelines
+
+To trigger the CI pipeline, first you need to select a Git commit. To select a Git commit, click the **Select Material** button present on the CI pipeline.
+
+
+
+Once clicked, a list will appear showing various commits made in the repository, it includes details such as the author name, commit date, time, etc. Choose the desired commit for which you want to trigger the pipeline, and then click **Start Build** to initiate the CI pipeline.
+
+
+
+CI Pipelines with automatic trigger enabled are triggered immediately when a new commit is made to the git branch. If the trigger for a build pipeline is set to manual, it will not be automatically triggered and requires a manual trigger.
+
+---
+
+## Partial Cloning Feature
+
+CI builds can be time-consuming for large repositories, especially for enterprises. However, Devtron's partial cloning feature significantly increases cloning speed, reducing the time it takes to clone your source code and leading to faster build times.
+
+**Advantages**
+* Smaller image sizes
+* Reduced resource usage and costs
+* Faster software releases
+* Improved productivity
+
+Get in touch with us if you are looking for a way to improve the efficiency of your software development process.
+
+The **Refresh** icon updates the Git Commits section in the CI Pipeline by fetching the latest commits from the repository. Clicking on the refresh icon ensures that you have the most recent commit available.
+
+The **Ignore Cache** option ignores the previous build cache and creates a fresh build. If selected, will take a longer build time than usual. [Click here](../creating-application/workflow/ci-pipeline.md#docker-layer-caching-) to read more about controlling cache behavior in Devtron.
+
+---
+
+## Passing Build Parameters
+
+:::caution Who Can Perform This Action?
+Users need to have [Build & deploy permission](../global-configurations/authorization/user-access.md#devtron-apps-permissions) or above (along with access to the environment and application) to pass build parameters.
+:::
+
+If you wish to pass runtime parameters for a build job, you can provide key-value pairs before triggering the build. Thereafter, you can access those passed values by referencing the corresponding keys in the environment variable dictionary.
+
+**Steps**
+
+1. Go to the **Parameters** tab available on the screen where you select the commit.
+
+ 
+
+2. Click **+ Add parameter**.
+
+ 
+
+3. Enter your key-value pair as shown below.
+
+ 
+
+ Similarly, you may add more than one key-value pair by using the **+ Add Parameter** button.
+
+4. Click **Start Build**.
+
+:::info
+In case you trigger builds in bulk, you can consider passing build parameters in [Application Groups](../application-groups.md).
+:::
+
+---
+
+## Fetching Logs and Reports
+
+Click the `CI Pipeline` or navigate to the `Build History` to get the CI pipeline details such as build logs, source code details, artifacts, and vulnerability scan reports.
+
+To access the logs of the CI Pipeline, simply click `Logs`.
+
+
+
+To view specific details of the Git commit you've selected for the build, click on `Source`. This will provide you with information like the commit ID, author, and commit message associated with that particular commit.
+
+
+
+By selecting the `Artifacts` option, you can download reports related to the tasks performed in the Pre-CI and Post-CI stages. This will allow you to access and retrieve the generated reports, if any, related to these stages. Additionally, you have the option to add tags or comments to the image directly from this section.
+
+
+
+To check for any vulnerabilities in the build image, click on `Security`. Please note that vulnerabilities will only be visible if you have enabled the `Scan for vulnerabilities` option in the advanced options of the CI pipeline before building the image. For more information about this feature, please refer to this [documentation](../../user-guide/security-features.md).
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/devtron-intelligence.md b/versioned_docs/version-1.7/user-guide/devtron-intelligence.md
new file mode 100755
index 0000000000..333bf57b55
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/devtron-intelligence.md
@@ -0,0 +1,320 @@
+---
+id: devtron-intelligence
+title: Using Devtron Intelligence
+sidebar_label: Using Devtron Intelligence
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Using Devtron Intelligence
+
+## What is Devtron Intelligence (AI Agent)
+
+Devtron Intelligence is an AI assistant that helps you troubleshoot issues faster by analyzing your Kubernetes workloads. It offers smart and easy-to-understand suggestions using large language models (LLM) of your choice.
+
+Check out the [Results](#results) section to see where Devtron gives you AI-powered explanation for troubleshooting.
+
+
+
+### Tutorial
+
+
+
+---
+
+## Steps to Configure Devtron Intelligence
+
+:::caution Who Can Perform This Action?
+User must have permissions to:
+ * Deploy Helm Apps (with environment access)
+ * Edit the ConfigMaps of 'default-cluster'
+ * Restart the pods
+:::
+
+### 1. Get API Key from LLM
+
+Devtron Intelligence supports all major large language models (LLM) e.g., OpenAI, Gemini, AWS Bedrock, Anthropic and many more.
+
+You can generate an API key for an LLM of your choice. Here, we will generate an API key from [OpenAI](https://platform.openai.com/account/api-keys).
+
+
+### 2. Create Secret in Devtron
+
+There are 2 methods to create a secret in Devtron, follow the one you prefer:
+* [Method A: Using 'Create Resource'](#method-a-using-create-resource)
+* [Method B: Using kubectl command](#method-b-using-kubectl-command)
+
+#### Method A: Using 'Create Resource'
+
+1. Go to [strings.devtron.ai](https://strings.devtron.ai/base64-encoder) and encode your API key in base64. This base64 encoded key will be used while creating a secret in the next step.
+
+2. Go to **Resource Browser** → (Select Cluster) → **Create Resource**
+
+3. Paste the following YAML and replace the key with your base64-encoded OpenAI key. Also, enter the namespace where the [AI Agent chart](#3-deploy-ai-agent-chart) will be installed:
+
+```yaml
+apiVersion: v1
+kind: Secret
+metadata:
+ name: ai-secret
+ namespace: # Namespace where the AI Agent chart will be installed
+type: Opaque
+data:
+ ## OpenAiKey: # For OpenAI
+ ## GoogleKey: # For Gemini
+ ## azureOpenAiKey: # For Azure OpenAI
+ ## awsAccessKeyId: # For AWS Bedrock
+ ## awsSecretAccessKey: # For AWS Bedrock
+ ## AnthropicKey: # For Anthropic
+```
+
+#### Method B: Using kubectl command
+
+:::tip
+Unlike [Method A](#method-a-using-create-resource), this method doesn't require you to encode your LLM Key to Base64 format.
+:::
+
+1. Go to Devtron's [Resource Browser](./resource-browser/README.md) and click the [terminal icon](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/kubernetes-resource-browser/cluster-terminal.gif) next to the cluster where you wish to create the secret.
+
+2. Use the following kubectl command to create a secret.
+ * Replace `my-namespace` with the namespace where the AI Agent chart will be installed.
+ * Use the correct LLM key-name and your key-value after `--from-literal`
+
+```bash
+kubectl create secret generic ai-secret \
+ --namespace=my-namespace \
+ --from-literal=OpenAiKey='openai-key-here' \
+# --from-literal=GoogleKey='google-key-here' \
+# --from-literal=azureOpenAiKey='azure-key-here' \
+# --from-literal=AnthropicKey='anthropic-key-here'
+```
+
+ 
+
+
+### 3. Deploy AI Agent Chart
+
+:::caution Where should I install the Chart?
+Deploy the chart in the cluster whose workloads you wish to troubleshoot. You may install the chart in multiple clusters (1 agent for 1 cluster).
+:::
+
+1. Go to Devtron's Chart Store.
+
+2. Search the `ai-agent` chart and click on it.
+
+3. Click the **Configure & Deploy** button.
+
+4. In the left-hand pane:
+
+ * **App Name**: Give your app a name, e.g. `ai-agent-app`
+
+ * **Project**: Select your project
+
+ * **Deploy to environment**: Choose the target environment (should be associated with the same namespace used while creating secret key in [Step 2](#2-create-secret-in-devtron))
+
+ * **Chart Version**: Select the latest chart version.
+
+ * **Chart Values**: Choose the default one for the latest version.
+
+5. In the `values.yaml` file editor, add the appropriate `additionalEnvVars` block based on your LLM provider. Use the tabs below to find the configuration snippet of some well-known LLM providers.
+
+
+
+
+```yaml
+additionalEnvVars:
+ - name: MODEL
+ value: gpt-4o-mini ## Examples: gpt-4o, gpt-4, gpt-3.5-turbo
+ - name: OPENAI_API_KEY
+ valueFrom:
+ secretKeyRef:
+ key: OpenAiKey ## Key of the secret created in Step 2
+ name: ai-secret ## Name of the secret created in Step 2
+ - name: CLUSTER_NAME
+ value: document-nonprod ## Name of the target cluster (optional)
+```
+
+
+
+```yaml
+additionalEnvVars:
+ - name: MODEL
+ value: gemini-1.5-pro ## Examples: gemini-2.0-flash, gemini-2.0-flash-lite
+ - name: GOOGLE_API_KEY
+ valueFrom:
+ secretKeyRef:
+ key: GoogleKey ## Key of the secret created in Step 2
+ name: ai-secret ## Name of the secret created in Step 2
+ - name: CLUSTER_NAME
+ value: document-nonprod ## Name of the target cluster (optional)
+```
+
+
+
+```yaml
+additionalEnvVars:
+ - name: MODEL
+ value: azure/ ## Replace with your Azure deployment name (keep "azure/" prefix)
+ - name: MODEL_TYPE
+ value: gpt-4o ## Supported: gpt-4o, gpt-35-turbo, etc.
+ - name: AZURE_API_VERSION
+ value: ## Replace with the version from Azure portal
+ - name: AZURE_API_BASE
+ value: ## Your Azure endpoint e.g. https://my-org.openai.azure.com/
+ - name: AZURE_API_KEY
+ valueFrom:
+ secretKeyRef:
+ key: azureOpenAiKey ## Key of the secret created in Step 2
+ name: ai-secret ## Name of the secret created in Step 2
+ - name: CLUSTER_NAME
+ value: document-nonprod ## Name of the target cluster (optional)
+```
+
+
+
+```yaml
+additionalEnvVars:
+ - name: MODEL
+ value: bedrock/anthropic.claude-3-5-sonnet-20240620-v1:0 ## Replace with your actual Bedrock model name
+ - name: AWS_REGION_NAME
+ value: us-east-1
+ - name: AWS_ACCESS_KEY_ID
+ valueFrom:
+ secretKeyRef:
+ key: awsAccessKeyId ## Key of the Access Key ID created in Step 2
+ name: ai-secret ## Name of the secret created in Step 2
+ - name: AWS_SECRET_ACCESS_KEY
+ valueFrom:
+ secretKeyRef:
+ key: awsSecretAccessKey ## Key of the secret created in Step 2
+ name: ai-secret ## Name of the secret created in Step 2
+ - name: CLUSTER_NAME
+ value: document-nonprod ## Name of the target cluster (optional)
+```
+
+
+
+```yaml
+additionalEnvVars:
+ - name: MODEL
+ value: claude-3-sonnet ## Examples: claude-3-sonnet, claude-3-haiku
+ - name: ANTHROPIC_API_KEY
+ valueFrom:
+ secretKeyRef:
+ key: AnthropicKey ## Key of the secret created in Step 2
+ name: ai-secret ## Name of the secret created in Step 2
+ - name: CLUSTER_NAME
+ value: document-nonprod ## Name of the target cluster (optional)
+```
+
+
+
+
+
+
+6. Click the **Deploy Chart** button.
+
+### 4. Check Service Endpoint
+
+1. In the **App Details** page of the deployed chart, expand **Networking** and click on **Service**.
+
+2. Locate the service entry with the URL in the format: `.:`. Note the values of `serviceName`, `namespace`, and `port` for the next step.
+
+
+
+
+### 5. Update ConfigMaps
+
+1. In a new tab, go to **Resource Browser** → (Select Cluster) → **Config & Storage** → **ConfigMap**
+
+2. Edit the ConfigMaps:
+
+ * **devtron-cm**
+
+ Ensure the below entry is present in the ConfigMap (create one if it doesn't exist). Here you can define the target cluster and the endpoint where your Devtron AI service is deployed:
+
+ ```yaml
+ CLUSTER_CHAT_CONFIG: '{"": {"serviceName": "", "namespace": "", "port": ""}}'
+ ```
+
+ 
+
+ * **dashboard-cm**
+
+ To enable AI integration via feature flag, check if the below entry is present in the ConfigMap (create one if it doesn't exist).
+
+ ```yaml
+ FEATURE_AI_INTEGRATION_ENABLE: "true"
+ ```
+
+ 
+
+
+### 6. Restart Pods
+
+1. Go to **Resource Browser** → (Select Cluster) → **Workloads** → **Deployment**
+
+2. Click the checkbox next to the following **Deployment** workloads and restart them using the **`⟳`** button:
+ * `devtron`
+ * `dashboard`
+
+ 
+
+
+### 7. Perform Hard Refresh
+
+Perform a hard refresh of the browser to clear the cache:
+* **Mac**: Hold down `Cmd` and `Shift` and then press `R`
+* **Windows/Linux**: Hold down `Ctrl` and then press `F5`
+
+---
+
+## Results
+
+Devtron supports **Explain** option at the following screens (only for specific scenarios where troubleshooting is possible through AI):
+
+### Pod Errors
+
+**Path**: Resource Browser → (Select Cluster) → Workloads → Pod
+
+
+
+
+
+### Pod Last Restart Snapshot
+
+**Path**: Resource Browser → (Select Cluster) → Workloads → Pod → Pod Last Restart Snapshot
+
+
+
+### Event Errors
+
+**Path**: Resource Browser → (Select Cluster) → Events
+
+
+
+### App Details - Application Status
+
+**Path**: Applications → (Select Application) → App Details → Application Status Drawer
+
+
+
+
+
+### App Details - K8s Resources
+
+**Path**: Applications → (Select Application) → App Details → K8s Resources (tab) → Workloads
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/README.md b/versioned_docs/version-1.7/user-guide/global-configurations/README.md
new file mode 100755
index 0000000000..6335b30633
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/README.md
@@ -0,0 +1,50 @@
+---
+id: README
+title: Global Configurations
+sidebar_label: Global Configurations
+description: Manage cluster-level, authorization, and integration settings that apply across all Devtron modules.
+---
+
+The **Global Configurations** section defines system-wide settings that govern clusters, environments, container registries, authentication, and integrations across Devtron.
+
+Before you start creating an application, we recommend to you to complete the Global Configurations.
+
+These configurations act as the foundation for all application, deployment, and policy operations.
+
+---
+
+## Table of Contents
+
+### 1. SSO Login Services
+* [Google](./authorization/sso/google.md)
+* [GitHub](./authorization/sso/github.md)
+* [GitLab](./authorization/sso/gitlab.md)
+* [Microsoft](./authorization/sso/microsoft.md)
+* [LDAP](./authorization/sso/ldap.md)
+* [OIDC](./authorization/sso/oidc.md)
+* [Keycloak](./authorization/sso/keycloak.md)
+* [Okta](./authorization/sso/okta.md)
+* [OpenShift](./authorization/sso/openshift.md)
+
+### 2. [Host URL](./host-url.md)
+Define the base URL for accessing the Devtron dashboard and related services.
+
+### 3. [Cluster and Environments](./cluster-and-environments.md)
+Register and manage Kubernetes clusters and deployment environments available to applications.
+
+### 4. [Container/OCI Registry](./container-registries.md)
+Configure Docker or OCI registries where your build artifacts are stored and fetched from during deployment.
+
+### 5. [Authorization](./authorization/README.md)
+Control user access and authentication mechanisms (RBAC).
+
+* [User Permissions](./authorization/user-access.md)
+* [Permission Groups](./authorization/permission-groups.md)
+* [API Tokens](./authorization/api-tokens.md)
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/application-template.md b/versioned_docs/version-1.7/user-guide/global-configurations/application-template.md
new file mode 100755
index 0000000000..7f757aa145
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/application-template.md
@@ -0,0 +1,109 @@
+---
+id: application-template
+title: Application Templates
+sidebar_label: Application Templates
+---
+
+# Application Templates
+
+## Introduction
+
+Application Templates in Devtron allows you to create Devtron application quickly and consistently. An application template in Devtron is created from an existing application. It captures the configuration (workflows, ConfigMaps, Secrets, Build Configurations, Source Repository, etc.) of that application, so the same setup can be reused to create new applications.
+
+Let's assume you have already created a microservice (Devtron Application) with all the required configurations, Git Repository, Build configurations, CI/CD workflows, deployment configurations, etc. Now, instead of repeating the same setup to create a similar Devtron app, you can create an Application Template from your existing Devtron app. This template can then be used to quickly create new microservices (Devtron applications) with the same trusted setup.
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to create Application Templates.
+:::
+
+---
+
+## Creating an Application Template
+
+1. Navigate to **Global Configurations** → **Application Templates**.
+
+2. Click **+ Create Template**; a modal window will appear.
+
+ 
+
+3. Select the Application from which you want to create the Application Template; you can also search for the preferred application from the search bar.
+
+ 
+
+4. Enter the information required by the following fields.
+
+ | Field | Required/Optional | Description |
+ | :------------------------ | :---------------- | :------------------------------------------- |
+ | **Template display name** | Required | Provide a name for the application template, e.g., `Banking-backend`|
+ | **Template ID** | Required | Template ID is a unique identifier for application templates, and is uniquely mapped to the application template.
Character limit: 3-50
Only lowercase alphanumeric characters are allowed
Special Characters: `-`,`_`,`.`
Template ID should be unique for each application template
|
+ | **Description** | Optional | Provide a short description for the application template |
+
+
+ 
+
+5. Click **Create Template**; application template will be created.
+
+---
+
+## Customizing an Application Template
+
+After you create an application template, you can view the configurations it inherited (Git, Build, Chart, Pipeline config) from the source application. If you wish, you may modify those configurations according to your use cases.
+
+1. Navigate to **Global Configurations** → **Application Templates**.
+
+2. Select your preferred application template.
+
+3. You may customize the following configurations under **Configurations** tab
+
+ | Field | Description |
+ | :------------------------ | :------------------------------------------- |
+ | **Git Repository** | The source code repository linked to the application.|
+ | **Build Configurations** | Build configuration is used to create and push docker images in the container registry of your application; refer [Build Configurations](../creating-application/docker-build-configuration.md) to learn more. |
+ | **Base Configurations** | Base Configurations let you define the following configurations:
**Deployment Template**; refer [Base Deployment Template](../creating-application/base-config/deployment-template.md) to learn more.
**ConfigMaps**; refer [ConfigMaps](../creating-application/base-config/config-maps.md) to learn more.
**Secrets**; refer [Secrets](../creating-application/base-config/secrets.md) to learn more
|
+ | **CI/CD Workflows**| Define and manage your build and deployment pipelines using Workflow Editor; refer [Workflow Editor](../creating-application/workflow/README.md) to learn more.|
+ | **Environment Overrides** | Environment Overrides lets you define custom configurations for different environments without changing the base configurations; refer [Environment Overrides](../creating-application/environment-overrides.md) to learn more.|
+
+ 
+
+
+
+4. (Optional) You can also define a README for your Application Template
+ 1. Click the **Edit** button in the **Readme** section.
+
+ 
+
+ 2. A Markdown editor will appear where you can write or modify content under the Write tab.
+
+ 3. Use standard Markdown syntax to format text, create lists, insert links, and more.
+
+ 4. Preview the content using the **Preview** tab.
+
+ 5. Click Save to update the **Readme**.
+
+ 
+
+---
+
+## Using an Application Template
+
+You can use an application template to create an application. Refer [Creating Application From Template](../using-application-templates.md) to learn more.
+
+---
+
+## Deleting an Application Template
+
+1. Navigate to **Global Configurations** → **Application Templates**.
+
+2. Select your preferred application template.
+
+3. Click **Delete Template** in the bottom right corner under **Configurations** tab
+
+ 
+
+4. A modal window will appear, click **Delete**; application template will be deleted.
+
+ 
+
+:::tip Note
+Deleting an Application Template does not affect any applications, neither the application used to create that template, nor the applications created using that template.
+:::
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/approval-policy.md b/versioned_docs/version-1.7/user-guide/global-configurations/approval-policy.md
new file mode 100755
index 0000000000..13a05f2243
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/approval-policy.md
@@ -0,0 +1,416 @@
+---
+id: approval-policy
+title: Approval Policy
+sidebar_label: Approval Policy
+---
+
+# Approval Policy
+
+## Introduction
+
+When it comes to critical environments (let's say, production), you as a super-admin might want to introduce an approval flow for application deployment or changes made to the configuration files. Enforcing such restrictions will prevent unwanted deployments and direct modifications to sensitive configurations.
+
+The **Approval Policy** feature in Devtron lets you introduce an approval mechanism whenever your users perform the following actions:
+
+- Deploying an Application to an Environment
+- Changes in Deployment Template
+- Changes in ConfigMap
+- Changes in Secret
+
+
+
+
+
+---
+
+## Create an Approval Policy
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permissions to create an approval policy.
+:::
+
+1. Go to **Global Configurations** → **Approval Policy**.
+
+ 
+
+2. Click **+ Create Profile**.
+
+ 
+
+3. Give a name to the policy, e.g., *`banking-prod-approval`*, and add a description (optional) preferably explaining what it does.
+
+ 
+
+4. Additionally, you can decide who can grant approval from the following 3 options:
+
+ * **Option 1**: Choose **Any Approver** if you want to allow any user with `Image Approver` permissions and/or `Configuration Approver` permissions to approve 'Deployment' request and 'Configuration Change' respectively. Choose the number of approvals your users must get to proceed with their changes. The permissible limit ranges from one approval (minimum) to six approvals (maximum).
+
+ 
+
+ * **Option 2**: Choose **Specific Approver** → **User Group** → **Add Criteria** to choose one or more [user groups](./authorization/user-access.md#add-users) who can provide the requisite number of approvals. The permissible limit is [1 to 6] for each user group you add. From the selected group(s), only the users having `Image Approver` and/or `Configuration Approver` permissions can approve.
+
+ 
+
+ * **Option 3**: Choose **Specific Approver** → **Specific Users (dropdown)** to cherry-pick the names of the user(s) who can provide an approval. Here, there is no upper limit to the approvals (unlike the above options), so the user must obtain approvals from all the specific members you add to the policy.
+
+ 
+
+:::caution Caution
+* The dropdown lists all users available in Devtron. Some users (except super-admins) may not have the necessary approver permissions, i.e, **Config Approver** or **Deployment approver**. These users cannot approve requests until the required permissions are assigned to them.
+
+* Super-admins have approver permissions by default.
+
+* Refer [User Permissions](./authorization/user-access.md#roles-available-for-devtron-apps) to learn more.
+:::
+
+:::info How do approvals of User Groups work?
+If a user belongs to multiple groups (see Option 2 above), their approval is considered and counted for each group. For example, if you mandate 2 approvals: 1 from DevOps group and 1 from Compliance group; an approval from a common user (belonging to both groups) will count as 2 approvals.
+
+However, once a group's required approvals are met, extra approvals won’t count. For example, if a request needs 2 Security and 3 QA approvals and already has 2 Security and 2 QA approvals, an approval from a user in both teams will count only for QA. The user appears in both lists but doesn’t add to Security’s count.
+:::
+
+:::info Can super-admins approve the requests?
+Yes, apart from the users having approver access, super-admins can also approve the requests (provided the requests are not their own).
+:::
+
+:::caution What happens if a specific user mentioned in the policy gets deleted from Devtron or has their permissions revoked?
+Even if the user mentioned in the policy no longer exists, the approval conditions will remain unchanged. Therefore, to prevent unfulfilled approval conditions because of an absent user, it's best to remove that specific user from the policy.
+:::
+
+5. Click **Save Changes**.
+
+---
+
+## Apply an Approval Policy
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permissions to apply an approval policy.
+:::
+
+1. After you create an approval policy, you can apply it. Click **Apply Profile** on the same screen.
+
+ 
+
+2. From the **Select profiles to apply** dropdown, choose the policy you wish to apply. You also have the option to select more than one policy (if they exist) using the checkbox.
+
+ 
+
+3. Choose the scope from the dropdown given next to **Use selected policy for approval of**. Here you can decide whether your policy is for:
+ * **Approval of Deployment** - Select 'Deployments' from the dropdown.
+ * **Approval of Configuration Change** - Select 'Configuration change' from the dropdown. You can further select: `Deployment template`, `ConfigMaps`, `Secrets`. Select the ones to which your policy should apply so that any change to your chosen configurations will require an approval.
+
+ 
+
+4. Under **Apply to**, you get the following options to choose from:
+ * **Specific Criteria** - Select this option to apply your policy to specific environment(s) of specific applications.
+
+ **Example**: In case of Deployment
+
+ 
+
+ **Example**: In case of Configuration Change
+
+ 
+
+ * **By match criteria** - Select this option to use a combination of filters to create criteria. Your policy will only apply to target pipelines/configurations fulfilling your criteria (including existing and future ones). (Optional) You may also write a note for your other team members to understand the intent and context of your policy.
+
+ **Example**: In case of Deployment
+
+ 
+
+ **Example**: In case of Configuration Change
+
+ 
+
+ * **Global** - Select this option to apply your chosen policies to every deployment pipeline or configurations (existing and future) of all applications in all clusters.
+
+ **Example**: In case of Deployment
+
+ 
+
+ **Example**: In case of Configuration Change
+
+ 
+
+
+5. Click **Save Changes**.
+
+---
+
+## Apply Multiple Policies
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permissions to apply more policies to a scope.
+:::
+
+As shown in step 2 of [Apply an Approval Policy](#apply-an-approval-policy), you can choose multiple policies and apply them to a scope (e.g., Global, Cluster, Application, Environment, Base Configuration). However, if you have already applied and now you wish to apply more policies to the same scope, you may do so by following either of the below steps:
+
+* [Apply More Policies to a Scope](#apply-more-policies-to-a-scope)
+* [Apply More Policies in Bulk](#apply-more-policies-in-bulk)
+
+### Apply More Policies to a Scope
+
+1. Go to **Applied Profiles** tab.
+2. Use the filters to find the applied profile and scope (e.g., Global, Cluster, Application).
+3. Click the context menu.
+4. Click **Manage policy**.
+5. Use the **Select profiles to apply** dropdown and tick the policy/policies you wish to apply.
+6. Click **Save Changes**.
+
+ 
+
+### Apply More Policies in Bulk
+
+1. Use the checkboxes to select the relevant scopes (e.g., Global, Cluster, Application).
+2. Click the **Manage Profiles** button on the floating widget.
+3. Click **Add**.
+4. Use the **Select profile to apply** dropdown and tick the policy/policies you wish to apply in bulk.
+5. Review the changes if needed, and click **Save Changes**.
+
+ 
+
+:::caution How do multiple policies work if applied together?
+If you apply multiple policies together, the user has to meet the approval conditions of all the applied policies.
+**Example 1**: if 'Policy A' demands 3 approvals specifically from John, Jane, and Jessy; and if 'Policy B' requires 1 approval from 'Product User Group', the user will have to get 4 approvals.
+**Example 2**: if 'Policy A' demands 3 approvals specifically from John, Jane, and Jessy; and if 'Policy B' requires 2 approvals from anyone, the user will still have to get 3 approvals from John, Jane, and Jessy. In short, the stricter conditions from the policies are enforced first and they have to be fulfilled.
+:::
+
+---
+
+## Configuring Exceptions (Optional)
+
+The Exceptions tab allows you to specify users or groups for whom the approval policies will not apply. This is useful in cases where certain teams, such as an operations team resolving production incidents, need to bypass approvals while the policies continues to apply to all other users.
+
+You can choose to:
+
+ * Exclude super-admins from approval permissions.
+
+ * Whitelist specific users or user groups who should be exempt from approvals for deployments or configuration changes.
+
+### Excluding Super Admins
+
+You can configure whether super-admins are required to follow approval policies or bypass them.
+
+1. Navigate to **Global Configurations** → **Approval Policy** → **Exceptions**.
+
+2. Choose the scope, for which you want super admins to not require approval.The available scopes are:
+
+ * **Configuration Change:** Exempts the super-admins to edit base configurations such as Deployment Templates, ConfigMaps, or Secrets without requiring approvals.
+
+ * **Deployment:** Exempts the super-admins to deploy images to an environment without requiring approvals.
+
+3. Enable/Disable the toggle next to **Super admins** as per your requirement.
+
+ * When enabled, super-admins can deploy images and edit base configurations without approvals.
+
+ * When disabled, super-admins follow same approval policies as other users.
+
+ 
+
+:::info Note
+Super-admins can approve requests even if the toggle is turned off.
+:::
+
+### Excluding Specific Users / User Groups / API Tokens
+
+1. Navigate to **Global Configurations** → **Approval Policy** → **Exceptions**.
+
+ 
+
+2. Choose the scope for which specific users / user groups / API tokens do not require approval. The available scopes are:
+
+ * **Configuration Change:** Exempts the selected users, user groups, and API tokens to edit base configurations such as Deployment Templates, ConfigMaps, or Secrets without requiring approvals.
+
+ * **Deployment:** Exempts the selected users, user groups, and API tokens to deploy images to an environment without requiring approvals.
+
+ 
+
+:::info
+### Note
+The list of users is fetched from [User Permissions](../global-configurations/authorization/user-access.md), and the list of [API tokens](../global-configurations/authorization/api-tokens.md) is sourced from API Tokens.
+
+You cannot enter a new email ID or token directly.
+ * Refer [Add Users (User Permissions)](../global-configurations/authorization/user-access.md#add-users) to add a new user.
+
+ * Refer [API token](../global-configurations/authorization/api-tokens.md#generate-api-token) to create a new API token.
+:::
+
+3. Click the **Add**/**Edit** button next to **Specific Users / User Groups**. A pop-up modal window will appear.
+
+ 
+
+4. You can do either of the following:
+
+ 1. You can select specific **Users** or **API Tokens** from **Add Users** dropdown.
+
+ 
+
+ 
+
+ 2. You can select specific **Users Groups** from **Add user groups** dropdown.
+
+ 
+
+:::caution Caution
+* The dropdown lists all users and API tokens or user-groups, available in Devtron. Some users or API tokens may have only view permissions or lack build, deploy, or admin permissions. Such users cannot bypass approval policies until the required permissions are assigned.
+
+* Refer [User Permissions](./authorization/user-access.md#roles-available-for-devtron-apps) to learn more.
+:::
+
+5. Click **Save**. The selected users or user groups will no longer require approvals for the selected scope.
+
+ 
+
+:::caution Caution
+By default, approvers cannot approve their own deployments or base configuration edits, but, if an approver is added as an exception, this restriction does not apply, and that approver can trigger their own deployments or edit base configurations without any approvals.
+:::
+
+After configuring exceptions, super-admins and specific users / user groups can make configuration changes and trigger deployments without requiring any approval.
+
+#### Triggering Deployments
+
+:::caution Do exceptions bypass blackout or maintenance windows?
+Approval Policy exceptions do not bypass a blackout or a maintenance window:
+
+ * During a blackout window, exception users cannot trigger deployments, unless you add them to the list of users, who are allowed to take action during the blackout window.
+
+ * Outside a maintenance window, exception users cannot trigger deployments, unless you add them to the list of users, who are allowed to take action outside the maintenance window
+
+ * Refer [Deployment Window](../global-configurations/deployment-window.md#configuring-deployment-window) to learn more.
+:::
+
+:::info Note
+An exception user can still follow the normal flow of requesting an image approval and getting it approved, and also has the option to deploy images without approvals.
+:::
+
+
+
+
+
+
+
+#### Editing Base Configurations
+
+:::info Note
+* An exception user can still follow the normal flow of submitting a configuration change draft for approval, and getting it approved.
+* Any existing draft is discarded once the exception user updates the configuration using express edit.
+:::
+
+
+
+
+
+
+
+---
+
+## Remove Applied Policies
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permissions to remove an applied approval policy.
+:::
+
+If you have already applied policies and wish to remove some of them from a scope, follow the steps below. The approval conditions of the removed policy will no longer apply to the given scope, and the conditions of other policies (if applied to the same scope) will remain.
+
+* [Remove Policies Applied to a Scope](#remove-policies-applied-to-a-scope)
+* [Remove Applied Policies in Bulk](#remove-applied-policies-in-bulk)
+
+### Remove Policies Applied to a Scope
+
+1. Go to **Applied Profiles** tab.
+2. Use the filters to find the applied profile and scope (e.g., Global, Cluster, Application).
+3. Click the context menu.
+4. Click **Manage policy**.
+5. In the **Select profiles to apply** dropdown, click '**x**' next to the policy/policies you wish to remove.
+6. Click **Save Changes**.
+
+ 
+
+### Remove Applied Policies in Bulk
+
+1. Use the checkboxes to select the relevant scopes (e.g., Global, Cluster, Application)..
+2. Click the **Manage Profiles** button on the widget.
+3. Click **Remove**.
+4. In the **Remove Approval Policy** dropdown, click '**x**' next to the policy/policies you wish to remove.
+5. Review the changes if needed, and click **Save Changes**.
+
+ 
+
+:::caution Note
+At least one policy must remain applied to a scope, so you cannot remove all the policies from a scope. You may use the [delete procedure](#delete-applied-policies) instead.
+:::
+
+---
+
+## Delete Applied Policies
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permissions to delete an applied policy.
+:::
+
+If you have already applied policies to a scope (e.g., Global, Cluster, Application) and wish to delete all of them from that given scope, follow the steps below. **Note**: This will not [delete the approval policy](#delete-an-approval-policy) you originally created. Moreover, deployment pipelines may still continue inheriting profiles from higher scopes (e.g., Global, Cluster, Application).
+
+1. Go to **Applied Profiles** tab.
+2. Use the filters to find the applied profile(s).
+3. Click the **Delete** option in the context menu or use the checkboxes to select multiple scopes for deletion.
+
+ 
+
+---
+
+## Delete an Approval Policy
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permissions to delete an approval policy.
+:::
+
+If you no longer require a given approval policy, you may delete it. This action will automatically remove its rules enforced earlier for both, deployments and configuration change.
+
+1. Go to **Profiles** tab.
+2. Click the delete icon next to the profile you wish to delete.
+
+ 
+
+---
+
+## Results
+
+### Approving Deployment Request
+
+Assume you created a policy (shown below) that blocks the deployment of a banking application to an environment unless there are two approvals. No user can trigger the deployment unless the images are approved.
+
+
+
+1. The user first requests approval of the intended image. Only those with the necessary permissions will show up in the approver list. Moreover, the user can also opt to notify all users apart from the approvers.
+
+ 
+
+2. Only those with `Image Approver` permissions can then approve the request.
+
+ 
+
+ If [SES/SMTP](../global-configurations/manage-notification.md) is configured in Devtron, the approver gets notified via email. This enables the approver to take an action directly from the mail, such as `View Request` and `Approve Request`.
+
+ 
+
+3. The user can then proceed with deploying the approved image.
+
+ 
+
+### Approving Configuration Change Request
+
+Assume you created a policy (shown below) that prevents direct changes to the configuration files (Deployment Template, ConfigMaps, Secrets) of a banking application unless there is one approval.
+
+
+
+1. The user first requests approval for pushing a configuration change in Deployment Template/ConfigMap/Secret.
+
+ 
+
+2. Only those with `Configuration Approver` permissions can then approve the request.
+
+ 
+
+ If [SES/SMTP](../global-configurations/manage-notification.md) is configured in Devtron, the approver gets notified via email. Therefore, the approver can take an action directly from the mail as shown below.
+
+ 
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/README.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/README.md
new file mode 100755
index 0000000000..20941e53bf
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/README.md
@@ -0,0 +1,18 @@
+---
+id: README
+title: README
+sidebar_label: README
+hide_table_of_contents: true
+---
+
+**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:
+
+* [SSO Login Services](../sso-login.md)
+
+* [User Permissions](user-access.md)
+
+* [Permission Groups](permission-groups.md)
+
+* [API Tokens](api-tokens.md)
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/api-tokens.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/api-tokens.md
new file mode 100755
index 0000000000..bbb81be423
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/api-tokens.md
@@ -0,0 +1,96 @@
+---
+id: api-tokens
+title: API Tokens
+sidebar_label: API Tokens
+---
+
+# API Tokens
+
+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.
+
+## Generate API Token
+
+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.
+
+
+
+## Use 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.
+
+
+
+
+## Update API Token
+
+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`.
+
+
+
+
+## Delete API 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.
+
+
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/permission-groups.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/permission-groups.md
new file mode 100755
index 0000000000..71891a72d1
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/permission-groups.md
@@ -0,0 +1,166 @@
+---
+id: permission-groups
+title: Permission Groups
+sidebar_label: Permission Groups
+---
+
+# Permission Groups
+
+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.
+
+:::info
+The [User permissions](../../global-configurations/authorization/user-access.md) 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.
+:::
+
+## Add Group
+
+Go to **Global Configurations** → **Authorization** → **Permissions groups** → **Add group**.
+
+
+
+Enter the `Group Name` and `Description`.
+
+
+
+You can either grant [super-admin](../../global-configurations/authorization/user-access.md#grant-super-admin-permission) permission to a user group or specific permissions to manage access for:
+
+ * [Devtron Apps](#devtron-apps-permissions)
+ * [Helm Apps](#helm-apps-permissions)
+ * [Jobs](#jobs)
+ * [Kubernetes Resources](#kubernetes-resources-permissions)
+ * [Chart Groups](#chart-group-permissions)
+
+### Devtron Apps Permissions
+
+In `Devtron Apps` option, you can provide access to a group to manage permission for custom apps created using Devtron.
+
+:::info
+The `Devtron Apps` option will be available only if you install [CI/CD integration](../../integrations/build-and-deploy-ci-cd.md).
+:::
+
+Provide the information in the following fields:
+
+
+
+
+| Dropdown | Description |
+| --- | --- |
+| **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** | Select one of the [roles](#devtron-apps-permissions) to which you want to give permission to the user:
`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**.
+
+### Helm Apps Permissions
+
+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:
+
+
+
+| Dropdown | Description |
+| --- | --- |
+| **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** | Select one of the [roles](#helm-apps-permissions) to which you want to give permission to the user:
`View only`
`View & Edit`
`Admin`
|
+
+You can add multiple rows for Helm app permission.
+
+Once you have finished assigning the appropriate permissions for the groups, Click **Save**.
+
+### Jobs
+
+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:
+
+
+
+| Dropdown | Description |
+| --- | --- |
+| **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** | Select one of the roles to which you want to give permission to the user:
`View only`
`Run job`
`Admin`
|
+
+You can add multiple rows for `Jobs` permission.
+
+Once you have finished assigning the appropriate permissions for the groups, Click **Save**.
+
+
+### Kubernetes Resources Permissions
+
+In `Kubernetes Resources` option, you can provide permission to view, inspect, manage, and delete resources in your clusters from [Kubernetes Resource Browser](../../../user-guide/resource-browser/README.md) page in Devtron. You can also create resources from the `Kubernetes Resource Browser` page.
+
+:::info
+Only super admin users will be able to see `Kubernetes Resources` tab and provide permission to other users to access `Resource Browser`.
+:::
+
+To provide Kubernetes resource permission, click `Add permission`.
+
+
+
+On the `Kubernetes resource permission`, provide the information in the following fields:
+
+
+
+
+| Dropdown | Description |
+| --- | --- |
+| **Cluster** | Select a cluster from the drop-down list to which you want to give permission to the user. You can select only one cluster at a time. Note: To add another cluster, then click `Add another`. |
+| **Namespace** | Select the namespace from the drop-down list. |
+| **API Group** | Select the specific API group or `All API groups` from the drop-down list corresponding to the K8s resource. |
+ **Kind** | Select the kind or `All kind` from the drop-down list corresponding to the K8s resource. |
+ **Resource name** | Select the resource name or `All resources` from the drop-down list to which you want to give permission to the user. |
+| **Role** | Select one of the [roles](#kubernetes-resources-permissions) to which you want to give permission to the user and click `Done`:
`View`
`Admin`
|
+
+You can add multiple rows for Kubernetes resource permission.
+
+Once you have finished assigning the appropriate permissions for the groups, Click **Save**.
+
+### Chart Group Permissions
+
+In `Chart group permission` option, you can manage the access of groups for Chart Groups in your project.
+
+:::info
+The `Chart group permission` option will be available only if you install [CI/CD integration](../../integrations/build-and-deploy-ci-cd.md).
+:::
+
+
+
+:::info
+You can only give users the ability to `create` or `edit`, not both.
+:::
+
+| Action | Permissions |
+| :--- | :--- |
+| View | Enable `View` to view chart groups only. |
+| Create | Enable `Create` if you want the users to create, view, edit or delete the chart groups. |
+| Edit |
**Deny**: Select `Deny` option from the drop-down list to restrict the users to edit the chart groups.
**Specific chart groups**: Select the `Specific Charts Groups` option from the drop-down list and then select the chart group for which you want to allow users to edit.
|
+
+Click **Save** once you have configured all the required permissions for the groups.
+
+
+### Edit Permissions Groups
+
+You can edit the permission groups by clicking the `downward arrow.`
+
+
+
+Edit the permission group.
+
+
+
+Once you are done editing the permission group, click **Save**.
+
+If you want to delete the groups with particular permission group, click **Delete**.
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/github.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/github.md
new file mode 100755
index 0000000000..6d7f534acc
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/github.md
@@ -0,0 +1,91 @@
+---
+id: github
+title: GitHub
+sidebar_label: GitHub
+---
+
+# GitHub
+
+## Introduction
+
+Setting up GitHub SSO enables you to authenticate using your GitHub account, ensuring secure access to Devtron without the need for passwords. This document provides you step-by-step instructions on setting up GitHub SSO in Devtron.
+
+---
+
+## Prerequisites
+
+To configure GitHub SSO in Devtron, you need:
+
+* Super Admin permission
+ * Only a [Super-Admin](../user-access.md) in Devtron can configure SSO. However, you can use the [Admin credentials](../../../../setup/install/devtron-oss.md#step-4-log-in-to-devtron) provided during the initial setup, if you’re setting up Devtron for the first time.
+* A GitHub account to create and manage OAuth credentials. If you do not have a GitHub account, you must create it first on GitHub.
+* [Host URL](../../host-url.md) configured on the Host URL screen (**Global Configurations** → **Host URL**).
+
+---
+
+## Get the redirectURI from Devtron
+
+Getting the redirectURI from Devtron is a crucial component of the authentication process. It acts as an endpoint to which you are redirected after successful authentication. Follow the below instructions to get the redirectURI:
+
+1. Navigate to **Global Configurations** → **Authorization** → **SSO Login Services**. The SSO Login Service page is displayed.
+
+ 
+
+2. Select **GitHub** from the list of available SSO login services.
+
+3. Click the URL suggested in green color next to the **Click to use** label to update the **URL** field. Update the **URL** field only if the host URL displayed in the **URL** field is incorrect.
+
+4. Click the **Update** button.
+
+When you populate the Host URL in the **URL** field, the redirectURI (or callbackURI) is updated automatically in the purple block displayed at the top of the SSO Login Service screen. This redirectURI is essential, as it is required while setting up the OAuth credentials in GitHub.
+
+---
+
+## Configuring OAuth in GitHub
+
+Open Authentication (OAuth) allows you to authorize one application to sign in to another without the need for passwords. Configuring OAuth credentials in GitHub involves creating a GitHub OAuth Client ID and Client Secret, which will then be used in Devtron for authentication.
+
+1. Navigate to **GitHub** → **Profile** → **Settings** → **Developer settings** → **OAuth Apps**.
+
+ If you do not already have an OAuth application created on GitHub, refer to [Creating an OAuth app](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app). If you already have an OAuth application on GitHub, follow the instructions below:
+
+2. Select your preferred OAuth app and click **Edit**.
+
+ 
+
+3. Click the **Generate a new client secret** button to create a new client secret. The client secret is created and displayed in the **Client Secrets** section. The Client ID is created by default and can be found in the **Client ID** field.
+
+4. Update the **Homepage URL** field with the host URL configured in Devtron.
+
+5. Update the **Authorization callback URL** with the redirectURI created in Devtron.
+
+6. Click the **Update application** button.
+
+---
+
+## Configuring GitHub SSO in Devtron
+
+To configure the GitHub SSO in Devtron, follow the below steps of instructions:
+
+1. Navigate back to the **SSO Login Services** screen in Devtron.
+
+2. Select the **Configuration** section available below the **URL** field.
+
+ 
+
+3. Update the `clientID` attribute with the Client ID generated in the OAuth application on GitHub.
+
+4. Update the `clientSecret` attribute with the Client Secret generated in the OAuth application on GitHub.
+
+5. Update the `redirectURI` attribute with the `redirectURI` configured earlier.
+
+6. Click **Update** to save the configuration. GitHub SSO is now successfully configured.
+
+
+
+---
+
+:::caution Important: Enable User Access After SSO Setup
+Although GitHub SSO is now configured, you will not be able to sign in with GitHub unless you add yourself as a user with the necessary permissions and manage other user permissions as well in Devtron. For detailed steps on managing user permissions, refer to the [User Permissions Documentation](../user-access.md).
+
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/gitlab.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/gitlab.md
new file mode 100755
index 0000000000..15684bd630
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/gitlab.md
@@ -0,0 +1,103 @@
+---
+id: gitlab
+title: GitLab
+sidebar_label: GitLab
+---
+
+# GitLab
+
+## Introduction
+
+Setting up GitLab SSO enables you to authenticate using your GitLab account, ensuring secure access to Devtron without the need for passwords. This document provides you step-by-step instructions on setting up GitLab SSO in Devtron.
+
+---
+
+## Prerequisites
+
+To configure GitLab SSO in Devtron, you need:
+
+* Super Admin permissions
+ * Only a [Super Admin](../../user-access.md) in Devtron can configure SSO. You can use the [Admin credentials](../../../../setup/install/devtron-oss.md#step-4-log-in-to-devtron) provided during the initial setup, if you’re setting up Devtron for the first time.
+
+* A GitLab account to create and manage OAuth credentials. If you do not have a GitLab account, you must create it first on GitLab.
+
+* [Host URL](../../host-url.md) configured on the Host URL screen (**Global Configurations** → **Host URL**).
+
+---
+
+## Get the redirectURI from Devtron
+
+Getting the redirectURI from Devtron is a crucial component of the authentication process. It acts as an endpoint to which you are redirected after successful authentication. Follow the below instructions to get the redirectURI:
+
+1. Navigate to **Global Configurations** → **Authorization** → **SSO Login Services**. The SSO Login Service page is displayed.
+
+ 
+
+2. Select **GitLab** from the list of available SSO login services.
+
+3. Click the URL suggested in green color next to the **Click to use** label to update the **URL** field. Update the **URL** field only if the host URL displayed in the **URL** field is incorrect.
+
+4. Click the **Save** button.
+
+When you populate the Host URL in the **URL** text box, the redirectURI (or callbackURI) is updated automatically in the purple block at the top of the SSO Login Service screen. This redirectURI is essential, as it is required while setting up the OAuth credentials in GitLab.
+
+---
+
+## Configuring OAuth in GitLab
+
+Open Authentication (OAuth) allows you to authorize one application to sign in to another without the need for passwords. Configuring OAuth credentials in GitLab involves creating a GitLab OAuth Client ID and Client Secret, which will then be used in Devtron for authentication.
+
+1. Navigate to **GitLab** → **Profile** → **Edit Profile** → **Applications** → **Add new application**.
+
+ If you do not already have an OAuth application created on GitLab, refer to [Creating an OAuth app](https://docs.gitlab.com/integration/oauth_provider/). If you already have an OAuth application on GitLab, follow the instructions below:
+
+2. Select your preferred OAuth app and click **Edit**.
+
+ 
+
+3. Update the **Redirect URI** field with the redirectURI created in Devtron.
+
+4. Enable the required scopes in the **Scopes** section as per the requirements. To know more, refer to [Required scopes](https://docs.gitlab.com/integration/oauth_provider/).
+
+5. Click the **Save Application** button. The following page is displayed.
+
+ 
+
+ The client ID is displayed in the **Application ID** field.
+
+6. Click the **Renew secret** button against the **Secret** field. The Client Secret is then displayed in the **Secret** field.
+
+---
+
+## Configuring GitLab SSO in Devtron
+
+To configure the GitLab SSO in Devtron, follow the below steps of instructions:
+
+1. Navigate back to the **SSO Login Services** screen in Devtron.
+
+2. Select the **Configuration** section available next to the **URL** field.
+
+ 
+
+3. Update the `clientID` attribute with the Client ID generated in the OAuth application on GitLab.
+
+4. Update the `clientSecret` attribute with the Client Secret generated in the OAuth application on GitLab.
+
+5. Update the `redirectURI` attribute with the redirectURI configured earlier.
+
+6. Click **Update** button to save the configuration. GitLab SSO is now successfully configured.
+
+
+
+:::caution Important Note
+Although GitLab SSO is now configured, you will not be able to sign in with GitLab unless you add yourself as a user with the necessary permissions and manage other user permissions as well in Devtron. It is highly recommended to create [User Permissions](../user-access.md).
+
+:::
+
+---
+
+## References
+
+* [GitLab Documentation](https://docs.gitlab.com/ee/integration/oauth_provider.html)
+
+* [Authentication Through GitLab](https://dexidp.io/docs/connectors/gitlab/)
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/google.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/google.md
new file mode 100755
index 0000000000..c6154e861d
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/google.md
@@ -0,0 +1,127 @@
+---
+id: google
+title: Google
+sidebar_label: Google
+---
+
+# Google
+
+## Introduction
+
+Integrating Google as your Single Sign-On (SSO) provider enables users to authenticate with their Google accounts, ensuring secure and streamlined access to Devtron. This document walks you through setting up Google SSO in Devtron, ensuring users can log in smoothly.
+
+:::info Prerequisites
+To configure Google SSO in Devtron, you will need:
+
+* Super Admin permissions
+
+ * Only a [Super-Admin](../user-access.md#grant-super-admin-permission) can configure SSO. If you are setting up SSO for the first time, use [Admin Credentials](https://docs.devtron.ai/install/install-devtron#devtron-admin-credentials) instead.
+
+* A Google Cloud account to create and manage OAuth credentials. If you don’t have one, you must create it at the [Google Cloud Console](https://console.cloud.google.com/).
+
+:::
+
+## Get the Redirect URI from Devtron
+
+Before configuring Google as an SSO provider,
+* Ensure that the [Host URL](../../host-url.md) is correctly configured in Devtron. This is crucial because the Redirect URI is generated based on the Host URL.
+* You need to retrieve the Redirect URI from Devtron, which will be required in Google Cloud while setting up OAuth credentials.
+
+ * Log in to Devtron.
+ * Navigate to **Global Configurations** → **Authorization** **SSO Login Services**.
+ * Select **Google** as the authentication provider.
+ * Click the URL next to **Click to use** in green color. The URL field will be automatically populated with the URL next to **Click to use**; this is essential to generate the correct **Redirect URI**.
+ * Copy the **Redirect URI** displayed in this section. You will need to enter this in Google Cloud.
+
+
+
+## Configure OAuth in Google Cloud Console
+
+The next step is to configure OAuth credentials in Google Cloud Console. This involves creating a Google OAuth Client ID and Client Secret, which will be used in Devtron for authentication.
+
+### To set up OAuth, follow these steps:
+
+* Access [Google Cloud Console](https://console.cloud.google.com/) and create a new project or select an existing one.
+* Navigate to **APIs & Services** → **OAuth Consent Screen** and configure the required details as shown on the screen.
+* In **APIs & Services** → **Credentials**, create a new OAuth Client ID:
+ * Select 'Web application' as the application type.
+ * Paste the Redirect URI (copied from Devtron) under Authorized Redirect URIs.
+* Click **Create** to generate the Client ID and Client Secret.
+
+:::caution
+### Google SSO Requires a Valid Domain with HTTPS
+
+Google does not support IP addresses as valid redirect URIs. You must use a valid domain name ([FQDN](https://en.wikipedia.org/wiki/Fully_qualified_domain_name)) accessible over HTTPS.
+
+Examples of valid URIs:
+
+✅ `https://devtron.example.com/api/dex/callback`
+
+✅ `https://auth.yourcompany.com/callback`
+
+Examples of invalid URIs:
+
+❌ `http://localhost:8080/callback`
+
+❌ `http://192.168.1.10/callback`
+:::
+
+
+
+You can see a new client ID is created in the **APIs & Services** → **Credentials**, under **OAuth 2.0 Client IDs** section. To obtain Client ID and Client Secret, click on the name (devtron-sso in our case) of the **OAuth 2.0 Client IDs**
+
+
+
+Copy the Client ID and Client Secret, as they will be required in Devtron’s SSO configuration.
+
+
+
+For a detailed step-by-step guide, refer to Google’s official documentation: [Get Google API Client ID](https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid).
+
+## Configure Google SSO in Devtron
+
+The next step is to configure Devtron to use these credentials for authentication. For this, navigate back to **Global Configurations** → **Authorization** → **SSO Login Services**, here you can already find a configuration template.
+
+## Configuration
+
+
+
+In the configuration,
+
+* Enter the OAuth Credentials:
+ * Paste the Client ID obtained from Google Cloud in the `clientID` field.
+ * Paste the Client Secret obtained from Google Cloud in the `clientSecret` field.
+* Configure Hosted Domains (Optional):
+ * If you want to restrict authentication to specific domains (e.g., only users from company.com can log in), add these under `hostedDomains` in Devtron.
+ * If you want to allow all users with any valid Google account, remove the entire `hostedDomains` section from the configuration.
+* Enter the Redirect URI:
+ * Copy the Redirect URI displayed in Devtron and paste the value in the `redirectURI` field.
+* Click **Update** to save the configuration, once saved, Google SSO is successfully configured
+
+:::caution
+Although Google SSO is now set up, users will not be able to sign in unless they are explicitly added to Devtron with the necessary permissions.
+:::
+
+## Important: Enable User Access After SSO Setup
+
+To ensure users can log in:
+
+* Go to **Global Configurations** → **Authorization** → **User Permissions**.
+* Click **Add User**.
+
+
+
+* Enter their email (matching their Google account).
+* Assign the required role.
+* Click **Save** to complete the setup.
+
+
+
+Once saved, Devtron will use Google OAuth for authentication, allowing users to log in using their Google accounts.
+
+For detailed steps on managing user permissions, refer to the [User Permissions Documentation](../user-access.md).
+
+## Reference
+
+* [View Google Documentation](https://developers.google.com/identity/gsi/web/guides/get-google-api-clientid)
+* [View Dex IdP Documentation](https://dexidp.io/docs/connectors/google/)
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/keycloak.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/keycloak.md
new file mode 100755
index 0000000000..31377c213c
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/keycloak.md
@@ -0,0 +1,155 @@
+---
+id: keycloak
+title: Keycloak
+sidebar_label: Keycloak
+---
+
+# Keycloak
+
+## Prerequisites
+
+* Install and [configure Keycloak](https://www.keycloak.org/guides#getting-started) on your server or cloud environment.
+* Create a new [realm in Keycloak](https://www.keycloak.org/getting-started/getting-started-kube#_create_a_realm) for your application.
+
+---
+
+## Steps on Keycloak Admin Console
+
+### Creating a Client
+
+Here, we will add Devtron as a client for using Keycloak SSO.
+
+1. In the Admin Console, go to **Clients** and click **Create client**.
+
+ 
+
+2. Within **General Settings**:
+ * Enter `devtron` in the **Client ID** field. We will use this ID while configuring SSO later in Devtron.
+ * Enter `Devtron` in the **Name** field.
+
+ 
+
+3. Within **Capability config**, turn on **Client Authentication**.
+
+ 
+
+
+4. Within **Login settings**, enter `https:///orchestrator/api/dex/callback` in the following fields.
+ * **Valid redirect URIs**
+ * **Valid post logout redirect URIs**
+ * **Web origins**
+
+ [Click here](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/global-configurations/sso-login-service/keycloak/base-url.jpg) to know where to find `DEVTRON_BASE_URL`.
+
+ 
+
+5. Click **Save**.
+
+### Getting Client Secret
+
+Here, we will obtain the secret we need while configuring SSO in Devtron.
+
+1. Go to the **Credentials** tab of the client you created.
+
+ 
+
+2. Use the copy button next to the **Client Secret** field and paste it somewhere for future reference.
+
+### Creating Users
+
+Here, we will create a user that can log in to Devtron via SSO. We will assign a username and password that the user can enter while logging in to Devtron via Keycloak SSO.
+
+1. In the Admin Console, go to **Users** and click **Add user**.
+
+2. Give a username (e.g., *usertest*) in the **Username** field and enter the user's email address (e.g., *usertest@example.com*) in the **Email** field.
+
+ 
+
+3. Click **Create**. Your user creation will be successful.
+
+4. Go to the **Credentials** tab of the user you created.
+
+ 
+
+5. Click **Set password**.
+
+6. Enter the password and confirm it.
+
+7. Click **Save**.
+
+### Retrieving Issuer URL
+
+Here, we will obtain the Issuer URL we need while configuring SSO in Devtron.
+
+1. In the Admin Console, go to **Realm settings**.
+
+2. In the **General** tab, scroll down to the **Endpoints** field, and click the **OpenID Endpoint Configuration** link.
+
+ 
+
+3. This will open a new page, copy the value of the key named `issuer`, and paste it somewhere for future reference.
+
+ 
+
+---
+
+## Steps on Devtron
+
+### Configuring OIDC SSO
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to configure SSO.
+:::
+
+Here, we will set up an OIDC SSO and enter the values we obtained in the [previous section](#steps-on-keycloak-admin-console).
+
+1. Go to **Global Configurations** → **Authorization** → **SSO Login Services** → **OIDC**.
+
+ 
+
+2. Below the URL field, take the help of the **Click to use** option to populate the exact URL if the displayed one is incorrect.
+
+ 
+
+3. In the **Configuration** editor, do the following:
+ * In the `issuer` field, paste the URL you got while [retrieving issuer URL](#retrieving-issuer-url).
+ * In the `clientID` field, paste the ID you entered while [creating the client](#creating-a-client).
+ * In the `clientSecret` field, paste the secret you got under [client credentials tab](#getting-client-secret).
+ * In the `redirectURI` field, make sure to enter the same redirect URI you gave in step 4 of [client creation](#creating-a-client).
+
+ 
+
+4. Click **Save** or **Update** to activate Keycloak SSO login.
+
+### Adding Users
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to add users.
+:::
+
+Here, we will add the user we created in the Keycloak Admin Console. If this step is skipped, the user might not be able to log in to Devtron via Keycloak.
+
+1. Go to **Global Configurations** → **Authorization** → **User Permissions**.
+
+2. Click **+ Add Users**.
+
+ 
+
+3. In the **Email addresses** field, enter the email address of the user you created in Keycloak.
+
+ 
+
+4. Assign necessary permissions to this new user. Refer [user permissions](../user-access.md) to know more.
+
+5. Click **Save**.
+
+Now, you may log out and test the Keycloak OIDC login method using the [user credentials](#creating-users). Clicking the **Login with Oidc** button will land you on Keycloak's login page.
+
+
+
+
+
+
+:::caution Note
+Kindly get in touch with us if you encounter any issues while logging out of Keycloak on Devtron as it might be buggy.
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/ldap.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/ldap.md
new file mode 100755
index 0000000000..28ebdd8308
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/ldap.md
@@ -0,0 +1,56 @@
+---
+id: ldap
+title: LDAP
+sidebar_label: LDAP
+---
+
+# LDAP
+
+## Sample Configuration
+
+
+
+---
+
+## Values to fetch from LDAP
+
+Devtron provides a sample configuration out of the box. Here are some values you need to fetch from your LDAP.
+
+* bindDN
+* bindPW
+* baseDN
+
+---
+
+## Reference
+
+[What is LDAP](https://www.okta.com/identity-101/what-is-ldap/)
+
+---
+
+## Auto-assign Permissions
+
+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 [Permission Groups](../permission-groups.md) 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 [individual permissions for users](../user-access.md) mapped to a permission group.
+
+:::caution
+SSO login requires exact matching between Devtron permission group names and LDAP user groups. Any discrepancies or missing groups will prevent successful login.
+
+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 [Permission Groups](../permission-groups.md) linked to LDAP user groups.
+:::
+
+:::info
+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.
+:::
+
+
+
+
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/microsoft.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/microsoft.md
new file mode 100755
index 0000000000..fcdcbfad37
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/microsoft.md
@@ -0,0 +1,76 @@
+---
+id: microsoft
+title: Microsoft
+sidebar_label: Microsoft
+---
+
+# Microsoft
+
+## Sample Configuration
+
+
+
+---
+
+## Values You Would Require at SSO Provider
+
+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.
+
+### Values to Fetch
+
+* clientID
+
+* tenantID (required only if you want to use Azure AD for auto-assigning permissions)
+
+ 
+
+* clientSecret
+
+ 
+
+### Values to Provide
+
+* redirectURI (provided in SSO Login Services by Devtron)
+
+ 
+
+ 
+
+---
+
+## Reference
+
+* [View Microsoft Documentation](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app)
+
+* [View Dex IdP Documentation](https://dexidp.io/docs/connectors/microsoft/)
+
+---
+
+## Auto-assign Permissions
+
+:::info
+Make sure to add tenantID in the SSO configuration field without fail.
+:::
+
+Since Microsoft supports Active Directory (AD)
+, 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 [Permission Groups](../permission-groups.md) 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 [individual permissions for users](../user-access.md) mapped to a permission group.
+
+:::caution
+SSO login requires exact matching between Devtron permission group names and AD groups. Any discrepancies or missing groups will prevent successful login.
+
+Once you save the configuration with this feature enabled, existing user permissions will be cleared and the future permissions will be managed through [permission groups](../permission-groups.md) linked to Azure Active Directory (Microsoft Entra ID) groups.
+:::
+
+:::info
+If your AD permissions aren't reflecting in Devtron, a quick sign-out and sign-in can resolve the issue.
+:::
+
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/oidc.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/oidc.md
new file mode 100755
index 0000000000..8fa64686c5
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/oidc.md
@@ -0,0 +1,57 @@
+---
+id: oidc
+title: OIDC
+sidebar_label: OIDC
+---
+
+# OIDC
+
+## Sample Configuration
+
+
+
+---
+
+## Values You Would Require at SSO Provider
+
+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.
+
+### Values to Fetch
+
+* clientID
+
+* clientSecret
+
+ 
+
+### Values to Provide
+
+* redirectURI (provided in SSO Login Services by Devtron)
+
+ 
+
+ 
+
+---
+
+## Reference
+
+* [View Okta Documentation](https://developer.okta.com/docs/guides/find-your-app-credentials/main/)
+
+* [Configure Keycloak SSO](../sso/keycloak.md)
+
+* [Configure Okta SSO](../sso/okta.md)
+
+* [View Dex IdP Documentation](https://dexidp.io/docs/connectors/oidc/)
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/okta.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/okta.md
new file mode 100755
index 0000000000..4fd21638d1
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/okta.md
@@ -0,0 +1,106 @@
+---
+id: okta
+title: Okta
+sidebar_label: Okta
+---
+
+# Okta
+
+## Prerequisites
+
+A verified account on [Okta](https://www.okta.com/). Okta activates your account only if email verification is successful.
+
+Here's a reference guide to set up your Okta org and application: [Link](https://developer.okta.com/docs/guides/oie-embedded-common-org-setup/go/main/)
+
+:::caution Who Can Perform This Action?
+Only super admin users can set up SSO providers.
+:::
+
+## Tutorial
+
+
+
+## Steps on Okta Admin Console
+
+Once your Okta org is set up, create an app integration on Okta to get a Client ID and Client Secret.
+
+1. In the Admin Console, go to **Applications** → **Applications**.
+
+2. Click **Create App Integration**.
+
+3. Select **OIDC - OpenID Connect** as the **Sign-in method**. [Click here](https://www.okta.com/openid-connect/) to read more.
+
+4. Select **Web** as the application type and click **Next**.
+
+5. 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 → Authorization → 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**.
+
+6. 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.
+
+
+## Steps on Devtron
+
+1. Go to the **Global Configurations** → **Authorization** → **SSO Login Services** → **OIDC**.
+2. In the **URL** field, enter the Devtron application URL (a valid https link) where it is hosted.
+3. Under `Configuration` tab, locate the config object, and provide the `clientID` and `clientSecret` of the app integration you created on Okta.
+4. 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](https://dexidp.io/docs/connectors/oidc/).
+5. Provide `issuer` value as `https://${yourOktaDomain}`. Replace `${yourOktaDomain}` with your domain on Okta as shown in the video.
+6. 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).
+7. Click **Save** to create and activate Okta SSO login.
+
+### Sample Configuration
+
+
+
+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.
+
+## Auto-assign Permissions
+
+:::caution Prerequisites
+In order to auto-assign feature to work
+
+1. A groups claim is configured in the authorization server, so that group information is included in the token. Refer to [Add a groups claim in Okta](https://developer.okta.com/docs/guides/customize-tokens-groups-claim/main/#add-a-groups-claim-for-the-org-authorization-server) to learn more.
+
+2. The required groups are created in Okta Universal Directory. Refer [Create a group in Okta](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-groups-create.htm) to learn more.
+
+3. Relevant users are added to these groups. Refer [Add Users to Okta groups](https://support.okta.com/help/s/article/adding-users-to-okta-groups?language=en_US) to learn more.
+
+:::
+
+Since Okta provides centralized user management through its Universal Directory, this feature further simplifies the onboarding process of organizations with a large number of users. It also eliminates repetitive permission assignment by automatically mapping your Okta groups to Devtron’s Permission Groups during single sign-on (SSO) login.
+
+If you’ve defined groups in your Okta Universal Directory, you can create corresponding permission groups in Devtron with the same names. When members of those Okta 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 individual permissions for users mapped to a permission group.
+
+### Enable Auto-Assign Permissions
+
+1. Go to the **Global Configurations** → **Authorization** → **SSO Login Services** → **OIDC**.
+
+2. Add a key `insecureEnableGroups: true` as shown in the image below. Note that this key is only required for Okta SSO. For other types of OIDC SSO, refer [OIDC supported configurations](https://dexidp.io/docs/connectors/oidc/).
+
+3. Enable the toggle for **Auto-assign permission to users on SSO login**.
+
+4. Click **Update**.
+
+
+
+:::caution Note
+SSO login requires exact matching between Devtron permission group names and Okta groups. Any discrepancies or missing groups will prevent successful login.
+
+Once you save the configuration with this feature enabled, existing user permissions will be cleared and the future permissions will be managed through [permission groups](../permission-groups.md) linked to Okta groups.
+:::
+
+:::info Tip
+If your Okta groups permissions aren't reflecting in Devtron, a quick sign-out and sign-in can resolve the issue.
+:::
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/openshift.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/openshift.md
new file mode 100755
index 0000000000..d8b156728e
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/sso/openshift.md
@@ -0,0 +1,50 @@
+---
+id: openshift
+title: Openshift
+sidebar_label: Openshift
+---
+
+# Openshift
+
+## Sample Configuration
+
+
+
+---
+
+## Values You Would Require at SSO Provider
+
+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.
+
+### Values to Fetch
+
+* clientID
+
+ 
+
+* clientSecret
+
+ 
+
+### Values to Provide
+
+* redirectURI (already provided in SSO Login Services by Devtron)
+
+ 
+
+ 
+
+---
+
+## Reference
+
+* [View Openshift Documentation](https://docs.openshift.com/container-platform/4.14/authentication/configuring-oauth-clients.html)
+
+* [View Dex IdP Documentation](https://dexidp.io/docs/connectors/openshift/)
+
+
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/authorization/user-access.md b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/user-access.md
new file mode 100755
index 0000000000..cfdc5cd594
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/authorization/user-access.md
@@ -0,0 +1,457 @@
+---
+id: user-access
+title: User Permissions
+sidebar_label: User Permissions
+---
+
+# User Permissions
+
+## Introduction
+
+Here you can manage who can access your Devtron instance and what actions they can perform. Use this section to add team members, assign them roles, and control their access by granting fine-grained permissions. Moreover, you can also download all user data in a CSV format.
+
+
+
+---
+
+## Add Users
+
+:::danger Mandatory Action
+This is a mandatory step after configuring SSO in Devtron; otherwise, your users won't be able to log in to Devtron via SSO.
+:::
+
+:::caution Who Can Perform This Action?
+Only managers and super-admins can add users.
+:::
+
+1. Go to **Global Configurations** → **Authorization** → **User Permissions**.
+
+ 
+
+2. Click **Add Users**.
+
+ 
+
+3. In the **Email addresses** field, type the email address of the user you wish to add. You may add more than one email address.
+
+ 
+
+4. (Optional) From the **Assign user groups** dropdown, you may assign one or more user groups to the user. This helps in identifying the group/team to which the user belongs (e.g., Security Team, Frontend Team, Department Leads) especially when adding larger teams.
+
+ 
+
+5. There are two types of permissions in Devtron (click the links below to learn more):
+ * [Super admin permission](#grant-super-admin-permission) for granting full access.
+ * [Specific permissions](#grant-specific-permissions) for granting cherry-picked access.
+
+ 
+
+6. Click **Save**. You have successfully added your user(s).
+
+---
+
+## Grant Super Admin Permission
+
+
+
+Super-Admins have unrestricted access to all Devtron resources. They can create, modify, delete, and manage any resource, including user access, Git repositories, container registries, clusters, and environments. Before assigning this permission, please note:
+
+* Selecting this option will grant the user full access to all the resources.
+
+* Since super-admin permission is the highest level of access you can grant, we recommend you give it only to limited users.
+
+* You can revoke a user's super-admin access at any time and restrict it to [specific permissions](#grant-specific-permissions).
+
+---
+
+## Grant Specific Permissions
+
+
+
+### Permission Groups
+
+**Permission Groups** allows you select a group with a predefined set of user permissions, so that the users belonging to the group automatically inherits those permissions. This reduces the need to repeatedly grant permissions each time a user is added.
+
+The **Permission Groups** drop-down box allows you to select from a list of permission groups already created in the [Permission Groups](../authorization/permission-groups.md) page.
+
+
+
+You can select one or more permission groups, and the user will automatically inherit all the permissions to the projects and resources defined for those groups. Once you select permission group(s), assigning direct permissions can be skipped (unless you wish to grant additional permissions).
+
+You can also make users [Active/Inactive](#making-users-activeinactive-) at permission group-level.
+
+:::info What happens when a user has direct permissions as well as permissions inherited from a group?
+If you assign a permission group as well as direct permissions, the user will have the combined permissions of both.
+
+**For example**:
+
+* A user is granted **Build & Deploy** access to three apps via direct permissions.
+
+* The same user is part of a group that has **View only** access to five apps (including those three apps).
+
+* Now, the user will have both **Build & Deploy** and **View only** permissions for those three apps, and just **View only** for the other two.
+
+:::
+
+### Devtron Apps permissions
+
+:::caution Note
+The **Devtron Apps** tab is displayed only when the [Build and Deploy (CI/CD)](../../integrations/build-and-deploy-ci-cd.md) module is installed in your Devtron instance.
+
+:::
+
+The **Devtron Apps** tab allows you to grant user permissions for Devtron applications.
+
+
+
+| Field | Description |
+| --- | --- |
+| **Project** | Select your preferred project from the drop-down box to grant the user access. You can select only one project at a time. **Note**: If you want to select more than one project, then click **Add Permission**. |
+| **Environment** | Select a specific environment or all environments from the drop-down box as per your requirement. **Note**: If you select `All environments`, the user will have access to all the current environments and any new environment which gets associated with the application in the future. |
+| **Application** | Select a specific application or all applications from the drop-down box that is associated with the environment(s) selected in the **Environment** drop-down box, as per your requirement. **Note**: If you select `All applications`, the user will have access to all the current and future applications associated with the project. Moreover, user with access to all applications, can create new applications too. |
+| **Role** | Available Roles:
`Base Role`
`Additional Roles`
`Access Manager`
[Click here](#roles-available-for-devtron-apps) to learn more about the role you wish to assign to the user. |
+| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) |
+
+#### Roles available for Devtron Apps
+
+The role-based access for Devtron Apps are as follows:
+
+**Base Role**
+
+* **View only**: Users can view applications and access environments but cannot view sensitive information like secrets used in applications or charts or perform any actions.
+
+* **Build and Deploy**: In addition to **View only** permission, users can build and deploy images of applications in permitted environments.
+
+* **Admin**: Users can create, edit, deploy, and delete permitted applications in permitted projects.
+
+* **Manager**: In addition to **Admin** permission, users can also grant or revoke user access for applications and environments that they manage. The **Manager** role for enterprise users will be deprecated and removed soon. Therefore, we recommend using the **Access Manager** role instead of **Manager** going forward.
+
+* **Additional Roles**
+
+ **Additional Roles** allows you to assign specific permissions to a user beyond their **Base Role**. For example, you can grant a user both the **Build and Deploy** (Base Role) and **Config Approver** permissions (Additional Role). This allows the user to build and deploy images, while also being responsible for approving configuration change requests.
+
+ The following permissions are currently available in **Additional Roles**:
+
+ * **Artifact Promoter**: You can approve the promotion of [artifacts](../../../reference/glossary.md#artifacts) directly to the target CD pipeline. For example, if your application workflow includes three CD pipelines (e.g., dev, qa, and prod) and someone raises a request to bypass dev and qa and deploy the artifact directly to prod, you can approve and perform this action with the **Artifact promoter** permission.
+
+ * **Config Approver**: You can approve configuration change requests for [Deployment Templates](../../creating-application/base-config/deployment-template.md), [ConfigMaps](../../creating-application/base-config/config-maps.md), and [Secrets](../../creating-application/base-config/secrets.md). However, you cannot self-approve your own proposed changes, even if you have the **Config Approver** permission or even the Super Admin access.
+
+ * **Deployment Approver**: You can approve the deployment requests for the selected applications and environments.
+
+You also have the provision of granting Access Manager role to a user. Refer [Access Manager](#access-manager-) to know more.
+
+#### Roles and Scopes
+
+| Role | View | Create | Edit | Delete | Build & Deploy | Approve Images | Approve Config Change | Approve Artifacts | Manage User Access |
+|-----------------------|:----:|:------:|:----:|:------:|:--------------:|:--------------:|:--------------:|:----------------:|:----------------:|
+| **View** | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
+| **Build and Deploy** | ✅ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ |
+| **Admin** | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
+| **Manager** | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ✅ |
+| **Artifact Promoter** | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ |
+| **Configuration Approver** | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ |
+| **Deployment Approver** | ✅ | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
+| **Access Manager** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
+| **Super Admin** | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
+
+### Helm Apps permissions
+
+Here you can grant your user the permissions for Helm apps deployed from Devtron or outside Devtron.
+
+
+
+| Field | Description |
+| --- | --- |
+| **Project** | Select a project from the dropdown list to grant the user access. You can select only one project at a time. **Note**: If you want to select more than one project, then click **Add Permission**. |
+| **Environment or Cluster/Namespace** | Select a specific environment from the dropdown list. **Note**: If you select `All existing + future environments in cluster`, then the user will get access to all the current environments including any new environment which gets associated with the application later. |
+| **Application** | Select a specific helm application or all helm apps from the dropdown list corresponding to your selected environments. **Note**: If `All applications` is selected, the user will have access to all current and future applications associated with the project. |
+| **Permission** | Available Permissions:
`View only`
`View & Edit`
`Admin`
[Click here](#roles-available-for-helm-apps) to learn more about the permission you wish to assign the user. |
+| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) |
+
+#### Roles available for Helm Apps
+
+There are three role-based access levels for Helm Apps:
+
+1. **View only**: Users with this role can only view Helm applications and their configurations but cannot make any modifications.
+2. **View & Edit**: These users can modify the configurations of permitted Helm applications and deploy them.
+3. **Admin**: Users with this role have full access to Helm applications, including the ability to create, manage, and delete applications.
+
+| Role | View | Create | Deploy | Edit | Delete |
+| :---: | :---: | :---: | :---: | :---: | :---: |
+| **View only** | ✅ | ❌ | ❌ | ❌ | ❌ |
+| **View & Edit** | ✅ | ❌ | ✅ | ✅ | ❌ |
+| **Admin** | ✅ | ✅ | ✅ | ✅ | ✅ |
+| **Super Admin** | ✅ | ✅ | ✅ | ✅ | ✅ |
+
+### Jobs permissions
+
+Here you can grant your user the permissions to access the jobs created in Devtron.
+
+
+
+| Field | Description |
+| --- | --- |
+| **Project** | Select a project from the dropdown list to grant the user access. You can select only one project at a time. **Note**: If you want to select more than one project, then click **Add Permission**. |
+| **Job Name** | Select a specific job or choose `All jobs` to grant access to all available jobs within the project. |
+| **Workflow** | Select a specific workflow or `All workflows` to grant access to the workflows containing the job pipelines. |
+| **Environment** | Select a specific environment or `All environments` to grant access to the environments associated with the job(s). |
+| **Role** | Available Roles:
`View only`
`Run job`
`Admin`
[Click here](#roles-available-for-jobs) to learn more about the role you wish to assign the user.|
+| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) |
+
+
+#### Roles available for Jobs
+
+There are three role-based access levels for Jobs:
+
+1. **View only**: Users can view the job workflows and logs but cannot trigger or modify jobs.
+2. **Run Job**: These users can trigger jobs but cannot make modifications to workflows.
+3. **Admin**: Users with this role have full control over jobs, including creating, modifying, and deleting workflows.
+
+| Role | View | Create | Run | Edit | Delete |
+| :---: | :---: | :---: | :---: | :---: | :---: |
+| **View only** | ✅ | ❌ | ❌ | ❌ | ❌ |
+| **Run job** | ✅ | ❌ | ✅ | ❌ | ❌ |
+| **Admin** | ✅ | ✅ | ✅ | ✅ | ✅ |
+| **Super Admin** | ✅ | ✅ | ✅ | ✅ | ✅ |
+
+
+### Kubernetes Resources permissions
+
+:::caution Note
+The 'Kubernetes Resources' tab will be available only if you have super-admin permissions.
+:::
+
+Here you can provide permission to view, inspect, manage, and delete resources in your clusters from [Devtron's Resource Browser](../../resource-browser/README.md).
+
+To grant Kubernetes resource permission, click **Add permission**.
+
+
+
+
+
+
+| Field | Description |
+| --- | --- |
+| **Cluster** | Select a cluster from the dropdown list to which you want to give permission to the user. You can select only one cluster at a time. **Note**: To add another cluster, click **Add another**. |
+| **Namespace** | Select a namespace from the dropdown list. |
+| **API Group** | Select a specific API group or `All API groups` from the dropdown list corresponding to the Kubernetes resource. |
+| **Kind** | Select a kind or `All kind` from the dropdown list corresponding to the Kubernetes resource. |
+| **Resource name** | Select a resource name or `All resources` from the dropdown list to which you want to give permission to the user. |
+| **Role** | Available Roles:
`View`
`Admin`
[Click here](#roles-available-for-kubernetes-resources) to learn more about the role you wish to assign the user. |
+| **Status** | Read: [Making Users Active/Inactive](#at-direct-permissions-level) |
+
+#### Roles available for Kubernetes Resources
+
+There are two role-based access levels for Kubernetes Resources:
+
+1. **View**: Users with this role can inspect Kubernetes resources but cannot make changes.
+2. **Admin**: Users can create, modify, and delete Kubernetes resources within their assigned namespaces and clusters.
+
+| Role | View | Create | Edit | Delete |
+| :---: | :---: | :---: | :---: | :---: |
+| **View** | ✅ | ❌ | ❌ | ❌ |
+| **Admin** | ✅ | ✅ | ✅ | ✅ |
+| **Super Admin** | ✅ | ✅ | ✅ | ✅ |
+
+### Chart Groups permissions
+
+:::caution Note
+The 'Chart Groups' tab will be available only if the [CI/CD module](../../integrations/build-and-deploy-ci-cd.md) is installed.
+:::
+
+Here you can grant your user the permissions for accessing Chart Groups. Note that you can only give users the permission to either create chart groups or edit them, but not both.
+
+
+
+| Action | Permissions |
+| :--- | :--- |
+| **View** | Click the `View` checkbox if you want the user(s) to view only the chart groups. |
+| **Create** | Click the `Create` checkbox if you want the user(s) to create, view, or delete the chart groups. |
+| **Edit** |
**Deny**: Select `Deny` from the dropdown list to restrict the users from editing the chart groups.
**Specific Chart Groups**: Select the `Specific Charts Groups` option from the dropdown list and then select the chart group for which you want to allow users to edit.
|
+
+#### Roles available for Chart Groups
+
+1. **View**: Users can view chart groups but cannot create or edit them.
+2. **Create**: Users can create new chart groups and modify existing ones.
+3. **Edit**: Users can modify chart groups but cannot create new ones.
+
+| Role | View | Create | Deploy | Edit | Delete |
+| :---: | :---: | :---: | :---: | :---: | :---: |
+| **View** | ✅ | ❌ | ❌ | ❌ | ❌ |
+| **Create** | ✅ | ✅ | ❌ | ✅ | ✅ |
+| **Edit** | ✅ | ❌ | ❌ | None/Specific Groups | ❌ |
+| **Super Admin** | ✅ | ✅ | ✅ | ✅ | ✅ |
+
+---
+
+## Access Manager
+
+### Can Manage Access For All Roles (Toggle)
+
+:::caution Who Can Perform This Action?
+Only a [Super Admin](#grant-super-admin-permission) can enable the **Can manage access for all roles** toggle for other users.
+
+:::
+
+
+
+By enabling the **Can manage access for all roles** toggle, you can grant a user the permission to manage access for all roles across Devtron apps, Helm Apps, Jobs, Kubernetes Resources, and Chart Groups. However, they cannot create new users.
+
+By default, this toggle is disabled.
+
+:::caution Important Note
+If you enable the **Can manage access for all roles** toggle for a user, then that user can modify permissions of all the users including super-admins.
+
+:::
+
+### Access Manager (Devtron Apps)
+
+:::caution Who Can Perform This Action?
+Only [Super-Admins](#grant-super-admin-permission) can grant an **Access Manager** role.
+
+:::
+
+
+
+Enabling **Access Manager** for a user allows that user to further grant or change permissions of existing users.
+
+:::caution Important Note
+An Access Manager cannot create other Access Managers or add new users. Creation of new users and Access Manager is restricted only to Super-Admins.
+
+:::
+
+A user who is an Access Manager can grant or change permissions for other existing users only within the permissions assigned to them under the **Access Manager** role in the **Role** drop-down box. For example, refer to the tables below to understand what an Access Manager (User A) is allowed and not allowed to do with the permissions of an existing user (User B).
+
+| Users | Base Role(s) | Access Manager Role(s) |
+|:-----------------------|:----|:------|
+| User A | Admin | View Only |
+| User B | Manager | Not Applicable |
+
+| What's Allowed | What's Not Allowed |
+|:----|:------|
+| **For User A:** Changing User B's **Manager** role to **View Only** role (Manager → View Only) |
Reverting to User B's **Manager** role (View Only → Manager)
Changing User B's **Manager** role to any other role, except for **View Only**
Performing operations beyond the base role (i.e., **Admin**)
Modifying Super-Admin permissions
|
+| **For User B:** Perform the operations under the scope of **Manager** role across Devtron |
Manage user access for other users
Perform operations beyond the base role (i.e., **Manager**)
Modifying Super-Admin permissions
|
+
+:::info Note
+If you need to grant someone global control over modifying the roles of other users, enable the [Can manage access for all roles](#can-manage-access-for-all-roles-toggle) toggle instead.
+
+:::
+
+When enabling the **Access Manager** toggle, make sure to select at least one permission from the checkboxes displayed beneath the toggle to ensure the role is active.
+
+The following permissions are currently available in the Access Manager role:
+
+* **View only**: When selected, this permission allows the Access Manager to grant or revoke View Only access to other users.
+
+* **Build and Deploy**: When selected, this permission allows the Access Manager to grant or revoke Build and Deploy access to other users.
+
+* **Admin**: When selected, this permission allows the Access Manager to grant or revoke Admin access to other users.
+
+* **Config Approver**: When selected, this permission allows the Access Manager to grant or revoke Config Approver access to other users.
+
+* **Artifact promoter**: When selected, this permission allows the Access Manager to grant or revoke Artifact promoter access to other users.
+
+#### Role and Scope
+
+| Role | View | Create | Edit | Delete | Build & Deploy | Approve Images | Approve Config Change | Approve Artifacts | Manage User Access |
+|-----------------------|:----:|:------:|:----:|:------:|:--------------:|:--------------:|:--------------:|:----------------:|:----------------:|
+| **Access Manager** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
+
+:::info Note
+[Raise a feature request on GitHub](https://github.com/devtron-labs/devtron/issues) if:
+
+* You would like to see the **Deployment approver** permission also within the **Access Manager** role.
+
+* You would like to have the app-specific **Access Manager** role (currently available only for Devtron Apps) for Helm apps, Jobs, Kubernetes Resources, or Chart Groups as well.
+
+:::
+
+---
+
+## Making Users Active/Inactive
+
+:::caution Who Can Perform This Action?
+* Super-admins can activate or deactivate users.
+* Managers can activate or deactivate users only if the users has the same or fewer permissions than the manager.
+:::
+
+When working with multiple collaborators in Devtron, you may need to deactivate users who no longer require access and reactivate them when needed. This applies to users of Devtron Apps, Helm Apps, Jobs, and Kubernetes Resources.
+
+
+
+You can manage a user's active status at three levels:
+* [User-level](#at-user-level)
+* [Permission Group-level](#at-permission-group-level)
+* [Direct Permissions-level](#at-direct-permissions-level)
+
+
+### At User level
+
+
+
+* **Active/Activate** - Use this option to activate a deactivated user while retaining their previous roles and permissions.
+* **Inactive/Inactivate** - Use this option to deactivate an existing active user and save the changes. If the user has an ongoing session, they will be logged out permanently on their next action or refresh.
+* **Keep active until** - Use this TTL-based option to keep a user active only till a specified date and time, after which the user is automatically deactivated. The user will not be able to log in to Devtron.
+
+### At Permission Group level
+
+
+
+* **Active/Activate** - Use this option to allow permissions from the group to take effect for the user.
+* **Inactive/Inactivate** - Use this option to prevent permissions from the group from taking effect for the user. However, they can still log in/log out of Devtron if [active at the user-level](#at-user-level).
+* **Keep active until** - Use this TTL-based option to grant group permissions to the user until a set date, after which permission group will become inactive for the user.
+
+### At Direct Permissions level
+
+
+
+* **Active/Activate** - Use this option to grant the project/resource access to the user.
+* **Inactive/Inactivate** - Use this option to revoke the project/resource access from the user. **Note**: The user will still be able to log in/log out of Devtron if [active at user-level](#at-user-level).
+* **Keep active until** - Use this TTL-based option to grant the project/resource access to the user only till a specified date and time, beyond which the user will no longer have access to the project/resource.
+
+---
+
+## Edit User Permissions
+
+:::caution Who Can Perform This Action?
+* Super-admins can edit user permissions.
+* Managers can edit user permissions only if the user has the same or fewer permissions than the manager.
+:::
+
+:::caution Note
+Direct user permissions cannot be edited if you're using [LDAP](./sso/ldap.md)/[Microsoft](./sso/microsoft.md) for SSO with 'auto-assign permission' enabled. Permissions can only be [managed via permission groups](./permission-groups.md#edit-permissions-groups) in such a scenario.
+:::
+
+You can edit the user permissions by clicking the edit icon. Click **Save** after editing the permissions.
+
+
+
+---
+
+## Export User Data to CSV
+
+You may download the user data of current users and deleted users in a CSV format. Broadly, your exported CSV will include:
+
+* User's Email address
+* User ID & Status (Active/Inactive/Deleted)
+* Last Login Time
+* Detailed Permissions
+* Role
+* Timestamps for User Addition, Updation, and Deletion
+
+
+
+---
+
+## Delete Users
+
+:::caution Who Can Perform This Action?
+* Super-admins can delete users.
+* Managers can delete users only if the user has the same or fewer permissions than the manager.
+:::
+
+If you want to delete a user, click **Delete**.
+
+
+
+This will remove the user from the system along with all the permissions granted earlier. The user will no longer be able to log in to Devtron unless added again.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/build-infra.md b/versioned_docs/version-1.7/user-guide/global-configurations/build-infra.md
new file mode 100755
index 0000000000..40b9b66daf
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/build-infra.md
@@ -0,0 +1,235 @@
+---
+id: build-infra
+title: Build Infra
+sidebar_label: Build Infra
+---
+
+
+# Build Infra
+
+## Introduction
+
+The [CI process](../creating-application/workflow/ci-pipeline.md) involves activities that require infra resources such as CPU, memory (RAM), and many more. The amount of resources required depends on the complexity of the application. In other words, large applications require more resources compared to small applications.
+
+Therefore, applying a common infra configuration to all applications is not optimal. Since resources incur heavy costs, it's wise to efficiently allocate resources (*not more, not less*).
+
+With the 'Build Infra' feature, Devtron makes it possible for you to tweak the resources as per the needs of your applications. The build (ci-runner) pod will be scheduled on an available node (considering applied taints and tolerations) in the cluster on which 'Devtron' is installed.
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to configure Build Infra.
+:::
+
+---
+
+## Configure Build Infra
+
+From the left sidebar, go to **Global Configurations** → **Build Infra**.
+
+
+
+Under **Profiles** tab, you will see the [Global Profile](#global-profile) and a list of [Custom Profiles](#creating-custom-profile-) (if they exist). Setting up profiles makes it easier for you to manage the build infra configurations, ensuring its reusability in the long term.
+
+### Global Profile
+
+This contains the default infra configuration applicable to all the applications, be it large or small.
+
+
+
+You may click it to modify the following:
+
+|Field| Description |
+|:---|:---|
+|**CPU**|Processor core allocated to the build process. See [CPU units](#cpu-units).|
+|**Memory**|RAM allocated to the build process. See [memory units](#memory-units).|
+|**Build Timeout**|Max. time limit allocated to the build process. See [timeout units](#timeout-units).|
+|**Node Selector** |Node Selector are key-value pair labels to match Pods with Nodes. To learn more, refer to [nodeSelector](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) page.|
+|**Toleration** |A Toleration allow a pod to be scheduled on a Node that has a matching Taint. To learn more, refer to [Taints and Toleration](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) page.|
+|**ConfigMaps** |Key Value pairs to store non-sensitive configurations. Refer to [ConfigMaps](../creating-application/base-config/config-maps.md).|
+|**Secrets** |Key Value pairs to store sensitive configurations. Refer to [Secrets](../creating-application/base-config/secrets.md).|
+
+:::info Note
+ConfigMaps and Secrets defined here will be used at the time of build, not during deployment.
+:::
+
+
+
+Furthermore, CPU and Memory have 2 fields each:
+
+|Field|Description|
+|:---|:---|
+| **Request** | This field is use to specify the minimum guaranteed amount of CPU/Memory resources your application needs for its CI build. In our example, we required 1500m or 1.5 cores CPU along with 6 GB of RAM.|
+| **Limit** | This field is use to set the maximum amount of CPU/Memory resources the build process can use, even if there is a lot available in the cluster.|
+
+
+### Creating Custom Profile
+
+Instead of global profile, you can create custom profiles having different infra configurations. Example: One profile for Python apps, a second profile for large apps, and a third profile for small apps, and many more.
+
+1. Click **Create Profile**.
+
+ 
+
+2. Enter a name for the profile along with a brief description (optional) and click **Create** button.
+
+ 
+
+3. Your custom profile will appear under the list of custom profiles as shown below.
+
+ 
+
+4. Click on your custom profile; a new page will open displaying the custom runner configuration which is inherited from global profile by default.
+
+ 
+
+5. To modify a specific configuration, click the **edit** icon next to that configuration, and turn off the **Inherit** toggle; this will stop that configuration from being inherited from global profile.
+
+ 
+
+6. Modify the resources according to your use case and click **Save**.
+
+7. Repeat step 5 and 6 to define other resources.
+
+---
+
+## Adding Platform Specific Configurations
+
+Modern applications often need to run on different hardware platforms (architectures), such as `amd64` (x86_64) and `arm64` to support cross-platform compatibility.
+
+[Multi-architecture (multi-arch) builds](https://docs.docker.com/build/building/multi-platform/) enables you to build container images that work seamlessly across multiple platforms.
+
+Optimizing your CI builds for each platform ensures:
+
+ * **Better performance**: Builds are tailored to the capabilities of the target architecture.
+
+ * **Resource efficiency**: Prevents over or under-provisioning, saving costs and improving reliability.
+
+Each platform may have unique requirements for resources like CPU and memory, or they may benefit from different configuration of resources. Thus, Devtron allows defining platform specific configurations within a build infra profile. This ensures each build is executed with the right configurations specific to the target platform.
+
+:::info K8s Driver v/s Container Driver
+ **Platform specific configurations** are only supported for builds executed using the k8s driver.
+
+ When you use the K8s driver, each build for a target platform runs as its own pod within your Kubernetes cluster. This allows you to assign different CPU, memory, and other configurations for each target platform like `amd64` or `arm64`.
+
+ If you use the container driver, all builds run inside a single CI runner pod and share the same configuration, regardless of the target platform while K8s driver.
+
+ :::
+
+To configure platform specific configurations:
+
+1. From the left sidebar, go to **Global Configurations** → **Build Infra**.
+
+2. Select the profile for which you want to configure platform specific configurations.
+
+3. Check the **Use K8s driver for build** and click **+Add Target Platform**; a modal window will open.
+
+4. Under **Select a target platform**, select the platform for which you want to define platform specific configurations.
+ 1. You can choose from `linux/amd64` or `linux/arm64`.
+
+ 2. You can also type to add a new platform.
+
+5. Configure the resources for the specific platform and click **Save**.
+
+6. The platform specific configuration will be available below the runner configuration.
+
+
+
+---
+
+## Attaching Profile
+
+Once you create a profile, attach it to the intended applications, or else the [global profile](#global-profile) will remain applied.
+
+1. Go to the **Applications** tab.
+
+ 
+
+2. Choose an application and click the dropdown below it.
+
+ 
+
+3. Choose the profile you wish to apply from the dropdown.
+
+ 
+
+4. Click **Change** to apply the profile to your application.
+
+ 
+
+
+:::tip Tip
+If you missed creating a profile but selected your application(s), you can use the 'Create Profile' button. This will quickly open a new tab for creating a profile. Once done, you can return and click the refresh icon as shown below.
+:::
+
+
+
+### Performing Bulk Action
+
+If you wish to apply a profile to multiple applications at once, you can do that too.
+
+Simply use the checkboxes to select the applications. You can do this even if there are many applications spanning multiple pages. You will see a draggable floating widget as shown below.
+
+
+
+Select the profile you wish to apply from the dropdown and confirm the changes.
+
+
+
+Once you apply a profile, it will show the count of applications attached to it.
+
+
+
+---
+
+## Editing or Deleting Profile
+
+You can edit or delete a custom profile using the respective icons as shown below.
+
+
+
+If you delete a profile attached to one or more applications, the [global profile](#global-profile) will apply from the next build.
+
+
+
+
+### Need More Options?
+
+If you need extra control on the build infra configuration apart from CPU, memory, and build timeout, feel free to open a [GitHub issue](https://github.com/devtron-labs/devtron/issues) for us to help you.
+
+---
+
+## Extras
+
+### CPU Units
+
+CPU resources are measured in millicore. 1000m or 1000 millicore is equal to 1 core. If a node has 4 cores, the node's CPU capacity would be represented as 4000m.
+
+### Memory Units
+
+Memory is measured in bytes. You can enter memory with suffixes (E, P, T, G, M, K, and Ei, Pi, Ti, Gi, Mi, Ki).
+
+| Symbol | Prefix | Value (Bytes) |
+| ------ | ------ | ------------------------------- |
+| m | - | 0.001 byte |
+| byte | - | 1 byte |
+| k | Kilo | 1,000 bytes |
+| Ki | Kibi | 1,024 bytes |
+| M | Mega | 1,000,000 bytes |
+| Mi | Mebi | 1,048,576 bytes |
+| G | Giga | 1,000,000,000 bytes |
+| Gi | Gibi | 1,073,741,824 bytes |
+| T | Tera | 1,000,000,000,000 bytes |
+| Ti | Tebi | 1,099,511,627,776 bytes |
+| P | Peta | 1,000,000,000,000,000 bytes |
+| Pi | Petabi | 1,125,899,906,842,624 bytes |
+| E | Exa | 1,000,000,000,000,000,000 bytes |
+| Ei | Exabi | 1,152,921,504,606,846,976 bytes |
+
+### Timeout Units
+
+You can specify timeouts in the following units, beyond which the build process would be marked as failed:
+
+* seconds
+* minutes
+* hours
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/catalog-framework.md b/versioned_docs/version-1.7/user-guide/global-configurations/catalog-framework.md
new file mode 100755
index 0000000000..7cde72e9b2
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/catalog-framework.md
@@ -0,0 +1,96 @@
+---
+id: catalog-framework
+title: Catalog Framework
+sidebar_label: Catalog Framework
+---
+
+# Catalog Framework
+
+## Introduction
+
+Ideally, all resources such as microservices, clusters, jobs, pods, etc. should contain detailed information so that its users know what each of those resources do, how to use them, as well as all their technical specs. Access to such data makes it easier for engineers to quickly discover and understand the relevant resources.
+
+To achieve this, Devtron supports a feature known as **Catalog Framework**. Using this, you as a [super-admin](../global-configurations/authorization/user-access.md#devtron-apps-permissions) can decide the data you expect from the managers of different resource types. In other words, you can create a custom JSON schema that would ultimately render a form for the resource owners to fill. Once the form is filled, a GUI output will appear as shown below.
+
+
+
+Currently, Devtron supports catalog framework for the following resource types (a.k.a. resource kind):
+
+* [Devtron applications](../../reference/glossary.md#devtron-apps)
+* [Helm applications](../../reference/glossary.md#helm-apps)
+* [Clusters](../../reference/glossary.md#cluster)
+* [Jobs](../../reference/glossary.md#job)
+
+There are two parts involved in the creation of a desirable resource catalog:
+
+1. [Defining a Schema](#defining-a-schema)
+2. [Filling the Schema-Generated Form](#filling-the-schema-generated-form)
+
+---
+
+## Defining a Schema
+
+:::caution Who Can Perform This Action?
+Only a super-admin can create/edit a schema.
+:::
+
+
+1. Go to **Global Configurations** → **Catalog Framework**.
+
+2. Choose a resource type, for which you wish to define a schema, for e.g., Devtron applications.
+
+ 
+
+3. You can edit the schema name and description.
+
+4. There is a sample schema available for you to create your own customized schema. Using this schema, you can decide the input types that renders within the form, for e.g., a dropdown of enum values, a boolean toggle button, text field, label, and many more.
+
+ 
+
+ 
+
+5. After defining your schema, click **Review Changes**.
+
+6. You get a side-by-side comparison (diff) highlighting the changes you made.
+
+ 
+
+7. Click **Save**.
+
+Similarly, you can define schemas for other resource types.
+
+**Note**: If you edit a field (of an existing schema) for which users have already filled the data, that data will be erased. You will receive a prompt (as shown below) to confirm whether you want to proceed with the changes.
+
+
+
+
+---
+
+## Filling the Schema-Generated Form
+
+Once a catalog schema exists for a resource type, its corresponding form would be available in the overview section of that resource type.
+
+1. Since we defined a schema for Devtron applications in the above example, go to the **Overview** tab of your application (any Devtron application). Click the **Edit** button within the `About` section.
+
+ 
+
+2. The schema created for Devtron applications would render into an empty form as shown below.
+
+ 
+
+3. Fill as many details as an application owner to the best of your knowledge and click **Save**.
+
+ 
+
+4. Your saved data would be visible in a GUI format (and also in JSON format) as shown below.
+
+ 
+
+This catalog data would be visible to all the users who have access to the application, but its data can be edited only by the resource owners (in this case, application admin/managers).
+
+
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/chart-repo.md b/versioned_docs/version-1.7/user-guide/global-configurations/chart-repo.md
new file mode 100755
index 0000000000..f62eacf410
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/chart-repo.md
@@ -0,0 +1,82 @@
+---
+id: chart-repo
+title: Chart Repository
+sidebar_label: Chart Repository
+---
+
+# Chart Repository
+
+## Introduction
+
+A Chart repository is like a library where [Helm charts](../../reference/glossary.md#helm-chartspackages) are stored and shared. It provides a centralized place to store and distribute your Helm charts across environments and teams.
+
+You can add one ore more chart repositories to Devtron. Once added, the charts from these repositories will be available in the **All Charts** section of the [Chart Store](../../user-guide/deploy-chart/README.md). This process may take a few minutes.
+
+By default, Devtron automatically includes a set of built-in chart repositories during installation.
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../global-configurations/authorization/user-access.md#grant-super-admin-permission) can add, update, delete chart repositories.
+
+:::
+
+---
+
+## Add Chart Repository
+
+To add a chart repository, follow the steps below:
+
+1. Navigate to **Global Configurations** → **Chart Repository**.
+
+2. Click **Add repository**.
+
+
+
+3. Provide below information in the following fields:
+
+ 
+
+ | Fields | Description |
+ | --- | --- |
+ | **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`)|
+
+4. Click **Save**.
+
+---
+
+## Update a Chart Repository
+
+To update a chart repository, follow the below steps:
+
+1. Navigate back to **Chart Repositories* page.
+
+2. Select the repository you prefer to update.
+
+ 
+
+3. Modify the repository as per your requirements.
+
+:::info Perform Dry Run
+If you prefer to perform a dry run to validate the chart repository configurations, click **Validate**.
+
+:::
+
+4. Click **Update**.
+
+
+
+---
+
+## Delete a Chart Repository
+
+If you are using an chart repository as your chart source and prefer to delete it, follow the instructions below:
+
+1. Navigate back to **Chart Repositories**.
+
+ 
+
+2. Select your preferred chart repository.
+
+3. Click the **Delete** button.
+
+ The chart repository will be deleted and removed from the **Chart Store** page.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/cluster-and-environments.md b/versioned_docs/version-1.7/user-guide/global-configurations/cluster-and-environments.md
new file mode 100755
index 0000000000..a2b8b69158
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/cluster-and-environments.md
@@ -0,0 +1,586 @@
+---
+id: cluster-and-environments
+title: Clusters and Environments
+sidebar_label: Clusters and Environments
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Clusters and Environments
+
+## Introduction
+
+Devtron allows you to connect and manage your existing Kubernetes clusters by adding them to its platform. Once a cluster is added, you can create different environments within it, making it possible to deploy your applications.
+
+You can add any of the following cluster types:
+* [Kubernetes Cluster](#add-kubernetes-cluster) - If you have access to the cluster, use this option.
+* [Isolated Cluster](#add-isolated-cluster-) - For air-gapped use-cases, use this option.
+
+---
+
+## Add Kubernetes Cluster
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to add a Kubernetes cluster to Devtron.
+:::
+
+
+1. Go to **Global Configurations** → **Clusters & Environments** → **Connect Cluster** (button); a **New Cluster** modal window will appear.
+
+ 
+
+2. Select **Connect Cluster**.
+
+ 
+
+3. You can choose to add your Kubernetes cluster using either of the following methods:
+
+ | Method | Description |
+ | :----------------------------------------------------------------------- | :------------------------------------------------ |
+ | [Server URL & Bearer Token](#add-cluster-using-server-url--bearer-token) | Use Server URL and Bearer Token to add a cluster. |
+ | [Kubeconfig](#add-cluster-using-kubeconfig) | Use `Kubeconfig` file to add a cluster. |
+
+ 
+
+4. Click **Save Cluster** and your cluster will be connected to Devtron.
+
+### Add Cluster Using Server URL & Bearer Token
+
+:::info Note
+Refer to [Get Cluster Credentials](#get-cluster-credentials) to learn the process of getting the Server URL and bearer token.
+:::
+
+1. To add a Kubernetes cluster on Devtron using Server URL and Bearer Token, provide the following information:
+
+ | Field | Description |
+ | :--- | :--- |
+ | **Name** | Enter the name of your cluster. |
+ | **Server URL** | Enter the Server URL of your cluster (with https) **Note**: We recommend using a [self-hosted URL](#benefits-of-self-hosted-url) instead of a cloud-hosted URL. |
+ | **Bearer Token** | Paste the bearer token of your cluster |
+
+ 
+
+2. Complete the remaining steps (optional):
+ * [Choose Connection Type](#choose-method-of-connection-)
+ * [Use Secure TLS Connection](#use-secure-tls-connection)
+ * [Configure Prometheus](#configure-prometheus-enable-application-metrics)
+ * [Assign a Category](#assign-category-to-a-cluster)
+
+:::tip Tip
+If you have a **kubeconfig** file ready, you may skip the above process and refer to [Add Cluster Using Kubeconfig](#add-cluster-using-kubeconfig) instead.
+:::
+
+### Add Cluster Using Kubeconfig
+
+In case you prefer to add clusters using kubeconfig, follow these steps:
+
+1. Copy and paste your kubeconfig file into the editor. Alternatively, you may browse and select the file as well.
+
+ 
+
+2. Click the **Get Cluster** button. This action will display the cluster details alongside the kubeconfig.
+
+ 
+
+3. If your kubeconfig file lists multiple clusters, they will be displayed in the window. Use the checkboxes to select the desired cluster(s) and click **Save**.
+
+ 
+
+4. Click the saved cluster, and complete the remaining steps (optional):
+ * [Choose Connection Type](#choose-method-of-connection-)
+ * [Use Secure TLS Connection](#use-secure-tls-connection)
+ * [Configure Prometheus](#configure-prometheus-enable-application-metrics)
+ * [Assign a category](#assign-category-to-a-cluster)
+
+:::caution Note
+Ensure that the **kubeconfig** file 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.
+:::
+
+### Assign Category to a Cluster
+
+Devtron allows you to assign a category (for e.g. Prod, QA, Dev, or Stage) to your clusters. This enables category-based filtering in the UI, allowing you to determine whether an application is deployed to the Prod, QA, Dev, or Stage environment.
+
+Before assigning a category, you must first add the category. To add a category, refer to the [Adding a Category](#add-category) section to learn more.
+
+To assign a category to a cluster, follow the steps below:
+
+1. Select a category from the dropdown under **Assign Category** and click **Update Cluster**.
+
+ 
+
+2. The selected category will be assigned to the cluster.
+
+ 
+
+
+### Choose Method of Connection
+
+When adding a new cluster to Devtron, you must choose how Devtron will connect to it. There are three connection options available:
+
+#### Direct Connection
+Clusters with a directly accessible API server endpoint, either publicly or via private peering, can be added as Direct Connection clusters.
+* Devtron connects directly without an intermediary.
+* Recommended when the cluster is publicly accessible or has a direct network route from Devtron.
+
+
+
+#### Via Proxy
+
+For security reasons, some Kubernetes clusters are deployed behind a proxy. In this setup, Devtron routes all communication through the specified proxy URL.
+* Use this option when network restrictions require traffic to go through a proxy server.
+* Requires specifying a **Proxy URL** (e.g., `http://proxy.example.org:3128`).
+* **Limitation**: Deployments via [GitOps (ArgoCD)](../../reference/glossary.md#gitops) are not recommended for clusters connected via proxy.
+
+
+
+#### Via SSH Tunnel
+
+When a direct connection isn't possible, Devtron can connect to the Kubernetes cluster through an SSH tunnel, ensuring secure and encrypted communication.
+* Requires:
+ * **SSH Server URL** (e.g., `http://proxy.example.org`).
+ * **Username** for authentication.
+ * **Authentication Method**:
+ * Password
+ * SSH Private Key
+ * Both Password & SSH Private Key
+* **Limitation**: Deployments via [GitOps (ArgoCD)](../../reference/glossary.md#gitops) are **not recommended** for clusters connected via SSH Tunnel.
+
+
+
+
+### Use Secure TLS Connection
+
+For a secure cluster connection, you can opt for TLS connection, where you need to provide Certificate Authority Data, a TLS Key, and a TLS Certificate.
+
+If your cluster is managed (e.g., [EKS](https://aws.amazon.com/eks/), [AKS](https://learn.microsoft.com/en-us/azure/aks/), [GKE](https://cloud.google.com/kubernetes-engine)), you might need to download these certificates from your cloud provider’s dashboard or API.
+
+| Field | Description |
+|--------|------------|
+| **Certificate Authority (CA) Data** | The CA certificate (see: [example](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/global-configurations/cluster-and-environments/kubeconfig-entry.jpg)) used to verify the Kubernetes API server’s identity. |
+| **TLS Key** | The private key associated with the client certificate for authentication. |
+| **TLS Certificate** | The client certificate used to authenticate with the Kubernetes API server. |
+
+
+
+
+### Configure Prometheus (Enable Application Metrics)
+
+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.
+
+Enable application metrics to configure Prometheus as shown below. In case it is not available, make sure to install the **Monitoring (Grafana)** integration from [Devtron Stack Manager](../stack-manager.md) to configure Prometheus.
+
+
+
+Provide the information in the following fields:
+
+| Field | Description |
+| :--- | :--- |
+| **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** | These fields are optional and can be used when you use a customized URL. |
+
+Click **Save Cluster** to save your cluster on Devtron.
+
+---
+
+## Create Kubernetes Cluster
+
+### Prerequisites
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../global-configurations/user-access.md#assign-super-admin-permissions) can add an OCI Registry in Devtron.
+
+:::
+
+To create an EKS cluster, you need:
+
+* [OpenTofu](#install-opentofu) (`tofu-controller`) chart installed in your Devtron instance.
+
+ Refer to [Getting Started with OpenTofu](https://opentofu.org/docs/intro/) for more information.
+
+* [FluxCD controller](#install-fluxcd-controller) (`flux2`) chart installed in your Devtron instance
+
+* [Secret](#create-a-secret) containing AWS credentials
+
+#### Install OpenTofu
+
+Follow the steps mentioned below to install OpenTofu:
+
+1. Navigate to **Global Configurations** → **Container/OCI Registry**.
+
+2. Refer to the following table and enter the information in the appropriate fields:
+
+ | Field | Value |
+ | :--- | :--- |
+ | **Registry provider** | Other |
+ | **Registry type** | Public Registry |
+ | **Name** | `tofu` |
+ | **Registry URL** | `ghcr.io` |
+ | **List of repositories** | `flux-iac/charts/tofu-controller` |
+
+
+
+ 
+
+3. Click **Save**. The `tofu-controller` chart will be displayed in the [Chart Store](../../user-guide/deploy-chart/README.md) page.
+
+4. Navigate to **Chart Store** and search for `tofu-controller` in the search box.
+
+5. Select the chart and click **Configure & Deploy**. The following page will be displayed.
+
+ 
+
+6. Enter the app name (e.g., `tofu-controller`) in the **App Name** field.
+
+7. Select your project in the **Project** drop-down box.
+
+8. Select the environment where you want to deploy the chart in the **Deploy to Environment** drop-down box.
+
+:::caution Important Note
+The environment/namespace where you install OpenTofu must be the same environment/namespace where the FluxCD controller will be installed (the next step) to create the cluster.
+
+:::
+
+9. Choose either **Helm** or **GitOps** [if configured](../../user-guide/global-configurations/gitops.md) as the deployment method.
+
+10. Click **Deploy Chart**. OpenTofu will be installed in your Devtron instance.
+
+Now that OpenTofu is installed, you can [install the FluxCD controller](#install-fluxcd-controller) in your Devtron instance.
+
+#### Install FluxCD Controller
+
+Follow the steps mentioned below to install OpenTofu:
+
+1. Navigate to [Chart Store](../../user-guide/deploy-chart/README.md) and search for `flux2` in the search box.
+
+ 
+
+2. Select the chart and click **Deploy**.
+
+3. Enter the app name (e.g., `tofu2`) in the **App Name** field.
+
+4. Select your project in the **Project** drop-down box.
+
+5. Select the environment where you want to deploy the chart in the **Deploy to Environment** drop-down box.
+
+:::caution Important Note
+The environment/namespace where you install the FluxCD controller must be the same environment/namespace where OpenTofu was installed to create the cluster.
+
+:::
+
+6. Choose either **Helm** or **GitOps** [if configured](../../user-guide/global-configurations/gitops.md) as the deployment method.
+
+7. Click **Deploy Chart**. FluxCD controller will be installed in your Devtron instance.
+
+Now that FluxCD controller is installed, the final prerequisite is to [create a secret](#create-a-secret) containing your AWS credentials.
+
+#### Create a Secret
+
+:::caution Who Can Perform This Action?
+User needs to be an [Admin](../../user-guide/global-configurations/authorization/user-access.md#kubernetes-resources-permissions) of the Kubernetes resource or a [Super-Admin](../../user-guide/global-configurations/authorization/user-access.md#kubernetes-resources-permissions) to create a Secret.
+
+:::
+
+Follow the steps mentioned below to create a secret containing your AWS credentials:
+
+1. Navigate to **Resource Browser**.
+
+2. Click the **default_cluster**.
+
+3. Click **Create Resource**.
+
+4. Copy the YAML snippet given below and paste it in the **Create Kubernetes Resource** page.
+
+ ```yaml
+ apiVersion: v1
+ data:
+ AWS_ACCESS_KEY_ID: SDKDI382DKD0=
+ AWS_SECRET_ACCESS_KEY: YVZsSIEOwcFRSMjlvM2xaUjSIE823J3PT0=
+ kind: Secret
+ metadata:
+ name: tf-aws-creds
+ namespace: your-namespace
+ type: Opaque
+ ```
+
+:::caution Important Note
+* It is recommended to keep the `name` attribute to `tf-aws-creds`. Changing this value might make the secret go unrecognized.
+
+* The secret must be created in the same namespace where OpenTofu and FluxCD controller are installed.
+
+* When creating a secret, kindly ensure that your `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are encoded in base64. Go to [Devtron Base64 Encoder](https://strings.devtron.ai/base64-encoder) to encode your AWS credentials.
+
+:::
+
+5. Enter your AWS access key against the `AWS_ACCESS_KEY_ID` attribute and AWS secret key against the `AWS_SECRET_ACCESS_KEY` attribute. Refer to [Create New Access Keys](https://docs.aws.amazon.com/keyspaces/latest/devguide/create.keypair.html) for more information.
+
+6. Click **Apply**. The secret will be created.
+
+Now that all the prerequisites are met, you can proceed to create a cluster from the **Create Kubernetes Cluster** page.
+
+### Steps
+
+:::caution Who Can Perform This Action?
+Only a [Super-Admin](../global-configurations/user-access.md#assign-super-admin-permissions) can create a Kubernetes cluster.
+
+:::
+
+* Navigate to **Global Configurations** → **Clusters & Environments** → **New Cluster** → **Create Kubernetes Cluster**.
+
+* Refer the following table (containing **mandatory** fields) and enter the details in the corresponding fields:
+
+ | Field | Description |
+ | :--- | :--- |
+ | `Cluster Provider` | Select the type of cluster you'd like to create based on your requirement |
+ | `Name` | Enter the name of your Kubernetes cluster (e.g., `eks-cluster-nonprod` in the case of EKS and `rancher-cluster-qa` in the case of Rancher) |
+ | `Region` | Select the region where your cluster is hosted (e.g., `us-east-1` in the case of EKS and `ap-south-3` in the case of Rancher) Refer to [View cluster details using the AWS Management Console](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-view-clusters.html#emr-view-cluster-console) for more information|
+ | `VPC CIDR` | Enter the [VPC CIDR](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) value. This value determines the number of [pods](../../reference/glossary.md#pod), [nodes](../../reference/glossary.md#nodes), or services your cluster can host (e.g., `10.0.1.6/16`)|
+ | `Authentication Mode` | Select the authentication mode you wish to perform for the cluster
**API_AND_CONFIG_MAP** - Select this if you want to use both the API and the ConfigMap to authenticate who can access the cluster. This option is recommended if you are migrating from the old `aws-auth` ConfigMap method (which is deprecated) to the new API method. Refer to [Grant IAM users access to Kubernetes with EKS access entries](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) for more information.
**API** - Select this if you want to manage access using a single API. This option is recommended as this is the best practice for EKS cluster creation. Refer to [Manage User Access with API](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html) for more information.
**CONFIG MAP** - Select this if you want to rely on the original (but deprecated) way of authentication using `aws-auth` ConfigMap. This option is not recommended anymore. Refer to [Grant IAM users access to Kubernetes. with a ConfigMap.](https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html) for more information.
|
+ | `Enable IRSA` | Turn on this IRSA toggle (IAM Roles for [Service Accounts](https://kubernetes.io/docs/concepts/security/service-accounts/)) if you want your application to securely connect to other AWS services using a service account|
+ | `Allow public access` | Turn on this toggle if you want to allow your [EKS control plane](https://docs.aws.amazon.com/eks/latest/best-practices/control-plane.html) endpoint to be accessed publicly from anywhere without the VPC. It is recommended to keep this toggle disabled |
+ | `Cluster Version` | Select your preferred Kubernetes cluster version. If you are running a live application in a production environment, it is recommended that you select a stable version instead of the latest version |
+
+
+
+ 
+
+
+
+* Refer the following table (containing **optional** fields) and enter the details in the corresponding fields:
+
+ | Field | Description |
+ | :--- | :--- |
+ | `Team` | Select the team whose tag you want to attach to the cluster resources. For example, when you select `qa-team`, it means that the cluster resources (pods, ConfigMaps, etc.) created with this cluster are owned by the QA team |
+ | `Environment` | Select the environment. For example, when you select `qa`, it means that this cluster is a part of the QA environment |
+ | `Availability Zones` | Select availability zones (e.g., `us-east-2b` and `ap-west-1a`) if you prefer to distribute your worker nodes across multiple zones to make your cluster highly available. This means that even if one availability zone goes down (e.g., `us-east-2b`), the other zones (e.g., `ap-west-1a`) keep your cluster up and running |
+ | `Private access CIDRs` | Enter the private access CIDRs (IP addresses that are allowed to reach the API server). If you had turned off the **Allow public access** toggle, then your EKS control plane endpoint would be private. It then becomes crucial to enter the private access CIDRs so that the API server recognizes them and allows them to access the endpoint |
+
+* Click **Create Cluster**.
+
+---
+
+## Add Isolated Cluster
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to add an isolated/air-gapped cluster to Devtron.
+:::
+
+For air-gapped Kubernetes clusters with restricted inbound and outbound traffic, Devtron enables seamless management using isolated clusters. While these are not actual clusters with API endpoints, they provide a convenient way to deploy applications in such environments.
+
+1. On the **New Cluster** modal window, select **Add Isolated Cluster**.
+
+ 
+
+2. Add a cluster name (e.g. *banking-airgapped-cluster*) and click **Save Cluster**.
+
+ 
+
+You have successfully configured an isolated cluster.
+
+
+
+:::info Note
+When you deploy to an isolated environment, Devtron automatically packages application manifests and images into a [Helm chart](../../reference/glossary.md#helm-chartspackages). You can then either:
+* Download and install manually in a fully air-gapped setup.
+* Push it to an [OCI registry](../global-configurations/container-registries.md) (provided pushing of helm package is enabled), allowing manifests to be pulled manually or automatically via Devtron on an air-gapped cluster (if pull access to the OCI registry is available).
+:::
+
+---
+
+## Add Environment to a Cluster
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to add an environment to a cluster.
+:::
+
+After adding a cluster to Devtron ([Kubernetes Cluster](#add-kubernetes-cluster), [Isolated Cluster](#add-isolated-cluster-), and a newly created cluster), initially it has no environments.
+
+1. Select the Cluster to which you want to add an Environment and click **Add Environment**. Alternatively you can also hover over the cluster and click `+` icon (Add Environment icon); an **Add Environment** modal window appears.
+
+ 
+
+ 
+
+2. Fill the following details within the **Add Environment** modal window.
+
+ | Field | Description |
+ | :--- | :--- |
+ | **Environment Name** | Enter a name for your environment. |
+ | **Enter Namespace** | Enter a namespace corresponding to your environment. **Note**: If this namespace does not exist in your cluster, Devtron will create it. If it already exists, Devtron will map the environment to it. |
+ | **Environment Type** | Select your environment type:
`Production`
`Non-production`
Note: Devtron shows deployment metrics (DORA metrics) for environments tagged as `Production` only. |
+
+ 
+
+3. **Assign a Category to environment** - Devtron allows you to assign a category (for e.g. Prod, QA, Dev, or Stage) to your environments. This enables category-based filtering in the UI, allowing you to determine whether an application is deployed to Prod, QA, Dev, or Stage environment.
+ To assign a category to your environment, follow the steps below:
+ 1. Select a category from the dropdown under **Assign Category** and click **Update**.
+
+ 
+
+ 2. The selected category will be assigned to the environment.
+
+ 
+
+ **Note:** Before assigning a category, you must first add the category. To add a category, refer to [Adding a Category](#add-category) section to learn more.
+
+4. **Add/Edit labels to namespace** - You can attach labels to your specified namespace in the Kubernetes cluster. Using labels will help you filter and identify resources via CLI or other Kubernetes tools. [Click here](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to know more about labels.
+
+ 
+
+5. Click **Save**. Your new environment will be visible in your cluster as shown below.
+
+ 
+
+---
+
+## Edit Environment
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to edit an environment in a cluster.
+:::
+
+You can also make edits to an existing environment if needed.
+
+1. Navigate to **Environments** tab.
+
+2. Hover over the environment you wish to edit, and click the **edit** icon.
+
+
+
+3. Edit the environment fields.
+
+| Feature | Editable? |
+| :----------------------------------- | :-------- |
+| **Production/Non-Production Option** | ✅ Yes |
+| **Description** | ✅ Yes |
+| **Labels for Namespace** | ✅ Yes |
+| **Assign a category** | ✅ Yes |
+| **Environment Name** | ❌ No |
+| **Namespace Name** | ❌ No |
+
+4. Click **Update** to save your changes.
+
+
+
+---
+
+## Delete Environment
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to delete an environment from a cluster.
+:::
+
+If an environment is no longer needed, you can delete it by following these steps:
+
+1. Navigate to **Environments** tab.
+
+2. Hover over the environment you wish to remove, and click the **delete** icon.
+
+ 
+
+:::caution Important
+Environment deletion is not allowed if any application has a CD pipeline corresponding to the environment. In such a case, go to [Workflow Editor](../creating-application/workflow/README.md) and delete the deployment pipeline first, and then return to delete the environment. This action is irreversible, so make sure no critical applications or resources depend on the environment before deleting.
+:::
+
+2. A confirmation dialog will appear. Click **Delete** to permanently delete the environment.
+
+ 
+
+---
+
+## Add Category
+
+Before assigning a category, you must first add the category. To add a category, follow the steps below:
+
+1. Go to **Global Configurations**.
+
+ 
+
+2. Select **Clusters and Environments** and click **Manage Categories**, a modal window will open.
+
+ 
+
+3. Enter the name of the category in the **CATEGORIES** field and provide a description in the **DESCRIPTION** field.
+
+ :::info Note:
+ * The category name must be unique and cannot be changed once defined. It should be a minimum of 3 characters.
+ * It can contain alphanumeric characters, but cannot start with a number.
+ * The name should be in lowercase only.
+ :::
+
+ 
+
+4. If you wish to add more categories, click **Add Category**, a new row will appear, enter the name and description of the new category.
+
+ 
+
+5. Click **Update** and your categories will be added.
+
+ 
+
+
+## Delete Category
+
+To delete a category, follow the steps below:
+
+1. Go to **Global Configurations**.
+
+ 
+
+2. Select **Clusters and Environments** and click **Manage Categories**, a modal window will open.
+
+ 
+
+3. Select the `x` icon next to the categories you want to delete.
+
+ **Note**: You cannot delete a category if it is assigned to a cluster or environment.
+
+ 
+
+4. Click **Update** to delete the categories.
+---
+
+## Extras
+
+### Get Cluster Credentials
+
+:::info Prerequisite
+[kubectl](https://kubernetes.io/docs/tasks/tools/) must be installed on the bastion.
+:::
+
+:::info Note
+We recommend using a self-hosted URL instead of a cloud-hosted URL. Refer to the benefits of a [self-hosted URL](#benefits-of-self-hosted-url).
+:::
+
+You can get the **Server URL** and **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:
+```bash
+curl -O https://raw.githubusercontent.com/devtron-labs/utilities/main/kubeconfig-exporter/kubernetes_export_sa.sh && bash kubernetes_export_sa.sh cd-user devtroncd
+```
+
+
+If you are using a **`microk8s cluster`**, run the following command to generate the server URL and bearer token:
+
+```bash
+curl -O https://raw.githubusercontent.com/devtron-labs/utilities/main/kubeconfig-exporter/kubernetes_export_sa.sh && sed -i 's/kubectl/microk8s kubectl/g' \
+kubernetes_export_sa.sh && bash kubernetes_export_sa.sh cd-user \
+devtroncd
+```
+
+
+
+
+
+### Benefits of Self-hosted URL
+
+* **Disaster Recovery**:
+ * You cannot 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 belongs to a single hosted domain independent of the cloud provider.
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/container-registries.md b/versioned_docs/version-1.7/user-guide/global-configurations/container-registries.md
new file mode 100755
index 0000000000..8229bd6028
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/container-registries.md
@@ -0,0 +1,245 @@
+---
+id: container-registries
+title: Container/OCI Registry
+sidebar_label: Container/OCI Registry
+---
+
+# Container/OCI Registry
+
+## Introduction
+
+While [container registries](../../reference/glossary.md#containeroci-registry) are typically used for storing [images](../../reference/glossary.md#image) built by the CI Pipeline, an OCI registry can store container images as well as other artifacts such as [helm charts](../../reference/glossary.md#helm-chartspackages). In other words, all container registries are OCI registries, but not all OCI registries are container registries.
+
+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.
+
+---
+
+## Add Container Registry
+
+### Steps
+
+1. From the left sidebar, go to **Global Configurations** → **Container/OCI Registry**.
+
+ 
+
+2. Click **Add Registry**.
+
+ 
+
+3. Choose a provider from the **Registry provider** dropdown. View the [Supported Registry Providers](#supported-registry-providers).
+
+4. 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.
+
+5. Assuming your registry type is private, here are few of the common fields you can expect:
+
+ | Fields | Description |
+ | --- | --- |
+ | **Name** | Provide a name to your registry, this name will appear in the **Container Registry** drop-down list available within the [Build Configuration](../creating-application/docker-build-configuration.md) 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](#supported-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](#registry-credential-access). |
+ | **Push helm packages** | Tick this checkbox if you wish to [push helm charts to your OCI registry](#push-helm-packages) |
+ | **Use as chart repository** | Tick this checkbox if you want Devtron to pull helm charts from your registry and display them on 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 |
+
+6. Click **Save**.
+
+### Push Helm Packages
+
+Upon enabling this option, Devtron supports the pushing of helm charts to your OCI registry.
+
+This is possible through [isolated clusters](../global-configurations/cluster-and-environments.md#add-isolated-cluster-) that facilitate air-gapped deployments. In other words, it generates a helm package that you can use to deploy your application in air-gapped clusters.
+
+If you have [configured your CD pipeline](../creating-application/workflow/cd-pipeline.md) to push the helm package to your OCI registry, you can view the pushed helm package in your registry as shown below:
+
+
+
+
+
+:::info Prerequisite
+
+OCI registry with `Use as chart repository` option enabled.
+
+:::
+
+Unlike Helm repos, OCI registries do not have an index file to discover all the charts. If you have helm packages pushed to your OCI registry, you can that registry as a chart repository.
+
+Upon enabling this option, Devtron can use your OCI registry as the chart source and pull the helm charts to display them on your [Chart Store](../deploy-chart/README.md) for easy deployment.
+
+#### Tutorial
+
+
+
+#### Steps
+
+Search your OCI registry in the list and click it.
+
+In the **List of repositories** field, add your chart repo(s). You can [find the username](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/use-cases/oci-pull/find-username.jpg) from your registry provider account.
+
+
+
+## Supported Registry Providers
+
+### ECR
+
+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.
+
+Before you begin, create an [IAM user](https://docs.aws.amazon.com/AmazonECR/latest/userguide/get-set-up-for-amazon-ecr.html) and attach the ECR policy according to the authentication type.
+
+Provide the following additional information apart from the common fields:
+
+| Fields | Description |
+| --- | --- |
+| **Registry URL** | Example of URL format: `xxxxxxxxxxxx.dkr.ecr..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](https://docs.aws.amazon.com/AmazonECR/latest/userguide/get-set-up-for-amazon-ecr.html).
`Access key ID`: Your AWS access key
`Secret access key`: Your AWS secret access key ID
|
+
+
+### Docker
+
+Provide the following additional information apart from the common fields:
+
+| Fields | Description |
+| --- | --- |
+| **Username** | Provide the username of the Docker Hub account you used for creating your registry. |
+| **Password/Token** | Provide the password/[Token](https://docs.docker.com/docker-hub/access-tokens/) corresponding to your docker hub account. It is recommended to use `Token` for security purpose. |
+
+
+### Azure
+
+For Azure, the service principal authentication method can be used to authenticate with username and password. Visit this [link](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-auth-service-principal) to get the username and password for this registry.
+
+Provide the following additional information apart from the common fields:
+
+| Fields | Description |
+| --- | --- |
+| **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 |
+
+
+### Artifact Registry (GCP)
+
+JSON key file authentication method can be used to authenticate with username and service account JSON file. Visit this [link](https://cloud.google.com/artifact-registry/docs/docker/authentication#json-key) to get the username and service account JSON file for this registry.
+
+:::caution
+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:
+
+| Fields | Description |
+| --- | --- |
+| **Registry URL** | Example of URL format: `region-docker.pkg.dev` |
+| **Service Account JSON File** | Paste the content of the service account JSON file |
+
+
+### Google Container Registry (GCR)
+
+JSON key file authentication method can be used to authenticate with username and service account JSON file. Please follow [link](https://cloud.google.com/container-registry/docs/advanced-authentication#json-key) to get the username and service account JSON file for this registry.
+
+:::caution
+Remove all the white spaces from JSON key and wrap it in single quote before pasting it in `Service Account JSON File` field
+:::
+
+### Quay
+
+Provide the following additional information apart from the common fields:
+
+| Fields | Description |
+| --- | --- |
+| **Username** | Provide the username of your Quay account |
+| **Token** | Provide the password of your Quay account |
+
+
+### Other
+
+Provide below information if you select the registry type as `Other`.
+
+| Fields | Description |
+| --- | --- |
+| **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)
|
+
+:::info
+You can use any registry which can be authenticated using `docker login -u -p `. However these registries might provide a more secured way for authentication, which we will support later.
+:::
+
+
+## Registry Credential Access
+
+You can create a Pod that uses a [Secret](../../reference/glossary.md#secrets) to pull an image from a private container registry. You can use any private container registry of your choice, for e.g., [Docker Hub](https://www.docker.com/products/docker-hub).
+
+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.
+
+1. To manage the access of registry credentials, click **Manage**.
+
+There are two options to manage the access of registry credentials:
+
+| Fields | Description |
+| --- | --- |
+| **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 |
+
+2. You can choose one of the two options for defining credentials:
+
+* [Use Registry Credentials](#use-registry-credentials)
+* [Specify Image Pull Secret](#specify-image-pull-secret)
+
+### Use Registry 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**.
+
+
+
+
+### Specify Image Pull Secret
+
+You can create a Secret by providing credentials on the command line.
+
+
+
+Create this Secret and name it `regcred` (let's say):
+
+```bash
+kubectl create -n secret docker-registry regcred --docker-server= --docker-username= --docker-password= --docker-email=
+```
+
+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`.
+
+:::caution
+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**.
+
+## Delete an OCI Registry
+
+If you prefer to delete an OCI registry, follow the instructions below:
+
+1. Navigate back to **Container/OCI Registry** page.
+
+ 
+
+2. Select your preferred OCI registry.
+
+3. Click the **Delete** button. The OCI registry will be deleted.
+
+:::caution Important Note
+If you used an OCI registry as a chart source, deleting the OCI registry will remove all its associated charts from the Chart Store.
+
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/deployment-charts.md b/versioned_docs/version-1.7/user-guide/global-configurations/deployment-charts.md
new file mode 100755
index 0000000000..170f132733
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/deployment-charts.md
@@ -0,0 +1,288 @@
+---
+id: deployment-charts
+title: Deployment Charts
+sidebar_label: Deployment Charts
+---
+
+# Deployment Charts
+
+## Introduction
+
+Devtron Apps leverage helm charts to carry out deployment of your images and configuration. Devtron includes predefined Helm charts (e.g., Deployment, Rollout, StatefulSet) that cover majority of your 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 deployment chart in Devtron.
+
+
+
+### Tutorial
+
+This video contains a quick walkthrough of the steps mentioned in the [Preparing a Deployment Chart](#preparing-a-deployment-chart) section of this page and the subsequent uploading of the deployment chart on Devtron.
+
+
+
+---
+
+
+
+## Preparing a Deployment Chart
+
+Below is the 5-step prerequisite you can follow to have your chart ready for uploading.
+
+### 1. Create a Helm Chart
+
+You can use the following command to create a Helm chart:
+
+```bash
+helm create my-custom-chart
+```
+
+> **Note**: `Chart.yaml` is a metadata file that gets created when you create a [helm chart](https://helm.sh/docs/helm/helm_create/). The following table consists the fields that are relevant to you in `Chart.yaml`.
+
+| Field | Description |
+| --- | --- |
+| `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` | Give a description to your chart (Optional). |
+
+:::info Example of Chart.yaml
+[Click here](https://devtron-public-asset.s3.us-east-2.amazonaws.com/custom-charts/chart-yaml-file.jpg) to view a sample 'Chart.yaml' file.
+:::
+
+### 2. Create an Image Descriptor Template File
+
+The Image Descriptor Template file is a GO template that produces a valid JSON file upon processing. It allows Devtron to dynamically inject values from the CD pipeline into your Helm chart during deployment. Therefore, details like image repository, tag, and environment are automatically populated at the placeholders specified in `.image_descriptor_template.json`.
+
+* In the root directory of your chart, create a file named `.image_descriptor_template.json` using the following command:
+
+ ```bash
+ touch .image_descriptor_template.json
+ ```
+
+* Ensure the above file is created in the directory where the main `Chart.yaml` exists (as shown below):
+
+ 
+
+* Paste the following content in `.image_descriptor_template.json` file:
+
+ ```bash
+ {
+ "server": {
+ "deployment": {
+ "image_tag": "{{.Tag}}",
+ "image": "{{.Name}}"
+ }
+ },
+ "pipelineName": "{{.PipelineName}}",
+ "releaseVersion": "{{.ReleaseVersion}}",
+ "deploymentType": "{{.DeploymentType}}",
+ "app": "{{.App}}",
+ "env": "{{.Env}}",
+ "appMetrics": {{.AppMetrics}}
+ }
+ ```
+
+ You can customize this template to include only the values your deployment needs. For instance, if you only require the image repository and tag, your template would look like:
+
+ ```bash
+ {
+ "image": {
+ "repository": "{{.Name}}",
+ "tag": "{{.Tag}}"
+ }
+ }
+ ```
+
+:::caution Got a JSON Error?
+If your code editor highlights a syntax error (property or EOF error) in the above JSON, ignore it.
+:::
+
+
+
+### 3. Add app-values.yaml
+
+In the root directory of your chart, Devtron expects an `app-values.yaml` file. It uses this file to determine the values to be displayed on the [deployment template](../../reference/glossary.md#deployment-template) as shown below.
+
+
+
+The `app-values.yaml` file is simply a subset of your `values.yaml` file. Therefore, you can insert specific entries from `values.yaml` that you wish to display.
+
+However, if you upload the chart without an `app-values.yaml` or with an empty one, your deployment template will appear blank (as shown below) or null.
+
+
+
+
+### 4. Add release-values.yaml
+
+The `release-values.yaml` file contains essential values needed for deployment that aren’t covered by [app-values.yaml](#3-add-app-valuesyaml). For example:
+
+* Some dynamic values (such as `IMAGE_TAG` and `IMAGE_REPO` from the [image descriptor JSON file](#2-create-an-image-descriptor-template-file)) are populated here because they are needed for deployment.
+* You can use `autoPromotionSeconds` to decide how long to keep old pods running once the latest pods of new release are available.
+
+In the root directory of your chart, create a file named `release-values.yaml` with the following command:
+
+```bash
+touch release-values.yaml
+```
+
+Use the following content in the `release-values.yaml` file (edit it as per your requirement):
+
+```yml
+server:
+ deployment:
+ image_tag: IMAGE_TAG
+ image: IMAGE_REPO
+ enabled: false
+dbMigrationConfig:
+ enabled: false
+
+pauseForSecondsBeforeSwitchActive: 0
+waitForSecondsBeforeScalingDown: 0
+autoPromotionSeconds: 30
+
+#used for deployment algo selection
+orchestrator.deploymant.algo: 1
+```
+
+### 5. Package the chart in a tgz format
+
+
+
+The Helm chart to be uploaded must be packaged as a versioned archive file in the format: `-x.x.x.tgz`.
+Both `` and `x.x.x` will be automatically fetched from the name and version fields present in the Chart.yaml file, respectively."
+
+:::caution Note
+Ensure you navigate out of the Helm chart folder before packaging it in a '.tgz' format
+:::
+
+Run the following command to package the chart:
+
+```bash
+helm package my-custom-chart
+```
+
+The above command will generate a `-x.x.x.tgz` file.
+
+---
+
+## Uploading a Deployment Chart
+
+:::caution Who Can Perform This Action?
+Only super admin users can upload a deployment chart. A super admin can upload multiple versions of a chart.
+:::
+
+### Steps
+
+* Go to **Global Configurations** → **Deployment Charts**.
+
+ 
+
+* Click **Upload Chart**.
+
+ 
+
+* Click **Select .tgz file** and upload your packaged deployment chart (in **.tgz** format).
+
+ 
+
+The system initiates the validation of your uploaded chart. You may also click **Cancel upload** if you wish to abort the process.
+
+
+
+### Validation Checks
+
+In the uploading process, your file will be validated against the following criteria:
+
+- Supported archive template should be in `*.tgz` format.
+- `Chart.yaml` must include the name and the version number.
+- `.image_descriptor_template.json` file should be present.
+
+The following are interpretations of the validation checks performed:
+
+| Validation Status | Description | User Action |
+| :--- | :--- | :--- |
+| **Success** | The files uploaded are validated ([View Snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/global-configurations/deployment-charts/chart-success.jpg)) | Enter a description for the chart and select **Save** or **Cancel upload** |
+| **Unsupported template** | The archive file do not match the [required template](#preparing-a-deployment-chart) ([View Snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/global-configurations/deployment-charts/unsupported-template.jpg)) | **Upload another chart** or **Cancel upload** |
+| **New version detected** | You are uploading a newer version of an existing chart ([View Snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/global-configurations/deployment-charts/new-version.jpg)) | Enter a **Description** and select **Save** to continue uploading, or **Cancel upload** |
+| **Already exists** | There already exists a chart with the same version ([View Snapshot](https://devtron-public-asset.s3.us-east-2.amazonaws.com/images/global-configurations/deployment-charts/chart-exists.jpg)) |
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**
|
+
+---
+
+## Viewing Deployment Charts
+
+:::caution Who Can Perform This Action?
+Only super-admins can view deployment charts.
+:::
+
+To view the list of available deployment charts, go to **Global Configurations** → **Deployment Charts** page.
+
+
+
+* You can search a chart by its name, version, or description.
+* You can add new [charts or chart versions](#uploading-a-deployment-chart) by clicking **Upload Chart**.
+
+---
+
+## Using Deployment Chart in Application
+
+Once you successfully upload a deployment chart, you can start using it as a deployment template for your application. Refer [Deployment Template](../creating-application/base-config/deployment-template.md) to know more.
+
+
+
+:::caution Note
+The deployment strategy for a deployment chart is fetched from the chart template and cannot be configured in the [CD pipeline](../creating-application/workflow/cd-pipeline.md#deployment-strategies).
+:::
+
+---
+
+## Editing GUI Schema of Deployment Charts
+
+:::caution Who Can Perform This Action?
+Only super-admins can edit the GUI schema of deployment charts.
+:::
+
+:::info Reference
+This section is an extension of [Customize GUI](../creating-application/base-config/deployment-template.md#using-gui) feature. Refer the document to know more about the significance of having a custom GUI schema for your deployment templates.
+:::
+
+You can edit the GUI schema of the following deployment charts:
+1. Default charts provided by Devtron (*Deployment*, *Job & CronJob*, *Rollout Deployment*, and *StatefulSet*)
+2. Custom charts uploaded by you
+
+### Tutorial
+
+
+
+### Steps
+
+In this example, we will edit the Deployment chart type provided by Devtron.
+
+1. Click the edit button next to the chart as shown below.
+
+ 
+
+2. A GUI schema is available for you to edit in case of Devtron charts. In case of custom charts, you may have to define a GUI schema yourself. To know how to create such GUI schema, refer [RJSF JSON Schema Tool](https://rjsf-team.github.io/react-jsonschema-form/).
+
+ 
+
+3. You may start editing the schema by excluding existing fields/objects or including more of them. Click the **Refer YAML** button to view all the supported fields.
+
+ 
+
+4. While editing the schema, you may use the **Preview GUI** option for a real-time preview of your changes.
+
+ 
+
+5. Click **Save Changes**.
+
+ 
+
+Next, if you go to **Configurations** (tab) → **Base Configurations** → **Deployment Template**, you will be able to see the deployment template fields (in GUI) as per your customized schema.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/deployment-window.md b/versioned_docs/version-1.7/user-guide/global-configurations/deployment-window.md
new file mode 100755
index 0000000000..4aa00c7cae
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/deployment-window.md
@@ -0,0 +1,318 @@
+---
+id: deployment-window
+title: Deployment Window
+sidebar_label: Deployment Window
+---
+
+# Deployment Window
+
+## Introduction
+
+Unplanned or last minute deployments of applications can affect the services of an organization. Consequently, its business impact will be severe if such disruptions occur during peak hours or critical periods (say festive season or no deployment on Fridays).
+
+Therefore, Devtron comes with a feature called 'Deployment Window' that allows you to define specific timeframes during which application deployments are either blocked or allowed in specific environments. Moreover, actions that can potentially impact the existing deployment are also restricted, which include:
+
+* [Hibernation](#hibernation)
+* [Restart Workloads](#restart-workloads)
+* [Deletion of Workloads](#deletion-of-workloads)
+* [Deployment](#deployment)
+* [Rollback](#rollback)
+* [Deletion of CD Pipeline](#deletion-of-cd-pipeline)
+
+However, exempted users can still perform the above actions even during blocked periods.
+
+
+
+### Types of Deployment Window
+
+| Name | Blackout Window | Maintenance Window |
+| --------------------- | ---------------------------------------------------|--------------------|
+| **Definition** | Time period during which deployments are not allowed | Only time period during deployments are allowed |
+| **Use** | To block deployments when systems are already stable and running a critical business in peak hours | To allow deployments preferably during non-business hours so as to minimize any negative impact on end-users |
+| **In case of overlap?** | Blackout window gets a higher priority over maintenance window | Maintenance window has a lower priority |
+
+
+### Difference between a Blackout Window and Maintenance Window
+
+Technically, both of them are different methods of restricting deployments to an environment. For example, specifying either a blackout window of [8:00 AM to 10:00 PM] or a maintenance window of [10:00 PM to 8:00 AM] essentially does the same job. You can define either of them depending on your use case.
+
+---
+
+## Configuring Deployment Window
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to configure deployment window.
+:::
+
+Go to **Global Configurations** → **Deployment Window**.
+
+
+
+This involves two parts:
+* [Creating Deployment Window](#creating-deployment-window)
+* [Applying Window to Deployment Pipelines](#applying-window-to-deployment-pipelines)
+
+### Creating Deployment Window
+
+This involves the process of creating a blackout window or a maintenance window.
+
+1. In the `Windows` tab, click **+ Add Window**.
+
+ 
+
+2. Give an appropriate name to your deployment window (e.g., *weekend restrictions*) and write a brief description that explains what the deployment window does. Refer [this section](#checking-deployment-window) to view the pages where the window name and description will appear.
+
+ 
+
+3. Choose a deployment window type, i.e., maintenance window or blackout window.
+
+ 
+
+4. In your deployment window, make sure to choose the correct time zone (by default it is determined from the browser you use).
+
+ 
+
+:::info Why Time Zone?
+Let's say you are a super-admin located in New Delhi (GMT +5:30) and you wish to restrict midnight deployments according to the Californian timings (GMT -07:00) for your team in the US. Therefore, it's crucial to choose the correct time zone (i.e., GMT -07:00) and then add the duration (see next steps).
+
+This ensures that deployments occur at the intended local time, helping to avoid disruptions, and facilitating co-ordinated operations across different regions.
+:::
+
+4. Click **+ Add duration**.
+
+ 
+
+5. The following options are available for you to enforce the deployment window:
+ * **Once**: Use this to make your deployment window active between two specific date and time, e.g., 20 Jun 2024, 08:00 PM ➝ 26 Jun 2024, 05:00 PM
+ * **Daily**: Use this to make your deployment window active everyday between specific timings, e.g., daily between 12:00 AM ➝ 06:00 AM
+ * **Weekly**: On selected days at specific timings, e.g., Wed and Sun • 02:00 AM ➝ 05:30 AM
+ * **Weekly Range**: Between days of the week, e.g., Mon (02:00 AM) to Fri (05:30 AM)
+ * **Monthly**: On or between days of the month, e.g., Day 1 (10:30 PM) to Day 2 (06:30 AM)
+
+ 
+
+You can also add **Start Date** and **End Date** to your recurring deployment window.
+
+| Option | When To Use |
+|---------------------------|----------------------------------------------------------------------------------|
+| Start Date | Use this to enforce restrictions of a deployment window only after a specific date|
+| End Date | Use this to stop restrictions of a deployment window beyond a specific date |
+| Both Start Date and End Date | Use these to confine your deployment window restrictions between two dates |
+
+Let's say you wish to enforce a blackout window every weekend to prevent unsolicited deployments by your team. If you select a weekly range (e.g., Saturday 12:00 AM to Monday 12:00 AM) and apply the deployment window without specifying dates, the weekend restrictions will persist indefinitely.
+
+However, by specifying a start date and an end date (as shown below), your deployment window will have a defined validity period. This ensures that the deployment window restrictions are temporary and do not extend beyond the intended timeframe.
+
+
+
+:::info
+After clicking **Done**, you can use the **+ Add duration** button to add more than one duration (for e.g., one monthly and one weekly) in a given deployment window.
+:::
+
+6. You can also determine the users who can take actions (say deployment) even when restrictions are in place. These can be super-admins, specific users, both, or none.
+
+ 
+
+7. Enter a display message to show the user whose deployment gets blocked, e.g., *Try deploying on Monday - Weekend deployment is not a best practice - Contact your Admin*. This will help the user understand the restriction better.
+
+ 
+
+8. Click **Save Changes**.
+
+If required, you can edit a deployment window to modify it as shown below.
+
+
+
+You may delete a deployment window if it's not needed anymore. If the deployment window was applied to any deployment pipeline (application + environment), the restrictions would no longer exist.
+
+
+
+
+### Applying Window to Deployment Pipelines
+
+This involves the process of applying the deployment window you created above to your deployment pipeline(s).
+
+1. Go to the **Apply To** tab and click the **No windows** dropdown next to the [application + environment] you wish to apply deployment window(s).
+
+ 
+
+2. Select the deployment windows from the dropdown and click **Save Changes**.
+
+#### Bulk Apply
+
+1. If you wish to apply deployment windows to multiple applications and environments at once, use the checkbox.
+
+ 
+
+ We recommend you to use the available filters (Application, Environment, Deployment Window) to simplify the process of application + environment selection.
+
+ 
+
+ 
+
+2. On the floating widget, click **Manage Windows**.
+
+ 
+
+3. Click the **Add Deployment Windows** dropdown to choose the deployment window(s).
+
+ 
+
+4. Use the **Review Changes** option to confirm the impacted environment(s) and click **Save**.
+
+ 
+
+You can remove deployment window(s) applied to one or more deployment pipelines as shown below.
+
+
+
+
+
+---
+
+## Checking Deployment Window
+
+:::caution Who Can Perform This Action?
+Users with view only permission or above for an application can view all deployment windows configured for its deployment pipelines.
+:::
+
+### Overview Page
+
+The **Deployment window** section shows the blackout and maintenance windows configured for each [environment](../../reference/glossary.md#environment) of the application.
+
+
+
+However, if a deployment window doesn't exist for an environment, the message `No deployment windows are configured` would be displayed next to it.
+
+You may click the dropdown icon to view the details which include:
+* Type of deployment window (Blackout/Maintenance)
+* Name and description
+* Frequency of window (once, weekly, monthly, yearly)
+* Duration
+
+### App Details Page
+
+Unlike the **Overview** page which shows deployment windows for all environments, the **App Details** page does not show all deployment windows configured for the environment. It shows:
+* Active deployment windows
+* Upcoming deployment windows
+
+
+
+For example, if the super-admin has configured 4 deployment windows (say 2 Blackout and 2 Maintenance), you will see 4 cards stacked upon each other. However, no cards will be shown if deployment windows aren't configured. You may click on the windows card stack to view the details of active and upcoming deployment windows.
+
+The default time period for showing upcoming deployment windows is 90 days. You can configure this individually for blackout and maintenance windows, via ConfigMap, in the `Orchestrator` microservice as shown below:
+
+```json
+DEPLOYMENT_WINDOW_FETCH_DAYS_BLACKOUT: "90"
+DEPLOYMENT_WINDOW_FETCH_DAYS_MAINTENANCE: "90"
+```
+
+
+
+
+---
+
+## Result
+
+The below functions are blocked during an ongoing blackout window or outside maintenance window.
+
+* [Hibernation](#hibernation)
+* [Restart Workloads](#restart-workloads)
+* [Deletion of Workloads](#deletion-of-workloads)
+* [Deployment](#deployment)
+* [Rollback](#rollback)
+* [Deletion of CD Pipeline](#deletion-of-cd-pipeline)
+
+:::info
+The exempted users specified in the deployment window configuration can perform the above actions.
+:::
+
+
+### Hibernation
+
+When you hibernate an application, it becomes non-functional. To avoid this, hibernation of application is blocked.
+
+
+
+
+
+### Restart Workloads
+
+Although Kubernetes handles the restart process smoothly, there is a possibility of interruptions or downtime. To avoid this, restarting workloads (say Pod, Deployment, ReplicaSet) of an application is blocked when deployment is restricted.
+
+
+
+
+
+
+
+### Deletion of Workloads
+
+Similar to [restart workloads](#restart-workloads), deletion of workloads might disrupt the desired state and behavior of the application, hence it is barred during a deployment block.
+
+
+
+
+
+### Deployment
+
+Go to the `Build & Deploy` tab. The CD pipelines with restricted deployment will carry a **`DO NOT DEPLOY`** label.
+
+
+
+Despite that, if a user selects an eligible image and proceeds to deploy, it will show `Deployment is blocked` along with a list of exempted users who are allowed to deploy.
+
+
+
+
+
+:::caution
+Not just manual trigger, deployments remain blocked even if the trigger mode is automatic. In such cases, if a new CI image is built, the user has to manually deploy once the deployment block is lifted.
+:::
+
+The `Deployment History` tab will also log whether a given deployment was initiated during a blackout window or outside a maintenance window.
+
+
+
+### Rollback
+
+Rolling back to an older version, by using a previously deployed image, is barred during a deployment block.
+
+
+
+
+
+
+
+
+### Deletion of CD Pipeline
+
+Go to **Configuration** (tab) → **Workflow**.
+
+In Devtron, deleting a CD pipeline affects the current state of the deployed application. Moreover, it might impact future deployments and you will also lose information about past deployments, i.e., Deployment History.
+
+If you attempt to delete any CD pipeline with restricted deployment, it will show `Pipeline deletion is blocked`.
+
+
+
+
+
+---
+
+## Impact on Application Groups
+
+Just like application, [application groups](../application-groups.md) are also subjected to deployment windows.
+
+
+
+Let's say you have 10 applications in your application group, and a blackout window is ongoing for 3 of them. In such a case, if you deploy your application group, those 3 applications will not get deployed. Therefore, you might experience a partial success along with an option to retry the failed deployments.
+
+
+
+The same stands true for other bulk actions like hibernate, unhibernate, and restart workloads.
+
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/external-links.md b/versioned_docs/version-1.7/user-guide/global-configurations/external-links.md
new file mode 100755
index 0000000000..1ba8e7e27f
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/external-links.md
@@ -0,0 +1,88 @@
+---
+id: external-links
+title: External Links
+sidebar_label: External Links
+---
+
+# External Links
+
+External Links allow you to connect to the third-party applications within your Devtron dashboard for seamlessly monitoring/debugging/logging/analyzing your applications. You can select from the pre-defined third-party applications such as `Grafana` to link to your application for quick access.
+
+Configured external links will be available on the `App details` page. You can also integrate `Document` or `Folder` using **External Links**.
+
+Some of the third-party applications which are pre-defined on `Devtron` Dashboard are:
+* Grafana
+* Kibana
+* Newrelic
+* Coralogix
+* Datadog
+* Loki
+* Cloudwatch
+* Swagger
+* Jira etc.
+
+
+
+## Use Case for Monitoring Tool
+
+To monitor/debug an application using a specific Monitoring Tool (such as Grafana, Kibana, etc.), you may need to navigate to the tool's page, then to the respective app/resource page.
+
+`External Links` can take you directly to the tool's page, which includes the context of the application, environment, pod, and container.
+
+## Prerequisites
+
+Before you begin, configure an application in the Devtron dashboard.
+
+- Super admin access
+- Monitoring tool URL
+
+**Note**: External links can only be added/managed by a super admin, but non-super admin users can [access the configured external links](../app-details/README.md) on the `App Configuration` page.
+
+## Add an External Link
+
+1. On the Devtron dashboard, go to the `Global Configurations` from the left navigation pane.
+2. Select `External links`.
+
+
+
+3. Select **Add Link**.
+4. On the `Add Link` page, select the external link (e.g. Grafana) which you want to link to your application from Webpage.
+
+
+
+
+
+
+The following fields are provided on the **Add Link** page:
+
+| Field | Description |
+|---------------|-------------|
+| **Link name** | Provide name of the link. |
+| **Description** | Description of the link name. |
+| **Show link in** | - All apps in specific clusters: Select this option to select the cluster. - Specific applications: Select this option to select the application. |
+| **Clusters** | Choose the clusters for which you want to configure the selected external link with.
- Select one or more than one cluster to enable the link on the specified clusters. - Select All Clusters to enable the link on all the clusters. |
+| **Applications** | Choose the application for which you want to configure the selected external link with.
- Select one or more than one application to enable the link on the specified application. - Select All applications to enable the link on all the applications.
**Note**: If you enable `App admins can edit`, then you can view the selected links on the App-Details page. |
+| **URL Template** | The configured URL Template is used by apps deployed on the selected clusters/applications.
By combining one or more of the env variables, a URL with the structure shown below can be created:
If you include the variables `{podName}` and `{containerName}` in the URL template, then the configured links (e.g. Grafana) will be visible only on the pod level and container level respectively.
The env variables: - `{appName}` - `{appId}` - `{envId}` - `{namespace}` - `{podName}`: If used, the link will only be visible at the pod level on the [App Details](../app-details/README.md) page. - `{containerName}`: If used, the link will only be visible at the container level on the [App Details](../app-details/README.md) page.
**Note**: The env variables will be dynamically replaced by the values that you used to configure the link. |
+
+
+> Note: To add multiple links, select **+ Add another** at the top-left corner.
+
+Click **Save**.
+
+## Access an external link
+
+The users (admin and others) can access the configured external link on the [App Details](../app-details/README.md) page.
+
+**Note**: If you enable `App admins can edit` on the `External Links` page, then only non-super admin users can view the selected links on the `App Details` page.
+
+## Manage External links
+
+On the `External Links` page, the configured external links can be filtered/searched, as well as edited/deleted.
+
+Go to **Global Configurations** → **External links**.
+
+
+
+* Filter and search the links based on the link's name or a user-defined name.
+* Edit a link by selecting the edit icon next to an external link.
+* Delete an external link by selecting the delete icon next to a link. The bookmarked link will be removed in the clusters for which it was configured.
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/filter-condition.md b/versioned_docs/version-1.7/user-guide/global-configurations/filter-condition.md
new file mode 100755
index 0000000000..ba4ca3ab09
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/filter-condition.md
@@ -0,0 +1,158 @@
+---
+id: filter-condition
+title: Filter Condition
+sidebar_label: Filter Condition
+---
+
+# Filter Condition
+
+## Introduction
+
+The [workflows](../creating-application/workflow/) you create in Devtron for managing the CI-CD of your application can be made flexible or restricting with the help of CD filter conditions, for e.g., not all events (such as image builds) generated during the CI stage require progression to the CD stage. Therefore, instead of creating multiple workflows that cater to complex requirements, Devtron provides you the option of defining filters to tailor your workflow according to your specific needs.
+
+Using filter conditions, you can control the progression of events. Here are a few general examples:
+* Images containing the label "test" should not be eligible for deployment in production environment
+* Only images having tag versions greater than v0.7.4 should be eligible for deployment
+* Images hosted on Docker Hub should be eligible but not the rest
+* Only images derived from master branch should be eligible for production deployment (see [example](#scenario-2))
+
+---
+
+## Steps to Create a Filter
+
+:::info Prerequisites
+You must have application(s) with CI-CD workflow(s) configured
+:::
+
+1. From the left sidebar, go to **Global Configurations** → **Filter Condition**.
+
+2. Add a filter condition.
+
+ 
+
+3. In the **Define Filter condition** section, you get the following fields:
+ * **Filter For**: Choose the pipeline upon which the filter should apply. Currently, you can use filter conditions for CD pipelines only. Support for CI pipelines is underway.
+
+ 
+
+ * **Filter Name**: Give a name to the filter.
+ * **Description**: (Optional) Add a description to the filter, preferably explaining what it does.
+ * **Filter Condition**: You can specify either a pass condition, fail condition, or both the conditions:
+ * **Pass Condition**: Events that satisfy the pass condition are eligible to trigger your CD pipeline.
+ * **Fail Condition**: Events that satisfy the fail condition are not eligible to trigger your CD pipeline.
+ * **Use CEL Expression**: You can use `Common Expression Language` (CEL) to define the conditions. Currently, you can create conditions with the help of following variables:
+ * **containerImage**: Package that contains all the necessary files and instructions to run an application in a container, e.g., gcr.io/k8s-minikube/kicbase:v0.0.39. It returns a string value in the following format: `/:`
+ * **containerRepository**: Storage location for container images, e.g., kicbase
+ * **containerImageTag**: Versioning of image to indicate its release, e.g., v0.0.39
+ * **imageLabels**: The label(s) you assign to an image in the CD pipeline, e.g., ["PROD","Stage"]. It returns an array of strings.
+
+ Click **View filter criteria** to check the supported criteria. You get a copy button and a description of each criterion upon hovering. Moreover, you can go to **CEL expression** to learn more about the rules and supported syntax. Check [Examples](#examples) to know more.
+
+ 
+
+4. Click **Next**.
+
+5. In the **Apply to** section, you get the following fields:
+ * **Application**: Choose one or more applications to which your filter condition must apply.
+
+ 
+
+ * **Environment**: Choose one or more environments to which your filter condition must apply.
+
+ 
+
+:::info
+Since an application can have more than one environment, the filter conditions apply only to the environment you chose in the **Apply to** section. If you create a filter condition without choosing an application or environment, it will not apply to any of your pipelines.
+:::
+
+6. Click **Save**. You have successfully created a filter.
+
+ 
+
+:::caution
+If you create filters using CEL expressions that result in a conflict (i.e., passing and failing of the same image), fail will have higher precedence
+:::
+
+---
+
+## Examples
+
+Here's a sample pipeline we will be using for our explanation of [pass condition](#pass-condition) and [fail condition](#fail-condition).
+
+
+
+
+### Pass Condition
+
+#### Scenario 1
+
+Consider a scenario where you wish to make an image eligible for deployment only if its tag version is greater than `v0.0.7`
+
+The CEL Expression should be `containerImageTag > "v0.0.7"`
+
+
+
+Go to the **Build & Deploy** tab. The filter condition was created specifically for `test` environment, therefore the filter condition would be evaluated only at the relevant CD pipeline, i.e., `test`
+
+
+
+Click **Select Image** for the `test` CD pipeline. The first tab **Eligible images** shows the list and count of images that have satisfied the pass condition since their tag versions were greater than `v0.0.7`. Hence, they are marked eligible for deployment.
+
+
+
+The second tab **Latest images** shows the latest builds (up to 10 images) irrespective of whether they have satisfied the filter condition(s) or not. The ones that have not satisfied the filter conditions get marked as `Excluded`. In other words, they are not eligible for deployment.
+
+
+
+Clicking the filter icon at the top-left shows the filter condition(s) applied to the `test` CD pipeline.
+
+
+
+
+
+#### Scenario 2
+
+Consider another scenario where you wish to make images eligible for deployment only if the application's git branch starts with the word `hotfix` and also if its repo URL matches your specified condition.
+
+**CEL Expression**:
+
+`gitCommitDetails.filter(gitCommitDetail, gitCommitDetail.startsWith('https://github.com/devtron-labs')).map(repo, gitCommitDetails[repo].branch).exists_one(branch, branch.startsWith('hotfix-'))`
+
+where, `https://github.com/devtron-labs` is a portion of the repo URL
+and `hotfix-` is for finding the branch name (say *hotfix-sept-2024*)
+
+Alternatively, if you have a fixed branch (say *hotfix-123*), you may write the following expression:
+
+`'hotfix-123' in gitCommitDetails.filter(gitCommitDetail, gitCommitDetail.startsWith('https://github.com/devtron-labs')).map(repo, gitCommitDetails[repo].branch)`
+
+**Walkthrough Video**:
+
+
+
+
+### Fail Condition
+
+Consider a scenario where you wish to exclude an image from deployment if its tag starts with the word `trial` or ends with the word `testing`
+
+The CEL Expression should be `containerImageTag.startsWith("trial") || containerImageTag.endsWith("testing")`
+
+
+
+Go to the **Build & Deploy** tab. The filter condition was created specifically for `devtron-demo` environment, therefore the filter condition would be evaluated only at the relevant CD pipeline, i.e., `devtron-demo`
+
+
+
+Click **Select Image** for the `devtron-demo` CD pipeline. The first tab **Eligible images** shows the list and count of images that have not met the fail condition. Hence, they are marked eligible for deployment.
+
+
+
+The second tab **Latest images** shows the latest builds (up to 10 images) irrespective of whether they have satisfied the filter condition(s) or not. The ones that have satisfied the filter conditions get marked as `Excluded`. In other words, they are not eligible for deployment.
+
+
+
+Clicking the filter icon at the top-left shows the filter condition(s) applied to the `devtron-demo` CD pipeline.
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/git-accounts.md b/versioned_docs/version-1.7/user-guide/global-configurations/git-accounts.md
new file mode 100755
index 0000000000..1aae3146df
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/git-accounts.md
@@ -0,0 +1,44 @@
+---
+id: git-accounts
+title: Git Accounts
+sidebar_label: Git Accounts
+---
+
+# Git Accounts
+
+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.
+
+## Add Git Account
+
+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:
+
+| Field | Description |
+| :--- | :--- |
+| `Name` | Provide a name to your Git provider. Note: This name will be available on the Configurations (tab) → [Git repository](../creating-application/git-material.md) drop-down list. |
+| `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` | Provide the Git host `URL`. As an example: [https://github.com](https://github.com) for GitHub, [https://gitlab.com](https://gitlab.com) for GitLab etc. |
+| `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.
|
+
+
+
+## Update Git Account
+
+To update the git account:
+
+1. Click the git account which you want to update.
+2. Update the required changes.
+3. 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 Configurations (tab) → [Git repository](../creating-application/git-material.md).
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/gitops.md b/versioned_docs/version-1.7/user-guide/global-configurations/gitops.md
new file mode 100755
index 0000000000..888cb1ebce
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/gitops.md
@@ -0,0 +1,320 @@
+---
+id: gitops
+title: GitOps
+sidebar_label: GitOps
+---
+
+# GitOps
+
+## Introduction
+
+In Devtron, you can use either Helm, GitOps (Argo CD), or GitOps (Flux CD) as your deployment method while deploying your application. When you choose Helm as your preferred deployment method, you are deploying your application directly into the Kubernetes cluster without version tracking of any kind.
+
+However, if you choose GitOps - a branch of DevOps that focuses on using Git repositories as a single source of truth - Devtron stores Kubernetes configuration files (e.g., Kubernetes manifests or YAML configs) and the desired state of your applications in Git repositories to track each and every deployment.
+
+
+
+Whenever tools like Argo CD or Flux CD recognize changes in the Git repository, they apply those changes to the Kubernetes cluster automatically. Similarly, if they notice any change in the cluster, they will revert back the cluster to the Git-defined state.
+
+---
+
+## Steps to Configure GitOps
+
+:::caution Who Can Perform This Action?
+Users need to have [Super-Admin](user-access.md#assign-super-admin-permissions) permission to configure GitOps.
+
+:::
+
+1. Go to **Global Configurations** → **GitOps**
+
+ 
+
+2. Select any one of the [supported Git providers](#supported-git-providers) to configure GitOps.
+
+ 
+
+:::caution
+The Git provider you select for configuring GitOps might impact the following sections:
+
+ * [Deployment Template](../creating-application/base-config/deployment-template.md)
+
+ * [Charts](../deploy-chart/README.md)
+
+:::
+
+3. Fill all the mandatory fields. Refer [supported Git providers](#supported-git-providers) to know more about the respective fields.
+
+ 
+
+4. In the **Directory Management in Git** section, you get the following options:
+
+ * **Auto-create git repository for each application**:
+
+ This option lets Devtron automatically create a GitOps repository within your organization. The repository name will match your application name, and it cannot be changed. Since Devtron needs admin access to create the repository, ensure the Git credentials you provided in Step 3 have administrator rights.
+
+ * **Ask git repository for each application**:
+
+ Select this option if you wish to use your own GitOps repo. This is ideal if there are any confidentiality/security concerns that prevent you from giving us admin access. Therefore, the onus is on you to create a GitOps repo with your Git provider, and then [add it to the specific application](../creating-application/gitops-config.md) on Devtron. Make sure the Git credentials you provided in Step 3 have at least read/write access. Choosing this option will unlock a [GitOps Configuration](../creating-application/gitops-config.md) page under the [App Configuration](../creating-application/README.md) tab.
+
+ 
+
+5. Click **Save**/**Update**. A green tick will appear on the active Git provider.
+
+### Feature Flag
+
+Alternatively, you may use the feature flag **FEATURE_USER_DEFINED_GITOPS_REPO_ENABLE** to enable or disable custom GitOps repo.
+
+:::info
+**For disabling** - `FEATURE_USER_DEFINED_GITOPS_REPO_ENABLE: "false"`
+**For enabling** - `FEATURE_USER_DEFINED_GITOPS_REPO_ENABLE: "true"`
+:::
+
+#### How to Use Feature Flag
+
+
+
+1. Go to [Devtron's Resource Browser](../resource-browser/README.md).
+
+2. Select the cluster where Devtron is running, i.e., `default_cluster`.
+
+3. Go to the **Config & Storage** dropdown on the left.
+
+4. Click **ConfigMap**.
+
+5. Use the namespace filter (located on the right-hand side) to select `devtroncd` namespace. Therefore, it will show only the ConfigMaps related to Devtron, and filter out the rest.
+
+6. Find the ConfigMap meant for the dashboard of your Devtron instance, i.e., `dashboard-cm` (with an optional suffix).
+
+7. Click **Edit Live Manifest**.
+
+8. Add the feature flag (with the intended boolean value) within the `data` dictionary
+
+9. Click **Apply Changes**.
+
+---
+
+## Supported Git Providers
+
+Below are the Git providers supported in Devtron for storing configuration files.
+
+* [GitHub](#github)
+* [GitLab](#gitlab)
+* [AWS Code Commit](#aws-code-commit-)
+* [Azure](#azure)
+* [Bitbucket](#bitbucket)
+* [Other GitOps](#other-gitops-)
+
+### GitHub
+
+:::info Prerequisite
+1. A GitHub account
+2. A GitHub organization. If you don't have one, refer [Creating Organization in GitHub](#creating-organization-in-github).
+:::
+
+Fill the following mandatory fields:
+
+| Field | Description |
+| --- | --- |
+| **Git Host** | Shows the URL of GitHub, e.g., https://github.com/ |
+| **GitHub Organisation Name** | Enter the GitHub organization name. If you do not have one, refer [How to create organization in GitHub](#creating-organization-in-github). |
+| **GitHub Username** | Provide the username of your GitHub account |
+| **Personal Access Token** | Provide your personal access token (PAT). It is used as an alternate password to authenticate your GitHub account. If you do not have one, create a GitHub PAT [here](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token).
**Access Required**: `repo` - Full control of private repositories (able to access commit status, deployment status, and public repositories). `admin:org` - Full control of organizations and teams (Read and Write access). May not be required if you are using user-defined git repo. `delete_repo` - Grants delete repo access on private repositories. |
+
+### GitLab
+
+:::info Prerequisite
+1. A GitLab account
+
+2. A GitLab group. If you don't have one, refer [Creating Group in GitLab](#creating-group-in-gitlab).
+
+:::
+
+Fill the following mandatory fields:
+
+| Field | Description |
+| --- | --- |
+| **Git Host** | Shows the URL of GitLab, e.g., https://gitlab.com/ |
+| **GitLab Group ID** | Enter the GitLab group ID. If you do not have one, refer [GitLab Group ID](#creating-group-in-gitlab).|
+| **GitLab Username** | Provide the username of your GitLab account |
+| **Personal Access Token** | Provide your personal access token (PAT). It is used as an alternate password to authenticate your GitLab account. If you do not have one, create a GitLab PAT [here](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html).
**Access Required**: `api` - Grants complete read/write access to the scoped project API. `write_repository` - Allows read/write access (pull, push) to the repository.|
+
+### AWS Code Commit
+
+:::info Prerequisites
+1. Existing user of AWS CodeCommit ([as AWS stopped adding new customers to it](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/))
+
+2. An AWS IAM user with `AWSCodeCommitPowerUser` permission. Refer to [Create and Configure an IAM User with AWSCodeCommitPowerUser Permission](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html#setting-up-gc-account) for more information.
+
+3. Obtain SSH Key ID and SSH Private Key. Refer to [Generating SSH Private Key in AWS Code Commit](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-ssh-unixes.html) for more information.
+
+:::
+
+
+
+Fill the following mandatory fields:
+
+| Field | Description |
+| --- | --- |
+| **SSH Host** | Enter the AWS Code Commit SSH host URL (e.g., `ssh://git-codecommit.ap-south-1.amazonaws.com`)|
+| **Enter username** | Enter the username (SSH Key ID), e.g., `APKDKDIERJS9EXAMPLE`. |
+| **SSH Private Key** | Enter the SSH private key. |
+
+Click **Save**.
+
+### Azure
+
+:::info Prerequisites
+1. An organization on Azure DevOps. If you don't have one, refer [this link](https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/create-organization?view=azure-devops#create-an-organization).
+
+2. A project in your Azure DevOps organization. Refer [Creating Project in Azure](#creating-project-in-azure-devops).
+
+:::
+
+Fill the following mandatory fields:
+
+| Field | Description |
+| --- | --- |
+| **Azure DevOps Organisation Url*** | Enter the Org URL of Azure DevOps. Format should be `https://dev.azure.com/`, where `` represents the organization name, e.g., [https://dev.azure.com/devtron-test](https://dev.azure.com/devtron-test)|
+| **Azure DevOps Project Name** | Enter the Azure DevOps project name. If you do not have one, refer [Azure DevOps Project Name](#creating-project-in-azure-devops).|
+| **Azure DevOps Username*** | Provide the username of your Azure DevOps account |
+| **Azure DevOps Access Token*** | Provide your Azure DevOps access token. It is used as an alternate password to authenticate your Azure DevOps account. If you do not have one, create a Azure DevOps access token [here](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page).
**Access Required**: `code` - Grants the ability to read source code and metadata about commits, change sets, branches, and other version control artifacts. [More information on scopes in Azure DevOps](https://docs.microsoft.com/en-us/azure/devops/integrate/get-started/authentication/oauth?view=azure-devops#scopes). |
+
+### Bitbucket
+
+Here, you get 2 options:
+
+* [Bitbucket Cloud](#bitbucket-cloud) - Select this if you wish to store GitOps configuration in a web-based Git repository hosting service offered by Bitbucket.
+
+* [Bitbucket Data Center](#bitbucket-data-center) - Select this if you wish to store GitOps configuration in a git repository hosted on a self-managed Bitbucket Data Center (on-prem).
+
+#### Bitbucket Cloud
+
+:::info Prerequisite
+1. A Bitbucket account
+
+2. A workspace in your Bitbucket account. Refer [Creating Workspace in Bitbucket](#creating-workspace-in-bitbucket).
+
+:::
+
+
+
+Fill the following mandatory fields:
+
+| Field | Description |
+| --- | --- |
+| **Bitbucket Host** | Shows the URL of Bitbucket Cloud, e.g., https://bitbucket.org/ |
+| **Bitbucket Workspace ID** | Enter the Bitbucket workspace ID. If you do not have one, refer [Bitbucket Workspace ID](#creating-workspace-in-bitbucket)|
+| **Bitbucket Project Key** | Enter the Bitbucket project key. If you do not have one, refer [Bitbucket Project Key](https://support.atlassian.com/bitbucket-cloud/docs/group-repositories-into-projects/). Note: If the project is not provided, the repository is automatically assigned to the oldest project in the workspace. |
+| **Bitbucket Username*** | Provide the username of your Bitbucket account |
+| **Personal Access Token** | Provide your personal access token (PAT). It is used as an alternate password to authenticate your Bitbucket Cloud account. If you do not have one, create a Bitbucket Cloud PAT [here](https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/).
**Access Required**: `repo` - Full control of repositories (Read, Write, Admin, Delete) access. |
+
+#### Bitbucket Data Center
+
+:::info Prerequisite
+A Bitbucket Data Center account
+
+:::
+
+
+
+Fill the following mandatory fields:
+
+| Field | Description |
+| --- | --- |
+| **Bitbucket Host** | Enter the URL address of your Bitbucket Data Center, e.g., `https://bitbucket.mycompany.com` |
+| **Bitbucket Project Key** | Enter the Bitbucket project key. Refer [Bitbucket Project Key](https://confluence.atlassian.com/bitbucketserver/creating-projects-776639848.html). |
+| **Bitbucket Username*** | Provide the username of your Bitbucket Data Center account |
+| **Password** | Provide the password to authenticate your Bitbucket Data Center account |
+
+### Other GitOps
+
+
+
+If you prefer to use the GitOps approach using a different platform other than the available ones, refer to the following table and fill in the mandatory fields:
+
+| Field | Description |
+| --- | --- |
+| **SSH Host** | Enter the SSH host URL (e.g., `ssh://git@:/.git`). |
+| **Enter username** | Enter the username (e.g., `git`). For other GitOps, the username will differ depending on the provider (e.g., personal access token or access key ID). |
+| **SSH Private Key** | Enter the SSH private key (e.g., `M7YtY8cdJKhZ7nYXxgXeqNffv`) here against the public key added to your GitOps provider. |
+
+Click **Save**.
+
+---
+
+## Miscellaneous
+
+### Creating Organization in GitHub
+
+:::caution
+We do **NOT** recommend using GitHub organization that contains your source code.
+:::
+
+
+
+1. Create a new account on GitHub (if you do not have one).
+2. On the upper-right corner of your GitHub page, click your profile photo, then click **Settings**.
+3. On the `Access` section, click **Organizations**.
+4. On the `Organizations` section, click **New organization**.
+5. Pick a [plan](https://docs.github.com/en/get-started/learning-about-github/githubs-products) for your organization. You have the option to select `create free organization` also.
+6. On the `Set up your organization` page,
+ * Enter the `organization account name`, `contact email`.
+ * Select the option your organization belongs to.
+ * Verify your account and click **Next**.
+ * Your `GitHub organization name` will be created.
+
+7. Go to your profile and click **Your organizations** to view all the organizations you created.
+
+:::info Additional References
+For more information about the plans available for your team, see [GitHub's products](https://docs.github.com/en/get-started/learning-about-github/githubs-products). You can also refer [GitHub organization](https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/about-organizations) official doc page for more detail.
+:::
+
+
+### Creating Group in GitLab
+
+
+
+
+1. Create a new account on GitLab (if you do not have one).
+2. You can create a group by going to the 'Groups' tab on the GitLab dashboard and click `New group`.
+3. Select `Create group`.
+4. Enter the group name (required) and select the optional descriptions if required, and click **Create group**.
+5. Your group will be created and your group name will be assigned with a new `Group ID` (e.g. 61512475).
+
+
+### Creating Project in Azure DevOps
+
+
+
+
+
+1. Go to Azure DevOps and navigate to Projects.
+2. Select your organization and click `New project`.
+3. On the `Create new project` page,
+ * Enter the `project name` and description of the project.
+ * Select the visibility option (private or public), initial source control type, and work item process.
+ * Click **Create**.
+ * Azure DevOps displays the project welcome page with the `project name`.
+
+:::info Additional References
+You can also refer [Azure DevOps - Project Creation](https://docs.microsoft.com/en-us/azure/devops/organizations/projects/create-project?view=azure-devops&tabs=preview-page) official page for more details.
+:::
+
+
+### Creating Workspace in Bitbucket
+
+
+
+1. Create a new individual account on Bitbucket (if you do not have one).
+2. Select your profile and settings avatar on the upper-right corner of the top navigation bar.
+3. Select `All workspaces` from the dropdown menu.
+4. Select the `Create workspace` on the upper-right corner of the `Workspaces` page.
+5. On the `Create a Workspace` page:
+ * Enter a `Workspace name`.
+ * Enter a `Workspace ID`. Your ID cannot have any spaces or special characters, but numbers and capital letters are fine. This ID becomes part of the URL for the workspace and anywhere else where there is a label that identifies the team (APIs, permission groups, OAuth, etc.).
+ * Click **Create**.
+6. Your `Workspace name` and `Workspace ID` will be created.
+
+:::info Additional References
+You can also refer [official Bitbucket Workspace page](https://support.atlassian.com/bitbucket-cloud/docs/what-is-a-workspace/) for more details.
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/host-url.md b/versioned_docs/version-1.7/user-guide/global-configurations/host-url.md
new file mode 100755
index 0000000000..1a88769ad1
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/host-url.md
@@ -0,0 +1,22 @@
+---
+id: host-url
+title: Host URL
+sidebar_label: Host URL
+hide_table_of_contents: true
+---
+
+# Host URL
+
+Host URL is the domain address at which your devtron dashboard can be reached.
+
+### Add Host URL
+
+To add host URL, go to the `Host URL` section of `Global Configurations`.
+
+
+
+On the **Host URL** page:
+
+* Enter the host URL in the `Host URL` field.
+* Or, you can select auto-detect from your browser.
+* Next, click `Update`.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/image-promotion-policy.md b/versioned_docs/version-1.7/user-guide/global-configurations/image-promotion-policy.md
new file mode 100755
index 0000000000..0a117b0f72
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/image-promotion-policy.md
@@ -0,0 +1,261 @@
+---
+id: image-promotion-policy
+title: Image Promotion Policy
+sidebar_label: Image Promotion Policy
+---
+
+# Image Promotion Policy
+
+## Introduction
+
+An ideal deployment workflow may consist of multiple stages (e.g., SIT, UAT, Prod environment).
+
+
+
+If you have built such a [workflow](../creating-application/workflow/README.md), your CI image will sequentially traverse and deploy to each environment until it reaches the target environment. However, if there's a critical issue you wish to address urgently (through a hotfix) on production, navigating the standard workflow might feel slow and cumbersome.
+
+Therefore, Devtron offers a feature called 'Image Promotion Policy' that allows you to directly promote an image to the target environment, bypassing the intermediate stages in your workflow including:
+
+* [Pre-CD](../creating-application/workflow/cd-pipeline.md#pre-deployment-stage) and [Post-CD](../creating-application/workflow/cd-pipeline.md#post-deployment-stage) of the intermediate stages
+* All [approval nodes](../global-configurations/approval-policy.md) of the intermediate stages
+
+
+
+
+---
+
+## Creating an Image Promotion Policy
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to create an image promotion policy.
+:::
+
+You can create a policy using our APIs or through Devtron CLI. To get the latest version of the **devtctl** binary, please contact your enterprise POC or reach out to us directly for further assistance.
+
+Here is the CLI approach:
+
+**Syntax**:
+```
+devtctl create imagePromotionPolicy \
+ --name="example-policy" \
+ --description="This is a sample policy that promotes an image to production environment" \
+ --passCondition="true" \
+ --failCondition="false" \
+ --approverCount=0 \
+ --allowRequestFromApprove=false \
+ --allowImageBuilderFromApprove=false \
+ --allowApproverFromDeploy=false \
+ --applyPath="path/to/applyPolicy.yaml"
+```
+
+**Arguments**:
+
+* `--name` (required): The name of the image promotion policy.
+* `--description` (optional): A brief description of the policy, preferably explaining what it does.
+* `--passCondition` (optional): Specify a condition using [Common Expression Language (CEL)](https://github.com/google/cel-spec/blob/master/doc/langdef.md). Images that match this condition will be eligible for promotion to the target environment.
+* `--failCondition` (optional): Images that match this condition will NOT be eligible for promotion to the target environment.
+* `--approverCount` (optional): The number of approvals required to promote an image (0-6). Defaults to 0 (no approvals).
+* `--allowRequestFromApprove` (optional): (Boolean) If true, user who raised the image promotion request can approve it. Defaults to false.
+* `--allowImageBuilderFromApprove` (optional): (Boolean) If true, user who triggered the build can approve the image promotion request. Defaults to false.
+* `--allowApproverFromDeploy` (optional): (Boolean) If true, user who approved the image promotion request can deploy that image. Defaults to false.
+* `--applyPath` (optional): Specify the path to the YAML file that contains the list of applications and environments to which the policy should be applicable.
+
+:::info
+If an image matches both pass and fail conditions, the priority of the fail condition will be higher. Therefore, such image will NOT be eligible for promotion to the target environment.
+:::
+
+:::info
+If you don't define both pass and fail conditions, all images will be eligible for promotion.
+:::
+
+---
+
+
+
+
+## Applying an Image Promotion Policy
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to apply an image promotion policy.
+:::
+
+You can apply a policy using our APIs or through Devtron CLI. Here is the CLI approach:
+
+* Create a YAML file and give it a name (say `applyPolicy.yaml`). Within the file, define the applications and environments to which the image promotion policy should apply, as shown below.
+
+```yml title="applyPolicy.yaml" showLineNumbers
+apiVersion: v1
+kind: artifactPromotionPolicy
+spec:
+ payload:
+ applicationEnvironments:
+ - appName: "app1"
+ envName: "env-demo"
+ - appName: "app1"
+ envName: "env-staging"
+ - appName: "app2"
+ envName: "env-demo"
+ applyToPolicyNames:
+ - "example-policy"
+```
+
+
+Here, `applicationEnvironments` is a dictionary that contains the application names (app1, app2) and the corresponding environment names (env-demo/env-staging) where the policy will apply. In the `applyToPolicyName` key, enter the value of the `name` argument you used earlier while [creating the policy](#creating-an-image-promotion-policy).
+
+* Apply the policy using the following CLI command:
+
+ ```
+ devtctl apply policy -p="path/to/applyPolicy.yaml"
+ ```
+
+
+## Result
+
+### Promoting Image to Target Environment
+
+:::caution Who Can Perform This Action?
+Users with build & deploy permission or above (for the application and target environment) can promote an image if the image promotion policy is enabled.
+:::
+
+Here, you can promote images to the target environment(s).
+
+1. Go to the **Build & Deploy** tab of your application.
+
+2. Click the **Promote** button next to the workflow in which the you wish to promote the image. Please note, the button will appear only if image promotion is allowed for any environment used in that workflow.
+
+ 
+
+3. In the `Select Image` tab, you will see a list of images. Use the **Show Images from** dropdown to filter the list and choose the image you wish to promote. This can be either be an image from the CI pipeline or one that has successfully passed all stages (e.g., pre, post, if any) of that particular environment.
+
+ 
+
+4. Use the **SELECT** button on the image, and click **Promote to...**
+
+5. Select one or more target environments using the checkbox.
+
+ 
+
+6. Click **Promote Image**.
+
+The image's promotion to the target environment now depends on the approval settings in the image promotion policy. If the super-admin has enforced an approval process, the image requires the necessary number of approvals before promotion. On the other hand, if the super-admin has not enforced approval, the image will be automatically promoted since there is no request phase involved.
+
+:::caution
+In case you have configured [SES or SMTP on Devtron](../global-configurations/manage-notification.md#configurations), an email notification will be sent to the approvers.
+:::
+
+7. If approval(s) are required for image promotion, you may check the status of your request in the `Approval Pending` tab.
+
+### Approving Image Promotion Request
+
+:::caution Who Can Perform This Action?
+Only the users having [Artifact promoter](./user-access.md#devtron-apps-permissions) role (for the application and environment) or superadmin permissions will be able to approve the image promotion request.
+:::
+
+1. Go to the **Build & Deploy** tab of your application.
+
+2. Click the **Promote** button next to the workflow.
+
+3. Go to the `Approval Pending` tab to see the list of images requiring approval. By default, it shows a list of all images whose promotion request is pending with you.
+
+ 
+
+:::info
+All the images will show the source from which it is being promoted, i.e., CI stage or intermediate stage (environment).
+:::
+
+4. Click **Approve for...** to choose the target environments to which it can be promoted.
+
+5. Click **Approve**.
+
+You can also use the **Show requests** dropdown to filter the image promotion requests for a specific target environment.
+
+
+
+If there are pending promotion requests, you can approve them as shown below:
+
+
+
+### Deploying a Promoted Image
+
+:::caution Who Can Perform This Action?
+Users with build & deploy permission or above for the application and environment can deploy the promoted image.
+:::
+
+If a user has approved the promotion request for an image, they may or may not be able to deploy depending upon the [policy configuration](#creating-an-image-promotion-policy).
+
+However, a promoted image does not automatically qualify as a deployable image. It must fulfill all configured requirements ([Image Deployment Approval](../global-configurations/approval-policy.md), [Filter Conditions](./filter-condition.md), etc.) of the target environment for it to be deployed.
+
+In the **Build & Deploy** tab of your application, click **Select Image** for the CD pipeline, and choose your promoted image for deployment.
+
+
+
+You can check the deployment of promoted images in the **Deployment History** of your application. It will also indicate the pipeline from which the image was promoted and deployed to the target environment.
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/lock-deployment-config.md b/versioned_docs/version-1.7/user-guide/global-configurations/lock-deployment-config.md
new file mode 100755
index 0000000000..b5ec2c590c
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/lock-deployment-config.md
@@ -0,0 +1,302 @@
+---
+id: lock-deployment-config
+title: Lock Deployment Configuration
+sidebar_label: Lock Deployment Configuration
+---
+
+# Lock Deployment Configuration
+
+## Introduction
+
+The [Deployment Template](../../reference/glossary.md#deployment-template) might contain certain configurations (e.g., `ingress`) that are critical to the stability and security of the applications. To prevent unauthorized or accidental changes to such configurations, Devtron allows super admins to restrict (lock) such critical configurations from modification or deletion.
+
+
+
+These restrictions can be applied for deployment templates in both the:
+
+* [Base configuration](../../user-guide/creating-application/base-config/README.md)
+* [Environment-level configuration](../../user-guide/creating-application/environment-overrides.md)
+
+**How is this different from the 'Protect Configuration' feature?**
+
+The 'protect configuration' feature is meant to verify the edits by introducing an approval flow for any changes made to the configuration files, i.e., Deployment template, ConfigMaps, and Secrets. Refer [Approval Policy](../global-configurations/approval-policy.md).
+
+Whereas, the 'lock deployment configuration' feature goes one step further. It is meant to prevent any edits to specific keys by non-super-admins. This applies only to deployment templates and is performed at the global level.
+
+---
+
+## Locking Deployment Configurations
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to lock deployment keys.
+:::
+
+To lock deployment configurations, you must first create a profile and apply it to the specific deployment templates.
+
+:::tip What is a Lock Deployment Profile?
+A lock deployment configuration profile is a template that specifies which configurations (keys) in the deployment template cannot be edited or deleted by non-super admin users. By using lock deployment configuration profiles, super-admins can manage edit access at different levels, such as global, cluster, environment, application, or a combination of application and environment.
+
+This allows for better control by making sure critical deployment template configurations are locked in sensitive environments (production), while giving flexibility to change deployment template configurations in other less critical environments (QA, Staging, etc.).
+:::
+
+### Creating Profile
+
+To create a profile, follow the steps below:
+
+1. Go to **Global Configurations** → **Lock Deployment Configuration**.
+
+2. Click **+ Create Profile**; a new **Create Profile** page will open.
+
+ 
+
+3. Enter the **Name** (Required) and a **Description** (Optional) for the profile.
+
+4. (Optional) Click **Refer values.yaml** to check which keys you wish to lock.
+
+ * Select the relevant Chart type and its version to reference the keys.
+
+ 
+
+5. Enter the keys inside the editor on the left-hand side, e.g., `autoscaling.MaxReplicas`. Use [JSONpath expressions](https://goessner.net/articles/JsonPath/index.html) to enter specific keys, lists, or objects to lock.
+
+ 
+
+:::caution Keys are case-sensitive
+Use the exact case as defined in the deployment template, otherwise the keys will not be locked.
+:::
+
+
+:::info Locking custom configurations (keys)
+You can lock custom configurations (keys) defined in your deployment template, even if they are not listed in the **Refer values.yaml** section. As long as the key matches your lock rule, it will be locked.
+
+:::
+
+6. Click **Save Changes**.
+
+ 
+
+7. Profile will be created, and available under the **Profiles** tab.
+
+ 
+
+:::caution Handling Locked Index Ranges
+If you have locked a range of configurations using JSONPath (e.g., `ingressInternal.hosts[1:3].paths`), the specified index positions are protected.
+
+If you want to add a new configuration entry (e.g., a new host), it should be added after the locked range i.e., in case of `ingressInternal.hosts[1:3].paths`, new host configuration entry should be added at the index 4.
+
+Adding an entry within the locked range may shift the indices and result in validation errors or unintended modifications of locked values.
+
+:::
+
+### Applying Profile
+
+After creating a profile, the next step is to apply the profile to the specific deployment templates according to your use case. To apply a profile, follow the steps below:
+
+1. Go to **Global Configurations** → **Lock Deployment Configuration**.
+
+ 
+
+2. Click **Apply Profile**; a new **Apply Profile** page will open.
+
+3. Select the profiles that you want to apply from the dropdown under **Select profiles to apply**; you can select multiple profiles.
+
+ 
+
+4. Select how you want to apply the profiles under **Apply selected profiles to deployment templates of**.
+
+ There are three options you can choose from:
+
+ 1. **Specific deployment templates**: This option allows you to apply the lock deployment configuration profile to the deployment template(s) of specific application(s) within particular environment(s).
+
+ 
+
+ 2. **By match criteria**: This option allows you to use a combination of filters to create criteria. Lock deployment configuration profile will only apply to the deployment templates of the applications fulfilling your criteria (including existing and future ones). (Optional) You may also write a note for your other team members to understand the intent and context of your policy.
+
+ Let's understand how to use **By match criteria** with the below example:
+
+ Suppose you want to apply a lock deployment configuration profile to all applications in a particular project. You can achieve this by selecting that project as the match criteria.
+
+ 
+
+ 3. **Global (All deployment templates)**: This option allows you to apply the lock deployment configuration profile to all the existing and future deployment templates across all the applications.
+
+ 
+
+5. Click **Save Changes**, and the selected profiles will apply to the required deployment templates and be visible under the **Applied Profiles** tab.
+
+---
+
+## Effect on Deployment Templates
+
+Only super admins can edit the locked configurations directly once the lock deployment configuration profile is applied to the deployment templates. Non-super admin users cannot edit the locked keys for those deployment templates.
+
+Let's look at a scenario where a user (non-super-admin) tries to edit the same in an [unprotected](../../user-guide/creating-application/config-approval.md) base deployment template.
+
+
+### Viewing Locked Configurations
+
+* User can hide/unhide the locked configurations as shown below.
+
+ 
+
+### Editing Locked Configurations
+
+:::info GUI/YAML Mode
+
+If you select 'GUI' mode instead of 'YAML', all the keys meant for GUI mode will be displayed in the GUI even if some are locked. While users can modify these keys, they cannot save the changes made to the locked keys.
+:::
+
+* Let's assume the user edits one of the locked keys...
+
+ 
+
+ ...and saves the changes.
+
+ 
+
+* A modal window highlighting the non-eligible edits will appear on the right.
+
+ 
+
+### Editing Unlocked Keys
+
+* Let's assume the user edits a key that is not locked or adds a new key.
+
+ 
+
+* The modal window will highlight the eligible edits. However, it will not let the user save those eligible edits unless the user clicks the checkbox: **Save changes which are eligible for update**.
+
+ 
+
+:::caution Who Can Perform This Action?
+Only a super-admin, manager, or application admin can edit the configuration values.
+:::
+
+* Once the user clicks the **Save Changes** button, the permissible changes will reflect in the deployment template.
+
+ 
+
+ However, if it's a [protected template](../../user-guide/creating-application/config-approval.md), the user will require the approval of a [configuration approver](./user-access.md#devtron-apps-permissions) as shown below.
+
+ 
+
+The same result can be seen if the user tries to edit environment-specific deployment templates.
+
+---
+
+## Managing an Applied Profile
+
+To manage an existing applied profile, follow the steps below:
+
+1. Go to **Global Configurations** → **Lock Deployment Configuration**.
+
+2. Click the **Applied Profiles** tab and click the `⋮` button next to the preferred applied profile.
+
+3. Click **Manage Policy** to add or remove the profiles. If you have applied the profile using match criteria, then you can also click **Edit match criteria** to edit the match criteria.
+
+4. In case you want to delete an applied profile, click **Delete** and the applied profile will be removed.
+
+5. Click **Save Changes**.
+
+
+
+
+
+
+
+:::caution Note
+Removing an applied profile does not delete the lock deployment configuration profile. It only removes the associated restrictions from the deployment templates where the profile was applied.
+:::
+
+---
+
+## Updating Profile
+
+To update a lock deployment configuration file, follow the steps below:
+
+1. Go to **Global Configurations** → **Lock Deployment Configuration**.
+
+2. Click the **Profiles** tab and then click the edit button next to the preferred profile.
+
+3. Edit the profile.
+
+4. Click **Save Changes**.
+
+
+
+---
+
+## Deleting Profile
+
+To delete a lock deployment configuration file, follow the steps below:
+
+1. Go to **Global Configurations** → **Lock Deployment Configuration**.
+
+2. Click the **Profiles** tab and then click the delete button next to the preferred profile.
+
+3. A pop-up window will appear, prompting you to enter the profile name for confirmation.
+
+4. Enter the name of the profile and click **Delete**.
+
+
+
+:::caution Note
+Deleting a profile will automatically remove it from the Applied Profiles tab and remove its restrictions from all deployment templates where it was previously applied.
+:::
+
+
+## Use Cases
+
+### Locking Resources
+
+Managing resources configurations (CPU & Memory) is critical for application stability (specifically in production environments).
+
+To prevent accidental or unauthorized changes to resource configurations (CPU & Memory), you can create a lock deployment configuration profile which locks resource configurations, and then you can apply it to the relevant deployment templates.
+
+**Lock Deployment Configuration Profile**
+
+```yaml
+resources.limits.cpu
+resources.limits.memory
+resources.requests.cpu
+resources.requests.memory
+```
+
+This ensures that only super admins can modify critical resource configurations (increasing CPU or reducing memory) especially in sensitive environments like production.
+
+### Locking Autoscaling
+
+Autoscaling configurations controls how your application scales based on traffic or resource usage. If not managed properly, accidental or unauthorized changes to autoscaling configurations can cause resource overuse resulting in high cost or application instability.
+
+To prevent accidental or unauthorized changes to autoscaling configurations, you can create a lock deployment configuration profile which locks autoscaling configurations, and then you can apply it to the relevant deployment templates.
+
+**Lock Deployment Configuration Profile**
+
+```yaml
+autoscaling.MaxReplicas
+autoscaling.MinReplicas
+autoscaling.TargetCPUUtilizationPercentage
+autoscaling.TargetMemoryUtilizationPercentage
+autoscaling.annotations
+autoscaling.behavior
+autoscaling.containerResource.TargetCPUUtilizationPercentage
+autoscaling.containerResource.TargetMemoryUtilizationPercentage
+autoscaling.containerResource.enabled
+autoscaling.enabled
+autoscaling.extraMetrics
+autoscaling.labels
+```
+
+### Locking Ingress
+
+Ingress configuration defines how external traffic is routed to your application. Unauthorized or accidental changes to ingress rules (hostnames or paths), can lead to incorrect routing, broken endpoints, or access to unintended environments.
+
+To prevent accidental or unauthorized changes to ingress configurations, you can create a lock deployment configuration profile which locks ingress configurations, and then you can apply it to the relevant deployment templates.
+
+**Lock Deployment Configuration Profile**
+
+```yaml
+ingress
+ingressinternal.hosts
+ingressInternal.hosts[*].pathType
+```
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/manage-notification.md b/versioned_docs/version-1.7/user-guide/global-configurations/manage-notification.md
new file mode 100755
index 0000000000..029b210915
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/manage-notification.md
@@ -0,0 +1,436 @@
+---
+id: manage-notification
+title: Manage Notifications
+sidebar_label: Manage Notifications
+---
+
+# Manage Notifications
+
+## Introduction
+
+Monitoring updates of your CI/CD pipelines, such as their triggers, successes, and failures, can be challenging without a proper notification system in place.
+
+The **Notifications** module in Devtron helps you solve this problem by sending you timely updates about your CI/CD pipelines through various mediums such as Email, Slack, Discord, and much more - ensuring you stay informed at all times.
+
+
+
+---
+
+## Initial Prerequisites
+
+* [Build and Deploy (CI/CD)](../integrations/build-and-deploy-ci-cd.md) integration installed in your Devtron instance.
+
+* **Notifications** module integration installed in your Devtron instance.
+
+ * **For OSS users**: The **Notifications** page won't appear in Global Configurations unless you install the **Notifications** module from [Devtron Stack Manager](../integrations/README.md) (Average installation time: ~ 5–6 minutes).
+
+ * **For Enterprise users**: This module comes installed by default.
+
+---
+
+## Configurations
+
+The **Notifications** page allows you to configure and manage notifications for your CI/CD pipeline(s). To access the **Notifications** page, navigate to **Global Configurations** → **Notifications**.
+
+
+
+The **Notifications** page has the following two tabs:
+
+* **Configurations** - Allows you to configure the way (Email SES, Email SMTP, Slack, Webhook) through which the notifications will be delivered.
+
+* **Notifications** - Allows you to define the recipients and the events (e.g., CI/CD success, failure, trigger) for which the notifications must be sent out.
+
+You can configure notifications in Devtron in the following four ways:
+
+* [SES Configuration](#email-ses-configuration)
+
+* [SMTP Configuration](#email-smtp-configuration)
+
+* [Slack Configuration](#slack-configuration)
+
+* [Webhook Configuration](#webhook-configuration)
+
+### Email SES Configuration
+
+:::caution Who Can Perform This Action?
+Only [Super-Admins](user-access.md) can create and manage SES configurations.
+
+:::
+
+
+:::info Prerequisites
+* **AWS access key and secret key** - When obtaining access key and secret access key from AWS SES, make sure to generate them from the **Security credentials** page (**Profile** → **Security credentials** → **Access keys** → **Create access key**).
+
+* **Verified domain/email identities on AWS SES** - To know more, visit [Creating and Verifying Identities in Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html).
+
+:::
+
+#### Email (SES) Tutorial
+
+
+
+#### Steps
+
+1. Navigate to the **Global Configurations** → **Notifications** → **Configurations** → **Email (SES)** → **Add SES**.
+
+ 
+
+2. Enter the following details in the **Configure SES** page:
+
+ | Key | Description |
+ | --- | ----------- |
+ | **Configuration Name** | Give a name to your SES Configuration, e.g., `qa-ses` |
+ | **Access Key ID** | Valid access key from your **AWS Security credentials** page, e.g., `AKIAWEAVHF123ABCD123` |
+ | **Secret Access Key** | Secret access key from your **AWS Security credentials** page |
+ | **AWS Region** | The AWS region you used while setting up SES, e.g., `United States (Ohio)` |
+ | **Send email from** | The sender email address verified by SES for sending emails |
+
+3. Enable the **Set as default configuration to send emails** check box (optional) if you wish to keep this configuration as the default one for sending emails.
+
+4. Click **Save**.
+
+Now that the Email (SES) configuration is set up, you can proceed to [Add Notifications](#add-notifications).
+
+### Email SMTP Configuration
+
+:::caution Who Can Perform This Action?
+Only [Super-Admins](user-access.md) can create and manage SMTP configurations.
+
+:::
+
+
+:::info Prerequisite
+SMTP credentials (username and password) from your SMTP provider.
+
+**Additional Resources**:
+* [Generate AWS SMTP Credentials](https://docs.aws.amazon.com/ses/latest/dg/smtp-credentials.html)
+* [Configure Gmail SMTP](https://mailtrap.io/blog/gmail-smtp/#Step-1-Enabling-SMTP-in-Gmail-settings)
+
+:::
+
+#### Email SMTP Tutorial
+
+
+
+#### Steps
+
+1. Navigate to the **Global Configurations** → **Notifications** → **Configurations** → **Email (SMTP)** → **Add SMTP**.
+
+ 
+
+2. Enter the following details in the **Configure SMTP** page:
+
+ | Key | Description |
+ | :--- | :--- |
+ | **Configuration Name** | Give a name to your SMTP Configuration, e.g., `qa-smtp` |
+ | **SMTP Port** | The port number available in your SMTP settings, e.g., `587` |
+ | **SMTP Host address/Server** | The SMTP endpoint available in your SMTP settings, e.g., `smtp.gmail.com` |
+ | **SMTP Username** | A valid username created with your SMTP provider, e.g., `AKIAWEAVHF123ABCD123` in case of AWS SMTP and `johndoe@gmail.com` in case of Gmail SMTP. |
+ | **SMTP Password** | The password generated by your SMTP provider |
+ | **Send email from** | The sender email address verified by your SMTP provider for sending emails |
+
+3. Enable the **Set as default configuration to send emails** check box (optional) if you wish to keep this configuration as the default one for sending emails.
+
+4. Click **Save**.
+
+Now that the Email (SMTP) configuration is set up, you can proceed to [Add Notifications](#add-notifications).
+
+### Slack Configuration
+
+:::caution Who Can Perform This Action?
+Only [Super-Admins](user-access.md) can create and manage Slack configurations.
+
+:::
+
+
+:::info Prerequisite
+A Slack account, a Slack channel, and an [Incoming Webhook URL](https://api.slack.com/messaging/webhooks#getting_started).
+
+:::
+
+#### Slack Tutorial
+
+
+
+#### Steps
+
+1. Navigate to the **Global Configurations** → **Notifications** → **Configurations** → **Slack** → **Add Slack**.
+
+ 
+
+2. Enter the following details in the **Configure Slack** page:
+
+ | Key | Description |
+ | :--- | :--- |
+ | **Slack Channel** | Name of the Slack channel on which you wish to receive notifications, e.g., `qa-slack-channel` |
+ | **Webhook URL** | Enter a valid incoming webhook URL |
+ | **Project** | Select the project name to control user access. Apps outside your selected project cannot use this configuration, e.g., `qa-demo` |
+
+3. Click **Save**.
+
+Now that the Slack configuration is set up, you can proceed to [Add Notifications](#add-notifications).
+
+### Webhook Configuration
+
+:::caution Who Can Perform This Action?
+Only [Super-Admins](user-access.md) can create and manage Webhook configurations.
+
+:::
+
+
+:::info Prerequisite
+A Webhook URL to receive notifications (e.g., Microsoft Teams Webhook URL, Discord Webhook URL).
+
+:::
+
+#### Webhook Tutorial
+
+
+
+#### Steps
+
+1. Navigate to the **Global Configurations** → **Notifications** → **Configurations** → **Webhook** → **Add Webhook**.
+
+ 
+
+2. Enter the following details in the **Configure Webhook** page:
+
+ | Key | Description |
+ | :--- | :--- |
+ | **Configuration name** | Give a name to your webhook configuration, e.g., `qa-webhook` |
+ | **Webhook URL** | Enter a valid Webhook URL link |
+ | **Headers** | Add optional key-value pairs, e.g. `Content-Type: application/json` |
+ | **Data to be shared through webhook** | Write the payload content of the notification in a JSON format. Refer:
[Microsoft Teams Payload](#for-microsoft-teams)
[Discord Payload](#for-discord)
[Slack Payload](#for-slack)
[RingCentral Payload](#for-ringcentral)
|
+
+3. Click **Save**.
+
+Now that the Webhook configuration is set up, you can proceed to [Add Notifications](#add-notifications).
+
+---
+
+## Notifications
+
+### Add Notifications
+
+Once you have configured the notifications in the **Configuration** tab, you can then add, edit, and delete notifications in the **Notifications** tab. To create a new notification, follow the below instructions:
+
+1. Navigate back to the **Notifications** tab.
+
+ 
+
+2. Click the **Add Notification** button. The **Add Notifications** page is displayed.
+
+ 
+
+3. Enter your preferred recipient in the **Send to** drop-down box. You can add one or more recipients in the **Send to** drop-down box and the recipients can be any or all of the following:
+
+ a. A verified email address (by SES/SMTP)
+
+ b. A Slack channel
+
+ c. A Webhook
+
+4. Select your preferred filter type from the following in the **Select pipelines** field:
+
+ a. **Application** - Select **Application**, if you specifically know for which application(s) you need notifications for.
+
+ b. **Project** - Select **Project**, if you want notifications for one or more applications within specific project(s).
+
+ c. **Environment** - Select **Environment**, if you want notifications for applications deployed in specific environment(s) (e.g., production).
+
+ d. **Cluster** - Select **Cluster**, if you want notifications for applications in a specific cluster(s).
+
+ Once you have selected your preferred filter type, a list of CI/CD pipelines are displayed as filter results.
+
+ * indicates that it is a CI (Build) pipeline.
+
+ * indicates that it is a CD (Deployment) pipeline.
+
+ * You can also choose to receive notifications for any CI or CD pipelines that do not exist currently but may exist in future by enabling the **All current and future pipelines matching** pipeline in the **Pipeline Name** column.
+
+5. Select your preferred events for which a notification must be sent out in the **Events** column. The labels are displayed when you hover over the check boxes. You can enable one or more events as per your requirements.
+
+ a. **Trigger** - Enable this if you wish to receive notification whenever the pipeline is triggered.
+
+ b. **Success** - Enable this if you wish to receive notification upon a successful build or deploy.
+
+ c. **Failure** - Enable this if you wish to receive notification upon a failed build or deploy.
+
+6. Click **Save**. The notification is now successfully added. You can now build and deploy your application to get notifications of its CI/CD events.
+
+### Modify Notifications
+
+You can always edit existing notifications instead of deleting them and creating new ones from scratch. For example, if you initially created notifications for **Trigger** and **Failure** events of your CI/CD pipelines, you can perform removal/addition of events anytime by modifying them.
+
+To modify the events, follow the below steps:
+
+1. Navigate to the **Notifications** tab.
+
+2. Select your preferred notification.
+
+3. Check the check box in the left side of the notification to select it.
+
+4. Click **Modify Events** to modify the events. Check or uncheck the events based on your requirements.
+
+5. Click **Apply**.
+
+
+
+When creating notifications, if you previously added a recipient but now no longer want them to receive the CI/CD notifications, or if you want to add a new recipient or remove a specific communication medium (e.g., Slack), you can do so by modifying the recipients.
+
+To modify the recipients, follow the below steps:
+
+1. Navigate to the **Notifications** tab.
+
+2. Select your preferred notification.
+
+3. Check the check box in the left side of the notification to select it.
+
+4. Click **Modify Recipients** to modify the recipients. Add or remove the recipients based on your requirements.
+
+5. Click **Save Changes**.
+
+
+
+### Delete Notifications
+
+If you no longer wish to receive CI/CD notifications for an application, you can delete the corresponding notification from the **Notifications** tab.
+
+:::danger Important Note
+If you are currently receiving CI/CD notifications for a specific application, deleting its associated notification(s) in Devtron will stop the notifications for all events and recipients mentioned in those deleted notification(s).
+
+:::
+
+To delete a notification, follow the below steps:
+
+1. Navigate to the **Notifications** tab.
+
+2. Select your preferred notification.
+
+3. Check the check box in the left side of the notification to select it.
+
+4. Click **Delete** to delete the notification.
+
+
+
+---
+
+## Sample Payloads
+
+### For Microsoft Teams
+
+```json title="Teams Webhook Payload" showLineNumbers
+{
+ "type": "message",
+ "attachments": [
+ {
+ "contentType": "application/vnd.microsoft.card.adaptive",
+ "contentUrl": null,
+ "content": {
+ "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
+ "type": "AdaptiveCard",
+ "version": "1.2",
+ "body": [
+ {
+ "type": "TextBlock",
+ "text": "Automation Notification for Devtron \n *App* : {{devtronAppName}} \n *Event Type* : {{eventType}}"
+ }
+ ]
+ }
+ }
+ ]
+}
+```
+
+
+### For Slack
+
+```json title="Slack Webhook Payload" showLineNumbers
+{
+ "text": "CI Triggered",
+ "blocks": [
+ {
+ "type": "section",
+ "text": {
+ "type": "mrkdwn",
+ "text": "Automation Notification for Devtron \n *App* : {{devtronAppName}} \n *Event Type* : {{eventType}}"
+ },
+ "accessory": {
+ "type": "image",
+ "image_url": "https://awsmp-logos.s3.amazonaws.com/3ec35b66-ca90-4ed0-8c9e-146fa65e1037/f3966518a472c0e5f51c57f5efb20da7.png",
+ "alt_text": "Devtron Logo"
+ }
+ }
+ ]
+}
+```
+
+
+### For Discord
+
+```json title="Discord Webhook Payload" showLineNumbers
+{
+ "content": "Automation Notification at Devtron \n App : {{devtronAppName}} \n Event Type : {{eventType}}"
+}
+```
+
+
+### For RingCentral
+
+```json title="RingCentral Webhook Payload" showLineNumbers
+{
+ "activity": "CI Triggered",
+ "attachments": [
+ {
+ "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
+ "type": "AdaptiveCard",
+ "version": "1.0",
+ "body": [
+ {
+ "type": "TextBlock",
+ "text": "Automation Notification at Devtron \n App: {{devtronAppName}} \n Event Type: {{eventType}}",
+ "weight": "bolder",
+ "size": "medium",
+ "wrap": true
+ },
+ {
+ "type": "ColumnSet",
+ "columns": [
+ {
+ "type": "Column",
+ "width": "auto",
+ "items": [
+ {
+ "type": "Image",
+ "url": "https://awsmp-logos.s3.amazonaws.com/3ec35b66-ca90-4ed0-8c9e-146fa65e1037/f3966518a472c0e5f51c57f5efb20da7.png",
+ "size": "small",
+ "style": "person"
+ }
+ ]
+ },
+ {
+ "type": "Column",
+ "width": "stretch",
+ "items": [
+ {
+ "type": "TextBlock",
+ "text": "Container Image Repo: {{devtronContainerImageRepo}} \n Container Image Tag: {{devtronContainerImageTag}}",
+ "weight": "bolder",
+ "wrap": true
+ },
+ {
+ "type": "TextBlock",
+ "spacing": "none",
+ "text": "Triggered by: {{devtronTriggeredByEmail}}",
+ "isSubtle": true,
+ "wrap": true
+ }
+ ]
+ }
+ ]
+ },
+ ]
+ }
+ ]
+}
+```
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/plugin-policy.md b/versioned_docs/version-1.7/user-guide/global-configurations/plugin-policy.md
new file mode 100755
index 0000000000..8574998670
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/plugin-policy.md
@@ -0,0 +1,134 @@
+---
+id: plugin-policy
+title: Plugin Policy
+sidebar_label: Plugin Policy
+---
+
+# Plugin Policy
+
+## Introduction
+
+Your [application workflow](../creating-application/workflow/README.md) should follow certain standards and precautions to ensure reliability and a smooth release. For example, mandating load testing for production deployments might help you identify performance bottlenecks early rather than face possible outages, unhappy users, or revenue loss.
+
+The **Plugin Policy** feature in Devtron lets you enforce the presence of specific [plugins](../plugins/README.md) at various stages in your application's build and deployment pipelines, such as [pre-build](../../reference/glossary.md#pre-build), [post-build](../../reference/glossary.md#post-build), [pre-deployment](../../reference/glossary.md#pre-deployment), or [post-deployment](../../reference/glossary.md#post-deployment). Therefore, if the required plugins do not exist in the specified stage(s), you can decide the action (whether to allow or block the pipeline trigger).
+
+
+
+---
+
+## Tutorial
+
+
+
+---
+
+## Creating a Plugin Policy
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to create a plugin policy.
+:::
+
+1. Go to **Global Configurations** → **Plugin Policy**.
+
+ 
+
+2. Click **+ Create Profile**.
+
+ 
+
+3. Give a name to the profile, e.g., *`check-jira`*, and add a description (optional) preferably explaining what it does.
+
+ 
+
+4. Choose whether the profile should apply to the **Build pipeline** or the **Deployment pipeline**.
+
+:::caution Note
+A single policy cannot apply to both build and deployment pipelines simultaneously. You can create separate policies instead.
+:::
+
+5. Under **Mandatory Plugin(s)**, click **Add Plugin**.
+
+ 
+
+6. A list of plugins will appear for you to choose from. Select one or more plugins to make them mandatory for the pipeline you selected in step 4.
+
+ 
+
+:::info Tip
+There is a search box for you to quickly find the plugins. Moreover, since plugins are classified by tags, you can use the tag filter to find your intended plugins.
+:::
+
+7. Click **Done**.
+
+8. Use the dropdown menu to choose the stage (pre or post) at which you wish to enforce your chosen plugin(s). You can select mixed stages too.
+
+ 
+
+ Here, `Pre` means before and `Post` means after.
+
+9. Decide the action that the system should take in case your policy is not followed by the intended pipelines in your application workflow.
+
+ 
+
+ * **Allow respective triggers with warning** - This will allow the non-compliant pipeline to run. However, it will display an 'Action required' warning at the intended stage (pre/post) of the pipeline in the application's workflow.
+ * **Block respective triggers immediately** - This will not allow the non-compliant pipeline to run (whether manual execution or automated) effective immediately, unless the user configures the mandatory plugins.
+ * **Block respective triggers from date/time** - This will allow the non-compliant pipeline to run only till a given date and time. After that, it will block the non-compliant pipeline unless the user configures the mandatory plugins.
+
+10. Click **Save Changes**.
+
+---
+
+## Applying a Plugin Policy
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to apply a plugin policy.
+:::
+
+1. After you create a policy, you can apply it. Click **Apply Profile** on the same screen.
+
+ 
+
+2. From the **Select profiles to apply** dropdown, choose the policy you wish to apply. You also have the option to select more than one policy (if they exist) using the checkbox.
+
+ 
+
+3. Under **Apply selected policies to all pipelines**:
+ * **Global** - Select this option to apply your chosen policies to all application workflows across all clusters.
+ * **By Match Criteria** - Select this option to use a combination of filters to decide the target pipelines fulfilling your criteria. Your policy will only apply to such target pipelines.
+
+ 
+
+
+4. (*Skip this if you chose **Global** in the previous step*) Upon choosing the **By Match Criteria** option, the following match criteria are available for you:
+ * Project
+ * Application
+ * Cluster
+ * Environment
+ * Branch fixed
+ * Branch regex
+
+ Once you select the criteria, choose the value displayed to you in the dropdown list as shown below.
+
+ 
+
+5. (Optional) You may also write a note for your other team members to understand the intent and context of your policy.
+
+ 
+
+6. Click **Save Changes**.
+
+Once you apply the plugin policy, you can view the pipelines that are not adhering to your policy as shown below. Clicking on the non-compliant pipeline will take you directly to the application workflow prompting you to take action.
+
+
+
+---
+
+## Results
+
+Since we created a policy that blocks the trigger of non-compliant deployment pipelines, no user can trigger the deployment unless the mandatory plugins are configured as shown below.
+
+
+
+On the other hand, if you selected **Build pipeline** in step 4 of [Creating Plugin Policy](#creating-a-plugin-policy), the build trigger would get blocked as shown below.
+
+
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/projects.md b/versioned_docs/version-1.7/user-guide/global-configurations/projects.md
new file mode 100755
index 0000000000..200e4e141e
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/projects.md
@@ -0,0 +1,23 @@
+---
+id: projects
+title: Projects
+sidebar_label: Projects
+hide_table_of_contents: true
+---
+
+# Projects
+
+Projects are the logical grouping of your applications so that you can manage and control the access level of users.
+
+Refer [user access](../global-configurations/authorization/user-access.md) for more detail.
+
+## Add Project
+
+1. To add a project name, go to the `Projects` section of `Global Configurations`.
+2. Click `Add Project`.
+3. Provide a project name in the field and click `Save`.
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/pull-image-digest.md b/versioned_docs/version-1.7/user-guide/global-configurations/pull-image-digest.md
new file mode 100755
index 0000000000..165cd9fd70
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/pull-image-digest.md
@@ -0,0 +1,59 @@
+---
+id: pull-image-digest
+title: Pull Image Digest
+sidebar_label: Pull Image Digest
+---
+
+# Pull Image Digest
+
+## Introduction
+
+Devtron offers the option to pull container images using digest. Refer [CD Pipeline - Image Digest](../creating-application/workflow/cd-pipeline.md#pull-container-image-with-image-digest) to know the purpose it serves.
+
+Though it can be enabled by an application-admin for a given CD Pipeline, Devtron also allows super-admins to enable pull image digest at environment level.
+
+This helps in better governance and less repetitiveness if you wish to manage pull image digest for multiple applications across environments.
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to enable pull image digest at environment level.
+:::
+
+---
+
+## Steps to Enable Pull Image Digest
+
+From the left sidebar, go to **Global Configurations** → **Pull Image Digest**.
+
+As a super-admin, you can decide whether you wish to enable pull image digest [for all environments](#for-all-environments) or [for specific environments](#for-specific-environments).
+
+### For all Environments
+
+This is for enabling pull image digest for deployment to all environments.
+
+1. Enable the toggle button next to `Pull image digest for all existing & future environments`.
+
+ 
+
+2. Click **Save Changes**.
+
+ 
+
+
+### For Specific Environments
+
+This is for enabling pull image digest for specific environments. Therefore, only those applications deploying to selected environment(s) will have pull image digest enabled in its CD pipeline.
+
+1. Use the checkbox to choose one or more environments present within the list of clusters you have on Devtron.
+
+ 
+
+2. Click **Save Changes**.
+
+Once you enable pull image digest for a given environment in Global Configurations, users won't be able to modify the [image digest setting in the CD pipeline](../creating-application/workflow/cd-pipeline.md#pull-container-image-with-image-digest). The toggle button would appear disabled for that environment as shown below.
+
+
+
+
+
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/scoped-variables.md b/versioned_docs/version-1.7/user-guide/global-configurations/scoped-variables.md
new file mode 100755
index 0000000000..d512473598
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/scoped-variables.md
@@ -0,0 +1,344 @@
+---
+id: scoped-variables
+title: Using Scoped Variables in Devtron
+sidebar_label: Using Scoped Variables in Devtron
+---
+
+# Using Scoped Variables in Devtron
+
+## Introduction
+
+In Devtron, many configuration values such as a database name, memory limit, or service endpoint may need to be used in multiple places. Instead of entering the same value repeatedly, you can store it in a scoped variable.
+
+A scoped variable (key-value pair) allows you to define a value once and reuse it. The value of the variable will depend on the scopes mentioned below:
+
+| Category | Description |
+| :---------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **Global** | Variable value will be universally same throughout Devtron. |
+| **Cluster** | Variable value might differ for each Kubernetes cluster. |
+| **Environment** | Variable value might differ for each environment within a cluster, e.g., staging, dev, prod. |
+| **Application** | Variable value might differ for each application. |
+| **Environment + Application** | Variable value might differ for each application on a specific environment. |
+
+
+For example, you can create a variable named `db_host` to store the database host URL and set its value to `https://dev.company.com/mydb` for development environment, and for production environment you can set its value to `https://prod.company.com/mydb`, at the time of deployment, Devtron will automatically choose the correct value based on the environment.
+
+The table below illustrates how Devtron uses scoped variables defined for different scopes
+
+| Scope | Variable | Values |
+| :-----------| :--------|:------------------------------------------------------------------------------------|
+| Global | DB_NAME | `central-db` |
+| Cluster | DB_NAME | **AWS EKS (Cluster):** `eks-db` **GKE (Cluster):** `gke-db` |
+| Environment | DB_NAME | **Dev (Environment):** `dev-db` **Prod (Environment):** `prod-db` |
+| Application | DB_NAME | **App1 (Application):** `app1-db` **App2 (Application):** `app2-db` |
+| Env + App | DB_NAME | **Dev + App1:** `dev-app1-db` **Prod + App2:** `prod-app2-db` |
+
+
+### Precedence of Scoped Variables
+
+If the same variable is defined at more than one scope, Devtron resolves the value based on the following precedence order:
+
+| Precedence Order | Scope |
+|:------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------|
+| 1 (Highest) | Environment + Application |
+| 2 | Application |
+| 3 | Environment |
+| 4 | Cluster |
+| 5 (Lowest) | Global |
+
+1. **Environment + App:** This is the most specific scope, and it will take precedence over all other scopes. For example, the value of `DB_Name` variable for the `app1` application in the `dev` environment would be `dev-app1-db`, even though there is a global `DB_Name` variable set to `central-db`. If a variable value for this scope is not defined, the **App** scope will be checked.
+2. **Application:** This is the next most specific scope, and it will take precedence over the `Environment`, `Cluster`, and `Global` scopes. For example, the value of `DB_Name` variable for the `app1` application would be `app1-db`, even though the value of `DB_Name` exists in lower scopes. If a variable value for this scope is not defined, the **Environment** scope will be checked.
+3. **Environment:** This is the next most specific scope, and it will take precedence over the `Cluster` and `Global` scopes. For example, the value of `DB_Name` variable in the `prod` environment would be `prod-db`, even though the value of `DB_Name` exists in lower scopes. If a variable value for this scope is not defined, the **Cluster** scope will be checked.
+4. **Cluster:** This is the next most specific scope, and it will take precedence over the `Global` scope. For example, the value of `DB_Name` variable in the `GKE` cluster would be `gke-db`, even though there is a global `DB_Name` variable set to `central-db`. If a variable value for this scope is not defined, the **Global** scope will be checked.
+5. **Global:** This is the least specific scope, and it will only be used if no variable values are found in other higher scopes. The value of `DB_Name` variable would be `central-db`.
+
+### Advantages of using scoped variables
+
+* **Reduces repeatability**: Configuration management team can centrally maintain the static data.
+
+* **Simplifies bulk edits**: All the places that use a scoped variable, get updated when you change the value of the variable without requiring manual edits. If the scoped variable is being used in **Deployment Template**, **ConfigMap**, **Secret**, or **Job** the actual value will be resolved and propagated upon next trigger.
+
+* **Keeps data secure**: You can mark a variable as sensitive, so its value is hidden in the UI, reducing the risk of misuse or leakage. Refer [How to Define a Scoped Variable](#how-to-define-a-scoped-variable) to learn more.
+
+---
+
+## How to Define a Scoped Variable
+
+:::caution Who can Perform this Action?
+ Only super admins can define scoped variables.
+:::
+
+In Devtron, you can define scoped variables by using a YAML template. It will contain a schema for defining the scoped variables.
+
+Depending on your use case, you can do either one of the following:
+
+| Action | Description |
+|:---|:---|
+| **Download the YAML Template and define variables from scratch** | In case you are defining the Scoped Variables for the first time:
[Download the YAML template](#download-the-template) to your local system.
[Define your variables](#enter-the-values)
[Upload it back to the Devtron](#upload-the-template)
|
+| **Edit the existing saved YAML configuration** | If you wish to add, update or delete the existing scoped variables, you can edit the existing saved YAML configuration using any of the following methods:
Edit using the in-built UI Editor.
You can download the existing saved configuration as a YAML file in your local system and can modify it in your preferred local editor and then upload the file to implement changes.
|
+
+### Download the Template
+
+1. From the left sidebar, go to **Global Configurations** → **Scoped Variables**
+
+2. Click **Download template**.
+
+ 
+
+3. Open the downloaded template using any code editor (say VS Code).
+
+### Enter the Values
+
+The YAML file contains key-value pairs that follow the below schema:
+
+| Field | Type | Description |
+| :---------------------- | :------ | :--------------------------------------------------------------------------- |
+| `apiVersion` | string | The API version of the resource (comes pre-filled) |
+| `kind` | string | The kind of resource (i.e. Variable, comes pre-filled) |
+| `spec` | object | The complete specification object containing all the variables |
+| `spec.name` | string | Unique name of the variable, e.g. _DB_URL_ |
+| `spec.shortDescription` | string | A short description of the variable (up to 120 characters) |
+| `spec.notes` | string | Additional details about the variable (will not be shown on UI) |
+| `spec.isSensitive` | boolean | Whether the variable value is confidential (will not be shown on UI if true) |
+| `spec.values` | array | The complete values object containing all the variable values as per context |
+
+
+The `spec.values` array further contains the following elements:
+
+| Field | Type | Description |
+| :---------------------------------------------- | :----- | :----------------------------------------------------------------------------------------- |
+| `category` | string | The context, e.g., Global, Cluster, Application, Env, ApplicationEnv |
+| `value` | string | The value of the variable |
+| `selectors` | object | A set of selectors that restrict the scope of the variable |
+| `selectors.attributeSelectors` | object | A map of attribute selectors to values |
+| `selectors.attributeSelectors.` | string | The key of the attribute selector, e.g., **ApplicationName**, **EnvName**, **ClusterName** |
+| `selectors.attributeSelectors.` | string | The value of the attribute selector |
+
+
+
+Here's a truncated template containing the specification of two variables for your understanding:
+
+```yaml
+apiVersion: devtron.ai/v1beta1
+kind: Variable
+spec:
+
+# First example of a variable
+ - name: DB_URL
+ shortDescription: My application's customers are stored
+ notes: The DB is a MySQL DB running version 7.0. The DB contains confidential
+ information.
+ isSensitive: true
+ values:
+ - category: Global
+ value: mysql.example.com
+
+# Second example of a variable
+ - name: DB_Name
+ shortDescription: My database name to recognize the DB
+ notes: NA
+ isSensitive: false
+ values:
+ - category: Global
+ value: Devtron
+ - category: ApplicationEnv
+ value: app1-p
+ selectors:
+ attributeSelectors:
+ ApplicationName: MyFirstApplication
+ EnvName: prod
+```
+
+### Upload the Template
+
+1. Once you save the YAML file, go back to the screen where you downloaded the template.
+
+2. Click **Upload file to add**, to upload your saved YAML file.
+
+ 
+
+3. The content of the file will be uploaded for you to review and edit. Click **Review Changes**.
+
+ 
+
+4. You may check the changes between the last saved file and the current one before clicking **Save**.
+
+ 
+
+5. Click the **Variable List** tab to view the variables. Check the [How to Use a Scoped Variable](#how-to-use-a-scoped-variable) section to know more.
+
+ 
+
+---
+
+## Defining YAML values in scoped variables
+
+In Devtron, Scoped variables usually store simple values like strings or numbers, for example, if you want to connect multiple applications to the same SonarQube server, you can define a variable for its endpoint URL once instead of entering it everywhere.
+
+```yaml
+SONAR_ENDPOINT: https://sonarqube.yourcompany.com
+```
+
+But, in some cases, you may need to define more detailed configuration in a scoped variable, such as autoscaling configuration or resource configuration. You can achieve this by defining a YAML snippet as the value of a scoped variable.
+
+Defining YAML snippets as the value of a scoped variable will help you to reuse YAML configuration across multiple applications or environments. Scoped variables with YAML snippets can be changed based on the context (`category`) such as **Global**, **Cluster**, **Environment**, **Application**, **Environment+Application**.
+
+Here's a truncated template containing the specification of one scoped variable with a YAML snippet as its value defined for different contexts for your understanding:
+
+```yaml
+apiVersion: devtron.ai/v1beta1
+kind: Variable
+spec:
+ - notes: Resource Configuration
+ shortDescription: Scoped variable with YAML snippet
+ isSensitive: false
+ name: resources # Defining name for the variable.
+ values:
+ - category: Application
+ value: # Insert the YAML configuration block with proper indentation
+ limits:
+ cpu: 100m
+ memory: 100Mi
+ requests:
+ cpu: 100m
+ memory: 100Mi
+ selectors:
+ attributeSelectors:
+ ApplicationName: banking-preprod
+ - category: Env # Defining the variable for an environment.
+ value:
+ limits:
+ cpu: 75m
+ memory: 75Mi
+ requests:
+ cpu: 50m
+ memory: 50Mi
+ selectors:
+ attributeSelectors:
+ EnvName: devtron-demo # Specifying the environment
+ - category: Env # Defining variable's values for another environment
+ value:
+ limits:
+ cpu: 200m
+ memory: 200Mi
+ requests:
+ cpu: 100m
+ memory: 100Mi
+ selectors:
+ attributeSelectors:
+ EnvName: banking # Specifying another environment name.
+ - category: Global # Defining Variable's Values for global context.
+ value:
+ limits:
+ cpu: 50m
+ memory: 50Mi
+ requests:
+ cpu: 50m
+ memory: 50Mi
+```
+
+---
+## How to Edit an Existing Scoped Variable
+
+:::caution Who can Perform this Action?
+ Only super admins can edit scoped variables
+:::
+
+Only a super-admin can edit existing scoped variables.
+
+### Option 1: Directly edit using the UI
+
+
+
+### Option 2: Reupload the updated YAML file
+
+
+
+:::caution Note
+Re-uploading the YAML file will replace the previous file, so any variable that existed in the previous file but not in the latest one will be lost
+:::
+
+### Option 3: Edit through 'Environments' tab
+
+The **Environments** tab allows you to view and edit scoped variable values for individual environments.
+
+ 1. Go to the **Environments** tab; you will see a list of all environments and how many scoped variables are defined for each of them.
+
+ 
+
+ 2. Click the preferred environment name to view or edit.
+
+ 3. You can edit the variables using the GUI or YAML mode.
+
+ 
+
+ 
+
+:::info Note
+Any changes you made through this method will also update the saved YAML configuration.
+:::
+
+---
+
+## How to Use a Scoped Variable
+
+:::caution Who can Perform this Action?
+ Users need to have Admin permission or above (along with access to the environment and application) to enable to use a scoped variable.
+:::
+
+Once a variable is defined, it can be used by your authorized users on Devtron. A scoped variable widget would appear only on the screens that support its usage.
+
+Currently, the widget is shown only on the following screens in [App Configuration](../creating-application/README.md):
+
+* Workflow Editor → Edit build pipeline → Pre-build stage (tab)
+
+* Workflow Editor → Edit build pipeline → Post-build stage (tab)
+
+* Workflow Editor → Edit deployment pipeline → Post-Deployment stage (tab)
+
+* Workflow Editor → Edit deployment pipeline → Post-Deployment stage (tab)
+
+* Deployment Template
+
+* ConfigMaps
+
+* Secrets
+
+
+
+To use a scoped variable, click on the floating widget; a list of variables will be visible.
+
+
+
+Use the copy button to copy a relevant variable of your choice.
+
+
+
+It would appear in the following format upon pasting it within an input field: `@{{variable-name}}`.
+
+
+
+In case you are using a scoped variable in deployment template, you need to encapsulate it in double quotes i.e., `"@{{variable-name}}"`
+
+
+
+
+
+**Note:** Ignore the red underline while using a scoped variable in the deployment template.
+
+---
+
+## List of Predefined Variables
+
+There are some system variables that exist by default in Devtron that you can readily use if needed:
+
+* **DEVTRON_NAMESPACE**: Provides name of the [namespace](../../reference/glossary.md#namespace)
+* **DEVTRON_CLUSTER_NAME**: Provides name of the [cluster](../global-configurations/cluster-and-environments.md) configured on Devtron
+* **DEVTRON_ENV_NAME**: Provides name of the [environment](../../reference/glossary.md#environment)
+* **DEVTRON_IMAGE_TAG**: Provides [image tag](https://docs.docker.com/engine/reference/commandline/tag/) associated with the [container image](../../reference/glossary.md#image)
+* **DEVTRON_IMAGE**: Provides full image path of the container image, e.g., `gcr.io/k8s-minikube/kicbase:v0.0.39`
+* **DEVTRON_APP_NAME**: Provides name of the [application on Devtron](../create-application.md)
+
+:::info
+Currently, these variables do not appear in the scoped variable widget, but you may use them.
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/sso-login.md b/versioned_docs/version-1.7/user-guide/global-configurations/sso-login.md
new file mode 100755
index 0000000000..e865a0f1bd
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/sso-login.md
@@ -0,0 +1,52 @@
+---
+id: sso-login
+title: SSO Login Services
+sidebar_label: SSO Login Services
+---
+
+# SSO Login Services
+
+## Introduction
+
+After successful installation of Devtron, when you login for the first time with the [Admin Credentials](../../setup/install/devtron-oss.md#step-4-log-in-to-devtron) provided during the initial setup, you will have [Super-Admin](user-access.md) privileges with unrestricted access to all Devtron resources including configuring SSO and creating new user permissions.
+
+Therefore, we highly recommend that you also create and manage necessary [User Permissions](user-access.md) for other users immediately after configuring the SSO, to ensure secure and streamlined access to Devtron.
+
+Devtron uses Dex to authenticate you against the identity providers such as GitHub, GitLab, Google, Microsoft, LDAP, OIDC, and OpenShift.
+
+---
+
+## Supported SSO Providers
+
+To configure SSO in Devtron, navigate to **Global Configurations** → **Authorizations** → **SSO Login Services**. The SSO Login Services page is displayed.
+
+
+
+Devtron supports the following SSO providers:
+
+* [Google](./authorization/sso/google.md)
+
+* [GitHub](./authorization/sso/github.md)
+
+* [GitLab](./authorization/sso/gitlab.md)
+
+* [Microsoft](./authorization/sso/microsoft.md)
+
+* [LDAP](./authorization/sso/ldap.md)
+
+* [OpenID Connect](./authorization/sso/oidc.md)
+
+* [OpenShift](./authorization/sso/openshift.md)
+
+Only one SSO configuration can be active at a time. Display of multiple SSO configurations is currently not supported on Devtron's login page. When you create a SSO configuration, for e.g., Google, the Google SSO configuration is made active and will be used by Devtron for authentication.
+
+:::caution Note
+If Google SSO is configured in Devtron, for example, and multiple users have logged in using it, changing the SSO configuration from Google to GitHub or any other providers will forcibly sign out all users who were logged in with Google SSO.
+
+:::
+
+---
+
+## Next Steps
+
+The next step is to select your preferred SSO login service from the available list of providers and set up the SSO configuration.
\ No newline at end of file
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/tags-policy.md b/versioned_docs/version-1.7/user-guide/global-configurations/tags-policy.md
new file mode 100755
index 0000000000..9d9e753122
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/tags-policy.md
@@ -0,0 +1,178 @@
+---
+id: tags-policy
+title: Tags Policy
+sidebar_label: Tags Policy
+---
+
+# Tags Policy
+
+## Introduction
+
+Managing resources in Kubernetes often requires categorizing and grouping resources for better visibility and analysis. A common use case is cost allocation. By analyzing Kubernetes labels, teams can identify which departments consume the most resources. However, this is only possible if the relevant tags are propagated as Kubernetes labels.
+
+The **Tags Policy** feature in Devtron allows you to enforce a tag that must be provided before application creation or before deployment to an environment. For example, you can create a tag named `team` and if it is propagated as labels to Kubernetes resources, you can easily audit the team-wise usage and resource consumption by its tag. Additionally, you can enforce deployment-specific rules for your applications if required tags are missing.
+
+
+
+## Adding Tag Policy
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to create tag policy.
+:::
+
+1. Go to **Global Configurations** → **Tags Policy**.
+
+ 
+
+2. Click **+ Add Tag**.
+
+ 
+
+3. **Suggested tags/Mandatory tags** - You can either suggest tags or make them mandatory when creating applications:
+ * If you want the person creating an application to compulsarily provide a tag, use `Mandatory tags`. Mandatory tags have two consequences:
+ * Blocks application creation if the required tag is not provided.
+ * Blocks deployment if restriction is enforced.
+
+ * If you just want to offer tag suggestions, use `Suggested tags`. These will appear as [dropdown suggestions](#appearance-of-suggested-tags) when adding tags to applications globally, and users can optionally use them if needed.
+
+ 
+
+4. **Select Project(s)** - To mandate a tag, you must provide a project where this policy should apply. All applications in the project will require the mandatory tag to be entered. Whereas, suggested tags are shown as suggestions globally (i.e., for all apps).
+
+ 
+
+5. **Tag Key** - Enter the key from the key-value pair (tag), e.g., *Business Unit*, *Team*, *Owner*.
+
+ 
+
+6. **Value Choices** - Here, you can create a list of values for the key-value pair (tag). A tag value can be a free text or you can restrict it to a set of values for the user to choose from.
+
+ 
+
+You may enable **Allow Custom Input** to give the user a choice to enter their own value if it is unavailable in the list. Or you may skip creating the list of choices altogether so that your user can enter their own value.
+
+7. **Description** - Write a brief description explaining the significance of the tag.
+
+ 
+
+8. **Allow/Block Deployments** - Mandatory tags additionally let you define what should happen if users do not configure them in the intended projects:
+ * **Allow deployments** - Use this option if you want to allow the user to deploy an existing application where mandatory tags are not configured yet.
+ * **Block deployment stages of prod environments** - Use this option if you want to prevent the user from deploying an existing application to [production environments](../global-configurations/cluster-and-environments.md#add-environment-to-a-cluster), if mandatory tags are not configured.
+ * **Block deployment stages of non-prod enviroments** - Use this option if you want to prevent the user from deploying an existing application to [non-production environments](../global-configurations/cluster-and-environments.md#add-environment-to-a-cluster), if mandatory tags are not configured.
+ * **Block deployment stages of all environments** - This will prevent the user from deploying an existing application to all environments if mandatory tags are not configured.
+
+ 
+
+9. **Propagate Tag** - By default, tags assigned to applications in Devtron are not automatically propagated to Kubernetes resources as labels. For more information on how labels function in Kubernetes, refer to the [Kubernetes Labels Documentation](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
+
+ 
+
+
+
+ 
+
+
+
+ 
+
+:::Info Changing Propagation in Suggested Tags vs. Mandatory Tags
+**In suggested tags**: When you enable/disable tag propagation, users can still disable/enable it during app creation, ensuring its tags propagate to associated Kubernetes resources.
+
+**In mandatory tags**: When you enable/disable tag propagation, users do not get the option to change the propagation setting.
+:::
+
+10. (Optional) Click the **`+`** option to create more suggested tags or more mandatory tags in one go.
+
+ 
+
+11. Click **Save** to create the tag(s).
+
+---
+
+## Editing a Tag
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to edit tags.
+:::
+
+You can edit an existing tag key to do the following:
+* Modify the tag key
+* Add/remove value choices
+* Tweak the description
+* Change deployment restrictions
+* Add or remove projects
+* Convert Tags from Suggested to Mandatory (or vice versa)
+* Enable/Disable the propagation of tags
+
+Once done, click **Update** to apply the changes.
+
+
+
+### Editing in Bulk
+
+You may use the checkboxes to add/remove projects from multiple tags at once as shown below.
+
+
+
+---
+
+## Deleting a Tag
+
+:::caution Who Can Perform This Action?
+Users need to have super-admin permission to delete tags.
+:::
+
+If you delete a 'Suggested Tag', it will no longer show up as a suggestion to your users while adding tags. If it's a 'Mandatory Tag', the deployment rules (if any, associated with that tag) will no longer be enforced.
+
+However, this action will not delete the applied tag from existing applications.
+
+
+
+If you wish to delete multiple tags, you may use the checkboxes to select the tags and delete them from the floating widget as shown below.
+
+
+
+
+---
+
+## Results
+
+### Appearance of Mandatory Tags
+
+* The mandatory tag is available for users to configure after they select the project in the app creation page. It is marked by a red asterisk.
+
+ 
+
+* For an existing application, users can configure it from the **Overview** page of the application.
+
+ 
+
+* In a project where mandatory tags are enabled, if the user does not provide values for the mandatory tags, the user cannot create an app in that project.
+
+ 
+
+### Appearance of Suggested Tags
+
+Users can see a dropdown list of your suggested tags while creating a new app or on the **Overview** page of an existing application.
+
+
+
+### Impact on Deployment Pipelines
+
+If an existing application belongs to a project where mandatory tags are enabled along with deployment restrictions, if the user does not provide values for the mandatory tags, they cannot deploy that app to the intended environment (check step 9 of [adding tags](#adding-tag-policy)).
+
+The same is true for auto-triggering deployment pipelines. A new image available after the build stage will not auto-trigger the deployment pipeline due to the missing mandatory tags.
+
+
+
+### Impact on Application Group
+
+Similarly, if deployment restrictions apply due to missing mandatory tags, users cannot deploy apps to the intended environment from the [Application Group](../application-groups.md).
+
+
+
+### Impact on Release
+
+If a user attempts to [deploy a release](../software-distribution-hub/release-hub.md#deploying-release) that contains applications with missing mandatory tags, the deployment will be blocked if restrictions apply.
+
+
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/user-access.md b/versioned_docs/version-1.7/user-guide/global-configurations/user-access.md
new file mode 100755
index 0000000000..55280b16da
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/user-access.md
@@ -0,0 +1,270 @@
+---
+id: user-access
+title: User Access
+sidebar_label: User Access
+---
+
+# User Access
+
+
+
+Like any enterprise product, Devtron supports fine grained access control to the resources based on
+
+1. Type of action allowed on the Devtron resources (Create Vs View)
+2. Sensitivity of the data (Editing image Vs Editing memory)
+
+Access can be added to the User either directly or via Groups.
+
+## Role-based Access Levels
+
+Devtron supports 5 levels of access:
+
+1. **View**: Users with `view` access have the least privileges. Such users can only view combination of environments, applications and helm charts on which access has been granted to the user. They cannot view sensitive data like secrets used in applications or charts.
+2. **Build and Deploy**: In addition to `view` privilege mentioned above, users with `build and deploy` permission can build and deploy the image of permitted applications and helm charts to permitted environments.
+3. **Admin**: Users with `admin` privileges can create, edit, delete, and view permitted applications in permitted projects.
+4. **Manager**: Users with `manager` privileges can do everything that an `admin` user can do. Additionally, they can also give and revoke access of users for the applications and environments of which they are the manager.
+5. **Super Admin**: Users with `super admin` privileges have unrestricted access to all the Devtron resources. Super Admins can create, modify, delete and view any Devtron resource without any restriction; it's like Superman without the weakness of Kryptonite. Moreover, they can add and delete user access across any Devtron resource, add delete git repository credentials, container registry credentials, cluster, and environment.
+6. **Image approver**: Users with `Image approver` privileges have the authority to approve requests for image deployment.
+7. **Configuration approver**: Users with `Configuration approver` privileges have the authority to approve changes to protected configurations of Deployment Template, ConfigMaps, and Secrets. However, the user who proposed the changes cannot self-approve, even if they have configuration approver or super-admin privileges.
+8. **Artifact promoter**: Users with this privilege have the authority to approve promotion of [artifacts](../../reference/glossary.md#artifacts) directly to the target CD pipeline.
+
+
+## User Roles And Permissions
+
+### 1. Custom Applications
+
+| User Roles | View | Create | Edit | Delete | Build & Deploy|
+| :--- | :---: | :---: | :---: | :---: | :---: |
+| View | Yes | No | No | No | No |
+| Build and Deploy | Yes | No | No | No | Yes |
+| Admin | Yes | Yes | Yes | Yes | Yes |
+| Manager | Yes | Yes | Yes | Yes | Yes |
+| Super Admin | Yes | Yes | Yes | Yes | Yes |
+
+### 2. Helm Charts
+
+| User Roles | View | Deploy | Edit | Delete |
+| :---: | :---: | :---: | :---: | :---: |
+| View Only | Yes | No | No | No |
+| Build and Deploy | Yes | No | No | No |
+| Admin | Yes | Yes | Yes | Yes |
+| Manager | Yes | Yes | Yes | Yes |
+| Super Admin | Yes | Yes | Yes | Yes |
+
+#### 3. User Access
+
+| User Roles | Add User Access | Edit User Access | Delete User Access |
+| :--- | :---: | :---: | :---: |
+| Manager | Yes | Yes | Yes |
+| Super Admin | Yes | Yes | Yes |
+
+#### 4. Global Configurations
+
+| User Role | Add Global Config | Edit Global Config | Delete Global Config |
+| :--- | :---: | :---: | :---: |
+| Super Admin | Yes | Yes | Yes |
+
+To control the access of User and Group-
+
+Go to the left main panel → Global Configurations` → `User Access`
+
+## Users
+
+### 1. Add new user
+
+Click **Add User**, to add one or multiple users.
+
+
+
+### 2. Create User Permissions
+
+When you click `Add User`, you will see 6 options to set permission for users which are as follow:
+
+- Email addresses
+- Assign super admin permissions
+- Group Permissions
+- Devtron Apps Permissions
+ - Project
+ - Environment
+ - Applications
+ - Roles
+- Helm Apps Permissions
+ - Project
+ - Environment or cluster/namespace
+ - Applications
+ - Permission
+- Chart group permissions
+
+## Email addresses:
+
+In the `Email address` box, you have to provide the mail ID of the user to whom you want to give access to your applications.
+
+**`IMP`** Please note that Email address should be same as that in the `email` field in the JWT token returned by OIDC provider.
+
+### Assign super admin permissions
+
+If you check the option `Assign super admin permissions`, the user will get full access to your system and the rest of the options will disappear. Please check [above](#role-based-access-levels) to see permission levels. Only users with super admin permissions can assign super admin permissions to a user.
+
+
+
+Click **Save** and your user will be saved with super admin permissions.
+
+We suggest that super admin privileges should be given to only select few.
+
+If you don’t want to assign super admin permissions then you have to provide the rest of the information.
+
+### Group Permissions
+
+This is used to assign user to a particular group and user inherits all the permissions granted to this group. The Group permissions section contains a drop-down of all existing groups on which you have access. This is optional field and more than one groups can be selected for a user.
+
+We will discuss how to create groups in the later section.
+
+### Devtron Apps permissions
+
+Access to devtron applications can be given to user by attaching permission directly to his/her email id through the `Devtron Apps` section. This section has 4 options to manage the permissions of your users.
+
+- **Project**
+
+Select a project from the drop-down to which you want to give permission to the users. You can select only one project at a time if you want to select more than one project then click **Add row**.
+
+- **Environment**
+
+In the `Environment` section, you can select one or more than one or all environments at a time. Click on the environment section, you will see a drop-down of your environments and select any environment on which you want to give permission to the user.
+
+**`IMP`** If `all environments` option is selected then user gets access to all current environments and any new environment which gets associated with this application later.
+
+- **Applications**
+
+Similarly, you can select `Applications` from the drop-down corresponding to your selected Environments. In this section, you can also give permissions to one or more than one or to all applications at a time.
+
+**`IMP`** If `all applications` option is selected then user gets access to all current applications and any new application which gets associated with this project later.
+
+- **Roles**
+
+ Inside the `Role`, you actually choose which type of permissions you want to give to the users.
+
+There are four different view access levels/Role available for both User and Group as described [above](#role-based-access-levels):
+
+
+
+You can add multiple rows, for Devtron app permission.
+
+Once you have finished assigning the appropriate permissions for the listed users, click **Save**.
+
+### Helm Apps Permissions
+
+Access to devtron applications can be given to user by attaching permission directly to his/her email id through the `Devtron Apps` section. This section has 4 options to manage the permissions of your users.
+
+- **Project**
+
+Select a project from the drop-down to which you want to give permission to the users. You can select only one project at a time if you want to select more than one project then click **Add row**.
+
+- **Environment or cluster/namespace**
+
+In the `Environment` section, you can select one or more than one or all environments at a time. Click on the environment section, you will see a drop-down of your environments and select any environment on which you want to give permission to the user.
+
+**`IMP`** If `all environments` option is selected then user gets access to all current environments and any new environment which gets associated with this application later.
+
+- **Applications**
+
+Similarly, you can select `Applications` from the drop-down corresponding to your selected Environments. In this section, you can also give permissions to one or more than one or to all applications at a time.
+
+**`IMP`** If `all applications` option is selected then user gets access to all current applications and any new application which gets associated with this project later.
+
+- **Permission**
+
+ Inside the `Role`, you actually choose which type of permissions you want to give to the users.
+
+There are four different view access levels/Role available for both User and Group as described [above](#role-based-access-levels):
+
+
+
+### Chart Group Permissions
+
+You can also manage the access of users to Chart Groups in your project.
+
+**NOTE:** You can only give users the ability to `create` or `edit`, not both.
+
+Click on the checkbox of `Create`, if you want the users to create, view, edit, or delete the chart groups.
+
+
+
+To permit a user to only `edit` the chart groups, check `Specific chart group` from `Edit` drop-down. In the following field, select the chart group for which you want to grant the user edit permission.
+
+Go to `Edit` drop-down, if you want to `allow` or `deny` users to edit the chart groups.
+
+Select on `Deny` option from the drop-down, if you want to restrict the users to edit the chart groups.
+
+
+
+Select the `Specific Charts` option from the drop-down and then select the chart groups for which you want to allow users to edit, from the other drop-down menu.
+
+
+
+Click on `Save`, once you have configured all the required permissions for the users.
+
+| Action | Permissions |
+| :--- | :--- |
+| View | Only can view chart groups |
+| Create | Can create, view, edit or delete |
+| Edit |
-
-
-
-
-
-
-
| Tells you whether the application deployment is blocked or allowed for the chosen environment. This card also displays the upcoming blackout/maintenance window and the remaining time for the blackout/maintenance window to complete. Refer to [Deployment Window](../global-configurations/deployment-window.md) for more information. |
| **Chart Used** (available only for Helm apps) | Displays the chart used to deploy the application. When you hover over the (**?**) icon in the card, you can directly configure the YAML values by clicking the **Go to Configure** option. |
| **Deployed commit** (available only for Devtron apps) | Displays the commit ID of the deployed image. When you click **Details**, the commit ID, repository name, branch name, and the deployed image ID are displayed. |
-| **Deployment Status** | Tells you the deployment status (e.g., `Succeeded` or `Failed`). The available deployment statuses in Devtron are: 
on the left side of your tag to propagate a tag.
again.
-* Click `Save`.
-
-
+* Click the symbol  on the left side of your tag to propagate a tag.
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
indicates that it is a CI (Build) pipeline.
+
+ * 
indicates that it is a CD (Deployment) pipeline.
+
+ * You can also choose to receive notifications for any CI or CD pipelines that do not exist currently but may exist in future by enabling the **All current and future pipelines matching** pipeline in the **Pipeline Name** column.
+
+5. Select your preferred events for which a notification must be sent out in the **Events** column. The labels are displayed when you hover over the check boxes. You can enable one or more events as per your requirements.
+
+ a. **Trigger** - Enable this if you wish to receive notification whenever the pipeline is triggered.
+
+ b. **Success** - Enable this if you wish to receive notification upon a successful build or deploy.
+
+ c. **Failure** - Enable this if you wish to receive notification upon a failed build or deploy.
+
+6. Click **Save**. The notification is now successfully added. You can now build and deploy your application to get notifications of its CI/CD events.
+
+### Modify Notifications
+
+You can always edit existing notifications instead of deleting them and creating new ones from scratch. For example, if you initially created notifications for **Trigger** and **Failure** events of your CI/CD pipelines, you can perform removal/addition of events anytime by modifying them.
+
+To modify the events, follow the below steps:
+
+1. Navigate to the **Notifications** tab.
+
+2. Select your preferred notification.
+
+3. Check the check box in the left side of the notification to select it.
+
+4. Click **Modify Events** to modify the events. Check or uncheck the events based on your requirements.
+
+5. Click **Apply**.
+
+
+
+When creating notifications, if you previously added a recipient but now no longer want them to receive the CI/CD notifications, or if you want to add a new recipient or remove a specific communication medium (e.g., Slack), you can do so by modifying the recipients.
+
+To modify the recipients, follow the below steps:
+
+1. Navigate to the **Notifications** tab.
+
+2. Select your preferred notification.
+
+3. Check the check box in the left side of the notification to select it.
+
+4. Click **Modify Recipients** to modify the recipients. Add or remove the recipients based on your requirements.
+
+5. Click **Save Changes**.
+
+
+
+### Delete Notifications
+
+If you no longer wish to receive CI/CD notifications for an application, you can delete the corresponding notification from the **Notifications** tab.
+
+:::danger Important Note
+If you are currently receiving CI/CD notifications for a specific application, deleting its associated notification(s) in Devtron will stop the notifications for all events and recipients mentioned in those deleted notification(s).
+
+:::
+
+To delete a notification, follow the below steps:
+
+1. Navigate to the **Notifications** tab.
+
+2. Select your preferred notification.
+
+3. Check the check box in the left side of the notification to select it.
+
+4. Click **Delete** to delete the notification.
+
+
+
+---
+
+## Sample Payloads
+
+### For Microsoft Teams
+
+```json title="Teams Webhook Payload" showLineNumbers
+{
+ "type": "message",
+ "attachments": [
+ {
+ "contentType": "application/vnd.microsoft.card.adaptive",
+ "contentUrl": null,
+ "content": {
+ "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
+ "type": "AdaptiveCard",
+ "version": "1.2",
+ "body": [
+ {
+ "type": "TextBlock",
+ "text": "Automation Notification for Devtron \n *App* : {{devtronAppName}} \n *Event Type* : {{eventType}}"
+ }
+ ]
+ }
+ }
+ ]
+}
+```
+
+
+### For Slack
+
+```json title="Slack Webhook Payload" showLineNumbers
+{
+ "text": "CI Triggered",
+ "blocks": [
+ {
+ "type": "section",
+ "text": {
+ "type": "mrkdwn",
+ "text": "Automation Notification for Devtron \n *App* : {{devtronAppName}} \n *Event Type* : {{eventType}}"
+ },
+ "accessory": {
+ "type": "image",
+ "image_url": "https://awsmp-logos.s3.amazonaws.com/3ec35b66-ca90-4ed0-8c9e-146fa65e1037/f3966518a472c0e5f51c57f5efb20da7.png",
+ "alt_text": "Devtron Logo"
+ }
+ }
+ ]
+}
+```
+
+
+### For Discord
+
+```json title="Discord Webhook Payload" showLineNumbers
+{
+ "content": "Automation Notification at Devtron \n App : {{devtronAppName}} \n Event Type : {{eventType}}"
+}
+```
+
+
+### For RingCentral
+
+```json title="RingCentral Webhook Payload" showLineNumbers
+{
+ "activity": "CI Triggered",
+ "attachments": [
+ {
+ "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
+ "type": "AdaptiveCard",
+ "version": "1.0",
+ "body": [
+ {
+ "type": "TextBlock",
+ "text": "Automation Notification at Devtron \n App: {{devtronAppName}} \n Event Type: {{eventType}}",
+ "weight": "bolder",
+ "size": "medium",
+ "wrap": true
+ },
+ {
+ "type": "ColumnSet",
+ "columns": [
+ {
+ "type": "Column",
+ "width": "auto",
+ "items": [
+ {
+ "type": "Image",
+ "url": "https://awsmp-logos.s3.amazonaws.com/3ec35b66-ca90-4ed0-8c9e-146fa65e1037/f3966518a472c0e5f51c57f5efb20da7.png",
+ "size": "small",
+ "style": "person"
+ }
+ ]
+ },
+ {
+ "type": "Column",
+ "width": "stretch",
+ "items": [
+ {
+ "type": "TextBlock",
+ "text": "Container Image Repo: {{devtronContainerImageRepo}} \n Container Image Tag: {{devtronContainerImageTag}}",
+ "weight": "bolder",
+ "wrap": true
+ },
+ {
+ "type": "TextBlock",
+ "spacing": "none",
+ "text": "Triggered by: {{devtronTriggeredByEmail}}",
+ "isSubtle": true,
+ "wrap": true
+ }
+ ]
+ }
+ ]
+ },
+ ]
+ }
+ ]
+}
+```
diff --git a/versioned_docs/version-1.7/user-guide/global-configurations/plugin-policy.md b/versioned_docs/version-1.7/user-guide/global-configurations/plugin-policy.md
new file mode 100755
index 0000000000..8574998670
--- /dev/null
+++ b/versioned_docs/version-1.7/user-guide/global-configurations/plugin-policy.md
@@ -0,0 +1,134 @@
+---
+id: plugin-policy
+title: Plugin Policy
+sidebar_label: Plugin Policy
+---
+
+# Plugin Policy
+
+## Introduction