We’ve just released v1.0 of the Arcjet JavaScript SDK. After more than two years of building, testing, and iterating in public, the
We’ve just released v1.0 of the Arcjet JavaScript SDK. After more than two years of building, testing, and iterating in public, the SDK is no longer beta. The API is stable, production-ready, and something teams can confidently build on.
For a security product, that milestone matters for a simple reason: security tooling only works if developers actually keep it installed. In the JavaScript ecosystem especially, long-term adoption depends heavily on stability.
JavaScript moves quickly - that pace is part of what makes the ecosystem powerful - but it also creates a real cost for developers maintaining production applications. Dependency churn is constant, and even small upgrades can turn into migration projects.
Most teams have experienced the pattern: a minor version introduces breaking changes, an integration suddenly needs a rewrite, and upgrading becomes work that doesn’t ship anything new for end users…over time this creates developer fatigue. It’s especially painful for infrastructure libraries, where the goal is reliability, not constant change.
We released the first Arcjet JS SDK alpha back in 2023. Even early on, we believed the core API design was solid, but we kept the unstable labeling because we wanted room to learn. Alpha was about understanding how developers were actually integrating Arcjet, what runtimes and frameworks needed first-class support, and where the SDK should be flexible versus opinionated.
The last two years have been spent refining those answers, not rushing to stamp a version number on something unfinished. Alpha turned to beta in Jan 2025 when we were confident we had the API right.
From the beginning, we treated breaking changes as something to avoid, not something to normalize. Over the entire alpha/beta period, we introduced only three breaking changes, and even then we maintained backwards compatibility wherever possible. Two of those changes were literally one-line updates.
When internal refactors were necessary, we handled the migration work ourselves so developers didn’t have to. Most upgrades didn’t require teams to touch application code at all. That’s intentional: the best developer experience is often the one you don’t notice.
Stability isn’t only about API design. It’s also about release cadence. Instead of pushing constant SDK versions, we aim for roughly one release per month that rolls up improvements into a predictable upgrade cycle.
That approach reduces noise and makes adoption easier for teams running real production workloads. Developers don’t want constant motion in their dependencies, they want steady progress without surprises.
Unofficially, Arcjet has been run as production infrastructure since the beginning, with full support, redundant systems, uptime monitoring, and ongoing operational investment. But semantic versioning matters. Releasing v1.0 is us making a clear promise that the API is stable, upgrades won’t become a burden, and developers can depend on Arcjet long-term.
Security should not introduce more work. It should quietly remove an entire class of problems so teams can focus on building features instead of maintaining tooling.
Arcjet JS SDK v1.0 is available now. If you’ve been using the beta, upgrading should be straightforward. And if you’re integrating Arcjet for the first time, this release represents the stable foundation we’ve been working toward since 2023.
We’re excited to keep improving the SDK without making developers pay the migration tax along the way.
Get the full posts by email every week.
