iBlueprint tracks every significant change to a Blueprint as a numbered version, giving you a complete audit trail and the ability to roll back, compare, or branch off from any point in the Blueprint’s history. Versions follow semantic versioning (major.minor.patch) so the version number communicates the impact of each change at a glance.Documentation Index
Fetch the complete documentation index at: https://docs.iblueprint.ai/llms.txt
Use this file to discover all available pages before exploring further.
How versioning works
Each Blueprint starts at version1.0.0. When you save a new version, you choose one of three bump types:
| Bump type | When to use | Example |
|---|---|---|
| patch | Small fixes — typos in prompts, minor config tweaks | 1.0.0 → 1.0.1 |
| minor | New nodes added or non-breaking config changes | 1.0.0 → 1.1.0 |
| major | Breaking changes — restructured chain, removed nodes, changed variable names | 1.0.0 → 2.0.0 |
The currently active version is always the latest one. You cannot roll back to a previous version by default, but you can view any historical snapshot and use it to manually restore configuration.
Saving a new version
Make your changes
Edit nodes, update configurations, or rearrange the chain in the Blueprint editor. Your changes are auto-saved as a draft and do not create a new version yet.
Open the Version dialog
Click Save version in the top toolbar (or press
Ctrl+Shift+S). The version dialog appears showing the current version number.Add a changelog entry (optional)
Write a short note describing what changed. This appears in the version history and is visible to collaborators and, for public Blueprints, to Marketplace users.
Viewing version history
Open the History panel from the Blueprint editor sidebar to see a chronological list of all saved versions. Each entry shows:- The version number (e.g.
2.1.0) - The timestamp and the user who saved it
- The changelog note (if one was provided)
Forking a Blueprint
Forking creates a fully independent copy of a Blueprint under your account. The fork starts at version1.0.0 and has no ongoing link to the original — changes to either Blueprint do not affect the other.
Open the Blueprint menu
From the Blueprint list or inside the editor, click the … menu on the Blueprint you want to fork.
Select Fork / Duplicate
Click Fork (for public or shared Blueprints) or Duplicate (for your own Blueprints). Both actions produce the same result — a new independent copy.
Blueprint visibility
Every Blueprint has a visibility setting that controls who can see and run it:| Visibility | Who can access |
|---|---|
private | Only you and invited collaborators |
public | Anyone — the Blueprint appears in the Marketplace and can be forked by any iBlueprint user |
Publishing to the Marketplace
Publishing a Blueprint makes it discoverable in the iBlueprint Marketplace, where other users can find it, run it directly, or fork it as a starting point for their own work.Save the version you want to publish
Make sure the Blueprint is in a stable state and save it as a named version. Published Blueprints should have a changelog so users understand what the Blueprint does.
Fill in Marketplace metadata
Add a clear description, relevant tags, and a cover image. Blueprints with complete metadata surface higher in Marketplace search results.
Publishing does not lock the Blueprint. You can continue editing and saving new versions after publishing. Marketplace users always see the latest published version.
Blueprint status reference
| Status | Description |
|---|---|
draft | Work in progress. Private by default; not listed in the Marketplace. |
published | Released and visible according to its visibility setting. Can be private (shared with collaborators) or public (listed in the Marketplace). |