Self-Host Continue.dev With Ollama on a VPS

Continue.dev looks like “just a VS Code extension” until you trace where your prompts and file context go. If you want a private coding assistant in 2026, the simplest path is to self-host Continue.dev by pointing it at an LLM you run with Ollama. That keeps third-party APIs out of the loop.

This walkthrough installs Ollama on an Ubuntu VPS, publishes it safely over HTTPS, and connects Continue from your laptop’s VS Code. By the end, you’ll have an assistant that can reason over your repo without sending source code to an external provider.

What you’ll build (and what you won’t)

• Build: Ollama running on an Ubuntu VPS, reachable via a reverse proxy with TLS and authentication.
• Build: Continue.dev in VS Code configured to use your private Ollama endpoint.
• Optional: Restrict access with a VPN or IP allowlist for tighter control.
• Not building: A multi-user chat UI (use a separate front-end if you need that).

If you want a tighter, Nginx-first hardening guide, HostMyCode has a solid companion tutorial on running Ollama behind Nginx with Basic Auth. This post focuses on the Continue connection, using the same building blocks.

Infrastructure sizing: CPU, RAM, and realistic expectations

Ollama runs fine on CPU-only VPS hardware if you pick a model that fits your box. “It starts” is not the same as “it’s usable inside VS Code.”

• Minimum (CPU-only): 4 vCPU, 8 GB RAM, NVMe storage. Fine for small quantized models, but responses will be slower.
• Recommended (CPU-only): 8 vCPU, 16–32 GB RAM. Much more comfortable for day-to-day “explain this code” work.
• GPU notes: A GPU server will cut latency a lot. This tutorial stays CPU-friendly and works on standard VPS plans.

RAM is usually the limiter. Smaller parameter models with quantization (for example, “Q4” variants) tend to be the sweet spot on VPS budgets.

Larger models may still run, but you’ll feel it. Expect swapping, stutters, or responses so slow they break your flow.

If you need consistently low latency for several developers, move to a larger instance or a dedicated machine. HostMyCode offers HostMyCode VPS plans that work well for private developer tooling.

You can step up to dedicated servers once shared CPU time becomes the bottleneck.

Prerequisites

• An Ubuntu server (this tutorial assumes Ubuntu LTS on a VPS) with root or sudo access
• A domain or subdomain you control (for example ollama.example.com)
• DNS A/AAAA record pointing to your VPS
• VS Code on your local machine

If you’re moving DNS and want the cutover to be boring, skim HostMyCode’s DNS cutover tutorial first. Come back after the new record resolves.

Step 1: Prepare the VPS (updates, firewall, and a non-root admin)

SSH in, update packages, and install the tools you’ll use throughout the setup:

sudo apt update
sudo apt -y upgrade
sudo apt -y install curl ca-certificates gnupg ufw nginx apache2-utils

Keep the firewall tight. For this stack, you only need SSH, HTTP, and HTTPS:

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

If you don’t want to babysit updates, set unattended upgrades now. HostMyCode’s guide on automated security updates is a good default.

Public AI endpoints attract attention. Staying patched is non-negotiable.

Step 2: Install Ollama and run a model

Install Ollama using the official script. On Ubuntu, it also creates a system service.

curl -fsSL https://ollama.com/install.sh | sh

Verify the service is up:

sudo systemctl status ollama --no-pager

Ollama binds locally by default. Keep it that way, and put Nginx in front.

Next, pull a model. Start modest:

ollama pull llama3.1:8b

If your VPS is smaller, go smaller here too. Optimize for “good enough for refactors and quick explanations,” not bragging rights.

Quick local test on the server:

ollama run llama3.1:8b

Try a prompt like “Explain what a reverse proxy is in two sentences.” If it replies, you’re ready to add HTTPS.

Step 3: Put Ollama behind Nginx with TLS and authentication

Don’t expose a raw LLM port to the internet. It will get found. You’ll pay for somebody else’s CPU time.

We’ll proxy requests to the local Ollama port (commonly 127.0.0.1:11434). We’ll also require Basic Auth.

First create an htpasswd file:

