Members & Roles

​

Overview

Stardeck provides flexible access control that separates who can manage your project from who can use your deployed application. You can define custom roles and permissions tailored to your application’s needs, invite users with specific roles, and control exactly what each user can do.

​

Access Level Hierarchy

​

Organization Members

Users who are part of your organization automatically have full access to all projects within that organization. They can:

• Manage project settings and code
• Deploy and publish changes
• Invite additional project members
• Access all deployments with all permissions (or a specific role you configure)

​

Project Members

You can invite specific users to individual projects. There are two types:

• Project Editors — Team members who can manage the project in Stardeck (code, settings, deployments)
• Deployment Users — End-users who can only sign in to your deployed application

​

Public Pages (Default)

By default, anyone on the internet can access the public pages of your deployed application without signing in. Your application code controls which routes are public.

​

Project-Level Roles

​

Project Editor

Project Editors have full control over the project within the Stardeck platform:

• Modify project settings and configuration
• Access and edit the codebase
• Deploy changes
• Invite and manage other project members
• Sign in to the deployed application (with a configurable role)

Use cases: External developers, freelancers, partner agencies collaborating on your project. To add a Project Editor:

1. Go to Settings → Project Members
2. Enter their email address
3. Click Add Member

​

Custom Roles & Permissions

For your deployed application’s users, Stardeck lets you define custom roles and permissions that match your application’s access control needs. Instead of being limited to “Admin” and “User”, you can create roles like “Moderator”, “Editor”, “Viewer”, or whatever fits your use case.

​

How It Works

1. Permissions define what actions a user can take (e.g., “Admin Panel Access”, “Content Editing”)
2. Roles are collections of permissions that you assign to users (e.g., “Moderator” gets “Content Editing” but not “Admin Panel Access”)
3. Each user in your deployed application is assigned exactly one role

​

Creating Permissions

Permissions represent specific capabilities in your application.

1. Go to Settings → Roles & Permissions
2. Under Permissions, click Add Permission
3. Enter a Name (e.g., “Admin Panel Access”) — a key is auto-generated from the name
4. Optionally add a Description
5. Click Create

The permission key (e.g., admin-panel:write) is what your application code uses to check access. Keys must be lowercase and can contain letters, numbers, hyphens, underscores, and colons.

​

Creating Roles

Roles group permissions together and are what you assign to users.

1. Go to Settings → Roles & Permissions
2. Under Roles, click Add Role
3. Enter a Name (e.g., “Moderator”) and optionally a Description
4. Click Create
5. Click Edit Permissions on the new role to assign permissions using the checkboxes

Every project starts with two default roles: You can modify these, add new roles, or create entirely different ones.

​

Default Role

One role is marked as the Default role. This is the role automatically assigned to new users who sign up through your deployed application. By default, the “User” role is the default. To change the default role, create or select the role you want as the default when configuring roles. The default role cannot be deleted.

​

Collaborator Role

The Collaborator Role setting controls what deployment role organization members and project editors receive when they access your deployed application.

• All permissions (default) — Collaborators get every permission defined in the project
• Specific role — Collaborators get a specific role’s permissions (e.g., “Admin”)

To configure this:

1. Go to Settings → Roles & Permissions
2. Under Collaborator Role, select the desired role from the dropdown

​

Managing Deployment Users

Deployment users are the end-users of your deployed application. You manage them separately from project editors.

​

Inviting Users

1. Go to Settings → Deployment Users
2. Enter the user’s email address
3. Select a role from the dropdown
4. Click Invite User

The user will receive an email invitation. They can accept it to create an account and sign in to your application with the assigned role.

​

Changing a User’s Role

You can change a deployment user’s role at any time:

1. Go to Settings → Deployment Users
2. Find the user in the Active Users list
3. Select a new role from the dropdown next to their name

The change takes effect on their next sign-in.

​

Pending Invitations

The Pending Invitations section shows invitations that haven’t been accepted yet. You can:

• Resend an invitation if the user didn’t receive it
• Revoke an invitation to cancel it

​

Removing Users

To revoke a user’s access:

1. Go to Settings → Deployment Users
2. Find the user and click Remove
3. Confirm the removal

The user will immediately lose access to your deployed application.

​

Enabling Public Sign-Ups

To allow anyone to sign up for your deployed app:

1. Go to Settings → Authentication
2. Enable Allow Sign-Ups
3. Configure your preferred sign-in methods

