LiteLLM master key and salt key management

LiteLLM master key and salt key management: what each key protects

The LiteLLM master key is the admin credential for a self-hosted proxy, and the salt key, when set through LITELLM_SALT_KEY, is the encryption key for the provider credentials the proxy stores. These two values do different jobs, and a platform or security team running a self-hosted LiteLLM gateway needs to decide early whether they stay separate. Teams that store OpenAI, Anthropic, Azure or Bedrock credentials in the proxy, and that need to control who can create keys, models and teams, usually have a reason to keep them apart.

The separation matters because it decides what a rotation touches. When LITELLM_SALT_KEY is set, the master key only authenticates admin requests. Rotating it means issuing a new value and restarting every proxy instance, with no change to the encrypted data. Without a salt key, the master key also serves as the at-rest encryption key. Any change to it then means re-encrypting stored data, which is a more sensitive operation and needs a tested plan. The choice you make now therefore shapes every later rotation, so it belongs in the design record rather than in a runbook written after go-live.

Before you commit to a design, confirm three things in your own environment. First, whether your current deployment already sets a salt key, and whether it was set before any model was added. Second, which systems hold the master key and salt key values, such as a secret manager your platform team operates, and who can read them. Third, how many proxy instances share the same database, because each one must pick up a new master key on restart. Write these answers down, since an auditor or a new operator will ask for them.

Treat the salt key as permanent once models exist. LiteLLM states that LITELLM_SALT_KEY must not change after a model has been added, because there is no in-place migration path and every stored credential would need to be registered again. This is the single most consequential setting in this area. If you are unsure whether the salt key is already fixed in an existing deployment, confirm the current value and its history with your team before any change to configuration or secrets.

Plan for the master key to change, and check the mechanics before you need them. LiteLLM describes two rotation flows for a deployment without a salt key: POST /key/regenerate with a new_master_key value, and the LITELLM_MIGRATE_FROM_MASTER_KEY setting at boot. LiteLLM recommends a database backup before either flow. Virtual keys are stored hashed rather than encrypted, so they continue to work after either rotation. Confirm the exact steps for your release against the LiteLLM rotation documentation and run them in a non-production environment first.

Which key setup fits your gateway: with or without a salt key

This table compares a gateway that sets only LITELLM_MASTER_KEY with one that also sets LITELLM_SALT_KEY. Read each row as a question you will face at setup or during rotation. The main takeaway is that setting the salt key before the first model is added separates master key rotation from stored credentials, but the salt key then effectively becomes permanent.

Question	Master key only	Master key plus LITELLM_SALT_KEY
What the master key does	Serves as the admin credential and the at-rest encryption key for stored provider credentials	Serves only as the admin credential
What encrypts stored provider credentials	The master key itself	LITELLM_SALT_KEY encrypts and decrypts stored credentials
What a master key rotation requires	Re-encryption of stored data through POST /key/regenerate with new_master_key, or LITELLM_MIGRATE_FROM_MASTER_KEY at boot	A new master key value and a restart of every proxy instance
Can the encryption key change later	Yes, but only through the re-encryption rotation flow	No, it must not change once a model has been added, and there is no in-place migration
Effect on virtual keys	Stored hashed in both setups, so they keep working after rotation	Stored hashed in both setups, so they keep working after rotation
Backup before any change	Take a database backup before rotating, as LiteLLM recommends	Take a database backup before rotating, as LiteLLM recommends
When this setup fits	Small or test gateways where a single secret and a re-encryption rotation are acceptable	Production gateways that expect master key rotation without touching stored credentials
Confirm before choosing	Test the re-encryption rotation in a staging copy of your database	Set the salt key before adding the first model and store it in your secret manager

Why the LiteLLM salt key cannot change after a model is added

