Skip to content
Sencai.docs

Blueprints & the catalog

A blueprint is a reusable template for a piece of infrastructure - a predefined instance configuration (provider, region, size, and any parameters you want to expose) that anyone with access to it can deploy in one action, instead of walking the full instance wizard each time.

Browsing the catalog

Section titled “Browsing the catalog”

Catalog → Blueprints (/gravity/catalog/blueprints) lists two groups:

  • Public blueprints - available to every organization on the platform, maintained centrally.
  • Your organization’s blueprints - created by your own team, visible only within your organization.

Filter by category (compute, Kubernetes, database, networking, storage, full stack, custom) or provider, or search by name, description, or tag. Each card shows a deploy count and, where the blueprint author has set one, an estimated monthly cost.

Deploying a blueprint

Section titled “Deploying a blueprint”

Click Deploy on any blueprint you have access to (any Member, Admin, or Owner in your organization can deploy - Viewer and Auditor cannot). If the blueprint defines parameters - a region, a size, a name prefix, anything the author chose to expose - you’ll be asked to fill those in before confirming; parameters with a default value are pre-filled. Deploying records a cloud instance from the blueprint’s configuration and lists it alongside your other instances. It does not provision one yet - see the note below.

Blueprint instances - tracking a deployment

Section titled “Blueprint instances - tracking a deployment”

Catalog → Instances (/gravity/catalog/instances) lists every blueprint deployment for your organization, separately from the plain instances list - which blueprint it came from, who deployed it, when, its overall progress, and (for multi-resource blueprints) a per-resource breakdown of what’s pending, ready, or failed. Each deployment links to the cloud instance it produced - see the caution above before expecting that progress to advance past Pending today.

Authoring a blueprint

Section titled “Authoring a blueprint”

Author Custom Blueprint (/gravity/catalog/blueprint-authoring) walks a five-step wizard: basic info (name, category, provider, version), the steps the blueprint performs, variables it exposes to whoever deploys it, an optional cost estimate and notes, and a final review before publishing.

You can also create a simpler blueprint directly from the catalog page’s New Blueprint button (unless your organization requires review - see Requiring review) - basic info, then the instance configuration template and any parameters, without the full authoring wizard.

Either way, choose whether the blueprint is:

  • Organization-only - visible and deployable only within your own organization, or
  • Public - visible in the shared catalog for every organization on the platform to deploy.

Requiring review before blueprints are published

Section titled “Requiring review before blueprints are published”

An organization can require every blueprint to be reviewed before it is published. Anyone who may change the organization’s settings turns it on in Organisations → (your organization) → Settings → Blueprint review, with the checkbox Require review before blueprints are published. It is off by default.

With review off, members can create a blueprint instantly and publish a draft from the authoring wizard straight away. With review on:

  • The catalog’s New Blueprint button is replaced by Submit for review, which opens the authoring wizard, and a note on the page says that instant creation is turned off. This applies to everyone in the organization, platform administrators included.
  • In the wizard’s last step, Request Review comes first. The draft then shows “Review requested - awaiting admin approval”, and an admin of the organization is notified. A draft that has not been put into review cannot be published; the platform refuses it.

Versioning

Section titled “Versioning”

Blueprints carry a version string you set yourself (for example 1.0.0) - there’s no automated version bump or change history beyond that field today. If you need to track meaningfully different revisions of the same template, give each one a distinct version and description rather than editing in place, so existing deploy counts and any in-progress deployments stay attributable to the version that produced them.

What’s next

Section titled “What’s next”