Docker
A container engine that packages software with the tools it needs and runs it isolated from the host. Things here that ship as an image need it installed, so the reader installs the engine rather than each of the command line tools inside the container.
Where it sits
Used by
Required dependency. building the images the workflow templates run; the README asks for DockerHub or Docker access before the notebooks are started
Optionally used: ARC-1 is run via the Docker image or local Docker-based development running ARC-1 as the published container image or in local Docker-based development
Optionally used: ARC-1 and its extension are deployed as a Docker image rather than run locally or on Cloud Foundry building and running an image that bundles the extension alongside arc-1arc-1An MCP server in front of the ADT REST API that runs locally and on Cloud Foundry with twelve tools that read, search, write, activate, lint and transport ABAP objects.independent, abap
Functional boundary
Classic BOPF only: business objects of the ABAP Programming Model for SAP Fiori are not handled, and on [the BTP ABAP environment](artifact:btp-abap-environment) or S/4HANA Public Cloud classic BOPF enhancements do not exist. It is version 0.1.0, verified on S/4HANA 2025 (SAP_BASIS 816) on-premise only, and [arc-1](artifact:arc-mcp-arc-1) still marks the plugin API it is built on as experimental. ARC-1 loads no extensions on its multi-target routes and offers none of these tools in its `hyperfocused` tool mode.
Required dependency. The engine that runs the container the script and the command line tools it drives live in; the basic setup lists installing it among the prerequisites, and the images are either pulled pre-built or built on the reader's machine.
RepositoryThe declared repository is archived
Optionally used: the dev container tools option described in unit 1 lesson 3 is chosen rather than a GitHub Codespace the container engine the dev container the lessons are worked through in runs on
Optionally used: the container runs locally under VS Code and Docker Desktop is the container manager; the README names Podman as an alternative the container manager the definition is reopened in on your own machine, where Docker Desktop is the one chosen
Optionally used: deployed via the project's Docker images running the server as a container image instead of an npm install
Functional boundary
Two licences, by which package you install: the standalone server, `@mcp-abap-adt/core`, is AGPL-3.0-only, a licence to read before shipping anything built around it; the library, `@mcp-abap-adt/lib`, is Apache-2.0. The destination model also expects service keys sitting in a local directory, which is a secrets decision to make deliberately.
Optionally used: running the self-hosted Docker path instead of BTP or the ARC-1 extension The server is packaged and run as a container image for self-hosted deployment.
Functional boundary
LISA does the translation step only: it does not discover objects or manage transports, and its README pairs it with [an ADT MCP server](artifact:sap-adt-mcp-server) for those. Every write needs a transport request, and which object types it can write differs between public cloud or [the SAP BTP ABAP environment](artifact:btp-abap-environment) and on-premise or private cloud, and by release. Running it locally is meant for development and testing, not production.
Optionally used: the server is started from the published container image rather than with npx or from a checkout the container engine the published image runs in, which is the way the README recommends starting the server
Functional boundary
Development and sandbox systems only: the README warns against pointing it at production. Transport release is never executed, since the tool exists to show the policy stopping it, and separation of duties is checked against the `identity.approvers` list in the policy file rather than against SAP authorisations, so it holds as far as that file does and no further. The write path has been tested with ABAP classes and other object types may need adjustments, there is deliberately no tool that creates or deletes an object, and one server instance serves one SAP system.
Optionally used: deploying the server as a container instead of running it directly with uv Running the server as a packaged container image rather than via the local Python environment.
Functional boundary
It reads the landscape inventory, not the systems in it — nothing here reaches a running application, and nothing here changes anything. A landscape description is also commercially sensitive in its own right: versions and hosts are what a targeting exercise starts from.
Optionally used: A container image is built for deployment in AWS Cloud, and Docker rather than finch or podman is the engine used Building the container image that is deployed in the AWS Cloud; the README names finch and podman as alternatives to it.
Functional boundary
There is nothing to clone here: "Access is provided through a registration page. Once registered, you will receive access to the GitHub repository containing the agents, deployment guides, and documentation", and that repository answers 404 to anyone who has not registered, so neither the agent code nor the deployment guides can be read before the form is filled in. AWS states the agents are published as an unsupported solution, with customers responsible for testing and securing the code before deploying in production, and that they are intended for non-production SAP environments rather than production systems. The documentation link in the README is still a placeholder.
Optionally used: it is started as a container rather than from the clone, a binary or the browser build runs the published image and the compose stacks, one per database; the arm64 image also runs on a Raspberry Pi 4
Functional boundary
Not a system to run a business application on: there is no business application in it, and what it implements of the language, the dictionary and Gateway is a stated subset of each. It is a clean-room reimplementation of the `/IWBEP/` interfaces that bundles no SAP source and no standard DDIC, so a service that reads standard objects has nothing to read, and `ANORMALIES.md` records every place the runtime differs from SAP before any workaround is written.
Optionally used: the API is run or deployed as a container Running the Python stack as a container, the route the README gives for skipping the Python part and the one the deployment steps build on.
Optionally used: deployed via the pre-built Docker image running ROSA as a self-hosted server using the published GHCR image
Functional boundary
It answers about the object catalogue, not about your code: nothing here reads your system, so it will tell you a table is not released and not that you used it. That check is ATC's, and this is what makes ATC's answer actionable.
Optionally used: the recommended dev container tools option is used the engine behind the dev container the README recommends for the exercises' tools.
Required dependency. Running the stacks, which are Docker Compose files, and building the Cloud Connector image.
Details
Graph
For your agent
- Ref
external:docker- JSON
- /externals/docker.json
- MCP
- Connecting an agent