The salt key cannot change once a model exists because LITELLM_SALT_KEY is the value LiteLLM uses to encrypt and decrypt the provider credentials it stores, such as the API keys the gateway presents to OpenAI, Anthropic, Bedrock or Azure. LiteLLM states that this value must not change after a model has been added. The reason is practical: there is no in-place migration that re-encrypts existing credentials under a new salt key. Once a credential is stored under one salt key, the gateway depends on that same key to read it. Treat the salt key as a fixed setting for the lifetime of the database, and keep it separate from the admin credential, which you can rotate. A changed salt key would force every stored credential to be re-registered. Each provider key and model entry would have to be recreated by someone holding the original provider secrets, and requests to affected models would fail until that work is done. The effort scales with the number of models and credentials, so the reader should inventory them now and record which teams depend on each one. Virtual keys are stored hashed rather than encrypted, so they keep working through a master key rotation, but that protection does not extend to provider credentials. The cost of a salt key change falls on provider credentials and the people who must re-enter them. The salt key decision therefore belongs before the first model is added. Generate a high-entropy value, store it in the same secret manager that holds LITELLM_MASTER_KEY, and restrict who can read it. Keep a second copy in a controlled offline location, and record the value's custody in your change log. Every proxy instance must use the identical value, so confirm that each pod and each restored or staging environment receives it. A value that differs between instances, or that exists only in one person's notes, is the most common way a deployment ends up with credentials it cannot read. If the salt key is lost or needs replacing, do not plan around an assumed recovery path. Confirm the exact steps with LiteLLM before you commit to a plan, including whether a replacement is supported, whether any re-encryption tooling exists, and what must be re-registered afterward. Note that the master key rotation flows, POST /key/regenerate with new_master_key and LITELLM_MIGRATE_FROM_MASTER_KEY, apply to deployments without a salt key, where the master key doubles as the encryption key. They are not a substitute for a salt key change unless LiteLLM confirms otherwise in writing. Before any rotation, take a database backup, and test a restore in a non-production environment using the recorded salt key.

Practical checks to complete before the first model is added: Decide the salt key value, document its custody, and confirm that every proxy instance receives the same value from the secret manager. Confirm that LITELLM_MASTER_KEY, which must start with sk-, is held separately so administrative access can be rotated without touching stored credentials. Write down a list of the provider credentials you expect to register so the re-registration effort can be estimated if the key ever has to change. Finally, ask LiteLLM to confirm the supported recovery path for a lost or replaced salt key, and keep that answer with your runbook.

How master key rotation differs with and without a salt key

When LITELLM_SALT_KEY is set, the salt key is the value that encrypts and decrypts stored provider credentials, and the master key serves only as the admin credential. That separation keeps master key rotation small. You generate a new master key value, update it in your secret manager, and restart every proxy instance so each one reads the new value. Stored model credentials stay encrypted under the salt key, so nothing in the database has to be re-encrypted or re-registered.

Points to plan for:

Change only the master key. Leave LITELLM_SALT_KEY untouched. LiteLLM says the salt key must not change after a model has been added, because there is no in-place migration and every stored credential would need to be re-registered.
Restart every instance. Each proxy replica, including any in a second region, must pick up the new value. Confirm that no instance still holds the old value after the rollout, since a stale instance will reject admin calls made with the new key.
Expect virtual keys to keep working. Virtual keys are stored in hashed form, so existing application keys are not affected by the master key change.
Back up first. LiteLLM recommends a database backup before rotation, even though this path does not re-encrypt data. Keep the backup until you have verified admin login and model calls on every instance.
Protect the salt key separately. Store it in the secret manager with its own access policy and a record of who can read it, because losing it means losing access to stored credentials.

Before the change, check that your runbook names the secret store entry, the restart order and the person who confirms admin login on each instance.

How to set and rotate the LiteLLM master key safely

This eight-step sequence takes a self-hosted LiteLLM gateway from a confirmed PostgreSQL database to a rotated master key with verified access. It fixes the salt key before any model is added and requires a tested backup before any change. Each step closes with a check that the reader can record.

