Start with the original site, that you wish to mirror. The original doesn't need to be in its final, perfected state, because any changes you make to its codebase can be propagated to its mirrors at any time.
Create a mirror
Open the project's actions menu, where you will see the three project duplication options listed, and select Mirror:
Add a subscription for the mirror
You will need to add a suitable subscription. Even though the mirror will always reflect the codebase of the original, it's a separate project. Its resources will be provided wholly separately, and billing will also be independent.
You will need to make sure that the new mirror has adequate resources allocated to it, and that if it depends on additional backing services (for example, Celery workers) that these are allocated too.
Important: the mirror must be in the same physical region as the original (e.g. EU or Germany for an original in the Germany region, or North America/United States for an original in North America). A mirror in a different region will fail to deploy.
Managing the mirror
In the Control Panel Dashboard for the mirror, you will find the usual options and controls, as well as the Test and Live servers, which can be deployed normally.
However, some options are not applicable, as these are determined only in the original site: Addons, Settings, Repository and so on (these are the options that are concerned with the project's codebase).
Rolling out code changes to the mirrors
All development for mirrored sites that involves changes to the codebase (i.e. anything that would be recorded in its Git history) is performed on the original.
The mirror adopts the image built for the original's Live environment. Thus both the Test and Live environments on all mirrors take their codebase from the Git branch used by the original site's Live environment. However, mirrors do not use the Git repository directly.
As soon as new commits appear on the branch and have been successfully deployed to the Live server of the original project, the Dashboard for the mirrors will indicate that new commits are available for deployment.
The mirror's Test and Live sites can then be deployed when required.
Mirrors can be very swift to deploy, as they will re-use the image built for the original project.
Deploying code changes en masse
Visiting each mirror and deploying the code changes may be feasible in some circumstances, but is not appropriate when a project has for example several hundred mirrors.
In this case, the changes can be deployed in bulk from the Mirrors view of the original.
This gives you an overview of all the project's mirrors, and their status, showing which have pending commits, the status of their Live/Test servers and so on.
The Deploy selection.. button will deploy the changes to the listed mirrors - and can handle deployment to hundreds of sites at once. However, it is recommended to keep the limit of five concurrent deployments - if more than this number are to be deployed at once, they will continue to be added to the queue until all have been processed.