Skip to content

v0.1.15

Choose a tag to compare

View all tags
@github-actions github-actions released this 30 Aug 13:07
· 14 commits to main since this release
v0.1.15
723526d
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

What's new in 0.1.15

Runners

Concentus has been one backend that is both the control plane and the place flows execute — the claude CLI on the machine the window is on, against the login already there. It still is. What is new is the other shape: a hub somebody deployed (java -jar, or the Docker image), and runners connected to it.

  • A runner is the execution half on its own. A process on a machine you operate — a laptop that stays on, a NAS, a container on your own cluster — connects out to the hub, registers with a token minted there, and runs the CLI turns the hub hands it. The hub keeps the flows, runs, approvals, credentials, groups, policies and the interface; the runner keeps the login, the folders, the clones and the processes. The same shape as a GitLab runner.
  • The login stays where its owner runs the process. Anthropic's terms do not allow a subscription's credentials to be routed through a third party, so the hub never holds a Claude login or a setup-token. A runner carries its own — the CLI's login on that machine, CLAUDE_CODE_OAUTH_TOKEN from claude setup-token, or ANTHROPIC_API_KEY — and the hub only ever learns which kind. Hosted execution stays API-key only, as before.
  • Three scopes. Whoever registers a runner chooses who may run flows on it: the whole organization, one group (Enterprise), or only me — somebody's machine and somebody's login, so not even an admin, and never a schedule or a webhook.
  • Resources → Runners. A roster with a status dot, the runner's host, version and CLI auth, and how busy it is. + New asks a name and a scope and shows the token once, with the three ways to start it and the hub's URL filled in: java -jar concentus-backend.jar runner --url … --token crn_…, docker run …, or the desktop app's tray → Set up… → Server.
  • The desktop app can be a runner too. Server, the optional last step of the first-run wizard (and reachable from the tray later), keeps the token in the OS keyring and restarts the backend with its agent connected. Everything local keeps working; this is also, not instead. The tray says whether it is connected and opens the hub's interface in a window of its own.
  • Runs on, in a flow's Settings: This server (here when the CLI is logged in, otherwise a runner you may use, otherwise today's answer), Any runner (the least busy one online), or a runner by name. Only Claude CLI flows go to runners; a self-hosted model stays on the hub. A run that went to a runner says so in its first line and carries a chip with the runner's name; the review of its checkouts is re-read through the runner while it is connected.
  • runner mode of the jar never starts Spring — no database, no port, a few hundred milliseconds to connect — and reconnects on its own when the hub goes away. A revoked token makes it stop for good, with exit code 3.
  • Docker. ghcr.io/gergilcan/concentus-hub and ghcr.io/gergilcan/concentus-runner, built on every stable release from now on, and a compose file under packaging/docker that brings up a hub and a runner in the order the token requires.

Not in this release. A turn does not survive the runner disconnecting: after 45 s without a heartbeat the hub ends it as disconnected, and what the runner was running finishes on its side with its output lost. Finished workspaces are not cleaned up on the runner. Self-hosted models do not run on runners. There is no queue for a runner that is not online — a launch with none fails at once, and a schedule simply fires again.

How it was tested. A real hub and a real agent over the real socket with a fake claude that prints what the real one prints (backend suite, Playwright); the two Docker images with compose on one machine — a hub, a runner with the real CLI (which answered Not logged in, relayed to the run), a runner with the fake one (a completed run), and a revoked token (the container exited 3). Not yet: a runner across a real network with a real login.

Tests

  • The runners end to end, against the real application: the jar in runner mode registered, connected, executing a flow and revoked, with a fake claude that prints what the real one prints. In CI with the rest.

Docs

  • Runners in the docs (English, Spanish, Catalan) and the README; the Docker images and compose under packaging/docker.

Full Changelog: v0.1.14...v0.1.15

Assets 17
Loading