Confirm the database is PostgreSQL
The platform team confirms that the proxy's database is PostgreSQL before any key work starts. LiteLLM names PostgreSQL as its primary supported database, and virtual keys need a PostgreSQL database. Check the database connection string in the deployment configuration and confirm the engine with a query against the running instance. If more than one proxy instance runs, confirm that Redis 7.0 or newer is in place for shared rate limits, router state and cache. The step is done when the engine and Redis version are written into the change record.
Store the master key in a secret manager
The platform team generates the LITELLM_MASTER_KEY value and stores it only in the organization's secret manager, keeping it out of Git repositories, container images and plain environment files. The value must start with sk-. Inject it into each proxy instance at runtime through the secret manager integration. Check that the value begins with sk- and that a test start of the proxy reads it from the secret manager instead of a hard-coded setting. Record the secret's location and owner in the runbook. The step is complete when the proxy starts with the injected value and the admin API accepts it.
Decide the salt key before adding models
Before any model is added, the platform owner sets LITELLM_SALT_KEY, stores it in the secret manager beside the master key and records who may read it. The salt key encrypts and decrypts stored provider credentials, so it must never change once a model exists. LiteLLM provides no in-place migration, and every stored credential would need to be registered again. Check that the proxy starts with the salt key set, that the value is covered by the secret manager's own recovery process, and that the change record states that no model has been added yet. The step is done when the salt key is in place and the model list is empty.
Take and verify a database backup
The database administrator takes a backup of the LiteLLM PostgreSQL database immediately before rotation, as LiteLLM recommends. A backup that has never been restored is only a file, so restore it into a separate, non-production PostgreSQL instance. Check the restored copy by confirming that the virtual key and team tables are present and that a sample of existing keys can be read. Record the backup identifier, the time it was taken and where it is stored. Do not begin rotation until the restore check passes. The step is complete when the restore check passes and the backup identifier is written into the change record.
Choose the rotation path for your configuration
The platform owner confirms whether LITELLM_SALT_KEY is set and selects one rotation path. With a salt key, the master key is only an admin credential, so rotation needs a new value and a restart of every proxy instance. Without a salt key, the master key also encrypts stored data, so rotation must re-encrypt that data through POST /key/regenerate with new_master_key, or at boot with LITELLM_MIGRATE_FROM_MASTER_KEY. Confirm the chosen path against LiteLLM's rotation guide before any change. The step is done when the path and the reason for it are written into the change record and a second reviewer has signed off.
Rotate the master key and restart every instance
The platform team applies the new LITELLM_MASTER_KEY value in the secret manager and carries out the chosen path. On the salt key path, the team restarts every proxy instance, including each pod or replica, so that none keeps the old value. On the path without a salt key, the team runs the re-encryption step before the old value is removed. Check that each instance starts cleanly on the new value, that a request using the old master key is refused, and that a request using the new key succeeds. The step is complete when all instances respond only to the new value.
Confirm virtual keys still authenticate
The platform team checks that existing virtual keys keep working after rotation. LiteLLM stores virtual keys in hashed form, so they should keep working after either rotation flow, but this must be confirmed in your environment. Send a test request with a representative virtual key for each team, and confirm that budgets, model restrictions and rate limits still apply as configured. Repeat the test for a key restricted to one model to confirm the restriction holds. The step is complete when sample keys from each team authenticate and the model call returns a successful response.
Close out the rotation record
The platform owner closes the change. Update the secret manager entry with the rotation date, record the backup identifier and the path used, and retire the old master key value once every instance and test has passed. Keep the pre-rotation backup for the period set by your retention policy. Update the runbook so that the next rotation starts from the new state. Check that the runbook names the current secret version, that no instance accepts the old value, and that, where audit logging is enabled, the rotation event appears in the trail. The step is complete when the record is signed off.

Securing the master key, salt key and stored provider credentials

The master key authenticates admins, the salt key encrypts provider credentials at rest, and the two have different risks and different recovery paths. The cards below cover where each key lives, who can reach it, how it is backed up, how it stays out of images and logs, and how the admin UI is protected.

Store both keys in a secret manager

Keep LITELLM_MASTER_KEY and LITELLM_SALT_KEY in a secret manager your organization already operates, and inject them into proxy pods or hosts at runtime. Check that each proxy instance reads the same salt key value, because a mismatch leaves stored provider credentials unreadable on some instances. Confirm with LiteLLM which secret manager integrations your license includes before you design the injection path.

