Our team has recently standardized on Continue for our internal VS Code development, and while the productivity gains for individual engineers are well-documented, we've hit a significant operational hurdle. The primary challenge is managing the LLM provider API keys (specifically for OpenAI, Anthropic, and local models) across a development team of 15+ engineers. We cannot, for security and compliance reasons, have each developer use their own personal, billed API key, nor can we have a single key hard-coded into a shared `config.json` that gets checked into version control.
We've evaluated a few approaches, but each presents a distinct set of trade-offs regarding security, ease of onboarding, and maintenance overhead. I'm keen to hear what patterns other teams have successfully implemented.
Our considered options so far include:
* **Environment Variables:** Instructing each developer to set `OPENAI_API_KEY` and similar in their shell environment. This is decentralized and simple but fraught with issues. Onboarding new team members becomes a manual process, and there's no guarantee of consistency or that the variable is even set, leading to support tickets. It also doesn't solve for a centrally managed, team-funded key.
* **A Central, Version-Controlled Configuration with Placeholders:** Maintaining a team `config.json` in a private repository with placeholder values (e.g., `"apiKey": "${CONTINUE_OPENAI_KEY}"`). This requires a pre-launch script or environment setup process to inject the actual keys, which again shifts the burden to the individual's local machine setup.
* **External Secrets Management Service:** Using a service like HashiCorp Vault, AWS Secrets Manager, or even a dedicated internal microservice to fetch keys at runtime. This is the most robust from a security and central management perspective, but it requires modifying the Continue extension's core behavior or building a custom wrapper, which introduces complexity and maintenance liability.
* **Pre-configured Workspace Settings in `.vscode/settings.json`:** Utilizing VS Code's workspace settings, which can be shared, but this still leaves the key in plain text within the project's `.vscode` folder unless it references an environment variable, bringing us back to the first problem.
The core of the issue seems to be that Continue's configuration is inherently user-scoped, not project or workspace-scoped, in its current design. Has anyone devised a secure, scalable method to provision and rotate these API keys for a medium-to-large engineering team? I am particularly interested in solutions that integrate with existing identity providers or cloud infrastructure without requiring a fork of the extension. A detailed comparison of the administrative overhead versus security posture for each method would be immensely valuable.
Support is a product, not a department.