Is there a mechanism for deploying settings to SSM Parameter Store using SST? I’m thinking of settings such as secret third-party API keys here and not stack outputs. In the past, I’ve created a util to read from a local dotenv file (not version controlled) and write these to SSM under an

/{appName}/{stage}

prefix

I generally use the CDK directly for this:

import { StackContext } from "@serverless-stack/resources";
import * as ssm from "aws-cdk-lib/aws-ssm";

// resources deployed only when running "locally"
export function MyStack({ stack, app }: StackContext) {

  // Create SSM parameter 
  new ssm.StringParameter(stack, "myParam", {
    description: "APIKey",
    parameterName: `/${stack.stage}/${app.name}/apiKey`,
    stringValue: process.env.MY_API_KEY!,
  });
}

we're going to be baking this into our console

be nice to be able to do it in the console

Since I follow a standard naming convention across my SSM parameters (

/<app name>/<stage>/<param name>

), I've started added a little helper script in my

package.json

that lists all the SSM parameter values my stack defines.

"scripts": {
    "ssm:list": "aws ssm get-parameters-by-path --recursive --with-decryption --path=/${npm_package_name} --region=${npm_package_region} --profile=${npm_package_myStage}"
}

just thinking of the workflow for a new developer joining a team with an app with multiple secrets in it. How do they quickly get those secret values into their own SSM params

mostly because I can never remember the AWS CLI options 🙂

nice!

if you have a single dev aws account for all developers, the new parameter thing has the concept of "fallback". So I'd specify

/myapp/fallback/STRIPE_KEY

and that way each developer won't have to set it under

/myapp/dax/STRIPE_KEY

yea I’m typically working in a shared dev account, so that fallback would work

me neither 😮

Yeah, I just found out about it myself! Unfortunately, it's just hard coded for now. Nothing too clever

{
  "packageName": "my-service-name",
  "myStage": "SSO-PROFILE-NAME-HERE",
  "region":"us-east-1",
  "scripts": {
     ...
   }
}

ah I just realised that it’s the AWS profile name and not the stage that you need in your CLI command. I think it makes sense for all devs to use the same SSO profile name when setting up AWS SSO CLI so this is fine to hardcode

yeah that's what I do as well

AWS_PROFILE=<company>-dev

Hm, I think I may have pasted a misleading script 🙂 I generally use $(whoami) as the stage name. I know SST will prompt for this if not present, but I am setting this up for a team of devs that might not be familiar with SST. I don't want them selecting a non-unique stage name (e.g.

dev

), so I use

$(whoami)

as a sensible default. I generally set the profile to a parameter named

profile

. A less misleading example:

{
  "name": "my-service-name",
  "profile": "SSO-PROFILE-NAME-HERE",
  "region": "us-east-1",
  "scripts": {
    "start": "sst start --stage $(whoami) --profile=${npm_package_profile}",
    "ssm:list": "aws ssm get-parameters-by-path --recursive --with-decryption --path=/${npm_package_name} --region=${npm_package_region} --profile=${npm_package_profile}"
  }
}

that totally makes sense 👍🏻

Interesting, I've used bash scripts to create/update/delete aws Parameter store - I'm going to tinker using NPM and the inline variables with package.json.

Good point, I should stop being so lazy and raise an error if undefined :)

Hmm .. custom package.json properties for me are always undefined when I try to reference them like so ${npm_package_region}