Testing APIs Running in Docker Containers

Running your API in a container doesn't change the problem browser-based API testing already runs into at localhost — it just adds one more layer between your browser tab and the actual process. This guide covers the container-networking part specifically; the underlying restriction is the same one covered there.

Where the request actually goes

A container's ports aren't reachable from anywhere by default. Starting a container like this:

docker run -p 3000:3000 my-api

publishes port 3000 on your machine to port 3000 inside the container. Once that mapping exists, http://localhost:3000 on your host machine reaches the containerized process — from your browser's point of view, it's exactly the same restriction as any other localhost server: same-origin policy blocks a hosted web page from reaching it, for the same reasons covered in the linked guide above.

If you're not sure a port is actually published, docker ps shows the mapping:

docker ps
# CONTAINER ID   IMAGE     PORTS                    NAMES
# 3f2a9c1d8e4b   my-api    0.0.0.0:3000->3000/tcp   my-api-container

No PORTS entry means nothing is reachable from the host at all yet — that's a Docker networking problem to fix before an API client, browser-based or not, can help.

Where Agent fits

Once a container's port is published to your host, it behaves like any other local endpoint. AlleForge Agent bridges it into your browser tab the same way it bridges plain localhost — install it once, start it while you're testing, and a request to http://localhost:3000/api/users reaches the container through Agent's local encrypted tunnel, without the traffic ever routing through AlleForge's own infrastructure.

Docker Compose and multi-container setups

If your API depends on other services (a database, a cache, another internal API) started via docker compose, only the ports you've explicitly published in your docker-compose.yml are reachable from the host. A service other containers reach over the internal Compose network isn't automatically exposed to your browser — if you need to test it directly, add a ports: mapping for it too.

What this doesn't fix

Agent solves the browser-to-local-machine boundary. It doesn't fix a container that isn't actually running, a port that was never published, or a Compose network misconfiguration — those show up the same way they would with any client, and docker ps/docker logs are still where you'd look first.