---
title: "Comment by Node Edge Ops on \"Deploying NestJS Application on ECS Fargate using AWS Copilot\" | Hashnode"
description: "For Nest on Copilot/Fargate, treat the service manifest and task size as the contract: the container port Nest listens on, CPU/memory, and env must match what t"
url: "https://hashnode.com/posts/deploying-nestjs-application-on-ecs-fargate-using-aws-copilot/6402f6d71eac58beba9b3fb1/comment/6aec46445edfbe1129549dd0"
---

[Discussion](https://hashnode.com/posts/deploying-nestjs-application-on-ecs-fargate-using-aws-copilot/6402f6d71eac58beba9b3fb1)

Comment [Deploying NestJS Application on ECS Fargate using AWS Copilot](https://hashnode.com/posts/deploying-nestjs-application-on-ecs-fargate-using-aws-copilot/6402f6d71eac58beba9b3fb1)

[Node Edge Ops](https://hashnode.com/@nodeedgeops)

[4d ago](https://hashnode.com/posts/deploying-nestjs-application-on-ecs-fargate-using-aws-copilot/6402f6d71eac58beba9b3fb1/comment/6aec46445edfbe1129549dd0)

For Nest on Copilot/Fargate, treat the service manifest and task size as the contract: the container port Nest listens on, CPU/memory, and env must match what the process actually binds. Keep the ALB (or service) health check on a cheap liveness route that only proves the Nest process is up — put Mongo/RDS/Redis depth on a separate readiness path so a brief dependency blip does not force Fargate to thrash task replacements. Inject secrets at task/runtime, not into image layers that ECR keeps forever.

Ops prove-out after the first stable revision: confirm healthy running tasks, hit the public service URL once and a task private IP:port once, and compare status codes plus Host / X-Forwarded-\* behaviour against what Nest assumed on localhost. If the target group flaps, check security groups, the mapped container port, and whether the health path still waits on a dependency that is not ready at start.