Skip to main content

AstroSite

The AstroSite construct is a higher level CDK construct that makes it easy to create an Astro app. It provides a simple way to build and deploy the app to AWS:

  • The client assets are deployed to an S3 Bucket, and served out from a CloudFront CDN for fast content delivery.
  • The app server is deployed to Lambda. You can deploy to Lambda@Edge instead if the edge flag is enabled. Read more about Single region vs Edge.
  • It enables you to configure custom domains for the website URL.
  • It also enable you to automatically set the environment variables for your Astro app directly from the outputs in your SST app.
  • It provides a simple interface to grant permissions for your app to access AWS resources.

Quick Start​

  1. If you are creating a new Astro app, run create-astro from the root of your SST app.
npx create-astro@latest

And select Astro App Server as the deployment target.

Select Astro App template

After the Astro app is created, your SST app structure should look like:

my-sst-app
├─ sst.json
├─ services
├─ stacks
└─ my-astro-app     <-- new Astro app
   ├─ src
   ├─ public
   └─ astro.config.mjs

Continue to step 3.

  1. Alternatively, if you have an existing Astro app, move the app to the root of your SST app. Your SST app structure should look like:
my-sst-app
├─ sst.json
├─ services
├─ stacks
└─ my-astro-app     <-- your Astro app
   ├─ src
   ├─ public
   └─ astro.config.mjs
  1. Let's set up the astro-sst adapter for your Astro app. The adapter will transform the SSR functions to a format that can be deployed to AWS. To do that, run astro add from your Astro app.
npx astro add astro-sst

This will install the adapter and make the appropriate changes to your astro.config.mjs file in one step.

info

If you are deploying the AstroSite in the edge mode, import the adapter from the astro-sst/edge package in your astro.config.mjs file.

- import aws from "astro-sst/lambda";
+ import aws from "astro-sst/edge";
  1. Also add the sst env command to your Astro app's package.json. sst env enables you to automatically set the environment variables for your Astro app directly from the outputs in your SST app.
  "scripts": {
-   "dev": "astro dev",
+   "dev": "sst env astro dev",
    "start": "astro dev",
    "build": "astro build",
    "preview": "astro preview",
    "astro": "astro"
  },
  1. Add the AstroSite construct to an existing stack in your SST app. You can also create a new stack for the app.
import { AstroSite, StackContext } from "sst/constructs";

export default function MyStack({ stack }: StackContext) {

  // ... existing constructs

  // Create the Astro site
  const site = new AstroSite(stack, "Site", {
    path: "my-astro-app/",
  });

  // Add the site's URL to stack output
  stack.addOutputs({
    URL: site.url || "localhost",
  });
}

When you are building your SST app, AstroSite will invoke npm build inside the Astro app directory. Make sure path is pointing to the your Astro app.

We also added the site's URL to the stack output. After the deploy succeeds, the URL will be printed out in the terminal. Note that during development, the site is not deployed. You should run the site locally. In this case, site.url is undefined. Read more about how environment variables work during development.

tip

The site is not deployed when running sst dev. Run the site locally while developing.

Single region vs edge​

There are two ways you can deploy the Astro app to your AWS account.

By default, the Astro app server is deployed to a single region defined in your sst.json or passed in via the --region flag. Alternatively, you can choose to deploy to the edge. When deployed to the edge, loaders/actions are running on edge location that is physically closer to the end user. In this case, the app server is deployed to AWS Lambda@Edge.

You can enable edge like this:

const site = new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  edge: true,
});

Note that, in the case you have a centralized database, Edge locations are often far away from your database. If you are quering your database in your loaders/actions, you might experience much longer latency when deployed to the edge.

info

We recommend you to deploy to a single region when unsure.

Custom domains​

You can configure the website with a custom domain hosted either on Route 53 or externally.

const site = new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  customDomain: "my-app.com",
});

Note that visitors to the http:// URL will be redirected to the https:// URL.

You can also configure an alias domain to point to the main domain. For example, to setup www.my-app.com redirecting to my-app.com:

