A Nitric stack represents a pairing of a project and its deployment target. A project may have multiple stacks as the deployment target is broken down into a cloud provider e.g.
aws and a region e.g.
If your project needs to deploy to
aws in two regions
eu-west-1, you'll have two stack definitions in your project.
To create a stack use the new command from your project root. Each stack name must be unique within the project.
nitric stack new
Follow the prompts to create a stack for your provider.
? What do you want to call your new stack? aws-stack ? Which Cloud do you wish to deploy to? aws ? select the region us-east-1
The stack definition will be created in the root of your project as a YAML file prefixed with
name: my-aws-stack provider: email@example.com region: us-east-1
If you want to specify different configuration for your functions you can use the following syntax:
name: my-aws-stack provider: firstname.lastname@example.org region: us-east-1 config: default: lambda: memory: 1024 telemetry: 10 target: lambda memory-optimized: lambda: memory: 4096
Once you have created a stack, you're ready to deploy and undeploy to your deployment target. See the CLI docs for available commands.
Previously stacks were not tied to a specific runtime and did not version the providers. It had the following format:
name: my-aws-stack provider: aws region: us-east-1 config: default: memory: 1024 telemetry: 10 memory-optimized: memory: 4096
The provider has been updated from
email@example.com respectively. This change enables locking a version for your deployments, as it was previously tied to the CLI version. This change will also enable creation of your own custom deployment providers.
There was also a change to the way configuration is written to support multiple execution runtimes. Currently there are no new runtimes supported (just Lambda, Cloud Run, and Container Apps), however there are plans to support more in the near future, hence the change. The migration involves adding the runtime key to the configuration, letting the deployment know what runtime it should apply the configuration to.
# Legacy config: default: memory: 1024 memory-optimized: memory: 4096 # New AWS Config config: default: lambda: memory: 1024 # in MB target: lambda memory-optimized: # A non-default configuration does not need to specify a target # It picks up from which runtime config is provided lambda: memory: 4096 # New GCP Config config: default: cloudrun: memory: 1024 # in MB target: cloudrun memory-optimized: cloudrun: memory: 4096 # New Azure Config config: default: containerapps: memory: 1 # in GB target: containerapps memory-optimized: containerapps: memory: 4
You are free to manually edit the stack definition if required, ensure that both the provider and region values are valid or simply run the
nitric stack new command again.