This section is for advanced readers and operators. It describes how the product is wired on the server side so you can reason about behaviour, security, and self-hosted operations. It is not part of the onboarding path.

If you are new to dFlow, start with How dFlow is structured under Core Concepts in the sidebar and the task guides under Getting Started.

What you will find here

Page — Purpose

• API overview — How HTTP surfaces are exposed (tRPC, Payload, webhooks). No separate public “customer REST API” for the dashboard.
• CLI overview — What exists today for CLI-style work (SSH, Dokku, Compose) versus a first-party dflow CLI.
• Authentication actions — Named server actions for sign-in, session, and related flows.
• Service actions — Server actions for Services, deploys, scaling, domains, backups, and related reads.
• Project / application actions — Legacy Projects, Applications, Environments, and unified deploy actions.
• Subscription and billing actions — Plan and Stripe-related tRPC routers plus the main subscription server action.
• tRPC and backend reference — Where tRPC lives, how it differs from Next.js Server Actions, and how to explore routers.
• Admin and advanced operations — Self-hosted control plane operations, operator-only actions, and Payload admin.

Conventions in this section

• Server action names match the actionName metadata in code (for example createServiceAction). They are implementation identifiers, not end-user features.
• RBAC in the dashboard maps many actions to permission keys such as services.read. The canonical map is getActionAccess in the monorepo.
• Legacy Projects still appear in code and permissions as projects.* while the UI moves customers to Applications.

See also

• Platform architecture (conceptual control plane and Worker Nodes).
• Roles and permissions (what members can do in the product).
• Troubleshooting overview when something fails in the field.