Introduction

To run vi inside a Docker container, you first need an interactive shell in that container and an image that actually contains vi or vim. The command is simple, but the bigger practical issue is whether editing inside the container is the right workflow, because many containers are minimal and container filesystem changes are often ephemeral.

Enter the Container Interactively

If the container is already running, attach to it with docker exec:

docker exec -it my-container sh

If the image has Bash, you can use that instead:

docker exec -it my-container bash

Once you are inside, check whether vi exists:

vi --version

If that fails, the editor is not installed.

Install vi or vim if Needed

Many slim images do not ship with editors. The install command depends on the base distribution.

Debian or Ubuntu:

apt-get update
apt-get install -y vim

Alpine:

apk add --no-cache vim

RHEL or CentOS style images:

yum install -y vim

Then you can edit a file normally:

vi /etc/myapp/config.yml

Start a New Interactive Container

If you are not attaching to an existing container and only want a temporary shell, run the image interactively from the start:

docker run -it ubuntu:24.04 bash

Then install vim if the image does not already contain it.

This is useful for debugging or experimenting, but it is not the usual production configuration workflow.

Why Editing Inside the Container Is Often Temporary

One of the most important Docker facts is that a container is not the long-term source of truth. If you edit a file directly inside a running container and that container is recreated, your changes may disappear.

That is why many teams prefer one of these approaches instead:

• edit the file on the host and mount it into the container
• update the Docker image with a new build
• use an environment variable or external config source instead of editing in place

For example, mounting a directory from the host makes edits persistent:

docker run -it -v "$PWD/config":/app/config ubuntu:24.04 bash

Now the files live on the host, and container restarts do not erase them.

Basic vi Commands Still Matter

If you do not use vi often, the minimum commands are:

• press i to enter insert mode
• press Esc to leave insert mode
• type :wq to save and quit
• type :q! to quit without saving

That is usually enough for one-off edits in a container.

A Safer Debugging Pattern

If your goal is to inspect or patch a container for debugging, a typical sequence is:

docker exec -it my-container sh
cat /app/config.yml
vi /app/config.yml

Then, once you understand the fix, apply the same change to the real source of truth such as the Dockerfile, Helm chart, compose file, or mounted configuration directory.

That prevents the classic mistake of fixing production manually inside one container and then losing the change at the next restart.

Common Pitfalls

• Assuming every image has vi installed is wrong, especially for slim or security-focused images.
• Editing inside a running container and expecting the change to survive recreation is a common Docker misunderstanding.
• Using docker attach when you really want a fresh shell can produce confusing results; docker exec -it is usually the better tool.
• Installing packages into a production container for convenience can drift it away from the image definition.
• Forgetting whether the shell is sh or bash causes avoidable friction when attaching to minimal images.

Summary

• Use docker exec -it container-name sh or bash to open an interactive shell.
• Install vi or vim if the image does not already include it.
• Run vi path/to/file once you are inside the container.
• Remember that edits inside a container are often temporary unless the file is backed by a volume or baked into a new image.
• For durable changes, update the image, config mount, or deployment source rather than relying on manual in-container edits.