dFlow separates what you ship (applications and services) from where it runs (environments and worker nodes).

Top-level map

Organisation └── Application ← product boundary, settings, default environment └── Environment ← compute attachment, isolation between stages └── Service ← runnable unit (app, database, docker, …) └── Deployment ← concrete release of that service 

How to think about each layer

• Organisation: Tenant boundary for billing, members, and shared settings.
• Application: The product or system you are delivering; groups environments.
• Environment: A target context such as production or staging; compute is attached here.
• Service: A specific workload (web app, API, database container, etc.).
• Deployment: An instance of a service configuration at a point in time.

Where configuration lives

• Application-level settings apply across environments unless overridden.
• Environment-level choices include which worker nodes back the environment.
• Service-level settings cover build sources, env vars for that service, scaling, and routing for that unit.

Legacy Projects

The Applications hub replaces legacy Projects for new work. Existing legacy Projects remain available while you migrate. Read Legacy Projects vs Applications for the mapping, then follow Migrate from legacy Projects to Applications under Migration and Release Notes in the sidebar when your team is ready.

See also

• Applications: product boundary and environments.
• Environments: isolation and compute attachment.
• Services: runnable units and deployments.
• Organisations and tenants: workspace and access scope.
• Platform architecture: control plane, Worker Nodes, proxy, builds, monitoring.