Guides
Flightcontrol
Configuring with Code
Fargate Worker

Configuring Worker Services with flightcontrol.json

In addition to the Service Configuration attributes that are common to all services, the following attributes are specific to worker services.

Worker Service Attributes

The type for all web server services is fargate-worker, and should be specified like the following:

type: 'fargate-worker'

In addition, there are several other attributes that are specific to worker services:

CPU

cpu: number

  • Example: "cpu": 0.25
  • Supported values: 0.25, 0.5, 1, 2, 4
  • This is the AWS vCPU unit for each service instance. It does not correspond to number of cores. It’s an abstract unit of CPU power defined by Amazon
  • For more details, see AWS’s Fargate pricing page (opens in a new tab)

Memory

memory: int

  • Example: "memory": 1
  • Supported values:
    • With cpu: 0.25 - 0.5, 1, 2
    • With cpu: 0.5 - 1...4 (int)
    • With cpu: 1 - 2...8 (int)
    • With cpu: 2 - 4...16 (int)
    • With cpu: 4 - 8...30 (int)
  • Memory can be in GB or MB for each service instance
  • For more details, see AWS’s Fargate pricing page (opens in a new tab)

Storage

storage: int

  • Example: "storage": 20
  • Support values: 20-200
  • This is the ephemeral storage available to all containers running on your task. For example, this storage will be shared between your main application container and the sidecar containers if you are using any (for example, for Datadog).
  • By default, AWS sets this value to 20GB.
  • For more details, see AWS’s Fargate task storage page (opens in a new tab)

Number of Instances

minInstances: int

  • Example: "minInstances": 1
  • Support values: 1+
  • Optional with default: 1
  • The minimum number of instances you want to be running. A min of 2 means there will be two containers running the same copy of code.

maxInstances: int

  • Example: "maxInstances": 2
  • Support values: 1+
  • Optional with default: 1
  • The maximum number of instances you want to be running. Fargate will autoscale the number of instances based on your traffic up to this maximum. This number effectively sets a limit on AWS cost you may incur.

Autoscaling

autoscaling: object

  • Example:
"autoscaling": {
    "cpuThreshold": 60,
    "memoryThreshold": 60,
    "cooldownTimerSecs": 300,
    "requestsPerTarget": 1000
},
  • Optional
  • Enables autoscaling for your service. For more, see our autoscaling guide.

For each service's autoscaling configuration, you can configure the following attributes:

  • cpuThreshold - The CPU threshold at which to scale up or down. For example, 60 would mean that if the average CPU usage across all instances is greater than 60%, then we will scale up. If it is less than 60%, then we will scale down.
  • memoryThreshold - The memory threshold at which to scale up or down. For example, 60 would mean that if the average memory usage across all instances is greater than 60%, then we will scale up. If it is less than 60%, then we will scale down.
  • cooldownTimerSecs - The cooldown timer in seconds. This is the amount of time to wait after scaling up or down before scaling again. For example, 300 would mean that we will wait 5 minutes after scaling up or down before scaling again.
  • requestsPerTarget - The number of requests per target. This is the number of requests per minute that each instance can handle. For example, 1000 would mean that each instance can handle 1000 requests per minute.

Container Insights

containerInsights: boolean

From Service

fromService: string

  • If using buildType: fromService, this is the ID of the service that you wish to use the image for.

Container Image

containerImage: object

  • containerImage defines the parameters needed when using buildType: fromRepository

    registryId: string

    • Example: "registryId": "ecr-9l03731"
    • Registry ID, you can find this on the Registries page in our dashboard

    repository: string

    • Example: "repository": "node:18-slim"
    • This is the URI of the image repository you wish to access

    tag?: string

    • Example: "tag": "latest"
    • Optional
    • This is the tag of the image from the repository that you would like to use

Runtime-only Environment variables

