Meta tags:
description= How to deploy Nitric applications;
Headings (most frequently used words):
providers, nitric, deployment, how, work, up, down, what, happens, during, get, started, build, deploy, languages, reference, misc, flexibility, pre, built, custom, deploying, your, application, stacks, importing, existing, resources, ci, cd, runtime, adaptation, direct, infrastructure, as, code, imports,
Text of the page (most frequently used words):
the (165), nitric (65), you (55), #provider (49), api (48), application (42), for (41), deployment (36), your (35), #providers (35), resources (32), and (30), file (28), this (27), cloud (24), will (24), bucket (22), stack (21), use (21), route (20), with (19), plugin (19), deploy (19), secret (18), delete (16), are (16), run (16), that (15), can (15), sql (15), configuration (14), code (14), get (14), websocket (14), existing (13), build (12), project (12), overview (12), custom (11), aws (11), specific (11), secrets (11), terraform (11), put (11), queue (11), topic (11), job (11), down (10), using (10), resource (10), all (10), iac (10), process (9), these (9), files (9), version (9), service (9), schedule (9), schedules (9), storage (9), key (9), value (9), stores (9), apis (9), deploying (8), how (8), import (8), target (8), read (8), generate (8), used (8), services (8), runtime (8), queues (8), topics (8), page (7), have (7), azure (7), tags (7), standard (7), allows (7), direct (7), platform (7), websockets (7), batch (7), patch (7), post (7), github (6), google (6), tools (6), not (6), created (6), like (6), example (6), available (6), want (6), container (6), required (6), cli (6), command (6), infrastructure (6), adapter (6), directly (6), importing (5), automation (5), during (5), need (5), set (5), type (5), them (5), access (5), options (5), which (5), such (5), images (5), also (5), could (5), useful (5), write (5), databases (5), websites (5), guides (4), stacks (4), built (4), work (4), applications (4), when (4), they (4), would (4), two (4), name (4), into (4), only (4), other (4), create (4), new (4), one (4), docs (4), about (4), typically (4), workflows (4), pulumi (4), graph (4), mode (4), where (4), deployments (4), development (4), prefer (4), send (4), dequeue (4), enqueue (4), subscribe (4), publish (4), keys (4), submit (4), handler (4), search (4), discord (3), foundations (3), support (3), pre (3), common (3), may (3), imported (3), just (3), from (3), able (3), section (3), another (3), reference (3), each (3), yaml (3), option (3), tear (3), case (3), choice (3), building (3), manage (3), starting (3), more (3), plugins (3), why (3), close (3), cron (3), every (3), connectionstring (3), latest (3), server (2), follow (2), contributions (2), 2026 (2), edit (2), flexibility (2), last (2), updated (2), open (2), issue (2), simple (2), explore (2), examples (2), added (2), manually (2), has (2), those (2), what (2), happens (2), extremely (2), tag (2), randomid (2), make (2), needed (2), since (2), add (2), allow (2), instead (2), imports (2), same (2), either (2), additional (2), chat (2), supports (2), define (2), there (2), format (2), specifying (2), image (2), docker (2), namespace (2), any (2), multiple (2), environments (2), collects (2), collection (2), includes (2), following (2), steps (2), commands (2), different (2), tooling (2), configure (2), change (2), still (2), leverage (2), recommend (2), simplicity (2), their (2), first (2), documentation (2), allowing (2), alternatively (2), doesn (2), but (2), generates (2), cost (2), estimation (2), know (2), sdks (2), result (2), between (2), requests (2), sdk (2), underlying (2), responsible (2), important (2), getuploadurl (2), getdownloadurl (2), exists (2), http (2), async (2), messaging (2), started (2), youtube, join, our, inc, jan, feedback, pipelines, gitlab, actions, below, removed, intend, redeploy, remove, tearing, deleted, because, were, safety, always, retainondelete, whichever, initially, unlikely, conflict, identifies, attempts, minimum, changes, compatible, location, additionally, necessary, permissions, creates, referenced, located, accessed, fail, meaning, indicates, rather, than, currently, both, while, via, yet, supported, buckets, gcp, including, advanced, viewed, east, region, copied, copy, here, basic, field, specifies, most, deployed, uses, identify, targets, running, simply, runs, output, directory, then, might, commit, generated, repository, pipeline, embedded, tool, official, perform, builds, performs, testing, production, teardowns, primary, focuses, extend, fulfill, contracts, workflow, host, own, good, point, customization, modules, integrate, azuretf, gcptf, awstf, under, hood, configured, persist, state, ships, five, three, possibilities, endless, check, out, come, maybe, shared, share, reducing, size, individual, report, relationships, auditing, human, control, over, least, requirement, never, missed, continue, abstract, details, above, true, general, flexible, significantly, reduces, burden, writing, ensures, its, don, drift, apart, continues, functions, etc, tested, independent, end, faster, easier, test, remains, portable, acts, protocol, compliant, accepting, calls, made, client, calling, translates, abstracting, boilerplate, locating, credentials, language, across, platforms, even, though, txt, aren, provide, interact, agnostic, way, adaptation, vary, depending, previous, step, determine, involves, differ, looking, deploys, rely, policy, enforcement, handled, second, complex, yourself, called, things, feel, works, return, later, learn, customize, quickstart, guide, separation, focus, decoupled, hosting, develop, locally, preferred, without, concerns, bleeding, faq, misc, containers, env, vars, config, preview, features, dart, sqldatabase, uploadurl, downloadurl, listfiles, accessversion, newroute, newwebsocket, newschedule, newtopic, newbucket, newsqldatabase, newsecret, newqueue, newkv, newjob, newapi, connection_string, upload_url, download_url, methods, python, node, languages, install, adding, types, extension, mappings, hpc, architecture, local, security, projects, quick, start, installation, introduction,
Text of the page (random words):
sql connectionstring schedules schedule schedule every schedule cron websockets websocket websocket on websocket send websocket close python overview apis api api get api post api put api delete api patch api methods api all batch job job handler job submit key value stores kv kv get kv set kv delete kv keys topics topic topic publish topic subscribe queues queue queue enqueue queue dequeue secrets secret secret put secret version secret latest secret version access storage bucket bucket on bucket file bucket files file read file write file delete file download_url file upload_url sql sql sql connection_string schedules schedule websockets websocket websocket on websocket send go overview resources newapi newjob newkv newqueue newsecret newsqldatabase newbucket newtopic newschedule newwebsocket apis api get api post api put api delete api patch api newroute api route all api route get api route post api route put api route delete api route patch batch job handler job submit key value stores kv get kv set kv delete kv keys topics topic publish topic subscribe queues queue enqueue queue dequeue secrets secret put secret accessversion secret access storage bucket on bucket listfiles bucket read bucket write bucket delete bucket downloadurl bucket uploadurl sql sqldatabase connectionstring schedules schedule every schedule cron websockets websocket on websocket send websocket close dart overview apis api api all api get api post api put api delete api patch api route api route all api route get api route post api route put api route delete api route patch batch job job handler job submit key value stores kv kv get kv set kv delete kv keys topics topic topic publish topic subscribe queues queue queue enqueue queue dequeue secrets secret secret put secret version secret latest secret version access storage bucket bucket on bucket file bucket files file exists file read file write file delete file getdownloadurl file getuploadurl sql sql sql connectionstring schedules schedule schedule every schedule cron websockets websocket websocket on websocket send websocket close reference cli preview features other config env vars custom service containers misc examples faq contributions support deployment nitric applications are decoupled from the underlying hosting provider allowing you to develop your application locally and deploy it to your preferred cloud provider or another platform without these concerns bleeding into the application code you can read about why this separation is important on the why nitric page this page will focus on the deployment process and how to configure your application for deployment if you re new to nitric we recommend starting with the quickstart guide to get a feel for how nitric works you can return to this page later to learn more about the deployment process and how to customize it providers the plugins used to deploy your application to a specific target platform are called providers typically providers do one of two things deploy your application directly generate infrastructure as code the first option is useful for simplicity where you deployment automation is handled directly by the provider plugin the second option is useful for more complex deployments where you want to manage the infrastructure as code yourself for example if you prefer to use terraform and you rely on other terraform tools for policy enforcement or cost estimation you can use or build a provider that generates terraform code for you to deploy this allows you to use nitric s deployment automation and still leverage your existing terraform workflows alternatively if you re looking for a simple deployment process you can use or build a provider that deploys your application directly to your cloud provider of choice it s important to know which type of provider you re using as the configuration options and deployment process will differ between them how providers work nitric providers are plugins that are responsible for deploying your application to a specific target platform they can be used to deploy your application directly or to generate infrastructure as code for deployment deployment when you run nitric up the provider plugin is responsible for deploying your application to the target platform this typically involves the following steps build the application the nitric cli will build the application using the configuration in the nitric yaml file this includes building container images for each service run the application in resource collection mode nitric will run the application in a mode where it collects the resources used by the application this is used to generate the graph of cloud resources required to run the application run the provider plugin nitric will run the provider plugin to deploy the application to the target platform the provider plugin will use the resource graph from the previous step and service container images to determine the required cloud resources result the provider plugin will either deploy the application to the target platform directly or generate iac code for you to deploy the deployment process will vary depending on the provider you re using runtime adaptation 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 this allows code like bucket file file txt read to work across platforms even though the underlying services are different 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 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 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 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 flexibility the details above are true in the general case but nitric is extremely flexible for example you could build a provider that doesn t use a runtime adapter and have your applications continue to use the cloud sdks directly this could be useful if you prefer not to abstract the cloud services or you want nitric to just manage the deployment process alternatively you could build a provider that doesn t deploy your application at all but instead generates a report of the resources required to run your application and their relationships this could be useful for auditing or cost estimation it could also be useful if you prefer more human control over the deployment process at least you ll know a requirement is never missed maybe you want to deploy the runtime adapter as a shared service allowing multiple applications to share the same runtime adapter reducing the size of individual container images the possibilities are endless if you d like to explore building a custom provider check out the custom provider documentation or come chat with us on discord pre built providers nitric ships with five pre built providers the first three are direct deployment providers and the last two are iac providers direct deployment providers all of the direct deployment 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 aws google cloud azure if you re new to nitric we recommend starting with one of the direct deployment providers for simplicity infrastructure as code providers all of the iac providers generate terraform code for deployment this allows you to use nitric s deployment automation and still leverage your existing terraform workflows awstf gcptf azuretf an azure terraform provider is in development these providers are also a good starting point for customization when you have existing terraform modules or workflows you want to integrate with nitric custom providers if you have a specific cloud service deployment workflow or tooling you want to use you can build a custom provider custom providers allow you to target the host you prefer with your own tools and configuration you can also extend the existing providers to change which cloud services are used to fulfill the nitric resource contracts to add configuration options or to change the deployment process deploying your application this section focuses on how to configure your application for deployment and how to deploy it there are two primary commands for deploying your application with nitric nitric up build the application and run the provider plugin to deploy it nitric down run the provider plugin to tear down the application the nitric down is only available for direct deployment providers if you re using an iac provider you ll need to manage deployments and teardowns with your iac tooling such as terraform these commands are used to deploy stacks to different environments such as development testing or production nitric up the nitric cli command to perform builds deployments is nitric up this command performs the following steps build the application nitric will build the application using the configuration in the nitric yaml file this includes building container images for each service run the application in resource collection mode nitric will run the application in a mode where it collects the resources used by the application this is used to generate the graph of cloud resources required to run the application run the provider plugin nitric will run the provider plugin to deploy the application to the target platform the provider plugin will use the resource graph and service container images to create the required cloud resources in the case of direct deployment providers the provider plugin will use the embedded iac tool of choice to deploy the application for the official providers this is pulumi in the case of iac providers the provider plugin will generate iac code for you using existing tools such as the terraform cli this code is typically output to a directory in your project which you can then use to deploy the application with your existing ci cd workflows for example you might commit the generated iac code to a repository and use a ci cd pipeline to deploy the application nitric down 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 stacks 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 stack files define the deployment plugin provider any additional configuration required by that plugin for it to be able to generate iac or deploy your application most configuration options available in the stack files are specific to the provider you re using the common configuration option available in all stack files is the provider field which specifies the provider plugin to use for the deployment the standard format for specifying a provider is namespace provider version the namespace for all standard providers is nitric the provider is the name of the provider plugin and the version is the version of the provider plugin to use there is another format for specifying providers as a container image docker image which you can read about in the reference docs here is a basic example using the standard nitric aws provider nitric aws 1 1 0 nitric aws deployment yaml copy copied provider nitric aws 1 1 0 region us east 1 provider specific stack configuration including advanced configuration options can be viewed in the reference docs for each provider aws stack configuration azure stack configuration gcp stack configuration if you create a custom provider you re able define the options available in the stack files that target your provider importing existing resources nitric allows you to import existing resources into your nitric project currently the aws standard provider supports importing both buckets and secrets while the google cloud standard provider supports importing secrets only importing resources via other providers is not yet supported need to import another resource type or want support for additional providers chat with us on discord or open an issue on github how imports work if you have existing resources that you would like to use in your nitric project you may be able to import them using the import section of your nitric stack file this section allows you to import existing resources and use them in your nitric project this indicates to the provider that you would like to use the existing resources in your nitric project rather than create a new one imports are stack specific meaning that you can import resources into a specific stack file and they will only be available in that stack other stacks for the same project can either create or import those resources as needed what happens during nitric up when deploying a stack that has imported resources the resources will not be created instead nitric will use the referenced resources from the stack file if the resources can t be located or accessed the deployment will fail nitric attempts to make the minimum changes needed to the imported resources to make them compatible with the nitric project since nitric standard providers use custom tags for resource location the resources will have these tags added during deployment additionally nitric will add the necessary permissions to the resources to allow the nitric project to access them just like it would with resources it creates the tags created are extremely unlikely to conflict with existing tags for example with the aws standard provider an s3 bucket will have these two tags created x nitric project stack randomid type and x nitric project stack randomid name the type tag identifies the type of nitric resource and the name tag is the name of the resource in the nitric project what happens during nitric down when tearing down a stack that has imported resources the resources will not be deleted this is because the resources were not created by nitric so for safety they re always set to retainondelete if you would like to delete the resources you will need to do so manually or using whichever tools created those resources initially the tags added to the resources during deployment may not be removed during the nitric down process if you intend to redeploy the stack with an updated import you may need to remove these tags manual...
|