Restrict who can read the master key

The master key grants full administrative access to the gateway, including creating virtual keys and changing models. Limit read access to the platform team members who deploy and rotate it, and log every read at the secret manager. Review that list when someone changes role, because a single copied master key bypasses SSO-based accountability for the admin UI.

Back up the salt key apart from the database

Without the salt key, the encrypted provider credentials in PostgreSQL cannot be decrypted, so a database restore alone does not recover the gateway. Store a copy of the salt key in a separate, access-controlled vault with its own recovery process. Test a restore into a non-production environment that uses only the database backup and the separately held salt key.

Keep keys out of images and logs

Do not bake either key into container images, Helm values files committed to Git, or environment dumps that CI systems retain. Confirm that the proxy's startup and debug logging does not print the environment, and that your log pipeline masks any value beginning with sk-. Search build logs and image layers for the key prefix as part of your release checks.

Protect the admin UI with SSO

Route admin UI sign-in through your identity provider so each change can be tied to a named person, rather than sharing the master key. LiteLLM's admin UI supports Google, Microsoft Entra ID, Okta and generic OIDC providers, and SSO is free for up to 5 users from v1.76.0, with an Enterprise license needed beyond that. Confirm the user count and license terms with LiteLLM before you plan the rollout.

Confirm the Enterprise secret manager license

Native integrations with AWS, Azure, Google, HashiCorp Vault and CyberArk are part of LiteLLM Enterprise, not the open-source release. If your environment requires one of them, treat the license as a separate decision and get written confirmation of the scope and terms from LiteLLM. Without that license, plan the secret manager access through your platform's own injection mechanism instead.

What to back up and verify before any LiteLLM key change

Take and verify a database backup before any master key change, because that backup is your recovery point if a rotation step fails partway through. LiteLLM recommends a backup before rotation, and the step matters most when the rotation re-encrypts stored data. The backup must hold two things: the stored provider credentials, which are the upstream keys the gateway uses to call model providers, and the virtual key records your teams and applications use to call the gateway. Virtual key records are what you will test after the change, so a backup that omits them leaves you unable to show that those teams were unaffected.

Confirm that the backup comes from the PostgreSQL database every proxy instance reads and writes, since LiteLLM names PostgreSQL as its primary supported database. A dump from a different database, or an older snapshot taken before recent model changes, will not show the state you are changing. Remember that encrypted provider credentials are unusable without the key that decrypts them. Store the backup under your database controls, and record where the current LITELLM_MASTER_KEY and, if you use one, the LITELLM_SALT_KEY values are held, so any restore can be paired with the matching keys. Ask your database team to confirm backup frequency, retention and encryption in writing before the change window opens.

A backup you have not restored is an assumption. Restore the copy into a separate PostgreSQL instance that no production proxy can reach, then start a proxy against it using the keys that match that backup. Check that the admin UI loads, that each stored provider model answers a test request, and that a sample virtual key authenticates and is limited to the models it was granted. Record how long the restore took and any errors, because those figures belong in your rollback plan. Keep the test copy isolated from production traffic, since replaying live requests against it could create spend records you would later need to explain.

After the rotation, run the same checks in the same order on every instance, not only the first one you touch. Log in to the admin UI with the new master key and confirm the old value no longer works. Send a model call through a stored provider model using an existing virtual key, and confirm that a key restricted to other models still behaves as its limits require. Then confirm every instance is serving traffic: check each instance against your health checks, confirm each one restarted with the new configuration, and scan each instance's logs for decryption or authentication errors. An instance still running the old value can pass a test that hits the load balancer and still fail for some users, so test instances individually.

Virtual keys are stored in hashed form and are not encrypted, and LiteLLM's documentation indicates they keep working after either rotation flow. That makes testing existing virtual keys the most useful post-change check, because it shows whether your teams see any change. Treat this behavior as something to confirm in your own version, not as a guarantee. Run the rotation first in a staging copy of your deployment, use keys created before the change, and keep a written list of which keys you tested. Keep LITELLM_SALT_KEY unchanged throughout, since none of these checks can repair a salt key change made after models were added.

