Websites had their WordPress moment. SaaS is having its BuildWithHQ moment. See the new BuildWithHQ homepage →
Home/Templates/Custom services
Installable custom services

Install a custom service once, then call it from anywhere

An installable custom service is exactly that: a real service running in its own container — document processing, a specialist model, an industry calculation, anything that does not belong inside a visual builder. It arrives as a signed package, declares the endpoints it exposes, and is then callable from your pages, workflows, scheduled jobs, and AI actions. In the product these are called appliance endpoints.

Provenance

You always know what is running

See the appliance catalog

Publisher signature

Every version is signed, and signing key history is retained so an old release can still be verified.

Image digest and manifest hash

The exact build and the exact declared contract, both fingerprinted.

SBOM reference

A bill of materials for what is inside the package, for the review your security team will ask for.

Release fingerprint

One value derived from the manifest, the image, and the egress policy together — a single thing to compare.

Governance

Declared, validated, revocable

Provenance tells you what is running. These three tell you what it is allowed to do.

Declared egress policy

A package states what it needs to reach. Sealed means nothing. Allowlist means exactly the declared destinations and nothing else.

Validation before listing

A version cannot be listed until it passes validation, so the marketplace does not become a distribution channel for unfinished work.

Emergency revocation

A bad release can be revoked centrally rather than depending on every installer noticing and acting.

Full invocation ledger

Request and response hashes, outcome, status, duration, package version, endpoint, and the code identity frozen at the moment of the call.

Calling an appliance

Six steps, all recorded

The execution path is deliberately boring, because the interesting failures happen when it is not.

  • Trigger. A page action, workflow step, AI action, schedule, or API request selects an endpoint.
  • Authorize. The platform checks the required permission before the call is made. The appliance never adjudicates its own access.
  • Validate. The input is checked against the schema the package declared.
  • Resolve secrets. Credentials come from approved mappings server-side, never from the request.
  • Execute. The container runs the work under its declared resource limits and timeout.
  • Log evidence. Hashes, outcome, duration, version, and disclosure details enter the ledger.
Common questions

Questions about this

What is the difference between an appliance and an extension?

They are closely related. An extension is custom code you commission for your own application. An appliance is that same isolated-container model packaged as a distributable, signed, versioned product that others can install.

Can an appliance reach the internet?

Only if its manifest declares it. Sealed packages reach nothing at all, allowlist packages reach only what they declared, and the manifest is authoritative — a mismatch is a validation failure, not a warning.

What happens if a published appliance turns out to be unsafe?

A release can be revoked. Revocation does not depend on every installer noticing an advisory and acting on it.

Get started

Build it, then prove what it did

Create an account, explore the full builder console, and launch your first application on a custom domain. Nothing is charged while your application is still in development.

Start building today

No credit card required. The console preview, the documentation, and the architecture reference are all readable before you sign up.

Get started free Read the docs