update README

README.md

@@ -37,7 +37,7 @@ All configurations are hierarchically structured in YAML files, which can inheri
 
 Configuration files support templating with Jinja2 and global variables, facilitating dynamic adjustments. The primary types of configuration files include:
 
-1. **`alaka.yml`**: Contains global configurations for a hierarchical layer, affecting all subordinate apps.
+1. **`alaka.yml`**/**`alaka-*.yml`**: Contains global configurations for a hierarchical layer, affecting all subordinate apps.
 2. **`example.com.yml`** (`<your-domain>.yml`): A minimalist configuration for each instance, specifying the apps to be installed, the instance domain and optionally instance specific configurations.
     - an **instance** means a collection of apps that are integrated with each other (one server / vm can contain multiple instances)
 3. **`combine.yml`**: Manages configurations required to integrate multiple apps with each other.
@@ -47,7 +47,7 @@ Configuration files support templating with Jinja2 and global variables, facilit
 
 ### App Configuration
 
-`alaka.yml`, `example.com.yml` and `combine.yml` contain a similar configuration structure.
+`alaka.yml`/`alaka-*.yml`, `example.com.yml` and `combine.yml` contain a similar configuration structure.
 For each app/recipe the following `<app_configurations>` can be used:
 
 - **`uncomment`/`comment`**: Manages the active status of lines in configuration files, such as uncommenting needed variables .
@@ -67,11 +67,11 @@ The `combine.yml` configuration additionally contains:
 
 ### Configuration Structure
 
-Configuration can be simplified into a single `example.com.yml` or expanded into multiple layered `alaka.yml` files for complex deployments. This allows for easy maintenance of multiple instances or groups.
+Configuration can be simplified into a single `example.com.yml` or expanded into multiple layered `alaka.yml`/`alaka-*.yml` files for complex deployments. This allows for easy maintenance of multiple instances or groups.
 These configurations are designed to modularize and simplify the management of app settings and integrations, making it easier to maintain and scale your deployments.
 
-1. **`alaka.yml` and `example.com.yml`**
-    - **`alaka.yml`**: Contains global app configurations (`<app_recipe>`) which are inherited by all configurations within its hierarchical layer. This ensures consistent settings across multiple applications.
+1. **`alaka.yml`/`alaka-*.yml` and `example.com.yml`**
+    - **`alaka.yml`/`alaka-*.yml`**: Contain global app configurations (`<app_recipe>`) which are inherited by all configurations within its hierarchical layer. This ensures consistent settings across multiple applications. All `alaka-*.yml` files inside a directory are merged into one configuration. Avoid overrides between `alaka-*.yml` inside of one layer.
     - **`example.com.yml`**: Specifies which apps should be deployed (`<app_recipe>` entries), focusing on the individual needs of each instance.
     - Configurations within these files are structured as follows, with specific `<app_configuration>` settings detailed in the [App Configuration](#app-configuration) section:
 
@@ -115,8 +115,8 @@ nextcloud:
 Alakazam supports a flexible inheritance model for configuration management, allowing for both simplicity and complexity depending on your deployment needs:
 
 - **Simple Configuration**: For straightforward setups, you can manage everything within a single `example.com.yml` file, placing all necessary configurations directly in this document.
-- **Multiple Similar Instances**: To manage multiple similar instances efficiently, common application configurations can be centralized in a global `alaka.yml`. This method reduces duplication by allowing shared settings across multiple instances.
-- **Grouped Instances**: For more complex setups, instances can be organized into folders, each with its own `alaka.yml`. This structure allows for group-specific configurations, making it easier to manage settings at different levels of your infrastructure hierarchy.
+- **Multiple Similar Instances**: To manage multiple similar instances efficiently, common application configurations can be centralized in a global `alaka.yml`. This method reduces duplication by allowing shared settings across multiple instances. The global `alaka.yml` can also be split into multiple `alaka-*.yml` files which are merged together.
+- **Grouped Instances**: For more complex setups, instances can be organized into folders, each with its own `alaka.yml`/`alaka-*.yml`. This structure allows for group-specific configurations, making it easier to manage settings at different levels of your infrastructure hierarchy.
 - **Inherited Configurations**: In even more complex scenarios, each group can inherit configurations from the levels above it. This cascading setup ensures that changes at a higher level can be automatically applied to all subordinate groups and instances, maintaining consistency and ease of updates across your entire environment.
 
 This hierarchical approach to configuration is designed to scale with your system’s complexity and can be visualized through the following example diagram:
@@ -159,7 +159,7 @@ rallly:
 
 Ensure that DNS records are set up for all your applications. The simplest approach is to create a `CNAME` record for the wildcard domain `*.example.com` to cover all subdomains used by the apps.
 
-For a more comprehensive configuration, refer to the example in [./examples/alaka.yml](./examples/alaka.yml), which can also serve as a template for single-instance configurations (`example.com.yml`).
+For a more comprehensive configuration, refer to the example in [./examples](./examples), which can also serve as a template for single-instance configurations (`example.com.yml`).
 
 Steps to initialize the instance: