cloudparts

Nitric

A multi-language framework in which code asks for APIs, buckets, queues, topics and databases through an SDK; at deploy time Nitric collects those requests and a provider plugin turns them into AWS, Google Cloud or Azure resources, through Pulumi or generated Terraform.

What it is
Infrastructure as code
Used for
Serverless functions (FaaS)
Type
Open source
Made by
Nitric Inc.
License
Apache 2.0
Facts checked
24 October 2026
Website Source code

What it is

A Nitric service declares what it needs with SDK calls: api('main'), bucket('profiles').allow('read', 'write'), topic('signups'), kv('carts'), schedule('cleanup').every('5 minutes', …). The allow() call states which operations the code performs, and Nitric turns that into IAM policies. SDKs exist for JavaScript and TypeScript, Python, Go and Dart. nitric start runs the services locally with emulated resources and a dashboard for calling APIs, publishing to topics and uploading to buckets.

nitric up builds each service into a container image, then runs the app in a collection mode that records every resource and permission it asks for. That graph, plus a stack file naming a provider such as nitric/aws, goes to a provider plugin. On AWS the standard provider uses Pulumi to create API Gateway HTTP APIs in front of Lambda functions running the images, S3 buckets, SNS topics, SQS queues, DynamoDB tables and Aurora PostgreSQL; on Google Cloud it uses API Gateway, Cloud Run, Pub/Sub and Firestore, and on Azure API Management, Container Apps, Event Grid and Table storage. Terraform providers instead generate a Terraform stack for you to review and apply, and teams can write their own providers for other platforms.

Nitric is open source under Apache 2.0, made by Nitric Inc. The company’s focus has since moved to Suga, a hosting platform, and after a quiet first half of 2026 the framework received a burst of fixes and v1.28.4 in October 2026.

Why teams pick it

  • Application code isn’t tied to one cloud: the same bucket() call becomes S3, Cloud Storage or Azure Blob depending on the provider in the stack file
  • Least-privilege permissions come from allow() declarations next to the code that uses them
  • Platform teams can keep control of the actual resources by writing or extending providers, or by reviewing the Terraform that Terraform providers generate
  • SDKs for JavaScript and TypeScript, Python, Go and Dart share the same resources and providers, so one deployment model covers several languages

Watch out for

  • Only the resources the SDK models (APIs, buckets, queues, topics, key-value stores, schedules, websockets, SQL, secrets) are covered; anything else needs a custom provider or separate IaC
  • The Terraform providers are built on CDKTF, which HashiCorp archived in December 2025
  • The company’s main product is now Suga, and framework development has slowed to occasional bursts of fixes
  • Because one bucket() or topic() has to mean the same thing on every cloud, cloud-specific settings are reached by customising the provider, not from application code

Alternatives

What all infrastructure as code have in common →Compare side by side →
EncoreOpen sourceA backend framework for TypeScript and Go in which services declare the databases, topics, buckets and cron jobs they need as typed objects in code; Encore reads those declarations and runs them locally or provisions them in your AWS or GCP account.WingPreviewOpen sourceA programming language for the cloud that puts infrastructure and the code that runs on it in one program: the compiler turns it into Terraform for AWS, Azure or Google Cloud plus JavaScript for the functions, and can also run it all in a local simulator.

How it fits with other technologies

services/profiles.ts and the stack file that picks the cloud · ts

import { api, bucket } from '@nitric/sdk'

const profiles = bucket('profiles').allow('read')  // becomes an S3 read policy on AWS
const main = api('main')

main.get('/profiles/:name', async (ctx) => {
  const { name } = ctx.req.params
  const image = await profiles.file(`users/${name}/profile.png`).read()
  ctx.res.body = image
})

// nitric.aws.yaml
//   provider: nitric/aws@1.1.0
//   region: us-east-1
// $ nitric start            local emulation and dashboard
// $ nitric up --stack aws   deploy through the AWS provider

See it in a real stack

No architecture uses Nitric yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2020–2026

Nitric’s repository was created at the end of 2020, and by October 2021 the framework was in developer preview with Azure added as a deployment target next to AWS and Google Cloud. The idea, which its makers later called infrastructure from code, was to let application code state what it needs and generate the infrastructure from that, rather than keeping a separate infrastructure codebase in step with the application.

The team chose Pulumi for its first providers, using the Pulumi Automation API from providers written in Go. In an October 2023 post they explained why: real programming languages, composable components, encrypted secrets in state and an Apache 2.0 licence, which fit better than Terraform’s new Business Source License. Version 1.0 followed in February 2024, adding live architecture diagrams, customisable providers and an experimental Dart SDK.

In July 2024 Nitric added Terraform providers for teams already invested in Terraform, mapping the app’s requirements onto reusable modules. The company, led by co-founder and CEO Jye Cusch, then built Suga, a deployment platform, and the nitric.io home page now leads with Suga while the framework is maintained in occasional bursts.

Why it’s built this way

Resources requested through SDK calls in application code
The code that reads a bucket is the best record of which bucket it needs and what it does with it, so permissions and resources can be derived instead of written twice.
Pluggable providers that receive a resource graph
Separating what the app needs from how it is built lets the same code target AWS, Google Cloud, Azure or a company’s own Terraform modules.
Pulumi for the first providers
Pulumi offered typed, testable code, encrypted secrets and an Apache 2.0 licence, and its Automation API could be driven from Go.
Add Terraform providers that generate a stack
Many operations teams already standardised on Terraform modules and wanted to review and apply generated Terraform rather than let a tool deploy directly.

Timeline

  1. 2020

    Nitric repository created in December

  2. 2021

    Developer preview adds Azure support

  3. 2023

    Team explains building its standard providers on Pulumi

  4. 2024

    Nitric 1.0 in February; Terraform providers in July

  5. 2026

    v1.28.4 in October, after months without changes

Sources12 · facts checked 24 October 2026

Improve this page on GitHub