Skip to content

Hop3 0.6.0 Released

Hop3 0.6.0 is out. Where 0.5 was a consolidation release — reliability, security, and a CLI that gets out of your way — 0.6 builds platform capability on top of it: per-app resource limits and volumes, an addon surface you can actually operate, a signed app catalog, etc. Read on for more details.

What's New in 0.6

Resource limits and volumes

Declare what an app is allowed to use, right in hop3.toml. A [limits] section caps memory and CPU — enforced through cgroup v2 for native apps and the deployer for containerized ones — resolved against a server-wide default and ceiling policy. hop3 app status reports the active caps and any out-of-memory kills, so a killed worker is visible rather than mysterious. Apps can also mount persistent bind volumes and tmpfs with [[volumes]], provisioned by the privileged daemon behind a default-deny allow-list and reconciled at startup. (ADR 046.)

A much richer addon surface

0.6 turns addons from "provisioned and forgotten" into something you operate. Every backing service — PostgreSQL, MySQL, Redis, S3 — gets a consistent hop3 addon <type> <verb> surface:

  • ad-hoc queries (SQL or redis-cli, least-privilege) and read-only diagnostics (activity, locks, settings, Redis info);
  • clone an addon, and export / import a dump by streaming it over stdin/stdout;
  • destructive verbs (restore, flush) ask for confirmation.

On top of that, the lifecycle and access commands: addon exists, addon promote (per-addon variable namespacing), addon endpoint, addon expose / unexpose, and hop3 tunnel to reach an addon from your own machine.

A signed app catalog

Hop3 can now load a signed, central catalog of installable apps from a trusted source (hop3 catalog refresh, kept current at setup time) and browse it from the dashboard. Publishers get matching tooling: hop3-catalog validate gates content specs, and hop3-catalog publish builds and signs the catalog tarball. The dashboard is hardened against untrusted content — app READMEs are sanitized and only raster icons are accepted — and the former "marketplace" is now the "catalog". (ADR 049, ADR 031.)

Stable ports for non-HTTP apps

Not every app speaks HTTP. A fixed-port registry (ADR 045) lets a non-HTTP app — a game server, an RTMP ingest, a mail listener — claim a stable host port declaratively from hop3.toml, optionally restricted to source CIDRs, with hop3 ports listing the active claims. Apps no longer grab a fixed port outside Hop3's control and quietly collide with each other.

Secrets and config, single-sourced

HOP3_SECRET_KEY now lives in exactly one place (ADR 048), ending an environment-vs-config drift that could leave addon credentials unreadable after a restart. Redeploys are idempotent: re-running the installer reuses existing database secrets and preserves operator config instead of regenerating them. And an app can ask Hop3 to mint its own secrets — SECRET_KEY = { generate = "urlsafe" } under [env] provisions a stable, per-app value.

CLI consistency

The app target is now --app only (ADR 036) — the deprecated positional argument is gone. A round of renames keeps the surface consistent: launchcreate, backup infobackup show, addon psaddon activity, domainsdomain, the Procfile importer env migrateapp migrate, and account creation consolidated under user add. Every old spelling still works as an alias.

Reliability fixes

A redeploy no longer SIGTERMs its own in-flight git receive-pack, so git push deploys complete reliably. The app port is stable across redeploys; static sites without a Procfile are served straight from [build].static-dir; build-output directories (Rust / Maven target/) are dropped from the upload; and the Redis health check authenticates correctly when no password is set.

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. Two things to know before you upgrade:

  • Minimum Python is now 3.12 — support for 3.11 was dropped.
  • The app target is --app — if you have scripts that used the old positional form, switch them to --app <name>.

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 configuration schema and compiler shipped in 0.6; the runtime engine arrives in 0.7.
  • A production hop3 upgrade command, with app-level orchestration and rollback on failure.
  • An email / SMTP addon.
  • 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.