Add comprehensive multi-user support specification and implementation plan

[Copilot]

Summary

Provides complete technical specification and phased implementation plan for multi-user support in InvokeAI. Enables multiple isolated users per instance with secure authentication, role-based access control, and shared collaboration features.

Documentation deliverables (65K+ words, 2,600+ lines) organized in docs/multiuser/:

Architecture

• Authentication: JWT tokens with optional server-side tracking, bcrypt password hashing, 24h/7d sessions
• Roles: Admin (full system access) vs User (isolated workspace)
• Data isolation: Database-level user_id filtering across all resources
• Sharing: Granular board permissions (read/write/admin)
• Audit logging: Authentication events and admin actions

Database Schema

• 4 new tables: users, user_sessions, user_invitations, shared_boards
• 5 modified tables: Add user_id FK to boards, images, workflows, session_queue, style_presets
• Migration: migration_25.py with rollback support, backward-compatible 'system' user
• Flexible data migration: Administrator can specify arbitrary user account for legacy data

API Changes

• 15+ new endpoints: /auth/login, /auth/setup, /users/*, /boards/{id}/share
• All existing endpoints: Add authentication middleware, user context filtering
• Backward compatible: Auth not required when auth_enabled: false

Frontend

• New components: Login page, admin setup dialog, user management panel, sharing controls
• Auth state: Redux slice for user/token management, protected route wrappers
• UI updates: User menu, model manager restrictions, queue filtering by user

Implementation Timeline

14-week phased approach:

1. Database schema (2w)
2. Auth service + API (4w)
3. Multi-tenancy updates (3w)
4. Frontend auth + UI (3w)
5. Testing + security review (2w)

Security

• Password strength validation
• Rate-limited login attempts
• Role-based access control on all endpoints
• Database-level data isolation
• Audit logging for auth events and admin actions
• Comprehensive security testing plan (SQL injection, XSS, CSRF, session hijacking)

Migration Path

• New installs: Admin setup on first launch
• Existing installs: Auto-migrate DB, admin chooses destination user for existing data
• Legacy mode: Optional auth_enabled: false for single-user deployments

Design Decisions (Approved)

• OAuth2: Future enhancement (not in initial release)
• Email/SMTP: Optional - fallback to showing setup links in admin UI when not configured
• Session storage: JWT tokens with optional server-side session tracking
• Audit logging: Enabled for authentication events and admin actions

Related Issues / Discussions

Enhancement request for multi-user support to replace discontinued enterprise edition features.

QA Instructions

This is a specification-only PR. Review documents in docs/multiuser/ directory in order:

1. EXECUTIVE_SUMMARY.md - Quick overview with architecture diagrams and approved design decisions
2. specification.md - Complete technical specification with design decisions section
3. implementation_plan.md - Step-by-step implementation guide

Key review points:

• Authentication approach (JWT + bcrypt with optional server-side tracking)
• Database schema changes (4 new tables, 5 modifications)
• Role model (Admin/User initially, extensible)
• Security considerations and audit logging
• Timeline and phasing (14 weeks estimated)
• Optional email/SMTP configuration
• Flexible migration approach for existing installations

Documentation formatting: All documents follow mkdocs material theme requirements with proper blank lines before ordered lists.

Merge Plan

No code changes - documentation only. Safe to merge when approved. Implementation begins in Phase 2 with database schema.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable) - N/A, specification only
• ❗Changes to a redux slice have a corresponding migration - N/A, specification only
• Documentation added / updated (if applicable) - 4 comprehensive specification documents in docs/multiuser/
• Updated What's New copy (if doing a release after this PR) - N/A, no user-facing changes yet

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[enhancement]: Add multiuser support to InvokeAI</issue_title>
<issue_description>### Is there an existing issue for this?

• I have searched the existing issues

Contact Details

No response

What should this feature add?

Overview

This feature will allow a single running instance of InvokeAI to support multiple isolated users, each with their own generation settings and image boards. Upon opening the new multi-user version, a user will be prompted for their username and password. They will then have access to Invoke's image generation, editing, canvas, and workflow functions. Each user will have their own Boards of generated images and assets. These will be isolated from each other, but there will be an option for an administrator to create shared boards that all users can read and write to.

Users will not be able to add or delete models, change server-side settings in the invoke config file, or make other significant changes that would be visible to other users.

An administrator mode will give designated administrative user(s) access to all of InvokeAI's features, including the ability to add and remove models, create shared folders, and administer users.

Administration

Upon the very first launch of InvokeAI, an Administrator setup mode dialog appears that prompts the user for an administrator name and password. These are to be stored in the invokeai config file using a password hashing scheme. The setup can be reinitialized by removing the administrator username and password manually from the config file.

The administrator has the ability to create, manage and delete ordinary users, as well as to grant selected users administrative privileges. The user interface for adding users prompts for the new user's email address. When a new user is added, a one-time login link is sent to them via email. The login link is then used by the user to set up their account.

The administrator has the ability to change a user's permissions. They can:

1. Change their name and email address.
2. Send a change-password link in the event the user has forgotten theirs.
3. Give the user Administrative privileges.
4. Add the user to a Group for future team/enterprise features.
5. View, pause and cancel queued generation sessions created by ordinary users.

Discussion point Would it be better to use OAuth2, OpenID and/or Google Identity Services for the authentication steps?

Users

Users must log in with a valid username and password in order to access InvokeAI. Once logged in, they can:

1. Create, edit and delete Image Boards.
2. Upload assets into boards
3. Use all of the image generation tools in the linear, canvas, upscale and workflow tabs.
4. Create, edit, save and load public workflows as well as their own custom workflows.
5. Adjust local preferences, such as night mode, hotkeys, and other UI settings.
6. View the generation queue and edit sessions that they created. They are not allowed to cancel or otherwise alter sessions created by other users.
7. Log out, returning to the login dialogue.

Users cannot add, delete or edit models. The model tab should be dimmed out for ordinary users.

Alternatives

None. These were part of the features offered by the enterprise edition, which is no longer supported.

Additional Content

No response</issue_description>

<agent_instructions>Please turn this issue into a more detailed specification and a draft plan for implementation for human review.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes [enhancement]: Add multiuser support to InvokeAI #1

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[lstein]

@copilot Thank you for your excellent work on this request. I have reviewed the detailed specification and executive summary and have the following answers to the Open Questions in the specification:

1. OAuth2Priority -- make this a future enhancement
2. Email requirement -- make this optional, as many administrators will not have ready access to an outgoing SMTP server.
3. Data migration -- during data migration allow the administrator to specify an arbitrary user account to hold the legacy data. The admin account can be used for this purpose if the administrator wishes it.
4. API compatibility -- add auth to all APIs, but do not require auth if multiuser support is disabled.
5. Session storage - JWT tokens with optional server-side session tracking
6. Audit logging - yes, log authentication events and admin actions.

Please update the specification and other docs appropriately. To keep these documents together, please put them in a subfolder of the docs directory named multiuser. Also be aware that the mkdocs material theme requires a blank line before its ordered lists. Instead of:

### 4.2 Initial Administrator Setup
**First-time Launch Flow:**
1. Application detects no administrator account exists

there needs to be a blank line before the start of the list, as in:

### 4.2 Initial Administrator Setup
**First-time Launch Flow:**

1. Application detects no administrator account exists

[Copilot]

@copilot Thank you for your excellent work on this request. I have reviewed the detailed specification and executive summary and have the following answers to the Open Questions in the specification:
...

Updated in commit 34a1c27. All changes implemented:

✅ Design decisions documented - Section 19 updated with all approved answers
✅ Docs moved to docs/multiuser/ - Clean organization with simplified filenames
✅ Markdown formatting fixed - Blank lines added before all ordered lists for mkdocs material theme
✅ Configuration updated - Added audit logging config options, clarified optional email
✅ Migration flexibility - Administrator can now specify arbitrary user for legacy data

Key updates:

• OAuth2 → Future enhancement (Phase 2)
• Email/SMTP → Optional with UI fallback
• Data migration → Admin chooses destination user
• API auth → Required but respects auth_enabled: false
• Sessions → JWT with optional server-side tracking
• Audit logging → Auth events and admin actions enabled

[lstein]

Good plan.