Introduction

Running TensorBoard in a Docker container on Google Cloud is straightforward when you treat it as a network path problem with three layers: process binding, container port publishing, and cloud access control. Most connection failures happen because one of those layers is configured for local-only access. A secure setup keeps TensorBoard reachable for you while minimizing public exposure. In shared cloud environments, access control should be treated as a first-class concern, not an afterthought after port forwarding works.

Build a Container That Starts TensorBoard Correctly

TensorBoard must listen on all container interfaces, not loopback, or external requests cannot reach it through Docker.

1FROM python:3.11-slim
2
3RUN pip install --no-cache-dir tensorboard
4
5WORKDIR /app
6
7EXPOSE 6006
8
9CMD ["tensorboard", "--logdir", "/logs", "--host", "0.0.0.0", "--port", "6006"]

Build and run locally first.

docker build -t tb-image .
docker run --rm -p 6006:6006 -v "$PWD/logs:/logs" tb-image

Visit http://localhost:6006 to verify the image before moving to Google Cloud.

Run on a Google Cloud VM with Port Mapping

On a Compute Engine VM, launch the same container and map host port 6006.

1docker run -d --name tensorboard \
2  -p 6006:6006 \
3  -v /home/ubuntu/tb-logs:/logs \
4  tb-image

Basic health checks:

docker ps
docker logs --tail 50 tensorboard
curl -I http://127.0.0.1:6006

If local curl fails on the VM, fix container startup first. Do not adjust firewall rules until service health is confirmed.

Prefer SSH Tunneling for Private Access

The safest pattern is keeping port 6006 closed publicly and using an SSH tunnel.

gcloud compute ssh ml-vm --zone us-central1-a -- -L 6006:localhost:6006

Then open a browser on your local machine at http://localhost:6006.

Benefits of tunnel mode:

• no public TensorBoard endpoint
• no broad ingress rule
• access controlled by IAM and SSH policy

For personal or small-team usage, this is usually the best operational default.

If Public Access Is Required, Restrict It Hard

Sometimes you need direct browser access without tunnel. In that case, create a firewall rule restricted to known source IP ranges.

1gcloud compute firewall-rules create allow-tensorboard-restricted \
2  --network=default \
3  --direction=INGRESS \
4  --action=ALLOW \
5  --rules=tcp:6006 \
6  --source-ranges=203.0.113.10/32 \
7  --target-tags=tensorboard

Attach the matching network tag to the VM instance. Avoid open ingress like global source ranges for TensorBoard.

Use Docker Compose for Repeatability

For shared environments, encode runtime config in compose files.

1services:
2  tensorboard:
3    image: tb-image
4    command: tensorboard --logdir /logs --host 0.0.0.0 --port 6006
5    ports:
6      - "6006:6006"
7    volumes:
8      - /home/ubuntu/tb-logs:/logs
9    restart: unless-stopped

Then start with:

docker compose up -d

This removes guesswork when another engineer needs to reproduce your setup.

Integrate with Training Jobs Cleanly

TensorBoard is only useful if logs are written reliably. Standardize log paths from training jobs so the container always reads from expected directories.

1import tensorflow as tf
2
3log_dir = "/home/ubuntu/tb-logs/run-001"
4writer = tf.summary.create_file_writer(log_dir)
5
6with writer.as_default():
7    for step in range(5):
8        tf.summary.scalar("loss", 1.0 / (step + 1), step=step)
9        writer.flush()

When logs appear empty, validate that the training process writes event files to the mounted directory that TensorBoard reads.

Debugging Checklist for No-UI Problems

Use this order to avoid random changes:

1. Confirm event files exist in mounted log directory.
2. Confirm TensorBoard process is listening on 0.0.0.0:6006.
3. Confirm Docker publishes port 6006.
4. Confirm local VM curl works.
5. Confirm tunnel or firewall path from your laptop.

This sequence isolates failures quickly and keeps troubleshooting systematic.

Common Pitfalls

A frequent mistake is leaving TensorBoard bound to localhost in container startup. Docker port publishing cannot expose a service that is not listening on container interfaces.

Another mistake is verifying browser access before checking local endpoint health on the VM. That mixes application and network issues.

A third mistake is opening unrestricted ingress rules for debugging and forgetting to close them afterward.

Teams also mount the wrong log directory path and assume networking is broken when the real issue is missing event files.

Summary

• Treat TensorBoard visibility as process, container, and cloud network layers.
• Bind TensorBoard to 0.0.0.0 and publish the correct Docker port.
• Prefer SSH tunneling for secure day-to-day access.
• Use restricted firewall ingress only when direct public access is necessary.
• Standardize log paths and follow an ordered debugging checklist for faster resolution.