fidzu : django

News

Incident Report: LiteLLM/Telnyx supply-chain attacks, with guidance

A recent supply chain attack on popular PyPI packages exposed how quickly malware can spread through unpinned dependencies-and why practices like dependency locking and cooldowns are now essential for Python developers.

pypi.org

The PyCon US 2026 schedule is live 🌴🐍 plus security updates, community programs & more

PyCon US 2026 heads to Long Beach with its schedule now live, alongside major Python ecosystem updates spanning security improvements, new community programs, and ongoing PSF initiatives.

mailchi.mp

Django Software Foundation

DSF Board Meeting Minutes, March 12, 2026

DSF approved trademark renewal plans, advanced a long-awaited Code of Conduct update, and continued shaping community governance and outreach efforts.

django.github.io

Wagtail CMS News

How to Generate SEO Descriptions for Your Entire Wagtail Site at Once ⚡

Use Wagtail AI's built-in LLM pipeline to bulk-generate SEO meta descriptions across your entire site in minutes with a simple Django management command.

timonweb.com

How to Show a Waitlist Until Your Wagtail Site Is Ready

A clever Django and Wagtail pattern for launching with a waitlist while selectively granting preview access using secure cookies and a simple passphrase gate.

djangotricks.com

Build Dynamic Campaign Landing Pages in Wagtail

Use a single Wagtail page with dynamic routing, built-in A/B testing, and campaign slug tracking to replace dozens of duplicate landing pages with one flexible, data-driven solution.

wagtail.org

Updates to Django

Today, "Updates to Django" is presented by Hwayoung from Djangonaut Space! 🚀

Last week we had 11 pull requests merged into Django by 9 different contributors - including 4 first-time contributors! Congratulations to Georgios Verigakis, David Ansa, Vinay Datta and Sebastian Skonieczny for having their first commits merged into Django - welcome on board!

