How to Make My App Invite-Only
Make your app invite-only by generating unique invitation codes or links, validating them at signup, and disabling public registration. You can implement this with Supabase RLS + an invitations table, Clerk allowlists, or a simple invite code check in your auth flow.
Why this matters
Invite-only access lets you control who joins your app — essential for closed betas, curated communities, and B2B tools where you want to onboard users gradually. It reduces spam signups, lets you gather focused feedback, and creates a sense of exclusivity that drives demand.
What's at stake
Without access control, anyone can sign up and overwhelm your early product with noise. An uncontrolled launch can flood support, expose unfinished features, and dilute the feedback that matters most during your critical early phase.
Step by step.
Decide on your invitation model
Choose between admin-generated invite codes, referral links from existing users, or an email allowlist. Admin codes give you full control over who joins. Referral links enable organic growth. Email allowlists work well for B2B or team-based apps.
Create an invitations table or allowlist
Set up a database table to store invitation codes with fields for the code itself, the invited email (optional), whether it has been used, and an expiration date. Make codes unique, single-use, and time-limited to prevent abuse.
CREATE TABLE invitations (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
code TEXT UNIQUE NOT NULL,
email TEXT,
used BOOLEAN DEFAULT false,
created_at TIMESTAMPTZ DEFAULT now(),
expires_at TIMESTAMPTZ DEFAULT now() + INTERVAL '7 days'
);Disable public registration
Turn off open signups so only users with valid invitations can create accounts. Redirect the signup page to show a "Request Access" or "Enter Invite Code" form instead of the standard registration form.
Validate invite codes at signup
When a user enters an invite code, verify it exists, has not been used, and has not expired. If valid, mark it as used and proceed with account creation. If invalid, show a clear error message.
const { data: invite } = await supabase
.from('invitations')
.select('*')
.eq('code', inviteCode)
.eq('used', false)
.gt('expires_at', new Date().toISOString())
.single();
if (!invite) {
throw new Error('Invalid or expired invite code');
}
// Mark as used after successful signup
await supabase
.from('invitations')
.update({ used: true })
.eq('id', invite.id);Build an admin panel to manage invitations
Create a simple admin interface where you (or authorized users) can generate new invite codes, see which codes have been used, revoke unused codes, and track who joined through which invitation. This gives you visibility and control over your growth.
Plan your transition to open registration
Invite-only is usually a phase, not a permanent state. Decide your criteria for opening up — a user count target, product stability milestone, or feedback threshold. When ready, enable public signup and optionally keep invite codes as a referral mechanism.
Launch with confidence using controlled access
- Readiness checks that verify your access control is properly configured
- Builder log to document your invite-only strategy and launch phases
- Public channel showing your intentional approach to growth
Keep learning.
Related guides
Frequently asked questions.
The simplest approach is an email allowlist: maintain a list of allowed emails and check against it during signup. With Clerk, this is built-in (enable Allowlist in Restrictions). With Supabase, create an allowed_emails table and validate before account creation. This takes under an hour to set up.
Invite codes are better for viral growth — users can share them with anyone. Email allowlists are better for controlled B2B onboarding where you know exactly who should have access. Many apps start with an email allowlist for beta, then switch to invite codes for broader launch.
Make codes single-use and time-limited (7 days is a good default). Optionally tie codes to specific email addresses so they cannot be shared. Rate-limit code generation to prevent bulk creation, and monitor usage patterns for anomalies.
Yes. Create an invitations table with RLS, add a database function or Edge Function that validates invite codes during signup, and mark codes as used after successful registration. You do not need a third-party auth provider — Supabase Auth plus a custom validation step is enough.
Common triggers include: reaching your target beta user count (usually 50-200), achieving a product stability milestone, getting consistent positive feedback, or hitting infrastructure readiness. Plan the transition before launch so you have clear criteria rather than guessing.