Good day, charmers, Juju users, and enthusiasts! The Juju team is delighted to bring you The Juju Insider #2 with all the latest from our community and development efforts. 
Here’s today’s agenda📋:
- Canonical Engineering Sprint in Frankfurt: Juju 4 roadmap and “language of concepts”
- Juju 4 progress: dqlite-based implementation and beta/Q4 2025 targets
- Juju 3.6 LTS: extended support, bug-fix highlights, and CI/stability improvements
- Jubilant 1.1.0 release: streamlined charm integration testing
- Terraform provider: v1.0 planning and v0.20.0 release insights
- GitHub issues migration: Launchpad → GitHub as the sole bug tracker
Canonical Engineering Sprint - Frankfurt May’2025
Every six months, we set our compasses toward a new destination, this time, the vibrant city of Frankfurt, to map out Juju’s journey for the next half-year. Between kick-off design and architecture deep dives, we never let the fun escape us: dark-room mini golf under glowing putters, special-edition Juju T-shirts, and those priceless face-to-face moments that spark creativity.
We are all laser-focused on the release of Juju 4.0. Juju 4 – the dqlite-based engine that will supercharge reliability and scale. We’re still targeting an early Q4 2025 official launch, with a functionally limited beta available in your development environments a few months beforehand.
To make sure we hit that mark without compromise, we continue to adopt a “language of concepts” for all design discussions. Rather than diving straight into code-level minutiae, teams now align around high-level abstractions: defining clear concepts, boundaries, and responsibilities before opening an editor. This shift means fewer rehashes of edge cases and more time validating the big-picture architecture, ultimately boosting both quality and velocity.
Want to peek behind the curtain? Follow @manadart’s articles: “Juju 4.0 Architecture” and “Juju Relation Network Data”, for rich, conceptual insights straight from the Frankfurt whiteboards.
We also charted the course for JAAS, exploring new features and enhancements. On the Terraform front, we solidified our provider posture and outlined plans for a 1.0 release that will give you even more power to manage Juju with HCL.
Team Updates
On the team front, we’ve fine-tuned our collaboration model to keep Juju moving at warp speed. By breaking into tight-knit squads, each just two or three engineers, we’ve slashed design-meeting overhead and supercharged our feedback loops. The results speak for themselves: PRs are landing faster, coordination feels near-seamless, and energy levels are through the roof. These process tweaks aren’t just boosting productivity; they’re lifting morale as we sprint toward the Juju 4.0 launch.
Please join us in giving a warm Juju welcome to Adis Azhar, who just hopped aboard our APAC Juju team this month! We’re also actively hiring across multiple Juju squads. If you’re passionate about open-source, distributed systems, or simply love collaborating on cutting-edge tooling, we’d love for you to give it a try.
Juju 3.6 Updates
Juju 3.6 remains our flagship LTS release—and we love it so much that we’ve officially extended its bug-fixing window all the way through May 2026! That means you can continue to rely on 3.6 for stability and receive monthly patch releases packed with incremental improvements, security hardenings, and refinements. Whether you’re running production workloads or experimenting in staging environments, rest assured that Juju 3.6 will stay rock-solid as we march toward Juju 4.0.
During the last couple of 3.6 releases, we’ve hardened the secrets backend to better accommodate real-world usage patterns. In particular, Juju now handles “NotFound” errors gracefully when deleting user secrets. Rather than failing the entire operation, the controller simply acknowledges that the secret does not exist and proceeds without raising spurious exceptions.
The enable-ha sequence (on Azure) no longer suffers from race conditions; controller units now initialize in the correct order, so distributed state replication is established predictably, avoiding orphaned instances.
Model-default values are coerced to their proper schema types before storage, preventing, for example, string-to-integer mismatches. Validation has been reintroduced to catch invalid defaults early.
Flaky SSH server and worker tests have been stabilized with explicit timeouts and stricter teardown logic, ensuring each test starts with a clean slate and reducing CI noise.
The controller upgrade guide now walks users through prerequisites first, followed by step-by-step instructions, with call-outs for common pitfalls such as client-version compatibility and backup verification. All contribution instructions have been consolidated into a single “Coding Guide.” This unified guide features plain-text snippets and enhanced anchor links, allowing you to jump straight to exactly what you need without extra scrolling.
More News
Jubilant!
As you’ve probably seen in Ben’s announcement, Jubilant 1.1.0 is now available! Jubilant continues to streamline charm integration testing by providing a synchronous, type-annotated Python wrapper around the Juju CLI.
For a while, Juju charms integration tests have relied on python-libjuju - a Python library that provides an asyncio-based WebSocket for driving Juju models (e.g., Model.deploy(), Application.add_unit(), etc.). While Python-libjuju offers full coverage of the Juju API, it often introduces complexity in tests and occasional reliability issues. Tests written with pytest-operator (which internally uses the lib) can be fragile.
Jubilant is a newer Python library that wraps the Juju CLI in a type-annotated, synchronous interface tailored specifically for charm integration testing. Instead of dealing with websockets or async/await, jubilant maps Juju CLI commands one-to-one into Python calls (e.g., juju.deploy(), juju.wait()), greatly simplifying test code. By switching tests from Python-libjuju to jubilant, teams eliminate common async pitfalls and reduce flakiness.
Terraform Provider v1.0
We are gearing up for the official release of the TF provider this year. The team has collected feedback and the potential goodies we’d want as part of this major release. Ьore details soon! In the meantime, check out the v0.20.0 release planning thread to see what’s coming next and help shape the final roadmap.
GitHub As The Only Bug Tracking System
The Juju project has officially transitioned its bug-tracking system from Canonical Launchpad to GitHub Issues. This change aligns Juju’s development workflow with its source code hosting, providing a unified platform where contributors can file, track, and resolve issues without context-switching. The Launchpad interface will remain read-only for archival purposes only. We encourage everyone, whether reporting a new bug, requesting a feature, or following ongoing work, to use the GitHub tracker.
All future development discussions, prioritization, and patch reviews will occur exclusively through GitHub Issues.
Stay Charmed
We hope these updates spark new ideas for your Juju projects and keep you excited for what’s ahead. Don’t forget to explore the links shared in this issue, whether you’re deep-diving into Juju 4 architecture, testing with Jubilant, or planning infrastructure with the Terraform provider, there’s plenty to dig into. As always, your feedback and contributions drive Juju forward. Join us on Discourse, file issues on GitHub, or drop into community channels to share your thoughts.
Please feel free to ask any questions in the comments section. Don’t forget that we are also open to code and documentation contributions on GitHub.
PS: Don’t forget to enjoy the fresh, new design of our Juju t-shirts!
