The Kurrent Cloud team has been hard at work over the past few months, and we'd like to highlight some of the new features that we think you'll really enjoy. Without further ado, here they are.
Single sign-on
Kurrent Cloud can now use SSO to authenticate your team against your own identity provider. We support SAML 2.0 and OpenID Connect, which covers Okta, Microsoft Entra ID (formerly Azure AD), Google Workspace, OneLogin, JumpCloud, and anything else that speaks either protocol. Instead of your team keeping a separate Kurrent Cloud password, they authenticate where they already do, and your provider decides who gets in.
This mattered most to teams whose security policy requires every third-party service to sit behind their own IdP. For those teams, Kurrent Cloud previously needed a written exception.
Read-only replicas, now in Cloud
If KurrentDB reads for reporting or analytics are slowing down your writes, you can now move them onto a read-only replica. A replica serves read traffic without taking part in the cluster's quorum, so you scale reads out while your primary nodes stay focused on the write path.
Provision them from the console, the API, or the Terraform provider, on AWS, Azure and GCP. They're available on three-node multi-zone clusters only; up to two per cluster. A replica is a real node, so it's billed as one, and the console shows the monthly cost difference before you confirm any change.
Once running, replicas sit alongside the rest of your cluster. Their addresses appear with your other node addresses, and each reports its own status and health in the topology view.
Signing in with a social login / OAuth
You can now sign in with a Google account instead of a Kurrent Cloud password. GitHub and Microsoft are planned.
Service accounts for automation
Your automation shouldn't stop working because someone left the company, but until now it could. The only way to authenticate a script or pipeline against Kurrent Cloud was a token issued to a person, so when their account was disabled, the automation went down with it.
Service accounts are the fix. They're owned by the organization rather than a person, they carry their own scoped permissions, and they work with our CLI, Terraform, and the API. Each can hold more than one secret, so you can add a new one, move your automation over, and revoke the old without downtime.
⚠️ Action required User access tokens will stop working after 15 September 2026. If a CLI session, script, or CI pipeline authenticates with one, move it to a service account before then. Browser sign-in is unaffected, so if the console is all you use, there's nothing to do. The full advisory explains what to change.
Granular permissions
You can now grant a service account exactly the access it needs from a single policy. Previously, permissions were hand-written JSON with group and object IDs pasted in, and since a policy applied its actions to every resource it covered, fine-grained access meant juggling several of them.
Now you set permissions as a grid of resources against actions, with checkboxes, scoped to your whole organization, all projects, or a single project. One policy can grant different actions on different resources, and it attaches straight to the service account with no group in between.
This applies to service accounts today. Groups and users still use the existing editor, and that's changing next.
Access control, groups and policies →
Multi-factor authentication
MFA setup can be self served now. So you can enroll an authenticator app yourself without going through support. Note that we support authenticator apps specifically, not SMS codes, passkeys or hardware security keys.
Organization admins can also make it mandatory. Turning on MFA for the organization prompts every member to set it up at their next login, and members who already had it enabled can no longer turn it off.
Enabling Projection from Console
Projections can now be turned on and off from the console. This used to mean opening a support ticket, and it's now an action on the cluster itself, available through Terraform and the CLI as well. It runs asynchronously and triggers a rolling restart, so multi-node clusters stay available while it happens, though a single-node cluster will be down briefly. The System Projections Only option is also retired, since system-only projections are on their way out, and clusters currently set to that level will show projections as disabled.
