We're Fly.io, a security bearer token company with a public cloud problem. We've spent too much time talking about security tokens and Macaroon tokens in particular, but we needed to revisit them for our internal operations manuals. Macaroons are bearer tokens that use a chained-HMAC construction, allowing users to scope down existing tokens before every API operation. This feature is useful, but its cool factor has been tempered by user behavior, which doesn't take full advantage of token features. However, we've found unexpected wins in our infrastructure due to the quirks of Macaroons, including a simple database system called tkdb that manages security tokens for our platform. The tkdb system uses LiteFS and Litestream to provide subsecond replication and encryption, resulting in a small database size despite managing thousands of tokens. Our client libraries cache verifications, reducing the need for online-stateful token verification. We've also implemented a revocation system using a blacklist table that's periodically updated by our primary API server. Service tokens are another area where Macaroons have been useful, particularly in our orchestrator flyd, which uses a third-party caveat to minimize access to user secrets. Our token systems also provide excellent telemetry thanks to OpenTelemetry and Honeycomb, allowing us to monitor errors and track token operations. Overall, we've found that while users may not take full advantage of Macaroon features, the technology has been instrumental in improving our infrastructure and security posture.