New users who sign up will automatically receive the default role. See User Authentication for detailed configuration options.

​

Agent & Chat Versioning

The Stardeck agent can create and modify roles and permissions during agent mode runs. When you ask the agent to set up access control for your application, it edits the role and permission configuration files in your project. When the agent commits these changes, roles and permissions are automatically synced to your project’s database. These changes are tied to chat versioning — each commit is linked to a specific chat message, so you can see exactly when and why roles changed. If you revert to a previous chat version, the role and permission configuration reverts along with the rest of your code.

​

Understanding the Access Flow

​

Public vs. Authenticated Access

Public Pages (No Sign-In Required)

• By default, anyone can visit your deployed application’s public pages
• No authentication needed for marketing pages, landing pages, or public content
• Your application code controls which routes are public

Authenticated Access (Sign-In Required)

• Custom roles and permissions control what each signed-in user can do
• Different roles provide different levels of access within your app

​

How Access is Determined

When someone tries to access your project or application, Stardeck checks access in this order:

1. Project-Level Access (Stardeck Platform)
   • Organization members can manage all projects in their org
   • Project Editors can manage the specific projects they’re invited to
2. Deployment-Level Access (Your Live Application)
   • Users sign in with their assigned custom role
   • Their permissions determine what features they can access
   • Organization members and project editors use the configured collaborator role
3. User Sign-Ups (Optional)
   • When enabled, new users can create accounts
   • They automatically get the default role
   • See User Authentication for configuration options

​

Common Scenarios

​

Scenario 1: SaaS with Admin and Regular Users

Situation: You’re building a SaaS product where some users need admin access and others are regular users. Solution:

• Create an “Admin Panel Access” permission and a “User Access” permission
• Create an “Admin” role with both permissions
• Create a “User” role with only “User Access” (mark as default)
• Enable sign-ups — new users automatically get the “User” role
• Manually invite administrators with the “Admin” role

​

Scenario 2: Content Platform with Multiple Access Levels

Situation: You’re building a content platform with viewers, editors, and moderators. Solution:

• Create permissions: “Content Read”, “Content Write”, “Content Moderate”, “User Management”
• Create roles:
  • Viewer — “Content Read” only (mark as default)
  • Editor — “Content Read” + “Content Write”
  • Moderator — “Content Read” + “Content Write” + “Content Moderate” + “User Management”

​

Scenario 3: Client Application with Operator Access

Situation: You’ve built a booking system for a client. The client needs to manage bookings but shouldn’t access Stardeck. Solution:

• Invite the client as a Deployment User with the “Admin” role
• They can sign in to the deployed app with full permissions
• They cannot access the Stardeck platform or modify code
• Their customers sign up with the default “User” role

​

Scenario 4: Agency Managing Multiple Client Projects

Situation: Your agency manages projects for multiple clients. Developers need full access, clients only need to use their deployed app. Solution:

• Add developers as organization members (full access to all projects)
• Invite each client as a Deployment User to their specific project with the “Admin” role
• Clients manage their deployed application
• Clients cannot access other projects

​

Frequently Asked Questions

​

Can I add someone who’s already in my organization as a project member?

Organization members automatically have access to all projects with full privileges. You don’t need to add them as project members. Their deployment role is controlled by the Collaborator Role setting.

​

What happens if I delete a role that has users assigned to it?

You cannot delete a role that has active members. Reassign those users to a different role first.

​

Can I delete the default role?

No, the default role cannot be deleted. You can change which role is the default, then delete the previous one (as long as no users are assigned to it).

​

What’s the difference between a Project Editor and a Deployment User?

• Project Editor: Can manage the project in Stardeck (code, settings, deployments) AND access the deployed app
• Deployment User: Can ONLY sign in to the deployed application, cannot access Stardeck

​

Can a Deployment User see my code or project settings?

No. Deployment Users can only sign in to your deployed application. They cannot access the Stardeck platform, your code, or any project settings.

​

How do I check a user’s permissions in my application?

Your application receives the user’s role and permissions when they sign in. You can check permissions to show or hide features, protect routes, or control access to specific functionality.

​

Can the agent set up roles for me?

Yes. You can ask the Stardeck agent to create roles and permissions for your application. The agent will configure the role and permission files, and changes are automatically synced when committed. These changes are versioned with your chat history.

​

Next Steps