Reference → Airnode → v0.14 → Docker Images

SearchHighlight.vue

FLEX_START_TAG

AWS/GCP Deployer Image

Use the deployer image to deploy or remove an Airnode with a cloud provider such as AWS. The simplest way is to use the pre-built packages. If you would rather build the images yourself see the README in the deployer package.

Quick Deploy Demos

See the Deploying an Airnode on AWS guides to quickly deploy and remove a preconfigured Airnode using the deployer image.

Configuration Files

The files config.json and secrets.env are used to configure the Airnode. The aws.env and gcp.json files are used to define environment information the deployer uses to connect to these cloud providers.

my-airnode
├── aws.env     <- Used for AWS deployment
├── gcp.json    <- Used for GCP deployment
├── config.json
└── secrets.env

Cloud Provider Credentials

In order to deploy Airnode to a serverless cloud provider, you need to provide cloud provider credentials to the Airnode deployer image. The deployer image currently supports deploying to AWS and GCP. For AWS deployment, see the AWS Setup and for GCP deployment, see the GCP Setup.

Deployer Logs

The deployer saves log files by default into the config/logs/ direcotry, but this can be changed by passing a --logs argument to the command.

Deployer Image Commands

Commands are similar for AWS and GCP. Any differences between AWS and GCP are noted where they exist.

• deploy
• list
• info
• rollback
• fetch-files
• remove
• remove-with-receipt

deploy

The deploy command will create the Airnode with a cloud provider or update it if it already exists. Three files are needed to run the deploy command.

• config.json
• secrets.env
• aws.env (AWS only)
• gcp.json (GCP only)

See Deploying an Airnode for deployment commands specific to various operating systems and cloud providers.

Note that a receipt.json file will be created upon completion. It contains some deployment information and is used to remove the Airnode.

Warning about simultaneous deployments

Avoid running multiple deployments simultaneously as doing so might result in a broken deployment. If this occurs, the standard removal approach may not succeed and Manual Removal may be required.

Normally (for Linux/Mac/WSL2) the deployer image deploy command is run by the user root. This may cause permission issues when the receipt.json file is generated. Optionally you can specify the UID (user identifier) and GID (group identifier) that the deployer image should use. Do so by setting the environment variables USER_ID and GROUP_ID, otherwise omit the line containing the variables.

Linux/Mac/WSL2

docker run -it --rm \
  -e USER_ID=$(id -u) -e GROUP_ID=$(id -g) \
  -v "$(pwd):/app/config" \
  api3/airnode-deployer:0.14.1 deploy

Windows

# For Windows, use CMD (not PowerShell).
docker run -it --rm ^
  -v "%cd%:/app/config" ^
  api3/airnode-deployer:0.14.1 deploy

Re-deployments

A unique deployment is defined by the value of nodeSetting.stage. If you deploy again, using the same nodeSetting.stage value, then you are re-deploying or updating the previous deployment.

By default the deployer will attempt to remove the Airnode should either a deployment or re-deployment fail. But if either fails (and --auto-remove is false) then the Airnode will not be removed, however it could be left in an unstable state. You can alter the deploy command to change this behavior using the following.

• --auto-remove true|false: defaults to true
• --no-auto-remove

Auto removal is usually recommended for development deployments. For production deployments, consider changing the value of nodeSetting.stage to create a new deployment and follow-up by removing the previous deployment.

Use the following example to avoid the automatic removal of the Airnode.

docker run -it --rm \
-e USER_ID=$(id -u) -e GROUP_ID=$(id -g) \
-v "$(pwd):/app/config" \
api3/airnode-deployer:0.14.1 deploy --auto-remove false

list

Once one or more Airnodes were deployed using the deploy command above, the list command can be used to list currently deployed Airnodes. Files for cloud provider authentication are needed for the command to run correctly: aws.env (for AWS) and/or gcp.json (for GCP).

Linux/Mac/WSL2

docker run -it --rm \
  -v "$(pwd):/app/config" \
  api3/airnode-deployer:0.14.1 list

Windows

# For Windows, use CMD (not PowerShell).
docker run -it --rm ^
  -v "%cd%:/app/config" ^
  api3/airnode-deployer:0.14.1 list

