How dFlow is structured

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

Top-level mapCopy Anchor Link

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 layerCopy Anchor Link

• 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 livesCopy Anchor Link

• 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.

See alsoCopy Anchor Link

• 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.