---
title: "Package structure and locations"
description: "Which parts of a live package you can change, and where a change must go to last."
product: "Alchemy"
edition: "Public"
type: "reference"
url: "https://docs.cloudhouse.com/public/managing-packages/package-structure-and-locations/"
---
# Package structure and locations

Two things decide what you can change in a live Cloudhouse Alchemy Compatibility Package, and whether the change lasts: which **part** of the Compatibility Package you are changing, and which **copy** of it you are changing.

Applies to: `Alchemy`

For the meaning of the terms used below, see [Terms Used in This Section](https://docs.cloudhouse.com/public/managing-packages/terms-used-in-this-section/index.md).

## Package Structure

The Compatibility Package has two parts, and the distinction between them is firm. It is not a matter of preference or support policy: one part can be changed and the other cannot.

| Part of the Compatibility Package | What it holds | Can you change it? |
|----|----|----|
| `ProgData` | The application's own files. The layout mirrors the paths the application occupies on a normal installation, so an application installed to `C:\Program Files\Example` appears under `ProgData\C\Program Files\Example` in newer Compatibility Packages, or `ProgData\Program Files\Example` in older ones built before the drive letter was carried. Application configuration files live here. | **Yes.** This is where a change that belongs inside the Compatibility Package is made. |
| The package root | The top level of the Compatibility Package: the `.xml` and `.clc` configuration files, and the Cloudhouse programs that deploy and run the application. | **No.** The configuration files here are covered by the package's licensing hash, so editing one invalidates the licensing tokens and the Compatibility Package stops working until Cloudhouse re-licenses it. Root changes come from us. |

!!! note

    Changing or replacing a file in an existing `ProgData` folder is straightforward. Adding a brand new file or folder under `ProgData` is different, because it may need a change to `Redirections.xml` before the application can see it. `Redirections.xml` is in the package root, so that part has to be done by Cloudhouse. Tell us before you add one and we will confirm whether it needs anything from us.

## Package locations

The Compatibility Package you deploy from and the copy that ends up on a machine are not the same thing, and the difference decides whether a change lasts.

| Copy | What it is | What happens to a change made here |
|----|----|----|
| The base package | The master, undeployed copy you keep and deploy from. | It reaches every machine deployed from that point on, and survives redeployment. |
| A deployed copy | What exists on one machine, created from the base package at the time it was deployed. | It applies to that one machine only. It is lost when that machine is redeployed, updated or rolled back, and no other machine ever receives it. |

!!! note

    A change that belongs inside the Compatibility Package must be made in the base package, not only in the deployed copy on a machine. A change made only in a deployed copy is undone the next time that machine is redeployed, and no machine deployed afterwards receives it.

## Related pages

- [Terms Used in This Section](https://docs.cloudhouse.com/public/managing-packages/terms-used-in-this-section/index.md) — definitions of the terms used above.
- [Changes You Can Make](https://docs.cloudhouse.com/public/managing-packages/changes-you-can-make/index.md)
- [Updating a File Inside the Package](https://docs.cloudhouse.com/public/managing-packages/updating-a-file-inside-the-package/index.md)
- [Changes Cloudhouse Must Make](https://docs.cloudhouse.com/public/managing-packages/changes-cloudhouse-must-make/index.md)