Can you share a bit more context on where are you using the env var that is not replaced?

@Frank could you give me some pointers how I could feed

ContentBucket.bucketName

into the NextjsSite construct at build time. Should I split

sst.Bucket

and

sst.NextjsSite

into different sst apps or stacks, and if so how do I feed

ContentBucket.bucketName

from one to the other in an automated way? If there's some documentation covering that, either in sst or cdk, that would be great.

Imagine you are building for the first time, the S3 bucket hasn’t been created. So when you are building the Next.js app, the bucket name is not known at build time. Hence your

getPost()

call in ur Next.js app doesn’t know where to load the post from.

A work around for this would be to create an SSM parameter with the value, and read it at build time. For example:

const ContentBucket = new sst.Bucket(this, "ContentBucket");

const ssmParamName = scope.logicalPrefixedName("ContentBucketName");
const ssmBucketName = new ssm.StringParameter(stack, 'ContentBucketNameParameter', {
  parameterName: ssmParamName,
  stringValue: ContentBucket.bucketName,
});

const site = new sst.NextjsSite(this, "Site", {
  path: "frontend",
  environment: {
    REGION: scope.region,
    BUCKET_NAME: ssm.StringParameter.valueFromLookup(stack, ssmParamName),
  },
});

What this does is

ssm.StringParameter.valueFromLookup

makes an AWS SDK call to SSM to fetch the value, so the bucket name is available at build time.

Let me know if this makes sense.

Give this a try: 1. Same as above, create an SSM parameter after the bucket is created:

const ContentBucket = new sst.Bucket(this, "ContentBucket");

const ssmParamName = scope.logicalPrefixedName("ContentBucketName");
const ssmBucketName = new ssm.StringParameter(stack, 'ContentBucketNameParameter', {
  parameterName: ssmParamName,
  stringValue: ContentBucket.bucketName,
});

2. In our index file (ie.

lib/index.js

or

stacks/index.js

) make a call to the SSM value using AWS SDK. If the value does not exist (ie. in the case of the first deployment), default the value to a “placeholder”. 3. Pass the value to the stack, and assign it to the environment

const site = new sst.NextjsSite(this, "Site", {
  path: "frontend",
  environment: {
    REGION: scope.region,
    BUCKET_NAME: props.VALUE_FROM_AWS_SDK,
  },
});

Let me know if it makes sense.

Hey @Devin, yeah this workaround is a bit cumbersome. I don’t have working code with me, does the 3 steps above make sense? Let me know which step is confusing, and I can elaborate on it. https://serverless-stack.slack.com/archives/C01JG3B20RY/p1634575874311200?thread_ts=1633529817.256700&cid=C01JG3B20RY

well it deployed which is awesome! But amplify is incorrectly configured on

prod

so I suspect I still have something to figure out with

env

variables and passing everything around

Thanks heaps for your help!

@Frank Here are the steps to reproduce the problem "NextjsSite replacing process.env vars in the initial build phase but not in the deployment SiteMainFunction Lambda". 1) git clone https://github.com/warwickgrigg/sst-nextjs-blog 2) cd sst-nextjs-blog 3) run npm install (and in frontend) 4) npx sst deploy --stage warwickrepo 5) repeat stage 4 6) open webpage s3posts/b.txt for the cloudfront site 7) check the cloudwatch logs which show { bucketName: undefined, testVar: undefined, ...} 8 ) check the SiteMainFunction Lambda code in pages/s3posts/[id].js which contains process.env.BUCKET_NAME etc

@Frank @Devin A trick I've used before is a viable workaround in the meantime. Adding this to next.config.js:

env: {
    BUCKET_NAME: process.env.BUCKET_NAME,
    TEST_VAR: process.env.TEST_VAR,
},

@Frank Thanks for all your help with this. The strategy you devised for getting CDK resource ids into the build via SSM is working very well. I've got the POC deployed very nicely via SST the way I hoped, with combined SSG/SSR pages via {fallback: blocking}. I'll update my repo with my workaround for the environment variables, and a basic README

Hey guys, the environment variable issue is fixed in v0.49.2

Do you need to use the

NEXT_PUBLIC_

prefix for them to be available to the client side JS after

next build

has been run?

Does anyone have an example repo with the

env

values used in a none API route or in

_app

?

The suggestion #2 is a bit tricky as the Lambda function only has 500MB of disk space. Might not be enough to build the Next.js app. As for suggest #1, that’s pretty much what @Warwick Grigg was doing by fetching the SSM values manually using AWS SDK. The first time it builds, the SSM values are not set because it has not been deployed yet. You have to build it again to pick up the SSM values.

@Devin, let me write something up with an example, and I will share it with you.

Solid it worked. Late here so I'll work on getting something out tmrw

@Devin, @Frank and @Warwick Grigg, adding some notes on this (going to add to a blog so ignore the circular references 😅 ) SST deployments were working fine locally, but I ran into errors with the UserPool when attempting to configure Amplify on the frontend. The UserID was was exposed through a

NEXT_PUBLIC_

env var through the

NextJsSite

