How to Share Onboarding Credentials with New Developers
Day-one access without day-one credential sprawl.
The onboarding credential problem
A new developer starts Monday. They need the staging database password, API keys for three services, a .env file for local development, VPN credentials, and a service account for CI. Someone DMs them over Slack. Five passwords in five messages. Each one sits in the channel history.
The developer joins, grabs the credentials, and moves on. The messages stay. Six months later, those credentials are still in Slack search, in the workspace export, in the backup. If anyone rotated them, good. If not, they're five live credentials in a searchable archive.
Where credentials end up during onboarding
› Slack DMs and channels (searchable, exportable, backed up)
› Email threads (archived, forwarded, backed up)
› Confluence or Notion pages (accessible to everyone with workspace access)
› Shared Google Docs (access permissions drift over time)
› Sticky notes on monitors
Each of these stores the credential longer than anyone needs it. The credential needed to get from one screen to another. Everything else is unintended persistence.
How to onboard securely
1 Collect the credentials the new developer needs. Group related ones if it makes sense: all staging credentials in one secret, all API keys in another.
2 Go to the tool and create a separate secret for each group. For .env files, attach them directly. Set the view limit to 1 and the expiry to 24 hours, enough time for the developer to grab them on day one.
3 Send the links over Slack, email, or whatever you normally use. Label each one: "Staging DB password," "AWS API key," ".env for local dev." The labels go in the message. The credentials stay behind the encrypted links.
4 The developer opens each link, saves the credentials to their password manager or local config, and the encrypted data is hard-deleted from the server. The Slack messages now contain dead links that point to nothing.
Why one secret per credential
If you bundle everything into one secret with a view limit of 1, the developer gets one shot to copy everything. If they miss something or the browser crashes mid-copy, the secret is gone. Splitting credentials into separate secrets means each one is independently accessible. If they need to come back for the VPN password, the .env file link still works (if they haven't opened it yet).
For the new developer
When you receive onboarding links, open each one and save the credential immediately. Copy passwords into your password manager. Save .env files to the right directory. The link works once. If you close the tab before copying, the credential is gone and someone will need to create a new link.
Don't screenshot the secrets. Don't paste them into your notes app. Save them where they belong and let the link die.
What about password managers?
If your team uses 1Password, Bitwarden, or similar, the long-term answer is to invite the new developer to the shared vault. But vault invites take time to process, and day-one access is often needed before the invite is accepted.
Secret.Broker handles the gap: the credentials that need to reach someone right now, before they're set up in the vault. See how password sharing works and sharing API keys.
The encryption
Your browser encrypts every credential before it leaves your machine. The server stores ciphertext it can't read. The protocol page documents the full stack, and the fragment security page explains why I never have the key.