Infrastructure as Code With Pulumi

Why Pulumi?

For defining and deploying necessary cloud infrastructure Webiny relies on Pulumi, a modern infrastructure as code (IaC) 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

Every Webiny project consists of four project applications:

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

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

1. every project application contains its own infrastructure-related code (Pulumi program), 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

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.

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.

State Files and Different Backends

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 backends 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.

FAQ

Are You Using Pulumi's Automation API?

Currently, Webiny is not using the Automation API. It’s actually using its own Pulumi SDK 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?

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.