iblai-api-infrastructure
How the ibl.ai platform is deployed and self-hosted on infrastructure you control:
the AWS topology, the tooling that provisions it, the SSO wiring for the edX LMS, and
the agent-sandbox (claw) gateway servers that back live agent chat.
Unlike the other iblai-api-* skills, this one is not a REST reference — it doesn't
call api.iblai.app, and it needs no IBLAI_ORG / IBLAI_API_KEY. It documents server
provisioning, ssh / CLI / Terraform / Ansible workflows, and provider consoles. Access
to the ibl.ai Docker images and platform codebase requires a license — see
ibl.ai/contact.
When to use
- Standing up the platform on your own AWS account (or an existing server / bare
metal) — start with
references/infra-cli.md, and see
references/aws-architecture.md for the resulting
topology.
- Launching or rebuilding staging environments from pre-baked AMIs via CI —
references/ami-pipeline.md.
- Adding Single Sign-On (Google, Microsoft/Entra, Apple, or a generic OIDC provider)
to the Open edX LMS —
references/edx-sso.md.
- Deploying an agent-sandbox gateway (OpenClaw on a VPS/Hetzner, or NVIDIA NemoClaw)
and connecting it to the platform —
references/claw-servers.md.
For the API side — registering a claw instance, storing its device keypair, pushing
config, health checks, and setting an agent's model — use /iblai-api-agent-sandbox.
Deploy the server here, then wire it up there.
Scope note
These guides reference server-level and provider-level surfaces (SSH, systemd, cloud
firewall consoles, the LMS Django admin) because that is the actual deployment mechanism
— this is the ops complement to the endpoint-focused REST skills, not a UI walkthrough of
api.iblai.app.
Reference material
Everything is in references/ — pick the file for the job. Each is self-contained enough
to deploy from:
references/aws-architecture.md — single-server
and multi-server AWS topology (VPC, subnets, ALB, EC2, ACM certs and their exact
subdomains, S3 buckets, security groups), the provision → Terraform → Ansible flow, and
the 9 Ansible roles with their full container inventory.
references/infra-cli.md — the iblai-infra-cli
provisioner: prerequisites, install (uv/pip), provision / setup / list / status
/ auth / destroy commands, the 9 setup roles, what Terraform + Ansible create,
authentication, and the ~/.iblai-infra workspace.
references/ami-pipeline.md — the GitHub Actions
golden-AMI launch pipeline for stg1–stg4: permanent vs ephemeral infra, AMI
contents, the 6 pipeline steps (incl. the 14-step Ansible service-update), timing,
repo map, secrets/variables, the IAM policy, known cold-boot behaviors, and how to bake
a new AMI.
references/edx-sso.md — adding SSO IdPs to the edX LMS:
the deployment-config vs Django-admin layers, the plugin gate, per-provider setup
(Google, Microsoft, Apple's signed-JWT secret, generic OIDC with full claim/endpoint
config), running multiple OIDC providers, org linking via TRACKED_PROVIDERS /
platform_key, apply/restart, verification, and troubleshooting.
references/claw-servers.md — deploying an
OpenClaw or NemoClaw gateway end to end: architecture, prerequisites, install, the
full openclaw.json config, Caddy + Let's Encrypt, firewall (cloud + UFW), validation,
Ed25519 device-identity signing, connecting to the platform, multi-agent setups,
updates, monitoring, the device re-pairing problem with its full solution catalog, and
the OpenClaw + NemoClaw snags tables.
1---2name: iblai-api-infrastructure3description: Deploy and self-host the ibl.ai platform infrastructure — AWS single/multi-server architecture, the golden-AMI staging launch pipeline, the iblai-infra-cli (Terraform + Ansible) provisioner, edX LMS SSO identity providers (Google/Microsoft/Apple/OpenID Connect), and standing up OpenClaw/NemoClaw agent-sandbox gateway servers. This is the ops/self-hosting reference (how the platform is deployed on infrastructure you control), not api.iblai.app REST calls. For the API side of claw instances, see /iblai-api-agent-sandbox.4---56# iblai-api-infrastructure78How the ibl.ai platform is **deployed and self-hosted** on infrastructure you control:9the AWS topology, the tooling that provisions it, the SSO wiring for the edX LMS, and10the agent-sandbox (claw) gateway servers that back live agent chat.1112Unlike the other `iblai-api-*` skills, this one is **not** a REST reference — it doesn't13call `api.iblai.app`, and it needs no `IBLAI_ORG` / `IBLAI_API_KEY`. It documents server14provisioning, `ssh` / CLI / Terraform / Ansible workflows, and provider consoles. Access15to the ibl.ai Docker images and platform codebase requires a license — see16[ibl.ai/contact](https://ibl.ai/contact).1718## When to use1920- **Standing up the platform** on your own AWS account (or an existing server / bare21 metal) — start with [`references/infra-cli.md`](references/infra-cli.md), and see22 [`references/aws-architecture.md`](references/aws-architecture.md) for the resulting23 topology.24- **Launching or rebuilding staging environments** from pre-baked AMIs via CI —25 [`references/ami-pipeline.md`](references/ami-pipeline.md).26- **Adding Single Sign-On** (Google, Microsoft/Entra, Apple, or a generic OIDC provider)27 to the Open edX LMS — [`references/edx-sso.md`](references/edx-sso.md).28- **Deploying an agent-sandbox gateway** (OpenClaw on a VPS/Hetzner, or NVIDIA NemoClaw)29 and connecting it to the platform — [`references/claw-servers.md`](references/claw-servers.md).3031For the **API side** — registering a claw instance, storing its device keypair, pushing32config, health checks, and setting an agent's model — use `/iblai-api-agent-sandbox`.33Deploy the server here, then wire it up there.3435## Scope note3637These guides reference server-level and provider-level surfaces (SSH, systemd, cloud38firewall consoles, the LMS Django admin) because that is the actual deployment mechanism39— this is the ops complement to the endpoint-focused REST skills, not a UI walkthrough of40`api.iblai.app`.4142## Reference material4344Everything is in `references/` — pick the file for the job. Each is self-contained enough45to deploy from:4647- **[`references/aws-architecture.md`](references/aws-architecture.md)** — single-server48 and multi-server AWS topology (VPC, subnets, ALB, EC2, ACM certs and their exact49 subdomains, S3 buckets, security groups), the provision → Terraform → Ansible flow, and50 the 9 Ansible roles with their full container inventory.51- **[`references/infra-cli.md`](references/infra-cli.md)** — the `iblai-infra-cli`52 provisioner: prerequisites, install (uv/pip), `provision` / `setup` / `list` / `status`53 / `auth` / `destroy` commands, the 9 setup roles, what Terraform + Ansible create,54 authentication, and the `~/.iblai-infra` workspace.55- **[`references/ami-pipeline.md`](references/ami-pipeline.md)** — the GitHub Actions56 golden-AMI launch pipeline for `stg1`–`stg4`: permanent vs ephemeral infra, AMI57 contents, the 6 pipeline steps (incl. the 14-step Ansible service-update), timing,58 repo map, secrets/variables, the IAM policy, known cold-boot behaviors, and how to bake59 a new AMI.60- **[`references/edx-sso.md`](references/edx-sso.md)** — adding SSO IdPs to the edX LMS:61 the deployment-config vs Django-admin layers, the plugin gate, per-provider setup62 (Google, Microsoft, Apple's signed-JWT secret, generic OIDC with full claim/endpoint63 config), running multiple OIDC providers, org linking via `TRACKED_PROVIDERS` /64 `platform_key`, apply/restart, verification, and troubleshooting.65- **[`references/claw-servers.md`](references/claw-servers.md)** — deploying an66 OpenClaw or NemoClaw gateway end to end: architecture, prerequisites, install, the67 full `openclaw.json` config, Caddy + Let's Encrypt, firewall (cloud + UFW), validation,68 Ed25519 device-identity signing, connecting to the platform, multi-agent setups,69 updates, monitoring, the device re-pairing problem with its full solution catalog, and70 the OpenClaw + NemoClaw snags tables.