Configuration

Connection settings, environment variables and the interface language.

Configuration

Connection credentials are taken from environment variables or from a .env file in the current directory (environment variables take priority):

Client-Id/Client-Secret are issued in the 1cmycloud control panel (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 or the directory where elemctl is installed. The elemctl repository excludes .env from Git; if you create one in another repository, add .env to its .gitignore. The file contains a secret and must stay out of commits and 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 multiple stands without changing process variables:

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. This keeps certificate-chain, validity, signature, and hostname verification enabled; it only relaxes OpenSSL’s strict RFC 5280 profile. Prefer fixing or reissuing the CA certificate when possible.

Use ELEMENT_CA_FILE=/path/to/internal-ca.pem when the private CA is not in the system trust store. ELEMENT_TLS_VERIFY=false disables both certificate and hostname verification and is intended only as a last resort in an isolated test network. With verification off every command prints a warning to stderr - stdout keeps the answer, so a piped JSON output is not spoiled by it. 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 can help when the proxy cannot reach an internal address or replaces its certificate, but it does not disable server-certificate verification. If the direct connection reaches the server and ends with CERTIFICATE_VERIFY_FAILED, configure the trusted CA or ELEMENT_TLS_* options.

Behaviour of the tool

These are set through the environment only – a connection .env is not their place:

The CI environment

The build declares no variables of its own, but it reads the ones CI sets itself – which 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 by --lang ru|en > the ELEMCTL_LANG env var > the system locale (LC_ALL, then LANG) > Russian; --lang is read before the parser is built, so elemctl --lang en --help prints English help.