Infrastructure > Pulumi IaC
Infrastructure as Code With Pulumi
Learn what is Pulumi and how Webiny is utilizing it with your project applications.
- what is Pulumi
- how is Webiny utilizing Pulumi with your project applications
- what are state files
- what are backends
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:
- Core (
apps/core/webiny.application.ts
) - API (
apps/api/webiny.application.ts
) - Admin (
apps/admin/webiny.application.ts
) - Website (
apps/website/webiny.application.ts
)
In the background, all of these applications are standalone Pulumi projects, which essentially means two things.
every project application contains its own infrastructure-related code (Pulumi program), configuration, meta, and state files
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
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 repository.
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
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 filesapps/api
- API project application’s cloud infrastructure state filesapps/admin
- Admin Area project application’s cloud infrastructure state filesapps/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.
Learn more about state files and how to store them Cloud Infrastructure State Files article.
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.