Features / Access Control

Control who sees what.

Role-based access control, row-level security for tenant isolation, and field-level permissions for sensitive data. Define rules in code or configure them from the admin panel.

Overview

What it does

Nextly's access control system supports five rule types: public (anyone), authenticated (logged-in users), role-based (specific roles), owner-only (record creator), and custom (code-defined functions). These rules can be set per operation (create, read, update, delete) on each collection.

For code-first collections, you define access rules using simple booleans or access functions that receive the user and their roles. Functions can be synchronous or asynchronous. Call external services, check databases, or apply any custom logic. For UI-created collections, access rules are configured from the admin panel and stored in the database.

Field-level permissions let you control read and write access to individual fields per role. This is useful for hiding sensitive data like internal notes, salary, or API keys from unauthorized roles.

Role-Based Access (RBAC)

3 default roles: admin, editor, viewer. Role-based rules use OR logic, so a user with any of the allowed roles gets access.

Owner-Only Access

Restrict access to records owned by the current user. Configurable owner field (defaults to createdBy). Auto-applied to queries.

Field-Level Permissions

Control read and write access to individual fields per role. Hide sensitive data in components from unauthorized roles entirely.

Code + Database Hybrid

Define access rules in code for version-controlled collections, or configure them from the admin panel for UI-created collections.

Code Example

Access control in a collection

Set CRUD permissions with simple booleans or access functions that receive the user and their roles. Returntrue to allow,false to deny.

collections/posts.ts
import { defineCollection, text, select } from"@revnixhq/nextly/config";

export default defineCollection({
 slug:"posts",
 fields: [
  text({ name:"title", required: true }),
  select({
   name:"status",
   options: ["draft","published"],
  }),
 ],
 access: {
  // Anyone can read published posts
  read: true,

  // Only authenticated users can create
  create: ({ user }) => !!user,

  // Editors and admins can update
  update: ({ roles }) =>
   roles.includes("admin") || roles.includes("editor"),

  // Only admins can delete
  delete: ({ roles }) => roles.includes("admin"),
 },
});

Access functions receiveuser,roles,permissions,operation, andcollection. They can be async: call external services, check databases, or apply any custom logic.

Rule Types

Five access rule types

Choose the right rule type for each operation. UI-created collections use these storable rule types; code-first collections can use these or custom functions.

publicAnyone can access. No authentication required.
authenticatedOnly logged-in users can access.
role-basedOnly users with specific roles (OR logic: any matching role grants access).
owner-onlyOnly the document creator can access. Uses a configurable owner field (defaults to createdBy).
customReference to a code-defined function for complex logic. Code-first collections only.
Field Permissions

Down to the field level

Control read and write access to individual fields per role. Sensitive fields can be hidden from unauthorized roles entirely.

Field permission rules
// Hide salary from all non-admin roles
{
 roleId:"viewer",
 collectionSlug:"employees",
 fieldPath:"salary",
 action:"none", // No read or write access
}

// Allow editors to write to the phone field
{
 roleId:"editor",
 collectionSlug:"users",
 fieldPath:"profile.phone", // Dot notation for nested fields
 action:"write",
}

Field actions:read (can see, can't edit),write (can see and edit),none (completely hidden). Dot notation supported for nested field paths.

Reference

Default role permissions

RoleCreateReadUpdateDeleteNote
adminFull access (super-admin)
editorContent management, no deletions
viewerRead-only access
custom~~~~Defined per collection

= allowed, = denied,~ = defined per collection. The admin role has super-admin access that bypasses all checks.

Start building with Nextly

Free, open source, and yours to own. No sign-up required.

>_npx create-nextly-app@latest