Full-stack Python

The pain that produced this chapter

The Reddit and Stack Exchange threads we mined surfaced one pain point that the previous chapters' techniques can't fix directly: "I'm not a dev." The exact phrasing varied — "I'm a CLI engineer, not a Python developer," "we don't have anyone who can ship a web app," "our automation team is two people and they're both backed up" — but the underlying frustration is the same. There is a gap between "network engineer who has learned some Python" and "network engineer who can put a tool in front of teammates that they can click on, every day, without your help."

That gap is bigger than it feels. CLI scripts are fine for you. They are not fine for the NOC operators, the customer-success team, the on-call engineers from adjacent teams who occasionally need to query state but won't ssh and grep. Those people need a URL. They need a form. They need it to be obvious.

The question this chapter answers: once I have learned all the AI techniques in chapters 01-07, how do I package one into a web tool my non-engineer teammates can use this week, without becoming a full-stack web developer?

The answer in 2026 is Streamlit — a Python library that lets a network engineer turn a script into a web app in 50 lines, and lets that app run anywhere Python runs, including free Google Colab through a tunnel. We will not become full-stack developers. We will use the one tool that lets us cheat past that whole stack and ship.

The architecture that survives

A web app for network operations doesn't need a microservices diagram. It needs three things and nothing else.

A UI layer. What the user clicks. A form, a query box, a button, a result panel. Streamlit gives you these as one-line function calls — st.text_input, st.button, st.dataframe. No HTML, no CSS, no JavaScript.

A logic layer. What happens when they click. Functions that call your MCP tools (chapter 06), your RAG retriever (chapter 04), your fine-tuned classifier (chapter 03), or just NetBox / Prometheus directly. Plain Python. The same code you'd write for a CLI script.

A data layer. Where state lives. For most netops tools, state lives in other systems — NetBox, Grafana, the device itself. Your app doesn't need its own database for most cases. Cache aggressively (Streamlit's @st.cache_data does this for you), don't persist what isn't yours.

Three layers, one Python file, hosted anywhere. This is the unsexy architecture that wins. Microservices are a real pattern for a real problem you do not yet have. A single Streamlit app handling 50 NOC operators is fine. When you need more, redesign — by then you'll know what you actually need.

Why Streamlit and not

There are dozens of Python web frameworks. Flask, FastAPI, Django, Gradio, Dash, Reflex, NiceGUI, Panel. Each has its devotees. For the specific use case of "network engineer wants to put their script behind a UI for teammates," Streamlit wins on the metric that matters: time from idea to deployed tool. Five minutes for a working prototype is realistic. Five hours for a polished production tool is realistic.

The tradeoffs you accept:

• Streamlit reruns your whole script on every interaction. This sounds terrible. It mostly isn't, because Streamlit caches the expensive parts. You learn the cache decorators in 10 minutes.
• State is awkward. If you want a session that remembers what the user typed three pages ago, Streamlit's session_state works but feels grafted on. For a network tool where each query is fresh, this is fine.
• The UI is opinionated. Everything looks the same. You can't ship a pixel-perfect design. For internal tools, this is a feature; teammates aren't comparing your app to Stripe's marketing page.

When not to use Streamlit: when you need to handle 10,000 concurrent users (FastAPI), when you need real-time bidirectional updates (WebSockets, not Streamlit), when the UI is the product (a real frontend framework). For 99% of internal network-ops tools, none of these apply.

Gradio is the other defensible choice. It is similar in spirit, sometimes shorter for ML-heavy demos. The Hugging Face ecosystem favors it. If you find yourself there often, use Gradio instead — the patterns in this chapter transfer almost verbatim.

What "Streamlit-in-Colab" buys you

Streamlit normally runs on localhost. To share with a teammate, you'd need to deploy somewhere — Streamlit Cloud, your own server, Hugging Face Spaces, a small VM. All of these are reasonable. None of them are free with zero setup.

