feat: add ALLOW_SIGNUP + ALLOWED_EMAIL_* for self-hosted instances

[azaanaliraza]

What does this PR do?

Closes #930

Adds self-hosting friendly controls to disable or restrict new user signups on private/internal deployments.

Currently, anyone can create an account via the magic-link flow on self-hosted instances. This change gives administrators proper control:

• ALLOW_SIGNUP=false → completely disables new registrations
• ALLOWED_EMAIL_DOMAINS=company.com,example.org → restrict to specific domains
• ALLOWED_EMAILS=... → allow only exact email addresses

Why this approach?

• Simple environment variables (easy for self-hosters)
• UI is hidden when disabled
• Backend blocks account creation at the magic-link verification step (real security, not just UI)

Related Issue

Closes #930

Type of Change

• New feature (non-breaking change that adds functionality)

Changes Made

• Added ALLOW_SIGNUP, ALLOWED_EMAIL_DOMAINS, and ALLOWED_EMAILS to .env.example
• Updated frontend (apps/web/features/landing/i18n/en.ts) to conditionally hide signup text
• Added backend check in the magic-link verification flow to block new user creation when signup is disabled
• (Optional) Added basic email domain validation

How to Test

1. Set ALLOW_SIGNUP=true → normal signup via magic link should work
2. Set ALLOW_SIGNUP=false → "Sign up" text should be hidden and new registrations should return 403 Forbidden
3. Test with ALLOWED_EMAIL_DOMAINS and ALLOWED_EMAILS (if implemented)
4. Run make check-worktree → all tests should pass

Checklist

• I have run make check-worktree locally and tests pass
• If this affects UI, screenshots are included (optional)
• Updated .env.example
• Considered security implications for self-hosted users

AI Disclosure

AI tool used: Grok (xAI)
Approach: Used Grok to understand the magic-link flow, locate relevant files, and generate the backend check + frontend conditional. Manually verified and applied the changes in the worktree.

Screenshots (optional)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
multica-web	Ignored		Apr 15, 2026 5:18pm
multica-web-production	Ignored		Apr 15, 2026 5:18pm

[Copilot]

Pull request overview

Adds self-hosting controls to disable or restrict new user signups by configuration, enforcing restrictions in the auth flow and adjusting landing-page copy accordingly.

Changes:

• Added server-side gating in findOrCreateUser using ALLOW_SIGNUP, ALLOWED_EMAIL_DOMAINS, and ALLOWED_EMAILS, returning 403 for prohibited registrations.
• Updated landing-page English copy to reflect “Login” instead of “Sign up” when signups are disabled.
• Documented new environment variables in .env.example.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
server/internal/handler/auth.go	Enforces signup restrictions during user creation and maps prohibited signups to HTTP 403.
apps/web/features/landing/i18n/en.ts	Adjusts English landing copy based on a public env flag.
.env.example	Documents new self-hosting environment variables for signup control.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[sarices]

Thanks for working on this — overall this looks like a useful addition for self-hosted setups.

A few things stood out to me, though I may be reading parts of this wrong:

1. Env var naming might be slightly inconsistent
   I noticed .env.example documents ALLOW_SIGNUP, while the landing page copy seems to read NEXT_PUBLIC_ALLOW_SIGNUP.
   I might be missing some wiring elsewhere, but if not, it seems possible for the backend to block signup while the landing page still shows signup-oriented copy.

2. I may have missed the locale updates, but I only noticed changes in en.ts
   If this is intended to affect the landing copy more generally, it might also be worth checking whether zh.ts (or other locales) should be updated too.

3. I might be overlooking existing coverage, but I didn’t spot tests for the new signup-gating paths
   Especially cases like:

• new users being rejected when signup is disabled
• existing users still being able to log in
• allowlist behavior for domains / exact emails

Small implementation note:
Using the SIGNUP_PROHIBITED: string prefix works, but I wonder if a typed/sentinel error might be a bit easier to maintain long-term.

Happy to be wrong on any of the above — just wanted to flag them in case they’re helpful.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Signup gating (ALLOW_SIGNUP / ALLOWED_EMAIL_DOMAINS / ALLOWED_EMAILS) is new behavior but there are no handler tests asserting the expected 403 outcomes or the “existing users can still log in” path. Add tests covering: (1) ALLOW_SIGNUP=false blocks new user registration, (2) allowlist mismatch blocks new user registration, and (3) an existing user can still authenticate when signups are disabled.

[azaanaliraza]

Thanks for the detailed review! @sarices

Regarding tests:
I didn't add tests in this PR because this is my first contribution and the auth/magic-link tests are quite involved (they require mocking email sending + DB).

Happy to add them in a follow-up PR if you can point me to similar existing auth tests or give some guidance on the testing pattern used in this codebase.

I've addressed the other points:

• Added NEXT_PUBLIC_ALLOW_SIGNUP to .env.example
• Updated zh.ts with the same conditional logic
• Changed to typed SignupError as suggested

Let me know if you'd like me to proceed with adding basic tests now.