By default, the deployer will attempt to list Airnode instances from all the supported cloud providers. You can use the --cloud-providers option to select just the cloud providers you want the deployer to list from.

Linux/Mac/WSL2

docker run -it --rm \
  -v "$(pwd):/app/config" \
  api3/airnode-deployer:0.14.1 list --cloud-providers aws

Windows

# For Windows, use CMD (not PowerShell).
docker run -it --rm ^
  -v "%cd%:/app/config" ^
  api3/airnode-deployer:0.14.1 list --cloud-providers aws

info

Retrieve more information about a deployment with the info command. Use the deployment ID from the list command above to request information about a specific deployment. The retrieved information include deployment's Airnode address, stage, Airnode version and the update history. Files for cloud provider authentication are needed for the command to run correctly: aws.env (for AWS) and/or gcp.json (for GCP).

Linux/Mac/WSL2

docker run -it --rm \
  -v "$(pwd):/app/config" \
  api3/airnode-deployer:0.14.1 info aws2c6ef2b3

Windows

# For Windows, use CMD (not PowerShell).
docker run -it --rm ^
  -v "%cd%:/app/config" ^
  api3/airnode-deployer:0.14.1 info aws2c6ef2b3

rollback

To revert to a previous version of a deployment, use the rollback command. Provide the deployment ID from the list command above to specify which deployment will be changed. Also provide the desired version ID from the info command above to revert to. The rollback command will then fetch the configuration files of the specified version and deploy the version using its configuration. Check this with the info command above.

Linux/Mac/WSL2

docker run -it --rm \
  -v "$(pwd):/app/config" \
  api3/airnode-deployer:0.14.1 rollback aws2c6ef2b3 3580a278

Windows

# For Windows, use CMD (not PowerShell).
docker run -it --rm ^
  -v "%cd%:/app/config" ^
  api3/airnode-deployer:0.14.1 rollback aws2c6ef2b3 3580a278

fetch-files

During the Airnode deployment, your config.json and secrets.env are uploaded to the cloud provider of your choosing. You can use the fetch-files command to retrieve them. You need to provide the deployment ID from the list command above to specify the desired deployment. By default, the files from the latest version of this deployment are fetched. Alternatively, you can additionally provide a deployment version ID from the info command above to specify the desired deployment version. By default, the archive with the files is stored in the config directory within the Docker container that is, in the example below, mapped to your current working directory. You can change the output directory by providing an --output-dir option specifying a different directory instead. Don't forget to add a mapping for the new output directory so you'll be able to access the files. Files for cloud provider authentication are needed for the command to run correctly: aws.env (for AWS) or gcp.json (for GCP).

Linux/Mac/WSL2

docker run -it --rm \
  -v "$(pwd):/app/config" \
  api3/airnode-deployer:0.14.1 fetch-files aws2c6ef2b3

Windows

# For Windows, use CMD (not PowerShell).
docker run -it --rm ^
  -v "%cd%:/app/config" ^
  api3/airnode-deployer:0.14.1 fetch-files aws2c6ef2b3

remove

A deployed Airnode can be removed via the remove command. To remove Airnode, use the deployment ID from the list command above. Airnode's update history, that can be seen by the info command, will be removed as well. Files for cloud provider authentication are needed for the command to run correctly: aws.env (for AWS) or gcp.json (for GCP). This is the recommended way to remove a deployment, but an alternative is the remove-with-receipt command.

Linux/Mac/WSL2

docker run -it --rm \
  -v "$(pwd):/app/config" \
  api3/airnode-deployer:0.14.1 remove aws2c6ef2b3

Windows

# For Windows, use CMD (not PowerShell).
docker run -it --rm ^
  -v "%cd%:/app/config" ^
  api3/airnode-deployer:0.14.1 remove aws2c6ef2b3

remove-with-receipt

When an Airnode was deployed using the deploy command, a receipt.json file was created. This file is used to remove the Airnode. The remove-with-receipt command is identical for AWS and GCP. Files for cloud provider authentication are needed for the command to run correctly: aws.env (for AWS) or gcp.json (for GCP).

