> For the complete documentation index, see [llms.txt](https://docs.eximee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.eximee.com/documentation/documentation-en/eksploatacja-aplikacji/designer/srodowiska.md). # Environment Module {% hint style="info" %} Availability of the functionality depends on the license and may not be available in all deployments. {% endhint %} The module is used to manage request templates. It enables: * previewing the version of the selected request on available environments, * migrating the request template (together with its dependencies) between environments, * rolling back the last request migration on a specific environment, * running the selected request on the selected environment in the simulator (see Requests Simulator), * downloading the business package (the request template together with the dependencies required to run it on the environment). ## Displaying request information on environments After navigating to the module, the button **REQUEST**.

After selecting a request from the list, the published and highest version of the request will be displayed on each available environment:

**Figure 2.** Request status on individual environments

## Running a request Clicking the button next to the published version redirects to the requests simulator module, automatically selecting the environment from which the redirect occurred. ## Template migration To migrate a request together with dependencies to a higher environment, click the arrow between the tiles:

**Figure 3.** Arrow migrating the request to a higher environment

This will trigger migration and publishing of the template in the highest version to the specified environment. Additionally, files necessary for the proper functioning of the request will be imported to the environment into the appropriate directories. Template migration is performed only on the first environment, due to the shared database for all LAN instances. The dependencies for the request, however, are delivered to all instances. ### Validation during template migration Before migrating the template together with dependencies, environment consistency validation takes place. The validator checks whether the dependencies imposed on the target environment will not introduce inconsistencies. If the validator encounters any problems, it will display a list and the content of warnings to the user. At this point, the user can decide whether they still want to force migration to the target environment.

## Environment action menu To open the environment action menu, press the button **Open action menu** located in the upper-right corner of the environment tile.

### Template export Clicking the option **Export package** in the action menu will build a zip file containing the request template in the latest version on a given environment together with the dependencies needed to run it.

**Figure 6.** Menu containing the package export command

The file will be saved in the Nexus repository. In response, a popup with a link to the package in Nexus will appear in the browser.

**Figure 7.** Window with a link to the package

* Template export from the repository is performed from the first environment, due to the shared database for all LAN instances. * Visibility of the export option is controlled by a flag from the environment configuration (`bundleExporter`). ### Environment rollback Option **Rollback** serves to restore on a given environment the last backup of directories with request dependencies. Backups are created when migrating any request with dependencies to an environment. Each environment has its own backup for each previously migrated request. * Template rollback is performed only on the first environment, due to the shared database for all LAN instances. * Visibility of this option is controlled by a flag from the environment configuration (`migrationTarget`). If no migration has been finalized previously, the option will be greyed out, because there is no available package that could be restored. ## Application graphics Migration and export of applications in the Environments module also include its [application graphics](/documentation/documentation-en/budowanie-aplikacji/aplikacja-biznesowa/elementy-aplikacji-artefakty/grafiki-aplikacji.md). ### Migration of an application with graphics 1. In the **Applications** module, click **Migrate** for the selected application or select the application in the **Environments**. 2. Click the arrow between the environment tiles. Together with the application, the published versions of all its graphics (light and dark variants) are transferred to the target environment. The graphics are published immediately and available at the same addresses as in the source environment. The migration is interrupted, before anything is saved on the target environment, when: * the graphic file cannot be downloaded from the source environment, * the target environment does not have application graphics enabled - the message "The target environment does not support application graphics, and the application ... has graphics. Nothing has been imported." is displayed ### Export of applications with graphics Option **Export application** in the environment action menu saves a package `.zip` with the application and its graphics - the same as exporting the application in the **Applications**. The package can be imported on another environment using the option **Import application**. ## Environment configuration The list of available environment "tiles" should be configured in the file whose path should be provided in the package installation parameters (`EXIMEE_CONSOLE_ENVIRONMENTS_CONFIGURATION_PATH`). The order of the provided environments also determines the migration direction. ```json [ { "name": "Environment1", "lanHosts": [ "lan.test.address" ], "migrationTarget": false, "bundleExporter": false }, { "name": "Environment2", "lanHosts": [ "lan.test.eximee", "lan2.test.eximee" ], "migrationTarget": true, "bundleExporter": true } ] ``` ### Meaning of individual attributes: * **`name`** – environment name displayed on the tile. * **`lanHosts`** – an array of LAN instances in a given environment (it is important that these are only hosts – without e.g. protocol `http://` or port). * **`migrationTarget`** – a flag indicating whether requests can be migrated to the given environment. * **`bundleExporter`** – a flag indicating whether a request package with dependencies can be exported from the given environment. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.eximee.com/documentation/documentation-en/eksploatacja-aplikacji/designer/srodowiska.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.