construct. But because the User Pool wasn't yet created, the User Pool Name wasn't accessible. This is how I'm calling Amplify on the frontend:

javascript
// amplifyLib.js
import { Amplify } from "aws-amplify";
import awsExports from "src/aws-exports";

export function configureAmplify() {
  return Amplify.configure({ ...awsExports, ssr: true });
}

// src/aws-exports.js
const awsExports = {
  Auth: {
    mandatorySignIn: false,
    region: process.env.NEXT_PUBLIC_REGION,
    userPoolId: process.env.NEXT_PUBLIC_USER_POOL_ID,
    identityPoolId: process.env.NEXT_PUBLIC_IDENTITY_POOL_ID,
    userPoolWebClientId: process.env.NEXT_PUBLIC_USER_POOL_CLIENT_ID,
  }
};
export default awsExports;

// index.js
import { configureAmplify } from "src/common/libs/amplifyLib";
// ... more imports
configureAmplify();

I ended up adapting the solutions from Frank and Warwick in this thread this thread . I also referred to Warwick's GitHub which was very helpful! There wasn't much of a difference outside of creating an SSM parameter for the User Pool ID Name as opposed to the S3 bucket. Relevant code for the backend:

javascript
// index.js
import { SSMClient, GetParameterCommand } from "@aws-sdk/client-ssm"

const getParameter = async (paramName, region) => {
  const params = {
    Name: paramName,
    WithDecryption: false,
  };

  const ssmClient = new SSMClient({ region });
  try {
    const { Parameter: { Value }} = await ssmClient.send(
      new GetParameterCommand(params)
    );
    return Value;
  } catch (err) {
    return undefined;
  }
}

export default async function main(app) {
  const ssmParamName = app.logicalPrefixedName("UserPoolIdName");
  const userPoolIdName = await getParameter(ssmParamName, app.region);

  console.log({ ssmParamName, userPoolIdName });
  new MyStack(app, "my-stack", { ssmParamName, userPoolIdName });
}


// MyStack.js
import { StringParameter } from "aws-cdk-lib/aws-ssm";
export default class MyStack extends sst.Stack {
  constructor(scope, id, props) {
    super(scope, id, props);

    const { ssmParamName, userPoolIdName = "" } = props;
    console.log({ ssmParamName, userPoolIdName });

    const auth = new sst.Auth(this, "Auth", {
      cognito: {
        userPool: {
          signInAliases: {
            email: true,
          },
        },
      },
    });

    // Define SSM Parameter
    new StringParameter(this, "UserPoolIdParameter", {
      parameterName: ssmParamName,
      stringValue: auth.cognitoUserPool.userPoolId
    });

    const site = new sst.NextjsSite(this, "ProdSite", {
      path: "frontend",
      customDomain: {
        domainName:
          scope.stage === "prod" ? "<http://productionSiteURL.io|productionSiteURL.io>" : `${scope.stage}.<http://productionSiteURL.io|productionSiteURL.io>`,
        domainAlias: scope.stage === "prod" ? "<http://www.productionSiteURL.io|www.productionSiteURL.io>" : undefined,
        cdk: {
          certificate: Certificate.fromCertificateArn(
            this,
            "ProductionCert",
            process.env.PRODUCTION_CERT_ARN
          ),
        },
          hostedZone: HostedZone.fromHostedZoneAttributes(
            this,
            "ProdZone",
            {
              hostedZoneId: process.env.HOSTED_ZONE_ID,
              zoneName: process.env.ZONE_NAME,
            }
          ),
      },
      environment: {
        NEXT_PUBLIC_REGION: scope.region,
        NEXT_PUBLIC_USER_POOL_ID: userPoolIdName,
        NEXT_PUBLIC_USER_POOL_ARN: auth.cognitoUserPool.userPoolArn,
        NEXT_PUBLIC_IDENTITY_POOL_ID: auth.cognitoCfnIdentityPool.ref,
        NEXT_PUBLIC_USER_POOL_CLIENT_ID:
          auth.cognitoUserPoolClient.userPoolClientId,
      },
      waitForInvalidation: false, // dev only
    });

    this.addOutputs({
      MESSAGE: userPoolIdName
        ? "" 
        : "Rerun `sst deploy` to generate UserPoolID",
    });
  }
}

I ran

npx sst start

once and indeed the

UserPoolIdName

was undefined. Running again as suggested produced a valid

UserPoolIdName

as the resource name was being pulled from SSM. Running

npx sst deploy

ran successfully. My sense is that exposing other User Pool properties as Next environment variables should throw an error similar to what I experienced with the

UserPoolIdName

. These are also passed into the Amplify configuration, though perhaps the User Pool ID is all that is required for the initialization. I also don't have an immediate need for Auth, so haven't given the Identity pool or User pool client an opportunity to yell at me 😄 Similar to others, I suppose there must be a cleaner way to do this. Scott considers in this thread the idea of moving the frontend to a separate repo, which then fetches the vars from a config. Another thought would be to create a separate stack for SSM params, deploy that first, and then deploy the Main stack. Though expect these may require separate

sst.json

files.