We recently shipped an updated growth chart in the Clerk Dashboard, giving better insight into your application’s growth—including detailed statuses like new, reactivated, retained, and even churned users.
Our latest upgrade goes a step further and now shows you exactly which users are part of those cohorts, enabling even more visibility into your application's growth and performance over time.
Note: The table of recent sign-ups has been replaced with user cohorts, providing a clearer and more detailed view of your users' activity.
Clerk is determined to become the best place for founders and builders to observe and understand their users. Head to the Overview section of the Clerk Dashboard to see it in action, and stay tuned for more.
Testing Tokens are now supported in production environments
Testing Tokens allow your automated tests to bypass Clerk's bot protections that might otherwise be triggered when interacting with Clerk-powered applications via automated browser agents. Previously, Testing Tokens were only for testing against Clerk development instances. With this update, Testing Tokens are now supported by Clerk production instances, allowing you to write tests against your production environment.
To make testing authenticated pages easier, the existing signIn test helper now allows authenticating a user directly by email address.
import { signIn } from'@clerk/testing/playwright'test('sign in',async ({ page }) => {awaitsignIn({ emailAddress:process.env.TEST_USER_EMAIL, page })// Navigate to a protected page for additional testingawaitpage.goto('/protected')})
To learn more about Testing Tokens, visit the documentation.
We're excited to announce that M2M tokens are now available in public beta, bringing secure authentication for communication between your backend services.
M2M tokens are designed specifically for authenticating requests between different machines within your backend infrastructure. Whether you're building microservices, background workers, or distributed systems, M2M tokens provide a secure way for your services to communicate with each other.
This is distinct from our other machine authentication offerings:
Create and configure machines directly from the Clerk Dashboard or via our API or SDKs. You have complete control over which machines can communicate with each other, allowing you to implement the principle of least privilege across your infrastructure.
Tokens can be customized with:
Custom claims to pass additional context between services
Configurable expiration times for enhanced security
Instant revocation when you need to immediately cut off access
Simple Integration
Creating and verifying M2M tokens is straightforward with our SDKs:
// Create a token on Machine Aconstm2mToken=awaitclerkClient.m2m.createToken()// Send authenticated request to Machine Bawaitfetch('<machine-b-url>', { headers: { Authorization:`Bearer ${m2mToken.token}`, },})// Verify the token on Machine Bconstverified=awaitclerkClient.m2m.verifyToken({ token })
Pricing
M2M tokens are free to use during the beta period. After general availability, they'll move to a simple usage-based pricing model. The pricing will be:
$0.001 per token creation
$0.0001 per token verification (for opaque tokens)
We'll provide usage stats, monitoring, and rate limiting in the Dashboard before the beta period ends, so you'll have complete visibility and control over your usage and costs. We're also planning to add support for JWT tokens before the beta period ends, which will only incur charges for creation, not verification.
Get Started Today
Ready to secure your backend service communication? Check out our resources to get started:
📖 M2M tokens guide - Complete walkthrough of creating machines and using tokens
💻 Example repository - See M2M tokens in action with two simple Express apps
We'd love to hear your feedback as you try out M2M tokens. Your input during the beta period will help us refine the feature and ensure it meets your needs. Have questions or suggestions? Reach out through our feedback portal or join the discussion in our Discord community.
Get started with Clerk authentication in Next.js apps using the shadcn/ui CLI
Clerk components are now available through the Clerk component registry, which is fully compatible with the shadcn/ui CLI. This integration brings the familiar shadcn add workflow to Clerk, making it easier than ever to add authentication to your Next.js applications with pre-configured components that match your shadcn/ui theme.
What's included
The Clerk component registry includes everything you need to get started with Clerk authentication in a Next.js project:
Complete quickstart setup - Layout, sign-in/up pages, middleware, and components
Individual components - ClerkProvider, authentication pages, and middleware
This initial release focuses on Next.js support. We're actively working on expanding the Clerk component registry to include components for other popular frameworks and meta-frameworks in the future. If you're interested in support for a specific framework, please let us know which one you'd like to see next!
We're excited to announce a new feature: you can now fetch all billing plans for your application directly from our Backend API via GET /v1/commerce/plans.
This gives you full flexibility to display your pricing plans however you'd like, whether it's a custom pricing page or a plan comparison chart tailed to your users.
To demonstrate what's possible in the latest Next.js versions we've put together an example that utilizes this new endpoint and renders a "cached" pricing table that is SEO-friendly and revalidates on demand.
Checkout the GitHub repo or execute the command below to clone it.
For new applications created after August 5, 2025, the allowlist and blocklist will only apply to sign ups. Previously, these lists affected both sign ups and sign ins. For existing applications, your settings remain unchanged, but you can opt in to the new behavior anytime from the Clerk Dashboard under Settings > User & Authentication > Restrictions.
Why the change?
The allowlist and blocklist are designed to control who can create accounts, not manage existing users. Because blocking sign ins does not affect existing sessions, it was a half-measure to blocking access and often caused confusion. It also made challenging to block access to identifiers moving forward, without affecting existing accounts. If you need to completely revoke a user's access, you should use the ban feature instead, which will immediately end their active sessions and prevent them from signing in again.
