ibl.ai's open-source Infra CLI reached 2.0 on October 12, 2026: it provisions the platform on AWS, GCP or an existing server against the 7.x declarative config system, takes one AWS key for pulling container images and a separate, optional key that reaches the platform's own storage, and refuses to half-configure a server on an older CLI, because on ibl.ai you own all the code and the data.
Infra CLI is the MIT-licensed installer at iblai/infra-cli: Terraform for the infrastructure, Ansible for the application, and a wizard that walks through cloud, credentials, topology, compute, network and domain.
The 2.0.0 release is the first major release since 1.0; its mirror on this site is at Infra CLI, and the deployment posture it serves is described at On-premise deployment.
What does Infra CLI 2.0 change for a self-hosted ibl.ai?
Three things, all about who holds which credential and how a server is configured.
| Change | Before 2.0 | In 2.0 |
|---|---|---|
| AWS keys | One key pulled images and served as the platform's own AWS credential | Two keys: an image-pull key, which also carries backup uploads by default, and an optional storage key, each scoped to its job |
| Config system | The legacy config system: ibl config save with implicit rendering |
The 7.x declarative model: init, config set, secrets set or generate, then an explicit render |
| Old CLI on the server | No version gate; the playbooks targeted the pre-7.x CLI | Setup checks the installed CLI and stops if it is older than 7.0.0 |
The release was validated on platform images release 1.277.0 with the 7.24.0 platform CLI, and the test suite stands at 1,109 passing tests.
Why does the installer now take two AWS keys instead of one?
Because a deployment whose registry access and S3 access live in different AWS accounts or IAM users had no way to say so, and the single key was handed to the platform as its S3 key.
Pulling container images is a deploy-and-update concern; storing media and SCORM uploads is the running platform's concern. One key doing both had to be scoped to both.
| Key | Variables | What it does | Where it lives |
|---|---|---|---|
| Image-pull key (required) | AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY |
Pulls the platform container images; needs ECR pull on the image repositories only. Backup uploads use it by default. | The server's default AWS CLI profile; never reaches the platform's own settings |
| Storage key (optional) | S3_ACCESS_KEY_ID / S3_SECRET_ACCESS_KEY, or the wizard prompt |
S3 storage, SCORM uploads, and SNS alerts when a topic is configured | The platform's own secrets file on the server, /ibl/secrets.yml; needs the buckets, plus sns:Publish only when a topic is configured |
The wizard offers a separate key, the same key, or skip. If the storage key is left unset, nothing is written: a fresh server renders without it, and iblai infra resetup keeps the key the server already has.
With buckets set and no storage key, setup stops before touching the server and says so.
AWS credentials are required on every deployment, including GCP and bare metal, because the images come from the registry; they are not for hosting, and object storage stays on AWS S3 even for a GCP deployment.
What does Infra CLI 2.0 setup look like on ibl.ai's 7.x config system?
The 2.0 playbooks drive the platform's declarative config model: ibl init, ibl config set, ibl secrets set or ibl secrets generate, then an explicit ibl render.
Setup requires the platform CLI at 7.0.0 or later and reads the release from one knob, PROD_IMAGES_TAG, which must name a platform images release that pins a 7.x CLI.
uv sync (--extra gcp for GCP), or uv tool install from git; Python 3.11+ and Terraform on PATHiblai infra permissions --check dry-runs the cloud policy before anything is creatediblai infra setup installs Docker, the platform CLI and the application; it is the only step on an existing serverhttps://learn.<your-domain>On the 7.x runtime, fresh installs and re-runs were fixed in four places: the Data Manager (DM) bootstraps without a manual launch, OAuth and OIDC credential rows are updated in place, every agent gets the settings row that chat reads, and the health-check agents pass the DM readiness gate.
iblai infra resetup no longer rotates the keys that encrypt stored data.
What else ships in Infra CLI 2.0?
NODE_ID, set with--node-id, in.envor in the wizard;ibl renderrequires it, and it defaults to the project name.- OpenRouter as the LLM key (
OPENROUTER_API_KEYor the wizard), stored as the deployment's gateway credential; the platform's default agents run on the gateway models (iblai-pro/iblai-fast), which only an OpenRouter key serves, so chat works with no further setup while tenants stay on the deployment's keys. - S3 storage for DM static files and media through
S3_STATIC_BUCKET,S3_MEDIA_BUCKETandS3_REGION; the platform keeps media, static assets and backups in three buckets that AWS provisioning creates for you. - SPA restarts follow the enabled SPAs instead of a fixed list, and the AI call service stays off until a call server is connected.
service-updateinstalls from the configured organization and repositories, and the GitHub token is kept out of install URLs.
How do you upgrade an existing ibl.ai deployment to Infra CLI 2.0?
Install the tool with uv tool install --force git+https://github.com/iblai/infra-cli and confirm iblai --version reports 2.0.0. Then pick a 7.x release by setting PROD_IMAGES_TAG or answering the wizard prompt.
An .env file that already names S3 buckets must also set the storage key, repeating the image-pull key there if one key does both jobs; .env.setup.example in the repo shows the layout.
Servers still on the 5.x platform CLI need the config migration first, documented in the repo's docs/config-6x-migration.md.
Why does an open-source installer matter to a buyer of self-hosted AI?
Because self-hosting is only real if someone can actually run it.
Most managed AI vendors cannot hand you an installer, since there is nothing of theirs to install; ibl.ai ships one under an MIT license, with the AWS, GCP and bare-metal paths in the same wizard, and the platform it installs comes with a Full Code License.
That is the sovereignty claim made concrete: the images pull with one scoped key, your data lives in buckets you own under a key that lives only in the platform's secrets file on your own server, any model answers through the LLM key you choose, and there is no per-seat pricing.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
Want to see a deployment provisioned end to end?
We will run the wizard against a cloud account of your choosing and walk through the two-key model and the 7.x config, in a 30-minute call. Book a 30-minute demo or talk to the ibl.ai team — ibl.ai is family-owned and operated from New York, NY.