anchor.diff:  
   For more information, see [Diego Components and Architecture](./diego/diego-architecture.html).
   
  -#### <a id='cf-apps'></a>How Cloud Foundry Distributes Apps
  +#### <a id='cf-apps'></a>Distributing Apps
   
   To meet demand, multiple host VMs run duplicate instances of the same app. This means that apps must be portable. Cloud Foundry distributes app source code to VMs with everything the VMs need to compile and run the apps locally.
   
  
positive.code: - [Buildpacks](../buildpacks/index.html)
  - [How Apps Are Staged](./how-applications-are-staged.html)
  
  ### <a id='organize'></a> How Cloud Foundry Organizes Users and Workspaces
  
  This section describes authentication in Cloud Foundry.
  
  Cloud Foundry manages user accounts through two User Authentication and Authorization (UAA) servers, which support access control as OAuth2 services and can store user information internally, or connect to external user stores through LDAP or SAML.
  
  
negative.code: 
  For more information, see [Orgs, Spaces, Roles, and Permissions](./roles.html).
  
  ### <a id='resources'></a>Storing Resources
  
  This section describes how Cloud Foundry stores its resources.
  
  Cloud Foundry uses the git system on [GitHub](https://github.com/) to version control source code, buildpacks, documentation, and other resources. Developers on the platform also use GitHub for their own apps, custom configurations, and other resources. To store large binary files, such as droplets, Cloud Foundry maintains an internal or external blobstore. Cloud Foundry uses MySQL to store and share temporary information, such as internal component states.
  
  ### <a id='communicate'></a>Component Communication
  
  This section describes how Cloud Foundry components communicate with one another.
  
  