| Lots of really great questions in here! Starting at the top- The process demoed in the video is for user-based auth. Service tokens can be issued programmatically and provide read-only access to one config. You can pass these into your environment via puppet and other configuration tools, or even via LDAP, in much the same way you bootstrap other OS config like SSH keys. I really like your thoughts around more niche access roles, and it's definitely where we're headed. Admittedly our RBAC is currently more limited with a basic Member, Admin, Owner model. We do have existing audit capabilities for monitoring secrets changes (without revealing the actual secrets) and support shipping those logs to Slack or a webhook. Audit history is based on your specific plan[0], but we currently offer up to a year. Some customers do have requirements for longer time periods and we can easily configure that for them. Regarding your last point, this is what we refer to as secret referencing. You can absolutely reference secrets across different configs and projects to avoid repeating common values. Here's our announcement from when we shipped this feature back in August[1]. [0] https://doppler.com/pricing [1] https://doppler.com/changes/secrets-referencing |