What to confirm about LiteLLM key rotation in your environment

Rotation steps depend on the LiteLLM version, whether a salt key is set and how the proxy fleet restarts. The LiteLLM documentation on rotating the master key is the source for exact steps, and DeployOpen will confirm them against the version your organization runs before any production change.

Running version and release line

Confirm the exact LiteLLM version in use and whether it falls within the four most recent stable minor versions that LiteLLM supports for open source and Enterprise deployments. The GitHub releases page lists v1.105.1, published October 14, 2026, so an older deployment may need an upgrade before rotation is scheduled. Rotation behavior can change between releases, so fix the target version in the change record before testing begins.

Salt key presence and migration path

Check whether LITELLM_SALT_KEY is set and whether any model has been added since it was set. With a salt key, rotating the master key needs only a new value and a restart of each instance. Without one, the master key also encrypts stored credentials, so rotation uses POST /key/regenerate with new_master_key or the LITELLM_MIGRATE_FROM_MASTER_KEY boot flow. Confirm which path your deployment uses before anything else is changed.

Restart sequence across proxy instances

Record how many proxy instances run, how each is deployed and whether they can be restarted together. Every instance must end up with the same master key, because mixed values can cause some requests to fail during the change window. Confirm whether your platform restarts instances in a rolling sequence or all at once, and agree on when the old value is removed from every secret store.

Redis state during restarts

Multi-instance deployments need Redis 7.0 or newer for shared rate limits, router state and cache. Confirm the Redis version, whether it persists data across restarts and whether it will be restarted during the rotation window. Ask what happens to counters, router cooldowns and cached data if Redis restarts while proxies stay online, and check that the outcome matches your rate limit and failover expectations.

In-flight and streaming requests

Confirm how existing requests, including long completions and streamed responses, behave when a proxy instance stops. Check the shutdown grace period, the load balancer or ingress drain setting and whether client applications retry on connection errors. Test a streamed request during a restart in a non-production environment, and record which calls complete, which fail and whether the application can retry them safely.

Database backup and post-change checks

Take and test a PostgreSQL backup before any rotation, since LiteLLM recommends a database backup beforehand. Virtual keys are stored hashed, so they keep working after either rotation flow, but stored provider credentials depend on the correct encryption key. After the change, confirm that sample models and keys can still reach their providers, and rehearse the restore procedure.

How much effort and cost does LiteLLM key management setup involve?

What does LiteLLM master key and salt key setup cost?

Cost depends on the written scope, and DeployOpen does not publish a price list, so a quote follows from the scope agreed in writing. The main cost components are the time spent reviewing your current proxy configuration, deciding how the salt key is handled, writing the rotation runbook, testing it in a non-production environment, running the change in a maintenance window and handing over documentation. Most of this is one-time work. Recurring costs come from later rotations, upgrades and any ongoing support retainer. Ask for each component to be priced separately so you can see what is one-time and what recurs.

What makes the effort of key management setup larger or smaller?

Five factors drive the effort most. Number of stored models: each model credential in the database must be verified before and after any change. Salt key status: a salt key set at the start keeps rotation simple, while a deployment without one needs a re-encryption path. Proxy instances: each instance must restart in the right order and share the same configuration. Backup and restore maturity: a tested restore lowers the risk of the change. Change control: the number of approvers and review steps sets how long the work waits for sign-off. Ask the vendor or partner to name which of these apply to your environment before estimating effort.

Can our internal platform team set up LiteLLM key management alone?

Often yes, if the team has PostgreSQL administration experience, can operate the secret manager that holds the master key, and is comfortable with the LiteLLM proxy configuration. The official rotation documentation describes the procedure, but the risky step is the salt key: once a model has been added, LiteLLM says the salt key must not change because there is no in-place migration. A mistake there can mean re-registering every stored credential. Internal teams should confirm the current behavior against the LiteLLM documentation for their release, test in a copy of production, and decide in advance who approves the change. An outside partner can take on the planning and testing if internal capacity is limited.

What must our organization provide before key management work starts?

