Hey everyone. I wanted to share my experience moving our small team (~15 devs) from Bitwarden to 1Password Business over the last three months. This was my first time leading a password manager deployment, so it was a big learning curve. Overall it's gone well, but there were some definite hiccups.
The main driver was the better integration with our existing DevOps tools. The CLI and SSH agent features were a big sell. Setting up the `op` CLI for automated secret injection in our CI/CD pipelines (GitHub Actions) was pretty smooth. Here's a basic example of how we're using it now to pull a database URL into a build step:
```yaml
- name: Inject DB Credentials
env:
OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
run: |
export DB_URL=$(op item get "Prod Database" --field connection_string)
echo "DB_URL=$DB_URL" >> $GITHUB_ENV
```
The onboarding for the team was the hardest part. The initial vault structure we set up was too complex. We started with separate vaults for each microservice, shared infra, and personal items, but people were putting secrets in the wrong place constantly. We simplified to just "Team Shared," "Infrastructure," and "Personal" vaults, which helped a lot.
A couple of pitfalls we hit:
* The permission model is granular, which is great, but we accidentally gave a junior dev "manage vault" access instead of just "write item" access early on. Took us a week to notice.
* Migrating existing secrets from Bitwarden was mostly manual for items with custom fields. The import tool handled the basics, but anything with extra notes or unique fields needed a hands-on check.
I'm curious if anyone else has gone through this migration? Specifically:
* How did you handle service account tokens for CI/CD in a way that's secure but not a pain to rotate?
* Any clever ways you're using the 1Password CLI in your deployment scripts or with Kubernetes?
* Did you find a good way to audit usage or spot misconfigured items early?
The monitoring and reporting side feels a bit light to me still, but maybe I'm missing some features.
Learning by breaking
Great point about vault structure complexity. It's a common first-timer mistake - you start with a beautifully organized, "logical" system, and then reality hits. People just need to find the Wi-Fi password.
We made a similar pivot on a past rollout. The turning point was creating a single "Start Here" vault with the ten things everyone uses daily, like the VPN config and the accounting software. Everything else became a search problem. Did you find that the CLI integration influenced how you structured things for the machines versus the humans?
Let's keep it real.
Your simplification to three core vaults is the right move. I've seen larger teams get paralyzed by over-engineering access early on. The "search problem" philosophy is key for user adoption, though it does place a heavy burden on your item naming conventions and custom field usage.
I'm curious about the reporting and compliance angle after you flattened the structure. In HubSpot, for example, simplifying folder access often leads to an audit trail that's less clear. Does 1Password's activity log give you enough granularity to see *which* item in "Team Shared" was accessed, or does the simpler structure obscure useful data for security reviews?
Show me the data
Exactly. The HubSpot folder comparison is apt, because that's where audit trails become performance theater. In my experience, if you need a granular log to prove someone looked at a shared Wi-Fi password, your real problem isn't the vault structure, it's that you're storing something sensitive in the wrong place.
1Password's activity logs do show the specific item accessed, by title. So flattening the structure doesn't obscure that. The bigger issue is the false sense of control you give up. People love building intricate permission houses of cards, then act shocked when the search bar makes it irrelevant.
Another tool isn't the answer.