A Polymarket bot only earns when it is running, and the hosting choice decides how many hours of the month that actually is. Most first builds run on a laptop under a desk, then quietly miss the one event of the quarter where the strategy was supposed to pay for itself because the wifi dropped during a thunderstorm. This guide walks through the realistic hosting options for a Polymarket bot, from a home server through generic VPS providers, region-aware cloud instances, and dedicated bare metal. It compares them on the four things that actually matter: round-trip latency to the Polygon RPC and Polymarket gateway, uptime guarantees, monthly cost, and the operational effort to keep the thing alive at three in the morning. The aim is a sober reference for choosing the right host for the strategy, not a sales pitch for any provider.
Why hosting matters more than people admit
Hosting is the part of a Polymarket bot build that operators consistently under-budget. The build excitement goes into the strategy, the order router, and the fee math. The hosting decision gets made in five minutes on a Sunday afternoon with whatever VPS the operator already happened to have a login for. Then the bot runs for a quarter, the operator looks at the realised PnL versus the backtest, and finds a 40 percent shortfall that has nothing to do with the strategy and everything to do with missed fills, late reconnects, and the two outages where the host went down for maintenance during a high-volume window.
Three numbers decide whether a hosting choice is right for a bot. First, median round-trip latency from the bot process to whichever Polygon RPC the order coordinator uses, plus the Polymarket gateway for websocket and order submission. Anything above 200 milliseconds for the RPC hop puts the bot behind every operator running in the right region. Second, monthly uptime in the real world, not the SLA brochure number. A 99.9 percent SLA permits roughly 43 minutes of downtime a month, and that downtime is almost never randomly distributed; it concentrates in the busiest periods because that is when host infrastructure is most stressed. Third, the human cost of keeping it running, which is the part nobody benchmarks but everyone pays.
The framing in this post is that hosting is part of the strategy, not separate from it. A market-making bot with quote-update latencies inside one second only works on a host with a sub-50 millisecond hop to the RPC. A daily-rebalance copy-trade bot is fine on a home server with a UPS because it does not care about a 30-second blip. Matching the host to what the bot actually needs is the whole game.
What a Polymarket bot actually needs from a host
Before comparing providers, the requirements have to be written down. A Polymarket bot is not a webserver. It does not need much CPU, almost no disk, and modest RAM. What it does need is steady network and reliable process supervision. The five concrete requirements:
- Stable outbound network. The bot opens long-lived websockets to the Polymarket gateway and HTTPS or websocket connections to one or two Polygon RPC endpoints. The connections should stay up for hours without forced renegotiation. Hosts that aggressively recycle NAT mappings or drop idle TCP sessions are not viable.
- Low and predictable network latency. Median round-trip to the Polygon RPC provider under 80 milliseconds for the bot to be competitive on the patterns documented in the Polymarket bot architecture guide. The variance matters more than the mean; a host that averages 60 milliseconds but spikes to 800 on p99 will lose more fills than one that sits at 120 with a tight distribution.
- Process supervision. The host needs a way to restart the bot process automatically if it crashes, and to restart it on host reboot. Systemd on Linux is the standard answer; pm2 is the standard answer on a Node.js stack. Anything that requires manual relaunch after a reboot is not a hosting choice for a 24/7 bot.
- Out-of-band recovery. When the bot is wedged and ssh is unresponsive, the operator needs a web console, an IPMI session, or some other way to get in. Cloud providers all have this. Home servers usually do not. Cheap VPS providers sometimes do.
- Modest hardware. Two vCPUs and 2 GB of RAM are enough for almost every retail Polymarket bot. Eight vCPUs and 16 GB if the bot also runs a local Polygon archive node, which is rare. Disk is small; logs and a SQLite state file fit in under 10 GB for a year of operation.
That is it. The bot does not need GPUs, does not need fast disk, does not need lots of RAM, and does not need many cores. The host that wins for a Polymarket bot is the one that ships predictable network and clean supervision, not the one with the biggest spec sheet.
The hosting tiers compared
The realistic options break into five tiers. Each is a sensible choice for some bots and a wrong choice for others. The table summarises the trade-offs; the prose after walks the cases where each tier is the right answer.
| Hosting tier | Monthly cost band | Median latency to Polygon RPC | Realistic uptime | Ops effort | Best fit |
|---|---|---|---|---|---|
| Home server + UPS | $0 to $20 (electricity) | 120 to 300 ms | 99.0 to 99.5% | High (manual) | Daily rebalance, paper trading, dev |
| Generic VPS (random region) | $5 to $15 | 80 to 250 ms | 99.5% | Medium | Copy trade, alerts, slow strategies |
| AWS us-east-1 / GCP us-east4 | $25 to $80 | 15 to 40 ms | 99.95% | Medium | Most retail execution bots |
| AWS us-east-2 or Ashburn-region budget | $15 to $40 | 20 to 55 ms | 99.9% | Medium | Latency-sensitive on a budget |
| Dedicated bare metal (Hetzner, OVH) | $40 to $120 | 25 to 80 ms (region dep.) | 99.9% | Higher (you own the box) | Arbitrage, market making, multi-bot |
The home server is the right answer for a builder who is still iterating on the strategy and does not yet care about a missed fill. A NUC or a Raspberry Pi 5 plus a small UPS plus a wired connection to the household router is a working setup. The hidden cost is the time spent debugging consumer ISP issues, NAT timeouts, and the family member who unplugs the wrong thing. It is not a 24/7 production host.
A generic VPS at $5 to $15 a month from any of the well-known budget providers is fine for a copy-trade bot, an alerting bot, or any strategy whose decisions are made on a timescale of minutes rather than seconds. The randomness of region is the catch: a $5 VPS in Frankfurt will have a 150-millisecond hop to a Polygon RPC hosted in Virginia, and that is the binding latency, not the bot code.
AWS us-east-1 (Northern Virginia) and GCP us-east4 (Ashburn) are where most serious Polygon RPC providers run their endpoints. A t3.small in us-east-1 typically sees sub-30 millisecond hops to Alchemy, QuickNode, and Infura, and sub-20 milliseconds to the Polymarket gateway. The cost is reasonable for what is gained. The same shape with AWS us-east-2 (Ohio) trades 10 to 20 milliseconds of latency for a noticeable discount, which is fine for most execution bots but marginal for tight arbitrage.
Dedicated bare metal at Hetzner or OVH is what the multi-bot operators graduate to. A single Hetzner AX41 covers half a dozen bots, a Redis, a Postgres, and a Prometheus stack, for the price of one mid-range AWS instance. The trade-off is that the operator now owns the box; failed disks, kernel panics, and DDoS scrubbing are now the operator problem. For a single bot it is rarely worth the complexity. For an operator running an arbitrage rig plus a market-making bot plus a copy-trade follower, the economics flip. The Hetzner dedicated server docs are the standard reference for what the boxes look like.
Latency math: where the milliseconds go
The scatter below maps each hosting tier on monthly cost (log scale, x-axis) against typical median round-trip latency from the bot process to a major Polygon RPC provider (y-axis). The cluster of cloud regions in the lower-left is where most retail bots should sit; the home server and Frankfurt VPS in the upper-left are cheap but slow; the bare metal in the lower-right is fast and cheap per workload but only if multiple bots share the box.
Polymarket bot hosting — cost vs latency to Polygon RPC
The lesson from the scatter is unfussy. Putting a bot in the same building as the RPC provider buys an order of magnitude more latency improvement than buying a faster CPU or more RAM. Polymarket gateway hops are similarly concentrated. Operators who treat hosting as a regional decision rather than a spec-sheet decision get the easy wins; operators who buy a 16-core box in Singapore for a Polygon bot do not.
Process supervision: keeping the bot alive
A bot that crashes once a week and stays down until the operator notices is not a 24/7 bot. The host has to restart the process automatically on crash, on host reboot, and ideally on a configurable health-check failure. The two standard answers are systemd on Linux and pm2 for Node.js stacks. A systemd unit for a Python bot, written for clarity rather than for any specific environment, looks like this:
# /etc/systemd/system/polymarket-bot.service
[Unit]
Description=Polymarket execution bot
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=botuser
WorkingDirectory=/opt/polymarket-bot
EnvironmentFile=/etc/polymarket-bot/env
ExecStart=/opt/polymarket-bot/.venv/bin/python -u -m bot.main
Restart=always
RestartSec=5
StartLimitIntervalSec=300
StartLimitBurst=10
StandardOutput=append:/var/log/polymarket-bot/stdout.log
StandardError=append:/var/log/polymarket-bot/stderr.log
[Install]
WantedBy=multi-user.target
The pieces worth pointing at: Restart=always handles crashes, RestartSec=5 avoids tight loops, the StartLimitBurst pair prevents an endlessly crashing bot from spamming logs to no purpose. EnvironmentFile keeps secrets out of the unit file. User=botuser means the process is not root, which limits the blast radius if it is ever compromised. Logs are appended to predictable paths so a journald-free operator can still tail them.
For a Node.js bot, pm2 covers the same ground with a one-line install. The ecosystem.config.js equivalent declares the script, the restart policy, and any environment overrides; pm2 startup wires it into the host init system so it survives reboots. Either tool is fine; what is not fine is running the bot in a tmux session and walking away.
Backups, secrets, and disaster recovery
The bot state file matters more than people think. A copy-trade bot that loses its mirror-state file forgets which positions it has already opened and immediately opens duplicates. An arbitrage bot that loses its order-state file cannot tell which legs filled. The state file should be backed up at least every hour to off-host storage, with a daily snapshot retained for at least 30 days. Object storage (S3, R2, B2) is the right primitive; the entire state is usually under 100 MB and the cost is negligible.
Secrets live in a secrets manager, not in a .env file committed to a repository. AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, and 1Password Service Accounts are all acceptable. The bot fetches the L2 API key, the wallet private key, and any RPC credentials at process start and caches them in memory; nothing sensitive touches the local disk in plaintext. The deeper security argument is laid out in the security post on the blog and is the only acceptable posture for a wallet that holds operating float.
Disaster recovery for a single-instance bot means having a documented procedure to spin up a fresh host from a clean snapshot in under 30 minutes. That procedure should be tested at least quarterly; an untested DR plan is an aspiration, not a plan. The shape of the script is standard: provision the instance, pull the deploy artefact, fetch secrets, restore the state file from the most recent backup, start the systemd unit, verify the bot is connected to the websocket and not in a half-open state. The operator who runs this drill once a quarter does not have a panicked Sunday morning when the primary host goes down.
Monitoring and alerting at the host level
Monitoring breaks into two layers: the bot itself and the host underneath it. The bot layer (signal counts, fill rates, PnL deltas) is covered in the architecture and debugging posts; the host layer is what this section is about.
The minimum host-level instrumentation is three signals. First, process liveness: a heartbeat that the bot writes to a known path every five seconds, and an external check that pages if the heartbeat is older than 30 seconds. Second, network latency: a periodic ping or HTTPS health check to the Polygon RPC and the Polymarket gateway, with alerts on a sustained increase above the operator-defined ceiling. Third, host saturation: CPU, RAM, and disk usage thresholds that trigger before the host falls over, not after. A simple Prometheus node-exporter plus a single Alertmanager rule per signal is enough for a one-bot deployment; Grafana Cloud or a hosted equivalent removes the need to run the dashboard stack as well.
The alerting destination should be something the operator actually reads at 3 AM. Email is not that destination. Telegram, PagerDuty, OpsGenie, or a phone push notification are. The alert payload should include the bot name, the signal that fired, and a one-line remediation hint; alerts that read “something is wrong” without context get muted and the next real incident gets missed.
One under-used technique is a daily health-summary message regardless of incidents. A single Telegram message every morning with uptime in the last 24 hours, fill counts, current state file size, and any non-alerting warnings keeps the operator in touch with the bot. Operators who only hear from their bot when something is broken stop noticing when it is silently degraded.
Picking the right host for your strategy
The choice falls out of three questions about the strategy itself.
How latency-sensitive is the strategy? A daily-rebalance copy trade or a once-an-hour rebalancer is not latency-sensitive; a generic VPS or even a home server is fine. A minute-cadence copy-trade with size that matters is moderately sensitive and belongs in AWS us-east-1 or us-east-2. An arbitrage bot or a market-making bot is highly sensitive and belongs in the same region as the RPC provider, on a host with predictable network. The deeper map of strategy types is in how to build a Polymarket trading bot, and the contrast with running off-the-shelf scripts is covered in Polymarket bot vs DIY scripts.
How many bots will run on this host? A single bot has no business renting bare metal; a $25 cloud instance covers it. Three or more bots, or a bot plus a Redis, plus a Postgres, plus a Prometheus, all change the economics in favour of a dedicated box at Hetzner or OVH. The breakeven is usually around the third workload.
What is the operator tolerance for ops work? A managed cloud instance with autoscaling and a managed log stack is more expensive per month but consumes less of the operator weekend. A self-hosted bare metal box with self-rolled monitoring is cheaper per workload but consumes more time. The right answer depends on whether the operator finds ops work energising or draining; both are valid, and the wrong fit produces burnout regardless of how good the strategy is. The AWS t3 instance type documentation is a useful reference for the cheapest sensible cloud starting point.
The default recommendation for a builder shipping a first serious Polymarket execution bot is a t3.small or t3.medium in AWS us-east-1, with the bot supervised by systemd, secrets in AWS Secrets Manager, state backed up hourly to S3, and a Telegram alerting hook for liveness. Total monthly cost is around $30 to $50, total setup time is a weekend, and the operational surface is small enough that a single operator can keep it healthy alongside a day job. From there, the upgrade path is dictated by what the bot actually needs, not by what the spec sheet says.
About the author
Jamal Okafor is an execution engineer on the Poly Syncer team. He has run Polymarket bots on a Raspberry Pi under a desk, on a budget VPS in Frankfurt, and on a Hetzner box in Ashburn; the lessons in this post come from missing fills on the first two. He thinks most retail builders over-engineer their hosting before they have a working strategy and under-engineer it once the strategy starts to matter, and that this guide is the version of the conversation he wishes he had been handed earlier.
Frequently asked questions
Can I run a Polymarket bot from my home computer?
For a daily-rebalance strategy, paper trading, or development, a home computer with a wired connection and a UPS is workable. For anything latency-sensitive or revenue-bearing, it is not. Consumer ISPs reset NAT mappings, household power blips, and the operator is unlikely to have an out-of-band path back into the machine when ssh stops responding. The first revenue-bearing deployment should move to a cloud or VPS host.
Which AWS region is best for a Polymarket bot?
AWS us-east-1 (Northern Virginia) is the default because most Polygon RPC providers and the Polymarket gateway have presence in or near Ashburn. AWS us-east-2 (Ohio) is the budget option with a small latency penalty. Frankfurt, Tokyo, and Singapore add 80 to 200 milliseconds of round-trip and are wrong choices unless the operator has a regulatory or operational reason to be there.
How much does it cost to host a Polymarket bot 24/7?
A serious entry-level setup costs $25 to $50 a month all in: the cloud instance, a secrets manager, S3 for state backups, and a hosted alerting stack. A budget VPS deployment can come in under $10 a month but should be treated as a development host, not a production one. Dedicated bare metal at Hetzner runs $40 to $120 a month and only pays off once three or more bots share the box.
Do I need a static IP for the bot?
Not for outbound trading; the bot initiates all connections and the gateway does not care about the source IP. A static IP becomes useful if the operator wants to allowlist the host in a secrets manager or an RPC provider for access control, which is a sensible posture for production deployments. Cloud providers expose static IPs as elastic IP addresses or reserved external IPs at marginal cost.
What is the most common hosting mistake first-time builders make?
Picking a host by spec-sheet (lots of cores, lots of RAM, lots of disk) instead of by region and network quality. A Polymarket bot does not need any of that hardware; it needs a short hop to the Polygon RPC and the Polymarket gateway, stable outbound connections, and a supervisor that restarts it on crash. An eight-core box in the wrong region performs worse for this workload than a two-core box in the right one.