Hosts isolated AI agents in Docker containers, each with their own workspace, conversation history persistence, and automatic container lifecycle management including idle timeout.
Enables agents to push code to repositories with scoped access tokens, create and update issues and PRs, and integrates with GitHub Actions for running agents in CI/CD workflows with artifact-based state persistence.
Provides workflow templates for running agents in CI/CD pipelines, with support for restoring and uploading agent state as artifacts, and CLI tools to pull agent data from workflow runs.
Supports Google/Gemini models for agent inference through API key configuration.
Supports OpenAI models for agent inference through API key configuration.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Containerized Strands Agentssend a message to my coding assistant to review the latest pull request"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Containerized Strands Agents
An MCP server that hosts isolated Strands AI agents in Docker containers. Each agent runs independently with its own workspace, persists conversation history, and can be restored after reboots.
Features
Async/Non-blocking:
send_messagereturns immediately (fire-and-forget)Isolated Agents: Each agent runs in its own Docker container
Session Persistence: Conversation history saved and restored across container restarts
Custom System Prompts: Configure per-agent system prompts via text or file
MCP Server Support: Connect agents to external tools via Model Context Protocol
GitHub Integration: Agents can push to repositories with scoped access tokens
AWS Profile Support: Pass different AWS profiles for different agents
Retry Logic: Automatic retry with exponential backoff for transient errors
Idle Timeout: Containers automatically stop after configurable inactivity period
Web UI: Browser-based interface for managing agents and chatting
Prerequisites
Python 3.11+
Docker (running)
AWS credentials configured in
~/.aws/with access to Amazon Bedrock (Claude models)
Quick Start
Open the URL shown in the terminal (usually http://localhost:8000) to create and chat with agents.
Installation
The Docker image will be built automatically on first use.
Usage
Web UI
The server finds an available port (starting at 8000) and displays the URL. Use the web interface to:
Create new agents with custom system prompts
Chat with existing agents
View agent status and conversation history
Stop idle agents
As an MCP Server (Kiro, Claude Desktop, etc.)
Add to your MCP configuration (e.g., ~/.kiro/settings/mcp.json):
The CONTAINERIZED_AGENTS_MCP_CONFIG env var sets a default mcp.json for all agents spawned by this server. You can point it to your existing Kiro config or a separate one.
MCP Tools
Tool | Description |
| Send message to agent (fire-and-forget), creates agent if needed |
| Get conversation history (use on-demand, not for polling) |
| List all agents and their status |
| Stop an agent's container |
send_message Parameters
CLI Commands for Snapshot/Restore
The CLI provides commands to create and restore agent snapshots (backups):
Create a Snapshot
Creates a zip archive of an agent's entire data directory, including:
Workspace files
Session history
System prompts
Tools
Runner files
Restore from Snapshot
Extracts a snapshot to a new (or existing) directory. The restored agent is immediately ready to run.
Examples:
Notes:
Snapshots work with both default data directories (
./data/agents/{id}) and custom onesThe CLI validates the directory structure before creating snapshots
Restoring to an existing directory will prompt for confirmation
Restored agents can be started immediately using the MCP server or Web UI
Pull from GitHub Actions
Downloads agent state from a GitHub Actions artifact. Useful for continuing work started in CI.
Options:
--repo(required): Repository inowner/repoformat--run-id: Download artifacts from a specific workflow run--artifact: Download a specific artifact by name--data-dir: Target directory (default:./agent-data)--token: GitHub token (usesGITHUB_TOKENenv var if not provided)
Examples:
GitHub Actions Workflow
A workflow template is provided at templates/gha-agent-workflow.yml for running agents in GitHub Actions:
The workflow:
Restores agent state from a previous artifact (optional)
Runs the agent with your message
Uploads updated state as an artifact
Trigger via workflow_dispatch with a message input. See the template for required secrets (AWS credentials).
Configuration
Environment Variables
These variables configure the MCP server. Set them either in your mcp.json (under env) or export them in your shell before running the web UI.
Server Configuration:
Variable | Default | Description |
|
| Base directory for persistence |
|
| Minutes before idle container stops (12 hrs) |
| - | Comma-separated paths to prompt files |
| - | Path to global tools directory |
| - | Path to default mcp.json for all agents |
Passed to Containers (agents can use these):
Variable | Description |
| GitHub PAT for git push access |
| OpenAI API key (for OpenAI models) |
| Google/Gemini API key |
| AWS bearer token for Bedrock authentication |
Example for web UI:
AWS Setup
Agents use Amazon Bedrock with Claude models by default. You have two options:
Option 1: AWS Credentials (default)
Your ~/.aws/credentials are mounted read-only into containers. Ensure your profile has Bedrock access.
Option 2: Bearer Token
Set AWS_BEARER_TOKEN_BEDROCK as an alternative authentication method for Bedrock.
GitHub Token Setup (Optional)
For agents that need to push to GitHub repositories:
Create a Fine-Grained Personal Access Token
Select "Only select repositories" and choose your repos
Grant "Contents: Read and write" permission
Set
CONTAINERIZED_AGENTS_GITHUB_TOKENenvironment variable
Agent Capabilities
Each agent has access to:
file_read,file_write,editor- File operationsshell- Execute shell commandspython_repl- Run Python codeuse_agent- Spawn sub-agentsload_tool- Dynamically load additional toolsGitHub tools - Create/update issues and PRs
MCP tools - Any tools from configured MCP servers
Important: Agents work in /data/workspace inside the container. This directory persists across container restarts.
MCP Server Support
Agents can connect to external MCP (Model Context Protocol) servers for additional tools. This uses the same config format as Kiro/Claude Desktop.
Quick Setup: Use Your Existing Config
Point agents to your existing Kiro mcp.json:
Or per-agent via MCP tool:
Inline MCP Config
Config Format
Same as Kiro/Claude Desktop:
Configuration Precedence
mcp_config_fileparam (path to mcp.json)mcp_configparam (inline dict)Agent's persisted config (
.agent/mcp.json)CONTAINERIZED_AGENTS_MCP_CONFIGenv var (global default)
MCP config is persisted per-agent, so you only need to set it once. Subsequent messages to the same agent will use the saved config.
Supported Transports
stdio (default): Local command-line MCP servers via
uvxornpxSSE: Remote HTTP-based MCP servers
Notes
uvxandnpxare pre-installed in containers - no need to install individual MCP serversEnvironment variables in config (like
${GITHUB_TOKEN}) are expanded at runtimeDisabled servers (
"disabled": true) are skippedFails open: If an MCP server fails to connect, the agent still starts with other tools. Check container logs for connection errors.
Data Persistence
Development
Troubleshooting
Docker image not found: Run ./scripts/build_docker.sh manually
Bedrock access denied: Ensure your AWS credentials have Bedrock permissions and the model is enabled in your region
Agent stuck processing: Check container logs with docker logs agent-<agent-id>
Port already in use: The web UI automatically finds an available port; check the terminal output for the actual URL
License
MIT