Skip to main content

Raftt Configuration File - raftt.yml

The configuration of Raftt is located in the raftt.yml file that is created the first time you run raftt up for the repository. (It can also be created by running raftt setup before running raftt up). Once the file is created, you need to modify it according to your needs, and we recommend committing it to your repo.

raftt.yml Example

See below a sample raftt.yml file containing all possible attributes.
A more detailed explanation can be found below

dockerComposeFile: ./docker-compose.yml # The path of the docker-compose file used to
# define the environment
workdir: ./ # The working dir for evaluating the docker compose file
devContainer: dev-container/dev-compose.yml # The path of the dev container that XYZ
data: # Database seeding configuration
- service: db
type: postgres
user: postgres
dump: raftt/dump.sql
secrets: # Secret fetched from local machine
inputcommand: python3 ./scripts/
outputenv: DB_PASSWORD

raftt.yml Specification


A top-level element that contains the required information for building the containers. This element contains the following keys:

  • dockerComposeFile - The path of the docker-compose file used to define the spawned environment.
  • workdir - The working directory expected when spawning the environment.
  • env - An optional mapping of environment variables to be included when building the environment. Similar to Docker Compose .env file (which is also supported).


The path to the compose file defining the dev container.


A top level element containing a list of databases and their seeding methods. For more information, see here.
Each list entry contains the following keys:

  • service - The name of the service that contains the database
  • type - The database type. Can be either postgres, mongodb or script
  • user - The user used to connect to the database
  • dump - The dump file that is loaded to the database in the seeding phase.
  • keyProvider - If a script type is used, the keyProvider is an additional script that returns a version of the loaded data. This is a significant optimization that shortens the amount of time it takes to deploy the environment.


A dictionary whose keys are the secret names that can be referenced as part of the environment.
Each dictionary entry contains the following attributes:

  • inputcommand - The command whose output is the secret.


    Since this command runs locally, we recommend using an OS-independent command, so the same raftt.yml file can be shared between team members working with different operating systems.
    A possible way to do it is having this command run a short OS-independent python script whose output is the secret.

  • outputenv - The name of the environment variable for which the value will be the output of inputcommand.

  • outputvolume - Boolean for whether to allow referencing the secret as a volume. If this is true, the secret may be loaded into the environment as a volume.

Secrets loaded into Raftt in this way are never persisted, and are available only within the context of the environment - isolated completely from other users. See Environment Security and Isolation for more information.

For example, the following raftt.yml definition:

inputcommand: echo "abcd"
outputvolume: true
inputcommand: echo "1234"
outputenv: MY_SECRET_ENV

Along with the following snippet in the docker-compose:

- /SECRETS/my-vol-secret:/root/secret_file

Will make:

  • The MY_SECRET_ENV env variable in the my_service container equal 1234.
  • The file /root/secret_file in the my_service container equal abcd.


The size of the volume we allocate per environment. Default size is 5GB. This is limited to 50GB.


A script executed from the context of the dev container before building and deploying the environment. For more details, see the dedicated warmup script documentation.


Before an environment is frozen or otherwise destroyed, this script is given a chance to run on the dev container. This can be used to tear down external cloud resources.


We guarantee only 30 seconds of runtime - after that we continue with tearing down the environment regardless of completion.