“Self-hosting” an AI coding assistant means different things depending on which tool you’re talking about, and conflating them leads to some expensive misunderstandings. This guide breaks down what AI coding assistant hosting actually involves for three popular tools — Cursor, Claude Code, and Continue.dev — because the honest answer is that they sit on genuinely different points of the self-hosting spectrum.
Before going further, one distinction matters more than any other in this space: hosting the development environment the assistant operates in is not the same thing as hosting the AI model’s weights yourself. Some tools let you do the first. Only some let you do the second. Getting this straight up front avoids provisioning infrastructure for a capability a tool doesn’t actually offer.
Two Different Things People Mean by “Self-Hosted”
- Hosting the agent/dev environment — running the assistant’s CLI, background agent, or execution sandbox on a server you control, so code execution, file access, and tool calls happen on your own infrastructure rather than a third party’s compute.
- Hosting the model itself — running the actual language model weights on your own hardware (typically via something like Ollama or a local inference server), so no inference request ever leaves your network.
Cursor and Claude Code both offer strong options for the first. Continue.dev is built specifically to support the second. Here’s how each one actually works.
Cursor: Self-Hosted Cloud Agents and Remote-SSH Devboxes
Cursor is primarily a desktop IDE, but it has two legitimate paths to running on your own infrastructure:
- Self-hosted cloud agents — Cursor’s enterprise offering lets teams run the agent’s execution environment inside their own network. A lightweight worker process connects outbound to Cursor’s cloud over HTTPS (no inbound ports or VPN tunnels required); Cursor’s cloud handles inference and planning, while tool calls — reading files, running tests, executing code — happen on your own Cursor server. Code and execution stay inside your infrastructure even though model inference still runs through Cursor’s cloud.
- Remote-SSH development — Cursor supports the same Remote-SSH model as VS Code: the editor UI runs locally while terminals, debuggers, and package management execute on a remote host. This is the standard way to point Cursor at a beefier dedicated server — useful when your local machine can’t handle the codebase, build times, or a GPU coding server workload the project depends on.
What Cursor does not do is let you swap in your own locally-hosted model weights in place of its cloud inference — the self-hosted agent feature keeps code execution local while model inference remains a cloud-side function.
Claude Code: Where “Hosting” Means the Dev Server, Not the Model
Claude Code runs locally in the terminal and talks directly to model APIs — there’s no separate backend server or remote code index involved in how it operates. For Claude Code hosting, that means the realistic infrastructure decision is where you run the CLI itself, not whether you can run the underlying model on your own hardware:
- Running Claude Code on a dedicated remote server — many teams SSH into a persistent dedicated dev server (often inside tmux or screen for long-running sessions) and run Claude Code there, keeping the full codebase, build tooling, and any GPU resources centralized rather than distributed across laptops.
- Headless use in CI/CD — Claude Code can run non-interactively inside pipelines, which is a genuine dedicated-server use case worth pairing with our guide on dedicated servers for CI/CD pipelines.
- Network requirement — Claude Code needs an active internet connection to reach its model provider; it isn’t designed to run fully air-gapped with local inference.
- Enterprise model routing — organizations can route Claude Code’s model calls through Amazon Bedrock, Google Vertex AI, or Microsoft Foundry instead of the direct Anthropic API, which keeps traffic inside an existing cloud account and VPC for compliance purposes — but this still means inference happens on a hyperscaler’s infrastructure, not on hardware you own outright.
In short: you can absolutely host the environment Claude Code runs in on your own dedicated server — and there’s a real performance and workflow case for doing so — but “self-hosting Claude Code” doesn’t mean running its underlying model without any network dependency.
Continue.dev: The One Built for Genuine Local Inference
Continue.dev is the outlier here, and deliberately so — it’s open source and designed from the ground up to work with either cloud model providers or fully local models served through tools like Ollama or LM Studio. This is where self-hosted AI for coding assistance genuinely means no inference request leaves your network:
- Local model serving — Continue.dev connects to a local inference server running open-weight coding models, with no dependency on an external API for core functionality.
- Data never leaves your infrastructure — for teams with strict data residency or IP protection requirements, this is the meaningful differentiator over Cursor or Claude Code, where at minimum an inference request reaches an external provider’s servers.
- Model quality tradeoff — open-weight coding models running locally are improving quickly, but teams should benchmark them directly against the task at hand rather than assume parity with the largest proprietary models.
This is also the path where Continue.dev hosting becomes a genuine infrastructure sizing question rather than just a network configuration one — you’re provisioning real compute for real inference, not just a lightweight execution sandbox.
GPU Coding Server Requirements for Local Model Inference
If you’re running Continue.dev (or any tool) against a genuinely self-hosted model, the hosting requirements look different from a typical dev environment:
- VRAM sizing drives everything — the model’s parameter count and quantization level determine minimum VRAM; undersized GPU memory forces slower CPU offloading or prevents the model from loading at all.
- Concurrent users multiply requirements — a single developer’s local model needs are very different from a shared team inference server fielding requests from an entire engineering org simultaneously.
- Fast storage for model loading — larger coding models can be tens of gigabytes; NVMe storage meaningfully cuts cold-start load times, a point covered in more depth in our guide to why NVMe storage is essential for modern AI and database workloads.
- Dedicated, unshared compute — inference latency degrades quickly under GPU contention; the same noisy-neighbor problem covered in bare metal servers vs cloud VMs for high-performance applications applies directly to shared GPU instances.
Securing Developer AI Infrastructure
Whichever path you take, AI coding assistants — cloud-routed or locally hosted — typically have broad access to source code, and often to API keys and credentials referenced within it. The same discipline covered in secrets management for production servers applies to developer AI infrastructure: scope any API credentials the assistant can access to the minimum required, and treat a dev server running an AI agent with the same network protections as any other production-adjacent system.
Choosing an Approach
| Factor | Cursor | Claude Code | Continue.dev |
|---|---|---|---|
| Can host execution environment yourself | Yes (self-hosted cloud agents, Remote-SSH) | Yes (run CLI on your own server) | Yes (fully local by design) |
| Can host the model itself | No — inference is cloud-side | No — always talks to a model API (direct or via Bedrock/Vertex/Foundry) | Yes — designed for local model serving via Ollama/LM Studio |
| Requires internet connection | Yes | Yes | No, if fully local |
| Best fit | Teams wanting Cursor’s UX with code execution kept in-network | Teams centralizing dev environments on dedicated servers or CI | Teams needing genuine data isolation or offline capability |
How BeStarHost Supports AI Coding Infrastructure
Whether you’re centralizing developer dev environments, running Claude Code or Cursor’s self-hosted agents on your own servers, or standing up a genuinely local inference server with Continue.dev, the infrastructure fundamentals are consistent:
- Dedicated servers with guaranteed, unshared CPU and RAM for centralized development environments and CI-integrated coding agents.
- NVMe storage across server tiers, keeping model loading, dependency installation, and large codebase I/O fast.
- Dedicated, unshared bandwidth on a global low-latency network — relevant for both cloud-routed assistants and remote-SSH development workflows.
- 99.9% uptime on Tier 3 / Tier 4 hardware with RAID 0 / RAID 1 configurations, so a centralized dev server doesn’t become a single point of team-wide failure.
- IPMI KVM-over-IP for direct remote access when configuring a devbox or troubleshooting a local inference setup.
- 14 global data center locations across Europe (France, Germany, Netherlands, United Kingdom), Asia (Singapore, Hong Kong, India, South Korea, Taiwan, Philippines, Myanmar, Cambodia), and North America (United States, Canada) — letting you place developer infrastructure close to your team.
- No setup fees and 24/7/365 support if you’re architecting a centralized AI-assisted development environment.
Explore our dedicated server plans, read more on our About Us page, or contact our team to scope infrastructure for your development environment.
Frequently Asked Questions
Can you run Claude Code without an internet connection?
No. Claude Code runs locally in the terminal but requires an active internet connection to reach its model provider, whether that’s the direct Anthropic API or an enterprise routing option like Amazon Bedrock, Google Vertex AI, or Microsoft Foundry. It doesn’t run the underlying model on local hardware.
What does Cursor’s self-hosted cloud agent feature actually keep on your infrastructure?
Cursor’s self-hosted cloud agents keep code execution and tool calls — reading files, running tests, executing commands — inside your own network via a lightweight worker process. Model inference and planning still run through Cursor’s cloud; the feature isolates code execution, not model hosting.
Which AI coding assistant supports fully local, offline model inference?
Continue.dev is built specifically to support this, connecting to local inference servers such as Ollama or LM Studio so that inference requests never leave your network. Cursor and Claude Code both require a connection to a cloud-hosted model provider.
Do I need a GPU to self-host a coding AI model?
For practical response times with modern coding models, yes — CPU-only inference is typically too slow for interactive coding assistance. VRAM requirements scale with model size and quantization level, and shared team usage requires proportionally more GPU capacity than a single developer’s local setup.
Is it worth running Claude Code or Cursor on a dedicated remote server instead of a laptop?
For teams working with large codebases, long-running agent sessions, or workloads that benefit from centralized GPU or compute resources, running these tools on a dedicated server via SSH or a persistent terminal session avoids being constrained by local machine specs and keeps the development environment consistent across a team.
Centralizing AI-assisted development on infrastructure you control? Talk to BeStarHost about dedicated servers built for developer AI infrastructure →