Skip to content

Hop3 0.6.1 Released

June 24, 2026 Release Announcement

Hop3 0.6.1 is out, two days after 0.6.0. Where 0.6.0 added platform capability — resource limits, a richer addon surface, a signed catalog — 0.6.1 is a consolidation release: it simplifies how you point the CLI at a deployment, makes Nix builds reproducible, pulls the email addon forward, and works through a broad stability pass. Read on for the details.

What's New in 0.6.1

One model for "where does this deploy?"

0.5 introduced two nouns for targeting a deployment — credentialed servers and project contexts — and 0.6.0 carried both. In practice the distinction was a tax: you had to know which one a command wanted. 0.6.1 collapses them into a single managed noun (ADR 042).

A context is now a deploy environment — dev, staging, prod — declared in your committed hop3.toml under [contexts.<name>]: a non-secret bundle of server address, app, domains, and env. --context is the one selector; the --server flag, the hop3 server command, and servers.toml are gone. Credentials drop out of sight into a per-server credential store (~/.config/hop3-cli/credentials.toml, mode 0600), and config.toml becomes secret-free — local preferences and an optional default-context pointer, nothing more. Existing connections migrate to the credential store on first run. And when a context can't be resolved, the CLI now says so with the full resolution chain rather than quietly falling back to some default server.

Authentication got the same de-duplication: hop3 login and hop3 auth login are one command, login --web is fixed, and a new hop3 auth get-token prints the current bearer token for scripting.

Reproducible Nix builds

Every Nix recipe now pins nixpkgs to a specific commit. The 33 hand-crafted hop3.nix expressions and the nix-gen template generator fetch a fixed nixpkgs via fetchTarball, and the installer no longer leans on a mutable nix-channel. A build resolves the same toolchain whatever the host's channel state happens to be — a precondition for the build/run reproducibility the Nix runtime is meant to deliver. A companion fix keeps the previous build's GC root alive across a rebuild, so a running worker's store closure can't be garbage-collected out from under it mid-deploy.

An experimental email / SMTP addon

The email/SMTP relay addon was on the 0.7 list; it lands here as an experimental addon (ADR 051). Provision an outbound relay and Hop3 injects its settings into your app following documented config-injection conventions — the same path that lets apps like Vikunja and Monica pick up SMTP without hand-wiring environment variables.

Reliability and test-infrastructure fixes

A round of correctness work, much of it surfaced by the nightly Test Lab packaging real apps:

  • Discourse precompiles its assets at build time, so the container binds $PORT inside the health-check window instead of after a multi-minute compile.
  • Kanboard runs its schema migration to completion before serving, so Hop3's readiness probe can't interrupt it mid-DDL and trip a half-applied migration.
  • Elixir apps no longer let a hardcoded [env] value clobber the toolchain's MIX_HOME at runtime.
  • Addon create no longer reports success on a generic-path edge where the addon wasn't actually created.
  • The Nix flake packages and the NixOS CI build again.
  • The Test Lab itself reports more truthfully: a run that completes with failing tests is recorded as failed rather than crashed, the report shows the packaging variant (native / docker / nix) instead of "other" and the demo's real name instead of "app", dispatch runs off-thread with quieter scheduler logs, and the queue view gained build numbers, timestamps, and a foldable detail.

App-packaging corrections

Archived Focalboard is dropped from the advertised set (upstream is no longer maintained). Validations for shlink and piwigo were corrected, bugsink's start-timeout raised, and native Monica is marked expects-failure — it forces HTTPS, which can't be verified over the plain-HTTP test path.

Installing and upgrading

On your server:

curl -LsSf https://hop3.cloud/install-server.py | sudo python3 -

On your laptop:

pip install hop3-cli

Existing installs upgrade in place; schema migrations run automatically. One thing to know before you upgrade:

  • hop3 server and --server are gone. If you have scripts or shell history using hop3 server … or --server <name>, switch them to --context <name> (or set a default context). Your existing config.toml connections migrate to the credential store automatically on first run.

What's Next

0.7 is the final deliverable of Hop3's NGI/NLnet grant, and it's where the remaining production-readiness items land:

  • A web application firewall — Layer-7 filtering with LeWAF, our pure-Python engine implementing the OWASP Core Rule Set (ADR 050). The schema and compiler shipped in 0.6; the runtime proxy integration arrives in 0.7.
  • A production hop3 upgrade command, with app-level orchestration and rollback on failure.
  • Web UI — Git-URL deploy, real-time log streaming, and an accessibility pass.
  • An external security review and accessibility scan.
  • Quantitative benchmarks and the final project paper.
  • Screencasts — a zero-to-running-app walkthrough and a dashboard tour.

Get Involved

Hop3 is open source (Apache 2.0):

New to Hop3? Start with Your First Deployment. Curious how we keep it reliable? Read How Hop3 is Tested.