Custom code in its own container, without exposing the platform core

Each extension container is registered to a SaaS application and customer account with role, runtime, host, image, resource limits, status, and health information.

CPU, memory, GPU hints, runtime type, and host placement can be tracked independently for each container.

A crashing or misbehaving custom service affects its own container rather than the central execution engine or other tenants.

Custom services can be upgraded or restarted without redeploying the shared BuildWithHQ application.

Extension packages include publishers, semantic versions, image digests, manifests, release fingerprints, signatures, and SBOM references.

The package defines endpoint keys, methods, request and response contracts, timeouts, and operational requirements.

Outbound network behavior can be declared and validated instead of allowing unrestricted calls by default.

Credentials remain server-side and are referenced through approved secret mappings rather than exposed to the browser.

A page action, workflow, AI action, schedule, or API request selects an extension endpoint.

The platform resolves the tenant, user, record, DataRoles, location, and required permission.

Trusted tenant and user context is injected server-side; untrusted browser values are validated.

The gateway calls the isolated endpoint and enforces timeout, size, rate, and egress rules.

Structured JSON results return to the workflow, page, record, or AI action.

Request and response hashes, outcome, status, duration, package version, endpoint, and disclosure details enter the invocation ledger.

Install specialist libraries that should not run in the shared platform.

Run data synchronization, transformation, document processing, or long-running vertical logic.

Keep customer or agency code private inside the customer’s isolated environment.

Wrap complex vendor SDKs behind a clean JSON API that the visual builder and workflow engine can use.