8000 feat(scaling): DigitalOcean and Hetzner Cloud providers by adeelahmad · Pull Request #573 · adeelahmad/lense · GitHub
[go: up one dir, main page]

Skip to content

feat(scaling): DigitalOcean and Hetzner Cloud providers - #573

Merged
adeelahmad merged 1 commit into
mainfrom
claude/project-thread-azm2mb
Oct 18, 2026
Merged

adeelahmad merged 1 commit into
mainfrom
claude/project-thread-azm2mb

Conversation

@adeelahmad
Copy link
Copy Markdown
Owner

Description

Before: auto scaling could only run more workers on the machine Lens runs on.

After: an admin can add a DigitalOcean or Hetzner Cloud provider. Saving one checks the token with a read-only call, and units are priced at the cloud's hourly list price; Hetzner's euro price is turned into dollars at a rate the admin can set. A group on one of these providers launches machines tagged for Lens. Each machine's first boot runs the mesh's install line, with a join token for that unit that works once within an hour. When a unit goes, its machine is deleted. Until the mesh has its install line (in progress, docs/mesh.md), these groups wait and launch nothing, and waiting_for says why.

How: domain/scaling_clouds.py holds a small REST driver base on httpx plus the two drivers. scaling_drivers.user_data builds the first-boot script: the unit's name and steps as environment, then the install line. Drivers gain needs_join, and the scaler keeps a needs_join group from launching unless scaling.can_join(cfg).

Motivation and Context

Adeel asked for auto scaling worker nodes on AWS, DigitalOcean, Hetzner, Proxmox and remote Linux. This PR is the second piece, after the core in #556. AWS is in the Dynamic expansion thread's #559. Proxmox, SSH and the model hosts come next.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change; ! in the title)

Checklist:

  • The title is a Conventional Commit.
  • My code follows the code style of this project (make hooks checks it on commit).
  • I added or updated tests.
  • My change requires documentation updates, and I have updated docs/ accordingly.
  • Users need more than the title to understand it, so I wrote it under ## Unreleased in CHANGELOG.md. (n/a: the title and docs/scaling.md say it)

Done questions (AGENTS.md)

  • Goal: two of the asked-for node providers. They launch once the mesh's install line lands; the other providers follow.
  • Agents: the same REST, MCP and assistant scaling tools take digitalocean and hetzner providers.
  • Zero setup: nothing to install. The drivers use httpx, which Lens already has.
  • Fewest clicks: region, image and size have defaults, so only the token is required.
  • Configurable: every setting has a default and is on the provider (Settings forms for providers come in a later PR, as planned).
  • Light: off by default, with no new dependency.
  • Private and secure: tokens are sealed and only the fixed API hosts are called. The user-data's join token works once, within an hour. Threat model: P-SCALING's voided-by names both.
  • Cost: list prices go to the ledger as estimates; the euro rate is labelled an estimate and can be set.
  • User decides: approvals are unchanged, and existing defaults are unchanged.
  • Upgrades: there is no change to stored data.
  • Honest: docs and README call these providers in progress, since launching waits on the mesh's install line.
  • Tests and docs: 3 new backend tests against mock cloud APIs. docs/scaling.md, the README, requirements and the threat model are updated. OpenAPI is unchanged (make openapi produced no diff).
  • Open: no new dependency.
  • Reported in the project thread. Refine later is in docs/scaling.md.
  • Reuse: httpx, the core's driver interface, and the mesh's tokens.

Local CI (ci/local-ci.sh) passed on 5ef90e3 for both backend jobs, Next.js, pre-commit and the title check. The upgrade job was cut off by the background time limit, so GitHub CI covers it.


Generated by Claude Code

Droplets and Hetzner servers boot with user-data that runs the mesh's
install line with a one-use, one-hour join token, carry Lens's tag, and
are deleted when their unit goes. Groups on providers whose machines join
over the mesh wait, launching nothing, until the mesh has that line.
Both call the clouds' REST APIs with httpx, so nothing is installed.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ALjNbLobvPe7VwvDL8j7V3
@adeelahmad
adeelahmad merged commit 36f8496 into main Oct 18, 2026
12 checks passed
@adeelahmad
adeelahmad deleted the claude/project-thread-azm2mb branch October 18, 2026 07:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

0