Hosted, self-hosted, white label

Hosted ALYT is the standard partner portfolio. A dedicated self-hosted installation exists on request for one customer tenant, such as a villa, mansion, business, or corporate facility. That customer remains an assigned customer in the partner portfolio, and self-hosting does not create a right to run an entire multi-customer partner platform. The current implementation supports both hosted and dedicated routes, but the dedicated route uses agreed scope, hardware, support, and branding rather than an automatic white-label entitlement.

Hosting models

	Hosted ALYT	Dedicated customer installation, on request
Customer scope	Standard hosted customer/partner relationships	One agreed customer tenant
Operation	ALYT operates the hosted platform	Operator responsibilities agreed per project
Hardware and local services	Existing PLATFORM home/hub route	Agreed SELF/local deployment and hardware
Branding	ALYT and verified partner attribution	Branding agreed explicitly; no automatic white-label entitlement
Support and updates	Established hosted support and update contracts	Scope, maintenance and support agreed per installation
Partner permissions	Current assignment and customer authorization	The same boundaries; self-hosting creates no extra privilege

The routing model for Property.hosting is already documented elsewhere in the portal. What matters for developers is that a dedicated installation is not proof that every commissioning path, offline feature, or deployment pattern is turnkey. Use the exact runtime behavior and acceptance receipts for the installation you are targeting. Jobs and Visits support both routes without changing tenancy or creating a whole-portfolio self-hosting option.

What developers can rely on

A dedicated installation is one agreed customer tenant on the operator’s own hardware or local deployment. Access boundaries do not change: household permissions remain narrower than staff permissions, DEV credentials act in the developer sandbox, and LIVE credentials apply only to their own installed connector. The platform still treats the tenant as a tenant, not as a new kind of portfolio.

Current behavior also preserves the hosted/local split: local functions can keep working during a cloud outage, while cloud-dependent connectors require the provider and network. A cloud connector does not work when its cloud path is unavailable.

Connector publication

Connectors follow two publication modes. A PUBLIC connector is approved and can be installed in every ALYT installation, hosted and self-hosted. A PRIVATE connector is not submitted or not approved, and it stays in the installation that wrote it. Central approval is what makes one connector available to everyone, and it is also what enables centrally distributed updates. A private connector stays under the operator’s responsibility, including updates.

This is a deliberate escape hatch. A connector for a product nobody else owns, such as an in-house system, a regional vendor, or something under NDA, is not blocked from use on the operator’s own platform. It does not appear in the central catalogue, and it does not gain any extra privilege by being private.

Self-host route

The self-host route is available end to end for moving a tenant from hosted ALYT to hardware of your own. The workflow is:

1. Export the tenant from the hosted platform with GET /tenants/{tenantId}/export. The request is available to a member of the tenant, including a developer’s session or DEV key for the sandbox, a household OWNER through app.alyt.com’s gateway, or staff.
2. Run the platform on your hardware using the standard compose-based deployment and matching environment from the documented example.
3. Import the tenant with POST /tenants/import as the platform OWNER of the installation. On a self-hosted install, the operator is staff.
4. Reconnect any imported connector that was exported without a secret. Devices return in PROVISIONING and re-register by serial with a pairing token from the new install.
5. Let the catalogue keep syncing. With the upstream configured, the installation mirrors every PUBLIC published connector from developers.alyt.com as definitions and versions at boot and hourly, outbound only.

The export contains the tenant name and three-letter code, its clients, properties and rooms, its connectors with the definition slug and pinned version, their endpoints, and its devices with units and serials. Secret connector fields are removed and listed in redactedFields. Device credentials, sessions, keys, tokens, telemetry, commands, audit data, and notifications do not travel with the export.

Import is one transaction. The tenant, clients, properties, rooms, connectors, endpoints, devices, and units come back under the same code. Import is refused with 409 if a tenant with that code already exists, or if a unit with one of those serials exists there. A connector whose definition the installation does not have is skipped and listed in missingDefinitions.

If a connector was imported without its secret, the import response lists it in needsReconnect together with the fields that must be supplied. Until then, the connector status is needs-reconnect.

Catalogue behavior

A self-hosted installation can pull the public catalogue from developers.alyt.com. The pull mirrors PUBLIC connector definitions and versions at boot and hourly, and it is outbound only. The offline rule stays in force: if the pull fails or returns nonsense, nothing changes. A house that has lost internet keeps every connector it already had.

Version pinning also stays in force. An integration keeps the definition version it was connected with. New connections take the newest version. Moving an existing integration to a different version remains an operator action.

Access and responsibility

A private connector runs on a white-labelled platform under the operator’s brand, not ALYT’s. ALYT vets what it distributes; it does not vet what someone installs on their own hardware. That boundary matters for support, branding, and liability. A private connector that reaches the central catalogue would break that boundary, so it is excluded rather than merely discouraged.

For developers, the practical rule is straightforward: hosted and dedicated installations share the same tenant model and connector rules, but a dedicated installation does not expand partner permissions, does not turn private connectors into public ones, and does not grant an automatic right to white label.