includeEnvVariablesInBuild: boolean

  • Example: "includeEnvVariablesInBuild": false
  • Optional with default: true
  • Enables runtime-only environment variables - see the Configuring Environment Variables page for more details.

Integrations

integrations: object

Under the integrations key, you can configure integrations with third-party services. At this time, the only supported integration is with Sentry (opens in a new tab).

Upload Sentry Source Maps

uploadSentrySourceMap: boolean

  • Example: "integrations": { "uploadSentrySourceMap": true }
  • Optional with default: false
  • Enables uploading source maps to Sentry. This is useful for debugging errors in production. For more, see our Sentry guide.

Sidecars

sidecars: array

  • Example:
 "sidecars": [
        {
          "name": "open-telemetry-collector",
          "image": "otel/opentelemetry-collector-contrib:0.83.0",
          "cpuAllotment": 0.1,
          "memoryAllotment": 0.25,
          "enableNetworking": true,
          "ports": [4318]
        }
      ]
  • Optional with default: []
  • Enables sidecars for your service. For more, see our sidecars guide.

For each individual sidecar, you can configure the following attributes:

  • name - The name of the sidecar container.
  • image - The URL to the image for the sidecar container.
  • cpuAllotment - The absolute amount of CPU to allocate to the sidecar container. In vCPU units. For example, 0.25 would be 1/4 of a vCPU.
  • memoryAllotment - The absolute amount of memory to allocate to the sidecar container. In GB units. For example, 0.5 would be 1/2 of a GB.
  • enableNetworking - Whether to enable networking for the sidecar container. Defaults to true.
  • ports - An array of ports to expose from the sidecar container. Defaults to [].
  • envVariables - An object of environment variables to set in the sidecar container. Defaults to {}. You can use the same rules for environment variables as you would for your main container.
  • dockerLabels - An object of Docker labels to set in the sidecar container. Defaults to {}.

Extra options for Nixpacks & Legacy Node.js

basePath?: string (only supported when buildType: nixpacks)

  • Allows you to specify in which folder the commands should run
  • Example: "basePath": "./apps"
  • Optional, defaults to "./"

installCommand: string

  • Example: "installCommand": "./install.sh"
  • Optional, intelligent default based on your language and framework detected at the basePath
  • What we use to install dependencies for your build

buildCommand: string

  • Example: "buildCommand": "blitz build"
  • Optional, intelligent default based on your language and framework detected at the basePath
  • What we use to build your app

preDeployCommand: string

  • Example: "preDeployCommand": "pnpm prisma migrate deploy"
  • Optional, if not configured the application is deployed immediately after successful build
  • A command that runs after successful build and before starting the deploy (more information).

postDeployCommand: string

  • Example: "postDeployCommand": "pnpm run bust-cache"
  • Optional, if not configured the applilcation was deployed as normal
  • A command that runs after successful deploy (more information).

startCommand: string

  • Example: "startCommand": "blitz start"
  • Optional, intelligent default based on your language and framework detected at the basePath
  • What we use to start your app

postBuild: string

  • Example: "postBuild": "./postbuild.sh"
  • Optional, Empty by Default
  • Used as a build hook to run any operation after your build is complete

Extra options for custom Dockerfile only

dockerfilePath: string

  • Example: "dockerfilePath": "packages/web/Dockerfile"
  • Relative path to the Dockerfile from your repo root
  • It’s recommended to use ENTRYPOINT instead of CMD for your start command
  • You can authenticate with Docker Hub by adding your Docker Hub credentials as DOCKER_USERNAME and DOCKER_PASSWORD environment variables. If these env variables are present, we’ll run docker login with them. This will prevent Docker Hub rate limit issues.

dockerContext: string

  • Example: "dockerContext": "packages/web"
  • Optional with default: "." (repo root)
  • Relative path to the docker context from the repo root
  • It’s recommended to use ENTRYPOINT instead of CMD for your start command
Fargate Web ServerStatic Sites