Tenants & projects

Almost everything in the Center belongs to a tenant and, usually, to a project inside it. Getting these right early matters, because moving things between them later is harder than placing them correctly now.

Tenants

A tenant is an organisation. Tenants nest: an operator can hold resellers, who hold end customers. A tenant can see itself and everything beneath it, and nothing above or beside it.

Una (operator)
├── Reseller A
│   ├── Water Utility
│   └── Facilities Co
└── Reseller B
    └── Municipality

Reseller A sees Water Utility and Facilities Co. It cannot see Reseller B, and Water Utility cannot see its sibling.

The active tenant

The sidebar shows your active tenant. It is not decoration — it decides where everything you create lands, and what you see in every list.

If you belong to more than one tenant, check it before creating anything. A device created under the wrong tenant is invisible from the right one.

The network side of a tenant

A tenant also has a home on each network it is granted: a Sigfox group, a The Things Stack organization, a ChirpStack tenant. Creating a tenant ends with one step per technology, and the same panels sit on the tenant page afterwards. Each offers two ways in — create it from the Center, or start with one that already exists on the network (picked from a live list, or by id when live reads are off). Starting with an existing one writes nothing to the network; the Center records the id and hangs everything below it there.

On The Things Stack, provisioning the tenant does one more thing. The Center mints an organization API key named una-center on that organization — with just the rights it needs, never "all rights" — and stores it as the tenant's managed credential tts-auto. From then on every call the tenant makes to the LNS goes out with its own organization key; saving the tenant pushes its name to the organization; the panel shows whether the key is still on the LNS and offers Rotate the organization key. An organization another tenant already runs on is shown in the picker but not offered.

Nobody pastes keys per tenant. The platform (or reseller) tenant holds one The Things Stack credential — a personal or organization API key with organization and application rights — and a sub-tenant is provisioned with its parent's key, or the platform's: the key above mints the key below, exactly as Sigfox provisions sub-tenants with the platform master key.

Projects

A project is a deployment: a set of devices, the integrations they talk through, and the routing and rules between them. Devices, integrations, routes and rules all belong to exactly one project.

How to split them

The useful question is "do these devices share a data pipeline?"

• Same project when devices feed the same destinations in the same shape. Twenty apartment blocks reporting to one billing system is one project.
• Different projects when the routing differs. A pilot deployment sending to a staging endpoint and a live rollout sending to production are two projects, even for the same customer.

Splitting more finely than that means repeating the same routes and rules in several places, and keeping them in step by hand.

Provider defaults

A project can hold provider defaults — settings new devices inherit rather than being retyped per device. For Sigfox that is the default device type new devices are created under; for LoRaWAN, the radio defaults new devices register with — frequency plan, LoRaWAN version, class and MAC settings.

A device can override what it inherits. The default is a convenience, not a constraint.

Where: Projects → your project → Provider defaults.

One LNS application per project

A project with a The Things Stack source maps onto exactly one application on the LNS, under the tenant's organization. Linking — from the source wizard or the project's The Things Stack panel — creates the application (or picks an existing one), a webhook from it into the project's source, and an una-center application key kept on that source. The panel shows the link, the webhook events, whether the key is still on the LNS, and warns when the webhook drifted — Re-apply fixes it; Rotate the application key mints a fresh key on the next apply.

Change application re-points the project at another application; the current one is unlinked, and kept, first. Unlink takes the webhook and the Center's key off the application and keeps the project's device defaults — tick Also delete the application on the LNS only for an application nothing else uses, since its end devices go with it. Deleting the project, or its The Things Stack source, unlinks the same way and keeps the application.

What sits where

Profiles and decoders are deliberately tenant-level: a device model does not change because you deployed it somewhere else, so you define it once and use it in every project.

Next