Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/mcamacho97/terraform-mean-stack-aws/llms.txt

Use this file to discover all available pages before exploring further.

Deploying the MEAN stack follows a standard Terraform workflow: initialize the working directory, validate the configuration syntax, preview the execution plan, and finally apply the changes to AWS. Each command is idempotent and safe to re-run — Terraform compares desired state against real infrastructure and only makes the changes necessary to converge. Full provisioning takes approximately three to five minutes from terraform apply to a live, health-checking application.

​
Deployment Steps

1

Initialize the Working Directory

Initialize Terraform by passing your backend.hcl file. This step downloads the three required providers (aws, tls, local) into .terraform/ and configures the S3 remote backend.
terraform init -backend-config=backend.hcl
Expected output:
Initializing the backend...
Successfully configured the backend "s3"!

Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 6.0"...
- Finding hashicorp/tls versions matching "~> 4.0"...
- Finding hashicorp/local versions matching "~> 2.5"...
- Installing hashicorp/aws v6.x.x...
- Installing hashicorp/tls v4.x.x...
- Installing hashicorp/local v2.x.x...

Terraform has been successfully initialized!
If you change the backend configuration or upgrade provider version constraints, re-run terraform init -upgrade to refresh the lock file.
2

Validate the Configuration

Check that all HCL files are syntactically correct and that all module references and variable types are consistent. Validation runs entirely locally — no AWS API calls are made.
terraform validate
Expected output:
Success! The configuration is valid.
If any errors are reported, fix them before proceeding. Common issues include missing required variables in terraform.tfvars or typos in module source paths.
3

Review the Execution Plan

Generate a human-readable preview of every resource Terraform will create, modify, or destroy. No changes are applied at this stage.
terraform plan
The plan output uses symbols to indicate the action for each resource:
SymbolMeaning
+Resource will be created
~Resource will be updated in-place
-Resource will be destroyed
-/+Resource will be replaced (destroyed then re-created)
On a fresh deployment you should see 20 or more resources marked for creation, including the VPC, subnets, gateways, security groups, IAM role, key pair, EC2 instances, and the Application Load Balancer.
Save the plan to a file for auditability or to pass directly to apply:
terraform plan -out=tfplan
terraform apply tfplan
4

Apply the Configuration

Deploy all planned resources to AWS. Terraform will prompt for confirmation before making any changes.
terraform apply
When prompted, type yes and press Enter:
Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes
To skip the interactive prompt (for CI/CD pipelines), use the auto-approve flag:
terraform apply -auto-approve
After approximately three to five minutes, Terraform will print a summary and display all output values:
Apply complete! Resources: 22 added, 0 changed, 0 destroyed.

Outputs:

alb_dns_name           = "terraform-mean-alb-1234567890.us-east-1.elb.amazonaws.com"
mongodb_private_ip     = "10.0.3.x"
nat_gateway_public_ip  = "x.x.x.x"
node_1_private_ip      = "10.0.1.x"
node_1_public_ip       = "x.x.x.x"
node_2_private_ip      = "10.0.2.x"
node_2_public_ip       = "x.x.x.x"
private_key_path       = "keys/terraform-mean.pem"
vpc_id                 = "vpc-xxxxxxxxxxxxxxxxx"

​
Deployment Order

Terraform resolves the resource dependency graph automatically — you do not need to create resources in a specific sequence manually. The provisioning order follows the dependency chain below: 
VPC
 └── Subnets (Public A, Public B, Private)
      └── Internet Gateway + NAT Gateway
           └── Route Tables
                └── Security Groups
                     └── IAM Role + Instance Profile
                          └── SSH Key Pair (TLS)
                               ├── EC2 Node 1  ──┐
                               ├── EC2 Node 2  ──┤── ALB Target Group
                               └── EC2 MongoDB    └── Application Load Balancer
Resources at the same level in the graph are created in parallel where possible, which keeps overall provisioning time low.

​
Verifying the Deployment

Once apply completes, use the following commands to confirm the infrastructure is healthy and the application is serving traffic. List all outputs: 
terraform output
Get just the load balancer hostname: 
terraform output alb_dns_name
Hit the health endpoint: 
curl http://$(terraform output -raw alb_dns_name)/health
A healthy Node.js server returns a JSON response similar to: 
{
  "status": "healthy",
  "hostname": "ip-10-0-1-x",
  "uptime": 42.3,
  "timestamp": "2025-01-15T12:00:00.000Z"
}
EC2 user-data scripts run on first boot and install Node.js, Nginx, and the application dependencies. This process takes two to three minutes after the instances reach a running state. If the ALB health check reports unhealthy targets immediately after apply, wait a few minutes and try again before investigating further.

​
Tearing Down

To destroy all provisioned resources and avoid ongoing AWS charges: 
terraform destroy
Type yes when prompted. Terraform will remove all resources in the reverse order they were created.
Terraform is idempotent. Re-running terraform apply at any time is safe — Terraform reconciles real-world infrastructure with your declared configuration and only modifies resources that have drifted or whose input variables have changed. Nothing is re-created unnecessarily.
Once deployed, review the full list of exported values and how to use them on the outputs page. View Terraform Outputs →

Build docs developers (and LLMs) love

Get started for freeTalk to us