Support/Trust & Security/Business continuity and application portability
/

Trust & Security

Business continuity and application portability

How applications can relocate to AWS or Azure, or be restored in a cloud or virtual machine if BuildWithHQ shuts down.

Enterprise option
Relocate to AWS or Azure
Shutdown option
Run in a cloud or virtual machine
Recovery unit
One isolated customer at a time

Two reasons to relocate

The same portability model supports two distinct situations:

  • Enterprise deployment: while BuildWithHQ is operating, an enterprise customer can arrange for its workload to run in an agreed AWS or Azure environment, including a customer-approved virtual-machine architecture.
  • Company shutdown: if BuildWithHQ ceases operation, customers can restore their applications to a cloud environment or virtual machine using their exported application definitions, isolated data, files, and the released continuity runtime.

What can be carried forward

  • Application definition: versioned JSON documents and JSON Schema contracts for pages, components, approved bindings, workflows, and related configuration.
  • Customer database: the customer's records, AI data, operational history, and audit history from that customer's isolated database.
  • Files: uploaded documents, images, attachments, and the metadata that connects them to records.
  • Restore metadata: schemas, settings, manifests, versions, and checksums needed to inventory and validate the package.
  • Continuity runtime: the managed API code and JSON interpreter needed to execute the exported application definitions if BuildWithHQ shuts down.

Why the database boundary matters

Customer data is not mixed with other customers in shared application tables. Each customer has its own database and audit history. That means a recovery team can restore one customer from its own package without first extracting that customer from a multi-customer data store. The same boundary also makes it practical for different customers to choose different recovery hosts.

Customer-owned restore bundles

A customer can direct restore bundles to customer-owned Amazon S3 storage. The customer controls the bucket, region, access, retention, versioning, and optional Object Lock. Each bundle includes a machine-readable manifest and checksums so the package can be inventoried and checked before a restore begins.

Tip

Keep periodic restore bundles in storage your organization controls and test the checksums. Portability is strongest when the latest usable copy already exists outside the platform.

Shutdown continuity release

If BuildWithHQ ceases operation, BuildWithHQ will release the managed API code and JSON interpreter required to run exported BuildWithHQ application definitions. The resulting system can run in a cloud environment or on a virtual machine. The objective is to let each customer bring its own application back online with its own hosting instead of receiving only raw data and starting a complete rebuild.

Recovery sequence

  1. Choose the target AWS, Azure, other cloud, or virtual-machine environment.
  2. Verify the restore bundle against its manifest and checksums.
  3. Restore the customer's isolated database and uploaded files.
  4. Load the exported page, workflow, schema, and settings definitions.
  5. Deploy the managed API code and JSON interpreter supplied through the continuity release.
  6. Recreate credentials and third-party connections; secrets are deliberately excluded from exports.
  7. Validate the application, then move the customer's domain or traffic to the restored environment.

What portability does not silently assume

Exports do not include usable passwords, API keys, OAuth tokens, or other live credentials. Third-party accounts, cloud tenancy, DNS control, and licenses for external services remain with their respective owners. Exact residency, retention, RPO, RTO, and operating-responsibility commitments are recorded in the applicable service terms or enterprise operating plan.

Related documentation