Deployment, backup and operations

These instructions do not deploy a site, package or remote endpoint.

Windows release readiness

Formal packaging requires matching SDK/runtime inputs, the web workbench build, tests and distribution-approval evidence. A passing packaging gate is not proof of a clean installation, upgrade, device isolation or long-duration acceptance.

Before customer release, record package hashes, dependency manifest/SBOM, SDK permissions, runtime/model distribution approval, OS/environment, supported camera/firmware and test evidence. Verify desktop, service, contracts and web assets are from the matching release. Do not redistribute licensed SDK files.

Back up before change

1. Reconcile running and unknown operations and preserve recovery requirements.
2. Stop the application and its own service through the normal controls; confirm the intended instance is stopped.
3. Back up the actual task data root and separate camera configuration to a new destination. Preserve original/result images separately where required by site policy.
4. Record package identity, data/schema version, instance, time and backup hashes. Protect backup credentials/data as private information.
5. Verify the backup can be read and plan restoration on an isolated copy. A file copy alone is not a tested restore.

Do not run an older service against a newer database or remove recovery materials to free space. Database schema changes and camera-job recovery are separate concerns. Downgrade compatibility and complete production restore need explicit validation.

Browser Lab and research hosting

The product has a separate public Lab build and Worker configuration. The deployed lead form, cookie gate, data bindings and optional human check are operator responsibilities. Building a static Lab directory alone does not reproduce the hosted gate.

Research account/relay hosting is another deployment. It requires matching web/relay/server versions, configured identity provider/client registration and database policies. Public own-Codex and complete production restore/load acceptance remain pending in the reviewed evidence. Do not enable those features by copying a Lab deployment.

A restored account database may include previously valid sessions; retirement and account authorization-version checks are required before admitting HTTP requests. Do not restore a session-bearing database directly to a public service.

Operations checklist

Monitor actual writer failures, disk space, recovery requirements, request receipts and service identity. Test disconnect/reconnect and expected shutdown in a controlled window. Use the site's retention and backup policy; gaps remain in internal-material budget and cleanup coverage.

No universal camera-count, 24-hour stability, restore-time or zero-downtime claim is established by the reviewed preview.