Editor Accounts

This page helps you put authentication in the right place before you build around it.

Dyrected has two kinds of login, and they never mix:

• Editor login controls who can enter the dashboard: owners, teammates, clients, editors, and administrators.
• Application-user login controls who can sign in to your product: customers, members, and anyone else your app authenticates. You add it with an auth collection.

Both Dyrected Cloud and self-hosted Dyrected support both kinds. The difference is who manages editor login. On Cloud, Dyrected manages dashboard access for you. Self-hosted projects manage it themselves.

Editor login is workspace access

Think about Dyrected Cloud the way you would think about a managed content workspace. You invite the people who should edit content, publish changes, manage media, and work inside the CMS. Dyrected handles access to that workspace and the hosted content backend behind it.

Use Cloud workspace access for:

• site owners who manage the content workspace
• clients and editors who update approved content
• team members who need dashboard access
• workspace access to the hosted content API and media library

Editors sign in through Dyrected Cloud. You do not create passwords for them in your own schema.

Application-user login on Cloud

Mark any collection in your schema with auth: true and it becomes a login collection for your application, on Cloud as well as self-hosted. Cloud keeps that collection as you defined it, including its access rules, and does not mix it with the dashboard.

// dyrected.config.ts
import { defineCollection } from "@dyrected/core";

export const Customers = defineCollection({
  slug: "customers",
  auth: true,
  fields: [{ name: "name", label: "Name", type: "text" }],
});

Application-user login uses the same auth collection model, endpoints, and user object in access rules as self-hosted Dyrected. The collection auth endpoints, request shapes, and SDK methods are documented in Operations.

How Cloud picks the dashboard collection

Cloud has to decide which collection in your schema represents dashboard accounts. It checks in this order and uses the first match:

1. A collection with the slug __admins.
2. The collection named by adminAuth.collectionSlug, if it exists in your schema.
3. The first collection in your schema that has auth enabled.

The collection Cloud picks is replaced with a Cloud-managed one. Its slug becomes accounts, its access becomes admin-only, and its roles options become admin, editor, viewer, and owner. Your other fields on it are kept.

Add an __admins collection with auth: true, and Cloud always uses it. Every other auth collection then stays an application-user collection:

export const Admins = defineCollection({
  slug: "__admins",
  auth: true,
  fields: [{ name: "name", label: "Name", type: "text" }],
});

Cloud still manages who can sign in to the dashboard. The __admins collection only tells Cloud which collection should carry that role and field shape.

What a Cloud handoff should prove

Before inviting a client or teammate, make sure one real content edit already flows from Dyrected Cloud into the frontend. That is the handoff signal that matters.

The first handoff usually looks like this:

1. Create or connect the Cloud site.
2. Sync the schema so the hosted content backend knows your collections and globals.
3. Confirm the frontend can read published content.
4. Invite the editor or client into the Cloud workspace.
5. Ask them to make one safe edit and confirm it reaches the site.

Use Handing Off to Editors for the full onboarding checklist.

What stays in your application

Auth collections give you accounts and login. They do not replace the rest of your product. Keep these in your app or the system built for them:

• payments, checkout, carts, and orders
• subscriptions and billing
• tenant membership and product-specific permissions beyond what your access rules express

If you already use an identity provider for your product, you can keep using it. Auth collections are an option, not a requirement.

Where to go next

• Operations — every auth endpoint with its request and response shape
• Handing Off to Editors — invite people into the right editing path
• Cloud vs Self-hosted — compare runtime boundaries
• Cloud-safe access control — write content rules that run in Cloud