Builder Guide
Appliances and their endpoints
How container appliances declare what they do, what they can reach, and why none of it can change after release.
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.
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. For exact current technical availability, use the generated API Map and first-class module inventory.