API, CLI, and Admin Reference
Reference overview
Who this section is for: API shape, CLI reality, server actions, tRPC, and operator-only paths without cluttering onboarding.
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. |
| Application / environment actions | Applications, Environments, and related dashboard reads. |
| 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. |
| dFlow MCP server | MCP at /api/mcp: base URL, OAuth 2.0 setup, client examples, and tools. Its own top-level section in the sidebar. Production: https://app.dflow.sh/api/mcp. |
Conventions in this section
- Server action names match the
actionNamemetadata in code (for examplecreateServiceAction). 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 isgetActionAccessin the monorepo. - Product navigation uses Applications and Environments. A Payload
projectscollection may remain only for leftover CMS cleanup.
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.