Teams & tenants

Planned design. TractorStack is in development. This page describes how it is designed to work; nothing here is available to install yet. See the roadmap for the status of each part.

Exploring An idea we are working through, not a committed design. Feedback from pilots will shape it.

Teams, organizations and multi-tenant MSP setups all raise the same question: how do you let several groups use one platform while making sure each one sees and changes only its own environments? Inside one company that might be separate product teams. For a managed service provider (MSP) it means separate customers, where a mistake is not just awkward but a breach of contract.

Separation by default, sharing by choice

The approach we are exploring is to separate tenants with plain, physical boundaries first: different GitLab groups and projects, different runners and different credentials. Clever permission rules inside one shared system are harder to reason about and easier to get wrong. Shared pieces, such as the GitLab server itself or a stack kit used by everyone, are added only where they carry no tenant data.

Multi-tenant MSP setups: three boundaries per tenant

Boundary	Per tenant	What it prevents
GitLab group and projects	A GitLab group per tenant, with one project (repository) per environment inside it	Seeing or proposing changes to another tenant’s infrastructure
Site runner	A GitLab Runner registered only to that tenant’s group	A job for one tenant running with another’s network access
Credentials	Separate age keys or secret paths, hypervisor accounts and backup keys	One leaked key exposing every customer

Each tenant also gets its own state database and its own backup buckets. Where tenants share hardware, the hypervisor and the network layer keep them apart. On Proxmox VE, the primary target, that means separate resource pools and API tokens limited to them, separate VLANs, and firewall rules held in code. On vSphere or another platform the customer already runs, the same idea uses that platform’s permissions; on bare metal, tenants simply get their own machines.

Teams inside one organization

For a single company the boundaries can be lighter. A common pattern we expect:

A platform team owns the network, hypervisor, OS and data services layers.
Product teams own their application stacks, in their own repositories or folders, with approvals from their own leads.
Changes that cross the line, such as a new database or a firewall opening, need sign-off from the platform team through a change request.

GitLab group membership, protected branches and merge request approval rules do most of this work. Sign-in for the people involved is covered in Sign-in & SSO.

MSP setups

For MSPs looking after many customers, we are exploring:

A runner on each customer site, so credentials for that customer’s hardware never leave it. The MSP works through the customer’s GitLab project, not through a central console holding every password.
Shared kits, separate copies. The MSP maintains versioned kits; each customer repository pins a version and upgrades when that customer approves. Rollout waves then move an upgrade across customers one group at a time.
Per-customer reporting. Status reports, alerts and audit records go to the right customer and the MSP team, never to another customer.
A clean exit. Because each customer owns its repository and its data, ending the contract means handing over access, not untangling a shared system.

Open questions

We have not settled how much cross-tenant overview an MSP should get, for example one report covering every customer’s backup status, without weakening the separation above. We also want to see how far GitLab’s group permissions go before something more is needed. If you run several teams or customers and want to help shape this, contact sales@infratractor.com.

Nothing on this page is built. It describes the direction we are exploring and may change.

Last updated 25 October 2026 · Questions or corrections: sales@infratractor.com