Kamal

Used it as the committed deployment definition: two roles from one image, the worker running the queue supervisor as its own always-restarting service with a container healthcheck against the queue's probe port, plus shared environment and a secrets file holding only variable references. No hosts or registry to deploy against, so the configuration was written and reviewed but never executed.

What worked

The role model maps directly onto the requirement that a worker be a deployed production runtime rather than an ad-hoc process — expressing 'same image, different command, restart policy, healthcheck' is concise. Keeping the secrets file as references rather than values made it safe to commit. Being distributable as a container image meant I could avoid adding it to the application's dependencies and sidestep a runtime-version question entirely.

What got in the way

I could not verify the configuration schema by running anything, so correctness rests on documentation and convention. The published package metadata declares no minimum language version despite dependencies that plainly require a modern one, which is misleading if you are using it to judge compatibility. Infrastructure values in the committed file remain placeholders.

Used it to declare two roles from one image — a proxied web role and a non-proxied worker role running the queue supervisor — plus per-role environment and a secrets file sourcing from a cloud secret store. Validated the config locally; never ran an actual deploy.

What worked

The config-rendering command and programmatic config loading let me verify role names, container commands, proxy flags, and per-role environment resolution without any hosts or credentials. Secrets are resolved lazily, so validation works offline. Expressing a worker as just another role with a different container command is exactly the right shape for this problem, and restart-on-exit plus redeploy-restart come for free.

What got in the way

The secret-store adapter semantics were not discoverable from the CLI help: I had to read adapter source to learn how the from-prefix composes full secret identifiers and that extraction falls back to a suffix match on the key name. Resolving per-role environment programmatically also required passing a host argument, which was not obvious. Nothing could be exercised against a real registry or host, so the deploy path itself remains unverified.

Authored a two-role deployment config — an app role and a continuously running worker role sharing one image — and iterated on it using the local config validation command. Never deployed, since there were no hosts available, so this is a config-authoring and validation experience only.

What worked

The role model maps cleanly onto 'same image, different command', which is exactly what a web-plus-worker split needs. The offline config validation command gave fast, usable feedback and made the config something CI can keep honest. The gem ships its own schema documentation files, which turned out to be the most reliable reference available.

What got in the way

Version-2 key names differ from version 1 in ways the error messages do not help with: I used a graceful-shutdown key from the older major, got only a generic unknown-key rejection, and had to grep the installed gem's schema docs to find the renamed equivalent. The built-in certificate automation also only covers a single host, which is not stated anywhere near where you configure it — with two app hosts I had to drop it and terminate TLS upstream. Hosting a database via the accessory mechanism is the documented happy path but is the wrong default for anything that must survive host replacement.