feat: update projectEnv doc

docs/cli.mdx

@@ -24,7 +24,16 @@ pip install sleakops
 To authenticate with the SleakOps CLI, you need an API_KEY. You can obtain this key from the [console <FiExternalLink/>](https://console.sleakops.com/settings/apikey) by clicking on Generate API-Key. 
 Each company is allowed to have only one active API_KEY at a time. If you request a new API_KEY, the old one will be automatically revoked. The page shows the company keys and who generated them.
 
-Once you have your API_KEY, you can use it as an argument when running SleakOps commands or set it as an environment variable named SLEAKOPS_KEY. 
+Once you have your API_KEY, you can use it as an argument when running SleakOps commands or set it as an environment variable named SLEAKOPS_KEY.
+
+:::tip Setting up SLEAKOPS_KEY in CI/CD Pipelines
+For CI/CD pipelines, it's recommended to set SLEAKOPS_KEY as a secret environment variable in your Git provider:
+- **GitHub**: Add it as a repository secret in Settings → Secrets and variables → Actions
+- **GitLab**: Add it as a CI/CD variable in Settings → CI/CD → Variables
+- **Bitbucket**: Add it as a repository variable in Repository settings → Pipelines → Repository variables
+
+This ensures secure access to SleakOps services without exposing your API key in your pipeline configuration files.
+::: 
 
 
 ### 2. Create a Build

docs/project/access_config.mdx

@@ -0,0 +1,73 @@
+---
+sidebar_label: Dependency Access Configuration
+sidebar_position: 7
+---
+
+import Zoom from "react-medium-image-zoom";
+import "react-medium-image-zoom/dist/styles.css";
+
+# Access Configuration
+
+The Access Configuration allows you to extend your project's permissions by granting access to external dependencies from other projects and attaching additional IAM policies. This feature enables cross-project resource sharing and enhanced security configurations.
+
+## Configuration Steps
+
+1. Navigate to **Project** → **Settings**
+2. Select **Access Configuration** from the settings menu
+3. Configure external dependencies and extra policies as needed
+4. Click **Apply changes** to save your configuration
+
+<Zoom overlayBgColorEnd="rgba(255, 255, 255, 0.8)">
+<img
+    src="/img/project/access-config.png"
+    alt="access config"
+/>
+</Zoom>
+
+## External Dependencies
+
+### Dependencies Already Assigned
+
+This section shows dependencies that have already been linked to your current project. These dependencies are available for your workloads to use and are marked with a blue checkbox to indicate they are active.
+
+**Features:**
+- View all currently assigned external dependencies
+- See dependency type and project information
+- Dependencies are automatically configured with appropriate permissions
+
+### Available External Dependencies
+
+This section displays dependencies from other projects that you can grant access to your current project. This enables cross-project resource sharing and collaboration.
+
+**How it works:**
+- Select dependencies from other projects that you wish to grant access to this project
+- Only dependencies from projects you have access to will be displayed
+- Once selected, the dependency becomes available in the "Dependencies Already Assigned" section
+
+## Extra Policies
+
+The Extra Policies section allows you to attach additional IAM policies to your project, providing enhanced permissions beyond the default project access.
+
+### Adding Extra Policies
+
+1. Click the **"Attach more policies"** button
+2. Select from available IAM policies in your AWS account
+3. Review the policy permissions before attaching
+4. The policies will be applied to grant additional permissions to the project
+
+### Policy Management
+
+- **Custom Policies**: Attach policies you've created in your AWS IAM console
+- **AWS Managed Policies**: Use pre-configured AWS policies for common use cases
+- **Policy Review**: All attached policies are listed and can be reviewed
+- **Removal**: Policies can be detached if no longer needed
+
+:::tip Cross-Project Access
+External dependencies enable teams to share resources across different projects, improving collaboration and resource utilization.
+:::
+
+:::warning Security Considerations
+- Review all attached policies to ensure they follow the principle of least privilege
+- Regularly audit external dependencies to ensure they're still needed
+- Monitor access patterns to identify any unusual activity
+:::

docs/project/build_resources.mdx

@@ -0,0 +1,51 @@
+---
+sidebar_label: Deploy Build Resources
+sidebar_position: 6
+---
+
+import Zoom from "react-medium-image-zoom";
+import "react-medium-image-zoom/dist/styles.css";
+
+# Deploy Build Resources
+
+The Deploy Build Resources configuration allows you to specify the CPU and memory resource requests for both build and deployment processes. This helps ensure that your builds and deployments have sufficient resources to complete successfully while optimizing costs.
+
+## Resource Configuration
+
+<Zoom overlayBgColorEnd="rgba(255, 255, 255, 0.8)">
+<img
+    src="/img/project/build-deploy-resources.png"
+    alt="dockerfile settings page"
+/>
+</Zoom>
+
+Access the Deploy Build Resources settings:
+
+1. Navigate to **Project** → **Settings**
+2. Select **Deploy Build Resources** from the settings menu
+3. Configure the resource values according to your project's requirements
+4. Click **Save** to apply the changes
+
+### Build Request Resources
+
+Configure the resources allocated during the build process:
+
+- **Build Request CPU**: Specifies the CPU allocation for build processes (measured in millicores)
+- **Build Request Memory**: Specifies the memory allocation for build processes (measured in GiB)
+
+### Deploy Request Resources
+
+Configure the resources allocated during the deployment process:
+
+- **Deploy Request CPU**: Specifies the CPU allocation for deployment processes (measured in millicores)
+- **Deploy Request Memory**: Specifies the memory allocation for deployment processes (measured in GiB)
+
+:::tip Resource Optimization
+- Start with default values and adjust based on build performance
+- Monitor build times and resource usage to optimize allocations
+- Higher resource allocations can reduce build times but increase costs
+:::
+
+:::warning Resource Limits
+- Ensure your cluster has sufficient resources to accommodate the requested allocations
+::: 

docs/project/configure_your_dockerfile.mdx

@@ -27,6 +27,16 @@ When configuring your Dockerfile in SleakOps, you need to:
 ### How do I add the Dockerfile arguments?
 </summary>
 Once you specify the Dockerfile path, SleakOps analyzes it to identify any build arguments that are required. If necessary, SleakOps will prompt you to provide values for these arguments. You can update these arguments at any time through the SleakOps interface.
+
+:::tip DockerArgs from CLI
+You can also define DockerArgs when using the SleakOps CLI for builds. Use the `--docker-args` parameter to pass build arguments directly from the command line:
+
+```bash
+sleakops build -p myproject -b main --docker-args "ARG1=value1,ARG2=value2"
+```
+
+This is particularly useful for CI/CD pipelines where you want to pass different arguments based on the environment or build context.
+:::
 </details>
 
 <details>
@@ -45,6 +55,14 @@ You can add the by following the steps below.
 
 ## Set up your Dockerfile
 ### 1. Access to your project settings
+
+<Zoom overlayBgColorEnd="rgba(255, 255, 255, 0.8)">
+<img
+    src="/img/project/dockerfile-settings.png"
+    alt="dockerfile settings page"
+/>
+</Zoom>
+
   1. **Complete the Dockerfile Path:** To enable SleakOps to search for the needed arguments, specify the Dockerfile Path and save the changes. SleakOps will then analyze your Dockerfile and render the required build arguments for you to provide.
 
 | **Dockerfile Path** | The Dockerfile is a critical component used to build your project into a container. The Dockerfile Path field requires the relative file path to your Dockerfile within the repository (e.g., /Dockerfile, /src/Dockerfile, or /app/Dockerfile). This file contains the instructions needed to create the container image, which SleakOps will build and later use for deployments. |

docs/project/index.mdx

@@ -151,4 +151,57 @@ Here the parameters that SleakOps allows you to customize during the creation:
 | **Branch** | The branch represents a specific version or line of development within the repository. This allows you to deploy a particular version of your code (e.g., main, develop, or a feature-specific branch). The branch you select will determine the code that gets built and deployed within the associated environment.  |
 | **Dockerfile Path** | The Dockerfile is a critical component used to build your project into a container. The Dockerfile Path field requires the relative file path to your Dockerfile within the repository (e.g., /Dockerfile, /src/Dockerfile, or /app/Dockerfile). This file contains the instructions needed to create the container image, which SleakOps will build and later use for deployments.  |
 
-Once you’ve completed the form, click on Submit in order to trigger the Dockerfile validation and then the build.
+Once you've completed the form, click on Submit in order to trigger the Dockerfile validation and then the build.
+
+## ProjectAccess
+
+ProjectAccess allows you to configure custom IAM policies and roles for your project, providing fine-grained control over AWS resource permissions. This feature enables you to define specific access patterns that align with your security requirements and operational needs.
+
+### Custom Policies
+
+Custom policies allow you to create tailored IAM policies that grant specific permissions to your project's workloads. These policies should be created in the same AWS account where your project is deployed.
+
+#### Creating Custom Policies
+
+1. **Navigate to AWS IAM Console** in your project's AWS account
+2. **Create a new policy** with the specific permissions your application requires
+3. **Reference the policy** in SleakOps using the policy ARN
+
+:::tip Policy Best Practices
+- Follow the principle of least privilege - grant only the minimum permissions necessary
+- Use resource-specific ARNs when possible to limit access scope
+- Regularly review and audit policy permissions
+:::
+
+#### Referencing Custom Policies in SleakOps
+
+When configuring ProjectAccess, you can reference your custom policies by providing the policy ARN:
+
+```
+arn:aws:iam::ACCOUNT_ID:policy/YourCustomPolicyName
+```
+
+### AWS Managed Policies
+
+SleakOps also supports AWS managed policies, which are pre-configured policies maintained by AWS. These policies provide common permission sets for various AWS services.
+
+#### Common AWS Managed Policies
+
+- **AmazonS3ReadOnlyAccess**: Read-only access to S3 buckets
+- **AmazonRDSReadOnlyAccess**: Read-only access to RDS instances
+- **CloudWatchReadOnlyAccess**: Read-only access to CloudWatch metrics and logs
+- **AmazonEC2ReadOnlyAccess**: Read-only access to EC2 resources
+
+:::info Policy Association
+When associating roles or policies with your project, it's recommended to use the minimum number of policies necessary. This approach:
+- Reduces complexity in permission management
+- Improves security by limiting potential attack vectors
+- Makes troubleshooting easier when permission issues arise
+:::
+
+### Best Practices for Policy Management
+
+1. **Minimize Policy Count**: Associate the fewest number of policies possible while meeting your requirements
+2. **Regular Audits**: Periodically review and audit the policies associated with your projects
+3. **Environment-Specific Policies**: Consider using different policies for different environments (dev, staging, prod)
+4. **Documentation**: Maintain clear documentation of why specific policies are required for each project

docs/project/volumes.mdx

@@ -11,4 +11,51 @@ You can define the volumes in the [Project](/project) form:
 Whenever a volume is needed, Sleakops deploys an EFS CSI Driver within the [cluster](/cluster). This allows every Project to have its own unique volume mount, storing folders based on the paths you specify.
 A practical use-case for Volumes is when you want all your pods to access the same files, such as a shared folder that requires its content to be persistent.
 
-For more details on how EFS is used for volumes, refer to the [EFS documentation](/cluster/addons/efs).
+For more details on how EFS is used for volumes, refer to the [EFS documentation](/cluster/addons/efs).
+
+## Creating Volumes
+
+<Zoom overlayBgColorEnd="rgba(255, 255, 255, 0.8)">
+<img
+    src="/img/project/create-new-volume.png"
+    alt="new volume modal"
+/>
+</Zoom>
+
+To create a new volume for your project:
+
+1. **Click on "Create Volumes"** in the Project settings
+2. **Add the mount path** - Specify the directory path where the volume will be mounted in your containers
+3. **Set storage capacity** - Define the amount of storage space allocated to the volume
+4. **Choose retention policy** - Select between:
+   - **Delete**: Volume will be removed when deleted from SleakOps
+   - **Retain**: Volume will persist in AWS even if removed from SleakOps
+
+:::tip Volume Configuration
+- Mount paths should be absolute paths (e.g., `/app/data`, `/var/logs`)
+- Storage capacity is specified in GB
+- The retain policy determines data persistence when volumes are removed
+:::
+
+## Deleting Volumes
+
+<Zoom overlayBgColorEnd="rgba(255, 255, 255, 0.8)">
+<img
+    src="/img/project/delete-volume.png"
+    alt="delete volume click"
+/>
+</Zoom>
+
+To remove a volume from your project:
+
+1. **Click the "X" button** next to the volume you want to delete
+2. **Confirm the deletion** when prompted
+
+:::warning Data Loss Warning
+Deleting a volume will permanently remove all data stored in it. Make sure to backup any important data before deletion.
+:::
+
+:::info Retain Policy Behavior
+- **Delete Policy**: Volume and all data are permanently removed from AWS
+- **Retain Policy**: Volume remains in AWS but is detached from the project, preserving your data
+:::

i18n/es/docusaurus-plugin-content-docs/current/cli.mdx

@@ -26,6 +26,15 @@ Cada empresa puede tener solo una API_KEY activa a la vez. Si solicitas una nuev
 
 Una vez que tengas tu API_KEY, puedes usarla como argumento al ejecutar comandos de SleakOps o configurarla como una variable de entorno llamada SLEAKOPS_KEY.
 
+:::tip Configurando SLEAKOPS_KEY en Pipelines de CI/CD
+Para pipelines de CI/CD, se recomienda configurar SLEAKOPS_KEY como una variable de entorno secreta en tu proveedor de Git:
+- **GitHub**: Agrégala como un secreto de repositorio en Settings → Secrets and variables → Actions
+- **GitLab**: Agrégala como una variable de CI/CD en Settings → CI/CD → Variables
+- **Bitbucket**: Agrégala como una variable de repositorio en Repository settings → Pipelines → Repository variables
+
+Esto asegura el acceso seguro a los servicios de SleakOps sin exponer tu clave API en los archivos de configuración de tu pipeline.
+:::
+
 ### 2. Crear un Build
 
 Para crear una compilación de tu aplicación, usa el siguiente comando:
@@ -43,6 +52,15 @@ Como se mencionó anteriormente, la clave puede ser un entrada aquí o una varia
 
 También puedes indicar si quieres que el proceso **espere** a que la compilación termine o no.
 
+:::tip DockerArgs desde CLI
+También puedes definir DockerArgs cuando uses la CLI de SleakOps para builds. Usa el parámetro `--docker-args` para pasar argumentos de construcción directamente desde la línea de comandos:
+
+```bash
+sleakops build -p myproject -b main --docker-args "ARG1=value1,ARG2=value2"
+```
+
+Esto es particularmente útil para pipelines de CI/CD donde quieres pasar diferentes argumentos basados en el entorno o contexto de construcción.
+:::
 
 ### 3. Realizar un Despliegue
 Una vez que tu compilación esté lista, puedes desplegar tu aplicación fácilmente usando el siguiente comando: