OWASP Juice Shop is a deliberately vulnerable web application designed for security training. Running it locally gives you a controlled place to learn how web vulnerabilities appear and how to investigate them without testing a real service. This guide uses Docker to start Juice Shop on your own computer, then shows how to check that it is reachable and shut it down safely.
Key takeaways
- Use the official Juice Shop Docker image for a straightforward local lab.
- Bind the application to
127.0.0.1so it is intended to be reachable only from your own computer. - Keep the lab separate from public networks and real accounts or data.
- Practice only on your local Juice Shop instance or other systems for which you have explicit authorization.
Before you start
Install Docker Desktop or Docker Engine for your operating system, and make sure the Docker service is running. You can check whether the Docker CLI is available with:
docker --version
The command should print a version. If it reports that the daemon cannot be reached, start Docker and try again. If Docker is not installed, use the installation instructions for your operating system in Docker’s official documentation.
You will also need a modern browser and a free local port. The example below uses port 3000 on your computer. If another application already uses that port, choose a different host port as described later.
Install OWASP Juice Shop locally with Docker
Run the official bkimminich/juice-shop image and publish its application port on the loopback interface:
docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop
On its first run, Docker may need to download the image. Keep this terminal open while you use the lab. When the application starts, open http://127.0.0.1:3000 in your browser.
The -p option maps a port on your computer to a port in the container. In 127.0.0.1:3000:3000, the first address and port specify where the host listens; the final port is the application port inside the container. Binding to 127.0.0.1 is an important safety choice: do not replace it with 0.0.0.0 for this exercise, since that can make the service reachable on other network interfaces.
The --rm option removes the stopped container after it exits. It does not remove the downloaded image. The command runs in the foreground, so the terminal displays the application logs while the lab is running.
Check that the lab is working
- Wait for Docker to finish starting the container and look for startup output in the terminal.
- Visit
http://127.0.0.1:3000in your browser. - Confirm that the Juice Shop page loads before beginning exercises.
- Keep the terminal available so you can see logs and stop the container when you finish.
If the page does not load, check that Docker is running and that the container has not exited. You can stop the foreground container with Ctrl+C.
If port 3000 is already in use
Choose another unused port on your computer, such as 3001, while keeping the container port as 3000:
docker run --rm -p 127.0.0.1:3001:3000 bkimminich/juice-shop
Then open http://127.0.0.1:3001. The left-hand port is the host port; the right-hand port remains the application port inside the container.
Keep the practice environment isolated
Juice Shop is intentionally vulnerable. Treat it as a lab, not as a service to host for other people or use with real data.
- Do not expose it publicly. Avoid router port forwarding, public cloud deployment, or binding it to all network interfaces. The loopback binding in the example is intended to limit access to the local computer.
- Use only authorized targets. Apply what you learn to this local instance or to systems whose owners have explicitly authorized testing. Do not scan or attack unrelated websites, networks, or devices.
- Keep sensitive information out of the lab. Do not enter real passwords, personal information, or production data.
- Stop it when you are done. Press Ctrl+C in the terminal running the container. If you started it in the background instead, use
docker psto identify the container and stop it withdocker stop <container-id>. - Remember the limits of local binding. Loopback binding reduces network exposure, but it does not make a vulnerable application safe for production or protect against every risk on a computer where it runs. Avoid running it on a shared or untrusted machine.
Common setup problems
Docker cannot connect to its daemon
Start Docker Desktop or the Docker Engine service, then retry. On Linux, your account may need permission to use Docker; follow your system’s Docker installation guidance rather than changing permissions broadly.
The browser reports that the connection was refused
Check the terminal for startup errors and confirm the container is still running. Make sure you are visiting the correct host port: 3000 for the first command or 3001 for the alternate-port example.
The host port is unavailable
A different application may already be listening on that port. Select another unused host port and keep the container-side port at 3000, for example 127.0.0.1:3002:3000.
You cannot reach the lab from another device
That is expected with the loopback address. This tutorial intentionally keeps the lab local rather than making it accessible across a network.
A safe practice workflow
- Start the container with the loopback-bound command.
- Read the exercise instructions and work only against the local Juice Shop instance.
- Record what you observe and focus on understanding the underlying behavior and defensive fixes.
- Stop the container when your session ends.
- For current installation options and project guidance, consult the official OWASP Juice Shop repository.
Conclusion
Docker provides a simple way to run OWASP Juice Shop locally without installing its application dependencies directly on your computer. Binding the published port to 127.0.0.1, using fictional lab data, and stopping the container when finished help keep practice within a controlled environment. The application is intentionally vulnerable, so keep it out of production and never use it as a reason to test systems without authorization.