Open-source alternative to AWS Secrets Manager rotation

Open-source alternative to AWS Secrets Manager rotation: the short answer

If your team maintains rotation Lambdas, a rotation schedule for every secret, and a growing wish to reduce dependence on AWS, OpenBao's database secrets engine replaces most of those rotation patterns. Dynamic credentials are the preferred model: an application requests a database login from a configured role, receives a username and password with a lease, and OpenBao revokes that login when the lease expires, so there is no long-lived password to rotate. Static roles cover the narrower case where an account must keep a fixed username, mapping one OpenBao role to one existing database user and rotating that user's password on a schedule.

The right pattern depends on two things: the database type and how the application handles credentials. The engine ships built-in plugins for Cassandra, InfluxDB, MySQL and MariaDB, PostgreSQL and Valkey, and custom types can be added through a plugin interface. Static roles are not available for Valkey, so confirm the exact combination you run against the OpenBao database secrets engine documentation before you plan a cutover. Applications that cache a password for hours, or that cannot re-read credentials when a lease ends, need code changes before dynamic credentials will work for them.

Treat the engine as a replacement for most rotation logic, not a drop-in for every rotation target. Any Lambda rotating a credential for a database without a plugin, a SaaS API key, or a non-database secret will need another approach, such as a custom plugin or a scheduled job that writes a new value into a KV path. Inventory each rotated secret against the supported list before you decommission a rotation function, and confirm with your database and application owners which accounts truly need a fixed username.

Which rotation capabilities map to OpenBao and where the gaps are

This table maps the rotation features AWS Secrets Manager offers to the OpenBao database secrets engine and names the cases where the match is partial or missing. Read each row as a question to answer for your own databases and non-database secrets. The main takeaway is that database credentials map well, while Valkey static roles and non-database rotation need a different design.

Capability	AWS Secrets Manager	OpenBao equivalent and gap
Scheduled password rotation	Rotation schedule on each secret, driven by a Lambda function	Static roles rotate one existing database user's password on a schedule; confirm the interval settings for your database plugin
Managed database rotation	Built-in rotation templates for supported database engines	Built-in database plugins for MySQL and MariaDB, PostgreSQL, Cassandra, InfluxDB and Valkey; confirm plugin versions in your release
Custom rotation Lambda functions	Your own code that sets and tests new passwords	Rotation logic is not written as a Lambda; for unsupported databases, build a custom database plugin through the plugin interface
Dynamic, short-lived credentials	Not offered as a native concept; apps read a stored value	Database roles issue a new user per request and revoke it when the lease expires, reducing standing credentials
Static accounts with a fixed username	Secret holds the current username and password	Static roles map one OpenBao role to one existing database user; use them when an application cannot change its username
Valkey accounts	Covered by managed rotation where AWS supports the engine	No static roles for Valkey; use dynamic roles or a rotation process outside OpenBao
Per-secret versioning and read control	Version stages and IAM policies on each secret	Leases, revocation and policies control reads; rebuild version history and approval workflows in your own process
API keys and non-database secrets	Rotation Lambdas for third-party credentials	No built-in rotation for most API keys; use a KV secret with an external rotation job that writes new values

Dynamic credentials, static roles or a custom plugin: which fits

OpenBao's database secrets engine offers three routes for replacing rotation Lambdas: dynamic roles that issue short-lived credentials, static roles that rotate one existing user's password, and custom plugins for databases OpenBao does not ship support for. The right choice depends on how much your applications can change and how much your database accounts are tied to existing configuration.

Dynamic database roles

Dynamic roles suit applications that can request a credential at startup, hold it for its lease, and request a new one before it expires. OpenBao creates a fresh database user per lease and revokes it when the lease ends, so a leaked credential has a limited life. The trade-off is application change: connection pools, deployment scripts and batch jobs must fetch and renew credentials instead of reading a fixed value. Check connection pool behavior on renewal before you commit.

Static roles for fixed usernames

Static roles map one OpenBao role to one existing database user and rotate that user's password on a schedule. They fit legacy applications, vendor tools and reporting accounts that require a fixed username in configuration files. The trade-off is that the rotation interval sets your exposure window, and every consumer must pick up the new password when it changes. Confirm which systems read the secret directly and how each one reloads after rotation.

Static roles and Valkey

