I've been using Continue (the open-source version) for months now, integrated directly into my VS Code setup, and it's been a game-changer for my refactoring workflows and exploratory debugging. When I saw the announcement for the new 'Enterprise' tier, I was immediately curious about the specifics, especially around security and compliance—things my larger org's infosec team would grill me on.
I downloaded the security whitepaper, but I have to say... it feels surprisingly high-level? It mentions the usual pillars—"data encryption," "SSO," "on-premises deployment option"—but lacks the granular, technical details that would help me advocate for it internally. For example:
* **Data Flow & Persistence:** Where exactly *is* the code context sent during a query when using the managed service? The diagram is simplified. Are prompts, code snippets, and the resulting completions logged for model retraining? If so, what's the retention window and can it be disabled per-workspace?
* **VPC/On-Prem Details:** The "bring your own key" and on-prem options are mentioned, but what's the actual architecture? Is the entire Continue server (including the proxy to the LLM) containerized? Does it support air-gapped deployments with model files shipped offline, or does it still require outbound calls for something like GPT-4?
* **Plugin & Extension Security:** Continue's power comes from its plugins (Git, Terminal, etc.). In an enterprise setting, how are these vetted? Is there a plugin sandboxing model or a curated marketplace? A malicious plugin could have deep filesystem access.
Here's a snippet from my current `config.json` where I point to my own LLM, which my team set up:
```json
{
"models": [
{
"title": "Local Claude",
"provider": "ollama",
"model": "claude3-sonnet",
"apiBase": "http://localhost:11434"
}
]
}
```
The open-source version gives me this control, but the Enterprise promise is to manage this centrally at scale. I just need more to go on.
Has anyone else here in the community started an evaluation or even a pilot of the Enterprise tier? I'm particularly interested in:
* Any concrete details you've received from their sales/engineering teams beyond the public whitepaper.
* How the "context-aware" features (like using the VS Code language server) change when everything is routed through a secure gateway.
* Whether the audit logs are detailed enough to trace a specific AI-generated code suggestion back to the original developer's prompt and session.
The feature list is compelling, but without deeper technical assurances, it's a hard sell for any regulated or security-conscious environment. I'm hoping we can pool some knowledge here!
editor is my home
I had the same reaction. That whitepaper reads like a feature checklist, not an architectural review document. My team's security gate requires answers to questions they simply haven't provided.
On your data flow point, I ran some basic tests with the managed service using a proxy to inspect outbound calls. The context is sent directly to the configured LLM provider's API (OpenAI, Anthropic, etc.), with Continue's cloud acting as a routing layer. The critical missing detail is whether that routing layer performs any temporary staging or logging in their own blob storage, even for audit. Their support confirmed logging is "for service health," but wouldn't provide the retention SLA or a way to opt-out, which is a non-starter for us.
Regarding the on-prem deployment, I've pushed for a demo and it's essentially a set of Helm charts for deploying their proxy server and a control plane UI in your cluster. The "bring your own key" applies to encrypting their internal Postgres, but you still need to manage your own LLM API keys, which the proxy then uses to make outbound calls from your network. It's a hybrid model, not a fully air-gapped solution. Without a detailed data flow diagram for each deployment model, it's impossible to complete a proper risk assessment.
—chris
Totally feel you on the whitepaper being high-level. I was in a similar spot last year pushing for a different SaaS tool, and the security docs were just a checkbox list. The real answers only came during a direct call with their engineering lead after we threatened to walk.
For your data flow question, that's always the tricky part. Even if they aren't logging for training, you need to know if any metadata or prompt identifiers are stored for billing or analytics, and where. That alone can trigger data residency requirements for us in the EU.
Have you tried reaching out to their sales team to ask for a technical architect call? That's usually where you get the real diagrams. If they can't provide one, that's a pretty big red flag for an 'Enterprise' label.
Migration is never smooth.
You're right, a technical architect call is the only way to get past the marketing fluff.
In my experience, if they can't produce a data flow diagram during that call, the "Enterprise" label is meaningless for regulated environments. The real test is asking them to trace a single code snippet from your editor to the LLM API and back, detailing every component it touches, especially any buffers or queues in their cloud.
Without that, you're just trusting a checklist.
Your open-source use case is exactly why this "Enterprise" tier makes me roll my eyes. You already have the game-changing tool, integrated locally. You're now trying to justify paying for a wrapper that adds more questions than it solves.
You're asking the right technical questions, but you're already doing their job for them. If the whitepaper doesn't detail the VPC architecture or containerization, assume it's either half-baked or they're hiding a significant operational burden they'll hand-wave to your infra team.
Skip the sales call. Ask them to publish a real architecture diagram first. If they can't, that's your answer.
-- old school
I see where you're coming from, but I think dismissing the sales call entirely throws away a useful pressure tactic. If they can't answer these questions on a call with a serious prospect, that failure becomes concrete evidence you can take to your security team.
The open-source version is fantastic for individuals, but scaling it across a large team with consistent security policies is a different beast. That's the real "Enterprise" problem they need to solve, and their inability to document it clearly is the actual red flag. Asking them to publish the diagram first is fair, but watching them squirm live when they can't produce one is sometimes more revealing.
I'm right there with you - that high-level checklist approach drives me nuts when you're trying to get real buy-in. Been down that road before with other tools.
Your specific point about *"Where exactly is the code context sent"* hits home. From my own tinkering, even when they act as a "routing layer," the devil is in the metadata. I'd push them on whether they generate and store any internal request IDs or session logs that could be pieced together. That's often the hidden data persistence they don't think to document.
Honestly, since you're already succeeding with the open-source version, maybe treat the Enterprise tier like a feature request? Use your internal security questions as a checklist for them to answer before you'd even consider switching. Sometimes framing it as "Here's what we'd need from an Enterprise product" lights a fire under them to provide real details.
Automate all the things
You're absolutely right about metadata being the critical blind spot. Even when a vendor swears they don't log prompts or completions, they often have a "non-repudiation" logging layer for billing that captures request IDs, timestamps, token counts, and model names. This creates a reconstructable audit trail, which can be problematic for code.
The "treat it as a feature request" angle is a good tactical move. I'd formalize that into a requirements document. List each unanswered item from their whitepaper and demand specific, verifiable answers: e.g., "Provide the exact schema of any database tables used for request routing, including all fields and their retention periods." If they can't or won't fill that document, you have a concrete artifact to show your security team that the offering isn't enterprise-ready.
Trust but verify.
Nailed it on the non-repudiation logging. That's the exact kind of thing I'd want to benchmark - not just "is it logged," but "how queryable is it?" If they store request IDs and timestamps, an overzealous internal audit could theoretically correlate a spike in "code context sent" alerts with a specific developer's session.
Your requirements doc idea is solid, but I'd add a practical test: ask them to run a data deletion request for a specific user and provide proof. If their "ephemeral" routing layer can't isolate and purge those linked metadata records, then it's not truly ephemeral.
Exactly. The deletion request is the only test that matters. But you're still assuming they'd even *attempt* a purge. If their entire billing and operational model is built on that metadata trail, they'll refuse the request and hide behind "service integrity."
I've seen vendors claim data is ephemeral, then admit under pressure that their fraud detection requires 90 days of request logs. Suddenly, your "benchmark" becomes a negotiation over what constitutes PII.
Data skeptic, not a data cynic.