As of 13 August 2026, AI can only partly containerise your business application with Docker.

What to actually do

1. Hand it to a person

   The route this page recommends

   A person who owns the outcome does this end to end, worth it when the failure is dear.

2. Use a tool built for this

   Second choice

3. Do it yourself

   The distant third

   A chat interface, developer skill, and roughly 1 hour until you can act on the result.

   How to actually do it

   1. Open the application repository and record its file tree, language and framework versions, build files, local start command, test command, required ports and required external services.
   2. Remove secret values from the material, record only environment-variable names and purposes, and note which directories need persistent storage.
   3. Paste those details into the prompt and ask the model to generate the Dockerfile, Docker Compose file if needed, .dockerignore, health check and commands.
   4. Create the generated files in a separate branch of the repository, then compare every dependency, command, port, volume and environment variable against the actual application files.
   5. Build the image locally with Docker, start the container or Compose services, inspect the logs and run the application's existing test command inside the container.
   6. Test the health check, application endpoint, service-to-service networking, restart behaviour, persistent data and shutdown behaviour, then ask a colleague familiar with the deployment environment to check the configuration before release.

   Prompt

   You are helping me containerise a business application with Docker. Do not invent files, commands, ports, environment variables, services, credentials or deployment assumptions. First inspect the information below and list any missing details that could change the design. Then produce a minimal, production-conscious solution for the stated application.
   
   Application repository or relevant file tree:
   [PASTE FILE TREE OR REPOSITORY DETAILS]
   
   Main language, framework and version:
   [PASTE DETAILS]
   
   How the application is started locally:
   [PASTE COMMANDS]
   
   Build and dependency files:
   [PASTE package file, requirements file, project file, lock file or equivalent]
   
   Required services such as databases, queues or caches:
   [PASTE DETAILS, OR SAY NONE]
   
   Application port and any other required ports:
   [PASTE DETAILS]
   
   Files and directories that must persist:
   [PASTE DETAILS, OR SAY NONE]
   
   Environment variables, with secret values removed:
   [PASTE NAMES AND PURPOSES ONLY]
   
   Target environment:
   [PASTE LOCAL DEVELOPMENT, CI, A UK CLOUD HOST, OR OTHER TARGET]
   
   Constraints:
   [PASTE SECURITY, COMPLIANCE, ARCHITECTURE OR OPERATING SYSTEM CONSTRAINTS]
   
   Return:
   1. A Dockerfile, with the base image and each build step explained.
   2. A docker-compose.yml only if multiple services are required.
   3. A .dockerignore.
   4. Any required entrypoint or health-check files.
   5. Exact commands to build, run, stop, inspect logs and run the application's tests.
   6. A list of assumptions and unresolved decisions.
   7. A verification checklist covering dependency installation, application startup, ports, health checks, persistence, networking, permissions, secret handling and graceful shutdown.
   8. A short production-readiness warning listing anything that still needs a qualified technical review.
   
   Keep secrets out of all generated files. Do not recommend running as root unless you explain why it is necessary. Do not claim the configuration is production-ready until the commands and tests have been run against the actual repository.

   Open it prefilled in ChatGPT or Claude, or copy it into Gemini, which takes no prefill link.