Static roles are not available for Valkey, so a Valkey-backed service cannot use scheduled password rotation through the built-in plugin. Teams in this position usually rely on dynamic credentials where the client supports them, or accept a documented manual or pipeline-driven rotation with a clear owner. Decide this before migration, because it changes how you write the rotation runbook.

Custom database plugin

A custom plugin is the route for a database that OpenBao does not ship a plugin for. The database secrets engine accepts custom database types through its plugin interface, so your team or a partner writes code that creates users, rotates passwords and revokes access. Budget for ongoing ownership: the plugin needs review, testing and updates whenever OpenBao or the database changes. Ask who will maintain it after go-live.

Built-in plugin inventory

Confirm first that your database is not already covered. OpenBao's built-in database plugins cover Cassandra, InfluxDB, MySQL and MariaDB, PostgreSQL and Valkey. Anything else, such as a commercial engine or a legacy system, starts as a plugin project. Map every database in the rotation inventory against this list, and record which ones need dynamic roles, static roles or a custom plugin.

Which databases OpenBao rotates natively today

OpenBao's database secrets engine ships built-in plugins for MySQL and MariaDB, and for PostgreSQL. Both dynamic roles and static roles are available for these engines, so they cover the most common replacement for a Lambda that rotates an RDS or self-managed password. Dynamic roles create a new user for each lease and revoke it when the lease expires. Static roles keep one existing user and change its password on a schedule.

Dynamic roles: OpenBao creates a short-lived user with the privileges defined in your role's creation statements and drops it at lease end.
Static roles: One OpenBao role maps to one existing database user, and OpenBao rotates that user's password on the configured schedule.
Connection user: The account OpenBao uses must be able to create users, grant privileges and change passwords, so confirm the exact grants your engine version needs.
Application behavior: Confirm that your application reconnects when a dynamic username changes or a lease expires.
Engine versions: Confirm that your MySQL, MariaDB or PostgreSQL version is supported by the plugin in the OpenBao release you plan to run.

Before cutover, test a dynamic role and a static role against a non-production copy of each database, and confirm the connection user's privileges in writing with your DBA.

How the database secrets engine replaces Lambda rotation

The core change is that OpenBao issues a new database credential per request and revokes it on its own schedule, instead of rewriting one stored password on a timer. An application authenticates to OpenBao with an auth method, requests a role from the database secrets engine, and receives a lease together with a username and password that OpenBao has just created on the database. When the lease expires or is revoked, OpenBao removes that database user. The application never needs a long-lived password, and the rotation logic that a Lambda function would hold becomes OpenBao's responsibility, configured through the role definition rather than custom code.

The contrast with a rotation Lambda is mostly about who holds the power. In the Lambda pattern, a function holds an administrative database credential, changes a shared password on a schedule, writes it back to the secrets store, and must coordinate with every consumer that caches the old value. Revocation is effectively the function's job, and a failed run can leave consumers with a password that no longer works. In the OpenBao pattern, the database admin credential is configured once in the engine and stays inside OpenBao, and lease expiry triggers revocation within OpenBao itself. Before you migrate, confirm with your database team which account OpenBao will use, what privileges it needs to create and drop users, and how that account will itself be rotated.

Two decisions follow for your architecture. First, identify which consumers can accept short-lived credentials. Applications that open a connection pool and hold it for a long time must handle lease renewal or re-requesting credentials, so test that behavior before you cut over. Second, decide where the lease lifetime limits sit, since they determine how often each workload contacts OpenBao. Where a consumer cannot change its connection handling, the static roles described in this section are the fallback, and their password rotation is still performed by OpenBao, not by a function you maintain.

Moving rotated secrets from Lambda and Secrets Manager into OpenBao

This sequence replaces each rotation Lambda with an OpenBao database secrets engine configuration, so applications receive short-lived credentials or a rotated static password from one place that the team controls. Each step closes with a check, so no database loses its rotation path before its replacement is proven.

