Open Source
A transparent, MIT-licensed Lightning login system you can read, run, and adapt.
What This Page Is For
This page is here to give you a clear, non-technical-first overview of how the Key-Rex codebase is structured, what is actually open source, and what kind of data the system uses. If you are a developer, you can drill into the file and directory references. If you are less technical, you can still get a high-level understanding of how things work and where to look if your team needs more detail.
Everything described here reflects the current implementation of Key-Rex (including the admin dashboard, analytics, documentation, and public pages). Outdated parts of the earlier prototype (like the original onboarding flow and old subscription system) have been removed from both the product and this page.
Repository & License
The complete Key-Rex source code is available in our public repository. All code is released under the MIT License, which means you can use, modify, and distribute it freely.
Source Code Repository
The full Key-Rex codebase is available on GitHub. You can browse the code, review the implementation, fork it for your own use, or contribute improvements.
Note: Repository link will be added when the GitHub repository is created. For now, the source code is available through the hosted Key-Rex service.
License File
The complete MIT License text is included in the LICENSE file in the repository root. Once the repository is available, you can view it directly there.
The license grants you permission to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, subject to including the copyright notice and license text in any redistributed copies.
License
Key-Rex is released under the MIT License.
In practical terms, MIT means you can:
- Use the code in your own projects (commercial or non-commercial)
- Modify it to fit your needs
- Fork it, host it yourself, or build your own version
- Bundle it into a broader product you sell
The main requirement is that if you redistribute the code (for example, in your own open source project or product), you keep the original license text and copyright notice.
You are not required to give Key-Rex credit when you use the code, but it's appreciated if you do.
What Is Open Source in Key-Rex?
Key-Rex is designed as a fully open-source application. The same code that powers the public website, customer dashboard, admin dashboard, and embed script is available in this repository.
That means you (or your developers) can:
- Inspect all authentication logic (including LNURL-auth and signature checks)
- Review how domains, analytics, and settings are stored and used
- See exactly what data is collected and how it flows through the system
- Understand the admin tools and how they aggregate system-wide metrics
There are no hidden proprietary services, closed-source “black box” enforcement modules, or secret tracking libraries injected at runtime. When in doubt, you can always search the code under the app/, components/, and lib/ directories to see exactly how something works.
Data Collection & Privacy
This section focuses on what the Key-Rex service itself uses in order to run. For a more policy-focused explanation, see the Support page. Here we focus on how it shows up in the code.
What Key-Rex Does Not Track for Your Visitors
- No email addresses or names from your end users
- No marketing pixels or behavioral tracking scripts
- No browser fingerprinting or device IDs for visitors
- No IP address storage for your end users' sign-ins
What Key-Rex Does Use
- xpub (extended public identifier) – a deterministic identifier derived from a wallet's public key, used as the "username" for authentication.
- Site ID – a unique ID that ties your Key-Rex account to the embed script on your site.
- Allowed domains and verification status – the list of domains that are permitted to use your Key-Rex integration. Production domains require DNS TXT record verification to prove ownership before authentication works. Test domains (localhost, *.test, staging.*) are automatically verified.
- Analytics metrics – counts of logins and high-level patterns (e.g., per domain, per wallet type, browser/device categories, day-of-week, new vs returning).
- Account-owner metadata – when you accept the disclaimer or submit the contact form, the code captures IP address and user agent for audit/support purposes.
All of this behavior is implemented in first-party code under lib/storage.ts, lib/db.ts, and various API routes in app/api/. There are no hidden third-party analytics SDKs.
Where Things Live in the Code
If you (or your developers) want to understand or audit a specific part of Key-Rex, this high-level map shows where to start. It is not an exhaustive per-file listing, but it covers the main areas most people look for.
Core App & Public Pages
Dashboard & Admin
Authentication & Embed
APIs & Storage
Security & Utilities
Configuration & Meta
Running Key-Rex Yourself
Many open source projects include a "how to run this yourself" section. Key-Rex is no different – you can run the full stack locally or deploy your own instance if you want complete control.
- Clone the repository and install dependencies (see
README.md). - Run the development server (usually
npm run dev). - Set any required environment variables (for example,
ADMIN_XPUBfor admin login). - In production, set
DATABASE_URLto your PostgreSQL connection string and runnpx prisma migrate deployto initialize the database. - Deploy to your preferred host (Vercel, your own infrastructure, etc.).
⚠️ Important: Known Limitations for Production Use
The current implementation includes some simplified implementations that work for development and basic use, but should be enhanced for production deployments:
- Database: Uses PostgreSQL via Prisma ORM. Connection pooling may need tuning for serverless environments (e.g., Vercel). See
lib/db.tsfor the current pooling configuration. - Signature Verification: Uses production-grade libraries (
@noble/secp256k1andelliptic) with support for both compact and DER-encoded signatures. Consider reducing verbose debug logging inlib/auth.tsfor production. - xpub Derivation: Uses a simplified derivation method. For production, consider implementing proper HD wallet derivation if you need to link multiple keys from the same wallet.
These limitations are documented in DEPLOYMENT.md. Review and address these before deploying to production.
Self-hosting is optional and requires engineering time. For most sites, using the hosted Key-Rex service is simpler, but the open source code is there if you ever need to move or customize.
Security & Vulnerabilities
Security is a priority for Key-Rex. If you discover a security vulnerability, we appreciate responsible disclosure so we can address it before it becomes public.
Security Policy
A detailed security policy is available in the SECURITY.md file in the repository root. This file follows GitHub's standard security policy format and provides complete details on how to report vulnerabilities.
If you find a security vulnerability in Key-Rex, please report it privately rather than opening a public issue. This gives us time to fix the issue before it's disclosed publicly.
Security Email: Please use the contact form on our website with "SECURITY" in the subject line, or email us directly at the address below.
Note: Security email address will be added when available. For now, please use the contact form with "SECURITY" in the subject line.
What to Include in Your Report
- Description of the vulnerability and potential impact
- Steps to reproduce the issue (if applicable)
- Affected versions or components
- Suggested fix (if you have one)
Our Commitment
We commit to acknowledging receipt of security reports within 48 hours and providing an initial assessment within 7 days. Critical vulnerabilities will be prioritized for immediate attention. We will work with you to coordinate public disclosure after the issue is resolved.
Contributing & Reporting Issues
At this stage, Key-Rex is focused on being a reliable, understandable reference implementation. Contribution guidelines are available in the CONTRIBUTING.md file in the repository (when available). If you are interested in contributing, auditing, or suggesting improvements, you can:
- Review the public code and raise questions through the contact form on the website.
- Fork the project and maintain your own internal version if you have very specific needs.
- Share feedback on documentation gaps or confusing areas so the public pages and dashboard docs can be improved.
- Check the
CHANGELOG.mdfile for version history and recent changes.
Third-Party Dependencies
Key-Rex uses several open source libraries. Key dependencies include:
- Next.js & React - Web framework and UI library
- Prisma & @prisma/client - Database ORM and PostgreSQL access layer
- @noble/secp256k1 - Cryptographic signature verification
- bech32 - LNURL encoding/decoding
- qrcode - QR code generation for mobile authentication
See package.json for the complete list of dependencies and their licenses.
Over time, more formal contribution guidelines (pull requests, coding standards, security disclosure process) can be added. For now, the priority is clarity and auditability for people deciding whether to trust Key-Rex as their Lightning login layer.