Cloud Foundry Getting Started
A good cloud foundry getting started plan starts by setting up orgs, spaces, and user roles. You then log in with the command tool to push your first app to a space. Most teams rush this early step and hand out broad space roles to every builder. When roles are too wide, one mistake can break live apps or expose secret keys. How the cloud foundry getting started flow works Cloud Foundry groups all work into two main layers called orgs and spaces. An org holds apps, users, and quotas for a who
Foundry Getting Started: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A good cloud foundry getting started plan starts by setting up orgs, spaces, and user roles. You then log in with the command tool to push your first app to a space. Most teams rush this early step and hand out broad space roles to every builder. When roles are too wide, one mistake can break live apps or expose secret keys.
How the cloud foundry getting started flow works
Cloud Foundry groups all work into two main layers called orgs and spaces. An org holds apps, users, and quotas for a whole company unit or large group. Inside each org, teams create separate spaces for dev, test, and live work. This structure keeps test code away from live customer traffic.
Platform admins assign specific roles to each user at the org and space levels. Org managers set spending limits and add people to the main group. Space developers can push code, bind backing services, and read app logs in that space. Space auditors can only view app status and resource use without making changes.
Once roles are set, a developer logs in through the command line tool. They pick an org and a target space for their work. The platform checks their role and packs the source code into a runnable droplet. It then starts the app instances and routes web traffic to them right away.
How service bindings and app secrets work
Apps need databases, message queues, and storage to do useful work. Cloud Foundry handles these needs through a built-in service marketplace. A space developer picks a service plan and creates a new service instance. They then bind that service instance to their app within the same space.
When a binding happens, the platform writes database keys into an app variable. The app reads this variable at start time to talk to the database. This design saves time because builders do not paste keys into source code. Still, anyone with the space developer role can still read those raw variables.
Developers can also open a direct shell into a running app container. They use this shell to check files, run scripts, or test network links. From inside that container, the user can reach any bound database or internal service. Native roles do not restrict what happens inside that shell once it opens.
Foundry Getting Started: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native roles solve and what they miss
Native org and space roles do a great job of sorting out team duties. They stop a developer on one project from pushing code to another team's space. They also help admins track resource quotas across different stages of work. For basic app pushes, the built-in permission model is fast and clear.
The gap appears when engineers need to fix a broken app in a live space. To debug an issue, a user often needs the space developer role. That single role grants full power to read secret keys, stop apps, and open shells. The platform checks who can enter the space, but not what they do next.
Once a user has that role, they can run risky commands or query live data. Native audit logs show that a user opened an app shell or viewed variables. They do not record the exact database queries or shell commands run in flight. Teams also struggle to mask sensitive fields like emails, phone numbers, or card numbers.
Over time, too many people keep high permissions in live spaces just in case. Revoking these roles by hand after every fix takes too much admin effort. Teams need a safer way to handle live checks without handing out standing space roles.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between an org and a space?
An org is a top-level account shared by many users and projects across a business unit. A space sits inside an org and holds the apps and services for one stage.
Which role do I need to push an app in Cloud Foundry?
You need the space developer role in the target space to push code and bind services. Org managers and space managers cannot push apps unless they also hold the space developer role.
Why is the space developer role risky in live spaces?
The space developer role lets users read raw service keys and open direct container shells. It does not restrict individual commands or rewrite sensitive data fields during live debugging.