Independent testing Updated April 2026 387 self-hosting guides 5 VPS providers tested

comparison

Best VPS for OpenHands (2026): Real Specs for the Coding Agent

OpenHands needs more than its docs admit. Here is the VPS spec that actually survives a long task, and the cheap one that will OOM on the first build.

Best VPS for OpenHands (2026): Real Specs for the Coding Agent

OpenHands is the project formerly known as OpenDevin, now at 74K plus GitHub stars and shipping monthly. The hosting picture changed a lot in early 2026 when the team pulled the runtime out of the main process and into a Docker sandbox. Good for safety. Painful if you read the old docs and provision a 2 GB VPS.

I have been running OpenHands as my background coding agent for nine weeks. Here is what the spec sheet does not tell you.

What OpenHands Actually Needs

Three resource sinks, in order of how often they bite people:

  1. The sandbox. Docker-in-Docker, with a runtime image that ranges from 800 MB to 2.5 GB depending on the language stack. Every active task spawns one.
  2. Build and install steps. When the agent decides to run npm install or pip install on a real repo, RAM usage spikes hard.
  3. The model. If you also self-host the LLM on the same box, you need a GPU and a different tier of hardware entirely.

Most users want path 1 plus 2 on a CPU box, with the model living on Anthropic or OpenAI. That is the setup the rest of this page covers.

VPS Comparison for OpenHands

ProviderPlanvCPURAMDiskMonthlyBest fit
Hetzner CloudCCX23416 GB160 GB NVMe29.74 EURDefault daily-driver pick
Contabo VPSVPS M616 GB400 GB NVMe8.50 EURBudget pick if you do not mind slow provisioning
DigitalOceanPremium AMD 4 GB28 GB100 GB NVMe28 USDUS team, low task volume
VultrHF General 16 GB416 GB320 GB NVMe48 USDWhen you need many concurrent sandboxes

Hetzner Cloud CCX23: My current pick

The CCX line is the sweet spot for OpenHands. CCX13 with 8 GB works for solo light use, but the moment you ask the agent to do two things in parallel you want CCX23. NVMe matters because the sandbox writes a lot during builds, and Hetznerโ€™s I/O is consistent in a way Contaboโ€™s older nodes were not.

What works for OpenHands here:

Downside: outbound bandwidth is 20 TB included, which sounds like a lot until the agent decides to clone five gigabyte repos in a loop. Watch the meter.

Provision Hetzner: Hetzner Cloud.

Contabo VPS M: The 8 EUR sleeper

Hard to argue with 6 vCPU and 16 GB for 8.50 EUR. On the newer NVMe plans, the I/O profile is fine for OpenHands. The two real downsides: provisioning takes hours rather than seconds, and outbound latency to the major model APIs is consistently 100 to 200 ms worse than Hetzner. If you keep the box running long term it is fine. If you spin up and tear down a lot, the wait time is brutal.

Pros:

Negative I will not gloss over: their support reply times on the cheaper tiers can stretch into days.

Get Contabo: Contabo VPS.

DigitalOcean Premium AMD: For US teams

If your model endpoint is in US-east and your team is too, DigitalOceanโ€™s NYC3 nodes cut a round trip out of every model call. The 8 GB tier handles a single OpenHands worker, but I would not run more than one heavy sandbox on it. The newer Premium AMD nodes are noticeably snappier than the older shared CPU plans, worth the price bump.

Honest downside: 28 USD for 8 GB is steep against Hetznerโ€™s EU pricing. Pay it if latency matters more than EUR per gigabyte.

Set up DigitalOcean: DigitalOcean.

Vultr HF General 16 GB: For multi-sandbox workloads

If you are using OpenHands as a team tool and need three or four concurrent sandboxes, Vultrโ€™s High Frequency line is the easiest place to land. The 16 GB plan with 4 vCPU is enough headroom that no single task starves the others, and Vultrโ€™s worldwide region map matters when your team is split across continents.

Get Vultr: Vultr.

Common Gotchas When Self-Hosting OpenHands

Three things that tripped me up:

  1. Docker socket exposure. The sandbox needs the host docker socket. That is fine on a single-user VPS, dangerous on a shared one. Do not run OpenHands as a service for untrusted users without a separate runtime user.
  2. Cleanup. Old sandbox containers accumulate fast. Set up a daily docker container prune or you will run out of disk inside a week.
  3. Memory limits. Cap each sandbox at 4 GB explicitly. Without limits, a runaway npm install will eat the whole VPS and crash the orchestration layer with it.

What I would actually pick

Starting today and you want OpenHands as your background coder:

For the broader self-hosting picture, see the SelfHostVPS comparison. OpenHands moves fast, so I refresh this page after major sandbox or runtime changes hit main.

Frequently asked questions

What is the minimum VPS for self-hosting OpenHands?

4 vCPU and 8 GB RAM is the floor if you bring your own model API key. The agent runs the runtime in a Docker-in-Docker sandbox, which is heavier than people expect. On 2 GB RAM the sandbox container OOMs the moment the agent installs npm packages or compiles anything. Plan for 16 GB if you do anything beyond toy tasks.

Does OpenHands need a GPU on the VPS?

No, unless you also self-host the model. OpenHands itself is a Python orchestration layer plus a sandboxed runtime, all CPU bound. The compute that matters is the model behind your API key. A CPU-only Hetzner CCX or Contabo NVMe box works fine when you point it at Anthropic, OpenAI, or a remote vLLM endpoint.

Can OpenHands run on a 5 dollar Contabo VPS?

Technically yes, in single-task mode with the smallest sandbox image. In practice it will swap heavily and any task that pulls a Node toolchain or runs a Python test suite tips it over. Spend the extra 5 EUR for the next tier and you avoid a week of frustration.

Why does OpenHands use so much disk?

The sandbox pulls a Docker image per task type, and the agent keeps repo clones, build artifacts, and a per-conversation state directory. 80 GB NVMe is the realistic minimum for daily use. After a month of mixed Python and TypeScript work I have seen the working set climb to 30 GB before pruning.