Note
The main branch currently contains the atomic deployments alpha preview.
For the lastest stable release, check out the v0.x branch.

Please see our blog post "The road to Atomic Deployments"
or watch the latest release review for more information:

Terraform Next.js module for AWS

A zero-config Terraform module for self-hosting Next.js sites serverless on AWS Lambda.

Features

Some features are still under development, here is a list of features that are currently supported and what we plan to bring with the next releases:

• ✅  Supports any version of Next.js
• ✅  Terraform v0.15+
• ✅  Unlimited parallel deployments of Next.js apps (atomic deployments)
• ✅  Static, SSG, Lambda and API pages (with dynamic routes)
• ✅  Automatic expiration of old static assets
• ✅  Rewrites & Redirects
• ✅  Image Component & Image Optimization support
• 🚧  Incremental Static Regeneration
• ⛔️  Middleware (Not supported by Lambda@Edge / CloudFront functions)

Architecture

The Next.js Terraform module is designed as a full stack AWS app. It relies on multiple AWS services and connects them to work as a single application:

Usage

Prerequisites

You should have the following tools installed:

• Terraform
• Node.js
• Bash & curl (Should be available by default on many Linux based images or macOS)

Note: Additionally we assume here that you already have a public Route53 Hosted Zone associated with your AWS account.

This is a requirement in the preview phase of atomic deployments, where each deployment gets a unique subdomain assigned. It will change once atomic deployments become generally available.

Setup the Next.js Terraform module

The Terraform module contains the system that is later used for creating new deployments and managing the aliases (domains) for your Next.js app(s). Creating the Terraform stack is only required on initial setup and creates the global resources (CloudFront distributions, DynamoDB tables, S3 storage) that is used for handling incoming requests to your website.

Create a new main.tf file in an empty folder (or add it to your existing Terraform stack) and add the following content:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

# Main region where the resources should be created in
# Should be close to the location of your viewers
provider "aws" {
  region = "us-west-2"
}

# Provider used for creating the Lambda@Edge function which must be deployed
# to us-east-1 region (Should not be changed)
provider "aws" {
  alias  = "global_region"
  region = "us-east-1"
}

###########
# Variables
###########

variable "custom_domain" {
  description = "Your custom domain"
  type        = string
  default     = "example.com"
}

# Assuming that the ZONE of your domain is already available in your AWS account (Route 53)
# https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/AboutHZWorkingWith.html
variable "custom_domain_zone_name" {
  description = "The Route53 zone name of the custom domain"
  type        = string
  default     = "example.com."
}

########
# Locals
########

locals {
  # A wildcard domain(ex: *.example.com) has to be added when using atomic deployments:
  aliases = [var.custom_domain, "*.${var.custom_domain}"]
}

#######################
# Route53 Domain record
#######################

# Get the hosted zone for the custom domain
data "aws_route53_zone" "custom_domain_zone" {
  name = var.custom_domain_zone_name
}

# Create a new record in Route 53 for the domain
resource "aws_route53_record" "cloudfront_alias_domain" {
  for_each = toset(local.aliases)

  zone_id = data.aws_route53_zone.custom_domain_zone.zone_id
  name    = each.key
  type    = "A"

  alias {
    name                   = module.tf_next.cloudfront_domain_name
    zone_id                = module.tf_next.cloudfront_hosted_zone_id
    evaluate_target_health = false
  }
}

##########
# SSL Cert
##########

# Creates a free SSL certificate for CloudFront distribution
# For more options (e.g. multiple domains) see:
# https://registry.terraform.io/modules/terraform-aws-modules/acm/aws/
module "cloudfront_cert" {
  source  = "terraform-aws-modules/acm/aws"
  version = "~> 3.0"

  domain_name               = var.custom_domain
  zone_id                   = data.aws_route53_zone.custom_domain_zone.zone_id
  subject_alternative_names = slice(local.aliases, 1, length(local.aliases))

  wait_for_validation = true

  tags = {
    Name = "CloudFront ${var.custom_domain}"
  }

  # CloudFront works only with certs stored in us-east-1
  providers = {
    aws = aws.global_region
  }
}

##########################
# Terraform Next.js Module
##########################

module "tf_next" {
  source  = "milliHQ/next-js/aws"
  version = "1.0.0-canary.4"

