A build fix and nothing else. The code is the same as 0.1.1, and the workflows that test and publish Cascade run on Podman the whole way through.
- Same code as 0.1.1, and so is everything you run: the chart, the Quadlet units, the settings and the database. No migrations and no new settings.
- The workflows that test and publish Cascade no longer reach for a Docker engine to start the test services, log in to the registry or load the image into k3s. The test scripts no longer offer Docker as a switch.
- The image was already built with Podman. It is built one platform at a time now, and the release reads the manifest list back and refuses to push unless it holds exactly amd64 and arm64.
- The image and the chart are public and pull with no login. The source repository is still private.
Pull it with `podman pull ghcr.io/hotloop-io/hotloop-cascade:0.1.2`, or install the chart with `helm install cascade oci://ghcr.io/hotloop-io/charts/hotloop-cascade --version 0.1.2`. The image is amd64 and arm64, and the tags are 0.1.2, 0.1, 0, latest and stable.
Upgrading from 0.1.1 means nothing to do. Run `helm upgrade` to 0.1.2, or let `:stable` roll the Quadlet units. Your key and your workflows stay where they were.
What isn't proven: the workflows on a real GitHub runner. I ran the workflow's own steps under Podman 4.9.3, the version the runner ships, on a box cut down to two CPUs, 7 GB of RAM and a runner-sized disk, with a local registry that needed a login. The tag run was the first time ghcr.io saw any of it.
The first Cascade release. A workflow engine in one static Go binary where every step is checkpointed, so a kill -9 in the middle of a run picks up where it left off.
- The engine: every step checkpointed, durable waits, retries, error ports and error workflows. Expressions, and a Code step that runs JavaScript in its own jail in its own process.
- Webhooks with a durable inbox, schedules that fire each slot exactly once no matter how many mains are looking, MQTT, and a trigger for files that land in a directory. An HTTP step for anything with an API, and connectors for HotLoop, Postgres, ERPNext, email, ntfy, Gotify and Discord. No others, on purpose.
- A credential vault with key rotation, OAuth2 for every grant a plant needs, sign-in with passwords, TOTP, passkeys or your OpenID Connect provider, enforced MFA, projects and roles, an audit log you can verify, every save kept as a version, and a scoped API with an OpenAPI document.
- Metrics, traces and probes, so somebody besides me can tell when it's stuck.
- SQLite on one box or Postgres with workers when you need more. The editor is baked into the binary, so there is nothing else to run.
- Podman with Quadlet units that follow :stable and roll an update back if it doesn't come up healthy, or k3s with the Helm chart, standalone or split into server and workers.
Pull it with `podman pull ghcr.io/hotloop-io/hotloop-cascade:0.1.1`, or install the chart with `helm install cascade oci://ghcr.io/hotloop-io/charts/hotloop-cascade --version 0.1.1`. The image is amd64 and arm64, and the tags are 0.1.1, 0.1, 0, latest and stable. The registry was private for this release, so it wanted a `podman login ghcr.io` as root first. The image and chart are public from 0.1.2 on and pull with no login.
There was a 0.1.0 tag and it never published anything. Its chart test failed on a hosted runner and I cancelled the run, so nothing reached the registry, and a tag stays where it is. 0.1.1 is the same code with the test fixed. It checked the upgrade by listing pods while the old ones were still stopping, which a quiet laptop never shows.
Migrations only go forward. A rollback puts the old image back and does not un-migrate your database, so take a backup before you turn updates on. Lose the key that seals stored credentials and every stored credential is unreadable, so keep a copy somewhere that isn't the box. Not here yet: SAML, LDAP, SCIM, environments, the HA scheduler with leases, more connectors and AI steps. That is 0.2.0 and on.
