Cloud Foundry Orgs and Spaces in Stackato 3.0
by Troy Topnik

Troy Topnik, January 20, 2014
Orgs and Spaces

An "organization" can be a number of things. In the corporate world it can mean a company, an association, a subsidiary, a deparment, a team, or really any functional grouping of people. A multi-national corporation will have a very different notion of how to group its employees than a ten-person startup. We want Stackato to work for as many of these groupings as possible.

Stackato 3.0 uses the new Organizations and Spaces permission model developed in Cloud Foundry v2, adding tremendous flexibility and fine-grained control over who gets to do what on a PaaS.

It's also one of the biggest conceptual differences between Stackato 2.10 and 3.0. To get up and running quickly on a new Stackato system, it's helpful to know how this new permission and ownership framework will affect how you work.

I'll cover the major differences between the old and new models, then describe one way you could set up the platform for use in a typical organizational structure.

Users don't have quotas, Orgs do

Stackato 2.10 had Users and Groups, both of which had quotas. Your user account would give you a certain amount of memory and a certain number of applications and service instances. Groups were similar, but the quotas were shared between all members of the groups. You could deploy applications and service instances under your own account, or any group you were a member of.

Organizations have Quota Definitions

With Stackato 3.0, users don't have quotas directly associated with their account. They are members of an Organization (org), which in turn is assigned a quota definition. The quota definitions are named sets of memory and service instance quotas (no more app quotas). Everyone in the org shares these quotas.

Apps and service instances belong to Spaces

Apps and service instances used to be owned by users or groups. Access to applications and service credentials was restricted to the user or group which deployed them. This has changed with the introduction of spaces.

Spaces own Apps and Service Instances

Spaces are sub-groups of orgs, and org members can be given access (as a Developer, Manager, or Auditor) to one or more of its spaces. Any member of the space can view apps in the web management console, but only members with the "Developer" role can deploy apps and provision service instances to the space.

Domains: Owned by Orgs, Assigned to Spaces

The new regime for domains and hostnames caught me by surprise when I first started looking into Cloud Foundry v2. Formerly, the system had a base domain and all applications pushed to it would get a virtual hostname on that default domain.

For example, if I pushed an app called "supercms" to an API endpoint of "", I'd end up with the URL "". It was great because it was simple, but it did mean that my virtual hostname had to be globally unique. If anyone else had pushed an app called "supercms" first, I'd have to choose a different application name (or at least map a unique URL to that app when deploying).

On the bright side, I could (as a regular end user) map my own domain name to the application (if the "Allow non-local URLs" option was enabled) and create a CNAME DNS record to point to the system.

With the new system, domains are controlled at the Admin and Org level, and users cannot map arbitrary URLs to their applications. Org managers configure domains for each org, and space managers map those domains to their spaces. Apps can only have URLs made up of a "route" (basically a virtual hostname - the app name, or another arbitrary string) and one or more of the domains mapped to the space.

Orgs own Domains

Upshot: Admins and org managers have ultimate control of the domains that the system will route. Developers and managers can specify the route portion of the URL, combined with one or more of the space's mapped domains.

Setting up Orgs, Spaces, and Domains

The Stackato VM starts you off with just one org, created when you first log in to the web console. The fully qualified system hostname becomes the domain for this initial org.


[Video: Organizations and Spaces in Stackato]


For a real production system, you'll need to set things up to allow for a little more flexibility. If you're setting up a system for a company with a number of distinct departments or subsidiaries, you'll probably want to create a number of orgs, with domains for each.

Before we do that though, we should probably modify the quota definitions (Settings > Quota Definitions) to match our system and projected usage. The default "paid" quota definition allots 200GB of memory and 500 service instances.

Quota Definitions

Avoiding overlapping domains

Next up are the orgs and their domains. Let's say our API endpoint is "". We want each org to have it's own subdomain (e.g. "", "", "", etc.). Before we create these domains, we need to remove the "*" domain that was created when we first launched the web interface (under Admin > Domains). We can't have overlapping domains; Stackato disallows this to prevent URL collisions between orgs and apps.

Adding an Organization

Adding the domain for an org

On creating a new org, you'll be prompted to create at least one space. However, first we're going to add a domain to our org by clicking the "+" on the Domains sidebar.

Adding a Domain

I've selected "Wildcard" which means any route (e.g. app name) can be added to this domain automatically to make the full URL. You can use this interface to specify full, non-wildcard URLs for specific apps.

So now, instead of having a "*" domain for all orgs on the system, the "webops" org has it's own separate domain.


[Free Download: Stackato Micro Cloud]


Setting up Spaces

With a domain in place, we should set up at least one space using the "+ Add Space" button.

There's a Cloud Foundry convention to use spaces called "dev", "test", and "prod" but the choice is yours. The names should signify some logical grouping of apps that suits the team's workflow.

New Space

We can now do the same for all of the other orgs we want to add to the system, then add users to each org, assigning the Manager role to at least one of them, which in turn can handle more fine grained configuration specific to the org. These managers can:

  • add registered users to the org
  • add spaces
  • add org members to spaces
  • add more domains (including "external" URLs)
  • edit or remove any of the above

Single-User Orgs

Notice anything regular end users can't do with the new system? I can think of two:

  • map external URLs to their applications
  • have personal usage quotas

If I'm running a public PaaS using Stackato, where "regular end users" are paying me directly to host their applications, I need a way to allow them to do these things or my hosting platform will suck.

There's a good way to do this: make each user the Manager of single-user org. Users get their own quota (you can even make different tiered quota definitions just for these) and can map whatever domains they have to applications hosted on the system.

There's an option in the Stackato data import tool to set up orgs like this automatically if you're moving from Stackato 2.10.

Subscribe to ActiveState Blogs by Email

Share this post:

Category: stackato
About the Author: RSS

As ActiveState's Technical Product Manager for Stackato, Troy Topnik is responsible for defining and prioritizing the product roadmap to build the best cloud platform for deploying applications. Since joining ActiveState in 2001, he has held roles in Technical Support, Training, and Technical Writing. He believes in documentation-driven development as a pragmatic path to a better user experience.