agentsclimarketplace

Iblai api infrastructure

Skill iblai/api/skills/iblai-api-infrastructure

Agent skills + a chat MCP server to operate the ibl.ai platform via its REST API. Install: npx skills add iblai/api

Install
npx -y skills add iblai/api --skill iblai-api-infrastructure

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 15 stars15 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

4.5 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it

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

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.

What ships with it: 5 files

69.5 KB alongside SKILL.md

references/

Gives 0 of the 12 instructions most containers cloud skills give in ~1.0k tokens

Counted across 607 of the 657 authors here whose files we hold, read 2026-08-07

  • Run containers as a non-root userin 66 of 607, across 46 files
  • Use multi-stage buildsin 53 of 607, across 44 files
  • Use Promise.all for independent operationsin 47 of 607, across 13 files
  • Import directly instead of barrel filesin 46 of 607, across 12 files
  • Use ternary instead of AND for conditionalsin 45 of 607, across 12 files
  • Use Set or Map for O(1) lookupsin 42 of 607, across 10 files
  • Create a .dockerignore filein 41 of 607, across 31 files
  • Read individual rule files for detailsin 39 of 607, across 9 files
  • Copy dependency files before source codein 36 of 607, across 23 files
  • Authenticate server actions like API routesin 35 of 607, across 7 files
  • Use next/dynamic for heavy componentsin 34 of 607, across 9 files
  • Use React.cache for per-request deduplicationin 34 of 607, across 10 files

Said here and by no other author read

  • start server provisioning with the infra-cli
  • consult aws-architecture for single and multi-server topologies
  • launch staging environments from pre-baked amis
  • configure identity providers in the lms
  • deploy agent-sandbox gateway servers
  • wire deployed claw servers to the api

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 327,069. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.