---
title: "Appliances and their endpoints"
section: "Builder Guide"
canonical_url: "https://support.buildwithhq.com/builder-guide/appliances-and-endpoints.html"
reviewed_at: "2026-09-14"
authority: Official
---

# Appliances and their endpoints

How container appliances declare what they do, what they can reach, and why none of it can change after release.

## In brief

- **Audience:** Builders installing or publishing appliances
- **Core idea:** The manifest is a contract, frozen at release
- **Related:** Marketplace, Audit & disclosure

An appliance is a container-based add-on that runs alongside your application with its own compute — typically for heavier processing your app calls out to. What makes appliances safe to install is that everything an appliance can do is **declared up front in a manifest, verified at publish, and frozen for the life of that version**. Nothing is discovered at runtime; nothing can quietly change.

## Endpoints: the appliance's entire surface

An appliance can only be called at the endpoints its manifest declares. Each endpoint is a complete contract:

| Declared per endpoint | What it controls |
| --- | --- |
| **Key and route** | A stable name and the HTTP method + path it answers on. Your app's actions bind to the key, so a new version can keep its promises even if internals change. |
| **Input and output schemas** | The exact shape of what goes in and what comes back. Calls that don't match the input schema are rejected before the appliance sees them. |
| **Required permission** | The platform permission a caller must hold. An endpoint with a required permission simply cannot be reached by a user who lacks it. |
| **Timeout and execution mode** | How long a call may run (default 60 seconds) and whether it answers synchronously or hands back a job to poll. |

A version with no declared endpoints cannot be published at all — an appliance with nothing callable is a packaging error, and the platform treats it as one.

## Egress: sealed or allow-listed, never open

Network reach out of an appliance follows one of exactly two policies, chosen at release:

- **Sealed** — the appliance can reach nothing outside the platform. Most appliances should be sealed; if the manifest declares any outside destination, publishing as sealed is refused.
- **Allow-listed** — the appliance may reach only the destinations its manifest names, each as a specific host and port with a stated purpose. Declaring the allow-list policy with an empty list is likewise refused — the two must agree.

When you review an appliance before installing, its egress list *is* its network behavior. An empty list means sealed. There is no third state.

## Versions are immutable, and provably so

Every release carries a **fingerprint** computed from the manifest, the exact container image digest, and the egress policy together. The image digest must be stated inside the manifest itself and match the image being released — a mismatch blocks the release. The result: the fingerprint identifies precisely one combination of code, contract, and network policy.

Versions move through a one-way lifecycle: **Draft → Published → Deprecated**. Only drafts can be edited; only published versions can be installed; deprecation sets a support-end date and removes the version from recommendation, without breaking existing installs. Releases can carry a publisher signature and a software bill of materials reference, and an emergency revocation path exists for a version that must be pulled.

## Every data access is on the record

When an installed appliance touches tenant data, the access is written to the tamper-evident disclosure ledger, with the version's code identity — that fingerprint — recorded at the moment of invocation. The audit trail therefore says not just *that* data was accessed but exactly *which code* accessed it. See [Audit trail and data disclosure](../trust/audit-and-disclosure.html).

Note

Reading an appliance listing, the questions to ask are always the same three: What endpoints does it expose? What can it reach (sealed, or which hosts)? What resources does it need? All three are in the manifest, and all three are frozen.

---

Capability review: 2026-09-14. [View the canonical guide](https://support.buildwithhq.com/builder-guide/appliances-and-endpoints.html).