Changing Fargate Service Port

Changing the Fargate Service Port

For new Fargate services, we use port 3000 as the default port for the container.

You may choose a different port within the standard range when you create the service.

This port configuration is used in multiple services on AWS side, in order to get the complete end to end integration working.

However, due to an AWS limitation, you can not change the port for the service after it has been created.

If you tried to change the service port in subsequent deployments, the deployment will fail with an error message directing you to this section in the documentation.

Restoring your Service Deployment

You have three options in order to restore your service deployments:

  1. The easiest is to restore the port to the current existing port that was used during the service creation (by default 3000 if you did not specify one).
  2. If your service is not handling production traffic then you can:
    • Go to the Flightcontrol dashboard, and delete the service
    • Trigger a new deployment which will create another service from scratch now with the new defined port.
  3. If your app is handling production traffic, follow those steps:
    • Rename your service id to a different id in your flightcontrol.json file
      • Make sure to rename the service id if you used that id in any dependency or in any environment variables
    • Push another deployment, which will create a different service, using the new port
    • Make any arrangement to your domain to route the traffic to the new service.
    • Delete the old service from the Flightcontrol dashboard once it is no longer needed or required.

Existing VPC Mapping

If you have an existing infrastructure in AWS, and you want to deploy your application in an existing VPC you can do so through the vpc object configuration in the flightcontrol.json file.

You can map and deploy any environment to an existing VPC using a configuration similar to the following:

  "environments": [
      "id": "test",
      "name": "test",
      "region": "us-east-1",
      "source": {
        "branch": "main"
      "vpc": {
        "id": "vpc-1234",
        "cidr": ""
      "services": [
          "id": "web",
          "name": "web",
          "type": "fargate",
          "cpu": 0.5,
          "memory": 1024,
          "minInstances": 1,
          "maxInstances": 1,
          "enableCloudfrontSwr": false,
          "envVariables": {
            "REVALIDATE_SECONDS": "20"
          "id": "db",
          "name": "Database",
          "type": "rds",
          "engine": "mysql",
          "engineVersion": "8",
          "instanceSize": "db.t4g.micro",
          "storage": 20,
          "private": false

There are few things to take into consideration:

  1. This only works with new Flightcontrol environment deployments, if you have an existing environment deployed already, we cannot change the VPC, you will need to deploy a brand new environment, route your application traffic, then delete the old environment.
  2. Make sure to use a VPC in the region you defined.
  3. The id maps to the VPC ID not the VPC name.
  4. cidr
    • If you have a single CIDR attached to the VPC, you do not need to define a CIDR, as Flightcontrol will automatically use the default CIDR.
    • If the VPC has multiple CIDRs attached, you can select the CIDR you want to use to deploy the application, using the cidr parameter.