Warning
You're browsing the documentation for an old version of Webiny. Consider upgrading your project to Webiny 5.41.x.
What you’ll learn
  • how to destroy cloud infrastructure previously deployed for project applications (possibly into multiple environments)

ThedestroyCommand
anchor

This command lets you destroy cloud infrastructure previously deployed within a project application.

As its first argument, the destroy command receives the path to the project application folder. You also need to specify the environment into which the cloud infrastructure was previously deployed, which is specified via the --env argument.

The following destroy commands destroy cloud infrastructure deployed for four project applications, all previously deployed into the dev environment:

To fully destroy your project, you can also run the command without specifying the project application folder:

Note that, upon doing this, the command will ask for a confirmation of the environment you wish to destroy, via the --confirm-destroy-env flag.

Debugging
anchor

If you run into an error while running the webiny destroy command, to get additional information and logs about it, you can append the --debug argument. For example:

This can significantly help in debugging underlying deployment (Pulumi) errors, since without it, in some cases the returned error report doesn’t contain enough useful information. We’ve also seen cases in which the report would actually be misleading and even incorrect, making the debugging process much harder for the user.

FAQ
anchor

How Do I Destroy Cloud Infrastructure Resources Deployed Into theprodEnvironment? I'm Receiving a Warning About Protected Cloud Infrastructure Resources.
anchor

When deploying into the prod environment, some of the cloud infrastructure resources that Webiny deploys for you as part of the Core project application are marked as protectedexternal link.

The protect option marks a resource as protected. A protected resource cannot be deleted directly. Instead, you must first set protect: false and run pulumi up. Then you can delete the resource by removing the line of code or by running pulumi destroy. The default is to inherit this value from the parent resource, and false for resources without a parent.

Within a Webiny project, note that the pulumi up and pulumi destroy commands are run via the webiny deploy and webiny destroy commands, respectively.

So, in order to destroy all cloud infrastructure resources deployed into the prod environment, we need to first pass protect: false upon calling the createCoreApp function in apps/core/webiny.application.ts:

Once that’s in place, run the webiny deploy command to apply changes, and finally, run the webiny destroy to destroy everything:

Once that has been destroyed, you can proceed with destroying the rest of the project applications, which do not contain any protected cloud infrastructure resources.

Troubleshooting
anchor

Upon Destroying My Webiny Project, I've Received a "PreconditionFailed" Error Message. What Can I Do?
anchor

On multiple occasions, we’ve seen users receive the following error upon destroying their Webiny project:

As we can see, the error is related to deleting an Amazon Cloudfront distribution that’s deployed as part of the Website project application.

As mentioned in this GitHub issueexternal link, this error can happen because of the fact that many operations within AWS silently mutate Cloudfront distributions’ ETAGexternal link. This causes the subsequent update (delete) attempts to fail.

Ultimately, this issue can be resolved by refreshing your Pulumi state files, by running the following command:

Destroying My Project Takes a Long Time to Finish.
anchor

We’re aware of this fact, and this is mainly because of the Amazon ElasticSearch Serviceexternal link. While other cloud infrastructure resources get destroyed reasonably fast, this service can take anywhere from 15 to 30 minutes to destroy itself. In rare cases, we’ve even seen the service still present in user’s account for daysexternal link.

Unfortunately, this is a well-known issue for quite some time, and until the present, there haven’t been any positive improvements.