Here’s an overview of key cloud.gov terms and concepts. cloud.gov uses Cloud Foundry terms, so the Cloud Foundry glossary is a helpful reference too.
Your work inside cloud.gov takes place within organizations, or “orgs” for short. Orgs group together users for management and present a shared perimeter for services, domains and quotas. When your account is created, it may already have permissions in an existing org.
List available orgs
This only displays orgs where you’ve been assigned an org role, or those which contain a space where you’ve been assigned a space role.
See details about a specific org
…including quotas, routing domains and which spaces it includes:
cf org ORGNAME
Target an org
In order to work with spaces, you’ll need to do this first:
cf target -o ORGNAME
Each org contains spaces, which can contain applications. Applications in the same space share a location for app development, deployment, and maintenance.
For orgs that contain production systems (or systems under development before release), we recommend setting up spaces to correspond to each environment, such as
production. If you have a prototyping org that contains many prototypes, each space may correspond to a project (such as
To create a space:
cf create-space SPACENAME
Note: To create a space within a given org, you must have the
OrgManager role. You can see which users are managers for your org with:
cf org-users ORGNAME
The Cloud Foundry CLI keeps a global state of the organization+space you’re interacting with. This is known as the “target”, and you can set it with:
cf target -o ORGNAME -s SPACENAME
All apps need to use a “buildpack” specific to their language, which sets up dependencies for their language stack. There are standard buildpacks for most languages, and Cloud Foundry usually auto-detects and auto-applies the appropriate one when you deploy an app (one exception is that it doesn’t auto-apply the special binary buildpack). We strongly encourage you to use the standard buildpacks. cloud.gov supports these standard buildpacks and provides security updates for them. (You’ll need to redeploy or restage your application to pick up buildpack updates. You’re also responsible for supporting and security-patching the application itself.)
In the rare case where Cloud Foundry doesn’t correctly auto-detect the buildpack, or if you want to use a binary buildpack or custom buildpack, you can specify a buildpack in the application manifest (as below) or with the
-b flag. To reference a buildpack in a manifest, you may specifying using a name:
buildpacks: - python_buildpack
Or with a URL:
buildpacks: - https://github.com/cloudfoundry/ruby-buildpack.git
Multiple languages: If your application requires multiple languages, we recommend evaluating these strategies to simplify your application:
- Can you split your project into smaller applications that work together, so that you can use one language for each application and deploy each one separately?
- Can you initiate long-running processes or schedule periodic jobs from outside your application using the Tasks capability?
- Can you build your static assets using CI prior to pushing your application, so that only the final built assets are deployed on cloud.gov?
If none of these strategies will help you deploy single-language applications, you can explicitly specify a set of buildpacks to run in sequence, one for each language.
Custom buildpacks: If your application can’t use a standard buildpack, you can use a custom buildpack. When you use a custom buildpack, you’re responsible for keeping your buildpack up-to-date and patching vulnerabilities in it. See this chart illustrating your responsibilities for more detail.