Polymarket Bot Tutorial · Chapter 4 of 32

A VPS keeps your Polymarket bot alive when your laptop cannot - lid closed, Wi-Fi dropped, mid-reboot. This is the honest version: when a VPS is actually worth paying for, what to look for, the host we run our own bots on, and a copy-paste setup checklist.

By Harley Young, lead writer at Polymarkets.co.il. Last reviewed: June 2026.

What this chapter covers

You do not need a server to learn Polymarket, and you do not need one to paper-trade a strategy on your own machine. You need one the day a bot starts managing real positions on its own, because at that point a closed laptop is a missed exit. This chapter keeps it practical: when a VPS earns its cost, what actually matters when you pick one, the host we use, and the exact commands to set it up.

  • Why a VPS instead of a laptop
  • Whether you even need one yet
  • What to look for in a host
  • The host we run our own bots on
  • Region choice (NY4 vs LD4 vs AMS3)
  • Sizing: vCPU, RAM, network
  • A setup checklist for a Polymarket bot VPS

Why a VPS instead of a laptop

A laptop closes when you close it. A laptop loses Wi-Fi when you move rooms. A laptop reboots when an update decides it is time. None of those is acceptable when a position needs an exit fired in three seconds and nobody is watching.

A VPS removes all three failure modes: 24/7 uptime, a datacenter network (typically under 5 ms to common Polygon RPC endpoints), and no human in the loop for the runtime. The entry tier costs roughly $5 to $20 a month and is worth many times that the first time it saves you from a "I closed the lid" loss.

The rule of thumb: run paper mode wherever you like, on whatever machine you like. Move to a VPS the day real funds reach the bot, not later. Builders who delay this step lose more to a sleeping laptop than to actual strategy bugs.

Do you even need one yet?

Be honest about which side of the line you are on. Most people reading this are still on the left side, and that is completely fine.

  • You do not need a VPS yet if you are paper-trading, backtesting, hand-placing positions, or running a script for a few minutes at a time while you watch it. Your own machine is enough.
  • You do need a VPS once a bot manages live capital unattended, needs to react in seconds, runs overnight, or fires alerts you cannot afford to miss. At that point "always on" is the whole point.

If you are not sure, you are probably not there yet. The cost of waiting one more week is nothing; the cost of a server you do not use is a few dollars. Spend the time getting the strategy right first, then host it.

What to look for in a host

Once you do need one, the checklist is short. A Polymarket bot is not CPU-hungry; it is network-sensitive and must never go down. In rough priority order:

  • Uptime and stability - the entire reason you are leaving your laptop. Look for a real uptime SLA and a provider that does not silently reboot you for maintenance.
  • Region and network path - low, consistent latency to Polymarket's API and to your Polygon RPC matters more than raw geographic distance. Jitter (the variation) hurts more than a slightly higher average.
  • Network allowance - websocket subscriptions are chatty. Prefer unmetered or a generous monthly allowance so a busy market day never throttles you.
  • Right-sized RAM and CPU - 1 to 2 vCPU and 2 to 4 GB RAM covers almost every single-strategy bot. Do not overpay for cores you will not use.
  • Linux images and flat pricing - Ubuntu LTS or Debian ready to go, and predictable monthly cost without the per-gigabyte egress surprises of the big clouds.

That is the whole list. Anything beyond it - colocation, bare metal, sub-millisecond paths - only matters for genuinely latency-critical strategies, and you will know if you are running one.

The host we run our own bots on

We host our own production Polymarket bots on TradingVPS. It is built for exactly the checklist above: trading-optimized hardware, consistently low jitter to Polygon RPC endpoints, colocation options where you need them, and flat pricing without egress surprises. We have used it for over a year, and the recommendation predates the affiliate relationship.

Region choice (NY4 vs LD4 vs AMS3)

