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.

We’re pleased to share the newest addition to AuthRocket, the LoginRocket 2 API.

When we launched AuthRocket 2, it included an all-new LoginRocket 2 UI with significantly expanded capabilities as compared to LoginRocket 1. Available as a hosted site, it’s the quickest way to add logins, signups, and a myriad of related features to your app.

However, some apps prefer to integrate logins and/or signups directly into the app for a more bespoke user experience. While this was (and still is) possible using the AuthRocket API, that requires both frontend and backend code.

The new LoginRocket API now gives you a third option that only needs frontend code, making it simpler than using the AuthRocket API, while still offering significant flexibility and customization.

The LoginRocket API is designed to play nicely with the LR UI (aka LoginRocket Web) and it’s easy to mix’n’match features. For example, perhaps you’d like to use the LR API to add logins and signups directly into your app, while still using LR Web for less frequent tasks like resetting passwords. No problem.

Or, perhaps you’d like to start with just LR Web on a new app, but as it matures, you want to go back and integrate core features directly into your app’s own UI one at a time. Again, easily done.

We’ve also released loginrocket.js, an npm to help get up and running even more quickly. It’s SPA-friendly, but also compatible with non-SPA frameworks too.

To learn more, check out Getting Started with the LoginRocket API and the LoginRocket API.

As always, if you have questions, we’d love to help!

AuthRocket’s been back to school and now knows Japanese!

Japanese language support covers all of LoginRocket plus AuthRocket APIs that support end-user functionality, including logins, signups, password resets, two-factor auth, all default emails, and more.