Radon Puts Node Authentication in Your Own Stack

Authentication often starts as a small task: add an email form, send a code, create a session, then add a social login. The trouble arrives later. The app now depends on a hosted identity service, its pricing model, its supported providers and its idea of how user records should work. Moving away can mean changing flows and asking users to sign in again.

Radon takes a different approach. It is a self-hosted authentication engine for Node applications. The core idea is simple: keep the auth code in your project, store identity data in your database, and connect the package to the email provider and framework you already use.

The problem Radon is trying to remove

Radon is aimed at developers who do not want authentication to become a permanent dependency on a hosted service. The developer describes it as open source and MIT licensed, with a free plan and a paid upgrade. The free plan is presented as a complete auth stack rather than a trial, while the upgrade adds additional authentication methods and team-oriented capabilities.

That ownership model is the product's main distinction. Radon does not ask you to create an account on a separate auth platform or configure a hosted dashboard. Your application runs the package, and your infrastructure carries the database, email delivery and uptime responsibilities. That can reduce vendor dependence, but it also means those responsibilities do not disappear. Self-hosting is a change in control, not a removal of operational work.

The package is built specifically for Node. That makes it relevant to founders and developers building Node APIs or web applications, including people who want a small amount of code rather than a separate auth console. It is not a general-purpose identity product for every backend ecosystem.

How the setup fits together

The landing page shows a three-part setup. First, you create a Radon instance and provide a database adapter, a session secret and the services needed for the auth methods you intend to use. The examples show PostgreSQL, though the page also names MongoDB, Prisma and Supabase adapters. Email delivery is supplied through a sender adapter, with an example using Resend.

Second, you mount a catch-all route through a framework helper. In the Next.js example, toNextHandler exposes the GET and POST handlers for the auth route. Radon says the same route covers email codes, OAuth callbacks and sign-out, rather than requiring separate hand-written endpoints for each flow.

Third, your application calls an auth method. The example uses verifyCode with an email address and code. On success, Radon handles the session cookie and returns a signed-in user result. The stated security primitives include password hashing with bcrypt, hashed codes and tokens, encrypted reversible secrets, constant-time comparison, and HttpOnly and Secure cookies. These are claims from the project rather than an independent security audit, so teams with serious compliance or threat-model requirements still need to review the implementation.

What it supports, and what that means

The basic plan covers email one-time codes, magic links, email and password login with reset, Google OAuth and stateless JWT sessions, according to the supplied materials. The paid upgrade adds the broader provider catalogue, passkeys, WebAuthn, two-factor authentication, phone or SMS OTP, refresh tokens, organisations, API keys, impersonation and GDPR export or deletion.

The provider story is deliberately broad. Radon says its OAuth2 and OpenID Connect engine supports 50 providers, including services such as GitHub, Google, Discord, Apple, Microsoft, Slack and Shopify. The appeal is consistency: providers are configured against the same engine instead of each requiring a separate integration pattern.

The package also claims seven database adapters, five email senders and ten framework integrations across its plans. That could make it easier to change a component later, since the advertised contract sits between Radon and the surrounding service. The important qualifier is that the application owner still has to configure credentials, maintain the infrastructure and understand each provider's requirements.

Who should use it

Radon makes the most sense for a developer or founder building a Node product who wants self-hosted auth, owns the deployment environment and is comfortable wiring together a database and email sender. It is also a reasonable fit for a small team that wants common flows such as passwords, magic links, OAuth and JWT sessions without building those pieces from scratch.

It is a poor fit for a team that wants a fully managed identity service, does not want to operate email delivery or database-backed sessions, or is building outside the Node ecosystem. The lack of a hosted control plane is central to Radon's appeal, but it is also a real limitation. You get control over the code and data, along with responsibility for updates, configuration, availability and security review.

Radon is therefore best understood as infrastructure you own, not authentication you outsource. Its value depends less on the number of providers than on whether your team wants that trade: more control and portability in exchange for more of the work.