sudo mkdir -p /etc/nginx/auth
sudo htpasswd -c /etc/nginx/auth/ollama.htpasswd continue

Create an Nginx site config:

sudo nano /etc/nginx/sites-available/ollama

Paste this (replace the server name):

server {
  listen 80;
  server_name ollama.example.com;

  location / {
    return 301 https://$host$request_uri;
  }
}

server {
  listen 443 ssl http2;
  server_name ollama.example.com;

  # TLS will be filled by Certbot

  client_max_body_size 50m;

  location / {
    auth_basic "Private Ollama";
    auth_basic_user_file /etc/nginx/auth/ollama.htpasswd;

    proxy_pass http://127.0.0.1:11434;
    proxy_http_version 1.1;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # Ollama responses can be streamed; keep buffering off
    proxy_buffering off;
    proxy_read_timeout 300s;
  }
}

Enable the site and reload Nginx:

sudo ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/ollama
sudo nginx -t
sudo systemctl reload nginx

Now add a Let’s Encrypt certificate. If you want a refresher, HostMyCode’s TLS setup guide covers common failure modes like renewals and mixed-content mistakes.

sudo apt -y install certbot python3-certbot-nginx
sudo certbot --nginx -d ollama.example.com

Test from your local machine:

curl -u continue https://ollama.example.com/api/tags

You should get JSON listing available models. A 401 means auth is being enforced (good).

A 502 usually means Ollama isn’t running, or Nginx can’t reach 127.0.0.1:11434.

Step 4: Lock it down further (recommended)

Basic Auth is a start, not the finish line. Pick one option below based on how and where you work.

Option A: Only allow your IP addresses

If you have a stable office IP (or a small list of developer IPs), add an allowlist in Nginx:

location / {
  allow 203.0.113.10;
  allow 198.51.100.22;
  deny all;

  auth_basic "Private Ollama";
  auth_basic_user_file /etc/nginx/auth/ollama.htpasswd;

  proxy_pass http://127.0.0.1:11434;
  ...
}

Option B: Put it behind a VPN (best for roaming laptops)

WireGuard gives you consistent private access even when your IP changes. HostMyCode’s walkthrough for setting up WireGuard on Ubuntu covers the full setup.

Once you’re on the VPN, restrict Nginx to the VPN subnet.

Option C: Add Nginx rate limiting

If credentials ever leak, rate limiting caps the blast radius. HostMyCode’s HostMyCode’s Nginx rate limiting tutorial shows the mechanics.

Treat LLM endpoints like any other expensive backend.

Step 5: Install Continue.dev in VS Code

On your local machine:

1. Open VS Code.
2. Open the Extensions panel.
3. Search for “Continue” (Continue.dev) and install it.

Continue reads configuration from a JSON file. The exact path varies by OS and Continue version.

The fastest way to find it is through the Continue settings UI. Choose “Open config file” (or similar), and VS Code will jump there.

Step 6: Configure Continue to use your Ollama endpoint

Continue needs two pieces of information:

