On VTEX IO, workspaces function similarly to Git branches with automatic rebase. Your work in development and production workspaces is always based on what's in the master workspace.

Below is an example to illustrate the behavior of apps when performing operations on workspaces.

Imagine there is a VTEX account with four identical workspaces:

• master: appA@1.x
• prod1: appA@1.x
• prod2: appA@1.x
• dev1: appA@1.x

The following sections present scenarios based on this example. Check what happens when you:

• Install an app on development or production
• Install an app on master
• Promote a workspace

Installing an app on a development or production workspace does not affect other workspaces.

Considering the given example, imagine the following actions:

• Installing appA@2.x on prod1
• Installing appC@2.x on prod2
• Installing appC@3.x on dev1

This would be the result:

• master: appA@1.x
• prod1: appA@2.x
• prod2:appA@1.x, appC@2.x
• dev1: appA@1.x, appC@3.x

When you install an app on the master workspace, it is installed on every workspace that does not have this app installed. If a workspace has the same app installed with another major version, the app version on this workspace is unchanged.

Considering the given example, imagine the following action:

• Installing appB@0.x on master

This would be the result:

• master: appA@1.x, appB@0.x
• prod1: appA@2.x, appB@0.x
• prod2:appA@1.x, appB@0.x, appC@2.x
• dev1: appA@1.x, appB@0.x, appC@3.x

When a production workspace is promoted to master, all the other workspaces are updated to reflect the changes seen in the promoted workspace.

Considering the given example, after promoting prod2 to master, this is the result:

• master: appA@1.x, appB@0.x, appC@2.x
• prod1: appA@2.x, appB@0.x, appC@2.x
• dev1: appA@1.x, appB@0.x, appC@3.x

After promoting a workspace, the name of the promoted workspace will not appear in the list of workspaces, since it became the new master workspace.