Streamlit-in-Colab is the hack that lets you iterate without any of that. You start Streamlit inside a Colab notebook. A tunnel service (ngrok, localtunnel, or cloudflared) exposes the Colab session to the public internet. You get a URL like https://random-words.ngrok.io that your teammate can open in their browser. The session is live as long as your Colab is alive.

This is not a production deployment. The URL changes every time you restart. The session times out. Free Colab cuts you off after a few hours. But it is the cheapest possible way to validate that your idea is useful before investing in real infrastructure. Build the tool, share the URL with one teammate, see if they actually use it. If yes, deploy properly. If no, you've saved a week of deployment work.

The notebook for this chapter walks through the tunnel setup. You'll have a sharable URL in under 5 minutes.

The composition: what we're actually building

The notebook builds a NetBox dashboard powered by chapter 04's RAG approach. The hypothetical scenario: your team has 700 devices in a mock NetBox. The NOC team frequently asks "do we have any spare Juniper EX4300s? Where? In what state?" — the question takes a senior engineer five minutes to answer by clicking through the NetBox UI; the senior engineer is busy.

The dashboard:

1. A query box. "Show me unused Juniper EX-series devices in the EU region."
2. A semantic search step. The query embeds, retrieves matching device records from the (mock) NetBox.
3. A filter step. Drop-downs for region, vendor, status — refining the natural-language result.
4. A result table. Hostnames, locations, status, last-seen timestamp.
5. A detail panel. Click a row, see the full device record.
6. An optional LLM-summary step. If an API key is set, Claude summarizes the result: "You have 12 EX4300s in the EU region, of which 4 are marked as spare in racks DC2-A03 and DC3-B17."

That's a tool the NOC team would actually use. Three new pieces of technology this chapter adds — Streamlit primitives, the tunnel setup, caching with @st.cache_data — plus reuse of everything from chapters 02 (embeddings), 04 (RAG), and 06 (MCP tools shape).

The line count: roughly 150 lines of Python for the whole dashboard. Most of those lines are UI scaffolding, not logic. The logic — the embedding, the retrieval, the optional LLM call — is 30 lines, all of which you've seen before. The chapter's value is showing you the thin layer that wraps the AI work in a clickable tool.

The pattern that scales to your real environment

The notebook works against synthetic data. The pattern transfers directly to your real environment:

script.py:
    1. Define the data source — real NetBox API call instead of synthetic dict.
    2. Define the embedding step — same model from chapter 02, cached.
    3. Define the retrieval function — same cosine similarity as chapter 04.
    4. Define the UI — same Streamlit primitives, no changes.
    5. Define the LLM summary — same Anthropic call as chapter 04.

Replace step 1 with your real NetBox client. Replace step 3 with FAISS if you have >10k devices. Replace step 5 with your team's preferred model. Everything else stays.

This is the pattern most production network-ops dashboards in 2026 are built on. Not because it's the best possible pattern — a hand-crafted React frontend over a FastAPI backend would be more polished — but because it's the pattern a network engineer can build alone, in a week, and maintain alone, for a year. Polished frontends are someone else's problem. Yours is to ship the thing that solves the actual question your team keeps asking.

Deployment: what to do when the prototype works

The notebook produces a prototype. To put it in front of real teammates beyond the experimental URL, you have four options in increasing order of effort:

Streamlit Cloud (10 minutes). Free for one app. Push the .py file to a public GitHub repo, connect the repo to Streamlit Cloud, get a stable URL. Works if your team is OK with the app being public. Not OK if the app touches sensitive data.

Hugging Face Spaces (15 minutes). Similar to Streamlit Cloud but allows private spaces on paid tier. Better choice if you want the app behind auth.

Self-hosted on a small VM (1 hour). Spin up a Linux box, pip install streamlit, nohup streamlit run app.py, point your team's reverse proxy at it. Works if you have an internal proxy that can do auth (most companies do). This is the right answer for a tool that will outlive a quarter.

Containerized via Docker (2-4 hours, scales to teammates). Wrap in a Dockerfile, deploy to your team's existing platform (Kubernetes, Nomad, ECS, whatever you already run). Right answer for a tool that's becoming team-critical.

