Skip to content
Regolo Logo
Tutorial & How‑to

How to Use Roo Code with Private EU Inference in VSCode

Use Roo Code in VSCode with a private EU-hosted inference backend, then validate the setup on real repository tasks before rolling it out more widely.

Fabrizio Elvidio Pardo Bartolomeo
6 min read
Share

If we want to try Roo Code on real code without defaulting to a US-hosted backend, this is the shortest path. We keep the VSCode workflow, point it at an OpenAI-compatible endpoint, and test it on one real task before trusting it with anything bigger.

If the repo is public and disposable, the default path is usually fine. If the repo contains client logic, internal tools, or code that would trigger a security review, backend choice stops being a footnote. It becomes part of the decision.

That is why we are doing this.

We are not trying to make Roo Code feel exotic. We want a setup we can explain without hand-waving when somebody asks where the code goes.

What you will build

We will wire Roo Code to Regolo.ai, verify the API connection first, then test the setup on a small but real task. The flow stays familiar. The backend changes.

At the end, we will have:

  • Roo Code pointing to an OpenAI-compatible endpoint;
  • a live Regolo API key;
  • one model ID chosen from the current catalog;
  • a short validation routine for latency, output quality, and privacy posture.

Why this is worth doing

Most coding-agent demos skip the part that actually matters once real code is involved. They show output. They rarely talk about where prompts go, where outputs go, and what kind of backend we are trusting with repository context.

Regolo is useful here for a few concrete reasons that are already documented in the product materials:

  • the API is OpenAI-compatible;
  • the base URL is https://api.regolo.ai/v1;
  • inference runs in EU data centers, mainly in Italy;
  • prompts and outputs follow a zero data retention policy.

That does not solve every compliance issue by itself. It does remove one large source of friction: the default assumption that coding-agent traffic has to pass through a US-hosted closed-model backend.

What you need before opening Roo Code settings

Do this in order. It saves time.

1. Create a Regolo API key

Go to https://dashboard.regolo.ai and create a key in the Virtual Keys section.

If you already know the exact model you want, you can scope the key narrowly. If you are still comparing models, keep enough room to test more than one option. Locking the key too early is just busywork.

2. Check the live model catalog

Do not guess the model name from memory. Pull the live catalog first.

curl -X GET https://api.regolo.ai/models
Code language: JavaScript (javascript)

Then choose a model based on the actual task. Coding workflows are not one thing. A model that feels fine for code explanation may be mediocre for iterative edits or test generation.

Good starting evaluation tasks:

  • code explanation;
  • bounded bug fixing;
  • small refactors;
  • test generation;
  • patch review.

3. Confirm the endpoint with a tiny script

Before touching Roo Code, check that the key and endpoint work with a minimal Python call. That gives us one clean failure point instead of guessing whether the problem is the editor, the provider config, or the API key.

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_REGOLO_KEY",
    base_url="https://api.regolo.ai/v1",
)

response = client.chat.completions.create(
    model="MODEL_ID",
    messages=[
        {"role": "user", "content": "Explain what this Python function does in two sentences."}
    ],
)

print(response.choices[0].message.content)
Code language: JavaScript (javascript)

If this fails, fix it here. Do not move into Roo Code yet.

How to connect Roo Code to Regolo

This part is simpler than it looks. Roo Code versions can expose provider settings under slightly different labels, so we should stay honest about that. We are not relying on one exact button name. We are relying on three values that stay the same.

In Roo Code, pick the provider path that supports an OpenAI-compatible endpoint or custom OpenAI-style chat completions. Then set:

  • base URL: https://api.regolo.ai/v1
  • API key: your Regolo key
  • model: one live model ID from the catalog

That is the integration.

If your version supports environment variables, use them. Hardcoding credentials in project files is lazy and it creates a second problem right after solving the first one.

An illustrative mapping looks like this:

{
  "provider": "openai-compatible",
  "baseUrl": "https://api.regolo.ai/v1",
  "apiKey": "YOUR_REGOLO_KEY",
  "model": "MODEL_ID"
}
Code language: JSON / JSON with Comments (json)

That snippet is a mapping example. It shows the values we need. It is not a promise that every Roo Code build uses those exact field names.

What to test first inside Roo Code

This is where most people ruin the evaluation. They ask the model to write a toy function, it answers, and then they declare victory. That is not a useful test.

Use tasks that look like the work we actually want from a coding agent.

Start with this sequence:

  1. Ask Roo Code to inspect a real repository and summarize the structure.
  2. Ask it to explain one module you already know.
  3. Ask it to fix a small bug with a bounded file set.
  4. Ask it to generate or repair tests for that same area.
  5. Ask it to iterate once after feedback.

That last step matters. First drafts are cheap. Recovery after feedback is where the setup proves itself or falls apart.

What should stay the same, and what will change

The editor experience should still feel familiar. We are still in VSCode. We are still prompting, reviewing, and iterating.

What changes is the backend.

That means a few things can feel different:

  • latency;
  • model behavior;
  • how reliably the model handles long context;
  • how useful the edits feel on multi-step work.

Expect differences. If we expect identical behavior from every backend, we are not evaluating a workflow. We are just hoping.

The right question is more practical: does this setup stay useful enough for our real work while giving us a backend we can defend more easily?

Common mistakes

Why does Roo Code connect but give weak answers?

The first thing to check is the model choice. People blame the provider when they actually picked the wrong model for the job.

Why are the edits too broad?

That is often a prompt-scoping problem, not an endpoint problem. Give a bounded task, a target file set, and a clear expected outcome.

Why is the workflow slower than the default backend?

Because model behavior and latency differ. That is normal. Measure it on real tasks before deciding whether the tradeoff is acceptable.

Why should we verify the API outside Roo Code first?

Because it isolates the failure. If the Python call fails, the issue is not Roo Code. It is the key, the model, or the endpoint.

A short checklist before team rollout

Before we push this beyond one machine, check four things:

  1. The API key is scoped correctly.
  2. The model ID is current and available in the live catalog.
  3. The setup works on at least one real repository task, not a toy prompt.
  4. We can explain why this backend path is better for our codebase than the default one.

If we cannot answer those four, the setup is not ready for wider use.

FAQ

Does this require rewriting Roo Code itself?

No. The point is to keep the coding workflow and swap the backend through an OpenAI-compatible configuration path.

Does this make every coding workflow compliant?

No. It improves the backend posture. It does not remove responsibility for repository access, logging, storage, or internal review.

Should we use the biggest available model by default?

Usually no. Start from the task, not from the model size.

Is this better than self-hosting?

Sometimes yes, sometimes no. If we want open models without carrying the full infrastructure burden, this path is usually easier to move on quickly.

Start with one small repo task. Do not try to settle the whole decision in one afternoon.

Create a key, pick one live model, wire the endpoint, and test a bounded bug fix or test-generation loop. That is enough to tell us whether this setup deserves a second pass.


Start your free 30-day trial at regolo.ai and deploy LLMs with complete privacy by design.

👉 Talk with our Engineers or Start your 30 days free ->



Built with ❤️ by the Regolo team. Questions? regolo.ai/contact or chat with us on Discord