Polymarket's order-book API is fronted by Cloudflare and serves from edge locations close to the user, so raw geographic distance to the origin matters less than network-path quality. Three regional choices are common.

  • AMS3 / Amsterdam - a strong default. Good peering to Cloudflare's EU presence; fine for US-or-EU strategies that also touch overnight Asian markets.
  • NY4 / New York - best for strategies tied to US market hours (NBA, NFL, US politics). Some hosts in NY4 have the fastest measured latency to Polygon RPC endpoints on US East.
  • LD4 / London - a middle ground. Generally fine for everything; not the fastest at anything.

Avoid regions in Asia or South America unless your strategy is regional. The latency to Polymarket and to North-American Polygon RPCs adds 80 to 200 ms, which swallows most micro-strategy edges.

Sizing: vCPU, RAM, network

A single-strategy bot does not need much. Recommended minimums:

  • 1 to 2 vCPU. A Python bot tracking 20 markets uses well under 10% of one core most of the time. Do not over-buy CPU; spend the budget on network instead.
  • 2 to 4 GB RAM. Order-book caches and a few months of price history fit comfortably.
  • 1 Gbps unmetered or a large monthly allowance. Websocket subscriptions are chatty; a 500-market subscription can use 20 to 50 GB a month.
  • SSD storage, 20 to 40 GB. Logs, a trade diary, and code. Nothing storage-heavy.

If you run multi-strategy or multiple bots on the same host, double the RAM, keep the CPU the same, and make sure the network is unmetered. CPU is rarely the bottleneck.

Setup checklist for a Polymarket bot VPS

Order of operations, run once per host:

  1. Provision an Ubuntu 22.04 LTS image; SSH key only, no password login.
  2. apt update && apt install -y python3 python3-venv git tmux ufw fail2ban htop
  3. ufw allow OpenSSH && ufw enable
  4. Create a non-root user; lock down root SSH login in /etc/ssh/sshd_config.
  5. Set the time zone to UTC. Every log timestamp in this series is UTC.
  6. Install Node 20+ if your stack needs it (nvm install 20).
  7. Clone your bot repo. Use SSH-key auth to GitHub; never push a token to the host.
  8. Set up a systemd unit for the bot so it survives reboots and auto-restarts on crash.
  9. Wire up a Telegram alert bot (chapter 30) - a silent failure is worse than no bot.
  10. Run paper mode for 24 hours before any live capital reaches the host.

Total setup time on a fresh VPS: 45 to 90 minutes including the bot deployment.

Frequently asked questions

Do I really need a VPS for a Polymarket bot?
Only once it runs your real strategy unattended. For paper trading or quick experiments your laptop is fine. The moment a bot manages live positions and must survive a closed lid, a dropped Wi-Fi connection, or an overnight reboot, a VPS stops being optional.
What region should I host my Polymarket bot in?
Polymarket's order-book API is fronted by a CDN, so network-path quality matters more than raw distance. Amsterdam and US East (New York / Virginia) both peer well and work for most strategies. Latency-sensitive strategies should pick a host with NY4 or LD4 colocation; avoid Asia or South America unless your strategy is regional.
How much RAM and CPU does a Polymarket bot need?
1 to 2 vCPU and 2 to 4 GB RAM is enough for a single-strategy bot watching a few dozen markets. Move to 4 vCPU and 8 GB only if you run several strategies at once, keep months of price history locally, or hold websocket subscriptions to hundreds of markets. CPU rarely bottlenecks; network and logging do.
Should I use a Linux or Windows VPS?
Linux. Ubuntu LTS or Debian. Every Polymarket SDK example, every monitoring tool (systemd, journalctl, htop), and every tutorial in this series assumes Linux. A Windows VPS is technically possible but you will fight friction at every step.
Which VPS host do you use?
We run our own Polymarket bots on TradingVPS: trading-optimized hardware, consistently low jitter to Polygon RPC endpoints, NY4/LD4 colocation options, and flat predictable pricing with no egress surprises. The link on this page is an affiliate link; we earn a small commission and have used them for over a year.