const site = new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  customDomain: {
    domainName: "my-app.com",
    domainAlias: "www.my-app.com",
  },
});

Environment variables​

The AstroSite construct allows you to set the environment variables in your Astro app based on outputs from other constructs in your SST app. So you don't have to hard code the config from your backend. Let's look at how.

To expose environment variables to your Astro application you should utilise the AstroSite construct environment configuration property rather than an .env file within your Astro application root.

Imagine you have an API created using the Api construct, and you want to fetch data from the API. You'd pass the API's endpoint to your Astro app.

const api = new Api(stack, "Api", {
  // ...
});

new AstroSite(stack, "Site", {
  path: "path/to/site",
  environment: {
    API_URL: api.url,
  },
});

Then you can access the API's URL in your server code:

const data = await db(import.meta.env.API_URL);

Note that, in Astro, only environment variables prefixed with PUBLIC_ are available in your browser code. Read more about using environment variables.

For example, if you want to access the API's URL in your frontend js code, you'd name it PUBLIC_API_URL:

new AstroSite(stack, "Site", {
  path: "path/to/site",
  environment: {
    PUBLIC_API_URL: api.url,
  },
});

Let's take look at what is happening behind the scene.

While deploying​

On sst deploy, the Astro app server is deployed to a Lambda function, and the AstroSite's environment values are set as Lambda function environment variables. In this case, process.env.API_URL will be available at runtime.

If you enabled the edge option, the Astro app server will instead get deployed to a Lambda@Edge function. We have an issue here, AWS Lambda@Edge does not support runtime environment variables. To get around this limitation, we insert a snippet to the top of your app server:

const environment = "{{ _SST_FUNCTION_ENVIRONMENT_ }}";
process.env = { ...process.env, ...environment };

And at deploy time, after the referenced resources have been created, the API in this case, a CloudFormation custom resource will update the app server's code and replace the placeholder {{ _SST_FUNCTION_ENVIRONMENT_ }} with the actual value:

const environment = {
  API_URL: "https://ioe7hbv67f.execute-api.us-east-1.amazonaws.com",
};
process.env = { ...process.env, ...environment };

This will make process.env.API_URL available at runtime.

While developing​

To use these values while developing, run sst dev to start the Live Lambda Development environment.

npx sst dev

Then in your Astro app to reference these variables, add the sst env command.

package.json
"scripts": {
  "dev": "sst env astro dev",
  "start": "astro dev",
  "build": "astro build",
  "preview": "astro preview",
  "astro": "astro"
},

Now you can start your Astro app as usual and it'll have the environment variables from your SST app.

npm run dev

There are a couple of things happening behind the scenes here:

  1. The sst dev command generates a file with the values specified by the AstroSite construct's environment prop.
  2. The sst env CLI will traverse up the directories to look for the root of your SST app.
  3. It'll then find the file that's generated in step 1.
  4. It'll load these as environment variables before running the start command.
note

sst env only works if the Astro app is located inside the SST app or inside one of its subdirectories. For example:

/
  sst.json
  my-astro-app/

Using AWS services​

Since the AstroSite construct deploys your Astro app to your AWS account, it's very convenient to access other resources in your AWS account. AstroSite provides a simple way to grant permissions to access specific AWS resources.

Imagine you have a DynamoDB table created using the Table construct, and you want to fetch data from the Table.

const table = new Table(stack, "Table", {
  // ...
});

const site = new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  environment: {
    TABLE_NAME: table.tableName,
  },
});

site.attachPermissions([table]);

Note that we are also passing the table name into the environment, so the Astro server code can fetch the value process.env.TABLE_NAME when calling the DynamoDB API to query the table.

Examples​

Configuring custom domains​

You can configure the website with a custom domain hosted either on Route 53 or externally.

Using the basic config (Route 53 domains)​

new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  customDomain: "my-app.com",
});

Redirect www to non-www (Route 53 domains)​

new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  customDomain: {
    domainName: "my-app.com",
    domainAlias: "www.my-app.com",
  },
});

Configuring domains across stages (Route 53 domains)​

