Cloud.gov Platform Concepts

Overview

Cloud.gov uses Cloud Foundry's organizational model to provide multi-tenant isolation and resource management. Understanding these core concepts—organizations, spaces, buildpacks, and targets—is essential for effectively deploying and managing applications. This hierarchical structure enables proper access control, resource allocation, and application isolation required for federal compliance.

Key Concepts

1. Organizations

Organizations ("orgs") provide the top-level boundary for resource management and access control. Each agency typically has one or more organizations based on their structure.

Organization Features

• Resource quotas (memory, services, routes)
• User management and role assignments
• Billing aggregation
• Security boundaries

Working with Organizations

# List your organizations
cf orgs

# View organization details
cf org YOUR-ORG-NAME

# Target an organization
cf target -o YOUR-ORG-NAME

2. Spaces

Spaces exist within organizations and provide environments for deploying applications. Use spaces to separate development stages or projects.

Recommended Space Structure

For production systems:

• development - Developer integration environment
• staging - Pre-production testing
• production - Live customer-facing systems

For prototypes:

• One space per project (e.g., analytics-tool, public-website)

Space Management

# Create a space (requires Org Manager role)
cf create-space SPACE-NAME

# List spaces in current org
cf spaces

# Target a space
cf target -s SPACE-NAME

3. Roles and Permissions

Cloud.gov implements role-based access control at organization and space levels:

Role	Level	Permissions
Org Manager	Organization	Create/delete spaces, manage billing, assign roles
Org Auditor	Organization	View org information, users, and quotas
Space Manager	Space	Manage space settings and roles
Space Developer	Space	Deploy apps, manage services, view logs
Space Auditor	Space	View space information and settings

Customer Responsibility: Assign roles following least privilege principles:

# Assign org role
cf set-org-role USER-EMAIL ORG-NAME OrgManager

# Assign space role
cf set-space-role USER-EMAIL ORG-NAME SPACE-NAME SpaceDeveloper

# View assignments
cf org-users ORG-NAME
cf space-users ORG-NAME SPACE-NAME

4. Buildpacks

Buildpacks detect application frameworks and configure runtime environments automatically. Cloud.gov provides standard buildpacks with security updates.

Standard Buildpacks

• staticfile_buildpack - HTML/CSS/JavaScript
• nodejs_buildpack - Node.js applications
• python_buildpack - Python/Django/Flask
• ruby_buildpack - Ruby/Rails
• java_buildpack - Java/Spring
• dotnet_core_buildpack - .NET Core
• go_buildpack - Go applications
• php_buildpack - PHP applications

Using Buildpacks

# Auto-detection (recommended)
cf push YOUR-APP

# Specify buildpack
cf push YOUR-APP -b python_buildpack

# Use custom buildpack
cf push YOUR-APP -b https://github.com/your-org/buildpack.git

Note: Standard buildpacks receive automatic security updates. When you use a custom buildpack, you're responsible for keeping your buildpack up-to-date and patching vulnerabilities in it

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.

5. Targets

The CLI maintains a "target" - your current organization and space context for commands.

# View current target
cf target

# Set target
cf target -o ORG-NAME -s SPACE-NAME

# Common workflow
cf login -a api.fr.cloud.gov --sso
cf target -o agency-org -s development
cf push my-app

Common Errors & Fixes

No Org Access

• Issue: cf orgs returns empty list
• Fix: Contact Org Manager to request role assignment

Cannot Create Space

• Issue: "You are not authorized" error
• Fix: Only Org Managers can create spaces

Buildpack Not Detected

• Issue: "Unable to detect buildpack" error
• Fix: Ensure project has standard framework files:
  • Node.js: package.json
  • Python: requirements.txt
  • Ruby: Gemfile

Wrong Target

• Issue: Apps deployed to wrong environment
• Fix: Always verify target before deployment:

  cf target
  # api endpoint:   https://api.fr.cloud.gov
  # org:            agency-org
  # space:          production

FAQs

Q: How many orgs and spaces can I have? A: Determined by your agency agreement. If you need more please contact support@cloud.gov.

Q: Can I move apps between spaces? A: You cannot move an app directly between spaces. You must deploy the app to new space, verify it works, and then delete the app from old space.

Q: Should I use custom buildpacks? A: Only when standard buildpacks don't meet requirements. Custom buildpacks require you to maintain security updates.

Q: How do I manage team access? A: Use cf CLI role commands or the dashboard for role management.

Q: What's the difference between org and space roles? A: Org roles apply across all spaces; space roles apply only to specific spaces.