Does a person need to sign in, or does your app need private settings?
Use a shared password vault for logins people need to open. Use an app secret store or your host’s private settings for the credentials the running app needs. A small app can start with what its host already provides.
Who uses the credential?
A credential is proof that a person or app has permission. Your teammate may need to sign into the domain registrar. Your app may need a private API key to send mail. Keep the first in a team-controlled vault and the second in a server-side setting.
When a provider offers a separate account for each person, use it so you can remove one person without making everyone change passwords.
Why should test and live settings be separate?
Preview should be able to test a booking without emailing a real customer. Use different settings that connect preview only to disposable services, and check the actual destination before trying a change. The live app keeps its own connections.
Keep private credentials out of public app code, screenshots, tickets and logs. A central secret store helps when the same app runs in several places or when a person needs to review who can make changes.
Compare tools
Scroll the table sideways to read every column.
| Tool | Who needs access?The person or app that needs the information. | How do you limit access?The setting that helps define which records or environment someone can use. | What affects the plan?The team size or usage limit to check. | What should you keep for a move?The information you need to re-create or restore access. |
|---|---|---|---|---|
| 1Password | Share company logins with teammates. | Give people access through a shared vault. Review the view, edit and management permissions. | Annual Teams Starter Pack includes ten member places. Business is billed per member. | Check export permissions and protect the unencrypted desktop export. |
| Bitwarden | Separate personal logins from company-owned items. | Choose collections and give the relevant people access. | Free organization supports two people and two collections. | Export personal and organization items separately. Check encryption and import requirements. |
| Doppler | Supply private settings to each running copy of an app. | Separate test from live and scope app access to one configuration. | Developer includes three users and five configuration syncs. | List setting names and destinations. Treat a downloaded configuration as sensitive. |
| Infisical | People or services use approved settings in an Infisical project. | Separate environments and limit the identity’s role and scope. | Free lists five identities across people and machines. Check paid rotation and recovery features. | Keep a values-free environment and permissions map with issuer ownership. |
| AWS Secrets Manager | An AWS app or operator uses a stored, versioned secret. | Scope read and administrative roles separately to the appropriate resource. | AWS counts stored secrets and API calls. Check replica, encryption and rotation costs. | Keep references, regions, consumers and the source service responsible for replacement. |
| Google Cloud Secret Manager | A Google Cloud identity uses one of the stored versions. | Grant access to the specific secret. Metadata visibility is separate. | Check active versions, read operations, notifications and shared account allowances. | Keep version choices, location requirements and identity mappings. |
| Azure Key Vault | An Azure app uses a secret, key or certificate according to its job. | Separate management permissions from data access. | Vault secret operations are listed per 10,000 transactions. Keys and certificates use separate pricing. | Keep role and consumer mappings. Individual backup restore has subscription and geography limits. |
| HashiCorp Vault | An approved service reads a stored value or uses a supported temporary credential. | A role sets the allowed use. Dynamic credentials have a lease. | Check Community versus Enterprise features and the cost of running and recovering the service. | Keep configuration, roles, protected backups and recovery ownership. |
| Phase | People and service accounts use secrets in assigned apps and environments. | Check both scope and role. The default Service role can change secrets within its grant. | Cloud Free lists five combined user or service accounts and three apps. Check custom role availability. | Keep environment and permission maps. Protect files that contain private values. |
| dotenvx | An approved app or person opens encrypted settings with the matching key. | Keep the key separate. Names, comments and any plaintext fields remain readable. | The core tool is open source. Armor has separate access and audit pricing. | Keep the encrypted file and an approved separate recovery path for its key. |
What changes when someone leaves or a credential is exposed?
Remove the person’s direct access first. For a shared password they could have kept, ask the service owner to replace it. If an app credential was exposed, replace it at the issuing service, update the affected app copies and check they work with the replacement.
Keep a recovery list with the service, affected apps and responsible person. Store the actual credentials only in their approved place.
Can you map access before choosing a tool?
Draw a fictional shop with an owner, a designer, a preview app and a live app. Leave all secret values blank.
- Match the user to the jobGive the designer only the design service. Connect the preview server to a disposable mail service and the live server to its own mail service.
- Trace a missing settingRemove the preview mail connection on paper. The preview should report it cannot send. It should have no path to the live mail account.
- Plan a handoffMark who could revoke the designer’s access and who could replace the live app’s mail credential. Write down what would still require a real test.