Most network-ops dashboards never need to go past option 3. Option 4 is what you do when the tool has been valuable for six months and you want it to survive your laptop being lost.

The risk you should know about

A Streamlit app exposing a tool that touches your real network is also a potential attack surface. Anyone with the URL — and an authentication bypass — gets your tool. Some considerations:

• Authentication. Streamlit Community Cloud and Hugging Face support OAuth. Self-hosted, put it behind your team's existing SSO via the reverse proxy. Do not expose a netops tool on the public internet without auth. Ever.
• Authorization. Not every user should see everything. Filter by user identity if your data has access controls. Streamlit can read auth headers passed by an upstream proxy.
• Rate limiting. Without it, one impatient user can DoS your backend. Put rate limits in the proxy if Streamlit itself doesn't support them.
• Audit logging. Log every query with user identity and timestamp. After an incident, you want to know who asked what when.
• Read-only by default. Resist the urge to add "fix it" buttons to the UI. Diagnostic apps stay diagnostic. If you need write operations, route them through change management, not through a button click.

These are not different rules from chapter 05's agent safety patterns. They are the same rules, restated for the web context.

What the notebook will give you

The notebook builds the NetBox-style device dashboard end-to-end.

Setup. Install streamlit, sentence-transformers, pyngrok or localtunnel. ~30 seconds in Colab.

Mock NetBox data. 100 device records inline — vendor (Cisco/Juniper/Arista), site, region, status (active/spare/decommissioned), last-seen timestamp.

Embedding step. Embed each device's description string once, cache.

Streamlit UI. Query box, filters (region, vendor, status), result table, detail panel.

Optional LLM summary. If ANTHROPIC_API_KEY is set, the dashboard calls Claude to summarize the result set into prose. If not set, this section gracefully says "set the key to enable summaries."

Tunnel. A single cell starts the tunnel and prints the public URL. Open in any browser.

Reflection. What you just built. What it would take to make this real.

By the end, you have a clickable URL you could send to a teammate. They can open it on their phone. They can search for "spare Juniper devices in EU" and see a result table. That's the win. That's the gap between "I'm a CLI engineer" and "I shipped a tool my team uses."

What comes next

Chapter 00 (course design) is the only thing left. It's the meta archive — the conversations where this course's structure was iterated. You may or may not need to read it. The fact that you reached chapter 08 means the structure worked for you, which is the only meaningful endorsement of curriculum design.

After this course, the realistic next steps for the network engineer who has worked through it:

1. Run Claude Code daily in your real netops repo. Iterate on CLAUDE.md for a month.
2. Build one production MCP server wrapping one of your existing tools (NetBox, Prometheus, your CMDB).
3. Ship one Streamlit dashboard that your team actually uses. Iterate based on usage.
4. Write the postmortem for the first AI-assisted incident response your team runs. Share with the broader team.

Those four steps put you ahead of ~90% of the network-engineering field as of 2026. The course gave you the techniques. The career value comes from the application.

For now: run the notebook. Get the URL. Open it on your phone. Internalize that you just built a network operations tool, alone, in an afternoon, using techniques that didn't exist five years ago and didn't exist for network engineers two years ago. That capability is the durable thing the course transfers.

Field exercise: replace the notebook's mock NetBox data with a real NetBox API call against your team's instance (read-only token). Run the dashboard. Search for something your team actually asks about weekly. Share the URL with one teammate. Notice if they use it twice.

Wrong way to use this chapter: treat Streamlit as a toy compared to "real" frontends. Right way: Streamlit is the right tool for the next 100 internal tools your team will build, regardless of how much fancier the public-facing world's tooling becomes. Build the boring thing. Ship.

Pain anchored: T3 (skills gap — "I'm a CLI engineer, not a dev"). Streamlit closes the gap to "I shipped a tool my team uses" in 50 lines of Python. Maps to: chapter 08-full-stack-python. Pairs with the polished python-genai-bootcamp-network-engineers-annotated.md already in this folder — the longer companion chapter that takes you from print('hello world') to deploying a small AI-powered app.