Hi HestiaCP team 
First - thanks for HestiaCP. Upfront: I know Docker isn’t officially supported, and I’m not asking you to support it. I maintain a community image + an Umbrel app on my own (ptrinh/hestiacp-docker) and it works well as a control panel. I only want to gauge whether you’d be open to a few small, environment-agnostic robustness changes that surfaced - ones I believe are harmless (or mildly positive) on a normal systemd install too. If it’s “out of scope,” totally fair and I’ll keep everything downstream.
What I observed: The panel runs fine non-privileged. The fragile spot without systemd is live web changes (e.g. v-add-web-domain): HestiaCP runs v-restart-service → systemctl reload-or-restart <web/php> and verifies the result. When PID 1 isn’t systemd, a restart can report failure and leave nginx/php-fpm down until the next clean start. I work around it by regenerating configs from persisted data + one clean restart at container start (v-rebuild-user), which is reliable - but live ops stay best-effort.
Questions:
- Open in principle to PRs making service control a thin, pluggable abstraction (one v-restart-service indirection targeting systemd or a generic service/supervisor backend) - systemd staying the default and only supported path?
- Or, smaller: accept making a restart’s status check more resilient (warn-and-continue when the init system can’t report status), without changing behaviour on supported OSes?
- Or keep this entirely in community images (no core changes)?
Happy to do the work and keep it minimal/opt-in - just want direction before opening anything. Thanks!