The work needs several inputs from your side before it can be scoped and carried out safely. Provide database access to the PostgreSQL instance that stores the proxy's data, including backup and restore access. Provide access to the secret manager where the master key and salt key will be held. Reserve a maintenance window that covers restarts of every proxy instance. Name the approvers who sign off on the change and who can make an emergency decision. You should also share an inventory of proxy instances, the models already registered, and the environments in scope. Missing inputs are a common cause of schedule changes, so confirm them in the written scope.

How long does LiteLLM key management setup take?

Duration depends on scope, including how many environments, instances and models are involved and how much testing and approval the change requires. No general duration applies, so ask for the timeline to be set in the written scope with clear milestones. A useful scope separates discovery and planning, testing in a non-production copy, the production change window and handover. Ask whether the timeline assumes your approvers and maintenance windows are available on the planned dates. Any dependency on your change calendar should be stated in the scope so that delays are visible early.

What recurring work follows the initial key management setup?

After setup, the recurring work is operational. Plan for regular database backups before any rotation, periodic rotation drills in a test environment, and review of who can read the master key in the secret manager. Each LiteLLM upgrade should be checked against the key handling steps for the release in use. If your team needs integration with an enterprise secret manager or stronger access controls, confirm with LiteLLM which features require an Enterprise license and what that license costs, since those terms come from LiteLLM and not from DeployOpen. Ongoing support can be handled internally or through a retainer, and the choice affects the recurring budget.

What should we ask for in a LiteLLM key management quote?

Ask for a quote built from a written scope that lists each deliverable. Request the following: the scope of environments and proxy instances, the models and salt key decisions covered, the deliverables (runbook, test evidence, handover notes), the testing approach and the environment used, the client inputs required before work starts, the timeline with milestones, and the assumptions that could change cost, such as more instances or unplanned re-registration of credentials. Also ask which items are one-time and which recurring, what happens if the scope changes, and how change requests are priced. A quote that cannot be traced back to this scope should prompt further questions.

Does a LiteLLM salt key change cost more than a master key rotation?

Usually yes, because the two changes behave differently. When a salt key is set at the start, rotating the master key needs only a new value and a restart of each proxy instance, since the master key acts only as an admin credential. Changing the salt key after models have been added is a different task: LiteLLM says it must not change because there is no in-place migration and every stored credential would need re-registration. That makes the salt key decision the most expensive one to revisit. Ask for it to be made, documented and approved during the initial scope so that later changes stay limited to master key rotation.

How DeployOpen plans LiteLLM key management

DeployOpen plans LiteLLM master key and salt key management as a written scope before any change is made to a live gateway. We separate the admin credential from the key that encrypts stored provider credentials, then document the rotation and recovery steps your team will run after handover.

How we scope

Inventory whether the gateway already runs with LITELLM_SALT_KEY and which provider credentials are stored in its database
Confirm whether any model has been added, since the salt key must not change once models exist
Define who holds the master key, where it lives in your secret manager, and how access is granted
Agree in writing which rotation paths, backups and recovery drills are in and out of scope, with engagements fixed-scope

How we build

Set LITELLM_SALT_KEY and the master key as separate secrets in the secret manager you already operate
Configure the proxy so every instance reads the same salt and master key values at startup
Take and verify a PostgreSQL backup before any rotation step, then rehearse the rotation in a non-production copy
Test that virtual keys keep working after rotation and that stored provider credentials still decrypt

How we hand over

Deliver a runbook for master key rotation, including the restart order for every proxy instance
Document the recovery path if the salt key is lost, and the backup and restore steps that depend on it
Record where each secret is stored, who can read it, and the owner who approves a rotation
Walk your operations team through a supervised rotation so they can repeat it without DeployOpen

How we support

Review the key management setup when LiteLLM releases change how keys, secrets or migrations behave
Plan rotations as change windows with your team, agreed in advance and tested on a copy
Offer ongoing support, upgrades and testing as a retainer if your team wants continued coverage
Confirm support terms and response expectations with DeployOpen in writing before engagement starts

LiteLLM master key and salt key management