Introduction

Running a web server in Google Colab is possible, but localhost behaves differently than it does on your laptop. The notebook is running on a remote machine, so a server started on 127.0.0.1 is local to the Colab runtime, not directly visible in your browser unless you expose it through a proxy or tunnel.

Understand What localhost Means in Colab

In a normal local development setup, opening http://127.0.0.1:5000 in the browser reaches a server running on your own machine. In Colab, the code runs on a hosted VM, so that same address refers to the VM itself.

That means this pattern works inside the notebook process:

1from http.server import HTTPServer, SimpleHTTPRequestHandler
2
3server = HTTPServer(("127.0.0.1", 8000), SimpleHTTPRequestHandler)
4print("Server running on 127.0.0.1:8000")
5server.serve_forever()

But opening http://127.0.0.1:8000 in your local browser will not reach that server, because your browser is not on the Colab VM.

A Practical Flask Example

For app-style experiments, Flask is a simple choice. In a notebook, run the server in a background thread so the cell does not block the entire notebook.

Install the packages first:

%pip install flask pyngrok

Then start the server:

1from flask import Flask
2from threading import Thread
3
4app = Flask(__name__)
5
6
7@app.route("/")
8def index():
9    return "Hello from Colab"
10
11
12def run_app():
13    app.run(host="0.0.0.0", port=5000)
14
15
16thread = Thread(target=run_app)
17thread.daemon = True
18thread.start()

Using 0.0.0.0 allows the server to listen on the runtime's network interface. It still is not public yet, but it is now available for a tunnel to forward.

Exposing the Server With pyngrok

The usual way to reach the app from your browser is to create a public tunnel. pyngrok gives you a simple Python interface to ngrok.

1from pyngrok import ngrok
2
3public_url = ngrok.connect(5000)
4print(public_url)

Once that prints a URL, open it in your browser and the request will be forwarded to the Flask app running inside Colab.

If your ngrok account requires an auth token, configure it first:

from pyngrok import ngrok

ngrok.set_auth_token("YOUR_NGROK_TOKEN")

This is usually the most reliable way to test a notebook-hosted web app from outside the Colab runtime.

A Minimal End-to-End Example

Putting the pieces together, the full notebook flow looks like this:

1%pip install flask pyngrok
2
3from flask import Flask
4from threading import Thread
5from pyngrok import ngrok
6
7app = Flask(__name__)
8
9
10@app.route("/")
11def index():
12    return "Server is running"
13
14
15def run():
16    app.run(host="0.0.0.0", port=5000)
17
18
19Thread(target=run, daemon=True).start()
20public_url = ngrok.connect(5000)
21
22print(f"Open this URL: {public_url}")

That gives you a temporary public entry point to the notebook server. It is good for demos, small experiments, and validating that request handling works.

When This Approach Makes Sense

Running a server in Colab is best for short-lived experiments:

• testing a lightweight Flask endpoint,
• previewing a notebook-driven demo,
• validating a model inference endpoint quickly.

It is not a substitute for a real deployment. Colab runtimes can reset, go idle, or disconnect, which means the server and the public URL disappear with the session.

For anything persistent, deploy the app to an actual hosting environment instead of treating Colab as a web server platform.

Common Pitfalls

• Expecting localhost in the notebook to be reachable directly from your own browser.
• Running app.run() in the foreground and blocking the notebook session.
• Forgetting to expose the port through a tunnel or proxy.
• Assuming the tunnel URL will remain stable after the runtime restarts.
• Putting secrets into notebook cells when configuring public tunnels.

Summary

• A server can run inside Google Colab, but localhost refers to the remote runtime, not your computer.
• Use a background thread so the notebook stays interactive.
• Expose the port with a tool such as pyngrok if you need browser access.
• Treat the setup as temporary and experimental, not production hosting.
• Keep security in mind, because tunneling makes the notebook service reachable from outside the runtime.