Organizations and projects

Before you create anything on SPEKTRA Edge you make two structural decisions: how to divide your fleet into projects, and how those projects sit under organizations. Both are cheap to get right at the start and awkward to change later, because a resource’s name — and therefore its identity — includes the project it belongs to.

This page explains the model and flags the choices to make deliberately.

Projects

A project is the unit of ownership and isolation. It holds devices, applications, secrets, metrics, alerting policies, and the role bindings that say who may touch them. Almost every resource on the platform lives inside one.

Two projects share nothing by default. A device in one is invisible to the other, a secret cannot be read across the boundary, and access granted in one grants nothing in the other. That makes the project the natural boundary for anything you want kept genuinely separate — customers, environments, business units.

The trade-off is that separation is not free. Anything you want to see across projects — a fleet-wide view, one alerting policy, a single dashboard — has to be assembled per project, because queries do not span them. Split for isolation you actually need, not for tidiness.

Organizations

An organization groups projects, and organizations can nest inside other organizations to mirror how your business is actually structured.

An organization carries three things its descendants inherit:

• Access. A role binding at organization level applies to every project beneath it. This is how you grant a platform team access once instead of project by project.
• Region policy. Which regions descendants may use, and which is the default.
• Which services descendants may enable, and the default business tier they get.

Inheritance flows downward only. A role granted on a project confers nothing on its parent organization or on a sibling project. When someone can see more than you expected, look upward from the resource, not sideways.

Every project records its full ancestry, so the effective access on a resource is the union of every binding from the root organization down to the project holding it.

Regions

A project’s region policy does two jobs:

• Enabled regions — the complete set of regions in which resources may be created. Creating a resource outside them is refused, not silently redirected.
• Default region — the one that handles resources not tied to a region of their own.

Region is part of a resource’s identity, not a routing hint, so the choice has consequences beyond latency:

• Limits are per region. A project enabled for two regions has two separate allowances for each resource type, not one shared pool. See Resource limits.
• Secrets do not cross regions. A secret in one region is not visible to a device in another; a multi-region fleet needs the secret created in each region it occupies. See Secrets.
• Queries are per region unless you deliberately widen them. The - wildcard reads across every region a project uses.

Enable the regions you need and no more. Adding one later is straightforward; having resources scattered across regions nobody meant to use is not.

Choices that are hard to change

Most of what you set when creating a project can be edited afterwards. These cannot, or not without disruption.

Pick the project ID deliberately. Something short, stable, and meaningful to a human reading a resource name two years from now — acme-retail-prod, not project-2 or a name containing a team that may be reorganized.

Business tier

The business tier — XSMALL, SMALL, MEDIUM, or LARGE — describes the expected size of the project and determines the default limits it is granted. Organizations set a default that child projects inherit unless they specify their own, and individual services can be given a different tier from the project’s overall one.

Start at the tier that matches your real intent. Under-sizing means requesting limit increases almost immediately; over-sizing reserves capacity you are not using.

Optional services

Some capabilities are not enabled by default and are switched on per project — Service Experience Insights, ZTNA, and the AI service among them.

Two gates apply, in order. The parent organization decides which services its descendants are allowed to use, and the project then decides which of those it enables. If a service appears unavailable when creating a project, the organization is usually the reason, not the project.

Enabling a service adds capability but also adds surface area — sidebar sections, resources, and permissions. Enable what you intend to use.

Structuring your projects

There is no universally right shape, but the trade is consistent: more projects buys isolation and costs you cross-cutting visibility.

Common patterns:

• By environment — separate production from staging so that access, limits, and an accidental bulk delete cannot cross the boundary. The most commonly worthwhile split.
• By customer or site group — where you genuinely need one project unable to see another. Note that limits are shared with child projects, so a hierarchy of customer projects needs the parent’s limits sized for all of them.
• By business unit, under organizations that mirror the reporting structure — so that access follows existing lines rather than being maintained by hand.

What usually does not justify a separate project is a group of devices you merely want to manage together. Labels do that job within one project, while keeping one view of the fleet and one set of alerting policies.

Next steps

• Accounts & access — granting people and services access to what you have created.
• Resource limits — what your project is allowed to hold.