When you connect a trading bot to a cryptocurrency exchange, you create an API key pair with specific permissions. That key pair is the most sensitive credential in your trading operation. Anyone who possesses it can place trades on your account. If withdrawal permissions are enabled, they can move your funds. The security of your API keys is, in a very literal sense, the security of your capital.
Cloud-hosted bot platforms require you to upload these keys to their servers. Self-hosted platforms keep the keys on your own hardware. This is not a minor architectural difference. It is a fundamental security boundary that determines your exposure to third-party risk.
The Cloud Key Problem
When you give your exchange API keys to a cloud platform, you are trusting that platform's security infrastructure to protect your most sensitive credential. You are trusting their encryption at rest, their access controls, their employee vetting, their network security, their incident response, and their disclosure practices.
The history of cloud-hosted trading platforms includes multiple security incidents involving exposed API keys. These incidents have resulted in unauthorized trades on user accounts, sometimes costing users significant capital. The specifics vary, but the pattern is consistent: a third-party platform was breached, and user API keys were compromised.
This is not unique to crypto. Any system that centralizes sensitive credentials creates a high-value target. The difference in crypto is that API key compromise can lead to immediate financial loss, because crypto exchanges settle trades in real time. There is no T+2 settlement window for a compliance team to intercept a fraudulent transaction.
The Self-Hosted Model
QuantForge runs entirely on your own hardware. The API server, the bot engine, the database, and the UI all run locally. No component communicates with external servers except for two necessary connections: the exchange API (for price data and order execution) and optionally the Claude API (for AI enrichment).
API keys are encrypted at rest using Fernet symmetric encryption with keys derived via PBKDF2. The encrypted keys are stored in the local SQLite database. Decryption happens in memory only when the key is needed for an exchange API call. The plaintext key never touches disk in unencrypted form.
The FastAPI server binds to localhost (127.0.0.1) by default. This means the API is only accessible from the local machine. Even if an attacker gained network access to your home network, they could not reach the API server from another device without explicit configuration to bind to all interfaces.
Bearer token authentication protects all API endpoints. Every request must include a valid token in the Authorization header. The token is stored in the .env file, which is excluded from version control by .gitignore.
Defense in Depth
Security is not a single mechanism. It is layers of protection, each catching failures that pass through the layer above.
Layer one is API key permissions. Exchange keys are configured with trade-only permissions. Withdrawal is disabled. Even if the keys are compromised, the attacker can place trades but cannot move funds off the exchange. This limits the worst case from total loss to trading loss.
Layer two is encryption at rest. Fernet encryption with PBKDF2 key derivation means that even if the database file is exfiltrated, the API keys are encrypted with a key derived from a password that exists only in the environment variables of the running process.
Layer three is network binding. The server binds to localhost. No external network access to the API is possible without explicit configuration. For distributed worker setups, binding to all interfaces is required but should be done only on trusted networks (we use Tailscale for encrypted point-to-point connectivity).
Layer four is authentication. Bearer token on every request. No anonymous access to any endpoint. The token is a shared secret between the client (browser, scripts, workers) and the server.
Layer five is the .env isolation. Sensitive credentials are stored in the .env file, which is never committed to version control. The file exists only on the machine where the platform runs. There is no central repository of credentials.
The Trust Surface
Every system has a trust surface: the set of entities you must trust for the system to be secure. Understanding your trust surface is essential for making informed security decisions.
With a cloud-hosted bot platform, your trust surface includes: the platform's engineering team, their cloud hosting provider (AWS, GCP, Azure), their CI/CD pipeline, their database encryption, their employee access controls, their SOC 2 compliance (if any), and their incident response capabilities. You are trusting dozens of systems and hundreds of people, most of whom you have never met and whose practices you cannot audit.
With a self-hosted platform, your trust surface is: your own machine's security, your network's security, and the exchange API's security. You control the first two directly. The third is unavoidable regardless of platform choice.
The reduction in trust surface is dramatic. Instead of trusting a cloud platform's entire security stack, you trust your own machine and your own practices. For a technically capable operator, this is a significant improvement, because you can audit and control every aspect of the security posture.
Practical Security Measures
Beyond the platform's built-in security, we recommend several operational practices.
Run the platform on a dedicated machine or virtual machine that is not used for general browsing or other activities. This reduces the attack surface from malware, phishing, and browser exploits.
Use a hardware firewall or host-based firewall to restrict inbound connections. The API server should only be accessible from localhost or from specific trusted IP addresses (such as your Tailscale network for distributed workers).
Rotate API keys periodically. Create a new key pair on the exchange, update the .env file, and disable the old keys. This limits the exposure window if a key is somehow compromised.
Monitor exchange account activity independently. Most exchanges provide email alerts for trades, logins, and API key changes. Enable these notifications so that unauthorized activity is detected even if the platform itself is compromised.
Keep the operating system and all dependencies updated. Security vulnerabilities in the OS, Python runtime, or npm packages can create attack vectors that bypass application-level security.
When Cloud Makes Sense
Self-hosted is not universally better. Cloud platforms offer convenience, managed infrastructure, and mobile access. For a trader running a single DCA bot with a few hundred dollars, the security risk of a cloud platform is proportional to the capital at stake and may be acceptable.
The security argument strengthens as capital increases. At $1K, a cloud platform breach is annoying. At $50K, it is devastating. At $500K, it is catastrophic. The effort required to run a self-hosted platform is constant regardless of capital. The benefit scales linearly with the amount at risk.
Our position is that any trader managing $10K or more in automated trading capital should seriously consider self-hosted infrastructure. The technical barrier is modest (Python, a terminal, and basic system administration), and the security improvement is substantial.
The core principle is straightforward: the fewer people who have access to your exchange API keys, the more secure your capital. A self-hosted platform means the number of people with access to your keys is exactly one.