Configuration

Connection settings, environment variables and the interface language.

Configuration

elemctl takes the connection credentials from environment variables or from a .env file in the current directory. An environment variable wins over the file.

Client-Id and Client-Secret are issued in the 1cmycloud control panel, in the Console API integrations section. A file template is .env.example.

Configuring with .env

Copy the template into the directory from which you will run elemctl:

cp .env.example .env

Then fill in at least the platform address, Client-Id and Client-Secret:

ELEMENT_BASE_URL=https://1cmycloud.com
ELEMENT_CLIENT_ID=client-id
ELEMENT_CLIENT_SECRET=client-secret

Without --env-file, the tool looks for a file named exactly .env in the current working directory. That is not necessarily the project directory, and not the directory elemctl is installed into. The elemctl repository excludes .env from Git. If you create one in another repository, add .env to its .gitignore: the file holds a secret and has no business in commits or logs.

When the configuration lives elsewhere, pass it explicitly. An absolute path is more reliable for the MCP server, background jobs and CI:

elemctl --env-file /opt/elemctl/cloud.env apps list

The option is also accepted after the command:

elemctl apps list --env-file /opt/elemctl/cloud.env

A relative path is resolved from the current working directory. Separate files let one installation address several stands, and no process variable has to change:

elemctl --env-file ./env/public-cloud.env apps list
elemctl --env-file ./env/local-cloud.env apps list

Example for a local cloud with a trusted but legacy internal CA that Python 3.13 rejects under strict RFC 5280 checks:

ELEMENT_BASE_URL=https://cloud.internal.example
ELEMENT_CLIENT_ID=client-id
ELEMENT_CLIENT_SECRET=client-secret
ELEMENT_TLS_STRICT=false

For an internal CA that is trusted but rejected by Python 3.13 with Basic Constraints of CA cert not marked critical, set ELEMENT_TLS_STRICT=false. Certificate-chain, validity, signature and hostname verification all stay on. Only OpenSSL’s strict RFC 5280 profile is relaxed. Where you can, fix or reissue the CA certificate instead.

Use ELEMENT_CA_FILE=/path/to/internal-ca.pem when the private CA is not in the system trust store. ELEMENT_TLS_VERIFY=false turns off both certificate and hostname verification. It is a last resort, and only for an isolated test network. With verification off, every command prints a warning to stderr while stdout still carries the answer alone, so piped JSON survives intact. Boolean values accept true/false, yes/no, on/off, or 1/0.

ELEMCTL_NO_PROXY solves a different problem: it routes requests past the environment’s proxy. It helps when the proxy cannot reach an internal address or replaces its certificate. Server-certificate verification stays on either way. If the direct connection reaches the server and ends with CERTIFICATE_VERIFY_FAILED, configure the trusted CA or the ELEMENT_TLS_* options.

Unlike the other tool-behaviour variables below, ELEMCTL_NO_PROXY can also be set in this stand’s own .env file, next to its credentials – an environment variable still wins when one is set. That is what an MCP call needs: a single server process may serve several stands through env_file, one call at a time, and there is no way for a caller to set a process variable for just one of them. The file’s setting only ever applies to requests of that stand; a second stand served by the same process, cloud or local, is unaffected. A server already running notices without a restart, default stand included: the client cache is keyed by env_file (or, without one, the server’s own --env-file if it was given at startup, or else the .env of the current directory) together with the file’s modification time and size, so an edit – adding this very variable, say – reaches the very next call for that stand. A change that leaves the bytes alone is not such an edit: take read access away from the file and the cache keeps the client it already built, because neither the modification time nor the size moved. That is the CLI’s own elemctl mcp; a Config object handed to the server directly by an application that embeds elemctl has no file behind it for the cache to watch and stays pinned for the life of the process instead.

Behaviour of the tool

ELEMCTL_LANG, ELEMCTL_NO_PLUGINS, ELEMCTL_DATA_DIR and ELEMCTL_REGISTRY_LIMIT are set through the environment only – a connection .env is not their place. ELEMCTL_NO_PROXY is the exception, explained above: it reads the same file the connection does.

The local registry of uploads

The platform keeps the commit of a build uploaded into an existing project and nothing else of where the build came from. So every upload elemctl makes – deploy, builds upload, probe – also appends a line to uploads.jsonl in the data directory above: the build id, the project, the version, the branch, the commit, whether the tree had uncommitted changes, the directory of the sources, the stand, the command and the time. builds list --brief and apps get fill the branch and the commit the card left empty from it and name the source of each value.

The registry is local. A build uploaded from another machine, from CI or by an elemctl that had no registry yet is not in it, and there the listings show what the platform knows. A registry that cannot be written is a warning and never a failed upload; the file can be deleted at any time, and only the history of this machine goes with it.

The registry keeps the newest thousand uploads, ELEMCTL_REGISTRY_LIMIT sets another number, and 0 keeps every one. Once the file has grown past the limit by a tenth, the next upload cuts it back to the newest lines: the builds a project still lists and an application still runs are the recent ones, and a file nobody trimmed grew for as long as the machine deployed.

The CI environment

The build declares no variables of its own, but it reads the ones CI sets itself. That is why a pipeline needs neither a version flag nor an edit of the sources:

Language

Error and progress messages, and the --help text, come in Russian and English. The JSON result is language-neutral. The language is picked in this order: --lang ru|en, then the ELEMCTL_LANG env var, then the system locale (LC_ALL, then LANG), then Russian. --lang is read before the parser is built, so elemctl --lang en --help prints English help.