Dynamic authorization tokens

[ari-becker]

🚀 Feature Proposal

Currently, TURBO_TOKEN is defined as an environment variable, therefore making changes to the token(s) requires a full restart. Instead, authorized tokens should be stored in a database, and a UI or API should be exposed to add or remove tokens from that database; ideally allowing users some kind of SSO login flow which ends in issuing them a token.

Motivation

We're looking at alternatives to Vercel hosting the Turbo remote cache, because Vercel charges $20/user/month. If we do pay Vercel $20/user/month, then each user gets their own API token, and removing a user from Vercel also invalidates their access to the cache. We'd like to self-host the cache, but manually maintaining a list of tokens is an operational headache we'd like to avoid. If we were to decide to restrict ourselves to use only one API token (and share that API token via 1Password etc.), then we might as well make a shared Vercel user on Vercel's free tier for that purpose.

[fox1t]

I like this proposal. I wouldn't say I like adding a DB. It could be an optional DB, though. I also like the idea of having a UI.

[lukeshay]

Maybe TURBO_TOKEN token could be updated to handle a comma-separated list of tokens. E.g. TURBO_TOKEN=token1,token2,token3. That way no DB is required and you can add/remove multiple tokens.

[ari-becker]

I ended up switching companies, but the way we planned around this limitation was, instead of running a turborepo-remote-cache from a central location (thus prompting the whole question of a shared token vs. multiple tokens), instead we planned to run turborepo-remote-cache locally, a separate copy on each dev laptop + instantiate at runtime in CI, with a shared storage provider (e.g. S3). Thus each developer would be responsible for providing personal credentials, and CI would use CI's credentials, to connect to the same S3 bucket, for example.