Self-hosting that was designed for the first hour

The eight steps

1. Database. Point Qrly at a PostgreSQL instance and probe the connection. Read-only.
2. Schema. Check what is there. Installing is an opt-in action that runs the idempotent migration alone and stamps nothing.
3. Tenant. The outermost unit of the multi-tenancy model.
4. Organisation. The unit that owns connections, collections and users.
5. Admin account. The first superuser. There is no default account with a known password, because there is no seeded account at all.
6. Settings. Properties management — read, save, generate a secret, download.
7. Service. Detect the systemd unit, copy or download the unit file, install, start, stop and check status, with a manual fallback for hosts where that is not appropriate.
8. Confirm. The only step that commits. It migrates, creates the tenant, the organisation and the superuser, then stamps the initialisation flag.

Property one: nothing is written until Confirm

Unless the operator explicitly asks for it, every step before Confirm is a read-only probe — status, check-db, check-schema. This matters because first-run setup is exactly where a half-finished attempt does the most damage: an abandoned wizard that has already created a tenant, or already stamped a migration baseline, leaves a database in a state nobody documented. Qrly's wizard leaves the database as it found it until you commit, which means you can walk through it against a production candidate to see what it says and then close the tab.

Property two: secrets are never read back

The setup endpoint is reachable before authentication. It has to be — there is no account yet. That makes any read-back of a configured secret a pre-authentication disclosure, so Qrly does not do it. Instead, each field reports one bit of information: whether the value is still the one the distribution ships. That comparison is made against the packaged properties with ${VAR:default} unwrapped, so a value inherited from an environment-variable default is judged correctly rather than by string equality on the template.

The practical result is the shipped-secret indicator: an operator can see at a glance which secrets are still at their distribution default and therefore must be changed, without the page ever disclosing a secret that has already been set. Values still at the shipped default are regenerated in the clear, precisely because they are not secret yet and you need to be able to copy the replacement.

False-history detection

There is a specific broken state that migration tooling handles badly: a baseline stamped on a database that never actually held the schema. The history table says the schema is at version N; the schema is not there at all. The usual outcome is a startup that refuses to migrate and an error message describing a version mismatch rather than the real problem.

Qrly names this state explicitly and clears it when the history records no migration of its own — and refuses with a count when it does, rather than quietly discarding real history. It is a small thing that turns an afternoon of confusion into a sentence on a screen.

What runs, and when

1. Alerts and delivery. AlertScheduler hourly with per-cadence gating; SubscriptionScheduler daily at 06:00.
2. Cache and materialization. MaterializationScheduler per minute for question-level caches; TableMaterializationScheduler per minute for tier-three crons; TableSyncScheduler per minute for tier-four configs and groups; QueryCacheEvictionScheduler sweeping the in-process tier every 60 seconds, cleaning the persistent tier hourly and ticking active refresh.
3. Schema and freshness. SchemaSyncScheduler nightly; FreshnessScheduler every five minutes.
4. Intelligence. AnomalyScheduler nightly at 03:00; ProactiveInsightScheduler hourly, honouring a per-organisation cron; ModelerEnrichmentScheduler nightly at 02:30; NarrationWorker draining every five seconds with FOR UPDATE SKIP LOCKED; WeeklyInvestigationDigestScheduler on Mondays at 07:00; RiskReportScheduler sweeping for overdue items hourly.
5. Housekeeping. BackupScheduler ticking every minute against the operator-editable cron; AuditLogRetentionScheduler daily at 03:00; AiCallContextPurgeScheduler daily at 03:30, defaulting to 90 days.

All of them are gated until the platform is initialized. That is not a detail — it is why an uninitialised Qrly is genuinely inert rather than merely un-navigable, and why a half-configured host does not start emailing subscriptions to an address somebody typed as a test.

Lifecycle signals

Qrly listens on a configurable PostgreSQL LISTEN channel and accepts reload schema, reload config or both, on a daemon thread with exponential reconnect backoff — skipping silently when the application database is not PostgreSQL. Two Unix signals are wired as well: SIGUSR1 reloads all schema caches, and SIGUSR2 logs a config-reload request. Both are the kind of thing you want to exist the first time a deploy script needs to nudge a running node without restarting it.

Four things Qrly does not do for you

1. PostgreSQL. Qrly needs an application database and does not run one for you. Version choice, storage, tuning, connection limits, patching and availability are yours. The product installs and migrates its own schema into that database and will tell you clearly when it cannot.
2. Verified backups. The platform console will run pg_dump on a cron, keep the results with size, duration and expiry, and let you download them. It will not restore one for you and it cannot tell you whether a restore would succeed. A backup nobody has restored is a hypothesis. Test it on a schedule, against a real target, and record the result.
3. TLS termination. Put a reverse proxy in front of Qrly and terminate TLS there, with your own certificate lifecycle. This also gives you a natural place for the custom domains that drive brand resolution and SSO discovery, since the hostname a user arrives on is what decides which sign-in buttons the login page offers.
4. The encryption key. Connection credentials are AES-encrypted at rest and the query cache is AES-256-GCM encrypted in both tiers. That protection is only as good as the key, and the key is yours to store, rotate and back up separately from the database. Restoring a database without the key restores an unreadable set of credentials — which is exactly what an attacker with only the database should get, and exactly what you must not accidentally arrange for yourself. The setup wizard's shipped-secret indicator exists to make sure this key is not still the one the distribution shipped with.

Everything else — schema installation, migrations, the systemd unit, clustering coordination, the schedulers, log levels, heap visibility, translation reloads — is in the product, which is the point of a first-run wizard that generates its own service file.