Deploy through MCP
The deployment workflow is discover → plan → inspect → apply → verify. Your client controls its own interaction and approval policy. Infralane validates permissions and configuration when executing its tools.
1. Discover the context
Ask the agent to inspect the projects and existing pools it can access. Use get_context, list_projects and list_resource_pools. Do not invent identifiers or treat configured pool sizes as live available-capacity measurements.
For GitHub sources, use list_repositories and choose a repository available through the project’s workspace installation.
2. Prepare a plan
Call plan_deployment with a project ID and a supported configuration. This example uses an existing public Docker image; replace the identifiers and image with values appropriate to your project.
{
"project_id": "<authorized project ID>",
"configuration": {
"name": "my-api",
"resource_pool_id": "<existing resource pool ID>",
"application_type": "web",
"source": {
"type": "docker",
"image": "<your accessible Docker image>"
},
"port": 8080,
"cpu_cores": 0.5,
"memory_mb": 512
}
}Use the port the image actually listens on. Source configurations use github, docker or zip discriminators. GitHub and ZIP source builds require a supported runtime of python, nodejs or static. An update supplies the existing application_id and requires the applicable configuration permissions.
3. Inspect the preview
Review application, source, pool, port, commands, limits and environment keys. Plans expire after fifteen minutes. A preview validates configuration; it neither deploys software nor purchases resources.
4. Apply the plan
Call apply_deployment using the returned plan ID and a stable, unique idempotency key. Reuse that key when retrying the same application of the plan, rather than creating a new operation accidentally.
{
"plan_id": "<returned plan ID>",
"idempotency_key": "<unique key for this operation>"
}5. Inspect the result
Use get_operation to follow submission. When it returns application and deployment IDs, use get_deployment and get_logs to inspect the result. Acceptance of an operation is not the same as a successful build or an available application.
Updates can replace a running container and cause downtime. An ambiguous submission must not be treated as a confirmed failure or blindly retried. Inspect the operation and the dashboard before deciding the next action.
For source archives, follow ZIP uploads. For current supported inputs and scope requirements, see the Tool reference.