Hi
Hi, Exasol Personal PM here. Not yet, but very soon
great, that will make it extreme useful for prototyping / testing in the scientific sphere where budget for extra cloud costs would usually be missing
What’s the difference/relationship of Personal to the Community Edition then?
FYI @WunderdataSL - if you want to try this out on Hetzner (Cloud, not bare metal), feel free to test my PR
main ← ingolevin:il.hetzner
opened 05:12PM - 13 May 26 UTC
## Description
Add full Hetzner Cloud support to Exasol Personal, including i… nfrastructure provisioning, cleanup provider, and power state management via the Hetzner Cloud API.
## Related Issue
None
Fixes #
## Type of Change
- [x] `feat`: New feature
- [ ] `fix`: Bug fix
- [ ] `docs`: Documentation update
- [ ] `test`: Test additions or changes
- [ ] `refactor`: Code refactoring
- [ ] `chore`: Maintenance tasks
## Changes Made
### New Infrastructure Preset: Hetzner Cloud
- **Location**: `assets/infrastructure/hetzner/`
- **Components**: Network, subnets, servers (ccx33 default), volumes, firewall, SSH keys, TLS certificates
- **OS**: Ubuntu 22.04 LTS with cloud-init configuration
- **Features**: Single/multi-node clusters, separate data volumes, generated passwords (20-char, mixed case + special chars)
### Cloud-init Fixes
Hetzner Ubuntu images use `root` as the default user, but Exasol expects `ubuntu`:
- Added `cloudconf/10-create-ubuntu-user.yaml` to create the `ubuntu` user with correct SSH authorized keys
- Injects SSH public key via cloud-init template to avoid timing issues with Hetzner's key injection
- Populates `known_hosts` with a retry loop so the barrier client can SSH to itself on the private network
### Power State Management
- `exasol stop` and `exasol start` call the Hetzner Cloud API directly from Go using the `hcloud-go/v2` SDK
- Server IDs are read from `deployment.json` at stop/start time — no Terraform state involvement
- Graceful shutdown attempted first; falls back to forced poweroff on failure
- Waits for the API action to complete before returning
- `HCLOUD_TOKEN` must be set in the environment for stop/start to work
- Infrastructure manifest declares `powerControl.provider: hetzner` to enable this behaviour
### Cleanup Provider
- New package: `tools/cleanup/internal/hetzner/`
- Discovers and deletes: servers, volumes, networks, firewalls, SSH keys
- Uses Hetzner resource labels (`deployment_id`) for scoped discovery
- Integrated with `exasol-cleanup` CLI
## Testing
- [x] All existing tests pass (`task all`)
- [ ] Added new tests for new functionality
- [x] Manually tested: `exasol install`, `exasol stop`, `exasol start`, `exasol-cleanup`
### Test Details
Manually verified on a live Hetzner deployment:
- Full install with SSH access and database connectivity
- `exasol stop` shuts down the VM via API and updates workflow state
- `exasol start` powers on the VM via API, waits for it to be reachable, then updates workflow state
- `exasol-cleanup` discovers and removes all Hetzner resources
## Checklist
- [x] Code follows the project's [coding guidelines](doc/best_practices.md)
- [x] Ran `task fmt` and `task lint`
- [x] Updated documentation (if applicable)
- [ ] Added/updated tests
- [x] All tests pass locally
- [x] Commit messages follow [Conventional Commits](https://www.conventionalcommits.org/) format
## Additional Notes
The `HCLOUD_TOKEN` environment variable must be set for all operations (install, stop, start, cleanup). It is used by both OpenTofu (via the hcloud provider) and the Go launcher (for direct API calls during stop/start).
You will be able to run a single-node Exasol database on your local machine. It will be a very small single binary that you use to start and stop the DB. With the same binary you can also start a DB in the cloud if you wanted to. The plan is to eventually even be able to migrate between local and cloud.