What you’ll learn
  • what is Pulumi
  • how is Webiny utilizing Pulumi with your project applications
  • what are state files
  • what are backends

Why Pulumi?
anchor

For defining and deploying necessary cloud infrastructure Webiny relies on Pulumiexternal link, a modern infrastructure as code (IaC)external link solution.

Webiny chose Pulumi as its default IaC solution for a couple of reasons:

  • cloud infrastructure is defined via code (TypeScript)
  • it supports multiple cloud providers (AWS, Azure, Google Cloud Platform, …)
  • it provides multiple solutions for storing infrastructure state
  • a vibrant and rising community

A Closer Look
anchor

Every Webiny project consists of four project applications:

  1. Core (apps/core/webiny.application.tsexternal link)
  2. API (apps/api/webiny.application.tsexternal link)
  3. Admin (apps/admin/webiny.application.tsexternal link)
  4. Website (apps/website/webiny.application.tsexternal link)

In the background, all of these applications are standalone Pulumi projectsexternal link, which essentially means two things.

  1. every project application contains its own infrastructure-related code (Pulumi programexternal link), configuration, meta, and state files

  2. upon fully deploying a Webiny project via the webiny deploy command, applications are deployed separately, one by one, in the same order as listed above

Cloud Infrastructure

Read more about the cloud infrastructure resources that get deployed into your AWS account in our Cloud Infrastructure key topics section.

When it comes to the cloud infrastructure (Pulumi) code that defines all of the required resources, note that all of it is abstracted away from users and maintained internally by the Webiny team. This way, users do not have to worry about the cloud infrastructure code, and can focus on building their applications.

If you are interested in seeing the actual cloud infrastructure code, you can find it in our GitHub repositoryexternal link.

Still, in some cases, users may need to modify the cloud infrastructure code. For example, when they want to add a new AWS resource, or modify an existing one. In such cases, users can do so by modifying the webiny.application.ts files located in the root of each project application.

To learn more about how to modify the cloud infrastructure code, please refer to the Modify Cloud Infrastructure article.

State Files and Different Backends
anchor

Pulumi state files describe at what state your cloud infrastructure is currently at. For example, it contains a list of all deployed resources, various metadata, configuration, and so on. State files are stored per Pulumi program stack, and by default, they are stored in the .pulumi folder, located in your project root.

Notice how in the .pulumi folder, the state files are organized per project application:

  • apps/core - Core project application’s cloud infrastructure state files
  • apps/api - API project application’s cloud infrastructure state files
  • apps/admin - Admin Area project application’s cloud infrastructure state files
  • apps/website - Website project application’s cloud infrastructure state files

While in some cases, like local development, storing state files locally may work for you, in others, you may want to store these in a remote storage.

This is where the concept of Pulumi backendsexternal link comes into play, which represent different storage services, that you can use for storing your state files.

For example, you can create a simple Amazon S3 bucket, and choose to store your files in it. You can also use the Pulumi Service, which, in addition to storing state files, also provides a couple of other cool features.

Learn more about state files and how to store them Cloud Infrastructure State Files article.

FAQ
anchor

Are You Using Pulumi's Automation API?
anchor

Currently, Webiny is not using the Automation APIexternal link. It’s actually using its own Pulumi SDKexternal link package, which is just a tiny wrapper over Pulumi CLI. Essentially, it enables programmatic use of the Pulumi CLI, which is similar to what the Automation API is also doing.

Is It Possible to Use a Different Infrastructure-as-Code Solution?
anchor

Switching to a different infrastructure-as-code (IaC) solution would require a significant amount of work as it would involve rewriting almost all of the Webiny IaC code from scratch for a different IaC solution. Therefore, we do not recommend it.