Prepare an installation for real customers
On this page
A running health endpoint is the beginning of a deployment check, not the end. This guide turns the alpha's current capabilities and limits into practical operator decisions. It does not claim a security certification or a zero-downtime release process.
Decide whether the alpha fits your use
Authentication, tenant-scoped services, published calculators, retained estimates and integrations work. Password recovery, account verification, MFA, invitations, membership administration and automated customer-data erasure/retention are not configured in this preview.
If your deployment depends on one of those missing workflows, resolve that requirement before launch. Do not advertise a forgotten-password process that does not exist. Plan account access and recovery operationally without weakening authentication.
The security model and roadmap are the exact reference for current boundaries and planned work.
Establish the canonical HTTPS origin
Set BETTER_AUTH_URL to the exact public installation origin, then restart the application and worker after configuration changes. Preserve the incoming Host and protocol at your reverse proxy. Keep database ports private.
The administration interface and REST API stay on this canonical origin. Customer custom domains are separately verified public routes. Do not rewrite every unknown Host to a tenant or enable unrestricted certificate issuance.
Test login, logout and customer submissions through the real TLS proxy, not just loopback. Read the Linux proxy examples and domain reference.
Review registration and privileged access
Registration is open by default. After creating the accounts required for your deployment, consider OQS_DISABLE_REGISTRATION=true and recreate services with the updated environment. It closes new signups; it is not a role-management interface.
Use owners/admins for integration and organization changes. Avoid sharing one privileged credential with every business employee. Protect operator access to the host, PostgreSQL, storage and environment secrets; those privileges sit outside tenant authorization.
Compose currently uses an installation-operator database account. Separate restricted application/migration credentials remain a hardening task rather than an automatically configured feature.
Test the durable state
A complete backup needs PostgreSQL, local assets or S3 objects, configuration and the webhook encryption key. A database dump alone cannot restore logos or decrypt signing secrets after the key is lost.
Follow backups and upgrades, then restore to an isolated test installation. Verify old estimates and revisions, image assets, PDF output and integration-secret decryption.
Restored jobs can send old emails or webhooks. Keep external destinations disabled or isolated during restoration tests. Do not point a restored worker at real recipients until its pending jobs have been reviewed.
Test integrations separately
| Capability | A meaningful check |
|---|---|
| Storage | Upload a logo, restart and verify the same asset remains |
| SMTP | Send to a controlled recipient and confirm actual receipt |
| Webhooks | Accept a signed event, reject a tampered event and handle a duplicate |
| Embed | Complete the estimator on the real allowed parent origin |
| Custom domain | Verify TXT ownership and open the domain through valid TLS |
| API | Check the required scope and a deliberately missing scope |
| Worker | Inspect heartbeat and an actual completed delivery, not heartbeat alone |
System status reports SMTP configuration, not the validity of every provider credential. Keep credentials out of screenshots and diagnostic request dumps.
Prepare for business data
Explain contact collection, terms and follow-up to customers. Choose where webhook payloads and SMTP messages may be sent. Brand assets are public; customer records and PDFs require authorized business access.
Establish a retention and erasure policy that covers the database, backups, outbox/job payloads and integrations. The alpha does not automate that policy. Use privacy and data flow to inventory stored information.
Rehearse an upgrade
Pin a reviewed release or commit. Read its changelog and migrations, take a tested backup, rebuild and recreate services, then inspect migration, web and worker logs. Migrations are forward-only; changing application binaries back does not reverse a database migration.
Keep estimator publication rollback separate from software rollback. One changes active pricing, the other changes executable code and potentially the database schema.
Before switching traffic, complete the calculator in both supported languages, inspect its stored estimate and lead, generate its PDF and test mobile validation. Record your expected pricing cases so future upgrades can repeat them.