Configuring Lift

Following are .lift.toml configuration guides which encapsulate common workflows. For a more detailed reference of all Lift configuration options, such as only running the tools applicable to your language, see the Build and .toml Details page.



Specifying Build System

Lift can guess which build system should be used in each directory by looking for common build files such as pom.xml,  build.gradle and  gradlew. Sometimes the detected build is not preferred, perhaps because there are several such files present. An explicitly specified build can be used to disable the detection and assume one system. Consider the below example .lift.toml file, that specifies use of Maven and jdk version 11:

build = "mvn"
jdkVersion = "11"

Build targets, flags, and environmental variables can be added to the build line too:

build = "gradle -DskipTests=true build"

NOTE: The build line is not executed verbatim and can not be a shell command. For each build system Lift has plugins to better understand the project files and dependencies. Normal behavior is if it builds then Lift will analyze the code but the difference surfaces rare cases. If the project’s build system is layered, such as a gradle build that just calls out to Maven, then the build will not be understood. If your project’s build falls into such a category then consider simplifying the build system and using a supported build system in a canonical manner.

Specific Tools

For Java, Lift uses multiple tools to analyze the code. Documentation for each of these tools can be found here:

C and C++

Lift supports C and C++ along with the common build systems of cmake, make, compilation databases, and GNU autotools including detecting then running  and  configure.

C and C++ analysis results are provided by Infer. Infer’s bug reference documentation can be found on their website.

As with Java, the build line can specify environmental variables and argument but it is not itself a place to write arbitrary shell script. If it is necessary to execute a script prior to build then read the dependencies section.

If your project’s build system is complex then consider writing a setup script to generate a compilation database. For example define a .lift/ file of:

#!/usr/bin/env bash
# execute any build dependency steps here
sudo apt update && sudo apt install -y $DEPS
# Generate a compilation database next
CC=gcc compiledb -n make all

Then, in the .lift/config.tomlspecify the build as compdb so Lift will ignore other build systems such as Make or CMake:

build = "compdb" setup = ".lift/"

The end results is you have full control over the compilation steps in a manner that is easy to inspect and debug.


ESLint is the tool that Lift uses to analyze Javascript projects. Lift respects ESLint configuration files and more information about the config files can be found on their website.

Lift includes five additional commonly used configurations and plugins:

Each must be configured individually in order to be used. For example, in order to use the Airbnb configuration with hooks support, simply add "extends": ["airbnb", "airbnb/hooks"] to your .eslintrc. Other plugins and configurations can be installed if desired by using a setup script.


Lift supports Python projects with Bandit and Pyre. By default, Pyre support operates by first finding requirements.txt or files, installing dependencies, and analyzing the project. Bandit will run on any repository containing files with the .py extension.


Ruby is supported by Rubocop and, in the case of ruby on rails, Brakeman. Both these tools run when the repository contains files with the .rb extension.


HLint is a Haskell analysis tool that is integrated with Lift. HLint can be configured by a .hlint.yaml at the working directory of the project. For more information on configuration, view HLint’s documentation.

Environment Variables

Environment variables are defined in the build field of  .lift.toml. For example, we can specify which C compiler to use when executing make:

build = "CC=gcc GXX=g++ CXX=g++ make"

Proxy settings with Bash environment variables can also be defined here.

build = "https_proxy=https://server:port make"

Local Settings

Some tools such as Maven use a settings.xml to specify custom maven repository servers. If the configuration file is not in the repository then the setup section of the Lift config can create that file.

setup = ".lift/"

And the repository would include a .lift/ file of:

$ cat .lift/
#!/usr/bin/env bash
mkdir ~/.m2
cat <<EOF > ~/.m2/settings.xml
<settings xmlns=""

N.B. Lift does not currently have a secrets vault and can not inject secret information, such as Artifactory or Nexus credentials, into the analysis process.


Many projects require external dependencies to be able to be built. We will look at some common ways to orchestrate Lift to download and build these dependencies.

The Lift analysis image is based on Ubuntu 20.04. A complete list of included utilities is available here.

The following  .lift.toml  will be used for these examples and  .lift/  is defined in each example.

setup = ".lift/"

Downloading Through GitHub

Adding another repository that is a dependency from GitHib.

$ cat .lift/
#!/usr/bin/env bash
git clone<someuser>/<someproject>.git
cd someproject/ && make

Using Apt Package Manager

The server used to analyze is managed with the apt package manager providing access to a rich environment of packages.  Be sure to use sudo when invoking commands requiring root permissions.

$ cat .lift/
#!/usr/bin/env bash
sudo apt update
sudo apt install -y libcrypto-dev

Something Else

Is there any additional functionality you are missing? Check out the Lift  “Bring Your Own Tool” API  to learn how to extend Lift functionality with custom tools.

Still experiencing a build error or any other problem? We have a Troubleshooting page or feel free to contact us for personal assistance.

More Details

In addition to our Build and .toml Details page, you can also see more on configuring individual analysts in the subpages here: