It’s been a while since we’ve added an entirely new event type within AuthRocket, but today is that day. We’re pleased to make available the new session.deleted event.

As you might guess from the name, session.deleted is sent when a Session is deleted before its expiration time. Since Sessions and JWTs already include an expiration time, session.deleted is not sent upon or after Session expiry.

This greatly improves the ability to cache sessions as now a webhook for session.deleted can be used to prematurely expire the cached copy.

Similarly, for apps relying solely on issued JWTs, this new webhook can be used to populate the app’s list of invalidated sessions. To help maintain such a list, the webhook payload will include the original expiration time. This bridges the gap until the session would have expired anyway.

Related, session.deleted is now triggered for all outstanding sessions upon a successful password reset or administrative password change.

Finally, sessions may now be optionally deleted upon a user-initiated password change with the new keep_sessions argument. The default value is all which preserves existing API behavior. LoginRocket now deletes all sessions except the one being used to perform the password change.

We’re pleased to announce enhanced support in DNScaster for the domain registrar Porkbun.

One of our goals with DNScaster is to streamline DNS management as much as possible. From our beginning, that’s included the option to automatically update nameserver and glue record configurations.

Only a small number of registrars provide the necessary APIs and, happily, Porkbun recently expanded their APIs, allowing us to enable our enhanced functionality with Porkbun. Thanks, Porkbun!

This allows Porkbun-registered domains to enable automated nameserver and glue record updates, and to function as a source for custom vanity names within DNScaster.

If you’re looking for a registrar for a custom vanity domain within DNScaster, Porkbun is now a great option!

We’re pleased to announce our latest service… CertFu!

CertFu is an ACME-enabled Private CA.

When running modern infrastructure, the goal should be for all services to be protected by TLS. Oftentimes this is more difficult than it looks. Private IPs. Private domain names. IP-only access. Not to mention all those renewals!

Public ACME services likes Let’s Encrypt solve the renewals, but your ACME server needs to handle those private IPs and domains too.

And what about manageability and oversight? As a general rule, ACME servers provide little to no oversight about what certs were issued, when, and by whom.

CertFu solves all of this.

• ACME - Use modern ACME tooling to fully automate renewals. Once setup, mark cert renewals off your list. Forever.
• Any domain, any IP - Issue certs for private domains or IPs. Routable or non-routable.
• Issuance policies - Restrict what certs are allowed to be issued. Authorize by IP, domain, CAA tags, and more.
• Manageability - Every server/host has its own, unique account key. Authorize and track each host and revoke access when no longer needed.
• Oversight - Know what certs were issued, when, and by whom.
• Privacy - Avoid publishing your internal domains and subdomains into public certificate logs.
• Online root CAs - Use an online root for maximum convenience: CertFu will handle all the intermediate CAs for you.
• Offline root CAs - Maintain sole control of your root CA and just give CertFu an intermediate CA instead.
• Multiple directories - Isolate certs (and permissions) for production, staging, QA/tests, etc.

Start a trial, Learn more, or Send us your questions.

We’ve been rather quiet this year, but that doesn’t mean we haven’t been hard at work. Quite the contrary. We’ve been actively building, updating, refining, and more throughout the year. Since it’s easy for updates to slip by without much discussion, let’s review the more interesting of those, along with a few other highlights.

For those that have been with us for a while, one of the most evident updates was to our UIs. We unified the UIs across our apps, also taking the opportunity to freshen up the look. While we were at it, we modernized much of the Javascript underneath, eliminating a bunch of legacy code.

AuthRocket

In AuthRocket, the API docs examples are now generated from real API calls. To improve clarity, we normalize IDs and dates, hence why they don’t appear as random as they otherwise might. This helps ensure the API examples match real-world use. We already did this with DNScaster, so this extends that to AuthRocket.

Additionally, we improved performance of LoginRocket by optimizing delivery of logos and other assets.

DNScaster

DNScaster Host records can now be designated as primary or secondary. Under normal operation, only primary hosts are used to answer DNS querites–secondary hosts are skipped. However, when all primary hosts are monitored and go offline, or directly set to inactive, the secondary hosts automatically kick in.

HTTP Monitors can now be configured to treat 3xx responses as online or offline. Previously they were always treated as online.

The UI also received numerous refinements and the sync engine was improved, making updates faster and more predictable.

Lastly, we added some new cities to our global network.

Operations

Systems and operations was a key focus for the year. We streamlined our stack by reducing the number of distinct database engines in use and swapped our background queueing engine for a better fit for our workloads. We made significant investments in new tooling and automation and made numerous updates to our overall cloud footprint.

That’s a high-level summary of updates and changes. We’ve also been working on some new stuff. Not ready to share much yet, but we can say there’s more than one new product in the pipeline. We look forward to sharing more when things are ready.

Happy 2025!

We’re pleased to announce the addition of two more cities to DNScaster’s global network: Chicago and Paris.

Additional datacenters have also been added elsewhere.

As a reminder, every region has at least two datacenters to maximize availability.

See all of our available nameserver regions.