User Accounts

A complete user dashboard is available for your users to manage their account.

Features

Account & Profile Management

Personal Info: Update name, email, and other details.
Profile Picture: Frictionless uploader. Users can drop any image; the system handles resizing and optimization.
Preferences: Users can set their preferred language and interface theme (Light/Dark).
Notification Preferences: Users can choose which optional email notifications they receive. See the Notification Preferences documentation.

Security

Password: Ability to update the password (or create one, if the user created their account using an external provider or previously chose to use magic links).
Two-Factor Authentication: Enable/disable 2FA.
Sessions: View and manage active sessions across devices.

Account Data Export

Users can export personal data linked to their account directly from the profile area. This feature is designed to support GDPR workflows, especially data access and portability requests.

The export is delivered as a compressed .zip archive.
The archive includes a JSON data export with account, activity, security, communication, authorization, and billing data.
If the user has uploaded a profile photo, that file is included in the archive under profile-photo/.
The export format is structured and machine-readable, making it suitable for GDPR data portability responses.
Sensitive one-time secrets and credentials (tokens, OTP codes, recovery codes, session payloads, etc.) are redacted in the exported JSON.
A fresh authentication confirmation is required before download for security.

Usernames

You can enable the username feature, allowing each user to choose a unique username, using the I_S_ENABLE_USERNAMES environment variable:

.env

I_S_ENABLE_USERNAMES=true

When validating usernames, the default disallowed words list (config/disallowed_usernames.csv) will be used, unless you create a CSV file at config/env/disallowed_usernames.csv with your own list.

Billing Portal

A secure link redirects users to the billing portal of the payment provider (Stripe or Paddle) to manage their subscriptions and invoices.

More information in the Billing documentation.

Case-insensitive emails

Email addresses are treated as case-insensitive by most providers. Enforcing case-insensitive comparisons prevents duplicate user accounts (e.g. John@ vs john@) and ensures consistent authentication across different database systems.

In our database migration for the users table, the email column is configured to behave case-insensitively (when available for your current database) across different database engines, ensuring consistent uniqueness checks and authentication behavior.

PostgreSQL: when available, we use the citext type, which performs case-insensitive comparisons at the database level.
MySQL / MariaDB: we explicitly set a case-insensitive collation. We prefer utf8mb4_0900_ai_ci (Unicode-based, case- and accent-insensitive) when available, and fall back to utf8mb4_unicode_ci otherwise.
SQLite: use COLLATE NOCASE for basic ASCII case-insensitive comparisons.
Other databases or when unavailable: we use the default string type and rely on their default behavior.

This approach aligns behavior across databases as much as possible without requiring application-level normalization, while remaining compatible with a wide range of setups.