Documentation was added to clarify how database routers handle related-object access. It explains that Django uses instance.state.db by default for related lookups and provides guidance on using the instance hint in dbfor_read() to maintain routing consistency in multi-database configurations. (#29762)

Django Newsletter

Sponsored Link 1

The deployment service for developers and teams.

appliku.com

Articles

The Story of Python's Lazy Imports: Why It Took Three Years and Two Attempts

From PEP 690's rejection to PEP 810's unanimous acceptance - how Python finally got explicit lazy imports after three years of real-world production evidence and a fundamental design inversion

techlife.blog

Tombi, pre-commit, prek and uv.lock

A subtle tooling mismatch reveals how a recent update made uv.lock suddenly count as TOML, causing pre-commit to reformat it unexpectedly across environments.

vanrees.org

Claude Pitfalls: Database Indexes

A smart migration tweak reveals how AI code reviews can both catch real production risks and miss critical context, proving that combining multiple agents leads to better Django performance decisions.

lincolnloop.com

Loopwerk: Building modern Django apps with Alpine AJAX, revisited

After ditching template partials and full-page AJAX hacks, this deep dive shows how splitting Django views and using template includes leads to simpler code, better performance, and a more maintainable Alpine-powered stack.

loopwerk.io

Djangonaut diaries, week 4: Eliminating a Redundant Index in Django's ORM

A deep dive into a subtle Django ORM inefficiency shows how removing a redundant many-to-many index improves database performance and highlights the real-world journey from bug report to merged PR.

dev.to

SHA Pinning Is Not Enough

SHA pinning isn't a silver bullet-this deep dive shows how attackers can still slip malicious code into GitHub Actions by pointing to trusted-looking but rogue commits.

rosesecurity.dev

A primer on Django project structure ¤ 101% objective - always!

AI is rapidly rewriting the world's software, but without scalable verification like formal proofs, we risk deploying fast, flawed, and fundamentally untrusted code at global scale.

overtag.dk

When AI Writes the World's Software, Who Verifies It?

AI is rapidly rewriting the world's software, but without scalable verification like formal proofs, we risk shipping faster code that no one truly understands or can trust.

leodemoura.github.io

So OpenAI is acquiring Astral

OpenAI's acquisition of Astral raises real concerns about the future of uv, but for now, it's still one of the fastest and most practical Python tooling choices worth sticking with.

mostlypython.com

Events

DjangoCon Europe is soon!

April 15-19 in Athens, Greece. Get a ticket if you're able to attend. Keynote speakers, workshops, and all talks available online.

djangocon.eu

PyCon US May 13-19 in Long Beach, CA

Tickets are available for this annual event now in beautiful Long Beach, California.

pycon.org

DjangoCon US Early Bird Tickets Now Available

Don't hesitate! If you can, join for five days of talks, workshops, and sprints once again in Chicago this August 24-28.

djangocon.us

Videos

Boost Your GitHub DX

A lively chat with Adam Johnson on leveling up your GitHub workflow, from practical DX tips to cutting-edge Python tooling like ICU bindings.

djangotv.com

Django Job Board

Two fresh Python roles this week: one focused on open data impact, the other on client-facing architecture with a leading developer tools company.

Python Developer at Open Data Services 🆕

Solutions Architect - Python (Client-facing) at JetBrains

Django Newsletter

Django Forum

Django sprint at Pycon DE? - Events

A call is out for someone to lead a Django sprint at PyCon DE 2026, with contributors already eager to join and help onboard newcomers.

djangoproject.com

Projects

freelawproject/django-s3-express-cache

A high-speed, low latency cache that uses S3 Express to store many objects cheaply and efficiently

github.com

kjnez/django-rclone

Django database and media backup management commands, powered by rclone.

github.com

This RSS feed is published on https://django-news.com/. You can also subscribe via email.

03 Apr 2026 3:00pm GMT

My main machine is a beast. Ryzen 9 9950X3D, 64 GB of RAM, RX 9060 XT, three monitors, the works. It barely ever shuts off. So at some point I started thinking: why isn't this thing working for me when I'm not sitting in front of it?

The answer is now: it does. I'm running OpenCode as a persistent server on this machine, accessible from anywhere through my WireGuard VPN. I can spin up coding sessions from my MacBook Air, my phone, wherever. And the best part? I have scheduled jobs that run overnight: adding tests, updating documentation, enforcing code conventions. I wake up to PRs waiting for my review.

Here's the full setup.

The architecture

 ┌─────────────────────────────────────────────────────────┐
│ roger-beast │
│ (Ryzen 9 9950X3D / 64GB) │
│ │
│ ┌──────────────────┐ ┌──────────────────────┐ │
│ │ opencode serve │◀─────│ systemd user service │ │
│ │ :4096 (web UI) │ │ (auto-start/restart) │ │
│ └────────┬─────────┘ └──────────────────────┘ │
│ │ │
│ │ ┌──────────────────────┐ │
│ │ │ opencode-scheduler │ │
│ │ │ (systemd timers) │ │
│ │ │ ┌──────────────────┐ │ │
│ │ │ │ 2am: add tests │ │ │
│ │ │ │ 3am: update docs │ │ │
│ │ │ │ 4am: conventions │ │ │
│ │ │ └──────────────────┘ │ │
│ │ └──────────────────────┘ │
│ │ │
└───────────┼─────────────────────────────────────────────┘
│
┌───────┴──────────────┐
│ Nginx Proxy │
│ Manager │
│(opencode.example.com)│
└───────┬──────────────┘
│
┌─────────┴──────────┐
│ WireGuard VPN │
│ / Local Network │
└─────────┬──────────┘
│
┌────────┴────────┐
│ │
┌──┴───┐ ┌─────┴──────┐
│ 💻 │ │ 📱 │
│ MBA │ │ Phone │
└──────┘ └────────────┘

The idea is simple: OpenCode runs as a systemd user service, Nginx Proxy Manager gives it a nice domain, and WireGuard makes sure only my devices can reach it. From any browser on any device, I just go to opencode.example.com and I'm in.

Phase 1: OpenCode server with systemd

OpenCode has a serve command that starts a web UI you can access from a browser. The trick is making it persistent so it survives reboots and restarts itself if it crashes.

First, create a systemd user service. This means it runs as your user, not as root, which is important because it needs access to your home directory, your API keys, your OpenCode config, everything.

Create the file at ~/.config/systemd/user/opencode.service:

[Unit]
Description=OpenCode headless server
After=network.target

[Service]
ExecStart=/home/roger/.opencode/bin/opencode serve --hostname 0.0.0.0 --port 4096
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target

A few things to note:

• --hostname 0.0.0.0 makes it listen on all interfaces, not just localhost. This is necessary so that Nginx Proxy Manager (or other devices on your network) can reach it.
• --port 4096 is arbitrary. Pick whatever you want, just make sure it doesn't conflict with anything else.
• Restart=on-failure with RestartSec=5 means if OpenCode crashes, systemd will bring it back up after 5 seconds. I've never had it crash, but it's nice to know it's there.
• WantedBy=default.target means it starts on login. Since this machine barely ever restarts, that's basically "always on."

Enable and start it:

systemctl --user daemon-reload
systemctl --user enable opencode.service
systemctl --user start opencode.service

Verify it's running:

systemctl --user status opencode.service

You should see it active and running. If you want the service to keep running even when you're not logged in (which you probably do, since the whole point is that it runs when you're away), you need to enable lingering:

