Architecture
dFlow anatomy: Application, Environment, and Service — and how Deployments and Worker Nodes fit.
dFlow’s UI and docs use the same product model. Learn it once here; other pages assume these names.
Organisation
└── Application
└── Environment ← Worker Nodes attach here
└── Service ← app, database, Docker, …
└── DeploymentApplication
An Application is the product or system you deliver. It groups
Environments, holds shared settings, and is usually named after the product
(for example checkout-api or marketing-site).
Create one with Create New Application — see Getting Started.
Environment
An Environment is a stage inside an Application — commonly production,
staging, or development. Configuration, domains, and Worker Nodes attach
here so stages stay isolated.
A Worker Node attaches to a single Environment. That 1:1 binding gives you resource isolation between stages (for example staging vs production) and efficient usage of each node’s capacity for the workloads in that Environment only.
The create-application wizard provisions a default production Environment for you during the compute step.
Service
A Service is a runnable unit inside an Environment: web app, API, database, Docker image, or similar. Builds, variables, scaling, and routing are per Service. Each release creates a Deployment.
How the pieces relate
| Layer | Job | Typical question |
|---|---|---|
| Application | Product boundary | “What are we shipping?” |
| Environment | Stage + compute | “Where does this stage run?” |
| Service | Workload | “What process or datastore is this?” |
| Deployment | Release instance | “What version is live right now?” |
| Worker Node | Capacity | “Which machine backs this Environment?” |