canonical: https://jentic.com/apis/azure.com/container-instance-management-client # Microsoft Azure ContainerInstanceManagementClient Jentic publishes the only available OpenAPI specification for ContainerInstanceManagementClient, keeping it validated and agent-ready. The Container Instance Management Client is the Azure Resource Manager API for Azure Container Instances (ACI) - running serverless container groups without managing a Kubernetes cluster. It exposes 16 endpoints covering container group create/update/delete, restart, stop, log retrieval, command execution, cached image lookup, and per-region capabilities and usage. Use it when an agent needs to run a one-shot container, exec into a running container, or pull logs. ## For AI agents Run, stop, restart, and exec into serverless container groups on Azure Container Instances; pull logs and inspect cached image availability per region. ## Scope Does not orchestrate Kubernetes clusters, manage container images in a registry, or run VMs - use for serverless single-container-group workloads on Azure Container Instances only. ## Capabilities - Create or update a container group with one or more containers, image, ports, and environment variables - Restart, stop, or delete a running container group from a single ARM call - Pull stdout and stderr logs from a named container in a group, with an optional tail line count - Execute a command inside a running container and stream the response over a websocket URL - List cached container images per region to predict cold-start latency - Query per-region capabilities and usage to size container group requests against quota ## Use cases ### Run an agent task as a one-shot container When an agent needs to run a sandboxed workload - a build, a data transform, or a model inference call - Azure Container Instances lets it spin up a container group, run the task, and tear it down without owning a cluster. The Container Instance Management Client creates the group with image, command, env, and resources, returns the public IP or DNS, and exposes Stop and Delete to clean up. Example prompt: PUT /subscriptions/{subscriptionId}/resourceGroups/agent-rg/providers/Microsoft.ContainerInstance/containerGroups/agent-job-001 with a Linux container image and command, then DELETE the group when the task exits. ### Pull logs from a running container Operators debugging a failing container group need stdout and stderr without SSHing into a host. The logs endpoint takes a container group, container name, and optional tail line count and returns the most recent log buffer, which can be streamed to an incident response channel or attached to a ticket. Example prompt: GET the logs subresource for container 'sidecar' in container group 'agent-worker' with tail=200 and post the response to the incident channel. ### Exec a command for live debugging ACI exposes a websocket-based exec channel so an operator can attach a shell to a running container without redeploying. The exec endpoint returns a websocket URI and a password; an agent can use this to run an env dump, inspect a process list, or rerun a failing migration step. Example prompt: POST the exec subresource on container 'sidecar' in container group 'agent-worker' with command '/bin/sh -c "ps aux"' and capture the websocket response. ### Quota-aware scheduling Azure Container Instances quotas vary per region. Before submitting many container groups, an agent should query usages and capabilities per location to confirm the requested vCPU and memory profile is available - this prevents wasted PUTs that 429 or 409 against subscription quota. Example prompt: GET /subscriptions/{subscriptionId}/providers/Microsoft.ContainerInstance/locations/eastus/usages and refuse to schedule new groups if vCPU usage > 80% of quota. ### Agent-driven sandboxed execution via Jentic An AI agent integrated through Jentic can use Azure Container Instances as a sandboxed runtime - pulling an image, running it with the agent's task as the entrypoint, fetching logs, and tearing the group down. Jentic's intent search exposes the right ACI operation for each phase and the AAD token never leaves the vault. Example prompt: Spin up an ACI container group with image 'mcr.microsoft.com/python:3.11', run the supplied script as the entrypoint, stream logs back, then delete the group. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | GET | /subscriptions/{subscriptionId}/providers/Microsoft.ContainerInstance/containerGroups | List container groups in a subscription | | GET | /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerInstance/containerGroups | List container groups in a resource group | | GET | /subscriptions/{subscriptionId}/providers/Microsoft.ContainerInstance/locations/{location}/cachedImages | List cached images for a region | | GET | /subscriptions/{subscriptionId}/providers/Microsoft.ContainerInstance/locations/{location}/capabilities | List ACI capabilities for a region | | GET | /subscriptions/{subscriptionId}/providers/Microsoft.ContainerInstance/locations/{location}/usages | Get ACI usage and quota for a region | | GET | /providers/Microsoft.ContainerInstance/operations | List Microsoft.ContainerInstance provider operations | ## Key resources - **ContainerGroups** — Create, update, list, get, restart, stop, and delete container groups - **Containers** — Pull logs and exec commands on individual containers in a group - **CachedImages** — List images cached on the ACI fabric per region - **Capabilities** — Per-region capabilities (vCPU/memory profiles) for container groups - **Usages** — Per-region subscription quota usage for container instances ## Why Jentic - **Setup:** Wiring Azure Container Instances by hand means an Azure AD app registration for the OAuth implicit flow against management.azure.com, Contributor on the resource group, and building both the container group ARM body and the websocket exec channel yourself. Through Jentic you install once, import ContainerInstanceManagementClient from the API Directory, store the Azure AD credential once, and your agent calls it. - **Permission scoping:** The subscription, resource group, and container group name are all URL path parameters (/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerInstance/containerGroups/{containerGroupName}), so a rule can pin the agent to one resource group and its container groups. You choose the operations it may call, so destructive ones like deleting a container group or exec-ing a command inside one are not included unless you add them. - **Credential handling:** Your Azure AD token for the user_impersonation scope is stored once, encrypted, by your own Jentic One instance and injected at execution time. It, along with any image-pull credentials, never enters the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'run a one-shot container on Azure' or 'pull logs from a container group', and Jentic returns the matching ACI operation with its input schema, including the container group and exec subresource shapes, so the agent calls the right endpoint directly. ## Related APIs - **Container Registry Management Client** — Manages the Azure Container Registry that ACI typically pulls images from - **Container Service Client** — Provisions full Kubernetes clusters when one-shot ACI groups are not enough - **Compute Management Client** — Standard VM-based compute when containers are the wrong abstraction ## FAQ ### Why is there no official OpenAPI spec for ContainerInstanceManagementClient? Microsoft Azure does not publish a single consolidated OpenAPI specification for the Container Instance Management Client. Jentic generates and maintains this spec so that AI agents and developers can call ContainerInstanceManagementClient via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the ContainerInstanceManagementClient use? It uses Azure Active Directory OAuth 2.0 with the implicit flow at https://login.microsoftonline.com/common/oauth2/authorize and the user_impersonation scope. The caller needs Contributor on the resource group. Through Jentic the AAD token sits in the encrypted vault. ### Can I exec into a running container with this API? Yes. POST the exec subresource on a named container in a container group with a command and terminal size. The response contains a websocket URI and a one-time password - open the websocket to attach to the container session. ### What are the rate limits for the ContainerInstanceManagementClient? ARM applies subscription-level read and write throttling (typically 12,000 reads and 1,200 writes per hour per subscription). Container instances also have per-region vCPU and memory quotas - call the usages endpoint to check current consumption against quota. ### How do I run a one-shot container through Jentic? Search Jentic for 'create azure container group', load the schema for PUT /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.ContainerInstance/containerGroups/{containerGroupName}, and execute it with image, command, and resources in the body. Run pip install jentic to get the SDK. ### Is the ContainerInstanceManagementClient free? Calling the management API itself is free, but each container group is billed per second on vCPU and memory allocated for the lifetime of the group. Standard ACI pricing applies; the spec does not change billing. ### Can I limit what my agent is allowed to do with the Azure Container Instances API? Yes. Because you run Jentic One yourself, your own rules decide which operations and credentials the agent may use. The subscription, resource group, and container group name are URL path parameters, so a rule can pin the agent to a single resource group and its container groups. You also choose which operations it may call, so destructive ones such as deleting a container group or exec-ing a command inside a running container are excluded unless you add them.