Deploying Nitric Applications
When you're ready to deploy your Nitric application, you can choose from a variety provider plugins. Nitric has pre-built providers that use either Pulumi or Terraform to deploy to AWS, Google Cloud or Microsoft Azure. If you have specific requirements, you can extend these providers or build your own custom provider.
If you're new to Nitric, or want a better understanding of Nitric Providers work, we recommend reading the Foundations section.
To learn how to deploy your Nitric application, we recommend starting with the Quick Start guide. This guide will walk you through setting up a Nitric project, creating a new stack, and deploying your application.
Use this page to learn more about the cloud providers supported by Nitric, and select or build a provider that meets your deployment requirements.
Pre-built Providers
Nitric publishes pre-built providers for AWS, Google Cloud (GCP), and Microsoft Azure, which are available as part of the core open-source repository on GitHub. These providers enable deploying and running code across AWS, Google Cloud, and Azure.
The following is a description of the underlying cloud services that each of the pre-built providers use.
The Nitric team is actively working on expanding the number of pre-built providers available. If you have a specific cloud provider or service you'd like to see supported, please raise a Feature Request on GitHub.
Default Cloud Services
Currently, both the Pulumi and Terraform providers use the same underlying cloud services to deploy your application. The following table shows the cloud services used by default on each cloud:
| Resource | AWS | Azure | Google Cloud | Local |
|---|---|---|---|---|
| APIs | API Gateway | API Management | API Gateway | Custom |
| Batch | AWS Batch | Coming soon | GCP Batch | Custom |
| Schedules | CloudWatch Event Bridge | Dapr Binding | Cloud Scheduler | Custom |
| Websockets | API Gateway | Not implemented | Not implemented | Custom |
| Storage | S3 | Blob Storage | Cloud Storage | SeaweedFS |
| Key Value Stores | DynamoDB | Table Storage | FireStore | BoltDB |
| SQL Databases | RDS | Azure Database | Cloud SQL | Docker |
| Messaging: Topics | SNS | Event Grid | PubSub | Custom |
| Messaging: Queues | SQS | Storage Queues | PubSub | Custom |
| Secrets | Secrets Manager | Key Vault | Secret Manager | Custom |
| Services | Lambda | Container Apps | CloudRun | Docker |
The code is open-source on GitHub, so you can see exactly how resources are deployed and handled at runtime, then make any changes you see fit. Some features may be unimplemented, but any interest or requests are appreciated. Let us know on Discord or by creating an issue on our GitHub repository.
Custom Providers
Because Nitric providers are plugins you're able to create or extend them to meet your specific deployment requirements. Common reasons for custom provider development include:
- Using a language other than Go to develop a provider (Nitric providers can be written in many other languages).
- Using a specific Infrastructure as Code engine, e.g. using Terraform or AWS CDK instead of Pulumi.
- Changing the way resources are deployed to use a preferred service or meet regulatory or policy requirements within your organization.
- Reusing existing work on infrastructure automation, such using existing Terraform Modules for deployment with Nitric.
- Deployments to another cloud provider or on-premises deployments. You can read more about building custom providers here.
Currently, there are two ways to build a custom provider:
- Extend an existing provider: This is the easiest way to build a custom provider. You can extend an existing provider to add new resources or change the way resources are deployed. You can read more about extending providers here.
- Create a new provider: If you have specific requirements that can't be met by extending an existing provider, you can create a new provider from scratch. You can read more about creating a new provider here.