Deployment

Nitric can automatically deploy your application to a supported cloud provider. As discussed in the concepts page, Nitric has three standard providers, one each for AWS, Microsoft Azure and Google Cloud. If none of those fit your needs you're also able to build a custom provider to target the host you prefer with your own tools and configuration.

The Nitric CLI command to perform deployments is nitric up. However, before your first deployment you'll need to create a stack, stacks represent deployment targets. If you haven't created a stack before we recommend reading the steps in our quickstart guide.

Using the official providers

The current providers in Nitric for AWS, Google Cloud and Azure all use Pulumi under the hood for their deployments, so Pulumi will need to be configured to persist your stack state and to run the deployment to the cloud of your choice.

Configuring cloud credentials

You will need to configure your cloud credentials, either locally or in your CI/CD pipeline, to allow Nitric to create resources in a cloud account. Instructions on how to setup credentials for your target provider can be found in our provider documentation: AWS, Google Cloud and Azure.

Configuring State Backend

To maintain the state of your deployment between runs you'll need to configure a backend for Pulumi to store its stack state. For this, you can use either Pulumi's managed service, or you could use one of the other state backends they provide support for.

Configuring Deployment

When deploying the application, you can add extra configuration for specific handlers or a globally for all handlers. This configuration is unique to each stack file, allowing you to deploy the same application to different environments with different configuration.

Below is an example of configuration added to an AWS stack to augment the memory, timeout, and telemetry sampling percentage for deployed handlers.

name: project
provider: nitric/aws@0.24.0
region: us-east-1
telemetry: 10
config:
  default:
    lambda:
      memory: 1024
  memory-optimized:
    lambda:
      memory: 4096

Note that the configuration above creates two types of handlers with different configuration for each. The default configuration, which we'll apply to most handlers. There is also a memory-optimized handler group, which we've used to allocate more memory to those handlers specifically.

To apply these handler group configurations, we need to create the groups. That's done by updating the project file to create groups and match them to different source code locations:

name: my-project
handlers:
  - match: functions/*.ts
    type: default
  - match: custom/*.ts
    type: memory-optimized