• Base URL: your HTTPS endpoint (https://ollama.example.com)
• Auth header: Basic Auth so the extension can connect

Generate a Basic Auth header value on your local machine. This produces the payload for Authorization: Basic ... that Continue can send.

printf 'continue:YOUR_PASSWORD' | base64

Copy the output. Then open Continue’s config and add an Ollama model entry.

Here’s a practical example (adjust the model name to whatever you pulled):

{
  "models": [
    {
      "title": "Private Ollama (VPS)",
      "provider": "ollama",
      "model": "llama3.1:8b",
      "apiBase": "https://ollama.example.com",
      "requestOptions": {
        "headers": {
          "Authorization": "Basic BASE64_GOES_HERE"
        }
      }
    }
  ]
}

Security note: this stores credentials on your workstation. If that’s a deal-breaker, prefer the VPN-only approach and remove Basic Auth.

Another option is an auth gateway that supports short-lived tokens. For solo use, Basic Auth is usually a reasonable trade-off if your laptop disk is encrypted.

Reload VS Code, open Continue, and try a prompt against a file in your repo:

• “Summarize what this function does.”
• “Suggest a safer way to parse this input.”
• “Write unit tests for this module.”

If everything is wired correctly, you’ll see streaming output. If it stalls, jump to the troubleshooting section.

Step 7: Test the endpoint from the VPS and from your laptop

Test both sides. It saves time when TLS or auth is misconfigured.

From the VPS (local health check)

curl http://127.0.0.1:11434/api/tags

From your laptop (real path, TLS, auth)

curl -u continue https://ollama.example.com/api/tags

Finally, test an inference call (example payload). This confirms the proxy settings aren’t breaking streaming or timeouts:

curl -u continue https://ollama.example.com/api/generate \
  -H 'Content-Type: application/json' \
  -d '{"model":"llama3.1:8b","prompt":"Say hello in one sentence.","stream":false}'

Quantization and model choice: practical trade-offs for coding help

Quantization decides whether your model fits comfortably or turns your VPS into a swap-fest. It also affects output quality.

For code assistance, the trade usually looks like this:

• Smaller / heavier quantization: faster and cheaper, but more brittle reasoning and more syntax mistakes.
• Larger / lighter quantization: better suggestions, but higher latency and more memory pressure.

Start with the smallest model that feels responsive. Move up only when you can name a concrete problem (weak refactors, poor test generation, inconsistent style).

Bigger isn’t automatically better if you’re waiting on every completion.

Operational hardening checklist for a self-hosted coding assistant

• Keep Ollama bound to localhost and expose only via Nginx.
• Enforce TLS (Let’s Encrypt + renewals working).
• Use auth (Basic Auth at minimum; VPN is better).
• Limit who can reach it (IP allowlist or VPN subnet restrictions).
• Monitor resource use so your VPS doesn’t starve other services.
• Patch the OS and reboot for kernel updates on schedule.

For monitoring, keep it lightweight and visible. HostMyCode’s Netdata monitoring guide fits this stack well.

It makes CPU pegging and memory pressure obvious within minutes.

Troubleshooting: the failures you’ll actually see

502 Bad Gateway from Nginx

• Check Ollama is running: sudo systemctl status ollama
• Confirm it’s listening locally: ss -lntp | grep 11434
• Check Nginx error log: sudo tail -n 50 /var/log/nginx/error.log

Continue connects but responses are very slow

• Your model is too large for CPU-only inference. Switch to a smaller model or increase vCPU/RAM.
• Confirm your VPS isn’t swapping: free -h and vmstat 1
• Make sure no other workloads are saturating CPU.

Auth keeps failing from Continue

• Recreate the base64 string and ensure there’s no newline copied.
• Verify the header is exactly Authorization: Basic ...
• Test with curl using the same credentials.

Let’s Encrypt renewal issues

If renewals fail, fix it sooner rather than later. A broken cert will stop Continue from connecting.

Run:

sudo certbot renew --dry-run

Where HostMyCode fits for private AI tooling

For one developer (or a small team), this runs comfortably on a right-sized VPS with enough RAM for your model.

If you’d rather not spend time on OS patching and baseline hardening, managed VPS hosting keeps the boring parts maintained while you focus on shipping.

FAQ

Is it safe to self-host Continue.dev with Ollama over the public internet?

It can be, as long as you don’t expose Ollama directly. Put it behind TLS and authentication, then restrict access with a VPN or IP allowlist. Rate limiting helps reduce abuse if credentials leak.

Do I need a GPU VPS for this?

No. A CPU-only VPS works if you choose a smaller quantized model and accept higher latency. If you want near-instant suggestions, a GPU server will feel much better.

Will my code be sent to a third party?

Not if Continue is configured to use your private Ollama endpoint and you don’t add external providers. Your prompts and retrieved context go only to your VPS.

Can multiple developers share one Ollama VPS?

Yes, but plan for concurrency. Each active user increases CPU/RAM pressure. Start small, then scale up to a larger VPS or a dedicated server if the box stays pegged.

Summary

You now have Continue.dev in VS Code talking to an Ollama model you control, served over HTTPS with authentication. That gives you a practical private coding assistant without handing your repositories to third-party APIs.

If you want a stable base for this kind of setup, run it on a right-sized HostMyCode VPS and operate it like a real service: TLS, access control, monitoring, and routine patching.