If you have ever logged into the SAP BTP cockpit, opened a subaccount, and wondered where exactly your app is supposed to live, you have run into the Cloud Foundry account model. Orgs, spaces, apps, services — the hierarchy looks simple on a diagram, but the first time you deploy something, the question always comes up: do I need a new org for this, or just a space?
Let us walk through it the way it actually works in practice, not just the way the documentation draws it.
What an org actually is
An org (short for organization) is the top-level grouping inside a Cloud Foundry environment on BTP. Think of it as a department or a business unit. It does not run anything by itself — no apps, no services, no routes live directly in an org. Its job is to contain spaces and to give you a boundary for billing, quotas, and access.
In a typical BTP setup, you get one org per subaccount in the Cloud Foundry environment. Most teams never create a second org. One is enough for the vast majority of projects, because the real isolation happens one level down.
The org is a billing and access boundary. The space is where work actually happens. If you remember only one thing from this post, make it that.
Spaces: where apps and services live
A space is the unit of deployment. Every app you push, every service instance you create, every route you map — all of it belongs to a space. When you run cf push, the app lands in whatever space you are currently targeting.
The standard layout that most SAP teams settle on looks like this:
org: mycompany-prod
├── space: dev ← developers push freely, experiments welcome
├── space: test ← QA validates, data refreshed from prod-like sources
└── space: prod ← locked down, deployments only via pipelineWhy separate spaces instead of separate orgs? Because spaces share the org's quota and service marketplace, which keeps things simple, while still giving you separate runtime environments, separate service instances (so your dev database is not your prod database), and separate user roles.
Roles: who can do what, and where
Cloud Foundry roles are assigned per org and per space, and the distinction matters.
Org-level roles are about administration: Org Manager (manages the org, invites users, assigns space roles), Org Auditor (read-only view of org usage), and Billing Manager (sees usage and invoices). In most SAP landscapes, only a handful of platform admins hold Org Manager.
Space-level roles are where daily life happens:
- Space Manager — invites users to the space, manages its roles.
- Space Developer — the workhorse role. Push apps, bind services, create routes, view logs. This is what every developer on the team needs.
- Space Auditor — read-only. Useful for security reviewers or external auditors who need visibility without the ability to break anything.
A common mistake: giving everyone Org Manager "to make things easier." Do not do that. Org Managers can delete spaces. Space Developer in dev, Space Auditor in prod — that is the shape of a sane setup.
Services, routes, and domains per space
A few things that trip people up:
Service instances are space-scoped. When you create a destination service instance or an XSUAA instance in the dev space, it does not exist in test or prod. You create one per space, usually with the same name so your mta.yaml stays identical across landscapes.
Routes are space-scoped too. Your dev app might live at myapp-dev.cfapps.eu10.hana.ondemand.com while prod uses a custom domain. The route belongs to the space, so there is no collision.
Quotas cascade. The org has a quota (memory, service instances, routes). Spaces can have their own sub-quotas carved out of it. If your dev space keeps hitting memory limits, check the space quota before assuming the org is full — someone may have capped dev to protect prod.
A practical example: targeting and deploying
Here is the everyday flow. You log in, target the right org and space, then push:
cf login -a https://api.cf.eu10.hana.ondemand.com
cf target -o mycompany-prod -s dev
cf push myappThe cf target step is the one people forget, and then they wonder why their app landed in the wrong space. Make it a habit to check cf target before every push — or better, let your CI/CD pipeline handle targeting so humans never have to think about it.
Keep service instance names identical across dev, test, and prod spaces. Your deployment descriptors stay the same, and promoting from one landscape to the next becomes a non-event.
When would you actually need a second org?
Rarely, but it happens. Separate orgs make sense when you need hard isolation: different cost centers that must be billed separately, a subsidiary with its own admins, or a strict regulatory boundary where even platform admins should not cross over. For 95% of SAP BTP projects, one org with well-designed spaces is the right answer.
Start with one org. Add spaces for your landscapes. Assign roles at the space level. Only reach for a second org when billing or compliance forces your hand — not before.