Daniel Nashed's Blog

Hetzner Server Factory for Domino workshops

Quite some time ago, I put together a small Domino database as a lab registration and automation tool. The original idea was simple and very pragmatic:
bring up Hetzner servers on demand for workshops, send notification emails to each participant, and tear everything down again once the workshop was over.

From a user perspective, the setup was intentionally minimal. You only had to provide your API keys for the DNS API and the Cloud API, and the database took care of the rest.
Over time, however, things changed. Hetzner merged the DNS API into the Hetzner Cloud API, and that was a good excuse for me to revisit the whole implementation.

Making the database smarter

Before my recent changes, the database required you to manually specify server type and location.
While that worked, it always felt a bit clunky. When I looked at it again, the obvious improvement was to stop hardcoding assumptions and instead pull all relevant metadata dynamically via REST.

So now the database reads:

• locations and data centers
• available images
• server types and capabilities
• and related configuration options
   

directly from the API and stores them locally. This not only reduces errors, but also makes the solution future-proof when Hetzner adds new regions or instance types.

DNS, SSH, and networking — automated

The database was already providing the most important automation steps:

• setting DNS records automatically for the assigned public IP
• creating the corresponding IN-ARPA reverse DNS entries
• assigning SSH keys during server provisioning
   

On top of that, I’ve now added support for:

• labels, which are extremely useful for grouping and lifecycle management
• automatic assignment to a private network, selected via a configuration profile
   

That last point is particularly important for lab deployments, where you want all machines to immediately see each other without any manual networking work.

Intended use: workshops and labs

This database is not (yet) an open-source project. That said, I’m more than happy to provide it to user groups that want to run workshops and need temporary cloud infrastructure.
In fact, we are already planning workshops this year for DNUG and Engage, and chances are we’ll need Hetzner-based lab environments spun up on the fly.
This database was designed for exactly that use case.
An interesting side effect: after adding the new functionality, I was asked to import existing DNUG lab data into the database.
That worked without any issues — even with read-only API tokens. Each database instance manages exactly one Hetzner project, defined solely by the API token it uses.

What’s next?

The next logical step is cloud-init integration. Not for anything fancy, but to bootstrap lab environments more efficiently — for example:

• starting custom scripts pulled from Git
• mounting and using an NFS share prepared as part of the lab

No magic involved. This is a straightforward REST API implementation in LotusScript talking to the Hetzner Cloud API — which, by the way, is easy to consume and very well designed.
I may also give the database UI a bit of love and improve navigation -- No, I’m not going to use Notes Restyle ...

• Comments [0]