While for performance reasons you may want OpenStack project's services to live on different machines, this is not always practical. For example, in small deployments there might be too few machines available, or a limited number of public IP addresses. Components from different OpenStack projects are not necessarily engineered to be able to be co-located, although many users report success with a variety of deployment scenarios. The following is a series of pointers to be used when co-location of services from different OpenStack projects on the same machine is a must: Ensure dependencies aren't in conflict. The OpenStack Continuous Integration team does attempt to ensure there is no conflict, so if you see issues during package installation, consider filing a bug. Monitor your systems and ensure they are not overloaded. Some parts of OpenStack use a lot of CPU time (such as Object Storage Proxy Servers), while others are I/O focused (such as Object Storage Object Servers). Try to balance these so they complement each other. Beware of security. Different parts of OpenStack assume different security models. For example, OpenStack Object Storage (Swift) assumes the storage nodes will be on a private network and does not provide additional security between nodes in the cluster. Ensure the ports you are running the services on don't conflict. Most ports used by OpenStack are configurable.