Juju 4.0.1

🗓️ 22 Jan 2026

🎯 Highlights

  • Migration/import reliability work continues: more of the end-to-end plumbing lands (activation, rollback safety, and import ordering fixes).

  • Controller destruction is safer and clearer: better behavior when the controller still hosts models.

  • Vault secrets are easier to integrate: mount-path support reduces “works only with my Vault layout” friction.

  • More helpful operational visibility: richer status/cluster visibility and more resilient debug tooling.

⚠️ Breaking changes

🚀 Features (key changes)

This is a patch release focused on reliability and usability improvements. There is no new major functionality. Key changes include:

  • Model import becomes “transactional” at the end: importing a model now activates it only at the final step, treating activation as the commit point across multiple import transactions. This reduces “half-imported model” states. feat: activate model on import step finale

  • Import/migration gains stronger rollback tooling: adds tooling to inspect database tables inside a transaction before rollback, making foreign-key failures debuggable (SQLite errors can be extremely vague otherwise). feat: add tooling to view tables within transaction before rollback

  • Controller destruction: hosted-model handling is explicit: Juju now prompts/handles controller destruction workflows more safely when hosted models exist (instead of treating “controller model only” and “hosted models present” the same way). feat: destroy controller hosted models

  • Secrets + Vault: mount-path support: Vault-backed secrets can be configured with an explicit Vault mount path, so Juju can fit into pre-existing Vault mount layouts cleanly. feat(secrets): add support for vault mount path

  • Operational visibility: cluster details in status: juju status can surface cluster-level details, improving “at a glance” understanding of controller health/topology. feat: output cluster details in status

Full ist list of changes: https://github.com/juju/juju/releases/tag/v4.0.1

🛠️ Fixes

🔐 Secrets and secret backends

Secrets had correctness gaps that operators hit quickly. Delete operations failed if the external secret was already gone. Rotate policy updates didn’t always stick. Label + refresh paths could return the wrong value.

Listing also needed to help humans. If output lacks backend name or revision context, operators can’t audit or debug. And when Kubernetes tunnelling and Vault mount paths interact, Juju must keep behavior consistent instead of “works here, fails there.”

🧭 Migration/import correctness

Import breaks hard when steps run in the wrong order. CMR models exposed this immediately: relations tried to load before remote applications existed, and the database rejected the write.

Legacy data also tripped migrations. Juju 4 drops fan networking, but Juju 3 can still export fan addresses. We need import to handle those leftovers instead of blocking migrations on old artifacts.

🧱 Controller, API, and lifecycle safety

Operators hit controller flows that should never feel fragile: login, kill-controller, destroy-controller. In 4.0.0, some of these failed in edge cases like empty credentials or live hosted models, and the errors didn’t always help. HA made this worse. Connections break; Juju should reconnect cleanly and keep going, not restart workers in a way that loses the address it needs to recover.

🔎 Status/history/logging

Juju leaked or held idle connections too long and could run out of file descriptors. It also logged only RPC-upgraded requests, which left gaps for other endpoints that operators care about.

Status history also needed to stay accurate. CAAS status entries missed timestamps, some “newest entry” behavior didn’t behave as expected, and application status history sometimes recorded under the wrong key—which breaks tools like status-log.

🌐 Networking, ports, firewalling, MAAS

Provider integrations can cause damage when they misbehave. On OpenStack, Juju risked deleting the wrong ports because it filtered too broadly. On MAAS, Juju treated volumes as MAAS-provisioned even when they weren’t, and tag validation didn’t always run depending on input shape.

Kubernetes firewaller logic also had sharp edges. It hid “not found” errors and didn’t shut down cleanly when apps disappeared, which led to unstable worker behavior and harder debugging.

📦 Resources, constraints, Charmhub interactions

Some failures came from “looks fine until deploy fails.” Space constraints broke because prepared statement caching collided on struct names, and expensive prepare calls inside transactions hurt both performance and stability.

Resource handling also needed to match real use. Juju should accept legitimate empty resources, record resource IDs correctly, and block uploads when the model isn’t in the right importing state. Mount path fixes belong here too: Juju must consult the right container mount definitions and mount workloads in the right place.

🧰 Build/test/tooling correctness

CI and safety checks should fail loudly and clearly when something breaks—and stay quiet when things are fine. Some integration tests failed without useful output, which slowed triage. Some watcher tests flaked under load due to timing assumptions.

🔒 Security / hardening

Provisioning needs modern config. Cloud-init’s older apt mirror settings no longer work the way users expect, so Juju must use the supported spec. Agent binary fetching needed stricter validation too—version alone isn’t enough.

📚 Documentation updates

Secret backend package documentation: introduces internal documentation for secretbackend, making backend behavior and extension points easier to reason about. docs(secretbackend): introduce package documentation

📘 Summary

Overall, 4.0.1 focuses on making the Juju 4.0 more dependable for real migrations, safer controller lifecycle operations, and smoother day-2 debugging and secrets usage.