DocsPublishing
How to publish blueprints to the Bivariant Marketplace — the packaging process, deep copy mechanics, version management, and distribution controls.
Publishing is the process of packaging a blueprint into an immutable artifact and making it available in the Marketplace. This page covers how the publishing process works and what happens behind the scenes.
Publishing workflow
1. Prepare the blueprint
Before publishing, ensure the blueprint is complete:
- All agents are configured with instructions and tools
- Flows are tested and working
- Collections have their schemas defined
- Integrations declare their required connections and auth schemes
- Knowledge base documents are uploaded and indexed
2. Initiate the publish
From the blueprint editor, select Publish to Marketplace. You will be prompted to:
- Set the version number — following semantic versioning (e.g.,
1.0.0) - Write release notes — describe what changed in this version
- Choose visibility — public, private, or restricted
3. Deep copy
The platform creates a deep copy of the entire blueprint. This is a critical step — the artifact captures a complete, independent snapshot:
| What is copied | Details |
|---|---|
| Agent definitions | Instructions, model config, tools, knowledge base refs |
| Flow graphs | All steps, groups, edges, triggers, and configurations |
| Collection schemas | Fields, types, validation, relationships |
| Integration specs | Operations, auth schemes, event channels |
| Action definitions | Runner configurations, input/output schemas |
| Metadata | Name, description, icon, category |
The deep copy means the artifact has no runtime dependencies on the original blueprint. Modifying or deleting the source blueprint does not affect the published artifact.
4. Artifact registration
The packaged artifact is registered in the Marketplace catalog with:
- Unique artifact ID
- Version number
- Publisher organization
- Visibility settings
- Listing metadata (description, category, tags)
Version management
Creating versions
Each publish creates a new version. The platform tracks the full version history:
v1.0.0 — Initial release
v1.1.0 — Added email notification flow
v1.2.0 — Updated agent instructions for better accuracy
v2.0.0 — Redesigned collection schema (breaking change)Version coexistence
Multiple versions can coexist in the Marketplace. Organizations that have acquired older versions continue to use them until they explicitly upgrade.
Deprecation
Publishers can mark older versions as deprecated. Deprecated versions:
- Are still functional for existing installations
- Show a deprecation notice in the Marketplace
- Are hidden from new acquisition searches
Distribution controls
Visibility settings
| Setting | Behavior |
|---|---|
| Public | Listed in the Marketplace catalog for all organizations |
| Private | Visible only to the publishing organization |
| Restricted | Visible only to explicitly allowed organizations |
Changing visibility
Visibility can be updated after publishing. Making a public artifact private removes it from the catalog but does not affect existing installations.
What happens at install time
When another organization installs a published artifact:
- The artifact's configuration is copied into the target space as a new app
- Collection schemas are created (empty — no data is copied)
- Integration connection placeholders are created — the installer must provide their own credentials
- Agents, flows, and actions are instantiated with the artifact's configuration
This ensures each installation is independent, with its own data and credentials.
Related concepts
- Artifacts — the versioned packages created by publishing
- Marketplace — where published artifacts are listed
- Blueprints — the source material for publishing
- Build vs Runtime — how build-time configuration becomes runtime instances