new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  customDomain: {
    domainName:
      scope.stage === "prod" ? "my-app.com" : `${scope.stage}.my-app.com`,
    domainAlias: scope.stage === "prod" ? "www.my-app.com" : undefined,
  },
});

Configuring alternate domain names (Route 53 domains)​

You can specify additional domain names for the site url. Note that the certificate for these names will not be automatically generated, so the certificate option must be specified. Also note that you need to manually create the Route 53 records for the alternate domain names.

import * as acm from "aws-cdk-lib/aws-certificatemanager";
import * as route53 from "aws-cdk-lib/aws-route53";
import * as route53Targets from "aws-cdk-lib/aws-route53-targets";

// Look up hosted zone
const hostedZone = route53.HostedZone.fromLookup(stack, "HostedZone", {
  domainName: "domain.com",
});

// Create a certificate with alternate domain names
const certificate = new acm.DnsValidatedCertificate(stack, "Certificate", {
  domainName: "foo.domain.com",
  hostedZone,
  region: "us-east-1",
  subjectAlternativeNames: ["bar.domain.com"],
});

// Create site
const site = new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  customDomain: {
    domainName: "foo.domain.com",
    alternateNames: ["bar.domain.com"],
    cdk: {
      hostedZone,
      certificate,
    },
  },
});

// Create A and AAAA records for the alternate domain names
const recordProps = {
  recordName: "bar.domain.com",
  zone: hostedZone,
  target: route53.RecordTarget.fromAlias(
    new route53Targets.CloudFrontTarget(site.cdk.distribution)
  ),
};
new route53.ARecord(stack, "AlternateARecord", recordProps);
new route53.AaaaRecord(stack, "AlternateAAAARecord", recordProps);

Importing an existing certificate (Route 53 domains)​

import { Certificate } from "aws-cdk-lib/aws-certificatemanager";

new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  customDomain: {
    domainName: "my-app.com",
    cdk: {
      certificate: Certificate.fromCertificateArn(stack, "MyCert", certArn),
    },
  },
});

Note that, the certificate needs be created in the us-east-1(N. Virginia) region as required by AWS CloudFront.

Specifying a hosted zone (Route 53 domains)​

If you have multiple hosted zones for a given domain, you can choose the one you want to use to configure the domain.

import { HostedZone } from "aws-cdk-lib/aws-route53";

new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  customDomain: {
    domainName: "my-app.com",
    cdk: {
      hostedZone: HostedZone.fromHostedZoneAttributes(stack, "MyZone", {
        hostedZoneId,
        zoneName,
      }),
    },
  },
});

Configuring externally hosted domain​

import { Certificate } from "aws-cdk-lib/aws-certificatemanager";

new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  cutomDomain: {
    isExternalDomain: true,
    domainName: "my-app.com",
    cdk: {
      certificate: Certificate.fromCertificateArn(stack, "MyCert", certArn),
    },
  },
});

Note that the certificate needs be created in the us-east-1(N. Virginia) region as required by AWS CloudFront, and validated. After the Distribution has been created, create a CNAME DNS record for your domain name with the Distribution's URL as the value. Here are more details on configuring SSL Certificate on externally hosted domains.

Also note that you can also migrate externally hosted domains to Route 53 by following this guide.

Configuring server function​

new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  timeout: "5 seconds",
  memorySize: "2048 MB",
});

Advanced examples​

Using an existing S3 Bucket​

import * as s3 from "aws-cdk-lib/aws-s3";

new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  cdk: {
    bucket: s3.Bucket.fromBucketName(stack, "Bucket", "my-bucket"),
  },
});

Reusing CloudFront cache policies​

CloudFront has a limit of 20 cache policies per AWS account. This is a hard limit, and cannot be increased. If you plan to deploy multiple Astro sites, you can have the constructs share the same cache policies by reusing them across sites.

import * as cdk from "aws-cdk-lib";
import * as cf from "aws-cdk-lib/aws-cloudfront";

