How to Host a Kalshi Trading Bot: Railway, Heroku, AWS Lambda, and VPS Compared

Writing a Kalshi trading bot is the easy part. Keeping it alive around the clock — reliably, cheaply, and close enough to Kalshi's servers to matter — is where most builders stumble. This guide compares the four most popular hosting options for a Kalshi bot: Railway, Heroku, AWS Lambda, and a self-hosted VPS. Each section covers cost, latency, setup complexity, and the exact scenarios where that platform wins.

What Your Bot Actually Needs from a Host

Before picking a platform, nail down what your strategy actually demands. The requirements split cleanly into two profiles:

• Continuous bots — market makers, arbitrage scanners, and position-management bots that need to be running every second. They typically hold a persistent WebSocket connection to the Kalshi API and react to price changes in real time. Uptime is not optional.
• Scheduled / event-driven bots — bots that only act at specific moments: a sports score settlement, an economic data release, a weather report. They can tolerate cold starts and don't need a persistent connection between events.

Two other factors matter regardless of strategy type: latency and secret management. Kalshi's API endpoints sit in AWS us-east-1. The closer your bot runs to that region, the faster your orders land. And your API key should never be hard-coded in source — every platform below has a secrets or environment-variable layer; use it.

If you're still building your bot, the Python bot tutorial and the Kalshi API tutorial cover the code side. This article picks up at the point where your bot.py is ready to deploy.

Railway: Managed Simplicity for Most Bots

Railway is a Platform-as-a-Service (PaaS) that deploys directly from a GitHub repo. Push to main, Railway detects your runtime (Python, Node, Go, etc.), builds a container, and runs it. No Dockerfile required, though you can provide one.

Cost

Railway's Hobby plan is $5/month flat plus resource consumption. A lightweight Python bot idling at ~50 MB RAM and negligible CPU typically costs $5–8/month all-in. There's no free tier for persistent services anymore — Railway deprecated sleep-after-inactivity plans specifically because they're incompatible with bots that need to stay awake.

Latency

Railway deploys to Google Cloud by default. US East deployments land in us-east4 (Virginia), which is geographically close to Kalshi's us-east-1. Round-trip API latency typically runs 8–15 ms — acceptable for most strategies.

Setup

1. Connect your GitHub repo to Railway.
2. Set environment variables (your KALSHI_API_KEY, KALSHI_API_SECRET, etc.) in the Railway dashboard under Variables.
3. Add a Procfile or set the start command: python bot.py.
4. Deploy. Railway tails logs in the dashboard in real time.

When Railway wins

Railway is the right default for developers who want managed infrastructure without ops overhead. If you'd rather not think about servers, firewalls, or SSH keys — and your bot doesn't need sub-5 ms latency — Railway is the cleanest path to production.

Heroku: Familiar but Pricier

Heroku was the original PaaS workhorse and still works well for bot deployments. The developer experience is nearly identical to Railway: git push heroku main and you're deployed. The friction shows up in pricing.

Cost

Heroku's free tier was shut down in November 2022. The entry-level Eco dyno is $5/month but sleeps after 30 minutes of inactivity — useless for a continuous bot. The Basic dyno at $7/month doesn't sleep, which is the real floor for a persistent bot. Add-ons (Postgres, Redis, log drains) stack on top.

Latency

Heroku runs on AWS. The us region maps to us-east-1, which is the same region Kalshi uses. That makes Heroku's latency profile genuinely good — often under 5 ms for API calls.

Setup

