Deploy governed environments on demand.
Any team. Any stack.

A blueprint is a governed, reusable environment definition assembled from IaC modules in the Curated inventory. It defines the components of an environment: compute, network, storage, and application layers, along with the configuration parameters users can set, the policy constraints that govern the deployment (cost caps, TTL limits, cloud account restrictions), and the RBAC controls that determine who can deploy it. A blueprint is the unit that platform teams publish and end users consume.

The AI Environment Designer allows users to describe an environment in natural language — “a web application stack with a load balancer, two app servers, and a Postgres database on AWS” — and the AI Copilot searches the Curated inventory, identifies the right IaC modules, maps their dependencies, and generates a deployable blueprint. The blueprint is built from your actual, governed assets, not generic templates. The quality and accuracy of what the Copilot generates is directly tied to the completeness of the Curate inventory it works from.

Anyone your platform team grants access to. Self-Service uses role-based access controls to determine who can see and deploy each blueprint. Platform teams configure which teams, roles, and users have access to each blueprint when they publish it. Developers, data scientists, QA engineers, solution engineers, and product managers can all use Self-Service — with each group seeing only the blueprints relevant to their work.

Governance in Self-Service is enforced at the blueprint level, before deployment, not after. Platform teams configure cost caps (maximum spend per environment), TTL limits (maximum runtime), cloud account restrictions (which accounts the environment can deploy to), and approval workflows (whether certain deployments require sign-off before they proceed). These constraints are baked into the blueprint. Users cannot override them. Every deployment is policy-compliant by construction.

Yes. Self-Service integrates with Backstage, Port, and OpsLevel via the Torque API, making the catalog and deployment workflow available inside your existing IDP. It also integrates with VS Code and JetBrains IDEs, GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps, ServiceNow, and Jira. The Self-Service catalog is not a destination; it’s a capability that plugs into wherever your teams already work.

Environments deployed through Self-Service have TTL-based auto-expiry. Users receive advance notification before an environment expires and can request an extension, subject to policy limits. When the TTL is reached, the environment is terminated cleanly: all resources are destroyed, costs are attributed, and a record is written. If an extension requires approval, the workflow is handled automatically. Nothing is left running silently.

Yes. Self-Service is not a pre-production-only tool. The same governed catalog that serves development and QA can serve production workloads, with the appropriate policy guardrails applied at the blueprint level. Production blueprints can require approval workflows before deployment, enforce stricter cost and TTL policies, restrict which cloud accounts they deploy to, and require mandatory tagging for cost attribution and compliance. The governance model scales to production requirements without requiring a different tool or process.

Yes. For environments backed by finite or constrained resources — GPU clusters, specialized hardware, or capacity-limited cloud quotas — Self-Service supports advance reservation. Users browse available time slots directly in the catalog, book the capacity they need, and receive a confirmed availability window. The environment provisions automatically when the reserved slot arrives. This eliminates the uncertainty of queuing for shared resources and gives teams a predictable schedule for when their environment will be ready, without any manual coordination with the platform team.