Linux/Mac/WSL2

docker run -it --rm \
  -v "$(pwd):/app/config" \
  api3/airnode-deployer:0.14.1 remove-with-receipt

Windows

# For Windows, use CMD (not PowerShell).
docker run -it --rm ^
  -v "%cd%:/app/config" ^
  api3/airnode-deployer:0.14.1 remove-with-receipt

Manual Removal

Optionally you can remove an Airnode manually though it is highly recommended that you do so using the deployer image's remove-with-receipt or remove commands. When removing manually, you will need the Airnode's deployment ID, deploymentId (e.g., awsef86dfad) and the Airnode stage name (e.g., production). They can be found in the receipt.json file generated when deploying the Airnode. These are included in the element name of AWS and GCP deployed features. Airnode has a presence in several areas of both AWS and GCP as listed below.

Remember

Only delete elements of a feature with the deploymentId and stage name contained in the element's name. There can be more than one Airnode. Example: (airnode-awsef86dfad-production-run), where awsef86dfad is the deploymentId and production is the stage name.

AWS

Select the region where your Airnode lives.

US East (N. Virginia) us-east-1US East (Ohio) us-east-2US West (N. California) us-west-1US West (Oregon) us-west-2──────────────Africa (Cape Town) af-south-1──────────────Asia Pacific (Hong Kong) ap-east-1Asia Pacific (Mumbai) ap-south-1Asia Pacific (Osaka) ap-northeast-3Asia Pacific (Seoul) ap-northeast-2Asia Pacific (Singapore) ap-southeast-1Asia Pacific (Sydney) ap-southeast-2Asia Pacific (Tokyo) ap-northeast-1──────────────Canada (Central) ca-central-1──────────────Europe (Frankfurt) eu-central-1Europe (Ireland) eu-west-1Europe (London) eu-west-2Europe (Milan) eu-south-1Europe (Paris) eu-west-3Europe (Stockholm) eu-north-1──────────────Middle East (Bahrain) me-south-1──────────────South America (São Paulo) sa-east-1

Click the following links and delete all elements for each feature.

• EventBridge : Delete the rules.
• CloudWatch : Delete the log groups.
• Lambda : Delete the functions.
• DynamoDB : There is one table to delete.
• IAM : Delete the IAM roles.
• API Gateways: Delete the API Gateways.
  1. Click on the desired API Gateway.
  2. Next click on API Keys in the left hand sidebar.
  3. Then click on the Airnode specific API Key.
  4. Select the Delete API Key button to remove the key.
  5. Click here to return to the API Gateway.
  6. Delete the API Gateway.
  7. Repeat for other Airnode gateways if present.
• S3 : Delete the Airnode's S3 bucket directory, not the S3 bucket. Drill down to the directory identified by the stage name of the Airnode which can be found in the config.json and the receipt.json files.

GCP

The steps below assume you have created a project that belongs to an organization.

Enter your GCP project ID:

Click the following links and delete all elements in each feature.

• API Gateways : Delete the API Gateways.
  1. Click on the gateway.
  2. Click on the GATEWAYS tab.
  3. Delete the gateway (a static red delete circle is the only feedback). Please wait as this can take a few minutes.
  4. Click on the CONFIGS tab.
  5. Delete the config file.
  6. Click the back arrow to return to the gateway summary page.
  7. Delete the gateway summary line (a static red delete circle is the only feedback). Please wait as this can take a several minutes.
  8. Repeat for other Airnode gateways if present.
• Cloud Scheduler : Delete the Cloud Scheduler.
• Cloud Functions : Delete all five Cloud Functions.
• Cloud Storage : Delete the Airnode's bucket directory, not the bucket. Drill down to the directory identified by the stage name of the Airnode which can be found in the config.json and the receipt.json files.

---

After removing an Airnode it may be necessary to wait several minutes before deploying / redeploying Airnode again to the same project. GCP takes several minutes to complete its behind the scenes clean-up of deleted cloud resources.

Learn more about AWS or GCP resources that Airnode uses in the Cloud Resources doc.

FLEX_END_TAG