sudo loginctl enable-linger roger

Replace roger with your username. This tells systemd to keep your user services running even after you log out. Without this, systemd kills your user services when your last session closes, which defeats the entire purpose.

At this point, you should be able to open http://localhost:4096 on the machine and see the OpenCode web UI.

Phase 2: Nginx Proxy Manager + WireGuard

I use Nginx Proxy Manager as my reverse proxy. It's a Docker-based GUI for managing Nginx configs, SSL certificates, and proxy hosts. If you prefer raw Nginx configs, you can absolutely do that instead, the concept is the same: point a domain at the OpenCode port.

In Nginx Proxy Manager, I created a new proxy host:

• Domain: opencode.example.com
• Scheme: http
• Forward Hostname/IP: 192.168.x.x (the local IP of my machine)
• Forward Port: 4096
• Websockets Support: enabled (OpenCode's web UI uses websockets)

For the access part, I don't need to worry too much about authentication because the domain is only accessible from two places:

1. My local network: If I'm at home, my devices are already on the same network as the machine.
2. My WireGuard VPN: If I'm remote, I connect to my WireGuard VPN first, which puts me on the same network. My WireGuard setup is the same one I described in my Claude Code from the beach post.

The DNS for opencode.example.com points to the internal IP of the machine running Nginx Proxy Manager. This means the domain simply doesn't resolve from the public internet. You'd have to be on my network (or VPN) for it to go anywhere.

Phase 3: Accessing from anywhere

This is the satisfying part. Once the server is running and the proxy is configured, the workflow from any device is:

1. Connect to WireGuard (if I'm not already home)
2. Open a browser
3. Go to opencode.example.com
4. Done. Full OpenCode web UI, all my agents, all my MCP servers, everything.

From my MacBook Air at a coffee shop, from my phone on the couch, doesn't matter. The web UI is the same everywhere. I can start a task on my MacBook, close the laptop, pick it up on my phone later, and everything is still there because the server is running on the beast at home.

This pairs really nicely with my Claude Code from the beach setup, but it's way friendlier. That setup uses mosh + tmux + SSH bridges through Termux to get a terminal on a remote machine. It works great for Claude Code (which is a TUI), but it's a lot of moving parts: you need Termux, SSH keys on your phone, a jump box, mosh installed everywhere. If something breaks in the chain, you're debugging SSH configs from a phone keyboard. I wrote a whole blog post about that setup and I'm proud of it, but let's be real: the fact that I needed an entire blog post to explain how to use Claude Code from my phone is kind of the problem.

With OpenCode, I just open a browser. That's it. Any browser, on any device. No Termux, no SSH keys, no jump box, no terminal emulator. My phone's regular browser works perfectly. My MacBook's browser works perfectly. If I ever get a tablet, that'll work too. The barrier to entry went from "install Termux, configure SSH, set up mosh, create fish aliases" to "open Firefox."

Hey Anthropic, if you're reading this: please give Claude Code a web UI. I love your tool, I pay $100/month for it, but the fact that OpenCode can do this out of the box and Claude Code can't is… not great. I shouldn't need a 600-word phase-by-phase guide to use my coding agent from my phone. Just saying. 🙃

I still use the Claude Code + mosh + tmux setup for Claude Code specifically (since it's terminal-only), but for OpenCode work, the web UI is a massive quality-of-life upgrade for mobile coding.

Phase 4: The overnight crew

This is my favorite part. The server runs 24/7, so why not put it to work while I sleep?

I use the opencode-scheduler plugin, which lets you schedule recurring jobs using your OS's native scheduler (systemd timers on Linux, launchd on Mac). It's an OpenCode plugin, so you set it up directly from the OpenCode UI.

First, add the plugin to your opencode.json:

{
 "plugin": ["opencode-scheduler"]
}

Then, from the OpenCode UI, you just tell it what you want in natural language:

Schedule a job that runs every weekday at 2am and runs the test-gap-pr-cronjob skill

The plugin takes care of creating the systemd timer and service under ~/.config/systemd/user/. You can verify it's installed with:

systemctl --user list-timers | grep opencode

What my overnight jobs do

I have three scheduled jobs that run between 1 AM and 6 AM while I'm sleeping. Each one uses a custom OpenCode skill (similar to the planning/execution/review agents I described on my AI Toolbox page):

• 2 AM - Test gap finder: Scans the codebase for untested or under-tested code, writes the missing tests, and opens a PR.
• 3 AM - Documentation updater: Checks for outdated or missing docstrings and README sections, updates them, and opens a PR.
• 4 AM - Convention enforcer: Reviews code for style and convention violations that linters don't catch (naming patterns, architectural decisions, etc.), fixes them, and opens a PR.

Each job uses a custom skill that knows the project's conventions, testing patterns, and documentation style. The skills are the same kind of custom agents I build for my regular OpenCode workflow, just triggered on a schedule instead of manually.

The morning routine

When I log in in the morning, I usually have 1-3 PRs waiting for me. Most of them are good to go with minor tweaks. Some need more work. Either way, the tedious stuff (writing tests for edge cases, updating docstrings, fixing inconsistent naming) is already done, and I just need to review it.

It's like having a junior developer who works the night shift. They're not perfect, but they're reliable, they don't complain, and they're surprisingly good at the boring stuff.

You can check the logs for any job at any time:

# From the OpenCode UI
Show logs for test-gap-pr-cronjob

# Or directly on disk
cat ~/.config/opencode/logs/test-gap-pr-cronjob.log

The specs

For anyone curious about the machine running all of this:

OS: Manjaro Linux 26.0.4
Host: B850M Pro-A WiFi
Kernel: 6.12.77-1-MANJARO
CPU: AMD Ryzen 9 9950X3D (32) @ 5.752GHz
GPU: AMD ATI Radeon RX 9060 XT GAMING OC 16G
Memory: 64 GB DDR5
Network: WiFi 6
Uptime: usually measured in days, not hours

The machine is wildly overpowered for this. OpenCode's server uses barely any resources when idle, and even during active sessions or scheduled jobs, it doesn't break a sweat. If you have a less powerful machine that stays on, this setup will work fine for you too.

Conclusion

The whole setup took maybe 30 minutes. A systemd service, a proxy host, and a scheduler plugin. That's it.

What I love about this is that it extends my AI Toolbox in a way I didn't expect. I went from "I use OpenCode when I'm at my desk" to "OpenCode is always running and I can use it from anywhere, and it also does work for me while I sleep." The scheduled jobs alone have saved me hours of tedious work every week.

If you have a machine that stays on (even a modest home server or an old laptop), you can do this. You don't need a Ryzen 9 or 64 GB of RAM. You need a machine that doesn't turn off, a way to reach it remotely, and the willingness to let AI handle the boring stuff while you're asleep.

All my configs are public in my dotfiles: git.rogs.me/rogs/dotfiles

If you have questions, hit me up. And if you set this up and wake up to PRs you didn't write, let me know. That first morning is a great feeling.

See you in the next one!

02 Apr 2026 5:00am GMT

02 Apr 2026 4:00am GMT