1. Home
  2. Extending Keboola
  3. Common Interface
  4. Environment

Environment Specification

Components use several channels to exchange information with Keboola, primarily structured folders and configuration files. Each component has full access to the outside network (network type bridge), unless changed to none in Developer portal. Additional parts of the environment in which your component is executed are specified below.

Environment Variables

The following environment variables are injected in the container:

  • KBC_DATADIR: This is always /data/ in Keboola; use this environment variable during component development to create development and testing environments.
  • KBC_RUNID: RunId from Storage; it couples all events within an API call (use this for logging)
  • KBC_PROJECTID: Id of the project in Keboola within a Keboola stack.
  • KBC_STACKID: Id of the Keboola stack.
  • KBC_CONFIGID: Id of the configuration or hash of configuration data if the configuration is not named (configData was used in API call).
  • KBC_CONFIGVERSION: Version of the configuration or empty if the configuration is not named (configData was used in API call).
  • KBC_COMPONENTID: Id of the component
  • KBC_CONFIGROWID: Id of the configuration row if available.
  • KBC_BRANCHID: Id of the development branch.
  • KBC_STAGING_FILE_PROVIDER: Either aws or azure depending on which kind of Stack the container is running. The value refers to the file storage used during file import end export operations.
  • KBC_PROJECT_FEATURE_GATES: Comma separated list of feature gates activated for the current project. Feature gates are considered internal and they may disappear without notice. We recommend that you check with our support before relying on any feature gates.
  • KBC_COMPONENT_RUN_MODE: Either run or debug. The value debug is used in case debug mode was used to run the job https://developers.keboola.com/extend/component/running/#debugging. This environment variable can be useful for example to switch the component to a more verbose logging.

The following variables are available only if “Forwards token” and “Forwards token details” are enabled in component configuration (and approved by us):

  • KBC_PROJECTNAME: Name of the project in Keboola.
  • KBC_TOKENID: Id of the token running the container.
  • KBC_TOKENDESC: Description (user name or token name) of the token running the container.
  • KBC_TOKEN: The actual token running the container.
  • KBC_URL: The Storage API URL.
  • KBC_REALUSER: Id of the user provided by a SAML authentication.

The following variables are available when GELF Logger is enabled in the component configuration:

  • KBC_LOGGER_ADDR: IP address of GELF server
  • KBC_LOGGER_PORT: Port of the GELF server

Return Values

The script defined in Dockerfile ENTRYPOINT or CMD should provide an exit status. The following rules apply:

  • exit code = 0 The execution is considered successful.
  • exit code = 1 The execution fails with a User Error; the contents of both STDOUT and STDERR will be sent to Storage API Events.
  • exit code > 1 The execution fails with an Application Error and the contents of both STDOUT and STDERR will be sent to internal logs.

It is possible to modify the above behavior so that regardless of the exit code, all errors are User Errors. This is done by setting no_application_errors in component configuration. See the implementation notes for tips on distinguishing between a User Error and Application Error.