Skip to content
Latest (currently 2026.9.0) has the newest features, bug fixes, and CVE patches of Solo Enterprise for agentregistry.

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

Page as Markdown

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 targetExample providerBuild steps
AI runtimes in KubernetesSolo Enterprise for kagentBuild a Docker image and push it to a container registry that your cluster can pull from.
Agentic cloud platformsAWS Bedrock AgentCoreBuild 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.yaml file includes the correct container registry and image tag details.
  1. Create and run an agent on your local machine.

  2. Review the image location and tag that was set for the agent in the agent.yaml file.

    By default, agentregistry uses localhost:5001 as the container registry and latest as the image tag, such as localhost: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.yaml

    Example 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 agent
    
  3. Build the agent image on your local machine. The following command builds the image with the Dockerfile that is included in your myagent scaffold and tags it with the container registry and version information that is provided in the agent.yaml file. If you followed the instructions in the Create and run an agent guide, localhost:5001/myagent:latest is used.

    arctl build myagent

    Example output:

    Building agent image: localhost:5001/myagent:latest
    ✓ Successfully built Docker image: localhost:5001/myagent:latest
    

    Tip

    To also use Solo Enterprise for agentregistry to push the image to your container registry, include the --push option. You can also set the platform, for which you want to build the image, such as linux/amd64 by using the --platform option. Note that you must log in to your container registry first, such as by using docker login for DockerHub. For more information, see the arctl build command.

  4. Verify that the image is built.

    docker images | grep myagent 

    Example output:

    localhost:5001/myagent latest  f7ba3e98adaa   11 minutes ago     2.93GB
    
  5. If 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 ENTRYPOINT or CMD. The image’s launch command is rewritten to start through the agent-proxy layer. 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/passwd and /etc/group files. The agent-proxy layer 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 9000 for the A2A protocol and 8080 if spec.source.protocol is set to HTTP in your agent definition. The agent-proxy layer 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.

  1. Create and run an agent on your local machine.

  2. 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",
        ...
      }
    }
    
  3. 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.com
  4. Build the linux/arm64 image 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 the agent-proxy on 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 \
      --push

    Example 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:latest
    
  5. Wrap the pushed base image with the agent-proxy layer, 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 \
      --push
    SettingDescription
    --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/arm64 for AWS Bedrock AgentCore.
    --pushPush the wrapped image directly to the repository that you defined in the --tag option.
  6. Update the spec.source.image field in your agent definition (agent.yaml) file to point to the wrapped image tag, such as 123456789012.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
FieldDescription
urlThe URL of the GitHub or GitLab repository that stores the agent’s Dockerfile and source code.
branchThe branch to read. Omit to use the repository’s default branch.
commitA specific commit to pin to. Omit to use the latest commit on branch.
subfolderThe path to the agent’s Dockerfile and source code, if they are not at the root of the repository.
credentialsRef.nameRequired 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.

Next