1. Install the Heroku CLI and run heroku create your-bot-name.
2. Add a Procfile with a worker process (not web, since a bot doesn't serve HTTP): worker: python bot.py.
3. Set config vars: heroku config:set KALSHI_API_KEY=your_key.
4. Deploy: git push heroku main. Scale the worker dyno: heroku ps:scale worker=1.

When Heroku wins

If your team already has Heroku infrastructure and tooling in place, the switching cost to Railway isn't worth it. For a greenfield bot, Heroku offers no meaningful advantage over Railway today, and costs slightly more for the same persistent uptime.

AWS Lambda: Great Fit for Event-Driven Bots Only

AWS Lambda is a serverless compute service. You upload a function, define a trigger, and AWS runs it on demand. You pay only for execution time — which can mean near-zero monthly cost at low frequencies.

Cost

Lambda's free tier covers 1 million invocations and 400,000 GB-seconds of compute per month — effectively free for most scheduled bots. A bot that polls Kalshi every 60 seconds spends roughly 1,440 invocations/day × 30 days = 43,200 invocations/month, well within the free tier.

Latency

Lambda in us-east-1 has excellent network proximity to Kalshi. The problem is cold starts: when a Lambda function hasn't run recently, AWS spins up a new container, which adds 200–800 ms to the first invocation. For strategies where every millisecond counts, that cold-start penalty is a dealbreaker. For a bot that checks an event result once every few minutes, it's irrelevant.

The WebSocket problem

Lambda functions have a maximum execution duration of 15 minutes. A bot that holds an open WebSocket connection — as real-time market-making bots do — cannot run on Lambda at all. This is the hard constraint that makes Lambda inappropriate for continuous bots.

Setup for a scheduled Lambda bot

# Example: Lambda handler that checks a Kalshi market and places an order
import json, os, requests

KALSHI_BASE = "https://trading-api.kalshi.com/trade-api/v2"
HEADERS = {"Authorization": f"Bearer {os.environ['KALSHI_API_KEY']}"}

def handler(event, context):
    resp = requests.get(f"{KALSHI_BASE}/markets/YOUR_MARKET_TICKER", headers=HEADERS)
    market = resp.json()["market"]
    yes_price = market["yes_ask"]
    # Your logic here
    return {"statusCode": 200, "body": json.dumps({"yes_ask": yes_price})}

Trigger this handler with an EventBridge (CloudWatch Events) rule set to a cron expression, and you have a scheduled bot with zero standing infrastructure.

When Lambda wins

Lambda is purpose-built for event-driven bots. If your strategy only needs to act at discrete moments — a weather forecast update, an earnings release, a sports final score — Lambda gives you Kalshi-region proximity at essentially no cost, with no server to maintain.

Self-Hosted VPS: Maximum Control, Minimum Cost

A Virtual Private Server gives you a raw Linux machine. You manage the OS, dependencies, process supervision, and security. In return, you get the lowest cost per unit of compute and the most flexibility.

Cost

Hetzner's CX22 (2 vCPU, 4 GB RAM) runs €3.79/month (~$4/month). DigitalOcean's Basic Droplet starts at $6/month. Vultr and Linode are in the same range. For the price of one Railway deployment, you can run 5–10 bots on a single VPS.

Latency

Choose a New York or Ashburn data center from any provider and you'll be 5–15 ms from Kalshi's API — comparable to Heroku, slightly better than Railway's Google Cloud routing. If you need the absolute lowest latency, a DigitalOcean NYC3 or Vultr New Jersey droplet is hard to beat at this price point.

Setup

The extra work on a VPS is process management. Your bot needs to restart automatically after crashes and survive server reboots. systemd handles this cleanly:

# /etc/systemd/system/kalshi-bot.service
[Unit]
Description=Kalshi Trading Bot
After=network.target

[Service]
User=ubuntu
WorkingDirectory=/home/ubuntu/kalshi-bot
EnvironmentFile=/home/ubuntu/kalshi-bot/.env
ExecStart=/home/ubuntu/kalshi-bot/venv/bin/python bot.py
Restart=on-failure
RestartSec=10s

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable kalshi-bot
sudo systemctl start kalshi-bot
journalctl -u kalshi-bot -f   # tail logs

Store your API credentials in the .env file referenced by EnvironmentFile, and make sure that file is chmod 600 — readable only by the bot's user account.

Security basics you can't skip

• Disable password SSH login; use key-based auth only.
• Run ufw allow 22 && ufw enable to lock down unused ports.
• Keep the OS patched with unattended-upgrades.
• Never store your API key in your Git repo — use .gitignore on .env.

When a VPS wins

A VPS is the right call when you're running multiple bots, need full control over the execution environment, or want the lowest possible ongoing cost. It's also the best path for market-making strategies where you want consistent low latency and zero platform-imposed resource limits.

Side-by-Side Comparison

Which Platform Should You Pick?

The decision tree is short:

• Your bot only acts at specific moments (economic release, game result, weather update) → AWS Lambda. It's nearly free and requires no standing server.
• You're deploying your first bot and don't want to manage Linux → Railway. Lowest ops overhead for a continuously running process.
• You're running two or more bots, or you want to cut costs long-term → VPS. A $6 DigitalOcean droplet can outlast any PaaS on a per-bot basis.
• Your team is already on Heroku → Stay on Heroku. The migration pain isn't worth it for one bot.

The complete guide to Kalshi trading bots covers the broader decision of what kind of bot to build before you get to the hosting question. If you're earlier in the process, start there.

For strategies that justify premium latency — particularly arbitrage between Kalshi and other prediction markets — a VPS in a New York data center is the right answer almost every time. Managed platforms introduce routing hops that add measurable milliseconds to round-trips.

Pre-Launch Deployment Checklist

Regardless of platform, run through this list before your bot goes live with real capital:

1. Secrets out of source control — API keys in environment variables or a secrets manager, .env in .gitignore.
2. Process restart on crash — systemd Restart=on-failure on a VPS; Railway and Heroku handle this automatically.
3. Startup reconciliation — on boot, your bot should fetch open orders from the Kalshi API and decide whether to cancel or manage them before placing new ones. A crash mid-strategy can leave stale orders alive.
4. Logging to a persistent store — stdout is fine on Railway and Heroku (they capture it), but on a VPS pipe logs to a file or a service like Papertrail so you have a record after a crash.
5. Position limits in code — hard cap the maximum dollar exposure the bot can hold at any moment. This is your circuit breaker if the logic misbehaves after a cold start or reconnect.
6. Alerting — a simple webhook to Slack or a Telegram bot when your process exits unexpectedly costs nothing to implement and saves you from discovering a dead bot hours later.
7. Test in paper / small size first — run the exact deployment configuration with small-lot orders for 24–48 hours before scaling up. Deployment environment bugs — missing dependencies, timezone issues, clock drift — almost always surface in the first few hours.

Position sizing discipline is equally important once the bot is live. The Kelly criterion sizing guide walks through how to set per-market exposure limits programmatically.

If you're not writing a custom bot from scratch, the no-code bot builder options handle hosting for you — worth reviewing if the infrastructure work above isn't where you want to spend your time.