Free trials just got more flexible! You can now choose whether users need to provide a payment method before starting their trial.
Previously, all free trials required a payment method upfront. Now there's a simple toggle in your billing settings that lets you decide what works best for your business.
Remove Friction, Keep Control
By disabling the payment method requirement, this lets users begin their trial instantly, skipping payment details.
When enabled, you keep the previous behavior where payment methods are required upfront — useful for preventing trial abuse and ensuring smooth transitions to paid subscriptions.
Easy Configuration
Head to your billing settings in the Clerk Dashboard to find the new toggle.
Track your organization metrics with the same depth as user analytics
We're excited to announce that the Clerk Dashboard now includes comprehensive organization growth tracking. Just as you've been able to monitor user growth with detailed retention and churn metrics, you can now access the same level of insight for your organizations.
Organization Growth Chart
The new organization growth chart provides detailed breakdowns of your organization activity over time, tracking new, reactivated, retained, and churned organizations across each period
Note
An organization is considered active when 2 or more of its members have signed in during the selected time period.
Flexible Filtering
Organization growth data includes flexible time-based filtering options. You can analyze your data across different time periods to see daily active organizations, weekly active organizations, or monthly active organizations based on which interval you select. Customize date ranges to gain deeper insights into your organization adoption patterns and behavior over time.
Organization Cohort Table
Below the growth chart, you'll find a detailed organization cohort table that provides a granular look at individual organizations, their status, member counts, and creation dates. You can click directly on any segment of the chart above to filter the cohort table and view the specific organizations that make up that data point, making it easy to identify trends and investigate specific cohorts in detail.
This update brings parity between user and organization analytics, giving you a complete picture of growth across your application. Stay tuned for more planned improvements to organization insights!
See how different LLMs perform at writing Clerk-specific code
Clerk has launched the LLM Leaderboard, a transparent benchmark showing how different large language models (LLMs) perform when writing Clerk-specific code.
As more developers use AI assistants to build their applications, having clear, objective data on which LLMs are best at writing Clerk integrations helps developers choose the right AI tool for their projects.
How It Works
The leaderboard evaluates LLMs based on their ability to generate working Clerk integration code from simple, real-world prompts. Each model is tested using the same criteria and scenarios to ensure fair comparison.
Current tests focus on Next.js integrations, with plans to expand to additional frameworks and use cases over time.
View the Results
Check out the LLM Leaderboard to see the latest performance scores across popular models.
Get Involved
The eval suite is open source. To learn about the testing methodology, report issues, or if you want to contribute, visit the GitHub repository. If you want to get involved or provide feedback on how Clerk works with AI tooling, with us.
M2M tokens are now generally available, providing stable, production-grade authentication between your backend services.
We're thrilled to announce that the M2M Tokens feature has graduated from beta and is now Generally Available (GA)!
After months of real-world testing and feedback, the APIs are stable, performance has been refined, and M2M tokens are ready to power your production-grade backend services.
M2M tokens enable secure communication between your backend systems — from microservices and background workers to distributed systems — all with a straightforward and highly configurable authentication model.
What's New
Stable APIs for Production:
M2M tokens are now officially supported for production workloads. You can confidently build and deploy systems using the M2M API without worrying about breaking changes.
Usage Charts in the Dashboard:
Track your M2M token activity directly from the Clerk Dashboard. You can now monitor token creation and verification trends at a glance, helping you stay in control of your usage.
Pricing Reminder:
As shared during the beta, M2M tokens will use a simple usage-based pricing model:
$0.001 per token creation
$0.0001 per token verification (for opaque tokens)
Billing isn't live yet — we'll provide at least 30 days' notice before billing begins. We recommend familiarizing yourself with your usage via the new usage charts before billing starts to avoid any surprises.
What's Next
We're still just getting started with machine authentication. Next, we're working on M2M tokens as JWTs, allowing verification to happen locally — no network calls required. This will make M2M authentication even faster and more flexible across your infrastructure.
Get Started Today
Ready to secure your backend service communication? Check out these 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're grateful for all the feedback that shaped M2M through its beta period — and we can't wait to see what you build next. Have questions or suggestions? Reach out through our feedback portal or join the discussion in our Discord community.
Database migration, high-update to append-only, direct job queuing, and more
This post is part of a regular series where Clerk shares details about ongoing infrastructure improvements. These updates happen continually behind the scenes, and will not impact end-users beyond improving reliability and performance.
A migration of our Cloud SQL database within GCP’s network was completed to minimize latency between Cloud Run and Cloud SQL. It was performed by GCP to reverse a prior migration that had increased network latency.
Although the first migration was unnoticed except by our latency monitoring, the reversal was coincident with a “connectivity issue” that lasted 11 minutes. Thankfully, our session failover mechanism succeeded and prevented active users from being signed out. However, new sign ups, sign ins, and other account changes failed during this time.
We are awaiting a full root cause analysis from GCP to determine if the two events were related. We will share the analysis when it becomes available.
Once connectivity was restored, we verified that latency improved as expected.
Convert high-update workload to append-only
We had a particular high-update table that created undue stress on the database in periods of high activity.
We’ve replaced that high-update workload with an append-only workload. The change was carried out over the course of a week, where we incrementally enabled dual writes until we reached 100% of traffic, then leveraged dual reads over several days to ensure consistent behavior. Finally, we removed dual writes and now only leverage the append-only workload.
Direct queuing of background jobs
We leverage PubSub for background jobs. Many jobs require transactional guarantees, which we achieve by writing the job details to the database within a transaction. Others don’t, like non-essential jobs for analytics and telemetry.
Previously, all jobs were written to the database, regardless of if they required a transactional guarantee. Going forward, jobs that don’t require transactional guarantees will be queued directly to reduce the database load.
Database tuning
We’ve continued efforts to tune autovacuum and fillfactor settings. Though this is an ongoing effort that is never truly “done,” we feel we’ve made the major adjustments necessary to take advantage of our recently upgraded database specs.
Query and index tuning
This is a regular activity that will likely be in every update, but it is still included in the interest of completeness. This time, the biggest improvement came from replacing a DISTINCT with an alternate strategy.
In progress
Blue/green database upgrade automation
We’re building an automated mechanism for blue/green database upgrades, which we’ll leverage for version upgrades and settings changes that typically require minutes of downtime.
With automation, we expect these upgrades to complete in a few seconds maximum, and are exploring solutions to minimize request failures during that window.
We’ve started focusing more on and reducing the overall number of queries per request, by either changing our application logic or leveraging database functions to perform multiple queries at once.
These changes will make us more resilient to future database VM migrations within the network, which are typically done administratively by GCP and out of our control. Our intention is to support up to 2ms of network latency between our compute and the database without a noticeable impact on user experience.
Reduce session API requests
(Promoted to in progress)
We’ve discovered a bug in our session refresh logic that causes individual devices to send more refreshes than necessary. We believe resolving this bug can significantly reduce our request volume.
Improved monitoring
We’re re-analyzing all of our recent degradation and outage incidents and improving our monitoring suite. So far, we’re optimistic that we can achieve earlier notice of potential issues by tuning our existing monitors and adding new ones.
Planned
Database connection pooler and major version upgrade
(Unchanged since last update)
Clerk has historically only used a client-side database pooler inside our Cloud Run containers. Though we’ve known this is non-optimal, we did this because Google did not offer managed database pooler, and we were skeptical of putting a self-hosted service in the middle of two managed services (Cloud Run and Cloud SQL).
In March, Google released a managed connection pooler in Preview, and it reached General Availability this week. However, using the connection pooler will require a major database version upgrade, and in our particular case, a network infrastructure upgrade. We are collaborating with Google to determine how we can achieve both upgrades safely and without downtime.
Simultaneously, we are investigating other database and connection pooler solutions that can run within our VPC.
We plan to leverage our blue/green automation for these upgrades.
Further session API isolation
(Unchanged since last update)
Currently, the session API must failover to a replica during primary database downtime, which is not ideal since the primary database is still impacted by other workloads. We are pursuing solutions that would lead to a session-specific database.
Additional service isolation
(Unchanged since last update)
While working to isolate our Session API, we’ve already developed a handful of techniques that can be re-used to isolate other services. When done, we’d like isolated workloads for each of our product areas:
Session
Sign up
Sign in
User account management (profile fields)
Organizations
Billing
Fraud
Additional staged rollout mechanisms
Today, our staged rollout mechanisms usually target all traffic in increasing percentages. We intend to build more targeted rollout mechanisms, for example by customer cohort or products used.
Introducing Clerk's integration with the AI developer agent, Leap.
Clerk is now available as an authentication provider for Leap, an AI developer agent.
To get started, builders can prompt Leap to create a new application with Clerk for authentication. Behind the scenes, Leap will provision a Clerk application on your behalf so you can start building immediately. When you're ready to configure your application, you can claim the generated application via the Clerk dashboard. To learn more about Leap's Clerk integration, visit the Leap documentation.
Clerk + AI builders: better together
Clerk is an excellent companion to generative AI tools, like Leap. With drop-in authentication and billing primitives, you can build and ship real-world applications faster, not just prototypes. Focus on iterating and building out your application with battle-tested primitives from Clerk.
If you're building AI tools and interested in integrating with Clerk, with us to learn more.
