Docker containers: run, inspect and stop one local web app

Set a small and observable goal

This evergreen guide covers the October 4 slot and was first published on October 5, 2026. Use a machine with Docker installed and its engine running, configured for Linux containers for this example. The goal is to understand one local application lifecycle, rather than to build a production hosting platform in one sitting.

Choose an unused host port, such as 8088, and a unique practice container name, spothub-container-lab. Check existing containers before starting. If either is already in use, choose a different value consistently throughout the exercise. Record the operating system and Docker version in your notes so another learner understands the environment.

Separate the image from the running container

Docker describes a container as an isolated process with its own filesystem, networking and process tree. An image provides the starting material for creating that process. Think of the image name and the container name as answers to different questions: what is being started, and which running instance are we inspecting?

For the exercise, use the docker/welcome-to-docker sample image from Docker's beginner guide. It serves a small demonstration page. This keeps the application deliberately simple so you can focus on execution and networking. Do not treat the sample as your own product or add customer records, passwords or production configuration to it.

Source: Docker Docs: What is a container?Docker Docs: Running containers

Start the sample on a local-only port

Run docker run -d --name spothub-container-lab -p 127.0.0.1:8088:80 docker/welcome-to-docker in your terminal. The detached option lets the command return while the process runs. The port mapping connects the host's loopback port 8088 to port 80 inside the container. Open http://127.0.0.1:8088 in the browser and inspect the page.

Write the two port numbers in separate columns: browser connection on the host, and application listener inside the container. They do not have to match. Binding to loopback is appropriate for this local exercise. If the command fails because the host port is occupied, select another unused host port instead of stopping an unrelated application.

Source: Docker Docs: Running containersDocker Docs: Publishing and exposing ports

Investigate using status and logs

Run docker ps and identify the named container, its status and its port mapping. Then run docker logs spothub-container-lab to inspect the available output. A started process and a visible page are separate observations: capture both. Logs may help investigate a failed start, but a quiet log is not proof that every application route works.

If the browser cannot connect, compare the address you typed with the published host port and check whether the container is still running. Do not immediately rebuild or reinstall everything. Write a short investigation sequence with the symptom, the command you used and what it ruled out. That sequence is useful evidence of cloud troubleshooting practice.

Source: Docker Docs: What is a container?Docker Docs: Running containers

Observe stopping, restarting and removal

Run docker stop spothub-container-lab and try a fresh request to the local address. The service should no longer answer; an already displayed browser page may remain visible from memory. Use docker ps -a to observe the stopped container. Run docker start spothub-container-lab and confirm that a new browser request works again.

When finished, stop this named practice container and remove it with docker rm spothub-container-lab. Do not run a broad cleanup command on a machine that contains other projects. Docker documents that removing a container removes its writable layer; persistent application data needs a deliberate storage design. This sample does not need a database or persistent volume.

Source: Docker Docs: Running containers

Explain what local success does not prove

Write a brief handoff explaining the image, container name, host port, container port, observed page and cleanup. Record the image identifier used in your run, because a later pull of a mutable image tag can change the starting contents. Keep the commands with the observations so you can repeat the experiment without relying on screenshots alone.

A successful local run does not demonstrate public availability, HTTPS, backups, resource limits, monitoring or a secure production configuration. Containerizing an application also does not make it run when its host is powered off. Extend this lesson through the related Cloud + DevOps path by adding a health check and a documented deployment environment as separate exercises.

Sources and further reading

• Docker Docs: What is a container? · checked 2026-10-05
• Docker Docs: Running containers · checked 2026-10-05
• Docker Docs: Publishing and exposing ports · checked 2026-10-05

Spot an error? Email info@spothub.in with the article link and correction.