const serverCachePolicy = new cf.CachePolicy(stack, "ServerCache", {
  queryStringBehavior: cf.CacheQueryStringBehavior.all(),
  headerBehavior: cf.CacheHeaderBehavior.none(),
  cookieBehavior: cf.CacheCookieBehavior.all(),
  defaultTtl: cdk.Duration.days(0),
  maxTtl: cdk.Duration.days(365),
  minTtl: cdk.Duration.days(0),
  enableAcceptEncodingBrotli: true,
  enableAcceptEncodingGzip: true,
});

new AstroSite(stack, "Site1", {
  path: "my-astro-app/",
  cdk: {
    serverCachePolicy,
  },
});

new AstroSite(stack, "Site2", {
  path: "another-astro-app/",
  cdk: {
    serverCachePolicy,
  },
});

Protecting server function behind API Gateway​

When deployed to a single region, instead of sending the request to the server function directly, you can send the request to API Gateway and have API Gateway proxy the request to the server function. With this setup, you can use features like authorizers to protect the server function.

import { Fn } from "aws-cdk-lib";
import * as origins from "aws-cdk-lib/aws-cloudfront-origins";

const api = new Api(stack, "Api");

const site = new AstroSite(stack, "Site", {
  path: "my-astro-app/",
  cdk: {
    distribution: {
      defaultBehavior: {
        origin: new origins.HttpOrigin(Fn.parseDomainName(api.url)),
      },
    },
  },
});

api.addRoutes(stack, {
  "ANY /{proxy+}": {
    type: "function",
    cdk: {
      function: site.cdk.function,
    },
  },
});

Constructor​

new AstroSite(scope, id, props)

Parameters

Properties​

An instance of AstroSite has the following properties.

customDomainUrl​

Type : undefined | string

If the custom domain is enabled, this is the URL of the website with the custom domain.

id​

Type : string

url​

Type : undefined | string

The CloudFront URL of the website.

cdk​

Type : undefined |

cdk.bucket​

Type : Bucket

cdk.certificate​

Type : undefined | ICertificate

cdk.distribution​

Type : Distribution

cdk.function​

Type : undefined | Function

cdk.hostedZone​

Type : undefined | IHostedZone

The internally created CDK resources.

Methods​

An instance of AstroSite has the following methods.

attachPermissions​

attachPermissions(permissions)

Parameters

Attaches the given list of permissions to allow the Astro server side rendering to access other AWS resources.

site.attachPermissions(["sns"]);

SsrSiteProps​

bind?​

Type : Array<SSTConstruct>

Bind resources for the function

new AstroSite(stack, "Function", {
  handler: "src/function.handler",
  bind: [STRIPE_KEY, bucket],
})

buildCommand?​

Type : string

The command for building the website

buildCommand: "yarn build",

customDomain?​

Type : string | SsrDomainProps

The customDomain for this website. SST supports domains that are hosted either on Route 53 or externally.

Note that you can also migrate externally hosted domains to Route 53 by following this guide.

customDomain: "domain.com",
customDomain: {
  domainName: "domain.com",
  domainAlias: "www.domain.com",
  hostedZone: "domain.com"
},

dev.deploy?​

Type : boolean

