OpenRC or runit for reproducible Artix development images

Short answer

Use a single init variant for every supervised service in one Artix image. For a development image running common databases and queues, OpenRC is the safer default on Artix because its packaged service scripts are generally more complete, but treat that coverage claim as likely rather than verified until you check your exact package list. Pin the choice in the image definition so rebuilds cannot silently switch variants.

What is confirmed vs. likely

Confirmed by how Artix is structured: init-specific variants exist side by side (for example postgresql-openrc and postgresql-runit), installing both supervisors in one image can leave conflicting supervision or orphaned state, and reproducibility depends on pinning package selection rather than letting the resolver float. Likely, and marked for review: OpenRC ships ready-made scripts for more of the usual dev daemons (PostgreSQL, MariaDB/MySQL, Redis, RabbitMQ) than runit, whose scripts are simpler but thinner for complex daemons. Repository contents change between Artix releases, so re-verify before freezing the image.

Steps for this case

1. Pick one supervisor — OpenRC unless your service list says otherwise — and install only that base plus matching suffixed packages.
2. Pin selection in the image definition with an explicit allowlist, e.g. a checked-in packages.txt consumed by the build, instead of a floating group.
3. Add a build-time guard that fails if more than one init suffix appears:

   test "$(pacman -Q | grep -E -- '-(openrc|runit)$' | sed -E 's/.*-(openrc|runit)$/\1/' | sort -u | wc -l)" -eq 1

4. Enable services deterministically at image build or first boot, e.g. rc-update add postgresql default, and start them from the entrypoint so no manual step is needed after a rebuild.
5. Verify coverage for your exact daemons before pinning:

   pacman -Ss -- '^(postgresql|mariadb|redis|rabbitmq)-openrc$'

Assumptions and gaps

Assumes a current rolling Artix repo and pacman-based image builds; exact repository names and group names vary by release. Some upstream projects ship only systemd units, so a few daemons will need a small hand-written OpenRC script or a wrapper — check each package rather than assuming a script exists. Because repo coverage is time-sensitive, treat the OpenRC-advantage statement as a draft for human review and confirm it against the repo at build time.

One detail would change the recommendation: which exact database and queue packages must this image run? If a required service has only a runit script and no OpenRC one, choose runit for that image instead.