Inventory every rotation Lambda and its target
Someone on the platform or database team lists each Secrets Manager secret that has rotation enabled, the Lambda function that performs the rotation, the database engine and version it targets, and the applications that read the secret. Pull this from the rotation configuration in AWS and from the Lambda code itself, since the code shows the exact ALTER or CREATE USER logic that must be reproduced. The output is a table with one row per secret, and each row names an owner. Done when no rotated secret is missing an owner or a consuming application.
Confirm the database has a built-in plugin
For each target, check whether OpenBao's database secrets engine ships a built-in plugin for it. Built-in plugins cover Cassandra, InfluxDB, MySQL and MariaDB, PostgreSQL and Valkey, and other types need a custom plugin built against the plugin interface. Confirm the exact plugin version and the database version with the OpenBao database secrets documentation and your own test environment, because support can differ by release. Record any database that has no plugin, since those stay on their current rotation path until a plugin or another approach is chosen. Done when every target is marked as built in, custom, or out of scope for now.
Create database connections and roles in OpenBao
The database team creates a privileged database user that OpenBao uses to manage other accounts, granting only the permissions needed to create, alter and revoke users in the target schemas. The platform team then configures a database connection in the database secrets engine and defines dynamic roles that contain the creation and revocation statements, with lease durations chosen for each application's reconnect behavior. Keep the connection credentials themselves in OpenBao's own storage, not in configuration files. Done when a test client can request a credential from a non-production role, use it to connect, and see it revoked when the lease ends.
Define static roles for fixed-username accounts
Some accounts, such as service users tied to vendor software, reporting jobs or grants that reference a fixed name, cannot change their username on each request. For those accounts, create static roles that map one OpenBao role to one existing database user, and let OpenBao rotate that user's password on a schedule. Static roles are not available for Valkey, so accounts there need another plan. Confirm that the applications reading these roles can refresh their password without a restart. Done when a rotated password is accepted by the database and the application reconnects without manual changes.
Switch one application at a time to OpenBao
Choose one low-risk application, grant it an OpenBao auth method suited to its runtime (AppRole is the usual choice for servers), and change its code or sidecar to request database credentials from OpenBao instead of reading the Secrets Manager secret. Keep the old secret in place during the cutover so the change can be reversed. Monitor connection errors and login failures in both the application and the database logs before moving the next application. Done when the application runs through a full business cycle on OpenBao credentials with no fallback to the old secret.
Repeat the switch across the remaining workloads
Work through the inventory in batches, grouping applications by database and by owner so that each database's roles change in one controlled window. Track each workload in the inventory with its new role name, auth method and cutover date. Where an application cannot request credentials dynamically, use a static role and document the reason. Done when every inventory row shows a workload reading from OpenBao and no application still reads a rotated Secrets Manager value for those databases.
Retire the Lambda and the rotation schedule
Once no consumer depends on a Secrets Manager rotation for a database, disable rotation on the secret, confirm that the rotation Lambda has no remaining invocations in CloudWatch logs for an agreed observation period, and then delete the function and its execution role. Keep the Secrets Manager secret and its recovery window in place until the export and decommissioning steps in the sibling topics are complete. Done when the rotation schedule is off, the Lambda has been removed, and the inventory marks every rotated database as served by OpenBao.

Questions buyers ask before replacing AWS rotation with OpenBao

Can our team move AWS rotation to OpenBao without outside help?

Yes, if you have people who can operate a Vault-compatible secrets manager, administer your databases and maintain Kubernetes or VM deployments. The database secrets engine itself is configured with a few API calls per database, so the hard part is rarely the configuration. The work that usually needs experienced people is the high availability setup, unseal key handling, audit logging, and rewriting each application so it fetches and renews credentials correctly. Many teams do the first pilot in-house and bring in a specialist for production hardening and cutover.

What makes an OpenBao rotation project larger or smaller?

Scope grows with four things: the number of databases and engines in use, how many Lambda rotation functions must be replaced, how many applications must change to request dynamic credentials, and how much testing each change needs. A single PostgreSQL database feeding one service is a small job. Dozens of MySQL, PostgreSQL and MariaDB instances with shared accounts, connection pools and long-running batch jobs is a much larger one. Ask any provider to break the work down by database and by application.

How much database admin access will the project need?

Expect to need privileged database access during setup. OpenBao's database secrets engine must connect with an account that can create users and grant privileges, and you will want a separate, tightly scoped account for it. Your database team will also need to review the SQL statements OpenBao runs for each role. You will need network paths from the OpenBao servers to every database, and from applications to OpenBao. Confirm these with your network and database administrators before the first design review.

How long does an OpenBao rotation migration take?