When running sst dev, site is not deployed. This is to ensure sst dev` can start up quickly.

dev: {
  deploy: true
}

edge?​

Type : boolean

The SSR function is deployed to Lambda in a single region. Alternatively, you can enable this option to deploy to Lambda@Edge.

environment?​

Type : Record<string, string>

An object with the key being the environment variable name.

environment: {
  API_URL: api.url,
  USER_POOL_CLIENT: auth.cognitoUserPoolClient.userPoolClientId,
},

memorySize?​

Type : number | ${number} MB | ${number} GB

The amount of memory in MB allocated for SSR function.

memorySize: "512 MB",

nodejs?​

Type : SsrSiteNodeJSProps

Used to configure nodejs function properties

path?​

Type : string

Path to the directory where the app is located.

permissions?​

Type : Permissions

Attaches the given list of permissions to the SSR function. Configuring this property is equivalent to calling attachPermissions() after the site is created.

permissions: ["ses"]

runtime?​

Type : "nodejs14.x" | "nodejs16.x" | "nodejs18.x"

The runtime environment for the SSR function.

runtime: "nodejs16.x",

timeout?​

Type : number | ${number} second | ${number} seconds | ${number} minute | ${number} minutes | ${number} hour | ${number} hours | ${number} day | ${number} days

The execution timeout in seconds for SSR function.

timeout: "5 seconds",

waitForInvalidation?​

Type : boolean

While deploying, SST waits for the CloudFront cache invalidation process to finish. This ensures that the new content will be served once the deploy command finishes. However, this process can sometimes take more than 5 mins. For non-prod environments it might make sense to pass in false . That'll skip waiting for the cache to invalidate and speed up the deploy process.

cdk.bucket?​

Type : IBucket | BucketProps

Allows you to override default settings this construct uses internally to ceate the bucket

cdk.distribution?​

Type : SsrCdkDistributionProps

Pass in a value to override the default settings this construct uses to create the CDK Distribution internally.

cdk.id?​

Type : string

Allows you to override default id for this construct.

cdk.server?​

Type : Pick<FunctionProps, "architecture" | "vpc" | "vpcSubnets" | "securityGroups" | "allowAllOutbound" | "allowPublicSubnet">

cdk.serverCachePolicy?​

Type : ICachePolicy

Override the CloudFront cache policy properties for responses from the server rendering Lambda. The default cache policy that is used in the abscene of this property is one that performs no caching of the server response.

SsrDomainProps​

alternateNames?​

Type : Array<string>

Specify additional names that should route to the Cloudfront Distribution. Note, certificates for these names will not be automatically generated so the certificate option must be specified.

domainAlias?​

Type : string

An alternative domain to be assigned to the website URL. Visitors to the alias will be redirected to the main domain. (ie. www.domain.com ).

Use this to create a www. version of your domain and redirect visitors to the root domain.

domainName​

Type : string

The domain to be assigned to the website URL (ie. domain.com).

Supports domains that are hosted either on Route 53 or externally.

hostedZone?​

Type : string

The hosted zone in Route 53 that contains the domain. By default, SST will look for a hosted zone matching the domainName that's passed in.

Set this option if SST cannot find the hosted zone in Route 53.

isExternalDomain?​

Type : boolean

Set this option if the domain is not hosted on Amazon Route 53.

cdk.certificate?​

Type : ICertificate

Import the certificate for the domain. By default, SST will create a certificate with the domain name. The certificate will be created in the us-east-1 (N. Virginia) region as required by AWS CloudFront.

Set this option if you have an existing certificate in the us-east-1 region in AWS Certificate Manager you want to use.

cdk.hostedZone?​

Type : IHostedZone

Import the underlying Route 53 hosted zone.

SsrSiteNodeJSProps​

Type : string

Use this to insert an arbitrary string at the beginning of generated JavaScript and CSS files.

nodejs: {
  banner: "console.log('Function starting')"
}

esbuild?​

Type : BuildOptions

This allows you to customize esbuild config.

format?​

Type : "esm" | "cjs"

Configure format

nodejs: {
  format: "cjs"
}

install?​

Type : Array<string>

Packages that will be excluded from the bundle and installed into node_modules instead. Useful for dependencies that cannot be bundled, like those with binary dependencies.

nodejs: {
  install: ["pg"]
}

loader?​

Type : Record<string, Loader>

Configure additional esbuild loaders for other file extensions

nodejs: {
  loader: {
   ".png": "file"
  }
}

minify?​

Type : boolean

Enable or disable minification

nodejs: {
  minify: false
}

sourcemap?​

Type : boolean

Configure if sourcemaps are generated when the function is bundled for production. Since they increase payload size and potentially cold starts they are not generated by default. They are always generated during local development mode.

nodejs: {
  sourcemap: true
}

SsrSiteReplaceProps​

files​

Type : string

replace​

Type : string

Type : string

SsrCdkDistributionProps​

defaultBehavior?​

Type :