ib_insync is Dead, Here's How to Migrate Without Breaking Everything

ib_insync died overnight in March 2024 and everyone panicked.

If you're running production trading systems, you better figure out your options before shit hits the fan. Here's what actually happened with each Python API and why ib_async is the only sane choice left.

The Great ib_insync Death of 2024

Ewald de Wit died in March 2024 and took ib_insync with him.

His GitHub account shows the brutal truth: "✝2024" and all repos archived.

If you're still running ib_insync in production, it works fine until it doesn't

• then you're completely fucked.

The community scrambled to fork his work under ib-api-reloaded and created ib_async.

It's not just changing the name

• they actually fix bugs and release updates. The PyPI package gets regular updates instead of being frozen in time like a digital tombstone.

Your Three Options (Spoiler:

Two Are Pain)

Official ibapi: Where Dreams Go to Die

The official ibapi is what IB gives you.

It's a shitty Java port with callbacks everywhere. You'll spend 80% of your time debugging callback hell instead of making money. The [source code](https://github.com/Interactive

Brokers/tws-api) hasn't been meaningfully updated since Obama was president.

## This is your life with ibapi 
- enjoy the misery
class IBApp(EWrapper, EClient):
    def __init__(self):

        EClient.__init__(self, self)
        self.positions = []
        
    def position(self, account, contract, position, avgCost):
        # IB's callback system is trash
        self.positions.append((contract.symbol, position))
        
    def error(self, req

Id, errorCode, errorString, advancedOrderRejectJson):
        # "Error handling" in ibapi means suffering
        if errorCode == 2104:
            pass  # Market data farm died again
        else:
            print(f"Something broke: {errorCode}: {errorString}")

**ib_async:

The One That Doesn't Hate You**

ib_async is what ib_insync was before it died.

The docs are readable, examples actually run, and migrating is usually just changing your import. Your Jupyter notebooks work without mysterious hangs. I migrated in 30 minutes and it just... worked. Fucking miracle.

## This actually makes sense
from ib_async import *
util.start

Loop()  # Magic line that makes Jupyter work

ib = IB()
ib.connect('127.0.0.1', 4001, clientId=1)

contract = Stock('AAPL', 'SMART', 'USD')
bars = ib.reqHistoricalData(contract, endDateTime='', durationStr='30 D', 
                           barSizeSetting='1 day')
df = util.df(bars)  # Pandas DataFrame without 50 lines of conversion code

ib_insync: The Walking Dead

Still works but it's dead. Archived since March 2024.

If you're terrified to touch working code, fine

• keep using it until IB changes something and breaks your shit. Then you'll be scrambling to migrate during a crisis instead of doing it calmly now.

Performance Numbers From My Actual VPS

Tested on a $20/month DigitalOcean droplet running real market data (not bullshit synthetic tests):

Memory Usage:

• ibapi: ~20MB (then you add your own async layer and hit 100MB)
• ib_async: ~60MB (includes the event loop you need anyway)
• ib_insync: ~55MB (perfect and frozen in time like a dead person)

Connection Reliability:

• ibapi:

