> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blockscout.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Variables

> ENV variables must be configured per chain

## Configuration

There are three groups of variables required to build BlockScout. The first is required to create infrastructure, the second to build BlockScout instances and the third is required both for infra and BS itself.

For your convenience we have divided variable templates into three files accordingly - `infrastructure.yml.example`, `blockscout.yml.example` and `all.yml.example` . Also we have divided those files to place them in the `group_vars` and in `host_vars` folders, so you will not have to repeat some of the variables for each host/group.

To deploy BlockScout, you will setup the following set of files for each instance:

```python theme={null}
/
| - group_vars
|   | - group.yml (combination of [blockscout+infrastructure+all].yml.example)
|   | - all.yml (optional, one for all instances)
| - host_vars
|   | - host.yml (combination of [blockscout+infrastructure+all].yml.example)
| - hosts (one for all instances)
```

The subsections below describe the variables you may want to adjust.

* [Infrastructure Variables](/setup/deployment/ansible-deployment/variables#infrastructure-variables)
* [BlockScout Variables](/setup/deployment/ansible-deployment/variables#blockscout-detail-variables)
* [Common (All) Variables](/setup/deployment/ansible-deployment/variables#common-variables)

## Infrastructure Variables

* `terraform_location` is an address of the Terraform binary on the builder;
* `dynamodb_table` represents the name of table that will be used for Terraform state lock management;
* If `ec2_ssh_key_content` variable is not empty, Terraform will try to create EC2 SSH key with the `ec2_ssh_key_name` name. Otherwise, the existing key with `ec2_ssh_key_name` name will be used;
* `instance_type` defines a size of the Blockscout instance that will be launched during the deployment process;
* `vpc_cidr`, `public_subnet_cidr`, `db_subnet_cidr` represents the network configuration for the deployment. Usually you want to leave it as is. However, if you want to modify it, please, expect that `db_subnet_cidr` represents not a single network, but a group of networks started with defined CIDR block increased by 8 bits.

<Info>
  Example: Number of networks: 2 `db_subnet_cidr`: "10.0.1.0/16" Real networks: 10.0.1.0/24 and 10.0.2.0/24
</Info>

* An internal DNS zone with`dns_zone_name` name will be created to take care of BlockScout internal communications;
* The `root_block_size` is the amount of storage on your EC2 instance. This value can be adjusted by how frequently logs are rotated. Logs are located in `/opt/app/logs` of your EC2 instance;
* Each of the `db_*` variables configures the database for each chain. Each chain will have the separate RDS instance;
* `instance_type` represent the size of the EC2 instance to be deployed in production;
* `use_placement_group` determines whether or not to launch BlockScout in a placement group.

## BlockScout Variables

* `blockscout_repo` - a direct link to the BlockScout repo;
* `branch` - maps branch at `blockscout_repo` to each chain;
* Specify the `merge_commit` variable if you want to merge any of the specified `chains` with the commit in the other branch. Usually used to update production branches with the releases from master branch;
* `skip_fetch` - if this variable is set to `true` , BlockScout repo will not be cloned and the process will start from building the dependencies. Use this variable to prevent playbooks from overriding manual changes in cloned repo;
* `ps_*` variables represents a connection details to the test Postgres database. This **is not installed automatically**, so make sure `ps_*` credentials are valid before starting the deployment;

## Common (All) Variables

* `ansible_host` - is an address where BlockScout will be built. If this variable is set to localhost, also set `ansible_connection` to `local` for better performance.
* `chain` variable set the name of the network (Kovan, Core, xDAI, etc.). Will be used as part of the infrastructure resource names.
* `env_vars` represents the set of environment variables used by BlockScout. [They are available here.](/setup/env-variables)
  * One can define `BUILD_*` set of the variables, where asterisk stands for any environment variables. All variables defined with `BUILD_*` will override default variables while building the dev server.
* `aws_access_key` and `aws_secret_key` is a credentials pair that provides access to AWS for the deployer; You can use the `aws_profile` instead. In that case, AWS CLI profile will be used. Also, if none of the access key and profile provided, the `default` AWS profile will be used. The `aws_region` should be left at `us-east-1` as some of the other regions fail for different reasons;
* `backend` variable defines whether deployer should keep state files remote or locally. Set `backend` variable to `true` if you want to save state file to the remote S3 bucket;
* `upload_config_to_s3` - set to `true` if you want to upload config `all.yml` file to the S3 bucket automatically after the deployment. Will not work if `backend` is set to false;
* `upload_debug_info_to_s3` - set to `true` if you want to upload full log output to the S3 bucket automatically after the deployment. Will not work if `backend` is set to false.

<Warning>
  Locally logs are stored at `log.txt` which is not cleaned automatically. Do not forget to clean manually or use the `clean.yml` playbook
</Warning>

* `bucket` represents a globally unique name of the bucket where your configs and state will be stored. It will be created automatically during the deployment;

<Warning>
  a chain name SHOULD NOT be more than 5 characters. Otherwise, it will throw an error because the aws load balancer name should not be greater than 32 characters.
</Warning>