> For the complete documentation index, see [llms.txt](https://docs.umbraco.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.umbraco.com/umbraco-deploy/13.latest/deployment-workflow/deploying-deletions.md). # Deploying deletions How deleting meta data and files work in Umbraco Deploy With Umbraco Deploy deletions are environment specific. This means that in order to delete something entirely from your project, you need to delete it on all environments. In this article you can read about the correct way of deleting files, schema and content when using Umbraco Deploy. When you are using Umbraco Deploy, you might have more than one environment - including a local clone of the project. These environments each have their own database. The databases will contain references to all of your content and media, as well as to all of your schema files (e.g. Document Types, Templates etc). The databases are environment specific. When you deploy from one environment to another, Umbraco Deploy will compare incoming schema files with references to these in the databases using both *alias* and *GUID*. If something doesn't add up - e.g. there is a mismatch between the database references and the files deployed - you will see an error. Learn more about this in the [Troubleshooting section](/umbraco-deploy/13.latest/troubleshooting.md). The workflow described above does not pick up deletions of content and schema from the database, which is why you'll need to delete the content and/or schema on all your environments, in order to fully complete the deletion. For schema, Umbraco Deploy can remove the database entries that no longer have a corresponding UDA file. Cleaning is an explicit operation or an opt-in setting, so nothing is deleted without a decision on each environment. See [Cleaning schema](#cleaning-schema) for details. The main reason Umbraco Deploy does not delete schema and content on deployments, is because it could lead to unrecoverable loss of data. Imagine that you delete a Document Type on your Development environment, and push this deletion to your production environment where you have a lot of content nodes based on the deleted Document Type. When the deployments goes through, all of those content nodes would be instantly removed with no option to roll back as the Document Type they are based on no longer exists. To avoid anyone ending up in this unfortunate situation, deletes are not automatically handled and will require an active decision from you on each environment in order to take place. ## Example scenario Let's say you've deleted a Document Type on your Development environment, and now you want to deploy this deletion to the production environment. Before you deploy the changes, in Git it will show that the following changes are ready to be committed and deployed: ![Changes ready for deployment](https://867571021-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FB2rzIQJQmJxHBEdpijuR%2Fuploads%2Fgit-blob-222348d67d21e60b619056d5450ac149c45cf46f%2Fdeletions-of-doctype2.png?alt=media) Commit the changes and push them to your repository and trigger a deployment to your environment. Once the deployment is complete, you will notice the following: * The Document Type you deleted on Development is still present in the backoffice on the production environment. You might wonder why the Document Type that you have deleted, is still there. The reason is, that deploy only deletes the associated UDA file, and not the actual Document Type in the database. In order to completely delete the Document Type from your entire project, you need to delete it from the backoffice of any of the other environments you have as well. When the Document Type has been deleted from the backoffice of all environments and no UDA file exists, you can consider it completely gone. Instead of deleting the Document Type in the backoffice, you can [clean the schema](#cleaning-schema) on the production environment. Deploy then deletes the Document Type, because its UDA file no longer exists. You should however keep in mind that if you at any point during the process, save your Document Type again, a UDA file will be regenerated and when you start deploying changes between environments, this will likely end up recreating your deleted Document Type. ## Which deletions are deployed? Every **file** that's deleted, will also be deleted on the next environment when you deploy. However, there are some differences depending on what you have deleted. Here's an overview of what happens when you deploy various deletions to the next environment. ### Deleting Schema (Document Types, Datatypes etc.) Deleted: * The associated `.uda` file. Not deleted: * The entry in the database. * The item will still be visible in the backoffice. ### Deleting a Template Deleted: * The associated `.uda` file. * The associated `.cshtml` file (the view file). Not deleted: * The entry in the database. * The template file will be empty, but still be visible in the backoffice. ### Deleting files (css files, config files etc.) As these are **only** files, everything will be deleted on the next environment upon deployment. ### Deleting content and / or media Content and media deletions will not be picked up by deployments and will have to be deleted on each environment you wish to delete the content or media on. To reduce the risk of accidental deletions, restrict the delete permission for the relevant user groups using [granular Document permissions](https://docs.umbraco.com/umbraco-cms/manage-and-publish-content/users-and-members/users#granular-permissions). ### Deleting backoffice languages Deleted: * The associated `.uda` file Not deleted: * The entry in the database * The language will still be visible in the backoffice/content dashboard (for multilingual content) Deleting the language in the backoffice on the target environment will ensure the environments are in sync. ## Cleaning schema Schema deletions leave database entries behind, as described above. Umbraco Deploy 13.4 and later can remove these entries for you. Deploy compares the schema in the database with the UDA files on disk and deletes the items without a matching file. Cleaning applies to all schema types managed by Deploy, including Templates and Languages. You can clean the schema in two ways: * **Manually**: Run the **Verify and Clean Schema** operation from the [Deploy Dashboard](/umbraco-deploy/13.latest/deployment-workflow/deploy-dashboard.md#verify-and-clean-schema) on the environment you want to clean. The Schema Comparison table on the same dashboard shows which items are missing a file. * **Automatically**: Set the [`PostDeploySchemaOperation`](/umbraco-deploy/13.latest/getting-started/deploy-settings.md#post-deploy-schema-operation) setting to `CleanSchema`. Deploy then cleans the schema after every schema deployment to that environment. {% hint style="warning" %} Cleaning the schema deletes items. Deleting a Document Type also deletes all content using that type, with no option to roll back. Only configure `CleanSchema` on environments where this is acceptable, such as local or development environments. On production, run the operation manually after checking the Schema Comparison table. {% endhint %} Cleaning the schema does not affect content and media. Those deletions must still be made manually on each environment. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.umbraco.com/umbraco-deploy/13.latest/deployment-workflow/deploying-deletions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.