The i26g Control Plane runs the i26g Platform: it deploys, promotes, checks, and rolls back the platform from Git. But a control plane is only as reliable as what it runs on, and “infrastructure of your choosing” can easily mean taking that foundation on trust. This post describes how i26g avoids that, while leaving your infrastructure yours.
Preconditions Must Be Known, Not Assumed
A trading operation fails in quiet ways when its foundation is wrong. Too little memory, a network shared with other workloads, backups that were never configured, or a clock that drifts will not stop the platform from starting. They show up later, as a missed order or a strategy acting on stale data.
So the i26g Control Plane cannot simply assume that whatever it runs on is right. It needs to know. There are three ways to get there:
| Approach | What i26g does | What it means for you |
|---|---|---|
| Verify only | Declares what it needs and checks it | It tells you when something is wrong, but you fix everything yourself |
| Own a bounded environment | Is given a boundary, checks it, and builds everything inside | You decide the boundary; i26g takes care of what is inside it |
| Own all the infrastructure | Manages everything down to the hardware | You would have to hand over your hosts and network, including what runs your other work |
i26g takes the middle one.
The Boundary Is the Contract
You set up a bounded environment for the trading operation, with whatever tooling you already use:
- a resource pool, with storage of a fixed size;
- a network zone and an IP range of its own;
- outbound access only to what the platform needs, such as brokers and data sources;
- credentials scoped to exactly that boundary and nothing else.
What the boundary must provide is i26g’s infrastructure contract. It is the same whether you run on your own hardware or in a cloud project. In my own setup, my laptop creates it, as described in My Laptop as Infrastructure Control Plane and Client.
Bootstrap and Handover
Inside the boundary, you create one VM and boot it from the i26g Control Plane image. That is the handover. From then on:
- The control plane checks the contract. If a resource, the isolation, or an access is missing, it refuses to proceed and says why.
- It builds the environment. It creates the VMs, the networks within its zone, and the storage the platform needs.
- It runs the platform. It deploys, promotes, checks, and rolls back the i26g Platform from Git, with trading-aware checks such as data freshness, risk limits, and broker health.
- It keeps checking. The contract is not a one-time gate; it is part of every reconciliation cycle.
The control plane never manages its own VM, and it cannot change its boundary. Both stay with you, so a broken control plane can always be repaired, rebuilt, or cut off from outside.
It can still watch both. When it sees its own VM running short, or the boundary no longer fitting what the platform needs — more memory, more storage, another IP range — it asks for the change, for example as a proposed change to your infrastructure repository, which you review and apply like any other. Asking stays separate from granting, so the control plane can never enlarge its own authority.
What Stays Yours
Everything outside the boundary: your hosts, your network, your accounts, and the other workloads you run beside the trading operation. i26g never needs administrative access to any of it.
What you get is a trading environment that knows its own preconditions, builds and runs itself within the limits you set, and tells you — rather than failing quietly — when those limits no longer fit.
How do you make sure a platform’s preconditions are actually met, rather than assumed? Leave a comment below, or reach out through another channel if you would rather keep the conversation private. Follow the RSS feed for more.