Infrastructure has always had boundaries. You can automate it, standardize it, put it in a catalog, and deploy it across clouds. But the infrastructure an organization builds, and the automation, governance, credentials, and operational knowledge behind it, has largely remained bound to the organization that created it. Delivering that capability to another business, customer, partner, region, or independently operated site has meant rebuilding it, copying it, or handing over code and control.
Federated infrastructure breaks that boundary. An organization can define an infrastructure capability once and deliver it to teams, customers, and partners wherever their infrastructure runs. They can consume it as delivered, extend it with their own technology, or turn it into a service and deliver it again to their customers. Infrastructure and credentials can remain with their owners, while governance, policy, lifecycle control, and consumption visibility continue across organizational boundaries, and across multiple levels of delivery.
That changes much more than how infrastructure is deployed. It changes what organizations can do with it. Technology vendors can distribute complete, ready-to-run environments rather than installation instructions. Partners can add their own technology and services without forking what came before. Service providers can deliver into infrastructure they don’t own. Central IT can govern capabilities deployed across independently operated teams and locations. And infrastructure that was once locked inside a company, cloud, data center, or site can become a capability that is packaged, distributed, extended, consumed, and ultimately offered onward.
Every organization that can’t deliver infrastructure beyond its own walls pays for it five ways: growth it can’t scale, risk it can’t see, delivery it can’t speed up, operations that never finish, and costs it can’t trace.
Wasted cloud spend has risen to 29%, the first increase in five years, as AI workloads surge. – Flexera, 2026 State of the Cloud Report
When each team, customer, region, or site gets infrastructure built by hand or from a copied script, headcount sets the limit on scale. Every new customer or location means another round of engineering. Each copy drifts a little further from the standard, and non-standard infrastructure is where security gaps, compliance failures, and outages start. Delivery that should take minutes takes weeks.
The work doesn’t end at deployment either: every variant has to be patched, updated, and audited on its own, so day-2 operations consume the engineers who should be building the next service. The business pays in delayed revenue, missed service commitments, and cloud spend nobody can attribute to a customer or a team.
A platform that federates infrastructure removes that ceiling. It lets an organization define infrastructure once, deliver it to any number of teams, customers, and partners on whatever infrastructure they run, and keep every copy governed, current, and accounted for.
Infrastructure stays where it was built
More organizations want to deliver infrastructure as a service. Systems integrators want to package their expertise. Technology vendors want to give customers ready-to-run environments. Service providers want to sell capacity with the services on top. Central IT teams want to serve business units that run their own technology.
Most hit the same wall. Infrastructure, and the automation that builds it, stays locked inside the organization that created it. The code is written for one set of cloud accounts, one data center, and one team’s toolchain. Moving it to another organization means rewriting it, and sharing it means handing over code the receiver then has to maintain alone.
Quali Torque and Stack Automation by Quali remove the wall. Organizations already use them to deliver governed environments to other teams, to other companies, and to their customers’ customers, on whatever infrastructure each one runs. The capability is called federation, but the word matters less than what it makes possible. This post covers why it has been so hard to do, and the four patterns it now supports.
Why this has been hard
Plenty of products solve part of this problem. Some unify a few infrastructure-as-code tools, some offer a self-service catalog, and some add policy or cost reporting. Delivering infrastructure across organizations needs all of those pieces working together, and that combination has been missing.
Companies building infrastructure service businesses have told us so directly. They came to Torque after looking elsewhere.
More than 50% of organizations will not get the expected results from their multicloud implementations by 2029. – Gartner, Top Trends
Six barriers stand in the way:
| Barrier | What it causes | How Torque handles it |
| Fragmented automation | Terraform, OpenTofu, CloudFormation, Ansible, Helm, and scripts each bring their own state, credentials, and skills. A receiving organization would have to adopt the provider’s exact toolchain. | A blueprint wraps existing automation as building blocks. The consumer deploys the blueprint and never needs to know which tools sit underneath. |
| Automation tied to one place | Code hardcodes accounts, regions, and networks. It describes one environment in one location. | The blueprint declares what it needs and binds to the target infrastructure at deployment time. |
| Extension means forking | Adding your own technology means copying the provider’s code. Updates stop flowing and versions drift. | Blueprints nest inside other blueprints. The upstream stays intact and keeps updating, and your additions stay yours. |
| Governance stops at the company edge | Access control, policies, and approvals assume everyone works for the same company. | Spaces set the boundary. Each one has its own catalog, permissions, policies, and approvals. |
| No usage data to build a business on | Cost is a report for internal teams, not a record of who consumed what. | Cost and usage are tracked per environment, blueprint, Space, and cloud account. |
| Execution has to happen where the infrastructure lives | A provider can’t hold every customer’s credentials or pull data out of their accounts. | A lightweight agent runs inside the target environment, connects outbound only, and keeps credentials local. |
From dividing infrastructure to distributing it
Federation has traditionally started from the resource. An organization has a fixed pool of hardware, or a cloud budget, and needs to share it out. That makes it an allocation problem, and it ends at the edge of the pool.
Torque starts from the blueprint. A blueprint describes an environment: the infrastructure, applications, networking, and policies it needs, and how they fit together. It doesn’t say where they come from. When someone deploys it, the blueprint finds the resources it needs on the target infrastructure, whether that’s a public cloud, a private data center, a Kubernetes cluster, or an edge site.
Spaces decide who gets which blueprints. A Space groups a set of blueprints for a specific audience: a customer, a business unit, a partner, a stage of the application lifecycle, or a fleet of sites. Each Space carries its own permissions, policies, approvals, and cost visibility.
Together, those two ideas turn infrastructure into something you can distribute. The provider defines the capability once, and each consumer deploys it on its own terms and its own infrastructure. The patterns below build from simple to complex.
How federation works
Federation connects one Torque account, the provider, to any number of other accounts, the subscribers. The provider creates an offering: a named package of the Spaces, the infrastructure, or both that it wants to share, with optional limits such as the number of subscribers and an expiration date. Each offering generates a secure token. The subscriber enters that token, and the provider’s catalog and capacity appear inside the subscriber’s own account as if they were its own.
Neither side has to learn anything new. Shared content arrives as a Space, next to the Spaces the subscriber already uses. Shared infrastructure arrives as a provider, in the same list as the subscriber’s clouds and data centers. The provider sees every subscriber and can remove any of them at any time.
Federations can be private, where both sides complete a token handshake, or public, where a catalog is open to any identified user and provisioned automatically. Four sharing models cover most needs:
| Model | What gets shared | Typical provider |
| Dedicated | Specific infrastructure assigned exclusively to one customer | Sovereign cloud operators carving out capacity for a single tenant |
| Shared pool | Infrastructure made available to several customers | Managed service providers offering common capacity at lower cost |
| Content only | Blueprints and catalog, with environments running on the subscriber’s own infrastructure | Software vendors and partners publishing solutions |
| Public marketplace | Catalog and infrastructure open to any identified user, provisioned automatically | Developer programs and hands-on lab platforms |
Each model maps to one or more of the patterns below.
Pattern 1: A self-service catalog
The simplest form of federation is one most people have already used. A provider publishes a catalog of blueprints, and teams deploy what they need on demand, without filing a ticket.
One catalog serving many teams.
Pattern 1. Self-service catalog
The provider owns both the infrastructure and the blueprints. Each consumer group gets a Space containing only the blueprints meant for it, plus the policies that govern their use, such as how long an environment runs and who approves it. Technology vendors running hands-on labs, training providers, and central IT teams serving developers all fit this pattern. In its most open form, the catalog is public: available to any identified user and provisioned automatically, with no invitation needed. Vendors can also federate training environments to their partners, turning training from a cost into a revenue stream.
Even at this level, the blueprint does the heavy lifting. Consumers don’t need to know Terraform or Helm, and the provider updates a blueprint once for every team that uses it.
Patterns 2 and 3: Extend it, then deliver it
Federation becomes more interesting when the consumer has its own infrastructure and its own technology. Company A provides blueprints and services to Companies B and C. C uses them as they are. B pays for what it deploys from A, then adds its own technology on top.
Each company or organization adds its own technology and IP and passes it on.
Patterns 2 and 3. Extend, then deliver
Pattern 2: extend. Where A allows it, B builds on A’s blueprint rather than copying it. A’s blueprint sits inside B’s as a building block, so A’s updates keep flowing while B’s additions stay B’s own. B can deploy the result onto its own infrastructure, whether that’s a different cloud from A’s or its own data center.
Pattern 3: deliver as a service. B goes further, adding applications, proprietary configuration, and domain knowledge until the blueprint no longer describes generic infrastructure. It describes a service that B offers. B can sell that service to its own customers, bundle it for internal teams, or both. Channel partners use this pattern to add a billable service layer, such as hosted labs or proving grounds, on top of the products they resell.
B doesn’t need to host anything for its customers. Torque can run inside a customer’s own cloud account, where the customer owns the account, the data, and the infrastructure that gets built. The license holder manages the blueprints, delivers the services, and is paid for what it delivers. That gives regulated industries a way to consume infrastructure services without data leaving their environment. A provider can also host its own instance and federate Spaces to customer tenants, which suits sovereign cloud operators that sell blueprints, infrastructure, and tenancy separately or as a bundle.
Over 50% of multinational organizations will have digital sovereignty strategies by 2029, up from less than 10%. – Gartner, Top Trends Shaping the Future of Cloud
Pattern 4: No fixed ceiling
The same mechanism repeats at every level. Company A can serve many partners and service providers. Each of them can add its own technology and serve many customers and internal teams, and each of those can do the same again.
Every consumer can become a provider
Pattern 4. Multi-level federation
This isn’t a hypothetical. Large infrastructure and technology providers are building exactly this kind of ecosystem today, and several came to Quali because they couldn’t find another platform that supported it.
What keeps a model like this manageable is control at every hop. Each provider decides which blueprints it publishes, to which Spaces, under which policies. Each consumer sees only what it has been given, adds only what it owns, and answers to the policies of the layers above it. Usage is tracked at every level, so each provider knows what its consumers deployed and what it cost. The platform stays out of the billing relationship: each provider charges its subscribers however it chooses, using the consumption reporting the platform supplies.
Where it currently matters most: the unified edge
Edge computing strains the traditional infrastructure model more than anything else. A retailer, manufacturer, or healthcare network may run hundreds or thousands of sites. Most have no IT staff on site, and hardware and connectivity differ from one site to the next. Central IT owns the platform, regional teams or franchisees run the sites, and outside vendors supply the applications.
Maintaining automation by hand for each site doesn’t scale, and copying code for each region produces thousands of slightly different sites that nobody can govern. Federation replaces both approaches with one governed stack.
Governed edge stacks reach every location
Unified edge. One stack, every site
Central IT, or the platform vendor, publishes the base edge blueprint once. Application partners add their layer on top without taking ownership of the base. Regions and franchise groups each get a Space with the local settings they’re allowed to change. Every site then deploys the same blueprint, which binds to whatever hardware sits at that location.
The result is consistency without micromanagement. One change to the base blueprint reaches every site that uses it. Partners can deliver into edge estates they don’t own, and every site stays inside the policies set above it. As integrated edge platforms built for distributed AI reach the market, this is the operating model that makes them manageable at scale.
Where this leads: an infrastructure mesh
Every pattern above rests on one idea: define infrastructure once and deliver it anywhere. Follow that idea to its end and the line between provider and consumer disappears.
Picture a highly distributed organization, or a group of organizations, in which every participant can both offer and use infrastructure. A data center that sits idle overnight, a GPU cluster between training runs, a partner cloud with room to spare: each can offer its capacity into a shared pool. A team with a business need draws from whichever sources meet its policy, cost, and location requirements, and the blueprint assembles the environment from them.
Every participant can provide, consume, or add value.
The vision. An infrastructure mesh
In that model, infrastructure works like a market:
- Anyone can provide. Owners lease out capacity they aren’t using instead of paying for it to sit idle.
- Anyone can consume. Teams subscribe to what they need without owning or building it.
- Anyone can add value. Service builders layer their own technology on top of pooled infrastructure and charge for the result.
- Everyone meters the same way. Measuring consumption in common compute units lets every participant price, pay, and get paid on the same terms.
“An application built on the intercloud layer should be oblivious of the cloud it is running on.” – Ion Stoica and Scott Shenker, UC Berkeley, “From Cloud Computing to Sky Computing”
The idea of a mesh isn’t new. What has been missing is the foundation that makes it practical: a common way to describe what a workload needs, independent of where it runs, plus governance and metering that hold up across ownership boundaries. Blueprints, Spaces, and usage tracking per environment provide that foundation. Built on it, infrastructure as a service stops being something only the largest cloud providers can offer. Any organization with capacity or expertise can offer it. Federation is the first layer of that foundation, and it already connects providers and subscribers through shared Spaces and shared capacity.
What a mesh demands: complete control of infrastructure
A mesh only works if the platform running it can see and govern every resource in it, which takes a level of control most organizations don’t have today. The platform has to know what is running, what sits idle, when each resource is in use, and when it’s reserved for work that’s coming. It has to make infrastructure from different owners and locations consistent enough to compare, price, and trust. And it has to show what is available and underused, not only what is in use.
Control turns idea infrastructure into value.
This is where Torque is focused. Every environment it deploys comes from a blueprint, so every resource is described the same way, has an owner, and follows a lifecycle: when it starts, how long it runs, and when it ends. Environments can be scheduled ahead of need, so the platform knows what’s planned as well as what’s live. Discovery and inventory reveal infrastructure beyond the environments Torque created, and usage and cost are tracked per environment, blueprint, and Space.
That control changes how infrastructure earns its keep. Most infrastructure today is charged by usage: the minutes a workload ran. In a mesh, value comes from consumption in the broader sense, meaning capacity that is reserved, held ready, scheduled, and delivered as a complete environment.
Idle infrastructure stops being a sunk cost and becomes inventory that can be offered, reserved, and sold. Priced per environment, potentially as consumption credits redeemed against a blueprint, it lets buyers pay for an outcome and lets owners earn from capacity that would otherwise sit dark.
The platform’s job then goes well beyond basic optimization. Rightsizing and shutting down idle resources recovers waste. Maximizing use means continuously matching demand anywhere in the mesh with supply anywhere else, so capacity finds work instead of waiting for it.
What this changes
For most organizations, infrastructure has been something you build and then operate. Federation makes it something you can package, deliver, and extend, the same way software moved from custom installs to distributed products.
The mechanism stays simple: blueprints that declare what they need, and Spaces that decide who gets them. What organizations build on it varies widely: a self-service catalog, a partner ecosystem, a managed service running inside a customer’s cloud, or a standard stack running across thousands of edge sites.
If your organization wants to deliver infrastructure beyond its own walls, or needs to bring discipline to infrastructure spread across many teams and locations, talk to us about how Torque federation fits your model.
Sources
- Flexera, 2026 State of the Cloud Report, March 2026. Survey of more than 750 cloud decision-makers.
- Gartner, Gartner Identifies the Top Trends Shaping the Future of Cloud, press release, May 13, 2025. Source for the multicloud and digital sovereignty predictions.
- Cast AI, 2026 State of Kubernetes Optimization Report, April 2026. Analysis of tens of thousands of Kubernetes clusters.
- Ion Stoica and Scott Shenker, From Cloud Computing to Sky Computing, Workshop on Hot Topics in Operating Systems (HotOS), UC Berkeley, 2021.
