For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.
Build image
Build a Docker image for your agent for each deployment platform.
Before you can add an agent to the Solo Enterprise for agentregistry catalog so that registry users can access and deploy the agent to a connected environment, you must build a Docker image for the agent and push it to a container registry. The build steps depend on the runtime that you plan to deploy your agent to.
| Deployment target | Example provider | Build steps |
|---|---|---|
| AI runtimes in Kubernetes | Solo Enterprise for kagent | Build a Docker image and push it to a container registry that your cluster can pull from. |
| Agentic cloud platforms | AWS Bedrock AgentCore | Build a Docker image, push it to Amazon ECR, and wrap it with the agent-proxy layer. |
Build a Docker image
Solo Enterprise for agentregistry uses the arctl CLI to build a Docker container image for your agent on your local machine and push it to a container registry. Later, when you add the agent to the Solo Enterprise for agentregistry catalog, you create a reference to its container image location, including the image repo and tag. This way, Solo Enterprise for agentregistry can retrieve the image and start the agent during deployment.
The build steps are mostly the same for every deployment target. AWS Bedrock AgentCore has two extra requirements: the image must target the linux/arm64 platform and be pushed to Amazon ECR, and you must wrap the image with the agent-proxy layer. agent-proxy captures and logs the agent’s traffic even without a managed gateway attached to the runtime; with one attached, it also routes that traffic through the gateway, so that agents can communicate with MCP servers and you can set up runtime authorization.
To build a Docker image, you can choose between the following options:
- Build the image locally. This option assumes that you want to build the agent image on your local machine only, such as for local test setups. The image is not pushed to your container registry. While you can still create a catalog entry for the agent image in Solo Enterprise for agentregistry, you cannot deploy the image to a Kubernetes cluster, unless you manually load the image to the cluster.
- Build and push: This process allows you to build the agent image on your local machine and push it to your container registry. Note that this option requires you to be logged into the container registry that you want to use and that the
agent.yamlfile includes the correct container registry and image tag details.
Create and run an agent on your local machine.
Review the image location and tag that was set for the agent in the
agent.yamlfile.By default, agentregistry uses
localhost:5001as the container registry andlatestas the image tag, such aslocalhost:5001/myagent:latest. If you want to use agentregistry to push images to your container registry, make sure to update this file with the registry and image tag that you want to use. Note that this update is not required if you want to build images locally only without pushing them to your container registry.cat myagent/agent.yamlExample output:
apiVersion: ar.dev/v1alpha1 kind: Agent metadata: name: myagent spec: source: image: localhost:5001/myagent:latest modelProvider: gemini modelName: gemini-2.5-flash description: myagent agentBuild the agent image on your local machine. The following command builds the image with the Dockerfile that is included in your
myagentscaffold and tags it with the container registry and version information that is provided in theagent.yamlfile. If you followed the instructions in the Create and run an agent guide,localhost:5001/myagent:latestis used.arctl build myagentExample output:
Building agent image: localhost:5001/myagent:latest ✓ Successfully built Docker image: localhost:5001/myagent:latestTip
To also use Solo Enterprise for agentregistry to push the image to your container registry, include the
--pushoption. You can also set the platform, for which you want to build the image, such aslinux/amd64by using the--platformoption. Note that you must log in to your container registry first, such as by usingdocker loginfor DockerHub. For more information, see the arctl build command.Verify that the image is built.
docker images | grep myagentExample output:
localhost:5001/myagent latest f7ba3e98adaa 11 minutes ago 2.93GBIf you did not push the image to a container registry, load the Docker image to your cluster. This step is required in local test setups, such as kind, to test the deployment of your agent later. Note that this step is not required if you pushed the image to a container image registry that your cluster can pull from.
kind load docker-image localhost:5001/myagent:latest --name <cluster-name>
To run an agent on AWS Bedrock AgentCore, the image must be wrapped with the agent-proxy layer. The agent-proxy layer intercepts all outbound traffic of the agent to log the source, destination, and byte counts for observability and auditing purposes. If you created a managed gateway when you set up the AgentCore runtime, the agent-proxy layer additionally reroutes all outbound traffic through the gateway so that the gateway can enforce runtime authorization policies and facilitate communication between the agent and MCP servers that are also deployed to AgentCore.
To wrap the agent image with the agent-proxy layer, you use the arctl wrap-agent-image command. Note that your Dockerfile must meet the following requirements to be eligible for wrapping:
- The Dockerfile must set a real
ENTRYPOINTorCMD. The image’s launch command is rewritten to start through theagent-proxylayer. If no launch command is set in your Dockerfile, the wrapping of the image fails. - If the Dockerfile sets a non-root
USER, that user must resolve from the image’s own/etc/passwdand/etc/groupfiles. Theagent-proxylayer preserves this user when it launches your agent, and fails to start if the identity does not resolve. - Your agent must listen on the port that AWS Bedrock AgentCore forwards requests to, which is
9000for theA2Aprotocol and8080ifspec.source.protocolis set toHTTPin your agent definition. Theagent-proxylayer forwards each inbound request to your agent on this same port.
AWS Bedrock AgentCore also only runs linux/arm64 images that it pulls from a private Amazon ECR repository in the same AWS account and region as your AgentCore runtime. Because of that, you must push the wrapped image to your Amazon ECR repository.
Create and run an agent on your local machine.
Create a private Amazon ECR repository for the agent image, if you don’t already have one. For more information, see Creating a private repository in the AWS documentation.
aws ecr create-repository \ --repository-name myagent \ --region <region>Example output:
{ "repository": { "repositoryUri": "123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent", ... } }Authenticate Docker to your ECR registry.
aws ecr get-login-password --region <region> \ | docker login --username AWS --password-stdin <account-id>.dkr.ecr.<region>.amazonaws.comBuild the
linux/arm64image and push it to the AWS ECR repository URI that you retrieved earlier. Make sure that your Dockerfile adheres to the requirements that were outlined earlier. The image that you create in this step serves as the base image for your agent. You later layer theagent-proxyon top of this image and also push the wrapped image to the same repository.Note
AgentCore spins up the agent from the wrapped image that you create in a later step, not the base image that you create in this step. You can store the base image in a container registry of your choice. However, this guide assumes that you want to store the base image in the same repository as the wrapped image.
arctl build myagent \ --image 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:latest \ --platform linux/arm64 \ --pushExample output:
Building agent image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:latest ✓ Successfully built Docker image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:latest ✓ Pushed image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:latestWrap the pushed base image with the
agent-proxylayer, and push the wrapped image to the same repository under a separate tag. AWS Bedrock AgentCore only pulls the wrapped image when deploying your agent runtime.arctl wrap-agent-image \ --image 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:latest \ --tag 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:wrapped \ --platform linux/arm64 \ --pushSetting Description --imageThe agent image to wrap. --tagThe reference to assign to the wrapped image. Use a new tag so that the unwrapped image stays available too. --platformThe platform of the base image. Use linux/arm64for AWS Bedrock AgentCore.--pushPush the wrapped image directly to the repository that you defined in the --tagoption.Update the
spec.source.imagefield in your agent definition (agent.yaml) file to point to the wrapped image tag, such as123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:wrapped.
Store source code
An Agent resource can also carry a spec.source.repository reference to the GitHub or GitLab repository that stores the agent’s Dockerfile and source code.
spec:
source:
image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/myagent:wrapped
repository:
url: https://github.com/myorg/agent.git
credentialsRef:
name: git-credentials| Field | Description |
|---|---|
url | The URL of the GitHub or GitLab repository that stores the agent’s Dockerfile and source code. |
branch | The branch to read. Omit to use the repository’s default branch. |
commit | A specific commit to pin to. Omit to use the latest commit on branch. |
subfolder | The path to the agent’s Dockerfile and source code, if they are not at the root of the repository. |
credentialsRef.name | Required only for private repositories. The name of a Secret that holds your GitHub or GitLab credentials. |
Note
If you reference a private repository, you must configure your GitHub or GitLab credentials and set credentialsRef on the repository. For more information, see Private repo access.
Important
For AWS Bedrock AgentCore, set spec.source.image to the Docker image that you built and wrapped, as described earlier. If spec.source.image does not resolve to an Amazon ECR repository, AWS Bedrock AgentCore builds and runs an image from spec.source.repository instead. This image does not contain the agent-proxy layer. It cannot route the agent’s traffic through the managed gateway, which affects runtime authorization and routing between the agent and its MCP servers.