  cloudfront_aliases             = local.aliases
  cloudfront_acm_certificate_arn = module.cloudfront_cert.acm_certificate_arn

  deployment_name = "atomic-deployments"

  enable_multiple_deployments      = true
  multiple_deployments_base_domain = "*.${var.custom_domain}"

  providers = {
    aws.global_region = aws.global_region
  }
}

#########
# Outputs
#########

output "api_endpoint" {
  value = module.tf_next.api_endpoint
}

output "api_endpoint_access_policy_arn" {
  value = module.tf_next.api_endpoint_access_policy_arn
}

To create the resources in your AWS account, run the following commands:

terraform init    # Only needed on the first time running Terraform

terraform plan    # (Optional) See what resources Terraform will create
terraform apply   # Create the resources in your AWS account

> Apply complete!
>
> Outputs:
>
> api_endpoint = "https://<api-id>.execute-api.us-west-2.amazonaws.com"
> api_endpoint_access_policy_arn = "arn:aws:iam::123456789012:policy/access-api"

The api_endpoint is later used by the CLI tool to create new deployments.

With the api_endpoint_access_policy_arn AWS policy you can create new users (and assign that policy) that only can use the CLI tool tf-next but cannot access other resources inside of your AWS account.

After the successful deployment your Next.js app is publicly available at the CloudFront subdomain from the cloudfront_domain_name output.

Deploy a Next.js App

For building and deploying Next.js apps to the system we created a CLI tool called tf-next.

It is a npm package that can be installed with:

npm i -g tf-next@canary

Next, we need to build the Next.js so that it can run in a serverless environment (with AWS Lambda). This is archived by running tf-next build in the same directory where your Next.js app is located (Right where your package.json or next.config.js files are located):

tf-next build

> All serverless functions created in: 20.791ms
> 1752924 total bytes
> Build successful!

Now deploy the Next.js app by running tf-next deploy from the same directory. The deploy command communicates through a secured (and authenticated with your AWS credentials) API with the Terraform module.

To tell the command where to deploy the app, an additional --endpoint flag must be provided, which should use the value from the api_endpoint output from the terraform apply step:

tf-next deploy --endpoint https://<api-id>.execute-api.us-west-2.amazonaws.com

> Available at: https://3edade7a2bf7bb0343699af6b851bbfa.example.com/

The preview deployment can now be accessed by the displayed url.
To make the deployment available from a more readable url, you can use the tf-next alias subcommand:

tf-next alias set my-app.example.com 3edade7a2bf7bb0343699af6b851bbfa.example.com

> Available at: https://my-app.example.com/

For a full list of available commands that can be used with tf-next, check the command reference.

Examples

• Atomic Deployments
  Each deployment gets a unique url from where it can be previewed.
• Complete
  Complete example with SSR, API and static pages.
• Static
  Example that uses static pages only (No SSR).
• Next Image
  Images are optimized on the fly by AWS Lambda.
• Existing CloudFront
  Use the module together with an existing CloudFront distribution that can be fully customized.
• Custom Domain
  Use the module with your own domain from Route 53.

Requirements

Providers

Inputs

[
  "Authorization"
]

Outputs

Known issues

Under the hood this module uses a lot of Vercel's build pipeline. So issues that exist on Vercel are likely to occur on this project too.

• Stack deletion (terraform destroy) fails on first run (terraform-provider-aws#1721)

  This is intentional because we cannot delete a Lambda@Edge function (Used by proxy module) in a synchronous way. It can take up to an hour for AWS to unbind a Lambda@Edge function from it's CloudFront distribution even when the distribution is already destroyed.

  Workaround:

  After running the initial terraform destroy command (that failed) wait ~1 hour and run the command again. This time it should run successfully and delete the rest of the stack.

• Initial apply fails with error message Error: error creating Lambda Event Source Mapping (#138)

  There is some race condition when the permissions are created for the static deployment Lambda. This should only happen on the first deployment.

  Workaround:

  You should be able to runterraform apply again and the stack creation would proceed without this error.

Contributing

Contributions are welcome!
If you want to improve this module, please take a look at our contributing guidelines to get started.

About

This project is maintained by milliVolt infrastructure.
We build custom infrastructure solutions for any cloud provider.

License

Apache-2.0 - see LICENSE for details.

Note: All sample projects in examples/* are licensed as MIT to comply with the official Next.js examples.