One product. Cloud and on-premises.

DocuBex separates interaction, relational records, document binaries and background processing. The browser expresses intent. Application services coordinate it. PostgreSQL and Prisma hold durable business state. S3-compatible storage holds bytes. Workers create derived outputs such as text and thumbnails.

That division is useful across deployment environments because a document version should mean the same thing regardless of where the object lives. Filing a document should not acquire a different business interpretation just because the storage endpoint changed. Provider adapters translate infrastructure behavior while domain services retain authorization, versioning and workflow rules.

The Windows Scanner Bridge and setup Hub remain separate applications with different responsibilities. A browser page is not the right place to own scanner drivers. Equally, a desktop installer is not the authority for whether a user may file into a particular organization or folder.

Avoid a customer fork for each environment unless there is a demonstrated requirement that configuration cannot represent. Forks multiply migration paths and make security fixes harder to distribute. A shared core still needs explicit compatibility contracts; “same repository” does not prove every configuration works.

The DocuBex case study supports this architectural account. The deployment checklist below extends the lesson into a recommended operating model rather than attributing unverified procedures to a client installation.

A configuration flag can request OCR while the worker is stopped. An endpoint can be reachable while its credentials are invalid. A provider can be healthy while policy forbids sending document bytes outside the installation.

Model those as separate questions: is the feature enabled, is an allowed provider configured, and is the required runtime ready? The UI should explain the resulting capability. If original-only filing is permitted, an unavailable enrichment path need not block intake.

DocuBex already distinguishes original storage, extraction, indexing and fuller enrichment. Its scanner inbox can file with processing off. That gives the product a useful path independent of optional intelligence services.

This illustrative policy function demonstrates a deployment capability decision. It is not the actual DocuBex configuration schema. Its result is advisory; the server must enforce policy again when work is submitted and executed.

type ProcessingProfile = {
  enabled: boolean;
  provider: "local" | "external" | "none";
  externalProcessingAllowed: boolean;
  workerReady: boolean;
};

export function processingCapability(profile: ProcessingProfile) {
  if (!profile.enabled || profile.provider === "none") {
    return { available: false, reason: "not-configured" } as const;
  }
  if (
    profile.provider === "external" &&
    !profile.externalProcessingAllowed
  ) {
    return { available: false, reason: "policy-blocked" } as const;
  }
  if (!profile.workerReady) {
    return { available: false, reason: "worker-unavailable" } as const;
  }
  return { available: true, provider: profile.provider } as const;
}

“Local” is not proof of isolation. A local helper may still call an external service. Validate the complete data path, including telemetry, error reporting, email, model calls and software-update checks. Capability names should describe verified behavior rather than imply it.

For each operation, identify the data crossing each boundary: original file bytes, extracted text, embeddings, filenames, user identifiers and diagnostic events. A storage service inside the network does not mean an OCR provider outside it sees no documents.

A useful topology makes the browser/API, database, object storage and workers explicit. The scanner companion connects through a controlled application path. Outbound processing and mail are separate, reviewable dependencies. A reverse proxy terminates the public entry point according to the installation's requirements.

Next.js self-hosting guidance recommends a reverse proxy and describes coordination concerns when running multiple instances. Cache state and invalidation need an intentional multi-instance design; a process-local cache is not shared business truth. Keep authoritative authorization and mutation checks in the server/database path.

The scenarios below are reference deployment profiles. They illustrate policy and capability choices; they are not a list of certified DocuBex installation modes.

Deployment is a compatibility exercise. The database has a current schema, workers have a job contract, desktop clients have versions and some clients may hold unsynchronized work. Changing the web process alone does not update all of them at once.

Hilton's recorded Windows replay correction is a concrete warning: an older queued warehouse command used a field shape different from the current executor. That work had to remain understandable after the application evolved. On-premises distribution makes such version overlap especially visible because installation timing may belong to the customer.

A practical rollout plan uses an explicit compatibility window. First introduce server support for the new shape while retaining supported old readers and writers. Backfill or transform durable data with observable progress. Upgrade workers and clients in a documented order. Remove old support only when the relevant records and installed clients have passed the migration boundary.

Rollback also needs a real definition. If the new version writes data the old binary cannot understand, replacing the binary is not a complete rollback. An irreversible data transformation may require restore or a forward repair. Rehearse the chosen path against a copy of representative data.

Record the application build, schema version and worker/client compatibility in a release manifest. Keep secrets outside that manifest. The purpose is to make the installed combination inspectable when a customer reports a failure.

A document platform stores related facts in more than one place. Restoring database rows while losing their corresponding objects can leave an apparently healthy application full of unreadable files. Restoring bytes without the metadata and permissions leaves a different incomplete system.

Define a recovery set: database state, object versions, required configuration, protected keys and job state. Derived thumbnails or embeddings may be rebuildable; signed artifacts and originals may not be. State those distinctions rather than treating every directory as equally disposable.

PostgreSQL's backup and restore overview provides the database mechanisms. The application playbook must add cross-store consistency and a restore drill. In an isolated recovery environment, sign in, open a known document, verify its version and permissions, inspect pending work and confirm that recovery does not accidentally send external notifications.

Recovery point objective describes how much recent data loss is acceptable. Recovery time objective describes how long restoration may take. They are requirements to agree and measure, not numbers to invent from a successful backup command.

A restored queue can contain work whose external effect already happened. Resume it through reconciliation and idempotent transitions. Blindly replaying every restored message may repeat exports, mail or provider actions. Keep network egress controlled during the drill until those consequences have been inspected.

A deployment handover needs more than an administrator password and an installer. Someone must own certificate renewal, storage capacity, database maintenance, worker restarts, backups and incident escalation. Specify what the customer operates and what the application team can diagnose.

Logs should connect operation, job, document version and deployment identity without spilling file contents or credentials. Useful health checks distinguish liveness from readiness and optional capability health. An unavailable enrichment provider should not be disguised as a healthy processor or unnecessarily make every stored document inaccessible.

The case studies support the value of a shared core and explicit recovery state. Scale, data residency and installation reliability still require deployment-specific evidence. The advanced work is making those requirements testable: the same business model, a visible capability matrix and an operating contract that survives the first failure.