Deployment options

Start with Install Hive for the required hosting contract. This page covers the choices that commonly differ between production environments.

Application processes

A Hive release has two responsibilities:

• Run database migrations before the new application version starts.
• Run the web process and expose its configured port through the public Hive address.

Keep these responsibilities in the same release so the application and database schema move forward together. Run a single web instance unless your platform has been tested with a different topology.

Visibility and authentication

Instances are public by default. Configure and test at least one authentication provider before setting HIVE_VISIBILITY=private.

Store provider credentials in the deployment's secret manager. Make them available to both migrations and the web process when the platform uses separate execution environments.

Database storage and backups

Hive requires PostgreSQL with durable storage. Size the database for the number of product signals, specs, comments, audit activities, and model usage records the organization expects to retain.

Use the database provider's normal backup system. Test both backup creation and restore before relying on it for production recovery. A backup is only useful once a restore has been proven against a clean environment.

Object storage

Hive can use Amazon Simple Storage Service-compatible storage for features that need durable objects. It is disabled by default.

Set HIVE_OBJECT_STORAGE_PROVIDER=s3 and provide the bucket, region, endpoint, access key, and secret key listed under Object storage. Keep storage credentials in the deployment's secret manager.

Secret management

Keep the session secret, database address, provider credentials, and integration signing secrets outside source control and deployment manifests.

Use the secret manager already supported by your hosting platform. Make secret rotation a deliberate operation: update the stored value, redeploy Hive, verify the affected integration, and revoke the previous credential when the provider supports revocation.

Do not rotate SECRET_KEY_BASE during a routine release. Changing it invalidates existing sessions.

Error reporting

Set SENTRY_DSN to send unhandled request errors and exhausted background-task failures to Sentry. Optional settings control the environment name, release label, retry reporting, and scheduled-task monitoring.

Leaving Sentry unset does not affect normal Hive behavior.

Production checklist

Before opening the instance to users:

1. Confirm /ready succeeds through the public address.
2. Test database backup and restore.
3. Sign in with every configured authentication provider.
4. Confirm an account outside the allowed domains is rejected.
5. Verify that public and private content behave as described in Authorization.
6. Connect a test repository and confirm that issues and releases appear.
7. Review secret rotation and incident-recovery procedures with the operators responsible for the deployment platform.