The duration depends on scope, not on a fixed rule. A pilot covering one database and one application can be planned in weeks, while a multi-database estate with many workloads needs staged waves, change windows and rollback plans. Your timeline should be set in a written scope that lists databases, applications, environments and acceptance tests. Ask any provider to show the phases and which decisions you must make at each one.

Can static roles keep our existing database usernames?

Yes. A static role maps one OpenBao role to one existing database user and rotates that user's password on a schedule, so the username stays the same. This suits accounts that other systems reference by name, such as legacy jobs or vendor tools. Static roles are not available for Valkey, so check that case separately. Dynamic roles are the better choice for new workloads, because each consumer gets its own short-lived credential that OpenBao revokes when its lease expires.

What happens to services that have no OpenBao database plugin?

OpenBao's database secrets engine ships built-in plugins for Cassandra, InfluxDB, MySQL and MariaDB, PostgreSQL and Valkey. For any other database, you can add a custom database type through the plugin interface, which requires development and testing. A second option is to keep the existing rotation logic for that system during transition and move it later. A third is to store its credentials as static secrets with a documented manual rotation process. Confirm the plugin list against the current OpenBao documentation before you commit to a design.

What should we ask for in a written quote for this work?

Ask for a written scope that names every database engine, the number of roles and applications in each wave, and the environments covered. The quote should list the deliverables, such as the OpenBao deployment design, role and policy definitions, application change records, test evidence and runbooks. Ask which costs are one-time, such as design, migration and cutover, and which recur, such as patching, upgrades and support. Also ask what the client must provide, including database access, network changes and staff time, and how changes after sign-off are handled.

What changes for applications, operators and auditors

Moving from managed rotation to OpenBao's database secrets engine changes who does the work at runtime. Applications stop reading a long-lived password from a store and start holding a lease that expires. Each service must renew its lease before it runs out or request a new credential when renewal fails, and it must handle a revoked credential without crashing. Teams should confirm, in their own test environment, how each client library, connection pool and ORM refreshes database connections when a credential changes, because a pool that caches the old password will fail only after the lease ends. Static roles reduce this burden for accounts that must keep a fixed username, but they still rotate the password on a schedule, so the same reacquisition logic is needed.

Operators take on what the AWS service previously hid. The team must run the OpenBao cluster itself, choose the storage backend, and keep high availability working. The OpenBao high availability documentation names integrated storage (Raft) and PostgreSQL as the supported HA backends, so the operator needs a clear answer on which one fits and who restores it. Unseal keys, root token handling, upgrades and database plugin credentials become recurring duties rather than AWS-managed ones. Every database connection OpenBao holds for rotation is also a privileged account that must be scoped and monitored.

Auditors will look at a different evidence set. Where the AWS model points to Lambda rotation logs and CloudTrail entries, OpenBao produces lease records, role definitions, and the policies that allow each identity to read a role. Ask the team to show which roles exist, who can create or change them, and how revocations are recorded. The audit device configuration decides whether any of this evidence exists at all, and it is not enabled by default in a way you can assume. Confirm in your own environment which audit devices are enabled, where their logs are written, how they are protected from modification, and how long they are retained.

How DeployOpen scopes and delivers a rotation replacement

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For rotation replacement, that means mapping each Lambda rotation function and each secret to a dynamic or static OpenBao database role before any cutover is planned.

How we scope

Inventory every rotation Lambda, its target database and the applications that read each secret
Classify each secret as dynamic credential, static role or non-database secret needing another path
Agree deliverables, timelines and acceptance tests in writing before any work starts, as fixed-scope engagements

How we build

Deploy OpenBao in your accounts or data centers and configure the database secrets engine for each supported database
Write role definitions with lease durations and revocation behavior tested against non-production databases first
Run security testing on the new credential paths, including lease expiry, revocation and failure of the OpenBao service

How we hand over

Document each role, policy, auth method and rotation schedule so your team can operate it without us
Provide a cutover runbook with rollback steps for each application moved off AWS Secrets Manager rotation
Deliver evidence of configuration and audit logging that your own auditors can review, noting DeployOpen does not issue audit reports

How we support

Support is available as a retainer covering OpenBao upgrades, patch review and backup testing
Retainers can include continuous testing of dynamic credential paths as databases and applications change
Confirm with us which OpenBao release line and plugin set your scope targets before the retainer starts

Open-source alternative to AWS Secrets Manager rotation