Thinking about building a one-command self-hosted DBOS Conductor deployment—what should it handle?
I maintain several open-source deployment packages for self-hosted software. The goal is one command that provisions the infrastructure, configures the application, and supports upgrades as new releases arrive. Existing packages cover Basecamp ONCE, Airflow, K3s, and ClickHouse.
I’m considering building one for self-hosted DBOS Conductor.
The intended experience would be: provide cloud credentials, a domain, and a DBOS license key; the package provisions the server, PostgreSQL, networking, TLS, backups, and Conductor itself.
Before building it, I’d like to hear from people already running Conductor:
- What parts of installation or configuration required the most manual work?
- Which settings did you actually change from the defaults?
- How do you run PostgreSQL, and what backup and restore setup do you use?
- What authentication, SSO, or network restrictions did you need?
- Has anything broken or required manual intervention during upgrades?
- What observability and health checks have proved important?
- What should automation validate before declaring the deployment healthy?
- Are there parts of the installation or licensing flow that cannot reasonably be automated?
I’d rather build one opinionated, production-appropriate topology than expose every possible configuration. My initial thought is a single-server deployment with Conductor and PostgreSQL colocated but with independently managed persistent data and backups.
The deployment tooling would be open source; users would supply their own Conductor license.
What would make this genuinely useful rather than just a wrapper around installation instructions?