Documentation  ·  Getting started

Launching on Docker

This page is an outline. What is here is accurate, but it is not yet the whole story — each section ends with a note on what is still to be written. For anything it does not answer, DEPLOYMENT.md and USING-MCP.md in the repository are the complete references.

The container holds the web console and every MCP server it generates. One image, one port to publish, one volume to keep.

The minimum

docker run -d --name mcpdbwizard \
  -p 8080:8080 \
  -v mcpdbwizard-data:/data \
  mcpdbwizard-web

Add the Oracle settings from Connecting to Oracle — the console will tell you plainly if they are missing.

Why only 8080 is published

Generated servers bind 8090–8109 on loopback and are meant to be reached through the proxy on 8080, which is the only component that knows who is calling. Publishing them directly bypasses the accounts, the access grid and the per-caller limits.

If you do it anyway, the server refuses to start unless it was generated with bearer tokens or OAuth: exposure is the act that puts it on a network, while authentication is opt-in.

The /data volume

Configs, accounts, access grants, each runtime’s workspace and (if you enable it) the audit spool all live here. Keep it. Replacing the image is then routine; losing the volume is losing your curation.

Set a memory limit

Without a cgroup limit, the container’s memory metric is a percentage of the whole host — Docker does not hide the host’s RAM from a container. A limit creates real cgroup accounting, and the metric’s basis label flips from host to cgroup.

    deploy:
      resources:
        limits:
          memory: 4g

The image already sets JAVA_TOOL_OPTIONS=-XX:MaxRAMPercentage=75. Overriding that variable replaces it, so keep the heap setting if you add anything to it.

To write. A worked docker-compose.yml; Kubernetes notes; the published image name and tag policy, once there is a registry to name; upgrade and rollback steps.