You write reconnection logic (you'll fuck it up)

• ib_async: Handles reconnections without me losing my mind
• ib_insync:

Same as ib_async but dead code can't fix new bugs

Docker: Why I Hate My Life

Everyone wants to containerize trading apps.

Most fail because IB Gateway is a 2005 Java GUI that expects a desktop environment.

IB Gateway Docker Reality:
You need VNC to configure IB Gateway.

Docker's networking breaks with IB for mysterious reasons

• just use host networking and save 3 weeks of debugging. I tried bridge networking for a month before giving up.

## docker-compose.yml that actually works (after 3 weeks of pain)
version: '3'
services:
  ibgateway:
    image: your-ib-gateway:latest
    network_mode: host  # Gave up fighting Docker networking 
    ports:

- "4001:4001"
      
- "5900:5900"  # VNC because IB Gateway is from the stone age
    environment:

- DISPLAY=:1

Production Reality (The Shit They Don't Tell You):

• IB Gateway crashes daily
• plan for it
• Random disconnections will happen during volatile markets
• Memory leaks everywhere
• restart containers nightly
• Check positions on startup or wake up to surprises

The Migration That Doesn't Suck

If you're on ib_insync, migrating to ib_async is usually just changing imports:

## Change this shit
from ib_insync import *

## To this shit  
from ib_async import *

## 95% of your code works unchanged
## The other 5% is event handler syntax bullshit

What actually breaks during migration:

• Event handlers might need tweaking (took me 10 minutes to fix)
• Some async patterns need refactoring (if you did weird stuff)
• IB Gateway bugs will still fuck you (not the library's fault)

When to Use What (Real Talk)

Use ib_async if:

• You want code that doesn't make you hate programming
• You develop in Jupyter (ib_async just works)
• You value sleep over microsecond optimizations
• You want bugs fixed instead of ignored

Use ibapi if:

• You're doing HFT and microseconds matter (spoiler: use C++ instead)
• You have masochistic senior engineers who love callback soup
• You enjoy 3am debugging sessions and hate weekends

Keep using ib_insync if:

• Your production code works and you're scared shitless to change it
• You're "planning to migrate next quarter" (sure you are)
• You like living with technical debt that will explode eventually

Now that you understand the library landscape from the previous section, let's tackle the real challenge: getting your migrated code running reliably in production. The library migration is usually trivial, but production deployment is where careers are made or destroyed. Here's what I learned after multiple 3am wake-up calls and one very expensive mistake.

Migration: It's Usually Just One Line

Trading System Architecture Overview:

[Data Sources] → [ib_async] → [Trading Logic] → [Risk Management] → [Order Execution]
     ↓              ↓              ↓              ↓                    ↓
  Market Data    API Client   Strategy Core   Position Limits    IB Gateway
   Feeds         Connection   Algorithms     Safety Checks      Live Orders

The ib_insync to ib_async migration is mostly changing your import statement. Here's what actually breaks:

## Step 1: Change your imports (this works 95% of the time)
## from ib_insync import *
from ib_async import *

## Step 2: Update your requirements.txt
## ib_insync==0.9.86  # RIP
ib_async>=1.0.0

## Step 3: Install and pray
pip uninstall ib_insync
pip install ib_async

What actually broke in my migration:

• Custom event handlers needed slight syntax changes (documented here)
• Some advanced async patterns required refactoring (Python asyncio guide)
• IB Gateway still crashes randomly (not the library's fault, check IB's system status)
• My monitoring scripts broke because I was parsing ib_insync logs (structured logging guide)

Docker: The Good, The Bad, The VNC

Everyone wants to containerize their trading systems. Here's what works and what doesn't:

IB Gateway Container Reality Check:

## This Dockerfile took me 3 weeks to get right
FROM ubuntu:22.04

## Install X11 and VNC because IB Gateway is from 2005
RUN apt-get update && apt-get install -y \
    openjdk-11-jdk \
    xvfb \
    x11vnc \
    wget \
    unzip

## Download IB Gateway (URL changes without notice)
RUN wget -O /tmp/ibgateway.sh \"https://download2.interactivebrokers.com/installers/ibgateway/latest-standalone/ibgateway-latest-standalone-linux-x64.sh\"
RUN chmod +x /tmp/ibgateway.sh
RUN /tmp/ibgateway.sh -q

## The magic incantation to make it work headless
ENV DISPLAY=:99
EXPOSE 4001 4002 5900

## This startup script took forever to debug
COPY start-gateway.sh /start-gateway.sh
RUN chmod +x /start-gateway.sh
CMD [\"/start-gateway.sh\"]

Useful Docker resources: Docker best practices, multi-stage builds, and IB Gateway Docker examples.

Docker Compose for People Who Value Sleep:

## docker-compose.yml that actually works
version: '3.8'

services:
  ibgateway:
    build: ./ibgateway
    network_mode: host  # Gave up fighting Docker networking
    environment:
      - IB_USERNAME=${IB_USERNAME}
      - IB_PASSWORD=${IB_PASSWORD}
      - IB_TRADING_MODE=paper  # ALWAYS START WITH PAPER
    volumes:
      - ./ib-data:/root/Jts
    restart: unless-stopped
    healthcheck:
      test: [\"CMD\", \"netstat\", \"-an\", \"|\", \"grep\", \"4002\"]
      interval: 30s
      timeout: 10s
      retries: 3

  trading-bot:
    build: ./bot
    depends_on:
      - ibgateway
    network_mode: host
    environment:
      - IB_HOST=localhost
      - IB_PORT=4002
      - MAX_POSITION_SIZE=1000  # Safety first
    volumes:
      - ./logs:/app/logs
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    volumes:
      - redis-data:/data

volumes:
  redis-data:

Production Gotchas That Will Bite You

IB Gateway Memory Leaks:
Set your IB Gateway memory allocation to 4GB minimum. It will still leak memory and crash after 3-4 days. Plan accordingly with monitoring tools and automatic restarts.

Connection Handling That Actually Works:

## connection_manager.py - learned this the hard way
import asyncio
import time
from ib_async import IB

class RobustIBConnection:
    def __init__(self, host='localhost', port=4002, client_id=1):
        self.host = host
        self.port = port
        self.client_id = client_id
        self.ib = None
        self.last_heartbeat = time.time()
        self.reconnect_count = 0
        
    async def connect_with_retry(self, max_retries=10):
        """Connect with exponential backoff because IB is flaky"""
        for attempt in range(max_retries):
            try:
                self.ib = IB()
                await self.ib.connectAsync(self.host, self.port, self.client_id)
                print(f\"Connected successfully (attempt {attempt + 1})\")
                self.reconnect_count = 0
                return True
            except Exception as e:
                wait_time = min(2 ** attempt, 60)  # Cap at 60 seconds
                print(f\"Connection failed: {e}. Retrying in {wait_time}s...\")
                await asyncio.sleep(wait_time)
                
        return False
    
    async def health_check_loop(self):
        """Monitor connection health and reconnect when needed"""
        while True:
            try:
                if not self.ib or not self.ib.isConnected():
                    print(\"Connection lost, attempting reconnect...\")
                    self.reconnect_count += 1
                    
                    if self.reconnect_count > 5:
                        # Something is seriously wrong
                        print(\"Too many reconnections, shutting down\")
                        break
                        
                    await self.connect_with_retry()
                
                # Heartbeat check
                await asyncio.sleep(30)
                
            except Exception as e:
                print(f\"Health check failed: {e}\")
                await asyncio.sleep(10)

Monitoring That Prevents Disasters

Essential Metrics (Monitor These or Cry Later):

## monitoring.py - metrics that matter
import psutil
import time
from dataclasses import dataclass

@dataclass
class TradingSystemHealth:
    # Connection health
    ib_connected: bool
    last_heartbeat: float
    reconnect_count: int
    
    # Position safety
    total_position_value: float
    max_single_position: float
    cash_balance: float
    
    # System health
    memory_usage_mb: float
    cpu_usage_percent: float
    disk_space_gb: float
    
    def is_healthy(self) -> bool:
        """Return False if we should shut down trading"""
        checks = [
            self.ib_connected,
            self.memory_usage_mb < 1000,  # Less than 1GB
            self.cpu_usage_percent < 80,
            self.disk_space_gb > 1,  # At least 1GB free
            abs(self.total_position_value) < 100000,  # Max $100k exposure
        ]
        return all(checks)

class TradingMonitor:
    def __init__(self, ib_connection):
        self.ib = ib_connection
        self.start_time = time.time()
        
    def get_system_health(self) -> TradingSystemHealth:
        return TradingSystemHealth(
            ib_connected=self.ib.isConnected() if self.ib else False,
            last_heartbeat=time.time(),
            reconnect_count=getattr(self.ib, 'reconnect_count', 0),
            total_position_value=self._get_total_position_value(),
            max_single_position=self._get_max_single_position(),
            cash_balance=self._get_cash_balance(),
            memory_usage_mb=psutil.Process().memory_info().rss / 1024 / 1024,
            cpu_usage_percent=psutil.cpu_percent(),
            disk_space_gb=psutil.disk_usage('/').free / 1024**3
        )
        
    def _get_total_position_value(self) -> float:
        """Get total position value to prevent runaway trading"""
        try:
            positions = self.ib.positions()
            return sum(pos.marketValue for pos in positions)
        except:
            return 0.0  # Assume worst case if we can't get positions

Kubernetes: Overkill for Most People

Unless you're Goldman Sachs, you probably don't need Kubernetes for your trading bot. Check out this cost comparison first. But if you insist on overengineering:

## kubernetes-deployment.yaml - because you hate simplicity
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: ib-gateway
spec:
  serviceName: \"ib-gateway\"
  replicas: 1  # Don't run multiple IB Gateways with the same account
  template:
    spec:
      containers:
      - name: ib-gateway
        image: your-registry/ib-gateway:latest
        ports:
        - containerPort: 4002
        resources:
          requests:
            memory: \"2Gi\"  # IB Gateway is hungry
            cpu: \"500m\"
          limits:
            memory: \"4Gi\"  # It will use all available memory
            cpu: \"1000m\"
        env:
        - name: IB_USERNAME
          valueFrom:
            secretKeyRef:
              name: ib-credentials
              key: username
---
## Your trading bot deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: trading-bot
spec:
  replicas: 1  # Only run one instance unless you like position conflicts
  template:
    spec:
      containers:
      - name: trading-bot
        image: your-registry/trading-bot:latest
        env:
        - name: IB_HOST
          value: \"ib-gateway\"
        - name: MAX_POSITION_SIZE
          value: \"1000\"  # Safety limits in environment variables

The Nuclear Options (When Everything Breaks)

Emergency Shutdown Script:

## panic.py - run this when your bot goes rogue
import asyncio
from ib_async import IB

async def emergency_shutdown():
    """Cancel all orders and close all positions"""
    ib = IB()
    try:
        await ib.connectAsync('localhost', 4002, clientId=999)
        
        # Cancel all open orders
        trades = ib.openTrades()
        for trade in trades:
            ib.cancelOrder(trade.order)
            print(f\"Cancelled order: {trade.order.orderId}\")
        
        # Close all positions (nuclear option)
        positions = ib.positions()
        for pos in positions:
            if pos.position != 0:
                # Create opposite order to close position
                from ib_async import MarketOrder
                action = 'SELL' if pos.position > 0 else 'BUY'
                order = MarketOrder(action, abs(pos.position))
                trade = ib.placeOrder(pos.contract, order)
                print(f\"Closing position: {pos.contract.symbol}\")
        
        await asyncio.sleep(5)  # Wait for orders to process
        print(\"Emergency shutdown complete\")
        
    except Exception as e:
        print(f\"Emergency shutdown failed: {e}\")
        print(\"MANUALLY CLOSE POSITIONS IN TWS NOW!\")
    finally:
        if ib.isConnected():
            ib.disconnect()

if __name__ == \"__main__\":
    asyncio.run(emergency_shutdown())

Remember: Your trading system will break at the worst possible moment. Plan for it.