Blueprints and Forms
One definition. The whole self-service experience.
The template and the request form usually live in two systems that fall out of step. In Cycloid a Blueprint carries what gets built and what gets asked, and won’t publish if the two disagree.
Blueprint with its forms
Lifecycle
Three slots, and one of them is compulsory
A Blueprint holds the shape of the thing and the actions you can run on it. Each action can carry its own form, as a block inside the Blueprint, so the two version and publish together. Call the actions whatever you like. Underneath, a managed Blueprint always has three slots.
Create
It brings the resource into existence, and its form is the creation wizard. It isn’t optional. Publish a managed Blueprint with no create action and it’s rejected, with an error saying what to add.
Update
Where day-2 changes run, defaulting to create. Its form arrives prefilled from the last submission, so you change an answer instead of starting again.
Delete
Recommended, not required. Leave it out and removal is unlink-only. The resource leaves the catalogue and nothing gets destroyed.
Cycloid for your team
What one object changes for each reader
One artefact to review
The problem
You maintain a module, a request form and a runbook saying who may run what, and they agree with each other on a good day.
With Cycloid
One Blueprint carries the architecture, the actions, their forms and the authority, and publishing enforces that a managed Blueprint resolves its create action.
The outcome
One thing to change when the module changes.
Provisioning and operating,
one surface
The problem
The golden path is a wiki page, and the actual path is asking somebody who knows.
With Cycloid
Pick the Blueprint, its create form renders, you deploy. The same resource then offers its day-2 actions with their own forms, prefilled from what was submitted last time.
The outcome
You never leave the resource to operate the resource.
The control outlives the author
The problem
Controls live in the head of whoever wrote the module, so a departure becomes a governance event.
With Cycloid
Who may trigger each action, and who approves it, are declared on the Blueprint and resolve to ownership fields, additive over tenant rules and never relaxing them.
The outcome
The rule is in the definition, not in somebody’s memory of it.
How it works
From a module to a governed action
01 · Decide managed or tracked
No actions means a tracked resource with ownership, relationships and scorecards. Add one action and it’s managed.
02 · Keep removal honest
A tracked Blueprint that demands a delete-first is rejected at publish. For managed resources you pick the removal behaviour.
03 · Say who may run each action
An executor allowlist resolves to an ownership field, such as the DBA field for a schema migration. Approval can route the same way.
04 · Declare what it needs
A Blueprint needing a plugin you haven’t installed still imports. It waits with a badge and clears on its own once you install it.
05 · Publish a version
Publishing is deliberate and validated, and every resource remembers its version. One object means one blast radius.
Blueprint rules only ever add. They sit on top of your tenant and team approval rules and never relax them. A Blueprint can ask for more scrutiny on a dangerous action. It can’t buy its way past the production gate you set. Force-remove, optional plugins and trigger types are in the Blueprint actions docs.
From a module to a governed action
The short version
A Blueprint, counted
3
action slots behind every managed Blueprint
1
of them required, checked at publish
5
ways to trigger an action, click to schedule
0
actions, and it’s tracked, not managed
Resize the production checkout database.
That action is restricted on this Blueprint, and you’re not in the field it resolves to.
Denied · resize
Executor allowlist
Restricted to
Whoever holds the operator field
Working with your assistant
The assistant picks the action, not the architecture
Does the assistant get its own permissions?
No. There’s no service account and no elevated assistant role. If you can’t deploy to production, neither can the assistant you’re talking to, in Cycloid’s own assistant or any compliant MCP host.
Ask for a staging database and your assistant finds the Blueprint and renders its create form with what it already knows. What it can’t do is more interesting. No tool writes or edits a Blueprint. People author the architecture, and the assistant picks from what they published.
Day-2 works the same way. If the resize is restricted to the operator field and that isn’t you, your assistant is refused too, and told which membership was missing.
“
The choice to pick Cycloid came from a double need: support our DevOps approach while allowing us to become independent and autonomous.
Abraham Gaougaou
Head of Managed Services, Valiantys
Frequently asked questions
The Blueprint is the definition: properties, relationships, requirements and actions. Forms is what a person gets asked when they run an action. It’s a block inside the Blueprint, so the two can’t drift.
Yes, one per action. Create is the wizard, scale asks about replicas, upgrade asks about versions. They share one property schema, so a field means the same thing in every one of them.
You get a tracked resource. Cycloid provisions nothing and the entry exists for ownership, relationships and scorecards. Removal is always an unlink, and publishing enforces that.
Yes, on the action itself. An executor allowlist resolves to whoever holds an ownership field, so nobody’s name is hard-coded. It adds to your tenant rules and never relaxes them.
Bring a module and the rules around it
Twenty minutes, one Terraform module, and the question of who should be allowed to run what against it. We’ll build the Blueprint, the create form and one day-2 action, and show you the publish-time error you get if the definition is incomplete.