fix: refactor url paths (#2205)

content/blogs/2024-01-22-release-0-14.md

@@ -167,7 +167,7 @@ triggers:
 
 The website has now a **new improved search** across the docs, plugins and blog posts, as well as [blueprints](https://kestra.io/blueprints) which are now available not only in the UI but also on the website. The plugins got their own (beautiful!) [homepage](https://kestra.io/plugins) with a dedicated search to make it easier to find the plugin you need.
 
-We've also added new documentation pages for [Azure DevOps CI/CD](../docs/version-control-cicd/cicd/05-azure-devops.md), and [Role-Based Access Control (RBAC)](../docs/06.enterprise/03.auth-users/rbac.md).
+We've also added new documentation pages for [Azure DevOps CI/CD](../docs/version-control-cicd/cicd/05-azure-devops.md), and [Role-Based Access Control (RBAC)](../docs/06.enterprise/03.auth/rbac.md).
 
 ## Bug fixes and reliability improvements
 

content/blogs/2024-02-29-release-0-15.md

@@ -285,15 +285,15 @@ We've also added a new generic Singer plugin that simultaneously integrates with
 
 ## Enterprise Edition Updates
 
-For Enterprise Edition users, we've added a new [Setup page](../docs/06.enterprise/01.getting-started-ee/02.setup.md) in the UI, showing the most important configuration options and streamlining the setup process for a new Kestra instance. That setup wizard will guide you through the initial configuration of your instance, making it easier to get started.
+For Enterprise Edition users, we've added a new [Setup page](../docs/06.enterprise/01.getting-started/02.setup.md) in the UI, showing the most important configuration options and streamlining the setup process for a new Kestra instance. That setup wizard will guide you through the initial configuration of your instance, making it easier to get started.
 
 ![ee_setup_page](/blogs/2024-02-29-release-0-15/ee_setup_page.png)
 
 We've also revamped the RBAC system, with improved handling of Superadmin access. There is also a dedicated UI page called Access allowing you to configure tenant-level RBAC.
 
 ![access_page](/blogs/2024-02-29-release-0-15/access_page.png)
 
-The new **Service Accounts UI page** allows you to create and manage [service accounts](../docs/06.enterprise/03.auth-users/service-accounts.md), and we've introduced API tokens valid for a specific period of time, allowing you to grant programmatic access to Kestra for Users and Service Accounts. This feature is particularly useful for CI/CD with GitHub Actions and Terraform, as well as for using the API token in API calls.
+The new **Service Accounts UI page** allows you to create and manage [service accounts](../docs/06.enterprise/03.auth/service-accounts.md), and we've introduced API tokens valid for a specific period of time, allowing you to grant programmatic access to Kestra for Users and Service Accounts. This feature is particularly useful for CI/CD with GitHub Actions and Terraform, as well as for using the API token in API calls.
 
 ![service_account_create](/docs/user-interface-guide/service_account_create.png)
 

content/blogs/2024-04-22-liveness-heartbeat.md

@@ -53,7 +53,7 @@ This approach was successful in most deployment scenarios. However, in more comp
 
 One of the first disadvantages was that the heartbeat configuration had to be the same for all workers. This configuration was managed globally by the Executor service, which was responsible for detecting unhealthy workers by applying the same rule to all. However, all workers don't necessarily have the same load, the same type of processing or being deployed in the same network. As a result, some workers may be more prone to resource saturation, leading to thread starvation or even network disconnection due to reduced bandwidth.
 
-As an example, Kestra Edition Enterprise provides the [Worker Group](../docs/06.enterprise/04.scalability-productivity/worker-group.md) feature, which allows you to create logical groups of Workers. Those groups can then be targeted for specific task executions.  Worker groups come in handy when you need a task to be executed on a worker having specific hardware configurations (GPUs with preconfigured CUDA drivers), in a specific network availability zone, or when you want to isolate long-running and resource-intensive workloads. In such a context, you can relax the heartbeat mechanism and tolerate more missing heartbeats to avoid considering a worker dead when it is not.
+As an example, Kestra Edition Enterprise provides the [Worker Group](../docs/06.enterprise/04.scalability/worker-group.md) feature, which allows you to create logical groups of Workers. Those groups can then be targeted for specific task executions.  Worker groups come in handy when you need a task to be executed on a worker having specific hardware configurations (GPUs with preconfigured CUDA drivers), in a specific network availability zone, or when you want to isolate long-running and resource-intensive workloads. In such a context, you can relax the heartbeat mechanism and tolerate more missing heartbeats to avoid considering a worker dead when it is not.
 
 ### Zombies may lead to duplicates
 
@@ -94,7 +94,7 @@ Now that we have a better understanding of the lifecycle of services and how the
 
 ### Configuring liveness and heartbeat
 
-Starting from Kestra 0.16.0, the liveness and heartbeat mechanism can be configured individually for each service through the properties under `kestra.server.liveness`. This means you can now adapt your configuration depending on the service type, the service load, or even your [Worker Group](../docs/06.enterprise/04.scalability-productivity/worker-group.md).
+Starting from Kestra 0.16.0, the liveness and heartbeat mechanism can be configured individually for each service through the properties under `kestra.server.liveness`. This means you can now adapt your configuration depending on the service type, the service load, or even your [Worker Group](../docs/06.enterprise/04.scalability/worker-group.md).
 
 Without going into too much detail, here is the default and recommended configuration for a Kestra JDBC deployment.
 

content/blogs/2024-06-13-quadis.md

@@ -94,7 +94,7 @@ Once the installation and setup of the [secret configuration](https://kestra.io/
 ## What’s Next
 
 Moving from a legacy system made of more than a hundred pipelines is always a complex task. At Kestra we’re impressed by the involvement of Quadis teams and the speed of their development with Kestra.
-After onboarding the first users, they expect to have more than 30 users using Kestra in the coming months. Even more: some of them will be less technical people. Thanks to the Kestra user interface and [role-based access control](../docs/06.enterprise/03.auth-users/rbac.md) they could execute flows without the fear of messing up with other works.
+After onboarding the first users, they expect to have more than 30 users using Kestra in the coming months. Even more: some of them will be less technical people. Thanks to the Kestra user interface and [role-based access control](../docs/06.enterprise/03.auth/rbac.md) they could execute flows without the fear of messing up with other works.
 
 As part of a broader modernization of Quadis operation, Kestra would also be the support for the new data lake architecture.
 

content/blogs/2024-10-17-cd-cd-kestra-comparison.md

@@ -201,7 +201,7 @@ Kestra, instead, uses a declarative YAML-based syntax that is much easier to rea
 #### Scalability Challenges
 Jenkins requires a lot of manual setup for distributed builds or scaling across [multiple nodes](https://www.jenkins.io/doc/book/managing/nodes/), and this can lead to bottlenecks when the infrastructure needs to grow.
 
-In contrast, Kestra leverages [Worker Groups](../docs/06.enterprise/04.scalability-productivity/worker-group.md), which are collections of workers that can be targeted for executing tasks based on specific requirements, allowing for efficient workload distribution across different nodes. Additionally, [Task Runners](../docs/06.enterprise/04.scalability-productivity/task-runners.md) enable the dynamic allocation of tasks in various cloud environments, facilitating the execution of compute-intensive jobs without the need for permanent infrastructure.
+In contrast, Kestra leverages [Worker Groups](../docs/06.enterprise/04.scalability/worker-group.md), which are collections of workers that can be targeted for executing tasks based on specific requirements, allowing for efficient workload distribution across different nodes. Additionally, [Task Runners](../docs/06.enterprise/04.scalability/task-runners.md) enable the dynamic allocation of tasks in various cloud environments, facilitating the execution of compute-intensive jobs without the need for permanent infrastructure.
 
 These features provide streamlined and scalable approach to managing complex workflows, reducing the operational overhead associated with scaling Jenkins.
 

content/blogs/release-0-19.md

@@ -493,7 +493,7 @@ Using an invalid worker group key in a task leads to task runs being stuck in a
 
 With the new Worker Groups UI page, worker groups are now treated as API-first objects — they must be created first from the UI, API, CLI, or Terraform before being used in flows. This ensures that worker group keys are valid and exist before they are referenced in tasks.
 
-Check the [Worker Group](../docs/06.enterprise/04.scalability-productivity/worker-group.md) documentation to learn how to create and manage worker groups.
+Check the [Worker Group](../docs/06.enterprise/04.scalability/worker-group.md) documentation to learn how to create and manage worker groups.
 
 In short, this new feature improves the way worker groups are managed, reducing the risk of misconfigured flows and providing better visibility into workers' health.
 

content/docs/04.workflow-components/01.tasks/02.scripts/index.md

@@ -17,7 +17,7 @@ There are dedicated plugins for `Python`, `R`, `Julia`, `Ruby`,  `Node.js`, `Pow
 
 By default, these tasks run in individual Docker containers (taskRunner type: `io.kestra.plugin.scripts.runner.docker.Docker`). You can overwrite that default behavior if you prefer that your scripts run in a local process (taskRunner type: `io.kestra.plugin.core.runner.Process`) instead.
 
-If you use a [commercial version of Kestra](../../../06.enterprise/index.md), you can also run your scripts on [dedicated remote workers](../../../06.enterprise/04.scalability-productivity/worker-group.md) by specifying a `workerGroup` property or using other [Task Runner types](../../../task-runners/04.types/index.md) for AWS, GCP, Azure, and Kubernetes.
+If you use a [commercial version of Kestra](../../../06.enterprise/index.md), you can also run your scripts on [dedicated remote workers](../../../06.enterprise/04.scalability/worker-group.md) by specifying a `workerGroup` property or using other [Task Runner types](../../../task-runners/04.types/index.md) for AWS, GCP, Azure, and Kubernetes.
 
 The following pages dive into details of each task runner, supported programming languages, and how to manage dependencies.
 

content/docs/04.workflow-components/01.tasks/index.md

@@ -45,7 +45,7 @@ The table below lists the core task properties available to all tasks.
 | `retry`           | Task [retry](../../04.workflow-components/12.retries.md) behavior                                                                                                                                                                                                                                                                                                    |
 | `timeout`         | Task [timeout](../../04.workflow-components/13.timeout.md) expressed in [ISO 8601 Durations](https://en.wikipedia.org/wiki/ISO_8601#Durations).                                                                                                                                                                                                                      |
 | `disabled`        | Set it to `true` to [disable](../../04.workflow-components/16.disabled.md) execution of the task.                                                                                                                                                                                                                                                                    |
-| `workerGroup.key` | To execute this task on a specific [Worker Group](../../06.enterprise/04.scalability-productivity/worker-group.md) (EE)                                                                                                                                                                                                                                                                         |
+| `workerGroup.key` | To execute this task on a specific [Worker Group](../../06.enterprise/04.scalability/worker-group.md) (EE)                                                                                                                                                                                                                                                                         |
 | `allowFailure`    | Boolean flag allowing to [the execution to continue](../../04.workflow-components/11.errors.md) even if this task fails.                                                                                                                                                                                                                                                |
 | `logLevel`        | Property to define the log level granularity for which logs will be inserted into the backend database. By default, all logs are stored. However, if you restrict that to e.g., the `INFO` level, all lower log levels such as `DEBUG` and TRACE won't be persisted.                                                                                                          |
 | `logToFile`       | Boolean flag that lets you store logs as a file in internal storage. That file can be previewed and downloaded from the `Logs` and `Gantt` Execution tabs. When set to true, logs aren’t saved in the database, which is useful for tasks that produce a large amount of logs that would otherwise take up too much space. The same property can be set on triggers. |

content/docs/06.enterprise/02.governance/tenants.md

@@ -15,10 +15,10 @@ A tenant represents an **isolated environment within a single Kestra instance**.
 Each tenant functions as a separate entity with its own resources, such as flows, triggers, or executions. Multi-tenancy enables different teams, projects, or customers to operate independently within the same Kestra instance, ensuring data privacy, security along with separation of resources between business units, teams, or customers. For example, you can have a `dev` tenant for development, a `staging` tenant for testing, and a `prod` tenant for production.
 
 ::alert{type="info"}
-You can think of multi-tenancy as running multiple virtual instances in a single physical instance of [Kestra Cloud](/cloud) or [Kestra Enterprise Edition](../01.getting-started-ee/01.enterprise-edition.md).
+You can think of multi-tenancy as running multiple virtual instances in a single physical instance of [Kestra Cloud](/cloud) or [Kestra Enterprise Edition](../01.getting-started/01.enterprise-edition.md).
 ::
 
-When multi-tenancy is enabled, all resources (such as [flows](../../04.workflow-components/01.flow.md), [triggers](../../04.workflow-components/07.triggers/index.md), [executions](../../04.workflow-components/03.execution.md), [RBAC](../03.auth-users/rbac.md), and more) are isolated by the tenant. This means that you can have a flow with the same identifier and the same namespace in multiple tenants at the same time.
+When multi-tenancy is enabled, all resources (such as [flows](../../04.workflow-components/01.flow.md), [triggers](../../04.workflow-components/07.triggers/index.md), [executions](../../04.workflow-components/03.execution.md), [RBAC](../03.auth/rbac.md), and more) are isolated by the tenant. This means that you can have a flow with the same identifier and the same namespace in multiple tenants at the same time.
 
 Data stored inside the internal storage are also isolated by tenants.
 

content/docs/06.enterprise/03.auth-users/api.md → content/docs/06.enterprise/03.auth/api.md

@@ -9,7 +9,7 @@ How to interact with Kestra Enterprise Edition using the API.
 
 ## Authentication
 
-To authenticate with the Kestra API, you will need to create an [API token](../../06.enterprise/03.auth-users/api-tokens.md). You can create it directly from the Kestra UI.
+To authenticate with the Kestra API, you will need to create an [API token](../../06.enterprise/03.auth/api-tokens.md). You can create it directly from the Kestra UI.
 
 Once you have your API token, you can use it to authenticate with the API. You can use the `Authorization` header with the `Bearer` token to authenticate with the API.
 

content/docs/06.enterprise/03.auth-users/rbac.md → content/docs/06.enterprise/03.auth/rbac.md

@@ -114,7 +114,7 @@ However, you should use Kestra through the role system.
 
 #### Through the UI
 
-First time you launch Kestra, if no prior action has been made through the CLI, you will be invited to setup Kestra through the [Setup Page](../01.getting-started-ee//02.setup.md).
+First time you launch Kestra, if no prior action has been made through the CLI, you will be invited to setup Kestra through the [Setup Page](../01.getting-started//02.setup.md).
 
 This interface will offer you to create your first User which will be automatically assigned the `Super Admin` privilege.
 
@@ -190,7 +190,7 @@ If you see an error when creating a new User or Service Account, it might be cau
 
 ####  Through the UI
 
-First time you launch Kestra, if no prior action has been made through the CLI, you will be invited to setup Kestra through the [Setup Page](../01.getting-started-ee//02.setup.md).
+First time you launch Kestra, if no prior action has been made through the CLI, you will be invited to setup Kestra through the [Setup Page](../01.getting-started//02.setup.md).
 
 This interface will offer you to create the first User which will automatically create the role Admin and bind the User to the role.
 

content/docs/06.enterprise/05.instance-management/instance.md → content/docs/06.enterprise/05.instance/dashboard.md

@@ -62,7 +62,7 @@ Temporarily pause all workflows and services for upgrades:
 ::badge{version=">=0.10" editions="EE"}
 ::
 
-Create [worker groups](../04.scalability-productivity/worker-group.md) to isolate workloads or delegate tasks to given workers:  
+Create [worker groups](../04.scalability/worker-group.md) to isolate workloads or delegate tasks to given workers:  
 - **Add Worker Groups**: Define groups with specific resource limits or labels.  
 - **Assign Tasks**: Route workflows to designated groups via worker group key within a task or trigger.  
 

content/docs/06.enterprise/index.md

@@ -5,7 +5,7 @@ editions: ["EE"]
 
 How to configure Kestra Enterprise Edition.
 
-The [Enterprise Edition](01.getting-started-ee//01.enterprise-edition.md) is a robust, enterprise-grade version of Kestra deployed to your private infrastructure. It offers security and governance features including multi-tenancy, authentication, SSO, RBAC, namespace-level management, distributed worker groups, worker isolation, secrets manager integrations, audit logs, and more.
+The [Enterprise Edition](01.getting-started//01.enterprise-edition.md) is a robust, enterprise-grade version of Kestra deployed to your private infrastructure. It offers security and governance features including multi-tenancy, authentication, SSO, RBAC, namespace-level management, distributed worker groups, worker isolation, secrets manager integrations, audit logs, and more.
 
 This section describes those features in detail and explains how to configure them.
 

content/docs/07.architecture/02.server-components.md

@@ -25,7 +25,7 @@ Workers are highly configurable and scalable, accommodating a wide range of task
 
 ## Worker Group (EE)
 
-In the Enterprise Edition, [Worker Groups](../06.enterprise//04.scalability-productivity/worker-group.md) allow tasks and polling triggers to be executed on specific worker sets. They can be beneficial in various scenarios, such as using compute instances with GPUs, executing tasks on a specific OS, restricting backend access, and region-specific execution. A default worker group is recommended per tenant or namespace.
+In the Enterprise Edition, [Worker Groups](../06.enterprise//04.scalability/worker-group.md) allow tasks and polling triggers to be executed on specific worker sets. They can be beneficial in various scenarios, such as using compute instances with GPUs, executing tasks on a specific OS, restricting backend access, and region-specific execution. A default worker group is recommended per tenant or namespace.
 
 To specify a worker group for a task, use the `workerGroup.key` property in the task definition to point the task to a specific worker group key. If no worker group is specified, the task will be executed on the default worker group.