Topics covered in this episode:
Watch on YouTubeAbout the show
Sponsored by Logfire from Pydantic: pythonbytes.fm/logfire
Connect with the hosts
Michael #1: Web UIs for your reverse proxy
Traefik, nginx, and Caddy all sit in front of a lot of self-hosted infrastructure, and all three are configured by hand-editing files. Three active projects put a control plane on top: Traefik Manager (Python + Flask), Nginx UI (Go + Vue), and caddy/ui (React + Node). All three are additive rather than replacements - none of them take ownership of your config away from you - which is the part that matters when the thing has write access to production routing.
- Traefik Manager is the Python one: Flask 3.1 and Gunicorn for the control plane, a lightweight Go agent for remote instances, currently v1.10.0 with an Android companion app.
- Nginx UI is a single Go binary at 11.3k stars, with a block-style config editor, an Ace editor doing LLM completion on nginx syntax, and an MCP server so agents can drive it.
- caddy/ui runs as two containers next to your existing Caddy, reads and writes your Caddyfile directly, and uses Caddy's
/adapt API to validate before reload - no Docker socket required. - Each one edits the config the underlying server already reads, so your files stay the source of truth and you can drop the UI without unwinding anything.
- Undo is a first-class feature across all three - timestamped backups with optional Git history, config version compare and restore, Caddyfile snapshots with one-click rollback.
- Observability is where they diverge: Traefik Manager does CrowdSec and a visual route map, Nginx UI does server metrics, caddy/ui streams access logs over SSE and pulls p50/p95/p99 off Caddy's Prometheus endpoint.
- Maturity spread is wide - Nginx UI has 11.3k stars, caddy/ui has 4 and was built in a single Claude session - and caddy/ui ships with auth off by default, so set
CADDY_UI_USER and JWT_SECRET before it goes anywhere near a public interface.
Calvin #2: Wagtail 8.0 is hot off the presses
Link: https://github.com/wagtail/wagtail/releases/tag/v8.0
- Custom base page models are now supported, so projects aren't locked into subclassing Wagtail's Page as shipped (Matt Westcott).
- New v3 REST API handles both read and write CMS operations, a first for Wagtail's API.
- A global registry for permission policies, plus full customizability for the remaining page views via PageViewSet.
- AVIF and WebP images are no longer auto-converted to PNG by default, a real behavior change to watch on upgrade.
- Five security fixes: page admin API restrictions, document identification by SHA1 hash, descendant collections in the Documents/Images API, snippet copy permissions, and the page translation endpoint.
- Formalized Django 6.1 support, and CI now runs on uv with a lockfile.
Sponsor: Logfire from Pydantic
Your AI agent failed at 2am. Was it the model? A tool call? The database? Most observability tools can't tell you, because they only see part of your stack.
Pydantic Logfire sees all of it. One trace across your agents, LLMs, APIs, and database. Down to the infrastructure: services, Kubernetes, and hosts.
It's built on OpenTelemetry, with SDKs for Python, TypeScript, and Rust, and it works with any OTel-compatible language.
Every prompt, token count, and cost, right next to your vector searches and API calls.
You query everything with Postgres-compatible SQL. And so can your coding agent, through the Logfire MCP server.
Stop guessing. Read the trace.
Pydantic Logfire. AI, it's still just engineering.
Visit pythonbytes.fm/logfire today and sign up today. Get 10M records free every month, no card required. You can even click “Onboard with your coding agent” to copy a prompt to have claude or codex integrate Logfire into your app.
Thanks to Pydantic for supporting the show.
Calvin #3: RISC-V is now officially supported by CPython
Link: https://blog.python.org/2026/08/riscv-now-officially-supported/
- CPython added RISC-V as a tier 3 platform under PEP 11, specifically the 64-bit Linux target riscv64-unknown-linux-gnu.
- RISC-V is an open ISA anyone can implement, unlike x86 and ARM, and its market is projected to quadruple by 2032.
- The RISE Project donated real RISC-V machines for buildbots; the author's work was funded by a Sovereign Tech Agency fellowship.
- What changes: the port is now a maintained compatibility target, so CPython changes are less likely to quietly break it. What doesn't: no python.org installers, no binary wheel parity for native extensions.
- Next up: RISC-V runners in CPython CI for pre-merge feedback, then a push toward tier 2, plus architecture-specific optimizations.
- The ask is testing. If you have RISC-V hardware, build CPython, run your test suite, file what breaks.
Tier 3 is the weakest support tier. PEP 11 tier 3 requires a core developer contact and a buildbot, but failures on tier 3 platforms explicitly do not block a release. Saying "ongoing CI/testing expectations" oversells it. The honest bit is "someone is now on the hook for it, and breakage gets noticed," not "it's guaranteed working."
Worth the caveat that this is Linux SBCs, not microcontrollers. A VisionFive 2 counts, an ESP32-C6 or Pico 2 does not. Those are 32-bit non-Linux parts where MicroPython is still the answer.
Michael #4: Django’s annual releases make every version an LTS
Starting with Django 2028, Django will move to one January feature release per year, adopt calendar-based version numbers, and support every release for three years. The old distinction between standard and LTS releases disappears, giving teams a predictable annual upgrade path that aligns more closely with Python’s own release and support cadence.
- Every Django release becomes the safe, long-supported choice, so teams no longer need to wait for a specially designated LTS version or absorb two years of changes at once.
- Each release gets one year of mainstream bug fixes followed by two years of security and data-loss fixes.
- New releases support the three latest Python versions and add the next Python release during their first year.
- Calendar versioning begins with Django 2028, followed by Django 2029 and so on.
- Three Django versions will be supported at any time, giving third-party packages a clearer rolling target.
- Nothing changes before 2028, and existing commitments for Django 5.2 LTS and 6.2 LTS remain in place.
Extras
Calvin:
- The Python docs now document the time complexity of built-in types
https://docs.python.org/3.16/library/time-complexity.html - Thinking in Python - Bruce Eckel's free book
https://thinkinginpython.com/
Michael: - prune_uv_pythons.py - Prune uv-managed Python installs, keeping only the newest patch per minor version
- Started using Ollama cloud models for my Hermes assistant. Thanks to Jeff Triplett I learned they are not just local models.
Joke: The Tao of Programming - Book Seven: Corporate Wisdom
