> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/cli/for-devops-and-administrators/automate/install-on-runners.md). # Install Devolutions CLI on build agents Install Devolutions CLI on CI build agents from an archive, keep each job's configuration separate, and control the background process. Devolutions CLI needs no runtime and no service: extract the archive for your agent's platform, add its folder to the `PATH`, and the agent is ready. This page covers what's different on a build agent: picking the right archive, keeping jobs from sharing configuration, and cleaning up after a job. ## Pick the archive for your agent
PLATFORMARCHITECTURECOMMAND
Windowsx64, Arm64devo.exe
macOSx64, Arm64devo
Linuxx64, Arm64devo
Each platform and architecture has its own build, available as a `.zip` or a `.tar.gz` archive: use the one that matches the agent. The archive can contain other files next to `devo`, such as native libraries, so keep the extracted folder together. ## Install it {% tabs %} {% tab title="Linux and macOS" %} ```bash mkdir -p "$HOME/devo" tar -xzf .tar.gz -C "$HOME/devo" export PATH="$HOME/devo:$PATH" devo --help ``` Use any folder the job can write to. {% endtab %} {% tab title="Windows" %} ```powershell Expand-Archive .zip -DestinationPath "$env:TEMP\devo" -Force $env:PATH = "$env:TEMP\devo;$env:PATH" devo --help ``` Replace `$env:TEMP` with any folder the job can write to. {% endtab %} {% endtabs %} ## Keep each job's configuration separate Devolutions CLI saves your contexts, sign-in sessions, and the state of its background process in a configuration folder in the user's profile. On a build agent that runs jobs one after the other under the same account, every job would share that folder: one job could use a context another job created. Set `DEVO_CLI_CONFIG_HOME` to a folder that belongs to the job, before the first `devo` command: {% tabs %} {% tab title="Bash" %} ```bash export DEVO_CLI_CONFIG_HOME="$(mktemp -d)" ``` {% endtab %} {% tab title="PowerShell" %} ```powershell $env:DEVO_CLI_CONFIG_HOME = Join-Path $env:TEMP "devo-config" ``` {% endtab %} {% endtabs %} Every `devo` command of the job then uses that folder for its contexts and its background process, and other jobs don't see it. ## Control the background process The first `devo` command that needs your workspace starts a background process and leaves it running for the next commands. It's the same `devo` file, running under the job's user account. It doesn't keep your job's output open, so the step that started it can finish normally. By default, the background process stops on its own after 60 minutes without requests. On a build agent, you usually want it gone sooner.
SETTINGWHAT IT DOES
DEVO_DAEMON_IDLE_TIMEOUTHow long the background process waits without requests before it stops, for example 30s, 5m, 1h, or 00:05:00. The default is 60 minutes. 0s turns the idle stop off. If Devolutions CLI can't read the value, the command that would start the background process fails with invalidParameterValue.
--daemon option or DEVO_DAEMON_MODEauto (default): start the background process when needed. require: use one that's already running, never start one. never: don't contact it, so commands that need it fail.
--no-daemon-autostart option or DEVO_DAEMON_AUTOSTARTDon't start the background process automatically. Set the variable to 0, false, or no to turn automatic start off.
With `require`, or with automatic start turned off, start the process yourself at the beginning of the job: ```bash devo daemon ensure ``` {% hint style="info" %} Set environment variables that Devolutions CLI reads later, such as the variable that holds your application secret, **before** the first `devo` command. The background process reads its environment when it starts. See [Sign in from a CI pipeline](/cli/for-devops-and-administrators/automate/ci-sign-in.md). {% endhint %} ## Clean up at the end of the job Run these commands in a step that always runs, even when the job fails: ```bash devo logout devo daemon stop --wait rm -rf "$DEVO_CLI_CONFIG_HOME" ``` * `devo logout` clears the stored authentication of the context. * `devo daemon stop --wait` stops the background process of this configuration folder and waits until it's gone. If none is running, it does nothing. * Delete the configuration folder last: `devo daemon stop` uses it to find the background process. On build agents that are deleted after each job, such as containers or temporary virtual machines, cleanup isn't required, but it costs nothing. ## Good to know * Check that the agent is ready with `devo doctor`. It shows a diagnostics snapshot without starting the background process. See [Collect diagnostics for support](/cli/help/troubleshooting/collect-diagnostics.md). * If a command reports that the background process isn't available, see [The background process won't start](/cli/help/troubleshooting/daemon-wont-start.md). * All environment variables are listed in [Environment variables](/cli/reference/environment-variables.md). ## Next * [Sign in from a CI pipeline](/cli/for-devops-and-administrators/automate/ci-sign-in.md) * [Read results as JSON](/cli/for-devops-and-administrators/automate/json-output.md) * [Install Devolutions CLI](/cli/reference/installation.md) --- # 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.devolutions.net/cli/for-devops-and-administrators/automate/install-on-runners.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.