Linux/DevOps Contractor for Trading Bot

Summary : Seeking a Linux/DevOps contractor to harden a 24/7 Python trading bot on a Hetzner VPS. The task involves converting a screen-based process to a systemd service with auto-restart. The ideal candidate will have experience in managing processes and ensuring system reliability. This is a part-time engagement with a short-term project duration. What this is A systematic futures trading engine that runs 24/7 on a Linux VPS. It reads live market data from Interactive Brokers, generates trade signals in Python, and fires those signals via webhook to TradersPost, which executes orders on Tradovate/Apex accounts. It also sends status and trade alerts to Telegram. The strategy logic works and is not the problem. Help is wanted only on infrastructure reliability — keeping the process alive, connected, and self-healing without manual babysitting. You do not need to understand trading strategy to help. This is a "keep a Python process connected and running 24/7" problem. The stack: VPS: Hetzner (Ubuntu), single box, root access. IB Gateway: runs in Docker (gnzsnz/ib-gateway image). Provides market data only — no orders go through it. Requires a manual 2FA login each morning after its nightly auto-restart. Engine: Python 3, ~5 modules, uses the ib_async library. Runs inside a screen session. Reads data from IB Gateway, computes signals, posts JSON to TradersPost webhooks, sends Telegram messages. Order execution: TradersPost → Tradovate → Apex (entirely outside the VPS; not in scope). Remote viewing: noVNC (browser, port 6081 via websockify) and a direct VNC app (port 5900) to see the Gateway login screen. What already works: Engine seeds historical bars, builds live bars, generates signals, sends webhooks + Telegram alerts. Auto-reconnect logic: if the IB API connection drops, the engine catches it, retries with fresh client IDs, re-seeds, and alerts Telegram. Tested and working. 4 instruments live across 2 accounts. Known snags / what we'd want help hardening: Process death survival. Reconnect handles a dropped connection, but if the Python process itself dies (or the box reboots), nothing brings it back. We want a systemd service that runs the engine, auto-restarts on crash, and survives reboot — replacing the manual screen workflow. noVNC/websockify instability. The browser VNC proxy (websockify, port 6081) drops on reboot/gaps and needs a manual restart each time. Want it as a systemd service too so it auto-starts. IB Gateway 2FA persistence. Gateway logs out on its nightly restart and needs a manual VNC + phone-2FA login each morning. We'd like to know if IBC config can reduce or remove this daily manual step (or confirm it genuinely can't, given 2FA). Seeding depends on start order. The engine must only be started after IB Gateway is fully connected/green, or it seeds badly. Ideally the engine should detect a not-ready Gateway and wait/retry rather than seeding from incomplete data. Security. VNC port 5900 is currently exposed to the public internet with a weak password. Want it firewalled (IP allowlist) and/or hardened. Nice-to-haves (lower priority) A watchdog/heartbeat that alerts if the engine goes silent. Tidy up leftover/stale screen sessions (moot once systemd replaces screen). Skills to look for A freelance DevOps / Linux systems contractor. Keywords: systemd, Docker, Python process management, VPS hardening, ufw/iptables. They do not need trading or quant experience. (A separate algo-trading developer would only be needed for strategy/engine logic changes, which are not the issue here.) Access they'd need SSH to the VPS (root or sudo user). Ability to view the IB Gateway screen via VNC. Read access to the engine code in /root/v3trading/. Do not hand over broker/TradersPost/Apex credentials — none of the infra work requires placing real orders. Testing can be done on connection/seeding/restart behaviour without live trading.