Skip to content

Why we launched Passlock as a cloud based toolkit

When we set out to build Passlock, we had a choice:

Should this be a self-hosted library developers run themselves, or a fully managed cloud platform?

On the surface, a library might seem simpler. Developers get full control, no external dependency, and everything runs in their own infrastructure. But after working deeply with WebAuthn—and seeing the real-world complexity behind passkeys—we made a deliberate decision:

Passlock would be cloud-first.

Here’s why.


Authentication is not a “feature”—it’s infrastructure

Section titled “Authentication is not a “feature”—it’s infrastructure”

Authentication sits on the critical path of your application. If it breaks, users can’t log in. If it’s insecure, everything else is at risk.

Building on top of a library gives you primitives—but it also means:

  • Designing your own credential storage
  • Handling edge cases across browsers and devices
  • Managing security, replay protection, and abuse prevention
  • Maintaining and evolving the system over time

In practice, you’re not just “adding auth”—you’re building and operating an authentication service.

Passlock exists to take that off your plate.


One of our core goals was to avoid locking developers into a specific stack.

While we provide a JavaScript server library, it’s intentionally thin - just a wrapper around our REST API.

That means Passlock works with:

  • Node / Deno / Bun / JavaScript
  • Python, Java, Go
  • Or any backend capable of making HTTP requests

By running as a cloud service, we can offer a consistent, language-agnostic interface instead of maintaining multiple deeply integrated SDKs across ecosystems.


Avoiding deployment complexity (for everyone)

Section titled “Avoiding deployment complexity (for everyone)”

If Passlock were self-hosted, we wouldn’t just be shipping code—we’d be shipping infrastructure.

That would mean supporting combinations like:

  • Docker vs native installs
  • Kubernetes vs simple VM deployments
  • Serverless environments
  • Multiple database backends (Postgres, MySQL, MongoDB, etc.)

Each combination introduces:

  • Different failure modes
  • Different performance characteristics
  • Different operational challenges

By running Passlock as a cloud platform, we eliminate that entire class of complexity—for both you and us.


WebAuthn and passkeys are still evolving.

Browsers are changing behaviour. New capabilities are being introduced. Edge cases are constantly being discovered.

At the same time, we have an aggressive roadmap for Passlock itself.

If we shipped a self-hosted product, we’d need to:

  • Support multiple versions “in the wild”
  • Maintain backward compatibility across deployments
  • Slow down changes to avoid breaking existing installations

By running in the cloud, we can:

  • Ship improvements immediately
  • Fix issues once, for everyone
  • Continuously refine behaviour as the ecosystem evolves

This lets us move much faster than a traditional self-hosted model allows.


Authentication data isn’t static.

As new features are introduced—or as the WebAuthn spec evolves—data structures may need to change.

In a self-hosted world, that means:

  • Writing migration scripts
  • Coordinating deployments
  • Risking inconsistencies across environments

With Passlock in the cloud:

  • We handle migrations centrally
  • Changes are applied safely and consistently
  • Everything is transparent to you

You don’t need to think about schema changes—we take care of it.


Security issues don’t wait for release cycles.

In a self-hosted model:

  • A vulnerability is discovered
  • A patch is released
  • You need to upgrade
  • You need to deploy
  • You need to verify everything still works

That gap—between patch release and deployment—is where risk lives.

With Passlock:

  • We patch vulnerabilities immediately
  • Fixes are applied globally
  • No action is required from you

Your application benefits from the latest security improvements automatically.


WebAuthn is powerful—but it’s not trivial.

Behind the scenes, there are complexities around:

  • Browser inconsistencies (especially Safari)
  • Credential lifecycle management
  • Cross-origin and RP ID behaviour
  • Device-specific quirks

These aren’t things you solve once. They’re things you continuously maintain.

Passlock centralises that effort, so every improvement benefits every developer using the platform.


Choosing a cloud platform is ultimately a trade-off.

With Passlock, you’re choosing:

  • Faster development
  • Less operational overhead
  • Continuous improvements
  • Centralised security and reliability

In exchange for:

  • Relying on an external service
  • Less direct control over the underlying system

For most teams, especially those where authentication isn’t the core product, that’s the right trade.


We don’t see Passlock as just an API.

We see it as authentication infrastructure, delivered as a service.

You focus on building your product.
We handle the complexity of passkeys, WebAuthn, and everything that comes with them.


If you’re building with passkeys and want to move fast without owning the entire auth stack, Passlock is designed for you.