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, Google Cloud and Azure. 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. The up command will prompt you to create a stack if you haven't already created one for you project.

nitric up

To tear down a previously deployed application use the down command.

nitric down

Providers

Each of your project's stacks will target a specific hosting platform. The plugins that perform the deployments to these platforms are called providers. Nitric currently has 3 official providers, one each for AWS, Google Cloud and Azure. All of the official providers 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 the provider documentation: AWS, Google Cloud and Azure.

Configuring state backend

To track the state of your stack between deployments you'll need to configure a location for Pulumi to store its stack state (also known as a 'backend'). Pulumi provides several options for state backends, a common choice is Pulumi's managed service which stores state in the cloud allowing for secure storage and collaboration. Alternatively, you can use any other state backends Pulumi support.

Configuring stacks

When using stacks to deploy to different environments such as a development, testing or production environment, you'll typically want to go beyond the default configuration Nitric uses when deploying cloud resources. This environment specific configuration is added to the stack files.

When deploying the application, you can add extra configuration for specific services or globally for all services. This configuration is unique to each stack file, allowing you to deploy the same application to different environments with different configurations. Since the configuration options available are unique to the cloud platform and the services they offer these settings are typically different between provider implementations.

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

provider: nitric/aws@1.1.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 services with different configuration for each. The default configuration, which we'll apply to most services. There is also a memory-optimized handler group, which we've used to allocate more memory to those services 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
services:
  - match: services/*.ts
    start: ts-node $SERVICE_PATH
    type: default
  - match: custom/*.ts
    start: ts-node $SERVICE_PATH
    type: memory-optimized

Provider specific stack configuration can be viewed in the reference docs for each provider.

• AWS stack configuration
• Azure stack configuration
• GCP stack configuration