You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 20, 2025. It is now read-only.
Copy file name to clipboardExpand all lines: docs/get-started/foundations/deployment/index.mdx
+14Lines changed: 14 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -96,6 +96,20 @@ In the case of IaC providers, the provider plugin will generate IaC code for you
96
96
97
97
The Nitric CLI command to tear down the application is `nitric down`. This command simply runs the provider plugin to tear down the application. This command is only available for direct deployment providers.
98
98
99
+
### Runtime Adaptation
100
+
101
+
Provider plugins aren't just about deploying your application. They also provide a runtime adapter that allows your application to interact with cloud services in a cloud-agnostic way.
102
+
103
+
This allows code like `bucket.file('file.txt').read()` to work across platforms, even though the underlying services are different.
104
+
105
+
The runtime adapter acts as a Nitric protocol compliant server, accepting runtime calls made by a Nitric client (such as one of the [Language SDKs](/reference/languages)), for example calling `.read()` on a file in a bucket. The runtime adapter translates these requests into cloud-specific API requests, typically abstracting common boilerplate such as locating SDK credentials for the cloud specific SDK.
106
+
107
+
This allows your services, functions, etc. to be built, tested and run independent of any specific cloud service. The end result is code that's faster to write, easier to test and remains portable between services and cloud providers.
108
+
109
+
It also significantly reduces the burden of writing project-specific Infrastructure as Code and ensures the application and its deployment automation don't drift apart as development continues.
Since an application can be deployed to multiple environments and cloud providers, Nitric uses stack files to identify these deployment targets. These files can be created by running the `nitric stack new` CLI command.
Copy file name to clipboardExpand all lines: docs/providers/index.mdx
+35-43Lines changed: 35 additions & 43 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,50 +2,37 @@
2
2
description: 'Details on the cloud providers supported by Nitric'
3
3
---
4
4
5
-
# Providers
5
+
# Deploying Nitric Applications
6
6
7
-
Nitric can declare and interact with cloud features in a way that is decoupled from any particular cloud provider. Nitric providers are the abstraction layer that enables this.
7
+
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](/providers/custom/extend) or [build your own](/providers/custom/create) custom provider.
8
8
9
-
Providers are separate plugins comprised of two components—a Deployment Engine, which automatically deploys your cloud resources and a Runtime Adapter, which handles requests from the SDKs forwarding them to appropriate cloud service APIs.
9
+
<Note>
10
+
If you're new to Nitric, or want a better understanding of Nitric Providers
To learn how to deploy your Nitric application, we recommend starting with the [Quick Start](/get-started/quickstart) guide. This guide will walk you through setting up a Nitric project, creating a new stack, and deploying your application.
12
16
13
-
Applications built with Nitric declare resources, services, and permissions directly in the application code. The following example defines an API named `main`, a bucket named `images`, and permissions for the service to `read` and `write` from the bucket.
17
+
Use this page to learn more about the cloud providers supported by Nitric, and select or build a provider that meets your deployment requirements.
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](https://github.com/nitrictech/nitric/tree/main/cloud). These providers enable deploying and running code across AWS, Google Cloud, and Azure.
21
22
22
-
The chosen language SDKs forward these resource requests to the Nitric CLI, which compiles a graph of the required resources and their connections. The graph of cloud resources is then sent the chosen provider for deployment. The provider convert this declaration graph into any cloud resources it wishes that fulfill the developers intentions, typically using Infrastructure as Code tools like Pulumi or Terraform.
23
+
The following is a description of the underlying cloud services that each of the pre-built providers use:
23
24
24
-
The specific cloud services that Nitric's out-of-the-box providers use for each resource is listed in the [table below](#standard-providers).
25
+
<Note>
26
+
The Nitric team is actively working on expanding the number of pre-built
27
+
providers available. If you have a specific cloud provider or service you'd
The runtime adapter acts as a Nitric protocol compliant server, accepting runtime calls made by a Nitric client (such as one of the Nitric language SDKs), for example calling `.read()` on a file in a bucket. The runtime adapter translates these requests into cloud-specific API requests, typically abstracting common boilerplate such as locating SDK credentials for the cloud specific SDK.
37
-
38
-
This allows your functions to be built, testing and run independent of any underlying cloud service. The end result is code that's faster to write, easier to test and remains portable between cloud services and cloud providers.
39
-
40
-
It also significantly reduces the burden of writing project specific Infrastructure as Code and ensures the application and its deployment automation don't drift apart as development continues.
You can find out more about how the Nitric CLI and SDK interact with providers on the [deployment](/get-started/foundations/deployment) section.
45
-
46
-
## Standard Providers
47
-
48
-
Nitric publishes standard providers for AWS, GCP, and Azure, which are available as part of the core open-source repository on [GitHub](https://github.com/nitrictech/nitric/tree/main/cloud). 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 standard providers use:
35
+
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:
Our code is completely open-source on our [GitHub](https://github.com/nitrictech/nitric), so you can know exactly how your resources are being deployed and handled at runtime.
48
+
The code is open-source on [GitHub](https://github.com/nitrictech/nitric), so you can see exactly how resources are deployed and handled at runtime, then make any changes you see fit.
62
49
63
50
## Custom Providers
64
51
@@ -69,11 +56,16 @@ Because Nitric providers are plugins you're able to create or extend them to mee
69
56
- Changing the way resources are deployed to use a preferred service or meet regulatory or policy requirements within your organization.
70
57
- Reusing existing work on infrastructure automation, such using existing Terraform Modules for deployment with Nitric.
71
58
- Deployments to another cloud provider or on-premises deployments.
72
-
You can read more about building custom providers [here](/reference/providers/custom/building-custom-provider).
73
-
<Note>
74
-
Improving the ease and flexibility of custom provider development is
75
-
currently a priority for the Nitric team, if you need help or want to
76
-
request a feature get in touch on
77
-
[GitHub](https://github.com/nitrictech/nitric) or
78
-
[Discord](https://nitric.io/chat).
79
-
</Note>
59
+
You can read more about building custom providers [here](/providers/custom).
60
+
61
+
Currently, there are two ways to build a custom provider:
62
+
63
+
-**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](/providers/custom/extend).
64
+
-**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](/providers/custom/create).
65
+
66
+
<Note>
67
+
Improving the ease and flexibility of custom provider development is currently
68
+
a priority for the Nitric team, if you need help or want to request a feature
69
+
get in touch on [GitHub](https://github.com/nitrictech/nitric) or
0 commit comments